FranGarcia.me (Posts about vmware)https://www.frangarcia.me/categories/vmware.atom2023-07-01T22:22:36ZFran GarciaNikolaSatellite 6.2 : Adding RHV4 compute resourceshttps://www.frangarcia.me/posts/satellite-62-adding-rhv4-compute-resources/2017-06-29T12:12:30+02:002017-06-29T12:12:30+02:00Fran Garcia<p>Satellite server allows to manage compute resources such as Vmware and Red Hat
Virtualization (RHEV/RHV). In the later RHV versions there's a caveat on how
they should be added into Satellite.</p>
<ul>
<li>The RHV certificate file has changed location:</li>
</ul>
<p><code>http://rhv4-fqdn//ovirt-engine/services/pki-resource?resource=ca-certificate&format=X509-PEM-CA</code> </p>
<ul>
<li>The API endpoint should be specified with a 'v3' tag, as follows :</li>
</ul>
<p><code>https://rhv4-fqdn/ovirt-engine/api/v3</code></p>
<p>Happy hacking!</p>Actualizar herramientas de HP con VUMhttps://www.frangarcia.me/posts/actualizar-herramientas-de-hp-con-vum/2016-01-17T09:13:00+01:002016-01-17T09:13:00+01:00Fran Garcia<p>Después de muchos años administrando ESXi sobre servidores HP, nos hemos
dado cuenta de un pequeño truco que permite actualizar de forma mucho
más fácil las herramientas para administrarlos y monitorizarlos
correctamente.</p>
<p>Basta con añadir la siguiente URL como origen de parches en la configuración
de VMware Update Manager (VUM) para que todas las actualizaciones de
paquetes se instalen al mismo tiempo que el resto de parches del hipervisor.
Del mismo modo, esto sirve para</p>
<p>La URL a añadir es:</p>
<p><a href="http://vibsdepot.hpe.com/index.xml">http://vibsdepot.hpe.com/index.xml</a></p>
<p>Es muy importante acordarse de que es index.XML ; si no, la descarga de
actualizaciones no funcionará.</p>
<p>Igualmente hay un documento bastante interesante que describe algunas
opciones más, incluyo una copia local (que ya sabemos cómo de fácil y
buena es la web de HP).</p>
<p>Happy hacking!</p>Diseñando soluciones con vCloud Directorhttps://www.frangarcia.me/posts/disenando-soluciones-con-vcloud-director/2012-08-05T22:34:00+02:002012-08-05T22:34:00+02:00Fran Garcia<p>vCloud Director es un producto de Vmware que permite ofrecer portal web
de cliente desde donde gestionar tus propias máquinas virtuales sin
tener que gestionar la infraestructura vCennter y ESX subyacente. Esto
permite a los Proveedores de Servicio (SPs) poder vender Infraestructura
como Servicio (IaaS) de forma sencilla.</p>
<p>Para aquellas personas acostumbradas a trabajar directamente con vSphere
y vCenter, vCloud Director 1.5 introduce algunas limitaciones que deben
ser consideradas a la hora de diseñar una aplicación a desplegar en la
nube:</p>
<p><strong>Tamaño de VM</strong>: Los discos de una VM solo pueden estar en un único
datastore, así que el máximo coincidirá con ese tamaño de DS.
Dependiendo del proveedor, esto puede significar un tamaño máximo de VM
de entre 1 y 3 Tb.</p>
<p><strong>RDM</strong>: Los discos RDM no están soportados en vCD. Así que no podemos
configurar clusters virtuales con almacenamiento compartido. Hay quien
recomienda utilizar un servidor iSCSI (ej: <a href="http://www.freenas.org/">FreeNAS</a>) dentro de la
solución y evitar el uso de RDMs, pero como veremos después, no hay
forma de garantizar el HA del storage.</p>
<p><strong>Redundancia</strong>: Si tenemos dos VM servidor web, en vSphere podemos
crear una regla de anti-afinidad para que corran en servidores ESX
distintos. En VCD no se puede hacer tal cosa, por lo que potencialmente
podemos tener todos nuestros servidores web ejecutándose en el mismo
servidor ESX. Con lo cual, significa que dejamos la "alta
disponibilidad" de las máquinas virtuales en manos del HA de vSphere. En
caso de fallo del ESX donde residen nuestras VMs, deberemos esperar a
que vCloud las reinicie en otro host ESX.</p>
<p>Seguramente algunas de estas limitaciones se resuelvan o mitiguen con la
próxima publicacion de VCD 2.0, que se realizará durante este mes de
agosto de 2012.</p>Limitaciones prácticas de Vmware VDRhttps://www.frangarcia.me/posts/limitaciones-practicas-de-vmware-vdr/2012-04-28T22:07:00+02:002012-04-28T22:07:00+02:00Fran Garcia<p><a href="http://www.vmware.com/products/data-recovery/overview.html">Vmware Data Recovery (VDR)</a> provee un mecanismo flexible para obtener
copias PIT (point in time) del estado de nuestras máquinas virtuales.
Nos podemos olvidar de instalación de agentes de backup tipo Netbackup,
Legato, etc en nuestras máquinas virtuales a la vez que obtenemos una
copia completa y consistente de nuestro sistema operativo y datos,
pudiendo volver a tener una VM funcional tras una catástrofe en minutos.</p>
<p>Sin embargo, esta flexibilidad muchas veces se convierte en un "todo
vale" y en una falta de diseño para obtener una estructura de backup
adecuada. Voy a exponer alguna de las limitaciones y/o buenas prácticas
que me he ido encontrado a la hora de desplegar este producto:</p>
<p><strong>No es aconsejable hacer backups de VMs de más de 250GB</strong>. Backups más
grandes de ese tamaño hacen difícil cuadrarlo en una ventana de backup
de 8h y no hay forma de tunear el VDR para que haga los backups más
rápidos (ni asignando más CPU/vRAM al appliance, ni de ninguna otra
forma).</p>
<p><strong>NO hacer backup de VMs muy transaccionales</strong>. Es decir, no hacer
Backup VDR de máquinas virtuales que tengan muchos cambios durante la
ventana de Backup (típicamente Bases de datos). Esto es debido a que los
snapshots necesarios pueden ocupar mucho espacio y hacer una estimación
de espacio necesario es muy complicado.</p>
<p><strong>Aprovisionar un 20%-30% de espacio adicional en datastore de origen
por máquina virtual que requiera VDR</strong>. Con relación al punto anterior,
y para evitar que un datastore se llene por snapshots durante ventana de
VDR, es necesario aprovisionar espacio adicional para que se realicen
los backups. Si lo del 30% os parece excesivo os contaré que una máquina
de GB con 1 Tera en discos ha llegado a tener 300gb en snapshots no
consolidados porque su Backup de VDR seguía en ejecución tras más de 48h
:-) .</p>
<p><strong>Almacenar los backups FUERA de la SAN</strong>. Esto suena a perogrullo, pero
en más de un caso me he encontrado que el appliance VDR reside en la
misma cabina que las luns a las que hace backup. Si falla la cabina, nos
quedamos sin VMs y sin backups, por lo que no tiene sentido almacenarlos
en el mismo sitio. Donde sea posible, es aconsejable almacenar los
backups en discos locales de los ESX o en una cabina distinta a las VMs
de origen. Por ejemplo, en máquinas HP Proliant se pueden comprar discos
SATA de 1 ó 2 Terabytes a precios bastante competitivos en relación a
los FC/SAS.</p>
<p><strong>No hacer que todos los backups finalicen a la msima hora</strong>. Si tenemos
muchos trabajos de backup y hacemos que todos finalicen a la misma hora
(ej: lunes a las 08:00), conseguiremos que a esa hora se produzca una
"<em>tormenta de consolidación de snapshots</em>". VDR cancela todos sus
trabajos e informa al vCenter que consolide todos los snapshots que ha
creado para poder hacer copias consistentes de las VMs, por lo que
conseguimos que a las 8:00 se produzcan operaciones I/O masivas hacia el
almacenamiento. Perfecto para que los usuarios estén felices y contentos
por la lentitud de sus VMs :-) .</p>
<p><strong>Dimensionamiento de espacio a asignar</strong>: Si queremos hacer backup de
VMs que ocupan 1 Terabyte neto, típicamente necesitaremos menos de ese
espacio asignado a nuestro VDR: ratios de 2/1 no parecen descabellados.
Sin embargo, hay que tener en cuenta el crecimiento de nuestras VMs y
cuánta retención queremos para ella. No es lo mismo querer guardar los
últimos 30 backups diarios, que guardar los últimos 4 semanales. Siempre
hay que tener en cuenta el no asignar más de 2 Terabytes de espacio por
appliance VDR, lo que según estos cálculos, nos permitiría proteger
hasta 3-4 Terabytes de VMs.</p>
<p><strong>Dimensionamiento de los datastores de VMs</strong>: Como comentaba antes, es
necesario dejar espacio libre en los datastores que vayan a albergar
máquinas protegidas por VDR, típicamente entre un 15-20%, dependiendo de
la transaccionalidad de las VMs. Para máquinas muy cambiantes, pueden
incluso requerir mucho más, por lo que requiere un análisis cuidadoso.
El hecho de quedarse sin espacio libre en un datastore mientras se
tienen máquinas virtuales encendidas es muy delicado, ya que puede
llegar a provocar corrupción de las VMs y/o pérdida de datos (rollback
de los snapshots).</p>Conversión P2V de RHEL en VMwarehttps://www.frangarcia.me/posts/conversion-p2v-de-rhel-en-vmware/2011-02-13T19:51:00+01:002011-02-13T19:51:00+01:00Fran Garcia<p>Cada día es más común realizar la migración de servidores físicos a
virtuales (P2V). Aunque existen herramientas específicas para ello, como
<a href="http://www.vmware.com/products/converter/">VMware Converter</a>, muchas veces es más sencillo usar una forma manual
que no tener que montar una nueva infrastructura de software para 1 ó 2
migraciones.</p>
<p>En este artículo vamos a ver cómo migrar una instalación de RHEL4 en
físico (servidor HP Proliant) a máquina virtual bajo vSphere 4.1. El
proceso descrito es similar a una <strong>Cold migration</strong>, es decir, una
mgiración con la máquina de origen apagada (y por tanto, con pérdida de
servicio).</p>
<p>Los pasos a realizar serán :</p>
<ul>
<li>Preparar la máquina física de origen con los drivers necesarios de
VMware (initrd)</li>
<li>Crear de una máquina virtual en VMware</li>
<li>Arrancar la máquina virtual con un LiveCD</li>
<li>Arrancar la máquina física con un LiveCD</li>
<li>Copiar por red cada uno de los discos de la máquina de origen a la
máquina virtual</li>
<li>Editar ficheros de configuración y ver que la VM arranca
correctamente</li>
<li>Instalación de VMware Tools</li>
</ul>
<p>Más en detalle:</p>
<p><strong>Preparación de la máquina de origen</strong></p>
<p>Esta será la única modificación que se realiza en la máquina de origen;
consiste en incluir los módulos necesarios para que la máquina pueda
arrancar con su futuro hardware virtual. Para ello es necesario editar
el fichero /etc/modprobe.conf de la siguiente manera:</p>
<div class="code"><pre class="code literal-block"><span class="c1">#alias eth0 tg3 </span>
<span class="c1">#alias eth1 tg3 </span>
<span class="nb">alias</span><span class="w"> </span>scsi_hostadapter<span class="w"> </span>cciss<span class="w"> </span>
<span class="nb">alias</span><span class="w"> </span>scsi_hostadapter1<span class="w"> </span>mptspi<span class="w"> </span>
<span class="nb">alias</span><span class="w"> </span>scsi_hostadapter2<span class="w"> </span>mptscsih<span class="w"> </span>
<span class="nb">alias</span><span class="w"> </span>scsi_hostadapter3<span class="w"> </span>ata_piix
</pre></div>
<p>Se han comentado las líneas 1 y 2 para evitar introducir los módulos de
las tarjetas de red en el initrd, así como añadido las lineas 4 y 5 que
son los módulos de la controladora SCSI virtual de VMware. Una vez
realizado esto se procede a construir un initrd nuevo y a añadirlo en la
configuración de GRUB :</p>
<div class="code"><pre class="code literal-block">root@server<span class="w"> </span>/boot<span class="w"> </span><span class="c1"># uname -a </span>
Linux<span class="w"> </span>server<span class="w"> </span><span class="m">2</span>.6.18-92.1.6.el5<span class="w"> </span><span class="c1">#1 SMP Fri Jun 20 02:36:16 EDT 2008 i686 i686 i386 GNU/Linux </span>
root@server<span class="w"> </span>/boot<span class="w"> </span>$<span class="w"> </span>mkinitrd<span class="w"> </span>initrd-2.6.18-92.1.6.el5-vmware.img<span class="w"> </span><span class="m">2</span>.6.18-92.1.6.el5<span class="w"> </span>
root@server<span class="w"> </span>/boot<span class="w"> </span>$<span class="w"> </span>cat<span class="w"> </span>/etc/grub.conf<span class="w"> </span>
<span class="o">[</span>...<span class="o">]</span><span class="w"> </span>
<span class="c1"># entrada con nuevo initrd </span>
title<span class="w"> </span>Red<span class="w"> </span>Hat<span class="w"> </span>Enterprise<span class="w"> </span>Linux<span class="w"> </span>Server<span class="w"> </span><span class="o">(</span>vmware<span class="o">)</span><span class="w"> </span>
root<span class="w"> </span><span class="o">(</span>hd0,0<span class="o">)</span><span class="w"> </span>
kernel<span class="w"> </span>/vmlinuz-2.6.18-92.1.6.el5<span class="w"> </span>ro<span class="w"> </span><span class="nv">root</span><span class="o">=</span>/dev/vg00/lvol00<span class="w"> </span>rhgb<span class="w"> </span>quiet<span class="w"> </span>
initrd<span class="w"> </span>/initrd-2.6.18-92.1.6.el5-vmware.img<span class="w"> </span>
<span class="c1">#entrada con initrd original </span>
title<span class="w"> </span>Red<span class="w"> </span>Hat<span class="w"> </span>Enterprise<span class="w"> </span>Linux<span class="w"> </span>Server<span class="w"> </span><span class="o">(</span><span class="m">2</span>.6.18-92.1.6.el5<span class="o">)</span><span class="w"> </span>
root<span class="w"> </span><span class="o">(</span>hd0,0<span class="o">)</span><span class="w"> </span>
kernel<span class="w"> </span>/vmlinuz-2.6.18-92.1.6.el5<span class="w"> </span>ro<span class="w"> </span><span class="nv">root</span><span class="o">=</span>/dev/vg00/lvol00<span class="w"> </span>rhgb<span class="w"> </span>quiet<span class="w"> </span>
initrd<span class="w"> </span>/initrd-2.6.18-92.1.6.el5.img
</pre></div>
<p><strong>Creación de la máquina virtual</strong></p>
<p>La única consideración a tener en cuenta es crear los discos de, al
menos, el mismo tamaño que los discos de la máquina física de origen.</p>
<p><strong>Arranque de las máquinas con un LiveCD</strong></p>
<p>En principio, nos vale cualquier LiveCD que tengamos a mano, pero
recomiendo <a href="http://www.sysresccd.org">SysRescCD</a> debido a su pequeño tamaño (~250MB), soporte
simultáneo de 32 y 64 bits y gran cantidad de utilidades embebidas. Una
vez arrancadas ambas máquinas, deberemos asignarles a cada una de ellas
una IP temporal y verificar que se vean entre sí (por ejemplo, a través
de ping).</p>
<p><strong>Transferencia de datos</strong></p>
<p>Usaremos <a href="http://www.ivarch.com/programs/pv.shtml">pv</a> para leer los contenidos del disco y netcat para
transferirlos por red. PV es una herramienta muy cuca que te aporta
información en tiempo real de tamaño leído, velocidad de transferencia
actual, tiempo restante (si se conoce el tamaño total del stream);
aunque podríamos usar perfectamente cosas más simples como cat ó dd.</p>
<p><em>En la máquina virtual de destino</em>: Dejamos escuchando un netcat en un
puerto TCP arbitrario que queramos, y redirigimos su salida hacia el
disco de destino. Ejemplo:</p>
<div class="code"><pre class="code literal-block">nc -l -p 5000 > /dev/sda
</pre></div>
<p><em>En el servidor físico de origen</em>: Iniciamos la lectura y la enviamos
con netcat hacia la IP y puerto de destino, ejemplo:</p>
<div class="code"><pre class="code literal-block">pv /dev/cciss/c0d0 | nc ipdestino 5000
</pre></div>
<p>Algunas notas sobre este proceso: Si tenemos varios discos de origen,
podemos paralelizar el proceso cambiándo de TTY y lanzando
simultáneamente varios netcats (cambiando los puertos TCP de destino).
En pruebas realizadas, hemos visto velocidades combinadas de hasta 70
MB/s (250 GB/hora) para conexiones Gigabit, aunque depende lógicamente
de la red y el hardware origen y destino.</p>
<p>Una vez realizado esto, podremos apagar la máquina física de origen y
proceder a verificar el estado de la copia. Deberemos recargar la tabla
de particiones en la máquina virtual para que se aplique lo escrito a
disco y, si usamos LVM, activar los Volume Groups correspondientes.</p>
<div class="code"><pre class="code literal-block"># cat /proc/partitions
major minor #blocks name
8 0 244198584 sda
# partprobe
# cat /proc/partitions
major minor #blocks name
8 0 244198584 sda
8 1 1024000 sda1
8 2 243172001 sda2
# vgchange -ay
# cat /proc/partitions
major minor #blocks name
8 0 244198584 sda
8 1 1024000 sda1
8 2 243172001 sda2
253 0 16777216 dm-0
253 1 7864320 dm-1
253 2 10485760 dm-2
253 3 2097152 dm-3
253 4 4194304 dm-4
253 5 80740352 dm-5
253 6 52428800 dm-6
253 7 27262976 dm-7
253 8 13631488 dm-8
</pre></div>
<p>Además, deberemos revisar la configuración de /etc/fstab para verificar
que no haya referencias a dispositivos incorrectos (en Proliant el
primer disco del sistema es /dev/cciss/c0d0 mientras que en VMware es
/dev/sda). Para ello, deberemos montar el filesystem raid en un
directorio temporal (por ejemplo mkdir /test ; mount /dev/sda1 /test) y
editar los ficheros necesarios. Además, en RHEL deberemos editar los
ficheros /test/etc/sysconfig/network-script/ifcfg-eth* para verificar
que no tengan asociada ninguna MAC Address concreta, o bien reemplazar
las existentes por las de la nueva VM).</p>
<p>Finalmente, reiniciaremos la máquina virtual y comprobaremos si todo
levanta correctamente. Si es así, procederemos a quitar todas las
herramientas que dependan de un hardware concreto (por ejemplo Proliant
Support Pack en HP, OpenManage en Dell, etc) e instalar las VMware
Tools.</p>