Excelente post de esxtop en las communities de VMware

Para los que se han encontrado alguna vez que deben realizar un troubleshooting en un entorno de VI de VMware a bajo nivel os recomiendo la lectura de este tecnicamente excelente post en las communities de vmware sobre la herramienta esxtop:
http://communities.vmware.com/docs/DOC-9279

Instalando y Configurando Linux Guests con VMware

El equipo de Linux de VMware acaba de sacar un documento (whitepaper) que incluye todo tipo de trucos (tips) y bests practices para la instalacon y configuracion de VM que lleven Linux.
Merece la pena leerlo y releerlo si funcionamos con Linux en nuestra infrastructura virtual.
http://www.vmware.com/resources/techresources/1076

Description
This technical note describes installing, configuring, updating, and administering Linux guest operating systems in virtual machines running on VMware Infrastructure 3 version 3.5. In addition, this note includes a collection of useful tips and tricks in fine-tuning your Linux virtual machines. Although the recommendations in this paper apply to most Linux distributions, they are tailored specifically to Red Hat Enterprise Linux 5. Linux administrators can use this paper as a source for guidelines when building and maintaining Linux virtual machines in their VMware Infrastructure environments. Some working knowledge of VirtualCenter 2.5 Update 2, ESX 3.5 Update 2, and Linux operating systems is required.

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.

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.

Soporte de SVMotion y 10Gb Ethernet para SANs iSCSI en VMware

La semana del 24 de Junio VMware reportó que con la versión 3.5 Update 1 Storage VMotion es soportado oficialmente para las SANs iSCSI. Esto nos permite reorganizar las VMs sin down time para adecuarlas a nuestras necesidades de almacenamiento.

SVMotion nos permite:

• Mover VM a un nuevo array para hacer operaciones sobre dicho array.
• Mover los discos de las VMs a una capa de almacenamiento diferente para adecuarls a las necesidades
• Resolver problemas de rendimiento causado por la configuracion del almacenamiento o demasiada carga en una LUN en concreto.

Según explican, se pueden mover VMs:

• De iSCSI SANs a otras iSCSI SANs
• De iSCSI SANs a FibreChannel SANs
• De FibreChannel SANs a iSCSI SANs

Además ha aprovechado para soportar el uso de 10Gb Ethernet para iSCSI en un entorno de VMware Infrastructure.

La compra de B-hive por parte de Vmware

Recientemente (finales de Mayo) VMware ha comenzado el proceso de compra de la compañia B-Hive. Como reza el comunicado de prensa : "B-Hive proporciona una visión de infraestructura en el rendimiento de aplicaciones (albergadas por entornos virtuales) tales como el tiempo de respuesta del usuario en las transacciones, utilizaciones de VMs y dependencia cruzadas de VMs".

De lo que se trata es de proveer una mayor cantidad de datos a herramientas como DRS y soluciones de management de forma que se pueda resolver problemas de rendimiento de las aplicaciones de forma proactiva realizando acciones como reservar dinamicamente más recursos, migrar las aplicaciones a otro servidor, aprovisionar otras VMs, cambiar el rutado de las transacciones o incluso reinicar el sistema.

La idea basica detrás de un APM (Application Performance Manager) es medir la experiencia del usuario o el rendimiento de las aplicaciones (cómo de rapido esta la apliacion procesando transacciones o unidades de trabajo desde que llegan de los usuarios u otras aplicaciones)

B-hive mide el tiempo de respuesta desde la perspectiva del la capa de presentación(el web server por ejemplo). Las soluciones de APM más antiguas infieren el rendimiento de las aplicaciones mirando los recursos que usan lo cual no es buena aproximación para un entorno virtual.

Funcionamiento General:
B-hive escucha en un puerto mirror (spanned) en el switch que está más cercano a los usuarios, lo que le permite ver las transacciones. En un entorno virtual, B-hive es implementado (de momento) como una virtual appliance que se une al mirror port del virtual switch dentro del ESX.

Mide el tiempo de respuesta entre las peticiones y la respuesta de la apliacaion a determinadas transacciones atomicas (o casi). Dichas operaciones no son algo palpable(xej una pagina web) desde el punto de vista del usuario sino que son opreaciones más pequeñas que dan una idea al personal de IT de cómo va la aplicacion. (El nivel de las transacciones atomicas depende de la aplicacion. Para web son HTTP tiempo peticion/respuesta. Para las que no son web las transacciones son a nivel TCP/IP tiempo peticion/respuesta o a Base de Datos tiempo peticion/respuesta.)


Lo bueno del producto es que es sin agente e independiente del OS de la VM y da el primer paso para proporcionar mejores datos para implementar el modelo de Data center de nube dinamica que es lo que persigue VMware(yo creo que es un buen movimiento de VMware).

Con este producto VMware conseguirá varias cosas (en mi opinion): será capaz de darnos una idea muy concreta de cómo van nuestras aplicaciones virtualizadas, consiguiendo por un lado que podamos dar unos determinados SLAs y por otro que nos atrevamos a realizar virtualizacion de aplicaciones más criticas. Además, ha pegado un mazazo a Citrix Y Microsoft que ahora se tendran que poner las pilas y por ultimo ha provocado una carrera en el mercado de los APM para posicionarse en el mercado de la virtualización.


Aqui os dejo un grafico que ve de foma general el mercado de los APMs. Algunos de los mejor emplazados son Akorri, vmSight y B-Hive.



Se supone que habra movimientos en breve por parte de Microsoft, Citrix, y algunos APMs.

Virtualización, Return Of Investment(ROI) y SAN

El hecho de que la Virtualización es una tecnología que tiene un ROI (Retorno de Inversión) alto es algo que generalmente no es muy dificil de hacer ver a los gerentes y directores. En cuanto se ven los ahorros en espacio, consumo, administracion etc, genralmente no es muy dificil tenerlos a favor. ("La virtualizacion es un virus, si inoculas una pequeña porción en una empresa, se expandirá hasta llenarlo todo").

Algo más dificultad nos plantea convencer a quienes tienen "los dineros" de que una SAN es algo por lo que merece la pena pagar, que es algo que nos va a dar a la larga una flexibilidad muy importante y que nos ahorrará disgustos y aumentará nuestro rendimiento.

Brad Krick, (manager of technical support configurations en GreenPages), nos provee de ciertos datos muy interesantes que nos permiten comparar las diferentes soluciones que tenemos a la hora de, por ejemplo, reemplazar 10 servidores viejos por nuevos.
Krick asume que "una compañía debe reemplazar 10 servidores viejos y su almacenamiento asociado". El estudio lo lleva a cabo usando unos servidores de ejemplo que son de HP y usando VMware ESX. (No tiene en cuenta el paso a cinta de la informacion , licencias de instalacion o instalacion).
En cuanto a los requeriemientos de almacenamiento supone unos 500 GB de datos de primera linea y otros 500GB de segunda linea(backup en disco).

Estos son los escenarios y su coste:
1.- Reemplazar los 10 servidores fisicos por otros 10 HP ML350, con discos de arranque en mirror(RAID1) y almacenemiento en RAID5.
Coste : 62.100$

2.- Consolidar con VMware los 10 servidores fisicos en 3 servidores con almacenamiento local: Tres HP ML350 (con mas memoria que los anteriores y almacenemiento en local RAID5) con VMware ESX (licencias incluidas).
Coste: 49,300$

3.- Los mismos servidores de Virtualizacion en un Cluster que usa una SAN de 1 TB: Tres HP ML350, con mas memoria que los primeros, discos de arranque, VMware ESX Enterprise y una SAN Hitachi de 1TB.
Coste: 52.730$

A la vista del experimenteo que ha llevado a cabo Krick, vemos que, nos ahorraríamos 12.000$, si usamos la virtualizacion y que, además por unos 3.400$ más que la opcion más barata(la 2), tendremos una SAN.

Es verdad que incrementa costes respecto a la opcion 2, pero (por unos 3.400$) nos deja opciones como redundancia, snapshots, thin provisioning y mejor rendimiento, además de que nos permita operaciones tan utiles como Vmotion, DRS, HA, etc, etc...

Realmente, si hacemos un ejercicio similar(ojo, comparando cosas similares), veremos que es algo que realmente merece la pena.

Slow performance of VMs that use vSMP on ESX using certain hardware

Como reza el título del post VMware ha publicado el dia 11 de Junio un articulo en la Knowledge Base que detalla un problema de rendimiento en VMs que se ejecutan en servidores ESX (3.0.x y 3.5) y que utilizan más de una vSMP y todo ello bajo determinados tipos de hardware (que no concretan por cierto). Todo el articulo es un poco difuminado (Puede ser leído aqui: http://kb.vmware.com/kb/1004901) y nos viene a decir que se puede apreciar un rendimiento pobre (no lo contabilizan) cuando usamos VMs con mas de una vSMP, además este rendimiento pobre también se puede manifestar en el Reinicio de la VM: "Síntoma: Reinicar una VM que tiene mas de un vSMP lleva significativamente más tiempo que si solo tuviera una vSMP, bajo ESX y bajo determinados HW...".

Como veis la explicacion no es muy detallada y para mi bastante confusa. En la explicacion nos comentan que parece que está relacionado con el COW (Copy-On-Write) de las VMs que tiene mas de una vSMP y nos proponen Apagar la maquina y Encenderla en lugar de Reinicarla pues esto hace que la memoria de COW se vacie y se llene.

Nos comentan también que para resolver el problema definitivamente se puede desactivar el Page Sharing (Transparen Page Sharing, TPS) de nuestro servidor ESX(Confguration-Advanced Settings- Set Mem-Mem.ShareScanGHz = 0, Reinica ESX).
El TPS nos proporciona la posibilidad de que se compartan paginas de memoria entre VMs resultando en grandes beneficios sobretodo si solemos tener sistemas operativos iguales en nuestro ESX. El resultado es muy visible cuando se inica una VM o varias a la vez. Por defecto VMware lo activa en nuestros servidores y parece que es el camino que van a seguir en el futuro.
Nos avisan que desactivarlo en todo el servidor puede producir mayor swapping si se hace Overcommitting de la memoria del ESX.
(Un post cojonudo sobre Gestion y Sobresuscripcion de Memoria de J.L. Medina).

Como ya he comentado antes la descripcion del problema es bastante disfusa y confusa (en mi opinión). Si por ejemplo, creo que estoy experimentando problemas de rendimiento en mi entorno de ESX(VI3) ¿Como sé yo si es este tipo de issue o no? Digo, antes de volverme loco intentando ver donde está el problema o cuello de botella, que, por cierto, no es de las cosas más faciles de pillar en VI3. (Espero escribir un post sobre ello...). Supongo que no será facil pero, creo que deberían describir mejor en que condiciones se produce, cuanto merma el rendimiento (%), etc, etc, para ver si nuestros sintomas coinciden con el KB.

Por otra parte el tema de desactivar el TPS para que la cosa vaya mejor me ha recordado a la directiva sched.mem.pshare.enable que es capaz de desctivar el TPS a nivel de VM y no a nivel de ESX como nos recomiendan en el KB. Es muy posible que esto también funcione, en lugar de tener que reinicar todo el ESX despues de cambiar la opcion en Advanced Settings como comentaba más arriba.

Este es uno de los parametros que mi colega Josep Ros comenta en su gran blog como polvos magicos para VMware.

En concreto los parametros que se comentan para aumentar el rendimiento de una VM (en lo que a gestion de memoria se refiere) son:

mainMem.useNamedFile = "FALSE"
Cuando está puesta a TRUE, se crea un fichero de tamaño de la RAM en el propio directorio con un nombre aleatorio.
Cuand se pone a FALSE, en Windows causa que la memoria la lleve el espacio de swap del host y en Linux causa que se cree un fichero en un directorio temporal (el fichero es borrado cuando se apaga la VM).
Se suele poner a FALSE cuando ejecutamos una VM desde un USB o un disco que tenga escrituras lentas.

MemAllowAutoScaleDown = "FALSE"
Permite ajustar automaticamente el tamaño de la memoria. Si esta puesto a TRUE, cuando encendemos una VM automaticamente se ajustará el tamaño de la memoria si el tamaño especificado no está disponible (en caso de sobresuscripcion)

MemTrimRate = "0"
El ESX chequea regularmente memoria virtual no usada y la recupera para sí(para correr mśa VMs o lo que sea). Cuando la VM que ha sido robada pide más memoria, el ESX se la da, epro esto tiene un precio en rendimiento. Si lo ponemos a "0" evitamos que nos coja memoria de dicha VM.

sched.mem.pshare.enable = "FALSE"
Como hemos comentado antes, VMware usa TPS para permitir almacenar como una sola pagina Copy-On-Write las paginas de memoria de las VM que contengan identico contenido. Esto hace que las VMs usen menos memoria pero consume mayores recursos, sobre todo CPU, pero también potencialmente ancho de banda de I/O.
Desactivarlo puede ser interesante en Hosts en los que tengamos memoria de sobra y nos interese que la VM tenga poca latencia de I/O.
(Mas info: http://communities.vmware.com/message/251822)

Conjuntado estas opciones tendremos una VM que escibe su memoria en la swap del propio ESX o en el temp, pero nunca un fichero de X gigas (tanta como RAM tenga la VM) en el propio directorio, además la VM será capaz de adecuar su memoria y no dejará que el ESX le reclame memoria cuando no la use.
Por último, la opcion más importante, no usara TPS, lo cual le dejará sus paginas de memoria dedicadas para sí misma, sin compartir. (Ojo, estas opciones no son recomendadas cuando usamos overcommittement, vamos sobresuscripcion).
Todo esto resultará en un incremento de rendimiento siempre que viene muy bien siempre y cuando sepamos que hemos tocado esto y que no deberemos pasarnos con la sobresuscripcion.

¿Sustituirá VMware su VMFS?

El CEO(Chief Executive Officer) John Thompson de Symantec ha levantado recientemente durante una entrevista el rumor de que VMware podria estar pensando en sustituir su famoso VMFS.

Si esto se produjese la estrategia de VMware y su relación con los proveedores de storage cambiaría.

Ciertamente que no se si es un bulo. Todo puede ser, quien sabe. Es probable que VMware esté viendo que algo tan antiguo(y a la vez flexible) como es el NFS esté sirviendo mejor para albergar sus VMs que el propio VMFS (con todo lo que les habra costado).

Por otra parte Microsoft apunta a que sus VMs podran ser albergadas en LUNs formateadas con Melio FS, dejando asi la puerta abierta otros Cluster File System. Su razón: que ellos piensan que es mejor que otros se dediquen a diseñar Cluster File Systems y ellos a la Virtualización.
Veremos que ocurre en los proximos tiempos.

VMware-liveCD

Vaya por delante decir que todavía no lo he probado pero este CD tiene muy buena pinta: VMware-liveCD
Ulli Hankeln ha creado una nueva version, que contiene entre otras cosas:

• Workstation 6.0.2 ripped
• Converter 3.0.3 cold clone mode
• ViClient for ESX 3.5.0 u1
• RemoteCli
• Virtual Disk Developement Kit
• ViToolkit for Powershell

Ocupa unos 450 MB y la ultima version MOA 2.3.-011 permite correr ESX 35i en WS 6.5. beta 91182. (Como ya comenté)
Se pueden montar VMFs locales y asignarselos a el ESX35i, puede incluso, una vez iniciado, ejecutar el SO que tengas instalado en el disco duro como una VM!!!

Top 10: Herramientas gratuitas para la adminsitración de VMware

Eric Siebert nos muestra esta relación de 10 herramientas gratuitas para la administración de VMware y VI3, la mayoria de ellas son geniales:

1) Putty - http://www.chiark.greenend.org.uk/~sgtatham/putty/
Telnet and SSH client for remotely connecting to the ESX service console.
2) WinSCP - http://winscp.net/eng/download.php and Veeam FastSCP - http://www.veeam.com/vmware-esx-fastscp.html
SCP clients for browsing ESX server file systems and transferring files to/from ESX hosts.
3) VI3 SnapHunter - http://www.xtravirt.com/index.php?option=com_remository&Itemid=75&func=fileinfo&id=19 and SnapAlert - http://vmprofessional.com/index.php?content=snapalert
Utilities that can report all running snapshots on ESX hosts including name, size and date. Can also automatically email reports and optionally commit snapshots.
4) VI Scripted Backup Utility - http://www.xtravirt.com/index.php?option=com_remository&Itemid=75&func=fileinfo&id=7
A backup utility that is run from the Service Console that provides VMDK level backups of any VM on storage accessible by the host. The script can be targeted at any ESX server or VC server, and if pointed at a VC server is DRS aware.
5) MCS StorageView - http://www.mightycare.de/downloads/task,cat_view/gid,16/
A utility that displays all the logical partitions, operating system, capacity, free space and percent free of all virtual machines on ESX 3.x or Virtual Center 2.x . It can also display how many gigabytes you can save by decreasing the logical partition to a size the VM really needs.
6) SSH Plug-in - http://akutz.googlecode.com/files/ConsoleClientSetup-0.1.5.msi
A VI client plug-in that integrates an SSH console directly into the client.
7) Storage vMotion Plug-in - http://sourceforge.net/projects/vip-svmotion/
A VI client plug-in that extends the client’s functionality by providing an integrated, graphical tool that can be used to invoke storage VMotion (SVMotion) operations.
8) Vmotion Info - http://www.run-virtual.com/?page_id=155
A program that will collect Vendor, Model, CPU Types and the CPU feature bits from all hosts to check for vMotion compatibility.
9) VMCdConnected - http://www.ntpro.nl/blog/archives/172-Software.html
Scans all Virtual Machines and shows if they have a CD connected to it. After scanning the VM’s you can disconnect all the CD’s with a click of a button.
10) VMware Converter – http://www.vmware.com/download/converter/
Performs hot and cold conversions of physical and virtual servers to virtual machines. Also converts image formats.

VMware Virtual Desktop Manager 2.1 Reviewers Guide

Simplemente enlazar este magnifico documento que facilita la comprension de VMware Virtual Desktop Manager 2.1. Es una guia detallada paso a paso de la installation y configuration de VMware VDM 2.1 consolidando la informacion en un unico documento. Lo cual facilita el aprendizaje.

Indice:

• VMware VDM 2.1 Overview
• VMware VDM 2.1 Key Features and Components
• VMware VDM 2.1 Requirements & Prerequisites
• VMware VDM Agent, Client and Web Access Prerequisites
• Firewall Modifications
• How to Create VMware VDM Specific User Groups
• How to Install the VDM Connection Server Standard Role
• How to Install the VDM Replica Server Role
• How to Load Balance VDM Connection Servers
• How to Install the VDM Security Server Role
• How to Login to the VDM Administrator Web Site
• How To License VMware VDM 2.1
• How to Configure VDM to Communicate with VMware VirtualCenter
• How To Add a VDM Administrator
• How To Edit the VDM Global Settings
• How to Generate a Certificate Signing Request (CSR) Key
• How to Submit CSR to your Certificate Authority
• How to Add the New SSL Certificate to VMware VDM
• How to Create the Base Virtual Machine
• How To Install Windows XP on a VMware ESX Host
• How to Install Applications
• How to Apply Windows XP Patches and Security Updates
• How to Add Group Policy Loopback Setting to VDM Managed Desktops
• How to Install the VDM Agent
• How to Create and Configure Virtual Machine Templates
• How to Convert the Base Virtual Machine to Template
• How to Configure VirtualCenter to Deploy Unique Virtual Machines from Templates
• How to Create a Guest Customization Specification
• How to Perform Maintenance to Existing Virtual Machine Templates
• How to Implement VDM Specific Windows Group Policies
• How to Prepare the Active Directory Environment for VMware Group Policies
• How to Add the VDM Group Policy ADM Template
• How to Add a New Individual Desktop
• How to Assign (Entitle) Users / Groups to a Individual Virtual Desktop
• How to Create a Persistent Desktop Pool
• How To Assign (Entitle) Users / Groups to a Persistent Desktop Pool
• How to Create a Non-Persistent Desktop Pool
• How To Assign (Entitle) Users / Groups to a Non-Persistent Desktop Pool
• How to Install the VDM Client on a Windows Client
• How to Login to VDM 2.1 through the VDM Windows Client
• How to Login to VDM 2.1 through the Web Access Client

SCSI Reservations y VMware

Cuando nos ponemos a trabajar con almacenamiento compartido mas tarde o mas temprano sale el termino SCSI reservations: Estas reservas sirven para asegurar el acceso exclusivo a recursos de disco cuando éstos recursos son accedidos por multiples hosts. Es algo que suele salir a la luz con VMware VMFS, Microsoft Cluster Server, etc...

Las SCSI Reservations son solamente usadas para operaciones específicas en las cuales se realizan cambios en los metadatos y son necesarias para prevenir que varios hosts puedan escribir concurrentemente evitando de esta manera la corrupción de datos.

Una vez que la operación es completada, la reserva es desbloqueada y las demás operaciones pueden continuar. Es obvio que es importante minimizar el numero concurrente y la duración de las operaciones que necesiten SCSI Reservations debido a que usan un lock exclusivo que al final lo que hace es serializar las operaciones. Cuando se realizan demasiadas reservations a la vez, tendremos errores de I/O porque el host que estaba intentando bloquear el recurso (la LUN, el fichero...) no puede puesto que otro host la habra bloquedao previamente. Cuando un host no puede realizar uns reservation porque hay otro host escribiendo, el primero continuará reintentandolo en intervalos de tiempo aleatorios hasta que lo logre, sin embargo, si se realizan demasidos intentos sin exito, la operacion fallará.

En el entorno de VI3, se vuelve importante el tema de las SCSI Reservations y es un factor a considerar a la hora de hacer el diseño de una arquitectura.
Algunos ejemplos de opreaciones asociadas a VI3 que requieran escrituras en los metadatos son:

• Crear o borrar un volumen VMFS
• Expandir un volumen VMFS(para mi usar extents esta prohibido)
• Encender o Apagar una VM
• Bloquear o liberar el lock de un archivo
• Crear o borrar un fichero
• Crear una plantilla
• Desplegar una VM de una plantilla
• Crear una nueva VM
• Realizar un VMotion
• Crecimiento de un archivo (Snapshot o un Virtual Disk Thin Provisioned)
• Hacer Rescans de VMFS, hacer vdf en console...
  

Lo normal en una infraestructura VI3 es que haya un numero residual de conflictos de SCSI Reservations.(Se ve en /var/log/vmkernel). Esto no nos debe preocupar porque tiene poca influencia en el rendimiento. Lo que si hay que evitar es tener demasiados problemas de SCSI Reservations porque además de afectar el rendimiento, puede hacer que algunas VMs se paren: En el caso de Linux, en muchos kernels, hace que la VM se ponga en Read Only (se soluciona cambiando un valor de timeout de mptisci.h: un RPM) y en el caso de Windows puede parar completamente la maquina.(Se soluciona cambiando un valor de timeout del disco del Registry: HKEY_LOCAL_MACHINE\System\CurrentCOntrolSet\Services\Disk\TimeOutValue)

Para mimimizar estos problemas deberemos intentar que se produzcan las menos operaciones posibles y si es posible que no ocurran simultaneamente en la medida de lo posible, es decir, una best practice seria Verificar que ninguna otra operacion de Reserva de SCSI esta ocurriendo a nivel de archivo, LUN o grupo de LUNs antes de proceder.
Algunas acciones para reducirlas son:

• Usar un punto central de administracion (Virtual Center) para ver qué operaciones se estan realizando y serializarlas en la medida de lo posible. (También las que se hacen por console)
  
• Mirar el estado de los Backups puesto que estos hacen uso de las SCSI Reservations.
  
• Limitar el numero de Snapshots activos.(Los snapshots crecen de 16MB en 16MB y cada vez que crecen usan SCSI Reservations)
• Intentar que las VMs no tengan los discos en más de dos LUNs puesto que una VMotion (operacion de VM) de una VM que tenga un disco en una LUN y otro en otra se dividira en cuatro operaciones a nivel de LUN.
  
• Intentar no realizar VMotion simultaneamente de dos VMs que residen en la misma LUN.
• Intentar solo realizar una migracion cold(VM apagada) por cada LUN en cada momento.
• Intantar no apagar o encender muchas VMs a la vez.(Esto es más por rendimiento que por SCSI reservatiosn pues solo dura 7 microsegundos el lock de reinicio)
• Limitar las creaciones y desplieges a una VM por LUN en cada momento.
• Usar un host en concreto para realizar despliegues siempre. De esta forma es facil limitar la creacion de templates, importaciones, despliegues...
  
• Usar un tamaño de LUN adecuado (<600gb)
• Usar solo un FileSystem en cada LUN
• No correr scripts que afecten a las LUNs (Backup, permisos) desde varior ESX a la vez y sobre las mismas LUNs.
  

Estas son algunas acciones para limitar dichas operaciones. Lo primero de todo es ver en nuestros logs si hay una buena cantidad de SCSI Reservations y ver si tenemos problemas de rendimiento. Posteriormente podemos aplicar alguna o todas de las recomendaciones anteriores.

Adjunto una Tabla en la que se ve el numero de operaciones por LUN que se podrian realizar corriendo un determinado riesgo:

Interesante estudio sobre el aislamiento del rendimiento entre VMs en Xen, VMware y Solaris

En estos días de competencia, se habla mucho de la diferencia de rendimiento entre Hyper-V, Xen y VMware, de hecho la red se ha plagado de documentos ( o docu cuentos) dicendo que el mío es más rapido que el tuyo por esto y por esto etc, etc... Todas estas comparaciones y marketing se han centrado en el overhead que introduce la existencia de un hypervisor comparado con un OS nativo.

Este trabajo, compara la degradación del rendimiento de una VM cuando coexiste con otra VM que tiene un comportamiento errático absorbiendo todos los recursos (CPU, Disco, Memoria...).
En mi opinión este es un dato muy interesante porque cada vez más usamos las VMs en producción y cada vez más se usa en hostings comerciales donde el proveedor deja que varios clientes administren sus servidores en el mismo host fisico y, como es natural, un cliente quiere un determinado nivel de rendimiento independientemente de lo que ocurra con otra VM alojada en dicho host fisico.

Por ello se realizaron la pregunta:
¿Cómo afecta a una VM que otra VM ahogue los recursos cuando ambas comparten el host en las diferentes plataformas de virtualización?
Las platafomas elegidas han sido : VMware Workstation(full virtualization), Xen 3.0(paravirtualization) y Solaris containers(OS virtualization) a dichas plataformas les sometieron a seis tests de estrés: fork bomb, test consume memoria, test CPU intensive, test con 10 threads de IOzone y dos tests que envían y reciben mucho I/O de red.

Las conclusiones generales son que VMware protege la VM que está actuando correctamente (la VM buena) y que a veces muestra una degradacion mayor que otras plataformas sobre la VM mala. Cosa que no es un comportamiento malo para una infraestructura en producción.
Xen, por su parte, protege la VM buena en todos los tests, excepto en el de I/O intensivo de disco en el que penaliza un poco a la VM buena.
En cuanto a Solaris, la VM buena sufre la misma degradación que la mala proporcionado una mala actuación del hypervisor.

Es una pena que no hayan hecho el experimento con VMware ESX y la linea de producto similar en Xen y Solaris, pero viene a demostrar que la "full vrtualization" tiene el comportamiento correcto y provee del mejor aislamiento de las cargas de trabajo normales(VM buena) sobre las cargas de trabajo erráticas.

Soporte para productos Microsoft en maquinas virtuales de VMware

Esta pagina de VMware describe el soporte para productos Microsoft que corren en VMs:
http://www.vmware.com/support/policies/ms_support_statement.html
Es una información útil para tener a mano, especialmente si necesitas asegurar a algún cliente sus opciones de soporte.
Personalmente, me da un poco pena que Microsoft(y Oracle dicho sea de paso) haga negocio de esta forma: poniendolo difícil a los usuarios para obtener su soporte mientras ellos desarrollan su producto de Virtualización. Está claro que cuando peguen fuerte con Hyper-V, Microsoft ofrecerá soporte total a las instancias virtuales de sus productos (que corran en Hyper-V, claro...). Que forma más triste de dar un servicio a la gente que les paga.

In Virtualization we trust.

vmreference VI3 card v1.2

Como ya os comenté en Marzo, Forbes Guthrie mantiene una increible "chuleta" en forma de pdf que actualiza de vez en cuando con las sugerencias de los que le escriben.

Aqui os dejo el enlace:
http://vmreference.googlepages.com/vmreferenceVI3Card1.2.pdf

Hay una docena de correcciones, updates, nuevas cosas añadidas, etc...
Un documento a tener a mano siempre.

VI3: ¿Dónde estan los logs?

Muchas veces(cuando tenemos problemas sobretodo) no sabemos dónde mirar en nuestro entorno Virtual Infrastructure 3 para enterarnos de lo que está pasando. Otras veces es el propio soporte de VMware el que nos pide los logs para saber que es lo que ocurre.

He aquí una lista de los logs más importantes y su ubicacion:

Ubicacion: Host ESX

Vmkernel - /var/log/vmkernel – guarda actividades relacionadas con las VMs y el host ESX.
Vmkernel Warnings - /var/log/vmkwarning – actividades relacionadas con VMs..
Vmkernel Summary - /var/log/vmksummary - Se usa para determinar las estadisticas de uptime y disponibilidad para el ost ESX. El log legible por el humano está en /var/log/vmksummary.txt
ESX Server host agent - /var/log/vmware/hostd.log - Contiene informacion del agente que administra y configura el host ESx y las VMs. (Es un log que rota).
Service Console - /var/log/messages - Mensajes generales usados para resolver problemas de VMs en el ESX.
Web Access - /var/log/vmware/webAccess - Sin comentarios..
Authentication log - /var/log/secure - Registra las conexiones que requieren autenticacion como los demonios de vmware y acciones que inicia el demonio xinetd.
VirtualCenter agent - /var/log/vmware/vpx - Informacion del agente que se comunica con el VirtualCenter.
Virtual Machines - En el mismo directorio que estael fichero .vmx hay un fichero llamado vmware.log que contiene informacion util cuando unaVM se cae o acaba inesperadamente.
HA - /opt/LGTOaam512/log/* y /opt/LGTOaam512/vmsupport/* .
Principalmente aam_config_util_listprimaries.log (hosts primarios) y aam_config_util_listnodes.log


Ubicacion: Virtual Center

Logs de Instalacion del Virtual Center

Los logs de instalacion están en el directorio %TEMP% del usuario que instaló el software

• vmlic.log resultados de test del serviodr de licencias durante la instalacion
• redist.log resultados de insalacion MDAC/MCAD QFE
• vmmsde.log log de instalacion de MSDE
• vmls.log log de instalacion del License server
• vmosql.log Creacion de la Base de Datos/transaciones de VCDB
• vminst.log Log de la instalacion y subtareas del VC server
• VCDatabaseUpgrade.log Detalles del upgrade de VC 1.x DB
• vmmsi.log Log de instalacion del VI client
• vpxd-0.log pequeño log de la primera vez que se arranco el servicio

Logs del Virtual Center
Los logs del Virtual Center están en el directorio%TEMP%\vpx del usuario que esta corriendo el demonio vpxd

vpxd-#.log (# es del 0-9)
vpxd-index contiene el # del actual acrhivo de log en uso. Los logs rotan cada vez que el vpxd es iniciado y/o cuando llegana 5MB.

Logs del VI Client

Los logs del VIC estan en %TEMP%\vpx del usuario que esta corriendo el cliente
viclient-#.log (# es del 0-9). Los logs rotan cada vez que el cliente es iniciado.

Logs Varios

• Core dump : %USERPROFILE%’Application Data’VMware
• Log del debug del License Server %ALLUSERSPROFILE%’Application Data’VMware’VMware License
• Server’lmgrd.log(se resetea cada vez que el servicio se inicia; no rotacion)
• %ALLUSERSPROFILE%’Application Data’Macrovision’FLEXlm’
• Web Access (Tomcat) Logs C:’Program Files’VMware’VMware VirtualCenter 2.0’tomcat’logs

¿Que hace cada proceso de un ESX?

Siempre me he preguntado qué hace cada proceso en un servidor ESX de VMware. El saber a tan bajo nivel que es cada cosa:
- nos da cierta seguridad porque al fin y al cabo es un *nix (windows la verdad es que me manejo a nivel de servidor pero no tan agusto como en un linux...),
- nos puede venir bien para tener el concepto de qué hace funcionar esas maquinas virtuales y qué representan para el Red Hat 7.1 que en realidad lleva el servidor ESX.
- nos sirve también para cuando el VIC falla(lo hace de vez en cuando) y no nos da la informacion necesaria de lo que ha pasado o esta pasando(esto ultimo lo hace constantemente... aun asi es muy buen producto).

Al grano, ¿qué procesos podemos ver corriendo cuando realizamos un 'ps' en nuestros ESX?
(Bueno para verlo bien deberemos ejecutar "ps axfwwww", las w son de wide wide wide, porque si no los procesos de nombre largo apareceran cortados en nuestra consola).

[vmnixhbd]
Este proceso del kernel modificado de VMware(vmnix) controla las HBAs de nuestro sistema.
[vmkdevd]
Este proceso controla los dispositivos(devices o adapters) que pueden ser reconocidos por el vmkernel.

Estos dos ultimos procesos son consultados por el comando esxcfg-vmhbadevs que nos devuelve el mapping de nombres vmhbaX:X:X a nombres /dev/ de linux.

/usr/sbin/vmklogger
logger -t VMware[init] -p daemon.err
Estos procesos se encargan del log del vmk(vm kernel o vmnix).

/bin/sh /usr/bin/vmware-watchdog
Este proceso es un supervisor (como su nombre indica perro guardian), es decir, es un proceso(un script de shell) que tiene el cometido de lanzar otro proceso y supervisar si se cae o no para levantarlo.
Es algo que me suena, jeje, reconozco que quiza en algunos servidores tenga tareas cronificadas para este tipo de labores... como dice un amigo: "Ese script me ha salvado de venir muchos domingos...".
Realmente lo que hace el proceso es lanzar el proceso especificado y volver a levantarlo si se cae. Dejará de hacer esto(en consecuencia dejara caido el servicio al cual supervisa) si se producen un numero de caidas sucesivas del proceso("quick failures" definido como "caidas entre las que hay menos tiempo que min_uptime") o un numero absoluto de caidas totales.

Por ejemplo: /bin/sh /usr/bin/vmware-watchdog -s vpxa -u 30 -q 5 /usr/sbin/vpxa
Sintaxis: /usr/bin/vmware-watchdog -s tag [-u min_uptime] [-q max_quick_failures] [-t max_total_failures] command
-s Nombre/Tag del servicio que debe correr (en este caso vpxa)
-u Maximo tiempo en segundos entre caidas para considerarlas "quick failures". O minimo tiempo que debe estar levantado para que
-q Numero maximo de "quick failures"
-t Numero total de "failures"
command: Comando a ejecutar (por ejemplo /usr/sbin/vpxa).

/bin/sh /usr/bin/vmware-watchdog -s webAccess -u 30 -q 5 /usr/lib/vmware/webAccess/java/jre1.5.0_07/bin/webAccess -server -Xincgc -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/common/endorsed -classpath /usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/bin/bootstrap.jar:/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/bin/commons-logging-api.jar -Dcatalina.base=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17 -Dcatalina.home=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17 -Djava.io.tmpdir=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/temp org.apache.catalina.startup.Bootstrap start
\_ /usr/lib/vmware/webAccess/java/jre1.5.0_07/bin/webAccess -server -Xincgc -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.endorsed.dirs=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/common/endorsed -classpath /usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/bin/bootstrap.jar:/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/bin/commons-logging-api.jar -Dcatalina.base=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17 -Dcatalina.home=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17 -Djava.io.tmpdir=/usr/lib/vmware/webAccess/tomcat/apache-tomcat-5.5.17/temp org.apache.catalina.startup.Bootstrap start
Como vemos el proceso vmware-watchdog lanza y supervisa el proceso webAccess de forma que si en los ultimos 30 segundos se cae mas de 5 veces, simplemente dejará de levantarlo.
Pero, ¿qué es el proceso "/usr/lib/vmware/webAccess/java/jre1.5.0_07/bin/webAccess": Este proceso controla el servidor web del ESX(sí, ese que no tiene todas las funcionalidades y por eso no se usa mucho...).
Su reinicio se realiza de esta manera: service vmware-webAccess restart.
Su log esta en: /var/log/vmware/webAccess
Puertos en uso: 8080, 8009, 8005,

/bin/sh /usr/bin/vmware-watchdog -s vpxa -u 30 -q 5 /usr/sbin/vpxa
\_ /usr/lib/vmware/vpx/vpxa
El agente del Virtual Center(el encargado de cominicarse conel VC) es uno de los que mas CPU consume normalmente. Como en el caso anterior watchdog vigila que no se caiga muchas veces. Entres sus funciones estan las de: comunicarse con las VMs, comunicarse con el Virtual Center y mantener la informacion del estado de los hosts comunicandose con VMAP y poder asi decidir que hacer en caso de caida de otro hosts(HA).
Su reinicio se realiza de esta manera: service vmware-vpxa restart
Su log esta en: /var/log/vmware/vpx
Puertos en uso: 902, 903 (el xinetd usa el 902 de la interfaz local)

/bin/sh /usr/bin/vmware-watchdog -s hostd -u 60 -q 5 -c /usr/sbin/hostd-support /usr/sbin/vmware-hostd -u -a
\_ /usr/lib/vmware/hostd/vmware-hostd /etc/vmware/hostd/config.xml -u -a
Este proceso es, por lo general, el que más CPU consume del servidor. (Suele ser tres veces más que el segundo que mas consume, el vpxa). Este proceso se ocupa, entreo otras cosas, de que el Virtual Infraestructure Client se entere de los cambios que se producen en el ESX. Los cambios realizados por linea de comandos en el ESX no seran visibles al Virtual Center sin reiniciar este demonio y, por consiguiente, que vuelve a leer el fichero de configuracion del ESX(/etc/vmware/esx.conf)
Su reinicio se realiza de esta manera: service mgmt-vmware restart
Su log esta en: /var/log/vmware/hostd.log

/bin/sh /usr/bin/vmware-watchdog -s cimserver -u 60 -q 5 /var/pegasus/bin/cimserver daemon=false
\_ /var/pegasus/bin/cimserver daemon=false
\_ /var/pegasus/bin/cimservera
Estos procesos son ajenos a VMware(de hecho Xen también los usa: http://xen.org/files/xs0106_xen_managmnt_interf.pdf ).
Llevan el CIM(Common Information Model), un standard industrial desarrollado por el Distributed Management Task Force (DMTF), para describir datos acerca de aplicaciones y dispositivos de forma que los administradores y los programas de gestion de software puedan controlar de la misma manera las aplicaciones y dispositivos en diferentes plataformas, asegurando la interoperativilidad. Usa tecnicas de Programacion Orientada a Objetos para proveer de una definicion consistente y una estructura de los datos. Por ejemplo, si una empresa compra cuatro servidores de diferentes vendedores, con CIM el administrador puede ver la misma info de cada uno de ellos: fabricante, SN, numero de dispositivo, capacidad de almacenamiento, relacion con aplicaciones... (Otros protocolos mas simples son SNMP y DMI)
Mas info: http://www.openpegasus.org/

/usr/lib/vmware/bin/vmkload_app --setsid --sched.group=host/system/vmkauthd --sched.mem.min=4 --sched.mem.max=12 /usr/lib/vmware/bin/vmware-vmkauthd
Este proceso es el cargador de aplicaciones del espacio de usuario. La aplicacion es ejecutada con los parametros indicados y administrada por el VMkernel. El proceso vmkload_app espera a que la aplicacion termine y sustituye (hace de repetidor/proxy) la entrada y la salida standard de la aplicacion. Si le enviamos una señal nº7(SIGNAL 7) a vmkload_app la señal sera reenviada a la aplicacion que corre debajo.
Solo las aplicaciones compiladas para el VMkernel pueden ser ejecutadas por este proceso, además, sólo son permitidos los binarios listados explicitamente en /etc/vmware/UserWorldBinaries.txt.
Con la opcion -k se puede mandar una señal a la aplicacion que esta corriendo.
Con la opcion -b se puede forzar a la aplicacion que esta ejecutandose a pararse y esperar que se enganche un debugger.

En concreto el proceso anterior esta lanzando la aplicacion /usr/lib/vmware/bin/vmware-vmkauthd desde el espacio de usuario contra el VMkernel. Las opciones dicen que se ejecute en el schedules group host/system/vmkauthd, con un maximo de memoria de 12 y un minimo de 4 y que se cree una nueva sesion de terminal para el proceso vmkload_app.
/usr/lib/vmware/bin/vmware-vmkauthd se encarga de la autorizacion el vmkernel(en concreto de que podamos usar la console de las VMs, como su fuera un redirector del KVM).
Su fichero de configuracion es /etc/vmware/config
Su reinicio se realiza de esta manera: service vmware-vmkauthd restart
Este proceso parece que no usa ningun puerto directamente pero el 902 es el puerto well-know de vmkauthd y es usado por vpxa.

/usr/lib/vmware/bin/vmkload_app /usr/lib/vmware/bin/vmware-vmx -ssched.group=host/user -@ pipe=/tmp/vmhsdaemon-0/vmx6c1dbb9c3b513d69;vm=6c1dbb9c3b513d69 /vmfs/volumes/4640826e-e0c6126a-e819-001a64088132/Virtual_Machine_RHELAS4U2/Virtual_Machine_RHELAS4U2.vmx
Estos procesos son la joya de la corona. Realmente son los procesos que representan las VMs, es decir, hay tantos procesos de este tipo como maquinas virtuales encendidas. Para el ESX cada VM es un unico proceso lanzado desde el espacio de usuario a través de vmkload_app. Como se ve, hace referencia al archivo de conf de la maquina virtual(vmx).

La forma de apagar forzosamente una maquina virtual (cuando no queda más remedio) es haciendo un kill -9 a ese PID, de esta forma el proceso muere y la maquina virtual será reportada en el VIC como apagada. Si alguien quiere tenfo desarrollado un rpc que se instala en el ESX y permite "apagar" una maquina virtual de forma instantanea. Lo use para un cluster GFS de maquinas virtuales y es el equivalente de un switch de corriente que le quita la corriente a un servidor para realizar el fencing.


Adjunto imagen con la configuracion de puertos de VI3. Espero que sirva para aclarar el tema de los puertos:


Como relfexion: Realmente en todos los ESX que he mirado, los procesos que más CPU gastan son vmware-hostd y vpxa que no se ocupan realmente de ejecutar las VMs sino que se ocupan de conectar la infraestructura virtual. Sin embargo los procesos de las maquinas (los procesos vmware-vmx) no consumen ni de lejos la misma CPU. ¿No deberia ser al revés si lo que estamos compartiendo con nuestros servidores virtuales es la CPU? Quiza sea un tema de cómo representa la CPU el Red Hat que lleva debajo..., quiza tengo algo mal en mis ESX...

Thin Provisioned: Problemas con Storage VMotion, migraciones y clonaciones

Cada vez es más usual trabajar con VMware sobre NFS. La combinacion con una NetApp y sus FlexVolumes hace que sea algo muy flexible y facil de provisionar y administrar. Con la capacidad de las cabinas NetApp de realizar Thin Provisioning somos capaces de dar grandes volumenes de datos pero ocupar solo lo necesario. El concepto se ve facilmente de forma grafica. Por defecto, cuando provisionamos VMDKs por NFS las cabinas NetApp lo administran como thin provisioned. Hasta el momento esto no habia dado problemas de ningun tipo, es mas, es una gran ventaja.

Las pruebas muestran que, aunque los VMDKs son provisionados como thin en su creacion, luego se pueden convertir a thick a lo largo de su vida por una serie de operaciones como son (Quiza haya mas):
:( Migracion de los VMDKs de un datastore a otro (aunque el destino tambien sea NFS) convierte los VMDKs a thick.
:( Realizar clones de los VMDKs thin hace que los clones sean thick.
:( Realizar Storage VMotion tambien provoca que los discos se vuelvan thick.

¿Como solucionarlo?

Si tenemos una NetApp con single file SnapRestore estamos de suerte. Bueno, al menos las dos primeras operaciones antes descritas sí que podemos conseguir que nos mantengan los VMDKs de forma thin. (Para la tercera Storage VMotion no sirve).

Pasos:

1. Una vez preparada la VM (sysprep si es windows), tomaremos un snapshot del volumen que la contiene [snap create vol-name snapshot-name ].
2. Posteriormente creamos una VM en el Virtual Center pero sin disco. (Esto crea los ficheros de conf y el directorio)
3. Ahora podemos correr un SnapRestore para recuperar el .vmdk y el -flat.vmdk. [snap restore -t file -s snapshot-name -r new filename and path original filename and path]
4. Editaremos el .vmdk de la nueva VM para que apunte al nuevo -flat.vmdk. Y ya solo nos queda Edit Settings y añadir el disco.

como funciona VMware HA

Bueno despues de varios posts cortos aqui va uno largo que llevo preparando tiempo.

La documentacion de VMware acerca de VMware HA deja bastante que desear y realmente es un producto que muchas veces necesitas conocer más a fondo para resolver problemas que te encuentras, por eso veo necesario tener una pequeña guía (técnica) de cómo funciona VMware HA:

VMware HA monitoriza constantemente todos los ESX de un cluster y detecta las caidas de estos. En cada host hay un agente corriendo que mantiene el heartbeat con los demas hosts del cluster. La perdida del heartbeat inicia el proceso de reiniciar las maquinas virtuales en los otros hosts proporcionando de esta forma un fail over de las maquinas virtuales con una parada minima(downtime = tiempo de reinicio) de servicio.

Es importante resaltar que HA es reactivo, es decir actua cuando ocurre algo y NO usa Vmotion y DRS es proactivo: usa vmotion y actua para que no ocurra nada o para que no se de la situacion en la que pueda ocurrir.

El hecho de que las VMs se inicien en un host o en otro cambió en el VC2 y el VC2.1: El primero lo hacia alfabeticamente, es decir la VM se iniciaba en el siguente host alfabeticamente que tuviese recursos, en cambio en el VC2.1 el host que iniciara la VM sera el host que tenga mayor capacidad(sin reservar) para levantarla. Una vez que HA ha realizado el paso de VMs, el DRS entra en juego y verá si es necesario mover las VMs.

VMware HA no controla la caida individual de una VM, ésto puede tratarse con una alarma, ya sea con el Virtual Center o con un software de monitorizacion externo.

Arquitectura:

La creacion y administracion de los clusters de HA se hace a traves del VC. El servidor de administracion del Virtual Center instala un agente en cada host del cluster de forma que cada host pueda comunicarse con los otros y mantener la informacion del estado de los hosts y poder asi decidir que hacer en caso de caida de otro hosts.
En cada cluster hay un host que es el primario(suele ser el primero) que actua como controlador y es el que inica las accciones de failover. De hecho, cuando se introduce un nuevo nodo al cluster, éste ultimo necesita comunicarse con el primario para completar la configuracion. Si el nodo primario cae, HA inmediatamente promociona uno de los nodos a primario.
Actualmente AAM no permite mas de 4 hosts y el parametro de max number of failures se refiere al maximo numero de primarios que podria haber en un cluster.

- Cuando queremos quitar un nodo del cluster lo podemos poner en Maintenance Mode y apagar las VMs o migrar (vmotion) sus VMs (si DRS esta activado, éste nos lo propondrá o lo hara directamente).
- Cuando se añade un nuevo nodo al cluster, todas las VMs se ponen a default: Restart Prioriy = Medium e Isolation Response = PowerOff

Nota: Para apagar temporalmente HA ponemos el ESX en maintenance mode y para apagar temporalmente DRS lo configuramos como partially automated.

El agenteVC (vpxa) se comunica con las VMs y VMAP (este ultimo contiene la lista de que hosts estan corriendo que VMs). El agente AAM (HA agent) monitoriza AAM en otros hosts (heartbeat via red SC), para evitar el split brain cuando los nodos se quedan aislados, cada nodo tiene una direccion a la que hace ping para ver si esta aislado (option das.isolationaddress ).
[Mas opciones avanzadas: http://pubs.vmware.com/vi35/resmgmt/wwhelp/wwhimpl/common/html/wwhelp.htm?context=resmgmt&file=vc_cluster_das.10.9.html]

Los requesitos para que funcione HA son:

• Capacidad de encender la VM desde cualquier host
• Acceso a recursos comunes(red, SAN)
• Resolucion de DNs en el cluster(tiene muchisima dependencia /etc/hosts y /etc/resolv.conf)

Parametros a Configurar:

Orden de reinicio de las VMs: Establece que prioridad de reinicio tienen las VMs. Se debe establecer a Disabled si no queremos que se use HA en dicha VM.

Admision Control: Aqui se prioriza el uptime o que las maquinas tengan sus recursos siempre.

Isolation response: Que hacer si se queda aislado el host: el power off de las VM liberará el lock de los discos.

Nota: Cuando se añade un nuevo nodo al cluser, todas las VMs se ponen a default: Restart Prioriy = Medium e Isolation Response = PowerOff

¿Que ocurre si el VC Server se cae?

El Virtual Center Management Server(servidor del VC) no es un unico punto de fallo porque si cayera el VC Server los clusteres de HA siguen pudiendo reiniciar las maquinas virtuales en otro host en caso de caida de uno de los hosts de forma que el funcionamiento general sigue pero la informacion de que recursos estan disponibles será la del estado del cluster antes de caer el VC Server.

Si entramos con el VIC a un ESX y cambiamos algo mientra el VC esta caido entonces eso cambios si tienen efecto y cuando repongamos el VC los verá.(En cambio si el VC no esta caido y modificamos algo con el VIC a traves de un ESX , el VC no lo verá y tendrá desactualizado su VMap etc...)

VMware HA esta continuamente monitorizando qué recursos hay para ser capaz de reiniciar las maquinas en diferentes hosts en caso de caida de uno de ellos. El agente AAM se ejecuta en la service console de los hosts y mantiene una base de datos en memoria de los nodos del cluster usando los heartbeats para coordinar los nodos que estan activos y los que no (los que no son activos son los que estan sin red o en maintenance mode).

El hecho de que una maquina virtual pueda ser levantada en otro servidor ESX(host) es posible gracias a la tecnologia de locking de la pila de almacenamiento del ESX que les permite a varios ESX acceder a un mismo disco simultaneamente.

¿Que ocurre cuando un host se cae? (Cronologia del Fail-Over)

Todo el proceso dura 15 segundos despues de que el host se quede aislado y no mande mas heartbeats:

t=0s: Un host deja de tener conectividad(o se queda aislado en la red) y deja de mandar heartbearts. El nodo intanta hacer pings a la isolation address para ver si efectivamnete esta aislado.(la verification address es el default gw de la interfaz de la service console, para cambiarla hay que cambiar el parametro das.isolationaddress en advanced parameters). Si no puede hacer ping a su isolation address entonces el nodo sabe que esta aislado y no que los otros nodoas se han caido.

t menor que 12s: Si antes de 12 segundos vuelve la conectividad, todo vuelve a la normalidad. Los demas hosts marcaran al hosts con problemas de red como activo y no pasará nada. El host no se marcará a si mismo como aislado.

t entre 12s y 15s: El host se marca como aislado(isolated) y empieza a apagar sus maquinas para liberar locks(respuesta por defecto y configurable). Si justo la conectividad vuelve en este momento las maquinas virtuales se apagaran(si esta conf por defecto) pero no se levantarán(reiniciarán) en otros hosts porque los otros no le han marcado todavia al host como caido(failed). El apagado de las maquinas es hard.

t=15s: Los demas hosts declaran el host como caido(failed) y en consecuencia adquieren el lock de las maquinas virtuales y las levantan(si asi lo hemos configurado, si no la VM seguira corriendo en el host aislado y el mecanismo de locking prevendrá que no se inicie en otro sitio).

http://kb.vmware.com/selfservice/viewContent.do?language=en_US&externalId=2956923

¿Que ocurre si Current failover capacity != Configured failover capacity? (Red Cluster)

Esto ocurre cuando han fallado mas hosts que los previstos. Las VMs con mayor prioridad haran el fail over las primeras. Para la version 3.02 de ESX y anteriores, el valor de HA Failover Capacity se calcula así: El valor de Failover Capacity está determinado por el valor del slot que tiene el cluster. El slot es calculado con una combinacion de la CPU y Memoria total que hay en los hosts.

Ejemplo:
Tenemos 4 hosts y el valor CONFIGURADO de Failover Capacity es 1 Los hosts tienen esta memoria: ESX1 = 16 GB
ESX2 = 24 GB
ESX3 = 32 GB
ESX4 = 32 GB
En el cluster tenemos 24 VMs configuradas y funcionando. De las 24, hay que determinar cual es la que mas "configured memory" tiene. Por ejemplo pongamos 2GB. Las demas tienen menos o igual a 2GB de memoria configurada. Con esto ya podemos hacer el cálculo:
1. Escojemos el host ESX que tenga menor memoria RAM intalada. En este caso es ESX1 y tiene 16 GB

2. Dividimos este valor por el mayor valor de la memoria RAM de nuestras maquinas virtuales(2GB en el ejemplo). Nos sale 8 (16 / 2). Esto significa que tenemos 8 slots disponibles(como minimo) en cada ESX.

3. Como tenemos 4 hosts y la failover capacity configurada es de 1, nos podriamos quedar con 3 hosts en la peor situacion(que cayera uno). Por ello el numero total de VMs que podemos encender en esos 4 hosts es 24 VMs. ( 8 slots x 3 hosts en el caso peor = 24 VMs)

4. Si el numero total de VMs excede 24 entonces nos dará: "Insufficient resources to satisfy HA failover" y el el valor de "current failover capacity" será puesto a 0. Si el numero de VMs encendidas es menor que 24 no obtendriamos este mensaje.

Nota: Si se sigue viendo el mensaje despues de bajar el numero de maquinas encendidas, chequea las reservations de CPU y Memory en las VMs y en los resource pools porque esto puede modificar el calculo. Se debe evitar reservations de CPU y memoria innecesarias en las VMs porque esto puede causar que ocurran estos tipos de errores dado que tenemos que asegurar que el recurso esta disponible.



Para que el Virtual Center deje de estar en una situacion en la que los recursos son insuficientes para satisfacer VMware HA posdemos hacer lo siguente:

1.- Marcar "Allow Virtual Machines to be powered on even if they violate availability constraints" en la confiduracion del cluster. En este caso se ignoran los calculos anteriormente descritos y se intentará encender el maximo numero de VMs posibles en caso failover. Con esta opcion se puede establecer la restart priority (en "Virtual Machine Options") en la configuracion del cluster, de esta forma, las VM prioritarias seran encendidas antes y posteriormente las menos prioritarias hasta en punto en el que ya no se pueda encender ninguna VM más

2.- Si tenenmos una VM que tiene configuarada una gran cantidad de memoria, podemos o bien rebajar su memoria configurada o bien sacarla del cluster y ejecutarla en otro ESX standalone. Esto incrementará el numero de slots disponibles con el hardware que tenemos.

3.- Incrementar la cantidad de memoria en los servidores de forma que haya mas slots disponilbes con las reservatiosn de RAM actuales.

4.- Quitar las reservas de CPU en todas las VM que sean mayores que la velocidad maxima de los procesadores fisicos.

Nota: El calculo descrito arriba es muy limitado como se puede ver y va a ser revisado en las siguentes versiones del Virtual Center.

Troubleshooting:

- Conectividad IP: pings desde todos a todos y con el nombre corto y el FQDN. Pings al VC server

- DNS!!!:

• Se pueden resolver los nombres cortos(sin el dominio) en cada ESX de los otros ESX
• El FQDN es menor de 29 caracteres?
• Mirar el /etc/hosts y /etc/resolv.conf poner en esos ficheros el "hostname.FQDN" tambien.
• Se puede editar el nsswitch.conf y cambiar: "hosts: dns files". Asi mira primero en dns y si estan caidos en local.

- Que la red y el almacenamiento sea visible por los nodos.
- Que no haya habido usuarios que hayan accedido con el VIC al host en concreto bypasseando al Virtual Center y hayan cambiado las reservations.
- Logs: /opt/LGTOaam512/log/* y /opt/LGTOaam512/vmsupport/* .
Principalmente aam_config_util_listprimaries.log (hosts primarios) y aam_config_util_listnodes.log

Errores y problemas tipicos:

"Could not find a primary host to configure DAS on"
A host that was removed from the VC inventory still appears on the internal list of hosts for this cluster.
Workaround: create a new cluster and add hosts to this new cluster.
Resolved in ESX Server 3.0.1 and VC 2.0.1.

"Configuring HA failed" or "while using HA, the vm did not failover".
Size of Fully Qualified Domain Name (FQDN) or short host name.
Workaround:
If the host short name is more than 29 characters, change the HOSTNAME entry in /etc/sysconfig/network to the shorter name.
If using an FQDN that is greater than 29 characters:
• Change the FQDN to less than or equal to 29 characters.
• Remove the existing cluster.
• Create a new cluster.
• Add all the hosts back to the cluster.

HA Configuration Fails
Check DNS, FQDN
You have just added a new host to the cluster
• Check /opt/LGTOaam512/log/aam_config_util_addnode.log
• /var/log/vmware/vpx/vpxa.log
• In VC, right click on the host that shows the HA problem and click reconfigure for HA.
• Were all the hosts responding?
• If not –new host cannot communicate with any of the primary hosts.
• Solution:
• Disconnect all the hosts that are not responding before you can add the new host.
• The new host becomes the first primary host.
• When the other hosts become available again, their HA service is reconfigured. ESX Server is running slowly.

Top command shows vmware-hostd using a lot of resources
vmware-hostd Uses a Lot of CPU or Has Generated a Core Dump Why DRS / HA cluster that contains VMs originally built on an ESX Server 2.x host.
Fix: To adjust resource allocation for vmware-hostd: For each VM, right click it and go to Edit Properties. Select Resources. Ensure you "touch" each CPU and memory resource:
• Restart hostd: type: service mgmt-vmware restart
• Set resources to the settings you want.

"HA service doesn't start up" or "HA error on the host, after booting successfully after host failure"
Due to problem rejoining the rest of the cluster
Fix: use the ReconfigureHA task on the host to correctly configure the HA service on the host.

Deploying a VM from a template into a cluster, the updated BIOS settings are lost.
Affects HA/DRS clusters but not DRS-only clusters.
Fix: Change the BIOS setting in the affected deployed VM.