VMWARE: Instalar controladores No Certificados ESXi 5 U1

No siempre VMWare ESX/ESXi reconocen los dispositivos de red que incorporan las placas madres, lo bueno es que se pueden incorporar controladores que no vengan con la instalación de VMWare ESX/ESXi.

Voy a explicar como hacerlo con una Placa Madre marca GIGABYTE, modelo GA-G41MT-S2 la cual trae incorporado un adaptador de red Atheros AR8151 (10/100/1000 Mbit).

Primero ubicamos el controlador optimizado para nuestro dispositivo y lo descargamos.

En el foro de vm-help.com encontramos un hilo que habla sobre este controlador y lo descargamos el .zip desde este enlace.

Lo descomprimimos y nos tiene que generar un archivo con extensión .vib, en nuestro caso el archivo es: net-atl1e-1.0.1.14.x86_64.vib

VCAP – Sección 1.10 – VMware DirectPath I/O

Que tal Gente, el día de hoy comienzo con esta serie de posts como una referencia de todos los requerimientos para la certificación VCAP – DCA , la nueva certificación por parte de VMware, aquí les dejo un link hacia un documento donde podemos ver el glosario de todos los requerimientos en cuanto a conocimiento para poder aprobar el examen VDCA410:

http://communities.vmware.com/docs/DOC-12751

bueno como podemos aver notado en el titulo del post, vamos a hablar sobre DirectPath I/O, esta capacidad de VMware permite el uso de dispositivos PCI y PCI-e físicos del host ESX/ESXi por las maquinas virtuales.

Con esto todas las instrucciones que se tengan a dicho dispositivo no tiene que pasar por la capa de virtualización, quitando así el overhead que se tiene, VMs que requieran el uso de dispositivos para altas transacciones de I/O (ej. 10Gb Ethernet) son candidatos claros para el uso de esta tecnología. Actualmente se soportan interfaces de red y adaptadores de storage (HBAs de Fibra). Se pueden tener hasta 2 dispositivos PCI conectados a una VM.

Para poder hacer uso de esta tecnología debemos cumplir con las siguientes características:

• Instrucciones  Intel Virtualization Technology for Directed I/O (VT-d) , se pueden encontrar en arquitecturas Nehalem.
• Instrucciones en procesadores AMD IP Virtualization Technology (IOMMU).
• Las maquinas virtuales deben contar con hardware virtual versión 7.

Al activar esta función perdemos varias capacidades que nos ofrece VMware:

• VMotion
• Storage VMotion
• FT
• Hot add de dispositivos
• Suspender y resumir VM
• Record  & replay

Bueno espero haya quedado claro en que nos ayuda y que nos afecta, ahora vamos a conocer como lo activamos.

Paso 1-. Seleccionamos el Host ESX que esta alojando la VM en cuestión , navegamos a Configuration > Advanced Settings

Paso 2-. Se nos mostrará una ventana de VMDirectPath Configuration damos click en "Configure Passthrough", esto nos abrirá una pequeña ventana donde marcaremos el dispositivo.

Paso 3-. Una vez seleccionados los dispositivos, reiniciamos nuestro Host ESX/ESXi.

Paso 4-. Seleccionamos la VM a la cual queremos agregar dicho dipositivo, damos click derecho sobre la misma y "edit settings" y damos click en "add"

Paso 5-. Se nos abrirá una nueva ventana donde seleccionamos el tipo de hardware que deseamos agregar, seleccionamos PCI device y a continuación seleccionamos el dispositivo que marcamos para VMDirectPath

Con esto al iniciar nuestra VM podremos notar que se detecta el nuevo dispositivo.

VCAP – Sección 1.9 – NPIV

Que tal gente, hoy vamos a hablar de NPIV (N_Port ID Virtualization) continuamos con los temas de VCAP.

¿Que es NPIV?

Es un standard de ANSI T11 , con el cual tenemos la capacidad de asignar WWN (World Wide Name) por maquina virtual, con esto logramos compartir una misma HBA de fibra para varios WWNs , primero vamos a entender un escenario clasico de Fabric:

En esta imagen tenemos un servidor Fisicos conectado a un arreglo de discos a través de FC . Los componentes son los siguientes:

1-. Servidor

2-. Switch de fibra

3-. Almacenamiento

4-. N-port

5-. F-port

Aquí podemos ver claramente que parte de la fabric o de nuestra infraestructura es un N-Port, en pocas palabras es el puerto de nuestra HBA de fibra que se conecta hacia el switch de fibra.

Existen 2 tipos de WWN:

• WWNN: este identificador es asignado a cada uno de los nodos que conforman la fabric,  esta conformado por una serie de valores hexadecimales. Estos identificadores WWN pueden ser regenarados a diferencia de los WWPN. En el caso que el host tenga una HBA con varios puertos estos puertos compartirán el mismo WWNN.

• WWPN: Este identificador se asigna fisicamente a cada uno de los puertos, como pueden ser HBAs , puertos del almacenamiento, etc. Estos son valores únicos y no se pueden modificar. La comunicación entre el almacenamiento , switches y servidores se lleva a cabo entre los WWPNs.

Para que quede mas claro podemos tomar el ejemplo de un almacenamiento X que tenga 4 puertos de fibra, cada uno de estos puertos tendra un unico WWPN , y el almacenamiento en si tendra solo 1 WWN :

 

¿Que ventajas nos ofrece el NPIV?

• Menos componentes físicos, por lo tanto menos puntos de falla. Ej. con una HBA podemos asignar varios WWN para un grupo de máquinas, logrando así el poder administrar el almacenamiento por VM o aplicación.
• Seguridad Granular con NPIV podemos zonificar por VM con esto logramos restringir el acceso a LUNs.
• Monitoreo mucho mas granular, tomando en cuenta que cada máquina tendría un único identificador WWN podemos hacer uso de herramientas existentes para servidores físicos ya que la comunicación es etiquetada con sus identificadores.
• Movilidad, cada VM conserva su identificador WWN sin importar en que servidor se encuentre, con lo cual no requerimos hacer cambios en nuestra zonificación.

Desventajas:

• Solo funciona con RDMs , VMFS no esta soportado.
• FT no esta soportado
• Storage VMotion no esta soportado

 

Requerimientos:

• Switches de Fibra compatibles con NPIV
• HBAs de Fibra compatibles con NPIV (Brocade, Emulex y Qlogic)

Pasos para Configurar NPIV

Paso 1-. Tener un RDM agregado a nuestra VM, sin esto no tendremos habilitadas las opciones de NPIV.

*Nota para poder hacer uso de VMotion con NPIV necesitamos tener nuestro apuntador de RDM residiendo en el mismo datastore de nuestra VM y nuestro RDM tiene que ser creado en modo virtual.

Paso 2-. Hacemos click derecho sobre nuestra VM , y damos click en "edit Settings", una vez abierta la ventana de settings vamos a la pestaña de "options" y seleccionamos "generate".

Paso 3-. una vez creados los WWNs los utilizamos para realizar la zonificación de nuestro almacenamiento basandonos en estos.

 
¿Como puedo verificar la creación del VPORT?

Paso 1-. identificamos nuestra HBA

# ls /proc/scsi

Qlogic es identificado como qla2300

Emulex es identificado como lpfc

Paso 2-. Una vez encendida la VM con NPIV habilitado, ingresamos a nuestra service console y con el resultado de la identificación de nuestra HBA hacemos uso de los siguientes comandos (dependiendo que marca es nuestra HBA).

# cat /proc/scsi/qla2300/6 (Qlogic, sustituimos el numero "6″ por el numero de nuestra HBA)

Este comando nos dará información como la siguiente:

FC Port Information for Virtual Ports:
Virtual Port index = 1
Virtual Port 1:VP State = <ACTIVE>, Vp Flags = 0×0
scsi-qla2-port-3=500601609020fd54:500601601020fd54:a00000:1000: 1;
scsi-qla2-port-4=500601609020fd54:500601681020fd54:a10000:1000: 1;
Virtual Port 1 SCSI LUN Information:
( 0:10): Total reqs 10, Pending reqs 0, flags 0×0, 2:0:1000,

# cat /proc/scsi/lpfc/3 (Emulex, sustituimos el valor "3″ por el numero de nuestra HBA)

Se nos dará información como esta:

# cat /proc/scsi/lpfc/3
SLI Rev: 3
NPIV Supported: VPIs max 127 VPIs used 1
RPIs max 512 RPIs used 13
Vports list on this physical port:
Vport DID 0x2f0901, vpi 1, state 0×20
Portname: 48:19:00:0c:29:00:00:0d Nodename: 48:19:00:0c:29:00:00:0b

Desde nuestros Switches de fibra también podemos verificar que efectivamente se creo el VPORT:

Brocade: con el comando  "nsshow" el cual nos muestra información sobre el switch y de nodos conectados al mismo. Solo buscamos en los nodos los secuencia de valores "00:0c:29″ que hacen referencia a los VPORTs de VMware.

Qlogic: con el comando "show ns"  se nos mostrarán los nodos conectados , nuevamente solo necesitamos confirmar que existe la secuencia de valores "00:0c:29″ sobre la columna de "Node WWN"

VCAP – Sección 1.8 – Configurar,administrar plugins PSA y arquitecturas complejas

Que tal gente, el día de hoy vamos a hablar del objetivo 1.3 de nuestra guía de VCAP, en este caso estaremos tocando temas referentes a la nueva arquitectura para el manejo de nuestro almacenamiento en vSphere – PSA (Pluggable Storage Architecture).

Un poco antes de comenzar con esta serie de posts de VCAP publique este post:

vSphere – ¿Que es VMware PSA?

aquí plasmo de manera completa (a mi parecer) como está conformada esta nueva arquitectura de almacenamiento y que ventajas tenemos. Creo que faltan algunos puntos en este post, vamos a echar un  vistazo:

¿Como modifico el PSP (Path Selection Plugin) predefinido de un SATP (Storage Array Type Plugin)?

Ej. Para un almacenamiento reconocido como Activo/Activo se le asigna un PSP Fixed.  Ejecutando el siguiente comando podemos ver cuáles son las reglas predefinidas

esxcli nmp satp list

En este caso estaremos trabajando con un almacenamiento Netapp, el cual es activo/activo. Así que haremos las modificaciones a la regla correspondiente para cada vez que se detecte un LUN de este almacenamiento se le asigne Round Robin en lugar de MRU.

Aquí tenemos el cómo se detecta un LUN por default para este tipo de almacenamiento:

Este tipo de almacenamiento es detectado como "VMW_SATP_DEFAULT_AA" así que haremos las modificaciones necesarias en dicho SATP:

esxcli nmp satp setdefaultpsp –satp VMW_SATP_DEFAULT_AA –psp VMW_PSP_RR

–SATP (Storage Array Type Plugin)

–PSP (Path Selection Plugin) en este caso lo modificamos a "VMW_PSP_RR" el cual es Round Robin.

con esto tenemos el siguiente resultado:

Una vez reiniciado nuestro host ESX/ESXi detectará todas las LUNS presentadas por almacenamientos activo/activo y les asignará el PSP de Round Robin:

Configurar iscsi port binding (iscsi multipathing)

ISCSI al ser un protocolo basado en tcp/ip y en el caso de iscsi basado en software (manejado por el vmkernel) este entabla todas las comunicaciones a traves de nuestras pNICS o tarjetas de red. En el caso que nosotros quisiéramos tener varios "paths" o caminos también conocido como multipathing necesitamos seguir ciertos pasos para poder habilitar varios puertos de vmkernel para la comunicación de ISCSI.

Inicialmente tenemos una configuración como la siguiente, un puerto vmkernel y en el mismo vSwitch donde reside este puerto puede existir una o más tarjetas de red realizando un nic teaming.

En este punto tenemos comunicación con nuestro almacenamiento iscsi de manera redundante mas no distintos "paths" o caminos hacia dicho almacenamiento ya que la comunicación es a través de una sola ip del lado de nuestro servidor ESX/ESXi siguiendo los siguientes pasos habilitaremos la comunicación para dos puertos vmkernel esto lo conocemos como iscsi port binding:

Paso 1-. Creamos uno o más puertos vmkernel (segun numero de pNics):

 

Nos aseguramos que cada uno de los puertos de vmkernel estén utilizando una de las tarjetas asignadas a dicho vSwitch, damos click en "properties…" seleccionamos uno de los puertos de vmkernel y damos click en "edit" después seleccionamos el tab de "nic teaming" y marcamos el checkbox de "override vSwitch failover order", con esto tendremos la capacidad de seleccionar una pNIC como activa y la otra(s) desactivadas, esto lo realizamos en cada uno de los puertos de vmkernel asignados para nuestra comunicación ISCSI habilitando una tarjeta exclusiva para cada uno de ellos:

 

Paso 2-. En este momento necesitamos crear la asociación entre puerto vmkernel y pnic para que nuestro servidor ESX/ESXi sea capaz de utilizar ambos puertos para la comunicación ISCSI.

dentro de nuestro service console o del tsm (esxi) e ingresamos el siguiente comando para crear dicha asignación:

esxcli swiscsi nic add -n vmk1 -d vmhba33

-n nombre del puerto vmkernel, vmk#

-d hba de sw iscsi (esto lo verificamos en "configuration>Storage Adapters")

Paso 3-. Verificamos que efectivamente ya esta asignado el vmknic:

esxcfg-vmknic -l

 

VCAP – Sección 1.7 – Analizar comportamientos de I/O para determinar los requerimientos de almacenamiento

Que tal gente, continuando con los temas de VCAP nos toca hablar sobre el como analizar los comportamientos o workloads a nivel del almacenamiento, para esto estaremos primero entendiendo ciertos conceptos y factores que componen estos workloads.

Es importante conocer el comportamiento que tienen nuestras aplicaciones para poder hacer un correcto diseño de nuestra infraestructura, en este caso nos estamos enfocando al almacenamiento parte fundamental del performance que tendrán nuestras aplicaciones virtualizadas.

¿Que elementos determinan el performance de nuestro almacenamiento?

• IOPS: I/O per second, básicamente la cantidad de lecturas y escrituras que un disco puede realizar en un segundo, esto básicamente nos dirá la capacidad del disco o del tipo de disco que estaremos utilizando para responder a nuestras operaciones. Existen valores aceptados y utilizados como base para cada tipo de disco:

• Latencia: básicamente es la cantidad de tiempo que nuestro disco o almacenamiento tarda en responder a nuestras solicitudes en disco, este valor se mide en ms,  un valor aceptable estaría entre 5 ms a 10 ms dependiendo los requerimientos de las aplicaciones virtualizadas.
  

• Ancho de banda o capacidad del arreglo/disco/interfaz (Mbps): este ancho de banda depende de que interfaz estaremos utilizando, existen varias interfaces actualmente, IDE, SATA,SCSI,SAS y FC.  Estas interfaces son vistas de distinta manera en el lado de un almacenamiento central (SAN, NAS), ya que ahí estaríamos hablando de 2 tipos de interfaces, back-end y front-end. En el caso de back-end es la interconexión entre los distintos controladores o storage processors de dicho almacenamiento aquí generalmente hablamos de interfaces SAS y FC. Finalmente en el caso de Front-end hace referencia a la interfaz que tiene contacto directamente con los servidores o clientes de este almacenamiento, aquí demos interfaces de FC y ethernet (ISCSI , NFS ,CIFS).

• RAID: en un post anterior tocamos el tema de los niveles de RAID, aquí tenemos que tener en cuenta que el nivel de RAID implica cierta implicación al performance en cuanto a escritura se refiere , para ser más claro, debido a la paridad que se tenga dependiendo del nivel de RAID para poder hacer la escritura de un bloque tiene que también escribir los bloques de su paridad es por eso que debemos tener en consideración este punto en el momento de hacer el calculo de nuestro almacenamiento. Aquí les dejo el link a mi post anterior sobre los niveles de RAID:

http://hispavirt.wordpress.com/2010/10/11/vcap-%e2%80%93-seccion-1-%e2%80%93raid-y-vms/

• Cache: En los sistemas de almacenamiento central, incluso en los mismos discos que utilizamos día a día existe un factor clave para mejorar el performance, el cache, por cache entendemos escencialmente memoria RAM que actua como buffer almacenando las operaciones de I/O, existen 2 tipos de caches , volatiles y no volatiles estos se diferencian simplemente en si se pierde o no la información almacenada en el caso de perdida de energía. Generalmente el cache para operaciones de escritura es no volatil es decir no se pierde en el caso de perdida de energía al contrario del cache para lecturas. Al ser memoria RAM es mucho más veloz que cualquier sistema de disco con esto mejoramos significativamente el performance de nuestro almacenamiento debido a que las operaciones son almacenadas temporalmente en estos caches y después escritas a disco, con esto ganamos la capacidad de aceptar mas operaciones concurrentes y en el caso de lectura almacena las lecturas anteriores a disco y en casos de almacenamientos avanzados existen algoritmos que predicen que información será leída y se almacena en dicho cache para ser entregada mas rápido.

• Queuing: con esta capacidad del almacenamiento se encolan las operaciones de I/O para poder ser procesadas después, esto puede ser a nivel del almacenamiento y directamente en las HBAs de nuestros servidores.

• Coalescing: esta capacidad de algunos almacenamientos lo que realiza es ordenar las operaciones de I/O almacenadas en cache  en el caso que tengamos un comportamiento "random" con esto se busca reducir la cantidad de actividad en disco ya que los comportamientos de escritura serán uniformes.

¿Que tipos de comportamientos o workloads existen? ¿Que debo tener en cuenta?

Existen 2 principales tipos de comportamientos en cuanto a operaciones a disco se refiere, secuencial y random. En el caso de un comportamiento secuencial las operaciones de I/O se llevan a cabo de manera más rápida debido a que se necesita un menor numero operaciones de "seek" que básicamente lo que se realiza es un posicionamiento de la aguja del o los discos en el correcto sector donde reside la información. Al contrario en el caso de un comportamiento random o al azar las operaciones de I/O estarán tratando de acceder a distintos sectores del almacenamiento, aumentando así las operaciones de seek a este tiempo se le llama "seek latency".

Una vez que sabemos que tipo de comportamiento tiene nuestra aplicación sea secuencial o random es importante tener en cuenta los siguientes elementos:

• tamaño de las operaciones I/O (I/O request size):  el tamaño de la información leída o escrita a nuestro almacenamiento, entre más grande el tamaño de nuestra operación ej. 64k será más eficiente de procesar y decrece el uso de procesador. Existen distintos tamaños, podemos ver 2k, 4k, 8k, etc. En el caso que quisiéramos virtualizar servidores Windows podemos determinar el tamaño de nuestras operaciones utilizando perfmon y ejecutando el siguiente counter "Avg. Disk Bytes/Read".
• porcentaje de escritura y/o lectura: importante para determinar el nivel de RAID a utilizar, ej. en el caso de aplicaciones que requieran un alto nivel de escritura se benefician de un raid 10.

¿Como puedo obtener todos estos datos?

• Windows perfmon — http://www.windowsnetworking.com/articles_tutorials/Key-Performance-Monitor-Counters.html
• Esxtop — http://www.yellow-bricks.com/esxtop/
• vscsiStats    — http://hispavirt.wordpress.com/2010/07/05/paso-a-paso-vscsistats/ , http://communities.vmware.com/docs/DOC-10095
• herramientas de proveedores de almacenamiento
• VMware Capacity Planner

VCAP – Sección 1.6 – LUN masking utilizando comandos de PSA

Que tal gente, continuando con los temas para la preparación de VCAP nos toca hablar de cómo hacer un mask o prevenir que ciertos hosts ESX/ESXi puedan tener visibilidad de algún LUN en especifico, esto basándonos sobre el nuevo plugin de PSA MASK_PATH de PSA.

En el diseño de nuestra arquitectura siempre es importante tomar en cuenta la cantidad de Hosts que estarán accediendo concurrentemente a un LUN, debido a que a mayor cantidad de hosts , mayor cantidad de operaciones SCSI. Si nosotros tenemos un granja de servidores ESX/ESXi 15+  servidores es un punto que tenemos que tener muy presente, aquí es donde entra el objetivo de enmascarar ciertas LUNs para ciertos hosts.

Generalmente este enmascaramiento lo hacemos del lado de la SAN y lo conocemos como zoning, pero también tenemos la capacidad de hacer este enmascaramiento directamente en los hosts ESX/ESXi, tengamos en cuenta que lo recomendado y lo más sano en términos de administración es hacerlo del lado de nuestro almacenamiento.

¿Cómo enmascaro algun LUN en mis hosts ESX/ESXi?

Paso 1-. Ingresamos a nuestro servidor ESX/ESXi con el vSphere Client, una vez dentro, navegamos a configuration>Storage Adapters

Paso 2-. Seleccionamos el adaptador a través del cual se esté llegando a dicho almacenamiento (HBA de FC , SW iscsi o HBA de ISCSI). Una vez seleccionado, en  los detalles de dicho adaptador encontraremos 2 tipos de vista Devices/Paths , damos click en Paths, aquí se nos mostrará cuales son los paths a través de los cuales se llega a dicho almacenamiento:

Paso 3-. Una vez que ya tenemos enlistados los paths, es cuestión de crear reglas para enmascarar cada uno de ellos, comenzamos por enlistar las reglas existentes para poder saber con que numero de regla podemos comenzar:

esxcli corestorage claimrule list

Paso 4-. Creamos las reglas necesarias (numero de paths) para enmascarar dicho LUN:

esxcli corestorage claimrule add -P MASK_PATH -r 120 -t location -A vmhba33 -C 3 -T 0 -L 0
esxcli corestorage claimrule add -P MASK_PATH -r 121 -t location -A vmhba33 -C 2 -T 0 -L 0
esxcli corestorage claimrule add -P MASK_PATH -r 122 -t location -A vmhba33 -C 1 -T 0 -L 0
esxcli corestorage claimrule add -P MASK_PATH -r 123 -t location -A vmhba33 -C 0 -T 0 -L 0

-C Canal o channel

-T destino o Target

-L LUN

-A adaptador

Recuerden que estos son los elementos del runtime name

Paso 5-. Cargamos las reglas que recién creamos y verificamos que efectivamente ya se muestran en la lista de reglas:

esxcli corestorage claimrule load

esxcli corestorage claimrule list

Paso 6-. Si se trata de un LUN que ya se presentaba en nuestro host ESX/ESXi, necesitamos quitar la regla actual:

esxcli corestorage claiming unclaim -t location -A vmhba33

Paso 7-. Ejecutamos nuestras reglas:

esxcli corestorage claimrule run

Una vez realizados estos pasos ya hemos enmascarado dicho LUN a nuestro host, si ingresamos con nuestro vSphere client y navegamos a configuration>Storage Adapters se nos muestran los paths como "dead":

VCAP – Sección 1.5 – Entendiendo y aplicando resignature a volumenes VMFS

Que tal Gente, el día de hoy les voy a hablar sobre de resignature de nuestros VMFS. Los servidores ESX/ESXi necesitan diferenciar entre sus datastores de VMFS , es por eso que desde la versión de VI3 se introdujo un mecanismo para cumplir con esto VMFS resignaturing.

En estos tiempos casi todos los almacenamientos centrales cuentan con mecanismos de protección o respaldo de datos a nivel del almacenamiento, entre los muchos que podemos encontrar están los snapshots (No de VMware), estos snaps de almacenamiento lo que hacen es tomar el estado de algún LUN en un momento especifico, teniendo así un copia exacta byte por byte pero además de copiar la información que se encuentra en la misma se copia el metadata del volumen aquí es donde tenemos problemas con VMware debido a que los servidores ESX distinguen sus Datastores basados en un UUID (Universally Unique Identifier) y este uuid se encuentra en el metadata de dichos volúmenes es un valor hexadecimal de 16 caracteres asignado por el LVM.

¿Cómo puedo saber el UUID de mi volumen VMFS?

Haciendo uso de vmkfstools.

vmkfstools -P -h /vmfs/volumes/nombredevolumen

-P nos permite la lectura del metadata

-h nos presenta la información en MB y GB

¿Como esta compuesto este UUID?

 

Primera parte (verde) — El tiempo de nuestro COS (console of service).

Segunda parte (azul) — El tiempo TSC (time stamp counter) métrica propia del CPU para llevar una cuenta de tiempo.

Tercera parte (naranja) — valor aleatorio.

Cuarta Parte (rojo) — MAC address de nuestra COS.

 

En el momento que nosotros presentamos un LUN que sea snapshot o copia de un mismo LUN que ya este dado de alta en nuestros servidores ESX/ESXi se generarán entradas en el log de vmkernel, si hacemos un "tail -f /var/log/vmkernel.log"  en el caso de ESX y "tail -f /var/log/messages |grep vmkernel"  en el caso de ESXi veremos entradas como:

vmhba0:0:0:1 may be snapshot

esto nos indica que se ha presentado un LUN que tiene un mismo UUID de algún LUN que se está utilizando. Podemos verificar esto ejecutando el siguiente comando:

esxcfg-volume -l

Esto nos mostrará algo como lo siguiente en caso de tener un snapshot LUN:
VMFS3 UUID/label: 49d22e2e-996a0dea-b555-001f2960aed8/VMFS_1
Can mount: Yes
Can resignature: Yes
Extent name: naa.60a98000503349394f3450667a744245:1 range: 0 – 97023 (MB)

Aquí tenemos varias opciones para el montaje de dicho LUN:

• Forzar el montaje de un snapshot lun hasta el siguiente reboot del Host ESX

esxcfg-volume -m <UUID|nombredeVMFS>

ej.   esxcfg-volume -m "49d22e2e-996a0dea-b555-001f2960aed8″

• Forzar el montaje de un snapshot lun de forma persistente (se monta sin importar reinicios)

esxcfg-volume -M "49d22e2e-996a0dea-b555-001f2960aed8″

• Realizar un resignature del snapshot LUN (cambio de UUID),se monta inmediatamente:

esxcfg-volume -r "49d22e2e-996a0dea-b555-001f2960aed8″

 

¿Cómo realizo operaciones de resignature desde el vSphere Client?

1. Ingresamos con nuestro vSphere Client y seleccionamos nuestro Host ESX/ESXi y seleccionamos la pestaña de "configuration".
2. Seleccionamos "Storage" y damos click en add storage.
3. Seleccionamos Disk/LUN.
4. En la lista de LUNs presentadas seleccionamos aquella que en la columna de "VMFS label"  tenga un nombre de datastore, en este mismo nombre se nos mostrará que es un snapshot.
5. en Mount options seleccionamos "assign a new signature" y damos next.
6. Finalizamos el proceso.