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

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.

Thin Provisioned: Problemas con Storage VMotion, migraciones y clonaciones

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

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

¿Como solucionarlo?

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

Pasos:

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