Resumen de Networking en VI3

Jason Boche ha publicado este diagrama de red en VI3, muestra exactamente qué puertos usa VC, ESX y otros servicios. Me parece extremadamente útil para solventar problemas de red en VI3. Aqui está:




Feliz año nuevo!!!!!! Os deseo lo mejor para este 2009 que llega.

Protocolo de Internet en bolas

Ya sé que con este titulo puedo aparecer en todos los buscadores, aunque desde siempre "internet" y "en bolas" son dos terminos que han estado ligados. ;-)
Además es raro que no hable de algo tecnico, pero es viernes y la verdad es que asi pruebo a incluir un video en el blog, asi que haremos una excepcion: ;-)

En el museo de Miraikan, museo de la ciencia de Tokyo, hay una máquina que representa el funcionamiento de un protocolo orientado a paquetes (como TCP/IP) de forma mecánica.

Los bits son bolas blancas o negras y los cables de datos son pistas por donde ruedan las bolas. También existen routers y PCs!!! Solo los japos son capaces de hacer algo asi. Lo cierto es que en la universidad en la asignatura de Redes, es lo que tendrian que poner el primer día!!!:

Comando dmidecode: o como ver la configuracion de los DIMMs de memoria de tu ESX y mucho mas

Me encontraba yo en la tesitura de ampliar la memoria de mis ESX o simplemente comprar más servidores (o una mezcla de ambas).
Pero, ¿cuantos DIMMs tienen ocupados mis ESX?
(Y en general: ¿Como sé qué configuracion de memoria tiene mis servidores Linux?)

Lo primero a lo que se puede recurrir es a aplicaciones del fabricante, tipo Open Manage de DELL o IBM Director o DSA de IBM para ver cuantos slot/bancos de memoria libres tenemos y en consecuencia cuanto podemos ampliar. Esta es la manera más lenta pero mas bonita graficamente. (Eso sí, requiere instalacion de dichas aplicaciones, bajandonos la version para RedHat3, que es lo que lleva el COS. Es posible que no es lo que busquemos para dar un vistazo rapido a la configuracion de memoria que tenemos).

Lo segundo es recurrir a un comando (aunque todavia no lo he probado): lshw.
Lo malo es que dicho comando no viene por defecto en elos ESX y adolece de lo mismo que la primera opcion: Hay que instalar algo en la console de nuestro ESX y eso me gusta evitarlo siempre que puedo.


Por último, existe un comando muy útil que no conocia: Es dmidecode (ejecutar siendo root) que nos da un montonazo de informacion de nuestro harware, entre otras cosas : BIOS Information, System Information, Base Board Information, Chassis Information, Cache Information, Processor Information,Port Connector Information:USB,Video,IDE/Parallel ATA,SAS,Serial,Ethernet, ServeRAID Adapter, PCI-Express/X Riser, Power Supply, Fan, PCI-Express ocupadas y libres... y un largo etc...

La informacion que buscamos (Estructura de los DIMMs de memoria RAM instalada actualmente en el sistema) aparece de este modo:

Handle 0x004A
        DMI type 16, 15 bytes.
        Physical Memory Array
                Location: System Board Or Motherboard
                Use: System Memory                
                Maximum Capacity: 65024 MB
                Number Of Devices: 12
Handle 0x004B
        DMI type 17, 27 bytes.
        Memory Device
                Size: 512 MB
                Form Factor: DIMM
                Set: 1
                Locator: DIMM 1
                Bank Locator: Bank 1
                Speed: 266 MHz (3.8 ns)
                
Handle 0x004C
        DMI type 17, 27 bytes.
        Memory Device                
                Size: 512 MB
                Form Factor: DIMM
                Set: 3
                Locator: DIMM 4
                Bank Locator: Bank 1
                Speed: 266 MHz (3.8 ns)
...
Handle 0x004F
        DMI type 17, 27 bytes.
        Memory Device
                Size: 2048 MB
                Form Factor: DIMM
                Set: 3
                Locator: DIMM 3
                Bank Locator: Bank 5                
                Speed: 266 MHz (3.8 ns)
        
Handle 0x0055
        DMI type 17, 27 bytes.
        Memory Device
                Size: No Module Installed
                Form Factor: DIMM
                Set: 4
                Locator: DIMM 9
                Bank Locator: Bank 6                
                Speed: 266 MHz (3.8 ns)

Se puede ver, que hay 12 slots en total, algunos ocupados por 512MB de RAM otros por 2GB, otros libres, etc ,etc..

PuTTY Connection Manager

Recientemente hablando con un guru de Oracle descubri esta maravilla de herramienta: PuTTY Connection Manager . Viene a suplir la falta de pestañas y de organizacion a la que llegas cuando tienes un monton de ventanas abiertas de PuTTY. Yo, personalmente, prefiero SecureCRT que te lo da de base, pero hace falta una licencia. Por ello, cuando uso PuTTY, este programilla se ha convertido en un indipensable.

Posts proximos

Bueno, llevo ya un retraso importante de publicacion de posts porque he andado un poco atareado este ultimo mes. Os pongo los posts en los que estoy trabajando y espero sean de inmininte publicacion:

• Mas sobre Vmware HA
• Networking en ESX
• Backup de Hosts: ESX, ESXi
• El maldito reloj en VMs linux
• El scheduler, vCPUs y demas parientes.
• Disaster Recovery

Poco a poco iran saliendo. Espero que antes del 31 todos!!!

El SPAM mundial cae un 75% tras la desconexion de la empresa McColo Corp

Sé que os tengo acostumbrados a hablar de virtualizacion y almacenamiento sobre todo, pero esta noticia me ha impresionado:

El volumen de SPAM mundial se desplomó el pasado martes 11 de Noviembre después de que una empresa de hosting, fue puesta fuera de línea.

La caída en el volumen de spam se debe a que los proveedores de Internet (ISPs) desconectaron a McColo Corp (un proveedor de hosting de California que alojaba los servidores responsables del envío de aproximadamente el 75% de todo el spam mundial diario.)

Prueba de ello es la grafica que se ve en los servidores de correo entrante (spam linea naranja, trafico normal linea azul):


Hace una seman (11 Nov) se preveia que para este martes los niveles de SPAM serian parecidos pero parece que los spammers están tardando en realojarse. Y espero que tarden mucho aunque segun los expertos estas Navidades puede llegarse a niveles historicos de SPAM.

Buen uptime!!

Esto no se suele ver demasiado. Este servidor lleva funcionando 975 días (y presumiblemente lo hará más) sin dar el menor problema. No es virtual, aunque estoy seguro que puedo encontrar alguno virtual con un uptime similar (una maquina virtual tiene razones para tener mayor uptime pues tiene mayor tolerancia a fallos).

Es un servidor de MySQL con hardware IBM xSeries x345 con doble Xeon con un Red Hat 4 y con alimentacion a grupo electrógneo. Buen Hw + Buen SO + Buena alimentacion.



Da gusto.

VMware ESX 3.5 Update 3 y VMDK Recovery Tool (vmfs-undelete)

Al margen de hacerme eco de la noticia de que ha sido lanzada la VMware ESX 3.5 Update 3 con sus correcciones y mejoras, queria destaca una herramienta que me ha llamado la atención y que han metido de forma experimental en esta release:

Experimental Support for the VMDK Recovery Tool — This release adds support for the VMDK Recovery tool, a script intended to help customers to recover VMFS/vmdk data stores from accidental deletion of VMFS/vmdk data store or physical disk corruption. For more information, see VMDK Recovery Tool (ESX 3.5 Update 3) ( KB 1007243).

Una especie de undelete de los que haciamos en MS-DOS. La herramienta realiza un backup de la lista de bloques que usa una determinada VM (haciendo un snapshot etc...) y si la borramos por accidente (ya sabes un click fuera de lugar o locura pasajera delante de la pantalla), la podremos recuperar con esta herrramienta.

Atencion:

• Es experimental, pero habra que echarle un ojo en unos meses...
  
• No sustituye a los backups.
• No sirve para ESXi
• No sirve para luns RDM
  

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.

7 claves para tener exito en la virtualizacion.

En www.networkworld.com han publicado este articulo que me parece muy interesante: 7 claves para tener exito en la virtualizacion.

Es un articulo dirigido tanto a las empresas que están pensando en la virtualización como a las que han adoptado la virtualización. Es una recopilación de lo que me parecen buenos consejos.

NetApp Deduplicacion y LUNs: Documento

Hacía tiempo que no escribia sobre NetApp y su deduplicación. Como ya sabeis NetApp(y otros fabricantes como EMC) nos ofrece la posibilidad de deduplicar nuestros datos para ahorrar espacio. (Algunos articulos relacionados que he escrito anteriormente).
Muchas veces me he visto con dificultades para saber qué opcion es la mejor a la hora de provisionar LUNs que van a ser deduplicadas.

Por casualidad hoy he encontrado este documento en las communities de NetApp, donde se necesita login (que deben usar el mismo motor que las de VMware porque son clavadas..):
Configuring NetApp Deduplication With LUNs
"Deduplication creates free space, but where does the free space go? The paper describes 5 basic LUN configurations and the different results that occur once space is reclaimed by deduplication."

Aqui dejo el link: Configuring NetApp Deduplication With LUNs
de mi espacio de google para que os lo bajeis sin registrarse.

La configuracion más común creo que es la D (La LUN sin espacio reservado y la garantia de espacio establecida en el Volumen) y E (La LUN sin espacio reservado y sin garantia de espacio ninguna). Lo logico es que nos guste ver como encoje la LUN después de aplicar la deduplicacion.

ESXi: Acceso a "consola" y bug ESX 3.5 Update 2

El otro día David Marquina me avisó de un bug que tiene la ESX 3.5 Update 2:
" Parece ser que el FT_HOSTS y demás ficheros de configuración de HA se quedan con la primera IP que se le asignó. En mi caso via DHCP. De momento se que pasa en ESX3i y claro, no puedo abrir los ficheros "
Por lo que me ha comentado, dicho bug se ha solucionado en la VC 2.5 Update 3. Se puede ver en las Release Notes.

De todas forma en dicho momento vimos la necesidad de entrar a la "console" ESXi (que no es otra cosa que un Busy Box: un comando que lleva dentro compilados unos cuantos binarios de linux y que se parece al command.com de MS-DOS). Para ello os dejo este link: http://kb.vmware.com/kb/1003677 que nos explica cómo entrar a la consola pulsando Alt+F1 y escribiendo "unsupported".
Una vez dentro podemos hacer lo que queramos.

Aprovecho para recomendar que dentro podemos habilitar el acceso ssh:

• Editat /etc/inetd.conf (usar vi)
• Quitar el comentario # de la linea del SSH
• Kill y restart el proceso inetd (o reboot del server)

El acceso ssh me parece importante por si tenemos que entrar por cualquier circunstancia, si queremos cambiar las opciones del driver de la HBA para obtenr mayor rendimiento, si queremos usar discos thin provisionned ...

Link Best Practices para Patching del ESX

Os dejo un link que he encontrado interesante sobre el parcheo de servidores ESX:
http://www.vmware.com/files/pdf/esx_patching_best_practices.pdf

Summary:

• “Patch Overview”
• “Patch Delivery and Packaging”
• “Patch Preparation”
• “Understanding the Impact of Patching an ESX Host”
  
• “Understanding the Impact of Patching an ESXi Host”
• “Identifying Build Numbers after Patch Install”
• “Resources”

Producto Fault Tolerance de VMware (FT)

Aqui os dejo un video muy interesante sobre Fault Tolerance: Producto que se ha presentado en VMWorld 2008 como experimental y que nos acerca la Alta Disponibilidad a nivel de VM.

Se trata de una tecnologia que se basa en Vmotion para mantener una copia exacta de la VM primaria llamada la VM secundaria (con su misma IP y su misma MAC) transmitiendo cada instruccion que se ejecuta y haciendo mirror a la otra maquina de forma que si se cae la VM primaria, la secunadaria entra en funcionamiento. En terminos de High Availability es una alta disponibilidad Active/Pasive.
Se pretende usar esta tecnologia en las VMs que queramos porteger con mayor disponibilidad que VMware HA. Recordemos que VMware HA protege frente a la caida de un nodo pero es inevitable un downtime igual al tiempo de inicio de la VM en otro nodo.

Decir que como se ve en la imagen es inevitable que las VM tengan discos "zeroed", es decir que ocupen todo el espacio que reservan.

Link del video.

Supongo que lo siguiente será dos VM en Active/Active(replicacion bidireccional) y que los switches virtuales balanceen tal y como lo hacen los Foundry, Alteon o F5... veremos con qué nos sorprenden!

Virtualization for Dummies,VI3 Card en Castellano y mucho más.

Jose Maria Gonzalez dejó un comentario que aprovecho para presentar su blog (su gran blog):
Jose Maria Gonzalez dijo:
Muy interesante tu articulo, y tu blog, enhorabuena. Me gustara compartir contigo y tus lectores, si me permites, la dirección del Blog de Virtualizacion en Español que yo mismo edito y gestiono en http://josemariagonzalez.es El blog está dedicado a la Virtualización en general y en particular a las soluciones de Virtualización de Servidores más importantes; VMware, XenServer, Hyper-V. Muchas gracias y enhorabuena otra vez por tu blog. Fenomenal trabajo rgds, Jose Maria Gonzalez

En primer lugar muchas gracias por el comentario Jose Maria, me alegra enormemente que mis posts sirvan (y más a expertos como tu). Jose Maria trabaja en Dublin (segun tengo entendido) y es un profesional de la virtualización.
Hay que decir que este blog es altamente recomendable: los videos son muy instructivos y recientemente Jose Maria ha traducido la VI Card (de la que hablamos aqui) para acercarnos ese documento a la comunidad hispanoparlante.
Un saludo chemavirtual!!!

Configurar las Alarmas de VMware VI3 (ESX)

Algo que nos ofrece VI3 y que merece la pena pasarse diez minutos en configurar son las alarmas. VI3 nos ofrece la posibilidad de reaccionar (por medio de un script) o ser avisados (por mail, por SNMP) de los cambios en determinados parametros de nuestras VMs.


Las alarmas indican el estado de los objetos, estos objetos pueden ser: carpetas, datacenters, clusters, resource pools, hosts y VMs. De hecho, en el lado izquierdo del VIC podemos ver estos objetos y su jerarquia.

Lo primero que tenemos que ver es a qué nivel queremos poner la alarma que vamos a configurar. A mí me resulta muy comodo hacerlo a la altura (jerarquica) mayor: la de Hosts & Clusters, de esta forma con configurar un par de alarmas me vale para todas las VMs que hay colgando. Si me interesa alguna VM en concreto, algun parametro en concreto que no esté monitorizando con las anteriormente mencionadas alarmas configuro una alarma especifica para ello, que no suele ser el caso.

Las alarmas que suelo poner a nivel de Hosts&Clusters son dos solamente, una de tipo Alarma Host y otra de tipo Alarma VM, de esta forma me entero de lo que ocurre a los Hosts y a las VMs que tengo en mi infraestructura virtual.


Por ejemplo, añado la alama de tipo Host, marco los triggers que quiero (Remarcar que en cada campo si pinchamos hay una lista desplegable):



Y pongo las notificaciones que quiero. En general por mail, para lo cual hay que definir primero el servidor SMTP. (En el VIC, Menu Administration, Virtual Center Management Server, Configuration, Mail)

Ejemplo de mail que llega, en este caso por uso de CPU excesivo:

Target: VirtualMachine1
Old Status: Green
New Status: Yellow

Current value:
Alarma Virtual Machine - (Metric CPU Usage (Average/Rate) = 76% OR Metric Memory Usage (Average/Absolute) = 12% OR Metric Network Usage (Average/Rate) = 0% OR Metric Disk Usage (Average/Rate) = 0% OR State = Powered On)

Alarm: Alarma Virtual Machine
([Yellow Metric Is Above 75%; Red Metric Is Above 90%] OR [Yellow Metric Is Above 75%; Red Metric Is Above 90%] OR [Yellow Metric Is Above 75%; Red Metric Is Above 90%] OR [Yellow Metric Is Above 75%; Red Metric Is Above 90%] OR [Yellow State Is Equal To suspended; Red State Is Equal To poweredOff])

Description:
Alarm Alarma Virtual Machine on VirtualMachine1 changed from Green to Yellow

Detalle Importante:
En los triggers, asi como en la CPU y Memoria se establece el umbral en %.
En los indicadores de uso de disco y red hay un bug (Al menos en la 3.0.2). No se expresan en %, el numero que ponemos son los "kiloBytesPerSecond" en lo que se refiere a disco y "kiloBitsPerSecond" en lo que se refiere a red.

This is a bug in the displayed units of the VI Client.
Disk metric monitored by alarms is "kiloBytesPerSecond", not "percent".
Network metric monitored by alarms is "kiloBitsPerSecond", not "percent"

http://communities.vmware.com/message/586823#586823

Kodiak de Bluebear

Me acaba de llegar una invitación para la beta privada de Kodiak, asi que ya la estoy probando.

Como comenté otro día, Kodiak es una aplicación multiplataforma que nos permite administrar "nuestro imperio virtual" (tal y como lo dicen ellos). En principio es una beta privada que nos permite administrar VMware. Esta previsto que tambien sirva para XenCitrix e Hyper-V, tiempo al tiempo.

¿Por qué probar esta herramienta si ya tenemos el VIC? Bueno, lo primero porque es multiplataforma: Mac, Windows y Linux. Lo segundo porque ofrece (y ofrecerá funcionalidades) que no tiene el VIC, como la rapidez, la vision global... y porque nos podria(en versiones futuras) ahorrar un Virtual Center administrando los ESX de forma global...

Por el momento la he instalado en una Mandriva 2008 y va muy bien, le faltan funcionalidades pero va muy bien para ser la version 0.0.1.
La instalacion se compone de Adobe Air(hay que hacer un chmod +x del binario para Linux) y luego de Kodiak Air Package. En unos cinco minutos lo tienes instalado y funcionando:

En esta version se puede ver el mapa, rotarlo, obtener consolas de las VMs, encenderlas, apagarlas, ver datastores, resource pools, etc.
La pantalla de login se ve asi:


Una vez dentro vemos un mapa como este (o similar): (Los arcos alrededor de las VM simboliza la CPU y MEM que estan usando)


Podemos ver la VMs tambien de este modo:


¿Que no podemos hacer con Kodiak(de momento)?:

• Editar Settings de VMs
• VMotion
• Añadir o Quitar una VM

Actualizado: La leche! Asustan estos osos. Solo han tardado unos minutos desde que he puesto el post y ya han dejado un comentario!

Actualizado2: Lo siento. Ya no me quedan invitaciones para bajarse el software.

vSMP (virtual symmetric multiprocessing)

Algo que me vienen preguntando ultimamente es cuándo usar vSMP.
¿Debemos asignar a una VM más de un virtual processor?

Deberíamos usarlo solamente cuando sabemos que se va a aprovechar por las aplicaciones que lleva dentro la VM, no simplemente por pensar "cuantas más vCPU tenga una VM mejor". Hay personas que piensan que cuantas más vCPU tenga una VM mejor, y esto no es necesariamente cierto, de hecho puede correr peor con dos vCPU que con una.

La razon para esto es que el scheduler de CPU del hypervisor debe encontrar el numero cores disponibles simultaneamente igual al numero de vCPUs que tiene asignada la VM. Por ejemplo, una VM con cuatro vCPUs deberá tener cuatro cores disponibles a la vez para cada petición de CPU que hace al host. Si dichos cuatro cores no están disponibles en ese momento (porque hay otra VM usando dos, por ejemplo) la VM deberá esperar hasta que estén disponibles.

Tips respecto a esto:

• Cuantos menos vCPUs lleven las VMs mejor.
• Sólo asignar a una VM multiples vCPUs cuando sabemos que la aplicacion que lleva dentro va a hacer uso de ello.
• Nunca asignar el mismo numero de vCPUs que el numero total de cores de tu host.(pCPUs). Mejor si mantenmos el doble de cores fisicos que los vCPUs de la VM que más tiene. (Por ejemplo, 8 cores fisicos = 4 vCPU como maximo)
• Si estas haciendo P2V de un servidor Windows con varias CPUs a una VM con una vCPU, cambia el HAL de multiprocessor a uniprocessor.
• Si puedes, evita usar afinidad de CPU.

Actualización:
Este link, aunque un poco viejo, explica muy tecnicamente el comportamiento con vSMP y sin él.

Uso de CPU en Oracle 10g RAC en VMware

Resulta que tenemos preparada una maqueta con Oracle 10g RAC de dos VMs con Linux Red Hat 4 U4 para pruebas/tests y desde hace tiempo se quejaban de que iba lenta. Despues de determinar que efectivemente iba lenta, mirando las graficas de la VM se veia que todo era normal: Un relativo uso de CPU alto, disco normal, red normal, etc, etc... Por supuesto los DBAs echaban la culpa al disco (sin saber bien lo que es un vmdk o las capas de abstraccion, caches etc, que tiene desde los discos en RAID5 de una cabina hasta el disco en vmdk....), o a que estaba virtualizado y claro era mas lento por eso...

Despues de descartar una por una las ocurrencias de los DBAs y de probar a cambiar la VM de discos(locales/SAN), de host y probar los polvos magicos, me meti en arena y sacamos unas cuantas cosas (todas en relacion con Oracle):
Indices de base de datos no creados, discos en RAID1 de software realizado por ASM de Oracle... etc, y una vez que teniamos la base de datos mas relajada decidi ver cuanta CPU consumía la VM cuando estaba parada. Fue una sorpresa ver como los scripts de Oracle de administracion, de recogida de estadisticas y en concreto el CRS estaban comiendo CPU aun a pesar de que la DB estaba apagada.

Pues bien, parece ser que uno de estos procesos, en concreto el CRS, realiza chequeos cada cierto tiempo y ello provoca consumo de CPU(se solapan chequeos y se va engordando el consumo, etc...).
Por lo que he podido ver ocurre sólo en entornos de Oracle 10g RAC virtualizado.

He aqui un link http://www.oracloid.com/2007/10/crs-eating-cpu-on-vmware/ que nos dio la solucion.
En la grafica se puede ver el bajon de CPU que se produce al cambiar un SLEEP 1 por un SLEEP 35. L averdad es que no es la primera vez que he observado que en VMware (esto es solo una impresion) con VMs linux, los scripts(perl, shell, compilaciones...) no van todo lo bien que van en fisico....

Compatibilidad de VMotion

En mi opinión, una de las grandes ventajas de VMware (y poco a poco sus competidores) es la capacidad de realizar VMotion. Pienso que es una ventaja clave y que cambia mucho de tener un entorno con o sin ello. Sin ello, simplemente estas poniendo muchos huevos en una cesta, que algun dia puede romperse o puede necesitar pararse. Con ello, tienes la posibilidad de mover esos huevos para arreglar la cesta.

Para realizar VMotion, además de tener un almacenamiento centralizado SAN/NAS, es necesario que las CPUs de los dos hosts entre los que se va a realizar VMotion sean de la misma familia o compatibles.
Cuando se nos da el caso de que entre los hosts no hay compatibilidad de CPUs podemos usar las mascaras personalizadas de CPU para conseguir realizar VMotion.
Tengo que decir que VMware no da soporte a esto y que no debe hacerse en produccion. También tengo que decir que nunca he visto que haya dado ningun problema y también lo he usado en produccion, asi que cada uno que vea.

Para crear una mascara (custom mask) para las VMs deberemos fijarnos en los valores de los registros de las CPUs de los servidores incompatibles y ver las diferencias para enmascararlas.

El primer paso es recolectar la informacion que necesitamos usando la genial herramienta VMotion Info de run-virtual.
Con ella podemos recabar toda la informacion de nuestra granja de servidores y ver cuales son incompatibles entre sí. Recomiendo activar la opcion "Con Debug" porque nos da los registros de las CPUs ya en binario y solo tenemos que fijarnos en eso:


Como se ve, hay varios procesadores IBMs(entre ellos compatibles) y tres CPUs diferentes de DELL(entre ellos compatibles).
Si intentamos realizar VMotion entre cualquier IBM y cualquier DELL nos dara un error de compatibilidad:

Como vemos, el error esta en el registro EAX del nivel 1. Para arreglarlo anotamos el valor del registro de los servidores incompatibles entre sí y vemos la mascara por defecto que tienen nuestras VMs (Edit Settings, Pestaña Options, Advanced, y en CPU Identification Mask pinchar en Advanced).


Como vemos en la leyenda, hay bits que directamente no interesan para nada (X), de hecho normalmente solo nos interesan los marcados con H, con R, con 0 con 1...

Veamos, tenemos:

Server1 Level1 EAX:   0000 0000 0000 0000 0000 0000 0000 0110 
Server2 Level1 EAX:   0000 0000 0000 0000 0000 0110 1111 0110
Standard CPU Mask Level1 EAX:  XXXX HHHH HHHH XXXX XXXX HHHH XXXX XXXX
Custom CPU Mask Level1 EAX:  ---- ---- ---- ---- ---- -00- ---- ---- 
Effective CPU Mask Level1 EAX:  XXXX HHHH HHHH XXXX XXXX H00H XXXX XXXX

Como podemos ver sólo nos interesa los bytes segundo, tercero y sexto(los demas llevan X asi que lo podemos dejar por defecto). En el caso del segundo y tercero byte, vemos que son iguales, luego no tenemos que hecer nada. En el caso del sexto vemos que los bits del medio son diferentes asi que los enmascaramos.

Ya solo nos queda probar a realizar VMotion, si hay algun otro registro que tocar, el error nos lo describirá(registro ECX, EBX, level 0, etc...)

Deberemos poner la mascara en cada VM con la que queramos realizar Vmotion.

Es importnate también darse un paseo por la web de IBM o Dell y ver que es lo que hemos podido enmascarar a la VM, para ver posibles efectos que pueda tener sobre ella. Yo hasta el momento no he tenido ningun problema. (ejemplo: http://www.intel.com/design/processor/applnots/241618.htm)

Cualquier comentario o correccion será bienvenido!

Consulta: Numero de VM por servidor o core

Rodrigo nos comenta:
Hola,

he estado leyendo tus artículos y me parecen muy útiles, y me parece que conoces bastante el tema, por lo que te hago una consulta que hace tiempo tengo, que es
¿Como saber o calcular el número de virtual machine que puedes instalar en un server?
La pregunta me parece bastante completa, pero debe existir algún tipo de calculo según Nº CPUs, RAM y otros datos.
Tu sabes que documentación o alguna forma de calcular esto?
Saludos

En primer lugar, muchas gracias por el comentario Rodrigo, es un aliciente muy grande que te resulten útiles los artículos.
La verdad es que, como te comenté, en este tema no existe una regla o formula que te diga: Puedes poner en tu servidor ESX "n" maquinas virtuales y te va a ir bien. Es algo muy relativo. A mi me gusta verlo por cores, porque hoy en día los servidores ya vienen con dos procesadores y dual core o quad core en la mayoría de los casos.

Los vendedores de servidores, sobretodo de blades (los cuales no me gustan para virtualizar dicho sea de paso), suelen mencionar que su hardware puede correr X maquinas virtuales, pero desde luego hay que cogerlo con pinzas, está claro que NO sale de un método científico, no tiene todos los fabricantes el mismo baremo y es algo comercial.

El numero de VMs soportado por un servidor depende de la carga que tenga cada una de las VMs (es algo muy relativo). Además, influyen factores como la RAM y el disco: Puedes quedarte sin disco o sin RAM antes de quedarte sin CPU en un servidor, de hecho esto ocurre frecuentemente.

He visto varios sitios que corren unas 30 VMs por cada servidor (8 cores), lo que da un ratio de 3,75 VMs/core, aunque muy probablemente se podría aumentar a 50Vms por cada server (8 cores) , que es un ratio de 6,25 VMs/core.

Este es el orden de magnitud: desde 4 hasta 8 VMs/core en servidores de aplicaciones normales.
Cuando hablamos de escritorios virtuales el numero aumenta algo, por lo que he visto, suelen andar por los 8 VDesktop/core, aunque seguro que hay gente que tiene 15! (En este caso la RAM puede ser nuestro limite de forma muy facil!)

Para que veas unos números según el preliminar de "2008 Purchasing Intentions Survey", el 61% corren menos de 10 VMs por servidor, el 33% corren de 10 a 25 VMs por servidor y un 5% corren mas de 25 VMs en un servidor. (Se supone un servidor con dos procesadores aunque no dicen el numero de cores por procesador).

Tal y como lo veo yo, la infraestructura virtual (de producción) debe estar cargada cerca del 75% (en RAM, CPU, Disco). Si se sube más de ahí, es mejor ir pensando en aprovisionar más servidor, memoria o disco, con los tiempos de entrega dará tiempo a que se pueda seguir trabajando y a que lleguen los materiales para mantenernos en dicho 75%.

Con DRS es muy fácil ver de un plumazo qué tal va la cosa, por ejemplo:


La imagen responde a un cluster de 9 servidores donde ahy todo tipo de servidores: Linux, Windows, Oracle, OAS, Apache-Tomcat, Webmail, Samba, PeopleSoft, Meta4, etc, etc. Puedes ver que hay 53 VMs en 9 servidores (con dos procesadores dual core), lo cual da un 1,5 VMs/core. Ya se ve que la infraestructura puede crecer, y así te lo dice el gráfico de utilización:


Cuatro de los nueve servidores se encuentra con un 15%(entre el 10 y el 20) de CPU(aprox.), dos de ellos con un 25%(entre 20 y 30) y otros dos con un 35%(entre 30 y 40). El ultimo tiene un 55%(entre 50 y 60) de uso de CPU. De media saldría un 26%. (Esto en el gráfico en dicho momento, que habría que ver si es como normalmente suele estar, para ello te puedes ayudar de las grafías de performance).
Con nuestros cálculos podríamos tener 3 veces (3*26 = 75%) las VMs que tenemos ahora, es decir 1,5 *3 = 4 VMs/core de media(algo bastante razonable, es decir 150 VMs(4VMs/core * 9 servidores * 4 cores/servidor) ).

En el gráfico de uso de GHz se puede ver como llega a los 28GHz en el punto mas alto, de los 89GHz que tenemos (un 30%, este dato es mas exacto y corrobora lo que nos indicaba antes el gráfico(26%)).


Ya ves que en este caso vamos mucho peor de RAM que de CPU: Fíjate en la gráfica(segundo dibujo), un 60% de RAM usado. Además, en este caso se está usando el 95% del disco disponible. Esto es lo que te comentaba antes, te puedes quedar sin disco antes que sin CPU.

Espero que esto te ayude!
Saludos,

Bluebear (Koala y Kodiak) Posible Cliente de Virtual Center de Linux

Muchos ya habreis oido hablar de ello, otros no. La compañia Bluebear, una startup de Washington, además de ofrecer servidores para virtualizar llamados Koala, está trabajando sobre una aplicacion multiplataforma (Windows, Mac OS y Linux) llamada Kodiak (es el nombre de un oso de Alaska) para gestionar nuestro imperio virtual (como ellos ponen: "Ruling your virtual empire!"). Se trata (se tratará pues de momento es beta y solo se puede probar bajo invitación) de una aplicacion de codigo abierto que sea capaz de manejar Vmware ESX, Citrix XenServer y MS Hyper-V. Por el momento empiezan dando soporte a VMware ESX, esto puede que supla la necesidad de tener un cliente de VMware en Linux(por fin), veremos qué tal es el producto, desde luego por los pantallazos tiene muy buena pinta!



Según lo que ellos mismo dicen:
Welcome to the next generation of unified systems management! Kodiak, from BlueBear, enables unprecedented visibility into and control over virtualized infrastructures, regardless of size or composition. As the industry's only application that's both hypervisor-agnostic and cross-platform, Kodiak sets a new standard in versatility, pushing virtualization out of the datacenter and catalyzing it's widespread adoption throughout the information technology landscape. BlueBear believes useful software should be available to anybody who needs it, and at no cost; hence Kodiak's price, totally free!

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!

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.

P2V de Linux

Aquí os dejo cómo realizar P2V de un Linux de forma rapida, que hay muchas formas, esta es una de ellas:

Software necesario:
Red Hat / Fedora Linux CD1 (culaquier version)
VMware Converter 3.x / 4.x

Convirtiendo el Servidor Fisico:

Convertir el servidor físico a VM usando el VMware Converter bootcd.

Limpiamos la VM:

Una vez realizada la conversión, hacemos "edit properties" y quitamos hardware innecesario.

• Hacemos un Snapshot antes de cambiar nada.
• Quitamos USB controllers, Serial ports, parallel ports, floppy drives
• Cambiamos la controladora de HD de Buslogic a LSI logic si es necesario:
• Configuramos la VM para arrancar desd el CD en la bios de la VM
• Conectamos en CD1 de Red Hat. Ponemos: Connected y Connect at Power on
• Iniciamos la VM con el Redhat CD1. (aceptamos el cambio de HD type a LSI logic)
• Seguimos el articulo de VMware KB para reconfigurar el hardware de la VM
  
• Y comprobamos que la VM se inicia correctamente despues de los cambios.
  

VMware Tools

• Nos ponemos en la Console de la VM. Selecionamos Install/Upgrade VMware tools del menu.
• Montamos el cdrom virtual con el comando (por ejemplo): #mount /dev/hda/ /media/cdrom
• Instalamos el rpm: rpm –i /media/cdrom/VMwareTools-xxxx.xxx.rpm (el xxx dependerá de la version del ESX y del linux)
• Corremos vmware-config-tools.pl y completamos la instalación.

Buscar Snapshots de VMs desde la Console

Pues nada, un comando que nos permite ver de forma rápida si en nuestro servidor ESX tenemos Snapshots y en qué VMs las tenemos.
Es algo muy tipico hacer un Snapshot y olvidarnoslo que lo tenemos, ocasionando perdida de rendimiento y a veces problemas muy graves.(Que se pueden solucionar usando el Converter)
Hay otras utilidades para verlo de forma más elegante (se llama SnapHunter y lo comenté aquí), pero esta es tan potente como directa:

# ls -Ral /vmfs/volumes/* | grep .vmsn

También podríamos usar:
# find /vmfs/volumes/ -iname "*-delta.vmdk"
Esto te puede encontrar Snapshots mal borrados además de los normales.

¿Alguien sabe alguna forma más?

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.