Virtual Machine power on stalls(In Progress) and cannot be cancelled

Muy buenas a todos, después de unas más que merecidas vacaciones y la vuelta a trabajar un tanto intensa que he tenido, por fin tengo un huequillo para escribir.

Una de las que me he encontrado al volver ha sido:
- Voy a encender estas VMs....
- Vaya parece que llevan un rato en el estado "In Progress"...
- Vaya parece que algo pasa poruqe se han quedado asi desde hace cinco minutos.

Pues sí, resulta que al encender dichas VMs en un entorno con un VC y unos cuantos ESX, las VMs se quedaban de forma indefinida como si se estuvieran encendiendo (El Virtual Center marca Power On Virtual Machine, Status= In Progress), pero nada de eso claro.

Lo primero ha sido intentar cancelar las tareas desde el VIC, pero nada, no me dejaba dicha opcion.
Lo siguente que he pensado ha sido ir a los hosts donde se ejecutaban dichas VMs y apagarlas por comando:
Veo el estado en que se encuentra (me dice que encendida no está):
vmware-cmd maquinavirtual.vmx getstate
(con vmware-cmd -l puedo ver el path de todas las VMs)

Intento pararla de "botonazo"(me dice que nanai):
vmware-cmd maquinavirtual.vmx stop hard

Intento ver el heartbeat(me retroenlazo) (pero nada, proque la VM esta apagada):
vmware-cmd maquinavirtual.vmx getheartbeat

Intento ver el proceso que representa la VM en la console y matarlo:
ps axfwww | grep maquinavirtual.vmx, pillaria el PID y kill -9 PID, pero nada porque la VM no está corriendo (como ya me habia contestado el ESX...).

Bien, parece claro que el ESX no se ha enterado de que dicha VM esté siendo iniciada, por lo que parece que el VC no se lo ha dicho....

Voy al servidor del Virtual Center, reinicio el servicio Virtual Center con el Administrador de Servicios, vuelvo a entrar con el VIC, y vaya parece que la terea ha desaparecido y que las VMs estan apagadas.
Enciendo las VMs y esta vez sí, pasan del "In Progress" a la barrita de progreso de encendido y todo Ok.

Una vez resuelto, miro por los googles a ver si a alguien le ha ocurrido algo similar y aqui esta. Parece ser que ha sido debido a que el servicio Virtual Center Server no estaba del todo bien justo cuando le he dado a encender las VMs. Toca mirar los log y a ver si encuentro alguna explicacion para que se caiga el servicio del Virtual Center...

Monitorización de VMs con VMware HA

Como la mayoria de vosotros sabreis, VMware High Availability (VMware HA) monitoriza la Infraestructura Virtual para ver si hay caidas de Servidores ESX y reinicia las VMs que son interrumpidas por dichas caidas de los servidores ESX en otros ESX con mejor salud.

Desde la ESX 3.5, Vmware HA puede detectar y manejar los fallos a nivel de VM y responder de forma apropiada de acuerdo a nuestras especificaciones. Con esta funcionalidad nueva(todavía en beta), llamada "VM Failure Monitoring", VMware Ha es/será capaz de tratar tanto caidas de servidor ESX como caidas de VMs individuales(usando las VMware tools, claro).
Aquí podeis encontrar un papel tecnico que es poco conocido pero muy interesante de leer.

Si a esto le añadimos el hecho de que VMware compró B-Hive, podemos ver por donde pueden ir los tiros en lo que se refiere a Alta Disponibilidad y Nivel de Servicio en la Infrastructura Virtual.

/* Me marcho de vacaciones, ya os contaré qué tal ha ido la pequeña aventura que estamos montando. ;-)
*/

Extensiones de ficheros de VMware

Dentro de cada directorio donde VMware alberga una VM se crean unos cuantos ficheros que seguro que hemos visto más de una vez. Estos ficheros sirven para controlar la ejecución de la VM. Sabiendo qué hace cada fichero nos haremos una mejor idea de cómo funciona nuestro ESX.

.VMDK
Son los discos duros de la VM propiamente. Suelen ser los ficheros más grandes del directorio. Su tamaño es mas o menos el tamaño del disco(si usamos discos preallocated) o el tamaño de los datos almacenados en este momento (si usamos discos growables)

.NVRAM
Este fichero contiene la BIOS de la VM.

.VMX
Lo normal es que haya un fichero VMX por cada directorio. Contiene la información de configuracion de la VM en formato texto.(La expresión de Edit Settings en forma de texto). Es editable por un programa de edicion de texto (vi, pico...)

.VMXF
Este fichero, editable también, que está en formato XML, incluye información adicional de la VM si ésta ha estado o está en un team.

.VMTM
Para la VMs que estén formando parte activa de un team

.VMEM
Estos fichero contienen un backup de los ficheros de paginación de la VM. Son muy pequeños o no existirán si la VM está apagada, pero crecerán hasta el tamaño de la RAM configurada si se enciende la VM.

.VMSN y .VMSD
Cuendo creamos snapshot de la VM, estos ficheros se crean para mantener el estado de la VM.
EL fichero con extensión VMSN guarda el estado de ejecución de la VM, es decir, el delta entre el VMDK en el momento del snapshot y lo que ha sido procesado hasta ahora.

El fichero VMSD guarda la informacion de metadata sobre el propio snapshot.

.VMSS
Contiene el estado de suspendido de la VM si es que la hemos suspendido.

ESX Server 3i Hosts Without Swap Enabled Cannot be Added to an HA Cluster

Recientemente VMware ha publicado una nota KB en la que se informa que los hosts con la 3i que no tengan habilitado la swap no pueden ser añadidos a un cluster VMware HA
Según el documento esto ocurre desde el VirtualCenter 2.5 Update 1, y los host que lleven la 3i y no tengan habilitada la swap mostrarán un mensaje asi, al intentar ser añadidos al cluster: "An error occurred during configuration of the HA agent of the host." (muy explicito...).
En la pestaña de Tareas y Eventos podemos ver una descripcion asi: "HA agent has an error : Host in HA Cluster must have userworld swap enabled".(esta ya es más explicita)

Para solventarlo y habilitar la swap podemos realizar los siguentes pasos:

1. Ir a la pestaña Configuration, y a Advanced Settings.
2. Elegir ScratchConfig.
3. Establecer el parametro ScratchConfig.ConfiguredScratchLocation con un directorio valido con al menos 1GB.
4. Seleccionar ScratchConfig.ConfiguredScratchLocation y darle a OK.
5. Reboot del host ESX Server 3i.

Cómo crear un Virtual Switch(vswitch) con un numero especifico de puertos

Un pequeño Tip, ahora que estoy volviendo a meterme en harina:
Con el comando esxcfg-vswitch podemos crear un vswitch y a la vez especificar el numero de puertos que queremos que tenga poniendo un ":" despues del nombre del switch.

Ejemplo:
#esxcfg-vswitch -a vSwitchTest:20

Otras acciones que podemos realizar con este comando son:
esxcfg-vswitch [options] [vswitch[:ports]]
-a|--add Add a new virtual switch.
-d|--delete Delete the virtual switch.
-l|--list List all the virtual switches.
-L|--link=pnic Set pnic as an uplink for the vswitch.
-U|--unlink=pnic Remove pnic from the uplinks for the vswitch.
-p|--pg=portgroup Specify a portgroup for operation
Use ALL for operation to work on all portgroups
-v|--vlan=id Set vlan id for portgroup specified by -p
0 would disable the vlan
-c|--check Check to see if a virtual switch exists.
Program outputs a 1 if it exists, 0 otherwise.
-A|--add-pg=name Add a new portgroup to the virtual switch.
-D|--del-pg=name Delete the portgroup from the virtual switch.
-C|--check-pg=name Check to see if a portgroup exists. Program
outputs a 1 if it exists, 0 otherwise.
-r|--restore Restore all virtual switches from the configuration file
(FOR INTERNAL USE ONLY).
-h|--help Show this message.

Vmware HA: Recopilación de Comandos, Logs y Archivos de configuración

Aquí os dejo una recopilación de comandos, logs y archivos de configuración relativos a VMware HA, ls cuales nos pueden servir para realizar troubleshooting cuando las cosas van mal.
Recomiendo primero leerse el post : Como funciona VMware HA?

AAM responde a Automated Availability Manager ("Administrador de Disponibilidad Automatica") y es el demonio que corre en la COS cuando creamos un cluster de VMware HA. Este software es una pieza del de Legato que ha sido renombrado a EMC AutoStart. El demonio mantiene en memoria una pequeña base de datos en los nodos activos del cluster y usa los heartbeats para coordinar los nodos activos y pasivos. Entre otras cosas, por esto se recomienda configurar la COS con 2 interfaces ethernet para no tener un unico punto de fallo.

Resolución de nombres:
La mayor dependencia de este componente es la resolucion de nombres, por ello es importante tener bien configurado estos archivos antes de "enable" VMware HA:

/etc/hosts
/etc/FT_HOSTS
/etc/resolv.conf
/etc/vmware/esx.conf

También antes de habilitar VMware HA se debe comprobar en todos los nodos que el comando #hostname -s nos devuelve el nombre corto de la Service Console, porque si no VMware HA fallará.

Log:
Los archivos de log (como ya comentamos) están en:

• ESX 3.0.x: /opt/LGTOaam512/
• ESX 3.5: /opt/VMware/

De especial antención a la hora de tener problemas es :
#cat /opt/LGTOaam512/log/aam_config_util_addnode.log

Red:
Para evitar situciones de "split brain" en el cluster los ESX pueden determinar cuando han sido aislados y podemos configurar su comportamiento. Cuando el agente de AAM pierde contacto con los demás nodos, lo intenta con el default gateway de la console realizando ICMP echo request (PING).

Si falla, pensará que está aislado y actuará en consecuencia. Por ello, es muy útil configurar varias isolationaddress (Advanced Conf: das.isolationaddress), puesto que si solo tenemos el heartbeat entre los nodos y el ping al gateway, imaginaros lo que ocurriría si cayese durante unos 15 segundo el switch/router al que están conectados nuestros ESX: Cada uno de ellos no veria a los demás y no llegaría con pings al gateway, con lo cual todos pensarian que estan aislados y actuarian en consecuencia(por ejemplo apagandose...).
Resultado: Por unos 15 segundos que nuestro switch/router ha dejado sin link a los ESX, TODAS las VMs han sido apagadas... Un buen marron, para un pequeño corte de red...

Por eso es bueno configurar otra/s das.isolationaddress por la que se puedan "ver" los ESX aunque no lleguen al gateway. (Creo que esto solo es posible en la 3.5)


Comandos y Archivos:
Siguendo con los comandos relacionados con VMware HA tenemos:

/opt/LGTOaam512/bin/ftcli
Esta utilidad nos permite ver los nodos activos en el cluster de HA y nos puede servir para determinar si el agente de HA está corriendo y que IPs están siendo visibles para el host.

Para usarlo primero debemos hacer FT_DIR=/opt/LGTOaam512 y luego export FT_DIR

• Lista el manager del cluster: /opt/LGTOaam512/bin/ftcli -domain vmware -timeout 60 -cmd "listrules"
• Lista los nodos del cluster: /opt/LGTOaam512/bin/ftcli -domain vmware -connect %node% -port 8042 -timeout 60 -cmd "listnodes"(Sustituyendo %node%, claro)
  

/etc/FT_HOSTS
Este fichero se crea cuando Vmware HA se habilita y es una copia de /etc/hosts.
Si se tiene problemas con la resolucion de nombres y configurando HA (por ejemplo al cambiar de IP o de nombre a un ESX), podemos borrar este fichero y reconfigurar el nodo para VMware HA, el fichero FT_HOSTS sera recreado.

Backup de VMware(Image Level, File Level) en Datastores NFS

Se está poniendo de moda usar NFS para albergar nuestras VMs con VMware. La principal desventaja que suelen esgrimir sus detractores es que no puedes usar Virtual Consolidated Backup (VCB).

Aqui tenemos un metodo para poder hacer Backup tanto de los VMDKS(image level) como de los ficheros que estén en los discos duros de nuestros servidores virtuales (ficheros dentro de los vmdk para entendernos) (llamado file level). Con este metodo tambien se puede hacer Restore, incluso provisionning:

El metodo consiste en utilizar un servidor de backup Linux con la distribucion a la que más acostumbrados estemos y montar el volumen NFS o un snapshot del mismo (via cabina, de NetApp, IBM o EMC).

Una vez que nuestro servidor de backup Linux tiene acceso al volumen NFS o a un snapshot del mismo, tendremos que instalar en el Linux, si queremos realizar backup o restore de VMs windows, el soporte de NTFS (si es que no viene instalado, que la mayoria de veces viene).

Lo siguiente es montar el export de NFS en el servidor:
# mount direccion_IP_de_la Cabina:/vol/nfs_de_pruebas /mnt/vm_nfs

Ahora mismo ya podriamos hacer backup de los ficheros VMDK (Image Level Backup) . En NetApp se puede encontrar los snapshots en el directorio .snapshot.

El siguiente paso es realizar backup de los ficheros que queramos que estan dentro de los VMDKs(File Level Backup). Para ello montamos el VMDK en el que estén los archivos que nos interesen.

En el caso de que queramos montar un VMDK de una VM Windows, (es decir el VMDK está formateado en NTFS):
Para montar el VMDK en el servidor de backup linux especificaremos el fichero VMDK (el fichero -flat), y en las opciones especificaremos el tipo de file system(NTFS), que el acceso es de sólo lectura(dado que es un VMDK de NTFS), el offset del disco y el dispositivo loop.

Ejemplo:
# mount /mnt/vm_nfs/.snapshot/hourly.1/maquina_virtual/maquina_virtual_windows-flat.vmdk /mnt/disco_vmdk_con_NTFS -o ro,loop=/dev/loop2,offset=32256 -t ntfs

De esta forma desde el servidor Linux podremos ver el contenido del VMDK y realizar backup de los ficheros que nos interesen. Podemos ver su contenido:
# ls -l /mnt/disco_vmdk_con_NTFS

¿Cómo sabemos el offset?
Pues bien , en nuestra maquina virtual Windows (de la cual queremos hacer algunos file level backups), ejecutaremos msinfo32.exe, luego vamos a Components, a Storage y a Disks.
Anotamos el Partition Starting Offset(Desplazamiento Incial de Particion) y lo ponemos en el comando mount antes descrito.
Se necesita especificar cada offset de cada particion para montarlas. Por ejemplo si tensmos un VMDK formateado en NTFS que tiene dentro la unidad C: y D: . Anotaremos los offsets de ambas particiones y usaremos dos comandos mount para montarlas.


En el caso de que queramos montar un VMDK de una VM Linux, (es decir el VMDK está formateado en ext3 o ext2):
Para montar el VMDK en el servidor de backup linux especificaremos el fichero VMDK (el fichero -flat), y en las opciones especificaremos el tipo de file system(ext3), que el acceso es de lectura/escritura(dado que es un VMDK de ext3), el offset del disco y el dispositivo loop.

Es muy importante saber que para montar un VMDK que tenga ext3 o ext2 debajo es NECESARIO que el volumen en el que está sea de acceso r/w. Por ejemplo con un snapshot de NetApp, no nos valdría, tendría que ser un FlexClone.

Ejemplo:
# mount /mnt/vm_nfs/.snapshot/hourly.1/maquina_virtual/maquina_virtual_linux-flat.vmdk /mnt/disco_vmdk_con_EXT3 -o loop,offset=32256 -t ext3

De esta forma desde el servidor Linux podremos ver el contenido del VMDK y realizar backup de los ficheros que nos interesen. Podemos ver su contenido:
# ls -l /mnt/disco_vmdk_con_EXT3


¿Cómo sabemos el offset?
Podemos usar fdisk -lu en nuestra maquina virtual Linux (de la cual queremos hacer algunos file level backups) para tener el starting sector de cada partition.
Multiplicando este valor por 512 bytes tendremos el valor del offset en bytes que lo colocaremos en la opcion del mount.

En el comando mount especificamos que el FS es ext3. Podemos ver el tipo de FS que es con #df -T


En el caso de una VM linux, existe un caso más: Que se use LVM:
Para montar las particiones no valdrá el metodo anterior. Deberemos usar un FlexClone(un snapshot de lectura/escritura) como en el caso de ext2 ó 3 y usar los comandos:
#mount direccion_IP_de_la Cabina:/vol/vmnfsXXXbk /mnt/vm_nfs
#losetup /dev/loop0 /mnt/vm_nfs/SERVIDORWEB/SERVIDORWEB-flat.vmdk
#kpartx -av /dev/loop0
#vgscan
Reading all physical volumes. This may take a while...
Found volume group "VolGroup00" using metadata type lvm2
#vgchange -ay VolGroup00
2 logical volume(s) in volume group "VolGroup00" now active
#lvs
LogVol00 VolGroup00 -wi-a- 10.0G
LogVol01 VolGroup00 -wi-a- 10.0G
#mount /dev/VolGroup00/LogVol00 /mnt/disco_vmdk_con_LVM


Espero que os resulte útil!