http://kurrin.blogspot.com/

Frases de niños

2009-12-19T19:40:00.001+01:00

Como muchos conocéis, existen un par de libros de Pablo Motos con frases de niños. El dinero recaudado va para inventigación de una enfermedad que afecta a niños. Os pongo el link.
Dicho esto, no me resisto a poner algna de ellas:

Alejandro, 2 años,
Un día le preguntó su padre: "Alejandro, ¿Como se llaman los Reyes Magos?". Y Alejandro contestó :"Queridos!"

Enrique, 7 años,
Enrique le preguntó un dia a su madre : Mama, cuando eras pequeña, ¿la Nintendo era de madera?

Manuel , 5 años,
Iba en el coche con sus padres y pasó un coche fúnebre lleno de flores, y dijo: Mira cuantas flores lelva ese coche, ¡Ahi debe ir la novia!

Manuel, 6 años:
Iba con su madre paseando por la calle y se cruzaron con una anciana muy bajita, vestida de negro. Al verla Manuel le dijo a su madre: "Mira, mama, una abuela recien nacida"

Anxo, 3 años:
Anxo fue de visita a casa de su bisabuela y ella le preguntó: Qué Anxo, ¿que te cuentas?. Y Anxo le respondió: Pues, ultimamente, solo mentiras.

Alex, 2 años
Estaba con su madre en el banco y ella estaba rellenando unos papeles. El cajero le preguntó a su madre el nombre y ella dijo : Inmaculada Torres Novalbos. Y entonces Alex, muy exaltado dijo : Que no, que tú te llamas mami!!!!

Nuevos Pasos

2009-11-08T18:19:00.003+01:00

Después de este silencio debido principalmente a la falta de tiempo y de haber publicitado ya suficientemente el libro de Josep en el anterior post ;-) , voy a ir dando los siguientes pasos para seguir escribiendo de vez en cuando. (por el momento me he puesto una meta poco exigente, a ver si la puedo cumplir). Gracias alos que me habiéis pedido que escriba, esto hace más facil sacar tiempo.

Como esta entrada va de primeros pasos, no me puedo resistir a poner un video de youtube que es espectacular. Son la gente de Boston Dynamics, que ya tienen una canal en youtube y se dedican a los robots, casi como se ven en las peliculas.

El ultimo que han sacado se basa en la forma de andar de un humano:

Y en este impresionante video aparece una especie de mula de carga, burro o similar(BigDog le llaman). Te entra una especie de sensación rara cuando ves un robot actuando de forma tan natural, como lo haria un caballo o una mula, cuando se resbala en el hielo.

Nuevo libro: Virtualización Corporativa con VMware

2009-06-14T22:28:00.002+02:00

Recientemente Josep Ros ha lanzado un libro titulado "Virtualización Corporativa con VMware" que se está convirtiendo en un documento que cualquiera que se quiera introducir de forma practica en el mundo de la virtualización debe leer, segun el propio prologo:

"En este libro podrás aprender paso a paso todos los conceptos y las técnicas para virtualizar una infraestructura, desde una Pyme, con Vmware Server, hasta una gran empresa con VMware Infraestructure 3.5. Este manual está especialmente indicado para aquellos administradores que se introducen en el mundo de la virtualización con una buena base de sistemas pero con pocos o nulos conocimientos en virtualización. El autor, Josep Ros, es un Consultor y Formador en TI. Es VCP-310 en VI3, y tiene más de 19 años de experiencia en el mundo de la Informática de Sistemas. Ha sido designado como VMware vExpert 2009 y comparte su conocimiento a través de su blog."

Enhorabuena Josep por este gran trabajo!!!

Google Revela el Hardware de su Servidor

2009-04-07T22:28:00.002+02:00

Tras un aépoca con mucho ajetreo y que además parece que va a durar, me dispongo a hablar por fin un poco.
Es una noticia que me ha llamado la atención: google habla sobre sus servidores.
Desde luego da una idea de cómo piensan a grnade escala (me recuerda cuando diseñaba placas PCBs (de circuitos) y nos estrujabamos el coco por poner una resistencia menos pues solo era 1 centimo menos pero multiplicado por un numero enorme de placas era mucho margen de beneficio...). Exactamente asi piensan ellos.

También me ha llamado la atención el hecho de que se fijen en la extraccion de aire. Es curioso porque con todas la peleas quehe tenido en CPDs al final ves que te dejas un paston en refrigerar cuando lo más barato, practico y fiable es sacar el aire caliente(extraccion) y meter aire del edificio (impulsion a 22º), ayudado claro con algo de refrigeracion.

Aqui va el texto: http://blogs.zdnet.com/gadgetreviews/?p=2936&tag=nl.e019

Google for the first time on Wednesday revealed the hardware at the core of its Internet operations at a conference about the increasingly prominent issue of data center efficiency, reports CNET’s Stephen Shankland.

Instead of buying hardware from companies such as Dell, Hewlett-Packard, IBM, or Sun Microsystems, Google designs and builds its own. (The company has hundreds of thousands of servers.)

Ben Jai, who designed many of Google’s servers, unveiled the server hardware. The first surprise: each server has its own 12-volt battery to supply power if there’s a problem with the main source of electricity.

Shankland writes:

Why is the battery approach significant? Money.

Typical data centers rely on large, centralized machines called uninterruptible power supplies (UPS)–essentially giant batteries that kick in when the main supply fails and before generators have time to kick in. Building the power supply into the server is cheaper and means costs are matched directly to the number of servers, Jai said.

“This is much cheaper than huge centralized UPS,” he said. “Therefore no wasted capacity.”

Efficiency is another financial factor. Large UPSs can reach 92 to 95 percent efficiency, meaning that a large amount of power is squandered. The server-mounted batteries do better, Jai said: “We were able to measure our actual usage to greater than 99.9 percent efficiency.”

Since 2005, Google’s data centers have been composed of standard shipping containers — each with 1,160 servers and a power consumption that can reach 250 kilowatts, the company said.

Google has been using the design since 2005 and now is in its sixth or seventh generation of design.

“It was our Manhattan Project,” Jai said of the design.

Energy efficiency, power distribution, cooling, and ensuring hot and cool air don’t intermingle are all on the top of Google’s list, the company said.

As for the actual unit, the server was 3.5 inches thick (2U) and had two processors, two hard drives, and eight memory slots mounted on a Gigabyte motherboard. Google uses x86 processors from both AMD and Intel. The battery design is used on its network equipment as well, Jai said in Shankland’s article.

What’s fascinating about all this is that Google operates servers on such an immense scale that every decision it must make in turn has a large affect (and potential cost/savings).

Take the power supply design, for example: Google’s designs supply only 12-volt power, with the necessary conversions taking place on the motherboard. That adds $1 or $2 to the cost of the motherboard, Shankland writes, “but it’s worth it not just because the power supply is cheaper, but because the power supply can be run closer to its peak capacity, which means it runs much more efficiently.” Google even pays attention to the greater efficiency of transmitting power over copper wires at 12 volts compared to 5 volts, Shankland writes.

That kind of attention can translate to big savings in power or cost — or both.

¿Podrá soportar España 4.000.000 de bajas de clientes de banda ancha?

2009-02-12T23:31:00.003+01:00

Siguendo la iniciativa de muchas personas que ya han publicado este texto:

Cerca de cuatro millones de ciudadanos no pueden acceder a la banda ancha en España en función de su sitio de residencia; a este indicador negativo para el desarrollo de la Sociedad de la Información en España, se le podrían sumar bajas masivas de clientes del Adsl más lento y caro de Europa.

Las entidades representativas de la comunidad internauta, los profesionales y los consumidores informáticos en España estiman en cuatro millones la cifra de clientes de banda ancha -Adsl y cable-modem- que podrían darse de baja, si finalmente se confirma el acuerdo que RedTel las sociedades de gestión de los derechos de autor, abanderadas por la Sgae, para que en España se dé tres avisos antes de desconectar o ralentizar la conexión a Internet por usar redes P2P. A la disminución de ingresos se sumarían las posibles indemnizaciones que podrían derivarse por incumplimiento de contrato de las operadoras y las sanciones aplicables en base a los artículos 8 ("Restricciones a la prestación de servicios y procedimiento de cooperación intracomunitario") y 11 ("Deber de colaboración de los prestadores de servicios de intermediación") de la Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de la Información y de Comercio Electrónico, modificado por la Ley 56/2007, de 28 de diciembre, de Medidas de Impulso de la Sociedad de la Información.

Mientras las operadoras de telecomunicaciones tratan de sortear la crisis, las sociedades de gestión de los derechos de autor, intentan conseguir prebendas para las empresas productoras de contenidos tratando de convencer a todo el mundo de que el intercambio de archivos entre particulares por Internet es un acto delictivo y que supone fuertes pérdidas al sector de entretenimiento.

Sin embargo tanto la fiscalía como las sentencias dictadas establecen que el intercambio de archivos con copyright restrictivo por redes P2P no es un delito y no es punible de ninguna forma cuando se trata de archivos públicos o bajo licencias copyleft (la mayoría de los casos)

Las propias entidades de gestión de derechos de autor han reconocido en el "Informe de la industria de contenidos en España", publicado por ASIMELEC, que no hay una bajada de ingresos en el sector y que solo la música tiene un retroceso en la venta a través del canal tradicional (aunque no se informa del aumento de ingresos por, entre otros, actuaciones en directo, descargas y publicidad)

Lo cierto es que las negociaciones que se están llevando a cabo bajo el auspicio del Ministerio de Cultura, pueden suponer que algunas de las empresas más solventes y con mayor capacidad tecnológica de España empiecen a perder clientes a marchas forzadas. Lo que repercutirá en su cuenta de resultados y en su capacidad de mantener el empleo.

Pero lo más grave es que un acuerdo de esta naturaleza atenta contra la libre competencia, frena en seco el acceso a la Sociedad de la Información en España menoscabando los derechos civiles de los ciudadanos y alejando aún más el derecho constitucional de acceso a la cultura y al conocimiento.

Firmado: Kurrin y 6870 firmas mas (por el momento). Pon la tuya publicando el texto en tu blog.

Como añadir un disco virtual (.vmdk) a un Linux en caliente (sin reboot)

2009-02-06T19:46:00.006+01:00

Muchas veces he añadido un disco a una maquina virtual(VM) Linux y he reiniciado para que lo reconociese. Pues, bien, tanto Linux como Windows son capaces de reconocerlo en caliente. En el caso de Windows es algo ya muy conocido (Administrador de discos, Refrescar y formatear...).

En el caso de Linux nos puede venir bien en los momentos en los que no podemos parar dicha VM ya sea por su criticidad o precisamente porque tenemos problemas en algún disco y necesitamos hacer backup en otro que acabamos de añadir.

(Este prodecimiento es para Red Hat 4, pero la mayoría de las distros funcionan de similar manera. De hecho no difiere del procedimiento de añadir un disco en caliente (que no formase un RAID) a un Linux Físico. Además es posible que otras distros lo faciliten):

Lo primero es añadir el disco desde el VIC o como normalmente lo hagamos.
Seguidamente podemos mirar /proc/scsi/scsi y ver los devices de nuestra VM: Los datos importantes son los que nos pone en la primera linea de cada elemento que aparece.
Por ejemplo: Host: scsi0 Channel: 00 Id: 00 Lun: 00

El primer numero es el numero de la controladora scsi. Ej: scsi0
El segundo es el canal
El tercero es ID del disco SCSI.
Y finalmente esta la LUN. (Sirve para fibra o iSCSI...)

Cuando hemos añadido con el VIC un disco a nuestro Linux, nos debemos fijar en el Virtual SCSI node (ej:SCSI 0:0 es la controladora 0 ID 0, SCSI 0:1 es la controladora 0 ID 1, etc,etc ) y en la controladora SCSI que es. Con esto ya tenemos los dos primeros numeros.

El numero que suele cambiar al añadir un disco es el ID del disco SCSI (1,2,3,4,5,6...) porque generalmente nuestras VMs tienen una sola controladora SCSI.

Una vez que tenemos el dato del disco que queremos que "vea", En la VM hay que hacer:

echo "scsi add-single-device" 0 0 1 0 > /proc/scsi/scsi

(Esto corresponde a SCSI0, Cahnnel=0, ID=1,LUN=0, que es lo típico cuando añades un segundo disco. Con esto le decimos al S.O. que reconozca el disco y lo ponga a sus revoluciones preparado para usarse, aunque los discos virtuales no giran...)

El proceso para quitar un disco en caliente (mirando que no tenga ningún proceso accediendo, claro), seria con el comando:

echo "scsi remove-single-device" 0 0 1 0 > /proc/scsi/scsi

Excelente post de esxtop en las communities de VMware

2009-01-08T19:51:00.002+01:00

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

Resumen de Networking en VI3

2008-12-30T11:52:00.000+01:00

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

2008-12-19T17:11:00.003+01:00

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

2008-12-12T17:57:00.008+01:00

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

2008-12-06T11:20:00.000+01:00

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

2008-12-05T11:13:00.004+01:00

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

2008-11-18T10:32:00.001+01:00

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!!

2008-11-13T18:43:00.000+01:00

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)

2008-11-11T07:09:00.000+01:00

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

2008-11-05T16:00:00.003+01:00

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.

2008-10-26T18:25:00.000+01:00

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

2008-10-24T12:21:00.001+02:00

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

2008-10-17T13:59:00.003+02:00

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

2008-10-17T01:55:00.000+02:00

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)

2008-10-16T23:50:00.001+02:00

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.

2008-10-16T23:20:00.000+02:00

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)

2008-10-07T13:09:00.000+02:00

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

2008-10-01T22:46:00.001+02:00

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)

2008-09-23T14:07:00.002+02:00

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

2008-09-23T13:34:00.001+02:00

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

2008-09-16T12:33:00.004+02:00

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

2008-09-09T13:04:00.002+02:00

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

2008-09-01T12:39:00.001+02:00

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

2008-08-28T10:59:00.000+02:00

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

2008-08-02T12:47:00.002+02:00

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

2008-07-29T13:15:00.000+02:00

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

2008-07-27T15:32:00.000+02:00

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:

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

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

2008-07-24T13:24:00.003+02:00

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

2008-07-15T11:59:00.001+02:00

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

2008-07-11T09:34:00.002+02:00

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

2008-07-09T15:55:00.000+02:00

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

2008-07-05T16:17:00.001+02:00

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

2008-07-03T10:17:00.004+02:00

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

2008-07-01T17:03:00.000+02:00

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

2008-06-23T18:09:00.001+02:00

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

2008-06-19T16:01:00.003+02:00

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?

2008-06-18T21:38:00.000+02:00

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

2008-06-18T17:13:00.000+02:00

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

2008-06-17T10:44:00.005+02:00

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

2008-06-16T18:12:00.003+02:00

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

2008-06-16T17:44:00.000+02:00

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:

Pensamiento: Virtualizacion del I/O. InfiniBand y 10Gbit Ethernet

2008-06-12T18:04:00.001+02:00

La Virtualizacion del I/O es una de las nuevas formas de virtualización, junto con la Virtualizacion de Aplicaciones o la Virtualizacion de Servicios, que están emergiendo de la meteorica expansion que vive la Virtualización de Servidores.

Por el momento es un mercado muy nuevo en el que hay muy pocas experiencias en escenarios del mundo real. A día de hoy, hay unas pocas compañías que comercialicen una solución verdadera de Virtualización del I/O proporcionando servicios completos de virtualizacion del IO, a saber: 3Leaf Systems, Xsigo Systems (dos compañias muy jovenes), Cisco Systems y Brocade (con sus standards).
(Alguna más habra salido que no conozca)

¿Que es exactamente la Virtualización del I/O? ¿En que nos puede beneficiar?
La Virtualización del I/O se entinde como una abstraccion de los protocolos de tranporte para realizar conexiones del nivel fisico. En palabras claras, es usar una tecnologia que agrupe todos los canutos infrautilizados (ya sea FC o Ethernet) en menos canutos más utilizados, mezclando los protocolos más tipicos.

Por el momento hay dos tendencias tecnologicas para llevar a cabo esta mision:
Algunos vendedores utilizan la tecnologia de interconexion InfiniBand como la capa de transporte fisico: esto les permite usar la extremadamente baja latencia de InfiniBand para transportar TCP/IP, FC y otros protocolos tradicionales. Como desventaja, hay que mencionar que está tecnología requiere nuevo cableado y algun switch(Aunque puede hacerse brige como luego comentaré). Esto puede ser un impedimento en entornos que han invertido dinero y know-how de arquitecturas Ethernet y FC.

Por el otro lado, otros vendedores como, apuestan por futuros standards como 10Gb Ethernet o extensiones a la 10Gb Ethernet como puede ser Data Center Ethernet (DCE), que es un standard IEEE en progreso que nos proveerá de una gran eficiencia, menor latencia y un comportamiento sin pérdidas y sin errores en una red Ethernet. En el proximo post espero colgar unos resultados sobre 10Gbit Ethernet com VMware.

Como todas las soluciones que existen, nacen para hacer frente a un problema:
Con la llegada de la Virtualización de los Servidores en nuestros CPDs han crecido el numero de puertos usados y la infrastructura de red (ya sea de datos o almacenemiento) se ha complicado.
Hoy en día, cada servidor destinado a la virtualizacion de servidores ocupa como poco 6-8 tomas. Por ejemplo 6 tarjetas ethernet: 2 para Service Console, 2 para VMotion y 2 para trafico de VMs y a las que hay que sumar 2 para iSCSI o 2 para Fiber Channel (o ambas).
En algunas empresas se puede llegar hasta 20 interfaces fisicas ocupadas por servidor, curiosamente estas empresas son las más grandes, donde las politicas son más estrictas respecto a la segmentación de las redes.
Hay que tener en cuenta que, en mi opinión, llegar a un numero mayor de 10 en las interfaces que necesita cada servidor de virtualización no es debido a una limitacion tecnica puesto que existen tecnologías (como las VLAN y VMware Port Groups) que permiten segmentar logicamente las redes mencionadas arriba, realmente se trata de un tema de segmentación mas que de un tema de rendimiento de I/O.

Como beneficios de esta virtualización del IO están mayormente la flexibilidad, la utilización y el aprovisionamiento más rapido. Por ejemplo, el numero de conexiones requeridas por servidor bajarían de 6-8 a 2 si usasemos conectores InfiniBand reduciendo el coste y la complejidad. Simplemente tendremos que fijar un nivel de virtualización (como en los servidores) que hará que nuestros canutos de InfiniBand o 10GbEthernet estén más o menos sobreutilizados.

La mayoría de los defensores de la tecnología 10Gb Ethernet se basan en que es 10 veces más rapida y eso la hace más potente y menos compleja. Como ya he dicho, en mi opinion, no es un tema de rendimiento ni de ancho de banda (que es importante, claro), si no que es un tema de segmentación fisica en la mayoria de los casos. Si lo que nos ofrece esta tecnologia (10Gbit Eth) es simplemente mayor ancho de banda, me veo con el mismo problema en dos años: 6-8 interfaces fisicas de 10Gbps por cada servidor de virtualizacion.
Veremos pues a ver que nos trae el standard Data Center Ethernet (DCE)

InfiniBand, por su parte, me parece que tiene un mayor atractivo para proporcionar un valor añadido que la propia fuerza bruta de 10Gb Ethernet. En primer lugar, está el hecho positivo de que VMware soporta InfiniBand en VI3.5 y el segundo aspecto a tener en cuenta es que InfiniBand se puede ser "bridged" en la arquitectura de I/O del DataCenter existente (Ethernet , FC), proporcionando una solución intermedia que permita usar esta tecnología en el Datacenter sin tener que desmantelar toda nuestra arquitectura.

Este escenario es posible gracias a la existencia de los bridges InfiniBand que conectan la red InfiniBand(IB) con la red normal:

Basicamente, instalando una HBA de InfiniBand en cada servidor podemos crear un numero de "puertos virtuales" que serán mapeados en los switches IB y en los bridges IB para conectarlos a la infrastructura ethernet existente. Este tipo de tecnología también permite usar una mezcla de virtual IB Ethernet adapters y VMware port Groups.

De esta forma se nos proporciona lo que queremos:

Algo tranparente y que cumpla con los requerimientos de nuestras politicas internas de segmentacion.
Continuar usando los hosts VI3 como si tuvieran sus 6 u 8 interfaces fisicas.
Rebajar dichas 6 u 8 interfaces por servidor de virtualización.

Desde un punto de vista puramente teorico, me parace que InfiniBand tiene más que decir que 10Gbit Ethernet, sobre todo en entornos granades de servidores VI3. Habiendo dicho esto, todos sabemos y el tiempo nos ha enseñado que no son siempre las mejores soluciones y las mejores tecnologías las que se imponen en el mercado. asi, pues puede que en unos años haya mayoritariamente InfiniBand, 10Gbit ethernet o una mezcla de ambas. Como ocurre con iSCSI y FC.

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

2008-06-11T23:28:00.000+02:00

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.

Herramientas para VMware ESX y Virtual Center

2008-06-11T22:54:00.002+02:00

Aqui os dejo tres herramientas para vuestra infraestructura virtual que pueden resultar muy útiles.
Las herramietas son de Mightycare Solutions GmbH y ya fueron sacadas hace tiempo pero creo que merece la pena tenerlas las tres agrupadas y comentadas:

Snapshots Version 1.5
Es un pequeño script con el que eres capaz de chequear si las VMs de un ESX tienen snapshots o no. Se ejecuta con el cron de linux y puede ser corrido diariamente, semanalmente, etc... el script nos devuelve una información detallada de las Vms con snapshots y su almacenamiento.

VMStatus:

VMStatus se conecta a un Virtual Center 2.5 y muestra una lista de las VMs con la siguente información:

Virtual Machine Operating System
VM Status
VM Tools
Time Synchronization

Con un doble click en una VM se puede cambiar la configuracón de "time synchronization".

Storageview 1.0.5:
MCS Storageview 1.0.5 muestra las particiones logicas de todas las VMs en un servidor ESX 3.x o Virtual Center 2.x. Nos muestra cuantos GB podemos ahorrarnos decrementando las particiones etc, etc...

Parte III: ¿Como funciona DRS de VMware?

2008-06-06T13:05:00.002+02:00

Tips:

Primero vigilar el DRS y ver como funciona. Cuando uno se siente seguro y pasado un periodo de aprendizaje, usar Fully Automated para la politica general y para las VMs criticas configurar a nivel de VM la politica de Manual o Partilly Automated.(Vmware DRS, Virtual Machine Options).
Usar DRS y Pools de Recursos para un numero de hosts ESX, NO en CADA host ESX.
DRS es proactivo, actúa para balancear y no provoca down time. No confundir con VMware HA que es reactivo: actúa cuando se ha caido un host y si tiene down time de las VMs.
El maximo numero de hosts en Virtual Center 2.0 es de 16 para DRS y HA
Se puede usar Resource Pools anidados y Fixed Reservations para el parent resource pool. Aunque mejor usar shares: se adaptan dinamicamente y los limites estáticos pueden volverse inmanejables.
Cuando DRS hace recomendaciones con muchas estrellas: Hadle caso
Pon las maquinas que se "hablan" mucho juntas (mismo Host, vSwitch y Portgroup) y usa reglas de afinidad para ello: conseguirar que su red vaya a velocidad de RAM.

Monitorizacion:
La monitorizacion del Cluster se puede realizar a traves del propio Virtual Center.

Un cluster sin ningun color en particular nos indica que todo esta correctamente.
Un cluster de color amarillo(Overcommited or Host down) indica que algun requerimiento de recursos no esta siendo satisfecho por el cluster.(Solucion: aumentar recursos o decrementar reservations)
Un cluster de color rojo nos indica que el cluster esta inconsistente o es invalido
(Cambios en resource pools a traves del VIC directo contra un host en lugar de hacerlo por el VCenter, o capacity failover)

Fallos Comunes:
En general DRS funciona bastante bien sin que nos dé sobresaltos.

Errores de DRS

No se puede encender una VM aunque tenga de reservation menos que la capacidad sin reservar del resource pool.

Causa: El host tiene que tener suficiente Aggregate unreserved capacity y Per-core capacity.
Solucion: Establecer en los hosts esta opcion de configuracion Cpu/VMAdmitCheckPerVcpuMin to 0 (OJO: not recommended)

Errores de VMotion:

Relacion de cluster entre VMs (MSCS)

La VM tiene afinidad a una CPU fisica:

Solución: Quitar la VM del cluster, quitar la afinidad y volver a meter al cluster DRS.

La VM tiene conectado el CD-ROM / floppy

Alertas de VMotion:

La VM esta configurada a un virtual switch interno pero no esta conectada a él.
La VM está configurada para acceder al CD-ROM/floppy pero NO está conectada a él.

Link Parte I:
Parte I: ¿Como funciona DRS de VMware?

Link Parte II:
Parte II: ¿Como funciona DRS de VMware?

Dell: ESXi y Citrix XenServer por 99€

2008-06-06T13:00:00.002+02:00

Bueno, esta es una de las noticias que tenia en el tintero:
Dell anunció el 7 de Mayo sus nuevos servidores para la virtualización: PowerEdge R805 (dos zocalos) y R905 (cuatro zócalos). Posteriromente comentan que lo extenderá a otrs servidores, incluso de pedestal.

Los servidores viene con la configuración: AMD Quad-Core, 16 ranuras DIMM, NIC integrada de puertos cuádruple con TOE, hasta 292GB de almacenamiento local y la opción de pre-instalación en una SD de hypervisors por 99€: VMware ESXi y Citrix XenServer Embedded Express (XenServer Dell Express Edition).

Ver dibujo:

Más interesante que la noticia en sí, me parece la ayuda que nos brinda Dell para la compra. En ella se puede ver qué es lo que opina (oficialmente) Dell sobre el estado actual del mundillo de la virtualización:

A ver cuando IBM, HP y SUN se lanzan a ello.

Parte II: ¿Como funciona DRS de VMware?

2008-06-05T13:53:00.002+02:00

Arquitectura:

DRS tiene dos niveles de planficador (Scheduling levels):

Local: En el host ESX. Determina que procesador ejecutará la VM.
Global: En el Cluster. Determina que host ejecutara la VM.

El modulo de DRS se ejecuta en cada host ESX y es evocado por el VCenter Server (vpxd), su evocacion puede ser periodica (cada 5 minutos) o por evento (añadir un host, retirada de uno...)

Como hemos comentado el output del algoritmo de DRS son las recomendaciones. Dichas recomendaciones pueden tener más o menos impacto en la reduccion del desequilibrio en el cluster, por ello a cada recomendacion se le da un rating: Las estrellas. Segun dicho rating el sistema determinara si usar o no Vmotion para mover la VM en cuestion. El hecho de que se aplique o no directamente determinada recomendacion dependerá del numero de estrellas y el modo de Umbral de Migracion(Migration Threshold) en el que estemos. Dicho umbral establece qué migraciones se llevaran a cabo automaticamente, desde el Mode Conservative (que solo aplica las que tiene 5 estrellas), al Agressive, que aplica todo lo que tenga una o mas estrellas.

Los requerimientos para formar un Cluster DRS son como los de Vmotion, requiriendo storage compartido y las etiquetas de las redes consistentes en todos los hosts (son case sentitive!!!!).

¿Que ocurre si quitamos un host del Cluster?
Si tenemos Manual o Partially Automated nos mostrará sus recomendaciones, si tenemos configurado Fully Automated las VMs seran migradas a otros hosts.

¿Que ocurre si ponemos un host en Maintenance Mode?
Las operaciones en dicho host se restringen automaticamente: No se pueden encender nuevas VMs dicho host y no se pueden migrar VMs a dicho host.
El administrador debera apagar las VMs o migrarlas a otras (se recomendara) y posteriormente apagar el host.
(El host marcado como en mantenimiento no sera tenido en cuenta para HA)

¿Qué ocurre si se cae el Virtual Center Server?
Los hosts seguiran corriendo usando los recursos disponibles pero no habra recomendaciones para optimización de recursos.

Link a la Parte I:
Parte I: ¿Como funciona DRS de VMware?

Link a la Parte III:
Parte III: ¿Como funciona DRS de VMware?

Soporte para productos Microsoft en maquinas virtuales de VMware

2008-06-03T13:20:00.001+02:00

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.

Como crear un Disco Duro para acceso compartido en el mismo Host ESX

2008-06-02T23:20:00.005+02:00

En muchas ocasiones nos puede venir muy bien que dos VMs compartan el acceso a un disco duro simultaneamente. Esta es la forma tipica de crear un cluster MSCS o un cluster GFS u OCFS o Linux HA, etc, etc.

Lo que se busca es que dichas VMs puedan acceder al mismo tiempo al disco, poniendo una capa por encima que arbitre (generalmente mediante locks) el acceso en lectura/escritura. Lo normal, es que usemos Raw Device Mapping y que dichas VM estén en diferentes Hosts ESX pero hay muchas veces que por diversas razones (no tenemos una SAN, estamos haciendo una maqueta de pruebas, etc,etc) necesitamos poner las VMs que conforman dicho cluster en el mismo Host ESX.

En estos casos, para que sea posible compartir un disco duro (un "virtual disk"), es necesario especificar en el driver SCSI de las máquinas virtuales en las cuales el disco va a ser compartido que su Bus SCSI va a ser compartido:

Una vez hecho esto, tendremos que crear el disco que va a ser compartido como "thick".

El comando para hacerlo es:

vmkfstools -c 10g ruta_del_disco_duro_a_crear -d thick

Una vez creado el disco, lo añadimos a las máquinas virtuales que lo tengan que utilizar a través de "Add Hard Drive", "Use an existing virtual disk". Lo normal es crear con el comando anteriror el vmdk que va a ser compartido en el primer nodo del cluster (es decir en el mismo direcorio que el vmx del primer nodo) y en los nodos simplemente añadir el disco usando Use an existing virtual disk y seleccionando el directorio donde esta el vmdk a compartir.

¿Porqué debemos crear el Virtual Disk como thick?
Esto ocurre porque, al tratarse de un disco que va a ser compartido, los nodos pueden estar escribiendo simultáneamente en posiciones del disco muy diferentes, por ejemplo uno podria escribir al principio mientras que otro podria escribir al final, por ello es necesario reservar y ocupar todo el espacio que ocupa el disco ya desde su creación.

Parte I: ¿Como funciona DRS de VMware?

2008-06-02T17:40:00.002+02:00

Despues de completar el post de ¿Cómo funciona VMware HA?, me permito continuar con la saga. La documentacion técnica de VMware sobre estos dos temas que se usan ampliamante en produccion me parece muy limitada, por eso veo necesario hacer este pequeño compendio de información para tener a mano.

DRS quiere decir Distributed Resource Scheduler y es quien se ocupa de balancear la carga que tienen los Host ESX de un cluster, mejorando el uso de los recursos y pools de recursos en un cluster. Cuando decimos carga nos referimos a los parametros de CPU y memoria, no tiene en cuenta el uso de I/O ni de disco ni de red, ni otros overheads que también influyen en la capacidad de nuestros host. El algoritmo de DRS tiene como entrada la informacion de uso de los recursos tanto de las VMs como de los Hosts y como salida las recomendaciones de movimientos de las VMs de un host origen a otro destino, es decir el emplazamiento de las VMs.
DRS acepta tres modos de funcionamiento: Manual, Partial o Full Automated Control y dependiendo del modo elegido el emplazamiento de las VMs se hará de forma más o menos automatica.

Las recomendaciones (output del algoritmo DRS) se basan principalmente en :

Asegurar las politicas de recursos de forma ajustada:

Reservation: Garantia de recursos (al menos X)

Limits: Limite superiror(No mas de X)

Shares: Prioridad relativa (si el sistema esta overcommited)

Balancear carga de las VMs:

Balanceo de la media de CPU y memoria

Host en maintenance mode.

Restricciones de emplazamiento:

Affinity/Anti-affinity rules (x ej Controladores de dominio en diferentes hosts o servidor de aplicaciones y base de datos juntos para aumentar el rendimiento(al no ir por red fisica...))
Vmotion Compatibility (Tipo de CPU, LAN, conectividad SAN)

Etapas en DRS:

Emplazamiento Inicial:
Cuando encendemos por primera vez una VM en un cluster DRS aporta una lista priorizada de los host que pueden ejecutarla. En el modo Manual, DRS nos muestra su recomendacion y el administrador elige, en cambio en los modos Partially y Full Automated el administrador no elige, simplemente la emplaza en el primer host de su lista.

Operaciones en ejecucion:
Durante la operativa normal las VMs estan corrindo cada una en su host. Las variaciones de CPU, memoria (factores como se ha comentado arriba), hacen que DRS nos haga sus recomendaciones.
En el modo Manual y el Partailly Automated, el DRS nos hace recomendaciones y administrador las acepta o no. En Full Automated DRS decide él solito.

Link Parte II:
Parte II: ¿Como funciona DRS de VMware?

Link a la Parte III:
Parte III: ¿Como funciona DRS de VMware?

Herramienta útil: Mapas de Virtual Center.

2008-05-28T18:12:00.000+02:00

Una herramienta que me parece muy útil y que me da la impresión que no se usa habitualmente es la capacidad de VI3 de hacer mapas de nuestra infraestructura en un par de clicks.
La pestaña de maps se situa a la derecha superior del GUI del Virtual Center. En dicha pantalla podemos seleccionar las relaciones que queremos que aparezcan: VM to Datastore, VM to Host, etc, etc.

En mi opnión lo más practico es deseleccionar todas menos una y observar dicha relacion. Esto nos da una vista de pájaro sobre nuestra infraestructura y de hecho me ha permitido ver algún error o cuestión a tener en cuenta, todo esto claro, conociendo el entorno y qué hace cada VM etc, etc...
(Tambien se puede Exportar el mapa que se está viendo como jpg, etc, en el menu del VC, File, Export...).

VM to Datastore:
Por ejemplo, en esta imagen vemos la relacion VM to Datastore, es decir, en qué datastore está cada VM.
Esta imagen nos permite ver si alguna VM está en los discos locales de un Host o estan en la SAN o si algunos de sus VMDKs están en diferentes datastores (por ej por falta de espacio, por tener montada una iso). Esta información es muy util para tener en cuenta qué maquinas podemos hacer VMotion y cuales no, cómo de dispersos tenemos los VMDKs y preguntarnos porqué...

En la imagen se aprecia que hay datastores bastantes balanceados con cuatro o cinco VMs y alguno con una. Lo normal es tener 15 VMs por datastore(receta personal), lo que significa que o todavia hay espacio en dichos datastores o se deberian hacer más grandes... También vemos algunas VMs alojadas en discos locales lo que imposibilita el VMotion.

VM to host:
Este mapa nos expresa en qué Host se está ejecutando cada VM. Con ello podemos ver si está balanceado, si hay alguno muy saturado, etc...

En la imagen vemos que cada Host tiene unas cinco o seis VMs. Con ello podemos ver que se podría seguir creciendo más de un 100% en este entorno (suponiendo dos procesadores dual core por Host). Además vemos que el DRS actúa correctamente y está balanceando bien. En el host que sólo tiene tres VMs podemos sospechar que será porque alguna de dichas VMs consume muchos recursos...

Host to Datastore:
Nos muestra qué Dataestores ven cada Host. En la imagen se ve que todos los Host ven todos los Datastores, muy logico en una instalación con un cluster DRS/HA.

Host to Network:
Este me parece uno de los maps mas utiles de todos. Nos permite ver de un plumazo qué redes están cofiguradas en cada Hosts y si hay redes que no se usan etc...

En la imgen vemos que todos los Host tienen todas las redes (es lo logico para Vmotion, usar a destajo y sin miedo VLAN Tags). Vemos tambien que hay un host que tiene una red de más: probablemente es un error del administrador y habria que revisarlo.

Vm to Network:
Por último, este mapa nos da una idea de qué redes usan nuestras VMs y de si hay redes sin usar o Vm sin red...

En este caso vemos que se usan principalmente dos redes, que cuatro VMs tienen redes especiales y que hay otras cuatro redes sin asignar a ninguna VM.

VMKnoppix: Distribucion Linux Live para Virtualización

2008-05-28T17:49:00.007+02:00

Han sacado una nueva release de VMKnoppix (antes llamada Xenoppix) una distribución Linux que lleva preparadas la mayoría de soluciones de virtualización open-source: Xen, KVM, VirtualBox, QEMU and KQEMU, UserModeLinux.
Os la podeis bajar aqui, está basada en la distribución Knoppix

Ventajas de usarla

Es live, lo que significa que no se instala nada en el disco duro y puedes probar estas soluciones de virtualización.
No es necesario bajarte rpms o compilar nada, todo está listo y perfecto para usarse.
En minutos puedes estar haciendo experimentos con un montón de soluciones de virtualización.

¿Cómo se usa?
Primero se descarga y se graba en un CD. Cuando se arranca el ordenador desde el CD-ROM el propio menú nos dará opciones para elegir el kernel con el que queremos arrancar, con soporte para Xen, etc...
Si tenemos alguna duda aquí está el manual.

Otros links:

vscsiStats: Disk I/O Workload Characterization in VMware ESX

2008-05-27T11:55:00.007+02:00

La herramienta vscsiStats nos permite medir y caracterizar la carga de I/O a nivel del adaptador de virtual SCSI de una VM. Esta utilisima informacion nos permite crear histogramas y graficos de los diversos valores que podemos medir y asi poder realizar el tuning de los discos para aumentar su performance u optimizar diversos valores del RAID etc, etc...

Está en ESX desde antes de la version 3.5 pero es ahora en la 3.5 cuando se le ha llenado de utilidad. Su ruta es : /usr/lib/vmware/bin/vscsiStats y os recomiendo que veais su ayuda.

Funcionamiento:
Simplemente tenemos que iniciar la monitorización con vscsiStats -s y posteriormente con proporcionarle el World Group ID de la Vm y el Virtual Disk Handle ID ya podremos obtener informacion sobre dicho disco a nivel virtual SCSI, tanto en escrituas como lecturas.
(Ejemplo de uso: root@esx1 root# /usr/lib/vmware/bin/vscsiStats -i 8277 -w 1382 -p ioLength).
Finalmente tendremos que parar la monitorizacion vscsiStats -x.

Entre los valores que le podemos pedir estan:

ioLength: Tamaño del I/O, puede indicar problemas del alignement de disco si hay valores como 8191 en lugar de 8192.... Los VMDKs suelen estar optimizados a 4kB.
seekDistance: Distancia entre busquedas seguidas
outstandingIOs: Indica el nivel de paralelismo
latency: Latencia
interarrival: Tiempo entre I/Os

El resultado será un histograma (ponemos los puntos de medida en tramos y dibujamos su frecuencia relativa).

Os pongo un ejemplo sacado del documento original, (el cual no dudeis en leer si quereis profundizar en el tema). Se trata de una comparación de una VM con XP y otra con Vista: En copias de ficheros grandes, Vista utiliza grandes I/Os(1MB) asi que aunque su latencia es mayor, el numero de comandos es mucho menor y el I/O es mucho más secuencial que el XP.

Top 10: Lecturas sobre VirtualCenter

2008-05-26T09:09:00.002+02:00

Eric Siebert publica en Virtual Strategy Magazine un conjunto de diez lecturas para que profundicemos en el conocimiento del Virtual Center. En estos diez puntos Eric nos detalla una colección de presentaciones de VMWorld, alguna Tech Note de VMware y white papers varios que cubren todo lo que se necesita saber sobre la Base de Datos, ventajas y desventajas de correr VC en una VM, roles, plantillas de permisos y como configurarlo correctamente.

Aqui van:

Bulletproof VirtualCenter
A VMworld 2007 presentation on properly configuring and protecting VirtualCenter so it has high availability.
http://www.vmworld.com/vmworld/mylearn?classID=11017

VirtualCenter Database Maintenance: SQL Server
A white paper from VMware on how to maintain the VirtualCenter database when using SQL Server.
http://www.vmware.com/files/pdf/vc_microsoft_sql_server.pdf

Running VirtualCenter in a Virtual Machine
A white paper from VMware discussing the advantages and limitations of running VirtualCenter as a VM.
http://www.vmware.com/pdf/vi3_vc_in_vm.pdf

VirtualCenter Database Performance for Microsoft SQL Server 2005
A white paper from VMware on performance statistic collections and there effect on the VirtualCenter database.
http://www.vmware.com/files/pdf/vc_database_performance.pdf

VirtualCenter 2 Diagnostics
A VMworld 2006 presentation on troubleshooting problems with VirtualCenter.
http://download3.vmware.com/vmworld/2006/tac4096.pdf

Managing Vmware VirtualCenter Roles & Permissions
A white paper from VMware on configuring roles and permissions in VirtualCenter.
http://www.vmware.com/pdf/vi3_vc_roles.pdf

VirtualCenter 2.0 The Technical Insights
A VMware TSX 2007 presentation on the technical architecture of VirtualCenter.
http://www.vmware-tsx.com/download.php?asset_id=52

Template Usage and Best Practices
A white paper from VMware on creating, managing and using templates to deploy virtual machines.
http://www.vmware.com/pdf/vc_2_templates_usage_best_practices_wp.pdf

Replacing VirtualCenter Server Certificates
A technote from VMware on replacing the default certificates in VirtualCenter.
http://www.vmware.com/pdf/vi_vcserver_certificates.pdf

VirtualCenter Technical Best Practices
A document from VMware with technical details on VirtualCenter and vMotion.
http://www.vmware.com/pdf/vc_technical_best.pdf

Xtravirt Virtual SAN (XVS) Appliance

2008-05-22T11:05:00.004+02:00

Los genios de Xtravirt (de los que comente su producto VISBU) acaban de sacar una de las cosas que es de obligada prueba. Se trata de un appliance que hace de SAN de iSCSI y lo mejor de todo GRATIS. Ahora, a la solucion de usar Openfiler como VM para tener una SAN simulada podemos añadirle la solucion de Xtravirt que desde luego parece muy buena (no me ha dado tiempo a probarlo).

¿Cómo funciona? Tenemos dos servidores ESX, cada uno de ellos con una VM con el appliance antes mencionado (solo ocupa 230MB). A dichas VMs le damos discos, pongamos que les damos 200GB, que presentaran como iSCSI a los ESX permitiendonos que los formateen en VMFS y que puedan meter VMs alli, usar HA, DRS(vMotion tambien obviamente) etc. Lo mejor de todo es que esos dos discos de 200GB(cada uno en un ESX: recordemos que es disco local de los ESX) son replicados sincronamente de forma que nos puede servir tambien de Disaster Recovery a nivel de datos.

Dicho esto, solo me queda probarlo! Espero que poco a poco este tipo de cosas se vayan incluyendo en el propio ESX puesto que son cosas que les da realmente potencia.

Como una imagen vale más que mil palabras :

The Xtravirt Virtual SAN (XVS) appliance for VMware ESX3 Server is a free solution to provide the benefits of shared VMFS storage without the cost of a SAN – this allows the utilisation of otherwise unused local storage in the ESX server to facilitate enterprise level features such as vMotion, DRS and HA normally only available through the use of a shared storage device. All volume data is synchronously replicated between hosts, providing full fail-over capability with data integrity in the event of host, disk or appliance failure. The appliance is menu driven and has been designed to be as easy to configure as possible, and full documentation on the implemenation process is provided.

Por el momento no puedo entrar a la documentacion. Si lo probais comentad algo.

Upgrade a ESX 3.5 y VC 2.5

2008-05-21T23:30:00.002+02:00

Desde VMware nos dan una serie de Best Practices para realizar el paso a la version 3.5 de ESX y a la 2.5 de VC: Upgrading to ESX 3.5 and VirtualCenter 2.5 Best Practices

Backup your VirtualCenter database. VMware recommends detaching the database and copying it somewhere safe.
Grant the System DSN user of the VirtualCenter Database db_owner privileges on the MSDB database as well as the VirtualCenter database. Ensure that your ODBC System DSN is using the proper driver. You must have a SQL Server driver if your database is SQL 2000, and SQL Native Client driver if using SQL 2005.
If your ESX Server host is in a DRS or VMware High Availability (HA) Cluster remove it from the cluster so no virtual machines migrate to the ESX Server host.
If possible VMotion all virtual machines off the host to be upgraded. If not, power them down gracefully and power off the ESX Server host.
Log in to your VirtualCenter server with a local Administrator account to run the installation, do not use a domain administrator.
Perform the upgrade to VirtualCenter to 2.5 and ensure all your data is visible in VirtualCenter 2.5 after the upgrade. Ensure no processes are running that conflict with the ports that VirtualCenter uses, such as IIS.
If there is a SAN connected to your ESX Server host detach the SAN before continuing with the upgrade.
Confirm that all the virtual machines are now migrated from the ESX Server host or powered down, and that ESX Server host is no longer part of an VMware HA or DRS cluster.
Download the newest version of the ESX operating system ISO image and burn it to CD.
Place the CD in the CD-ROM drive of the host and boot from the CD.
Install ESX Server 3.5 with a fresh install or upgrade.

Note: A fresh install wipes out all previous network configuration.

ESX 3.5 puede correr en Workstation 6.5 Build 91182

2008-05-21T22:58:00.004+02:00

Supongo que habrá muchos que se alegrarán: Ya se puede correr una VM con el ESX3.5 en Workstation 6.5, concretamente :
Download VMware Workstation 6.5 Beta VMware Workstation 6.5 Beta
Latest Version: Beta | 5/12/08 | Build 91182

Como antes, hay que tocar el .vmx de la maquina virtual.
Ejemplos de configuraciones que funcionan:
ethernet0.virtualDev = "e1000"
monitor.virtual_exec = "hardware"
monitor_control.restrict_backdoor = "true"

o

guestOS = "other"
ethernet0.virtualDev = "e1000"
scsi0.virtualDev = "lsilogic"
monitor.virtual_exec = "hardware"
monitor_control.restrict_backdoor = "true"

Y alguna recomendacion:
I'd also recommend to install the ESX itself to IDE and use the LSI-logic disks for VMFS Use 2 virtual CPUs only when you have a quadcore system - otherwise use one CPU

vmreference VI3 card v1.2

2008-05-21T22:41:00.002+02:00

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.

¿Cómo saber cuánto se deduplicará?

2008-05-16T12:07:00.004+02:00

La principal pregunta a la hora de aplicar deduplicación o convencer a alguien de que es algo que le puede venir muy bien es precisamente ¿Cual es mi potencial de deduplicacion? Es decir, si aplico la deduplicacion a tal o cual volumen: ¿Cuánto se deduplicará? ¿Cuanto espacio me ahorraré? El 10%, el 40%...

Aqui os pongo un script (en python) que realiza (o intenta realizar) una estimación de lo que nos ahorraríamos usando la deduplicación de NetApp.

Como ya expliqué en este post la deduplicación de NetApp funciona en un 99% de esta forma:
En algun lugar hay un directorio que dice que el fichero A esta almacenado en los bloques 123-345, 500-510 y 12999-14090. Por el momento esto es lo normal para todos los FS. La diferencia entre el FS deduplicado y el normal es que pueden usar el mismo bloque más de un fichero. Si edito el fichero A y añado 10KB al final y lo guardo como B en algun momento (dedupe en tiempo real o dedupe diferida) el proceso de deduplicacion reconocerá (via hashes o por comparacion de bytes) que ambos ficheros tienen los mismos datos y creará una entrada en el directorio que dice que B utiliza los bloques 123-345, 500-510, 12999-14090 y 66666-66669(Por ejemplo los bloques son de 1K), de forma que la creacion del fichero B solo ocupa 10K(del 66666 al 66669).

¿Como funciona el script?
El script mira recursivamente en el directorio que le indiquemos leyendo cada archivo. Posterirormente va troceando cada archivo en chunks de 4 kB (ese es el tamaño de bloque que usa NetApp) y calcula un md5 de cada bloque de 4kB. Se mantiene una lista de los md5 calculados y comprueba si se trata o no de datos duplicados.
Cada vez que se procesa un archivo el script nos proporciona por un lado la deduplicacion que obtendria ese fichero y por otro cómo vamos en el total del directoriro en el que estamos intentando estimar el ahorro debido a la deduplicación:

Archivo /tmp/dedup/Archivos_Backup.txt: Tamano 286927441 bytes (70051 bloques)
Estadisticas del Archivo /tmp/dedup/Archivos_Backup.txt: Bloques Usados: 3728, Bloques del Archivo: 70051, Ratio 5.3%, Ahorro 94.7%.
Estadisticas Totales Recalculadas: Numero de Archivos: 12, Bloques Usados: 7073, Bloques Totales: 73396, Ratio 9.6%, Ahorro 90.4%.

Finalmente, cuando se ha terminado de procesar todo el directorio el script nos muestra los datos importantes:
=======================================================================================================================
Estadisticas Totales Finales: Numero de Archivos: 961, Bloques Usados: 268422, Bloques Totales: 401134, Ratio 66.9%.
Ahorro Final que obtendras con la deduplicacion 33.1%.
=======================================================================================================================

En este caso obtendríamos un 33% de ahorro de espacio si usasemos deduplicacion.
El script sólo da una aproximación de los ahorros que conseguiríamos aplicando la dedupliación puesto que
se necesitaría también espacio para mantener la base de datos de hash y algunos metadatos.
Por las pruebas que he hecho es bastante fiable, incluso a veces el tiempo que tarda en hacerlo es equivalente en la cabina y con el script. A ver que os sale a vosotros...

Ejemplo de uso: python estimar_dedup.py /tmp/dedup
(Podeis poner delante time para ver el tiempo que tarda: time python estimar_dedup.py /tmp/dedup)

Con los comandos df -h y df -s antes y despues de realizar la dedupliación con NetApp(sis on, sis start -s) podreis comprobar si el script ha resultado fiable o no.

Por favor, si obteneis resultados(buenos o malos) o mejoras o problemas con el script, ¡comentadmelo! Espero que sirva aunque sea para saber a priori si te compensa usar deduplicacion o no...

Nota: Los resultados más espectaculares de la dedup de NetApp se dan en los ficheros que no pierden su alignment de 4kB anque se modifiquen. Como los vmdks de VMware y no como los ficheros de texto.


[root@server ~]# more estimar_dedup.py
#!/usr/bin/python

import os, sys, md5
from stat import *

# Lee todos los ficheros del directorio y
# estima los ahorros de la dudup de NetApp haciendo el md5
# y comprobandolo para cada bloque de 4 kB. el paramentro importnate
# es el que da el ultimo Ratio (un ratio de 70% significa que te ahorras # un 30%)

if len(sys.argv) != 2:
  print "Uso: nombre.py "
  sys.exit(1)

workdir = sys.argv[1]

if not os.path.isdir(workdir):
  print "Problema: " + workdir + " no es un directorio"
  sys.exit(1)

print "Comprobando directorio: " + workdir

numfiles = 0

storage_blocks = 0

total_blocks = 0

current_file_storage_blocks = 0

fingerprint_index = {}


for root, dirs, files in os.walk(workdir):
 for f in files:
  filename = root + "/" + f
  print "Archivo " + filename + ": ",

  if f==".snapshot":
   continue

  if not os.access(filename, os.R_OK):
   print "No access, skip"
   continue

  if os.path.islink(filename):
   print "Symlink, skip"
   continue

  mode = os.stat(filename)[ST_MODE]
  if not S_ISREG(mode):
    print "No regular file, skip"
    continue

  file_size = os.stat(filename).st_size

  blocks = int( round( (file_size + 2048) / 4096.0) )

  print "Tamano " + str(file_size) + " bytes (" + str(blocks) + " bloques)"

  f = open (filename, "r")

  current_file_storage_blocks = 0

  for block_number in range(0,blocks):
    blockdata = f.read(4096)
    m = md5.new(blockdata)
    fingerprint = m.digest()

    if fingerprint_index.has_key( fingerprint ):
      pass
    else:
      fingerprint_index[fingerprint] = True
      storage_blocks = storage_blocks + 1
      current_file_storage_blocks = current_file_storage_blocks + 1

    total_blocks = total_blocks + 1

  f.close()

  print "Estadisticas del Archivo "+ str(filename) + ": Bloques Usados: "+str(current_file_storage_blocks)+ ", Bloques del Archivo: "+str(blocks)+ 
 ", Ratio "+str( round((100.0 *current_file_storage_blocks)/blocks,1) )+ 
 "%, Ahorro "+str( round(100 - (100.0 *current_file_storage_blocks)/blocks, 1 ) )+"%."
  numfiles = numfiles + 1
  print "Estadisticas Totales Recalculadas: Numero de Archivos: " +str(numfiles)+", Bloques Usados: "+str(storage_blocks)+ 
 ", Bloques Totales: "+str(total_blocks)+ ", Ratio "+str( round ( (100.0 *storage_blocks)/total_blocks, 1 ) )+ 
 "%, Ahorro "+str( round ( 100 - (100.0 *storage_blocks)/total_blocks, 1) )+"%."
  print "-"
  print

print
print "======================================================================================================================="
print "Estadisticas Totales Finales: Numero de Archivos: " + str(numfiles) + ", Bloques Usados: " + str(storage_blocks) + 
 ", Bloques Totales: " + str(total_blocks) + ", Ratio " + str ( round ( (100.0 *storage_blocks)/total_blocks, 1) ) + "%."
print "Ahorro Final que obtendras con la deduplicacion " + str ( round ( 100 - (100.0 *storage_blocks)/total_blocks, 1) ) + "%."
print "======================================================================================================================="

Site Recovery Manager

2008-05-14T23:05:00.001+02:00

Ayer anunció oficialmente VMware que la proxima semana estará disponible para pedirlo el Site Recovery Manager(SRM) y que posteriormente estará disponible para todo el mundo en 30 dias.

En lineas generales, Site Recovery Manager necesita:

VirtualCenter con licencia en ambos sites.
ESX con licencia (y corriendo) en ambos sites.
Base de datos de backend para SRM en ambos sites.
Almacenamineto compartido con capacidad y licencia para realizar replicacion a nivel de bloque (SAN based) en ambos sites.
Site Recovery Agent (SRA) proporcionado por nuestro vendedor de almacenamiento.(En teoria los que lo proporcionan son: 3PAR, Dell, EMC, FalconStor, Hitachi Data Systems, HP, IBM, LeftHand Networks y NetApp)
Tanto en el primario como el secundario necesitaremos instalar el codigo SRM en el servidor SRM, instalar el plugin SRM en el VI Client, instalar SRA en el servidor SRM.

Entre las recomendaciones están:

Organizar las VMs en las LUNs de forma que no se necesiten replicar todas(VC server, Update Manager server, and SRM server (si son VMs no deben ser replicadas).
Separar LUNs de VMs criticas y no criticas, la idea es reducir el trafico de replicacion para dejarlo mayormente para las LUNs de VMs criticas.(El uso del sVMotion nos ayudará a hacer esto...)

A ver cómo hacen el fail over, no he probado nada del SRM pero tiene pinta de que las VMs se levantarán como de un crash...veremos...

Update: Aqui teneis un link con una presentación donde explican qué es el SRM de VMware, a disfrutarlo:
http://communities.vmware.com/docs/DOC-3210

Essential ESX 3.5 & VC 2.5 links

2008-05-13T08:45:00.000+02:00

Eric Siebert (VMware Communities User Moderator) ha publicado (en forma de post sticky) una recopilacion de enlaces muy muy utiles para ESX 3.5 y V.C 2.5. La tenemos aqui.

Abarca una gran cantidad de puntos:

Compatibility & Version Info:
VI3 Key Features & Benefits Summary by Version - http://www.vmware.com/files/pdf/key_features_35.pdf
VMware Infrastructure Compatibility Matrixes - http://vmware.com/pdf//vi3_35/esx_3/r35/vi3_35_25_compat_matrix.pdf
Details of What's New and Improved In VI3 Version 3.5 - http://www.vmware.com/support/vi3/doc/whatsnew_esx35_vc25.html

Must Read:
RTFM Upgrade guide for ESX 3.5 and VirtualCenter 2.5 - http://tinyurl.com/3722dz

Release Notes/Install, Upgrade and Patch Guide:
ESX Server 3.5 and VirtualCenter 2.5 Release Notes - http://www.vmware.com/support/vi3/doc/vi3_esx35_vc25_rel_notes.html
ESX Server 3 Installation Guide - http://vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_installation_guide.pdf
Upgrade Guide - http://vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_upgrade_guide.pdf
ESX Server 3 Patch Management Guide - http://vmware.com/pdf/vi3_35/esx_3/r35/vi3_35_25_esxupdate.pdf

Additional downloads:
Remote CLI Download - http://www.vmware.com/download/download.do?downloadGroup=VI-RCLI
License Server for ESX 3.5 - http://download3.vmware.com/software/vi/VMware-licenseserver-64192.exe
CPU Compatibility Tool for ESX 3.5 - http://download3.vmware.com/software/vi/CPU_Compatibility-64557.zip

Converter:
VMware Converter Enterprise for VirtualCenter 2.5 Admin Guide - http://vmware.com/pdf/vi3_vec_10_admin_guide.pdf
VMware Converter Enterprise for VirtualCenter 2.5 Release Notes - http://vmware.com/support/vi3/doc/vi3_vec_10_rel_notes.html

Update Manager:
VMware Update Manager Release Notes - http://vmware.com/support/vi3/doc/vi3_vum_10_rel_notes.html
VMware Update Manager Admin Guide - http://www.vmware.com/pdf/vi3_vum_10_admin_guide.pdf
VMware Update Manager Sizing Estimator - http://vmware.com/support/vi3/doc/vi3_vum_10_sizing_estimator.xls

Latest Hardware Compatibility Guides:
Systems - http://vmware.com/pdf/vi3_systems_guide.pdf
I/O - http://vmware.com/pdf/vi3_io_guide.pdf
Storage/SAN - http://vmware.com/pdf/vi3_san_guide.pdf
Backup Software - http://vmware.com/pdf/vi3_backup_guide.pdf

Blog & News Articles:
VMware ESX 3.5 goes live with key new features - http://searchservervirtualization.techtarget.com/originalContent/0,289142,sid94_gci1285629,00.html
What's new in ESX 3.5 & VC 2.5? -
http://virtualgabe.wordpress.com/2007/12/08/what%e2%80%99s-new-in-esx-35-vc-25-part-2/
http://virtualgabe.wordpress.com/2007/12/08/what%e2%80%99s-new-in-esx-35-vc-25-part-3/
http://virtualgabe.wordpress.com/2007/12/08/what%e2%80%99s-new-in-esx-35-vc-25-part-4/
VMware VI Client 2.5 does not support 64-bit workstations - http://www.dabcc.com/article.aspx?id=6674

Relevant KB Articles:
Licensing:
Updates to your VMware VI3 Starter Licenses - http://kb.vmware.com/kb/1003299
Changes in licensing for VI3 Standard Edition When upgrading to VI 3.5 - http://kb.vmware.com/kb/1003301
Understanding VI 3.5 Licensing: Server and Host-based Licensing Models - http://kb.vmware.com/kb/1003295

ESX 3.5:
Installing ESX Server throws an "Anaconda Error" in the Partitioning Options screen - http://kb.vmware.com/kb/1003217
VMFS Partition cannot be created for "Typical" ESX Server Installation if Prior installation is detected - http://kb.vmware.com/kb/1003309
IBM System x3850 M2 and System x3950 M2 Servers fail to connect to 100Mbps Networks - http://kb.vmware.com/kb/1003226
Installing the Tivoli Storage Manager Client on the Service Console results in an error - http://kb.vmware.com/kb/1003142
Virtual Machine on a RDM Shared Storage becomes invalid after migration from ESX Server 2.5.x to ESX Server 3.5 or 3i - http://kb.vmware.com/kb/1003092
Vmotion is disabled after ESX Server upgrade - http://kb.vmware.com/kb/1003060
Certain Special Characters cause software iSCSI Initiator CHAP Configuration corruption - http://kb.vmware.com/kb/1003095
Connection to ESX Server host through VI Client is lost if you attempt to delete several VM's at once from the Datastore Browser - http://kb.vmware.com/kb/1003250
Storage Devices connected to McData FC Switch through Qlogic adapters occasionally do not re-appear after reboot - http://kb.vmware.com/kb/1003250
Snapshot operations submitted directly to an ESX Server Host during Storage vMotion corrupts Virtual Machine data - http://kb.vmware.com/kb/1003114
Storage vMotion on a VM with I/O intensive workload may result incorrectly in a timeout error - http://kb.vmware.com/kb/1003276
Upgrading to ESX Server 3.5 when the Root Parition is nearly full might cause Incomplete System Configuration - http://kb.vmware.com/kb/1003311
Restarting Hostd (mgmt-vmware) on ESX Server hosts restarts Hosted Virtual Machines where VM Auto Startup/Shutdown is enabled - http://kb.vmware.com/kb/1003312
ESX Server becomes temporarily unresponsive under a Heavy I/O load - http://kb.vmware.com/kb/1003039
Consolidation of Large or Deeply Nested Snapshots using VirtualCenter, SDK or VCB might take longer on ESX Server 3.5 than on ESX Server 3.0.x - http://kb.vmware.com/kb/1003308

Consolidated Backup 1.1:
Upgrading Consolidated Backup version 1.0.x to 1.1 causes the installer to hang - http://kb.vmware.com/kb/1003045
Consolidated Backup cannot create Quiesced Snapshots of VM's running Windows Vista - http://kb.vmware.com/kb/1003074
VCB 1.1 Command Line utility connection to port 902 causes an error message - http://kb.vmware.com/kb/1003088

VC 2.5:
When you install SQL Server Express on a System where SQL Native Client is present the installation might fail with error - http://kb.vmware.com/kb/1003076
VirtualCenter Server Fails to Start after your replace Default SSL Ceritifcates with Custom Certificates - http://kb.vmware.com/kb/1003070
Error Message During Installation: error 1603: error installing Windows installer engine - http://kb.vmware.com/kb/1003036
Administrative Credentials are Required for Oracle and SQL Database when Installing or Upgrading VirtualCenter - http://kb.vmware.com/kb/1003052
Client-side CD-ROM or Floppy can become disconnected - http://kb.vmware.com/kb/1003118
VirtualCenter Server does not detect changes in Host IP Address unless SSL Certificate Verification has been enabled - http://kb.vmware.com/kb/1003066
Permission problem if host had been in lockdown mode - http://kb.vmware.com/kb/1003117
Virtual Machines might lose Network Connectivity when moved to a different Port Group - http://kb.vmware.com/kb/1003061
Powering on Virtual Machines with multiple PCI Devices might fail - http://kb.vmware.com/kb/1003048
Incorrect Device Paths for LUNs displayed in Storage Summary - http://kb.vmware.com/kb/1003064
VirtualCenter Consolidation service Usernames and Passwords must use only ASCII characters - http://kb.vmware.com/kb/1003096
VI Client installation fails on Windows Vista Business Edition with enabled Anti-virus software - http://kb.vmware.com/kb/1003079
VirtualCenter Server might crash in a cluster with Manual or Partially Automatic DRS and Automatic DPM - http://kb.vmware.com/kb/1003027
Deleting Snapshots of VM's with Heavy disk I/O might cause host to be Disconnected from VirtualCenter - http://kb.vmware.com/kb/1003024
Paravirtualization option is not Disabled for Unsupported Operating Systems - http://kb.vmware.com/kb/1003008
VirtualCenter Server installation fails or results in an error if your system does not have MDAC 2.8 SP1 or later installed - http://kb.vmware.com/kb/1003160
Installing Update Manager with Unified Installer might faile if Disparate Databases are used - http://kb.vmware.com/kb/1003277
Some Alarms may disappear after upgrading to VirtualCenter 2.5 - http://kb.vmware.com/selfservicekb/1003072
VirtualCenter Database upgrade fails with an exception when a Password that contains Apostrophes or Double Quotes is used - http://kb.vmware.com/kb/1003049
The VirtualCenter Server might Crash when using an older ODBC driver with Oracle 9i - http://kb.vmware.com/kb/1003049
Guest Operating System Standby feature removed in VirtualCenter Server 2.5 - http://kb.vmware.com/kb/1002414
Cannot specify Destination Folder on Non-default Datacenter when Cloning Virtual Machines - http://kb.vmware.com/kb/1003075
VirtualCenter Service will not start on a machine with non-Ascii characters in it's Machine Name - http://kb.vmware.com/kb/1003075
vMotion from ESX Server 3.5 hosts to ESX Server 3.0.x hosts causes the console sessions of the migrated VM's to become blank - http://kb.vmware.com/kb/1003038
Automatic VMware Tools upgrade does not upgrade to the latest version on VM's with Insufficient space in the Root parition - http://kb.vmware.com/kb/1003051

Forum Threads:

Other:
Technote: Round-Robin Load Balancing - http://www.vmware.com/pdf/vi3_35_25_roundrobin.pdf
Technote: Enabling Netflow on Virtual Switches - http://www.vmware.com/pdf/vi3_35_25_netflow.pdf
Technote: Configuring and Troubleshooting N-Port ID Virtualization - http://www.vmware.com/pdf/vi3_35_25_npiv_config.pdf
Technote: Virtual Machine Failure Monitoring - http://www.vmware.com/pdf/vi3_35_25_vmha.pdf
ESX 3.5 Installation Video (You Tube) - http://ca.youtube.com/watch?v=qobhariBEec

Blog & News Articles:
Review: VMware Infrastructure 3.5 builds on the base - http://www.computerworld.com/action/article.do?command=viewArticleBasic&articleId=9053158

Relevant KB Articles:

VC 2.5:

For SQL Server 2000, Do Not Grant or Revoke the System Administrators Role to Satisfy the Database Permission Requirements When Upgrading to VirtualCenter 2.5 - http://kb.vmware.com/kb/1003346

VMware Converter Update

2008-05-08T16:52:00.003+02:00

VMware ha sacado una actualización de VMware Converter (3.0.3.).
Esta actualización resuelve un buen numero de bugs y trae nuevas features: La más importnte es el soporte para Open Virtual Machine Format (OVF) version 0.9. Esto nos permite crear una VM en Virtual Infrastructure y usar el Converter para convertirla en un virtual appliance OVF para su distribución (otras empresas, entornos diferentes en la misma empresa, etc...)

Para más detalles podeis ver las release notes.

Deduplicacion de NetApp con LUNs

2008-05-06T18:46:00.005+02:00

Sigo con la saga de posts sobre NetApp. Esta vez algo que no sé si es muy usado pero que nos puede venir muy bien:
Deduplicacion de NetApp con almacenamiento tipo bloque (LUNs presentadas al host por FC o iSCSI).
Por lo general todo lo referente de la deduplicacion de NFS es aplicable a la deduplicacion de LUNs:

Necesitas la licencia de NearStore y dedupliacaion(A-SIS)
Se sigue activando el proceso de deduplicacion con el comando "sis on" para el FlexVol que contiene las LUNs
Las limitacions del tamaño del FlexVol siguen siedo las mismas.
Con el comando "sis status" vemos el estado del porceso y con "sis config" vemos el calendario de la deduplicacion.

¿Qué es lo diferente? Lo diferente es que las LUNs están implementadas encima del sistema de ficheros WAFL. Dicho sistema de ficheros ve las LUNs como un sólo fichero y dicho fichero es tratado como "space reserved", lo que significa que durante la creacion de la LUN se reserva el maximo tamaño de dicha LUN. (Simplificando) Si creas una LUN de 50GB, se crea un fichero de 50GB.

Debido a que las LUNs son creadas de este modo, el espacio es reservado en su creacion y el dichero que representa la LUN no decrecerá jamás su tamaño y nunca refeljará los ahorros de la deduplicacion (no cambiará su tamaño). La deduplicacion no nos servirá para nada. Sí que funciona en dicha LUN, pero no nos sirve de nada.

¿Cómo resolverlo?
Es facil, simplemente cuando se crea la LUN desmarcaremos la casilla "Space Reserved" y dejaremos que Data ONTAP reserve bajo demanda el espacio que require la LUN en dicho FlexVol.
El fichero que representa la LUN puede crecer y decrecer en tamaño sin problemas. Por ello la deduplicación, además de funcionar como en el caso anterior, sí será efectiva y nos permitirá ahorrar espacio. Este espcacio nos permitirá provisionar otras LUNs en el mismo FlexVol teniendo un ojo encima...

En resumen:

Instalar y configurar la deduplicacion para NFS y LUNs es lo mismo en esencia.
Desmarcar la casilla "Space Reserved" cuando se crea la LUN que va a ser deduplicada.
A diferencia de NFS , con LUNs el espacio ahorrado NO se verá desde el host (No hay comando SCSI que pueda pasar ésta informacion del array al filesystem del host). El comportamiento diferente del NFS se debe a que no hay otra capa de indireccion entre el array y el host, por eso, en NFS las caracteristicas del FS del array son vistas directamente por el host, en consecuencia en NFS, los bloques que se liberan en el dedupe estan disponibles inmediatamente para el host (ESX o servidor normal). Además, el host no podrá almacenar más datos que el tamaño máximo de la LUN (como es normal).
Es importante el orden: (Si no, se te pueden llenar los snaps porque el proceso de dedupe cambia mucho los datos...)

Desactivar los snapshosts,
Deduplicar,
Activar snapshost.

Con el ahorro que se obtiene de la deduplicacion se puede provisionar otras LUNs en ese mismo FlexVol a otros servidores o usarlo para más snapshots....

VI3: ¿Dónde estan los logs?

2008-05-05T10:12:00.002+02:00

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

Networking Performance en ESX 3.02 y 3.5

2008-04-30T16:35:00.005+02:00

Si teneis alguna duda sobre el rendimeinto de red del ESX podeis ver este documento. La ultima revision es de finales de Febrero.
Aunque es relativo, como todo lo que es comercial, lo destacable es la buena comunicacion en cuanto a latencia y throughput que se establece entre dos VMs que estan en el mismo vswitch (2,5Gbps) contra la que se establece cuando debe pasar por el cable (900Mbps), ademas del uso de TSO.

Estas son sus conclusiones:
"The results in this study clearly show that the virtualized applications running in virtual machines on ESX
Server 3.5.0 can achieve the same network throughput and latencies that are achieved by applications running
natively. In fact, virtual machines that are connected to the same virtual switch can communicate at rates that
are up to two-and-a-half times the rates supported by physical 1Gbps Ethernet networks."

Otra cosa seria una comparación en rendimiento de acceso a disco...... ;-)

Estado del Arte: Thin provisioning, Deduplication, SVI, NFS, FC

2008-04-30T13:38:00.001+02:00

Uno se queda pensado cuando ve el pequeño boom que esta teniendo el viejo NFS con VMware y las soluciones tan vistosas que están saliendo al mercado para VDI..., para ahorrar espacio (duplicación, thin provisioning etc...). La confluencia de todas estas tecnologías está haciendo que a la mayoría de los usuarios se escape las implicaciones que tiene usarlas por lo poco que el mercado ayuda y lo mucho que nos confunden los comerciales:
¿Que hacer? Usar NFS? Usar VMFS? Usar deduplicación? Usar SVI?
Todo tiene sus pros y sus contras, pero al menos hay que saber lo que nos espera:

La historia suele comenzar con VDI o con las maquinas virtuales en VMFS y cuando nos damos cuenta de que no es tan barata la solución como la pintan, entonces vemos si hay algo en el mercado que nos pueda satisfacer y hacer que nos gastemos menos...

Bien, estos dos vídeos comerciales: Primero y Segundo nos pueden hacer pensar que todo es muy bonito y que la solución es trivial, barata y sencilla.

El primer vídeo nos muestra al campeón de la Fibra: EMC enseñándonos como de unos 10GB podemos realizar unos 1000 escritorios. Nos explica como metiendo una capa extra, con cinco "Fully realiced" copies (50GB) podemos escalar a 1000 escritorios usando snaps de la cabina "sin ocupar nada de espacio".
En fin, la única idea que me gusta del vídeo es que menciona que podemos dar servicio Silver, Gold etc, según de las copias full que realicemos y eso da la ligera impresión de que al menos suponen "cierta" pérdida de performance.
Al margen de que sea "solo pizarra" y de que no diga un solo detalle técnico, por lo que nos muestra, podemos pensar que se trata de LUNs de VMFS(en ningún momento lo dice y por lo que sabemos los snaps EMC basados en SAN son de tipo LUN), pero a nada que nos acordemos del limite (256 creo recordar) de LUNs que pueden ver nuestros ESX llegamos a la inevitable conclusión de que se trata de NFS, (a no ser que VMware, al ser muy amiguitos, les haya pasado las especificaciones de VMFS durante el café...).
Conclusión: Lo que nos propone EMC, gran defensor del FC, para VDI es claramente el uso de NFS: "Adiós FC, (o hasta luego)"
(Y eso que me encanta la fibra: Te hace ir al baño ;-) , No, en serio, vale que el inicio es complejo y que su precio, si te la puedes permitir, no es una ventaja, pero luego tiene una estabilidad muy buena, hay que decirlo).

El segundo vídeo, esta un poco más currado la verdad (faltaría mas, es NetApp!). Después de verlo te queda claro que no se pueden correr 1000 VMs con solo ese espacio de disco, pero ilustra bien la potencia que tiene NFS+NetApp y sus clones a nivel de fichero. Por algo su sistema de ficheros se llama WAFL ("Write Anywhere File Layout'") y nos permite ofrecer Thin Provisioning ("dedicate on write not on allocation") según instalamos la cabina.

Aquí llegamos al primer meollo de la cuestión:
Thin provisioning y VMware, es decir, Thin Provisioning en dos niveles: nivel VMware y nivel NFS(cabina).

Puede parecer una buena idea tener ambas capas pero esto lleva a pesadillas serias en la administración (sobretodo el primer punto):
1.- El tener el thin provisioning y el thin disk nos produce issues con Storage VMotion, Cold Migration, deploy de template...

Cuando creamos una VM en VMware, por defecto dicha VM es creada en el volumen NFS como thin disk, de hecho esto no es algo que lo determine VMware sino el propio servidor de NFS. Segun "ESX Configuration Guide":

Y mas tarde, el mismo documento, añade: "The virtual disks that you create on NFS‐based datastores use a disk format dictated by the NFS server, typically a thin‐disk format that requires on‐demand space allocation. If the virtual machine runs out of space while writing to this disk, the VI Client notifies you that more space is needed."

Posteriormente, cuando realizamos alguna de las acciones antes mencionadas (Storage VMotion, Cold Migration, deploy de template) el disco se vuelve thick. Se puede, como hemos visto (autobombo, jeje), clonar el disco a thin y volver a unirlo a la VM. Incluso se puede scriptear, pero no deja de ser un arreglo.

2.- Consideremos también la visibilidad y la administración dependiendo de si el disco es thin o thick:
2.1.- Desde la perspectiva del VC, siempre veremos el tamaño del disco thin en el datastore y si, como suele ocurrir, tienes multiples usuarios finales haciendo deploys de VMs , éstos no tendrán la visibilidad de la ocupacion actual para realizar el provisionamiento y el hecho de que las VM tengan la posibilidad de llenar X espacio puede llegar a ser un problema serio: Estamos infraprovisionando el almacenamiento y sobreprovisionando las VMs: Algo puede ir mal.

2.2.- ¿Que ocurre con nuestra Console ? Haciendo un "ls" veremos el disco thin ocupando la maxima capacidad de la que es capaz, sin embargo un "du" nos devuelve el tamaño thin del disco. Amazing.

Veo que puede dar menos problemas que el Thin Provisioning esté controlado en el sistema de almacenamiento que tengamos. Esto es totalmente discutible pero intuyo que sería mucho mas simple para todos. (Creo que 3PAR actualmente puede manejar correctamente el formato de vmdk "zero'ed thick" asi que probablemente por ahi vayan los tiros en un futuro. ¿Alguien sabe cómo decirle a nuestro NFS que por defecto provisione de forma thick y no thin?).

El otro tema candente que nos venden como la panacea es la Dedupliacion(Single Instancing).
La deduplicacion consiste en que los bloques de datos iguales no se repiten, si no que en su lugar hay un puntero que los señala.
Explicacion somera (esto es cierto en un 90% para NetApp):
En algun lugar hay un directorio que dice que el fichero A esta almacenado en los bloques 123-345, 500-510 y 12999-14090. Por el momento esto es lo normal para todos los FS. La diferencia entre el FS deduplicado y el normal es que pueden usar el mismo bloque más de un fichero. Si edito el fichero A y añado 10KB al final y lo guardo como B en algun momento (dedupe en tiempo real o dedupe diferida) el proceso de deduplicacion reconocerá (via hashes o por comparacion de bytes) que ambos ficheros tienen los mismos datos y creará una entrada en el directorio que dice que B utiliza los bloques 123-345, 500-510, 12999-14090 y 66666-66669(Por ejemplo los bloques son de 1K), de forma que la creacion del fichero B solo ocupa 10K(del 66666 al 66669).

Como se puede intuir esto no puede ser manejado por la cabina que esta detrás sin algo intermedio, un S.O o un FS que escanean los bloques duplicados y los enlazan con lo que significan más alto en la cadena y deciden que hacer si algo desde arriba necesita escribir en un bloque previamente deduplicado etc, etc...
Lo que choca de todo esto es que lo que les pedimos idealmente a nuestros diseños de almacenamiento (al menos en teoria) es precisamente NO hacer nada de esto pues idealmente debe hacerse mas arriba (en el File System ).
Por el momento VMFS no es capaz de hacer resto pero SVI(Scalable Virtual Image) sí parece que lo va a hacer de alguna forma quitando (o compitiendo con) la necesidad de la deduplicacion a nivel de cabina.

¿Que es SVI?
Explicacion muy somera porque hay poca info: Es una tecnología que esta basada en "linked clone" (VMware Workstation 6) que, segun VMware, reducirá en un 90% los requerimientos de almacenamiento en entornos de escritorios virtuales. Segun ellos, repito, mejora la gestion de imagenes de escritorios y facilita el provisioning. La idea es tener un disco stateless(o unos pocos) que lleven el SO (disco maestro) que sea el mismo para todos y luego un disco de personalización para cada usuario de forma que los parches etc sólo haya que aplicarlos en los discos maestros.

Seria muy interesante una comparacion de NetApp sis-clone y SVI, incluso trabajando juntos...

¿Que concluir de todo esto?

NFS mola, tiene sus cosillas pero mola, el elegirlo o no depende del entorno, como siempre.

La primera conclusion de todo es que cada vez es menos cierto el paradigma de que la Fibra es la Reina. (Con lo que me gusta...jeje)
Lo segundo es que VMware deberia meter muchas mas horas en el VMFS y hacer que sea algo realmente competitivo. Seria genial que integrasen la "deduplicacion" de SVI en VMFS. Y tema Thin Provisioning... Tiempo al tiempo.
Lo tercero es que NFS te puede quitar bastantes dolores de cabeza si estas pensando en migrar en un futuro o tener un entorno heterogeneo (Citrix XenServer o Microsoft Hyper-V). Probablemente para ese momento los formatos de discos virtuales ya sean interoperables y cualquier cabina es capaz de presentar NFS y CIFs.
Lo cuarto es que si pones soluciones de VDI basado en cabina como muestran los videos o VDI+SVI mejor si tienes cache de sobra para parar un tren. Como idea: Puede servir para dar diferentes niveles de servicio en escritorios(¿esto es util realmente?): GOLD, SILVER, BRONZE dependiendo del ratio (Escritorios)/(Full VM Copy)...
Lo quinto es que la solucion de NetApp que incorpora un S.O y un File System precisamente para hacer cosas como la deduplicacion es muy buena aunque de forma "pura" la cabina no se debería de ocupar de la deduplicacion, es cosa del File System. Desde luego no hay que olvidar que la deduplicacion nos sirve también para todo lo demas que no sea vmdks(en una cabina no solo existe VMware...), por ello pienso que en global la solucion de NetApp es muy versatil y cómoda aunque también pienso que deberia ser el propio FS (VMFS en este caso) el que realizase la deduplicacion.

Primer documento OFICIAL de VI Client Plug-in

2008-04-21T15:51:00.010+02:00

Pues sí señor, los de VMware se han pueso las pilas y han sacado documentacion sobre el desarrollo de VI Client Plug-in(tanto servidor como cliente). Os recomiendo echarle un vistazo, esta muy bien: Lo teneis aqui

La idea de abrir el framework y dejar que terceros desarrollen plugins de sus productos para integrarlos en el virtual Center 2.5 hace que se puedan realizar soluciones como esta.

Por lo que he podido hojear, la documentacion es tan simple que incluso yo seria capaz de poner un botoncillo en el Virtual Center y hacer que haga algo.
Esperemos ver aparecer buenos y diversos plug-ins...

¿Que hace cada proceso de un ESX?

2008-04-21T13:00:00.012+02:00

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...

Oracle VM: LiveSync - High Availability, LiveMigration sin SAN

2008-04-19T20:44:00.009+02:00

Los de Thinsy(EnSpeed) han anunciado que ya esta disponible para descarga las caracteristicas de Live Migration(Vmotion en terminos vmwaristicos) y VMFailover(HA en terminos vmwaristicos) para OracleVM. La noticia no sería tan importante si no hubiesen anunciado que esto se puede hacer sin una SAN, es decir que con Direct Attached Storage sería suficiente.
Como dice la nota de prensa:

Saratoga, California – April 17, 2008 – Thinsy Corporation today announced the immediate availability of a new version of their Peer to Peer SAN Replacement technology LiveSync, for Oracle VM Server 2.1.1. Once the LiveSync rpm is installed on the Direct Attached Storage equipped Oracle VM Servers, High Availability Failover and LiveMigration are enabled. Clone VM support, a new feature which enables the cloning of VMs in less than fifteen seconds was also unveiled by Thinsy Corporation.

Yo por el momento no lo he visto asi que permanezco incredulo pero podria ser un fuerte varapalo para VMware puesto que la compra de una SAN es una de las cosas que suele tirar para atrás a las empresas a la hora de comenzar con la virtualizacion. Proximo episodio en su casa...

Thin Provisioned: Problemas con Storage VMotion, migraciones y clonaciones

2008-04-11T12:00:00.001+02:00

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:

Una vez preparada la VM (sysprep si es windows), tomaremos un snapshot del volumen que la contiene [snap create vol-name snapshot-name ].
Posteriormente creamos una VM en el Virtual Center pero sin disco. (Esto crea los ficheros de conf y el directorio)
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]
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

2008-04-07T21:00:00.001+02:00

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.

la funcion Shadow Copies de NetApp sobre CIFS

2008-04-03T21:00:00.001+02:00

El otro dia en Madrid asistimos a una demostración de NetApp. Hacía tiempo que tenía ganas, la verdad es que es una pasada, lo que no creo que sea igual es el precio....

Algo que muchos conocerán pero que me llamó muchisimo la atencion es la utilidad de acceder a las shadow copies de volumenes compartidos. Me explico, estas cabinas son capaces de presentar al usuario de la NAS que se ha conectado por CIFS una especie de historial (o versiones) de los archivos que almacena en los volumenes compartidos, es decir la funcion de snapshots de NetApp se integra con VSS(Microsoft Volume Shadow Copy Service) de tal forma que los usuarios pueden ver los snapshots tomados en la cabina via el cliente de VSS.
Es tan facil como pinchar en el menu contextual de un archivo (boton derecho), ir a propiedades y pichar la pestaña Versiones. La verdad es que es asequible para cualquier usuario y quitaría mucho trabajo a los administradores de sistemas que tienen que tirar de backup.

vmreference VI3 card

2008-03-25T11:01:00.006+01:00

Aunque sea posteo corto pero posteo. Aqui os dejo un enlace a un pdf muy muy útil en mi opinion. Es una especie de chuleta de Virtual Infrastructure 3 de VMware. Tips condensados en una hoja por las dos caras, desde la instalación, la localización de logs, resource pools, licencias, puertos, red, virtual center... vamos, una buena chuleta:

http://vmreference.googlepages.com/vmreferenceVI3Card1.1.pdf

Link para preparar VCP de VI3 de Vmware

2008-03-12T22:40:00.002+01:00

Hace mil años que no escribo nada... cosas del curro.
Aqui va un link que puede venir bien para echar un vistazo rapido y clarificar conceptos:
http://www.markwilson.co.uk/blog/data/vcpcram.pdf

StreetView de google, increible

2007-06-29T11:43:00.000+02:00

Otra vez mas nos sorprenden los amigos de google. A veces dan miedo:

http://maps.google.com/help/maps/streetview/index.html

Puedes hacer un tour virtual por los sitios que tienen metidos (por el momento 3). Requiere tener instalado la ultima version del flash player.

Script para Backup de VMs en caliente II

2007-06-28T15:41:00.000+02:00

El script que mencionaba esta en : http://www.xtravirt.com/ .
Va bastante bien y hay continuamente nuevas versiones.

Script para Backup de VMs en caliente

2007-05-25T18:02:00.000+02:00

Andaba yo buscando desde hacia tiempo algo que me puediera solucionar el backup de los discos duros de maquinas virtuales que estuviesen en produccion. Al menos de las windows que son las mas problemáticas.
He dado con un script que, por lo que llevo probado, lo hace a la perfección:

http://www.vmware.com/community/thread.jspa?threadID=70253&start=0&tstart=0

Es bastante activo el autor, asi que si teneis dudas preguntad en el foro!

Links para aprender Perl

2007-05-11T08:55:00.000+02:00

http://www.perl.com/pub/a/2000/10/begperl1.html
http://www.comp.leeds.ac.uk/Perl/start.html
http://www.wellho.net/forum/perl.html

VMware Player para probar .ISOs

2007-05-10T21:42:00.000+02:00

Nada, que andaba con la distribucion wifiSlax que no me arrancaba bien y me dije cómo puedo probar con el vmwarePlayer una .iso de un Live CD?
(Puede ser bueno para los probadores compulsivos de LiveCDs)

Pues nada creamos un fichero .vmx con un contenido similar a este:

config.version = "8"
virtualHW.version = "4"
memsize = "192"
ide1:0.present = "TRUE"
ide1:0.fileName = "D:\Mis Documentos\knoppix.iso"
ide1:0.deviceType = "cdrom-image"
floppy0.fileName = "A:"
usb.present = "TRUE"
displayName = "Knoppix"
guestOS = "otherlinux"
priority.grabbed = "normal"
priority.ungrabbed = "normal"
powerType.powerOff = "soft"
powerType.powerOn = "hard"
powerType.suspend = "hard"
powerType.reset = "soft"

workingDir = "."

Y lo arrancamos con VmPlayer. Los parametros son bastante explicativos de por sí. Los cruciales:
memsize = "memoria que reservará. Ojo que crea un fichero de dicho tamaño donde indique el parametro workingDir"
ide1:0.present = "TRUE"
ide1:0.fileName = "Ruta a la .iso"

Así ya tenemos una plantilla creada para ejecutar las distros que queramos y verles la cara.

Las que no sean ISOs de livecds también las cojerá pero no podrá instalar en el HD porque sencillamente no hay ninguno. Deberiamos poner un vmdk valido, etc...

Cluster GFS de maquinas virtuales con VmWare: Ideas

2007-05-10T01:39:00.000+02:00

Tengo desde hace tiempo en la cabeza el proyecto de realizar un cluster de maquinas virtuales bajo linux: Una solucion muy escalable y versatil que lleva implicta la alta disponibilidad.

Por el momento, todos los clusters que he visto nombrados en vmware son clusters de microsoft en maquinas vituales pero ninguno que corra sobre maquinas linux. Este estudio me servirá para determinar si es posible realizar esta solucion y si se puede llevar a produccion incluso para servidores tipo IMAP con millones de pequeños ficheros (situacion mas desafavorable para el filesystem).

De partida descarto Xen como tecnologia para virtualización en produccion. Yo esperaria un par de años antes de poner nada en produccion con paravirtualizacion. Tiene muy buena pinta pero si no quieres estar sufriendo una solucion recien nacida no os lo aconsejo.

La eleccion del sistema de ficheros GFS (o GFS2 si logro ponerlo) viene dado por los conocimientos que tengo (hemos echado a andar un cluster gfs para web(apache) y servidor de apps(tomcat) y funciona a las mil maravillas). Otras implementaciones como PolyServe están fuera de presupuesto.

Algunas ideas/pasos para ponerlo en marcha:

Instalacion de GFS en una maquina virtual.
En esto no creo que tengamos problemas, es identico a una maquina real. La instalación en un RedHat 4U4 la haré por rpms.

Clonacion.
Una vez tenemos una vm (nodo) del cluster bien configurado lo clonamos (con lo que tenga en eso momento, copiando discos vmdk y cambiando los vmx...). De esta forma tendrmos 3 nodos idénticos. Necesitariamos una vlan para señalización del gfs y otra vlan para los datos de aplicación.

Acceso Raw Device Mapping.
Las luns de datos estarán en una cabina DS4300, haremos un RDM de dichas luns.

Fencing.
Esta es una de las cosas que mas me preocupa. El fencing es la forma que tiene el gfs de impedir que un nodo corrompa el fs. Cuando un nodo ha perdido heartbeats (se envían por la red de señalización) los demas nodos que forman el cluster deciden que no tenga acceso a los datos. Esto se puede hacer de diversas formas: Por medio de un switch de corriente(apagando el nodo), Cortando el acceso a la lun de datos,etc.

Cuando los nodos son reales esto no supone ningun problema, pero ¿ Y con maquinas virtuales ? Buscando en google(herramienta de trabajo donde las haya) podemos ver que no hay mucho implementado a este respecto.

Podemos ver la solución que nos plantean aqui .
Se trata de un script de perl que manda un comanda com vmware-cmd al ESX remoto que alberga el nodo que ha perdido la comunicación.
Esta solución no es viable puesto que con ejecutar de forma local el comando vmware-cmd.pl ruta_a_la_vm.vmx off hard ya nos tardaría alrededor de 3,5", tiempo inaceptable para un cluster en producción puesto que hasta que el nodo no es 'fenceado' el nodo que 'fencea' no tiene acceso al FS.

La solución más inmediata y elegante es realizar el fenceo via RPC. Matando la vm, averiguando su pid a través de su numbre (nombre.vmx).

Las pruebas que llevo hasta ahora me dan tiempos de 40ms en local y desde remoto unos 80ms, claro que depende de la latencia de la red. Por ello nos viene muy bien el hecho de que la señalización vaya por una vlan diferente.

Pruebas de carga.
Bueno , esto está por ver. Es posible que se hagan pruebas con IMAP.

Espero escribir un poco mas sobre el tema pronto.