Una instalación inicial de vSphere™ ESXi usa el formato GPT – de las siglas en inglés GUID Particion Table – en lugar del formato MBR – de las siglas en inglés Master Boot Record – lo cual permite instalar ESXi 5 en discos con un tamaño superior a 2TB. No obstante, si actualizas de versión VMware ESX/ESXi 4.x a ESXi 5 no se usará el formato GPT, sino que se mantendrá el formato MBR.

Durante la instalación de vSphere™ ESXi 5, el installer de VMware escanea, no solo los discos locales conectados al servidor físico ESXi, sino que también hará un escaneo de los discos de tu SAN de FC y los mostrará si este tiene acceso a ellos.

Por consiguiente, y para evitar la instalación del binario de ESXi en una de tus LUNs de la SAN FC, recuerda esta “Best Practices” de VMware para evitar la sobre escritura de una LUN: Establece o solicita al administrador SAN de tu empresa un “LUN Masking” o mejor aún, si vas a instalar el binario en discos locales, desconecta los cables de la SAN de tu servidor ESXi.

Además, está mejor práctica reduce el tiempo que necesita el installer de VMware en buscar discos conectados al sistema. Si estás instalando un servidor ESXi en un disco que ya contiene una versión previa a la versión vSphere™ 5, el installer te da la opción de actualizar esa versión.

Cuando configuras una cabina SAN de FC con vSphere™, asegúrate de seguir las mejores recomendaciones:

1. Cada LUN debería contener solo un DataStore VMFS.
2. Cada LUN debería ser presentada a todos los servidores ESXi con el mismo LUN ID.

Hay cuatro opciones o métodos para instalar la nueva versión de VMware vSphere™ ESXi 5:

• Usando vSphere Auto Deploy
• Mediante una instalación vía script
• Actualizando un servidor ya existente con VUM (VMware Update Manager)
• Haciendo una instalación interactiva como se muestra en la imagen de cabecera de este post.

Esta última opción es el método de instalación recomendado cuando has de instalar un número pequeño de servidores VMware vSphere™ ESXi 5.

VMware vSphere™ 5 ha dejado de soportar máquinas virtuales de 32bit y VMM de 32bits. Solo Virtual Machine Monitors de 64 bits pueden ejecutar sistemas operativos de 32bits. Por consiguiente, el uso exclusivo de un VMM de 64bits en vSphere™ 5 requiere instrucciones específicas a nivel de CPU llamadas LAHF y SAHF, las cuales no se encuentran en arquitecturas de 32bit más antiguas. LAHF y SAHF solo están soportados en vSphere™ 5.

Para terminar, una vez instalado, un servidor VMware vSphere™ ESXi 5 puede tener hasta 256 LUNs FC (Fiber Channel) por servidor. Asimismo, el número máximo del ID en FC es de 255 pues los IDs de FC empiezan por el número 0 y no por el 1. Sin embargo, el número máximo de caminos iSCSI que un servidor ESXi pues ver es de 1.024.

¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Hoy veremos algunos puntos interesantes sobre el nuevo sistema de archivos de VMware (VMFS-5 de las siglas en ingles VMware File System) en la nueva versión de VMware vSphere 5.

Ahora, con VMware vSphere ESXi 5 y VMFS-5 es posible hacer una migración en caliente con Storage vMotion de una máquina virtual que tiene snapshots. Asimismo, VMFS-5 soporta un máximo de 9.000 discos virtuales por datastore.

A diferencia de versiones anteriores, en VMFS-5 solo existe una única opción de tamaño de bloque para los datastores formateados con la versión 5 de VMFS. Este block size es únicamente de 1MB y te permite crear discos virtuales con un tamaño de hasta 2Gb. Sin embargo, cuando actualizas VMFS-3 a la versión VMFS-5, la configuración del block size de tu datastore VMFS-3 es heredada, es decir, si tu datastore VMFS-3 fue configurado con un block size de 4MB, al actualizar a la versión VMFS-5 seguirá siendo de 4MB. Nota que el tamaño de bloque de un datastore VMFS-5 no actualizado no puede ser distinto de 1MB.

También ahora es posible con VMware vSphere ESXi 5 hacer un “unmount” del datastore, siempre y cuando se cumplan los tres requisitos siguientes:

1. El datastore no puede contener ninguna máquina virtual.
2. El datastore no puede ser usado por vSphere HA heartbeat.
3. El datatore no puede pertenecer a un datastore clúster.

VMware vSphere ESXi 5 soporta ahora hasta 3.000 máquinas virtuales por clúster HA/DRS con independencia del número de servidores ESXi que hayas configurado en tu clúster. Gracias VMware!

¿Crees que este videopost le puede interesar a alguien a quien conoces? Compártelo clicando los botones de Twitter, Facebook o Google+ de abajo. Gracias por tu apoyo.

Una de las preguntas que uno se plantea cuando que se encuentra ante un diseño de una plataforma de virtualización es la del diseño del almacenamiento en general y la del tamaño de las particiones o datastores donde se van a almacenar las máquinas virtuales en particular.

En particular esta última cuestión, el tamaño de los datastores, fue la que me planteó el otro día un cliente. Además me planteaba que plataforma, Microsoft Hyper-V o VMWare Hypervisor, tenía mayores límites, en lo que a almacenamiento se refiere.

En este sentido me gustaría presentaros esta semana una pequeña comparativa entre ambas plataformas en lo que a máximos de almacenamiento se refiere.

Antes de entrar en la comparativa en si misma creo importante hacer una pequeña diferenciación entre:

• Almacenamiento físico, es decir aquel almacenamiento que es gestionado o “visto” directamente por el hypervisor.
• Almacenamiento virtual, que para el caso que nos ocupa es el almacenamiento que es usado o “visto” directamente por la máquina virtual.

En el caso del almacenamiento físico antes de poder hacer uso del espacio disponible e independientemente de si se trata de almacenamiento DAS (Direct Attached Storage) o SAN (Storage Area Network) debemos particionar el almacenamiento para después formatearlo.

En este punto es donde llega la primera cuestión que debemos tener en cuenta, ¿de qué tamaño creo la partición? Estrictamente hablando y de forma absolutamente teórica el límite para particiones GUID estaría en 9.4 ZB (ZettaBytes ). El problema real es que una partición no deja de ser como un armario sin cajones, es decir, un espacio vacío donde no hay ni orden ni concierto. En este punto es donde entra en juego el sistema de ficheros. Volviendo al ejemplo anterior, un sistema de fichero sería el equivalente a los cajones, barras, perchas, etc que encontramos dentro del armario, es decir las estructuras que usamos para organizar la ropa, o los datos si hablamos de particiones.

Respecto a los números que nos interesan vemos que el tamaño máximo que puede tener una partición es de:

• VMFSv3 (VMware) 2 TB por partición única
• NTFSv6 (Microsoft) 2 TB por partición única

Pero es posible que un datastore (vmware) o un volumen (Microsoft) ocupe más de una partición, con lo que el tamaño máximo para un datastore o volumen crezca por encima de esos 2TB que acabamos de ver, en particular:

• VMFSv3 hasta 64TB para un único datastore, haciendo uso 32 particiones o “extends” de 2 TB cada una.
• NTFSv6 hasta 16 EB (ExaBytes) para un único volumen lógico.

Una vez que tenemos el armario organizado, es decir que hemos creado la partición y la hemos formateado con un sistema de ficheros, tenemos que meter la ropa dentro, las máquinas virtuales.

Las máquinas virtuales, como ya sabemos, hacen uso de discos virtuales que son, dicho de forma general, ficheros almacenados en un disco físico, los cuales tienen un formato bien definido que es interpretado por Virtual Machine Monitor (Hypervisor) como un disco duro.

Dicho esto, vemos que un disco virtual no deja de ser un fichero dentro de un disco físco, y como tal está sujeto a las limitaciones del sistema de ficheros. Para el caso que nos ocupa, el límite que nos debe preocupar es el de tamaño máximo de fichero, que para ambas plataformas es de 2 TB por fichero.

Por supuesto, en esta comparativa no entran el mapeo directo del almacenamiento a las máquinas virtuales, bien usando RDM o iSCSI.

Un último apunte que me gustaría hacer es que “simplemente por que podamos hacer algo no significa que debamos hacerlo”, por lo que os animaría a consultar las best practices antes de realizar configuraciones que se acerquen “peligrosamente” a los limites, ya que existen otras implicaciones además del tamaño del almacenamiento.

A continuación os pongo algunos enlaces de referencia para ampliar algo de información:

• VMware Configuration Maximums, Storage Maximums on ESX Host Maximums section
• How NTFS Works
• Practical limits to number of files in NTFS filesystem
• VMware Virtual Machine File System: Technical Overview and Best Practices
• Virtual Hard Disk Performance

SearchStorage.com acaba de publicar una entrevista con el CEO de Symantec acerca de la nueva infraestructura virtual “Veritas Virtual Infrastructure” que lanzó el miércoles.

El entrevistador menciona un interesante rumor:
SearchStorage: Se habla de que VMware podría estar buscando en sustituir VMFS con otro sistema de archivos en cluster. Está Symantec trabajando con ellos en eso?

Thompson: Si VMware está buscando en sustituir su VMFS (Virtual Machine file system), seremos todo oídos.

Si esto fuera cierto, implicaria un cambio importante en la estrategia de VMware y su relación con los proveedores de almacenamiento.