Pasos de migración offline de SCSI a almacén de datos VMware VMFS NVMe

Pasos de migración de almacén de datos de VMFS offline de SCSI a NVMe

Tabla de contenido

• Pasos de migración de almacén de datos de VMFS offline de SCSI a NVMe 1
• Descripción general
• Alcance

1. Pasos de migración offline
   1.  Antes de la migración
   2. Compruebe la cantidad de dispositivos y las rutas a cada host ESXi 3 
   3. Compruebe si hay características no soportadas 4 
   4. Comprobar el posible impacto posterior a la migración en las características soportadas 4 
2. Migración
   1. Desmontar el volumen VMFS de todos los hosts 5 
   2. Compruebe la coherencia de metadatos del volumen VMFS. 5 
   3. Volver a firmar el volumen VMFS 10 
   4. Cambiar el nombre del almacén de datos VMFS (opcional) 11 
   5. Compruebe la coherencia de metadatos del volumen VMFS después de volver a firmar. 11 
   6. Presentar el dispositivo como NVMe a todos los hosts ESXi del clúster 11 
   7. Registre y encienda todas las VM 11 
3. Después de la migración. 12 

 

---

 

Descripción general

Con el crecimiento de la adopción de NVMe, más clientes buscan migrar datos de SCSI a NVMe. En este documento, se describe uno de los métodos eficientes, aunque disruptivos, para migrar SCSI a NVMe conocido como migración offline. La migración del almacén de datos VMFS offline de SCSI a NVMe no implica la transferencia de datos. El dispositivo que se presentó anteriormente a un host o clúster ESXi como un dispositivo SCSI, deja de presentarse y, a continuación, se vuelve a presentar como un dispositivo NVMe. A continuación, el almacén de datos VMFS se vuelve a firmar y se pone a disposición de los hosts, conservando su contenido de VM. Los detalles de los pasos de migración offline se describen a continuación.

Alcance

• Los pasos para la migración offline, que se describen en las secciones siguientes, se aplican únicamente a los almacenes de datos VMFS6.
• Los pasos cubren los aspectos funcionales de la migración y no las características de rendimiento de las cargas de trabajo posteriores a la migración.
• La validación de escala (cantidad de migraciones simultáneas, etc.) o límites (rutas máximas por dispositivo, VMDK máximos por VM, etc.) no está dentro del alcance.
• Los términos dispositivo, volumen y LUN se utilizan indistintamente en el documento.
• La migración offline requiere que todas las VM del almacén de datos VMFS se apaguen antes de iniciarse.  

 

---

 

1. Pasos de migración offline

   La migración offline de un almacén de datos VMFS6 de SCSI a NVMe consta de tres fases. Cada fase puede implicar varias comprobaciones o pasos.

   1. Antes de la migración

      Esta fase preparatoria incluye comprobaciones para comprender las características del entorno y las características que están en uso. Esta fase es necesaria para determinar si la migración offline es factible en el entorno y también para comprender el impacto posterior a la migración. A continuación se enumeran algunas de las comprobaciones importantes. Esta no es una lista exhaustiva, sino que abarca las comprobaciones más comunes en un entorno de cliente estándar.

   2. Compruebe el modo de bloqueo del volumen VMFS

      En primer lugar, asegúrese de que el LUN sea compatible con el modo ATS. La migración se debe intentar solo si el almacén de datos VMFS6 utiliza el modo de bloqueo solo de ATS y no utiliza reservas de SCSI-2. 
      
      Para determinar el modo de bloqueo de un volumen determinado, ejecute el comando esxcli storage vmfs lockmode list -l <volume name/label> en un host ESXi con acceso al almacén de datos. La migración offline solo se admite si el modo de bloqueo para el volumen VMFS6 es "ATS". El modo "ATS+SCSI" no es compatible.
      
      Un ejemplo de un volumen que admite la migración offline:

      esxcli storage vmfs lockmode list -l testVol1
      Volume Name UUID                                Type   Locking Mode ATS Compatible ATS Upgrade Modes ATS Incompatibility Reason
      
      ----------- ----------------------------------- ------ ------------ -------------- ----------------- --------------------------
      
      testVol1    5d1c5b0f-xxxxxxxx-xxxx-246e9xxxxdb0 VMFS-6 ATS          true           No upgrade needed
      
      An example of a volume not supporting offline migration:
      
      esxcli storage vmfs lockmode list -l testVol2
       Volume Name UUID                                Type   Locking Mode ATS Compatible ATS Upgrade Modes ATS Incompatibility Reason
      
      ----------- ----------------------------------- ------ ------------ -------------- ----------------- --------------------------
      
      testVol2    63510e51-xxxxxxxx-xxxx-246e9xxxxde6 VMFS-6 ATS+SCSI     false          None              Device does not support ATS

       

   3. Compruebe si hay alguno vmdk de cualquier VM en el almacén de datos seleccionado se utiliza como RDM (física o virtual)

      Si una VM en el almacén de datos seleccionado tiene un RDM en modo SCSI, no se le puede permitir migrar a NVMe. No hay ningún comando de VMware para descubrir si una VM tiene un RDM; sin embargo, el plug-in de VSI de Dell enumera el tipo de disco para cada VM. A continuación, se muestra una captura de pantalla de la vista en VSI en la que se indica si alguna VM (nombre de tiempo de ejecución) tiene un RDM.
      
       
       

      Si una VM tiene un RDM, este debe eliminarse de la VM, convertirse o transferirse a otro almacén de datos antes de la migración.

   4. 1.3 Compruebe la asignación de reglas/ajustes de reclamación al dispositivo que aloja el almacén de datos VMFS

      Si hay reglas de reclamación personalizadas en el dispositivo SCSI antes de la migración, es probable que no se apliquen al dispositivo cuando se presenten mediante NVMe. Los dispositivos NVMe no se presentan con campos de proveedor y modelo separados cuando se accede a ellos a través de una consulta. Los campos están juntos y, por lo tanto, se necesita una nueva regla de notificación si así se desea. Además, las reglas de notificación basadas en identificadores de dispositivos, por ejemplo, World Wide Name (WWN) fallarán, ya que el identificador SCSI y el identificador NVMe son distintos.
      De manera predeterminada, VMware reclamará los dispositivos NVMe presentados recientemente con el plug-in de rutas predeterminado de HPP.

   5. Compruebe la cantidad de dispositivos y las rutas a cada host ESXi

      NVMe admite menos dispositivos y rutas que SCSI para cada host ESXi. Si la cantidad de dispositivos SCSI supera los límites de NVMe, no es posible convertir todos los almacenes de datos en el mismo host ESXi. Como solución, los clientes pueden emplear más hosts ESXi o consolidar almacenes de datos antes o después de la conversión con Storage vMotion. 

      1. SCSI: 1024 dispositivos/4096 rutas
      2. NVMe: 256 dispositivos/2048 rutas

   6. Compruebe si hay características no compatibles 

      Algunas características de VMware actualmente no son compatibles con NVMe. Compruebe la compatibilidad antes de la migración.

      Por ejemplo, las siguientes características no son compatibles actualmente con NVMe que se ejecuta en ESXi (hasta la versión 8.0U1).

       

      Característica	Breve descripción	Observaciones
      Agrupación en clústeres de invitados	Función de VMDK en clúster que admite soluciones de alta disponibilidad, como el clúster de conmutación por error de Windows Server (WSFC)	Un almacén de datos VMFS con VMDK Enabled no se puede migrar.
      SRM	La replicación basada en arreglos con SRM no es compatible con NVMe.	La migración de almacenes de datos relacionados con la replicación de arreglos de SRM hace que la solución sea inútil.

       
      Nota: La lista anterior no es exhaustiva. Los clientes deben consultar la documentación específica del arreglo con respecto al impacto de la migración en las características críticas.

   7. Comprobar el impacto potencial de la posmigración en las características soportadas

      La falta de integración de las siguientes características puede cambiar el rendimiento de ciertas operaciones en NVMe en comparación con SCSI.

      Característica	Naturaleza del impacto	Medidas que deben adoptarse
      Transferencia acelerada de hardware: XCOPY	En la actualidad, no existe un comando equivalente a XCOPY. En su lugar, se utiliza el administrador de transferencia de datos de software de VMware. Esto podría disminuir el rendimiento de las operaciones que utilizan la primitiva, como la clonación o SvMotion.	Ninguno
      Write Same/UNMAP	Si un dispositivo NVMe no es compatible con el equivalente NVMe de los ceros de escritura o unmap, podría haber un impacto en el rendimiento.	Ninguno

 

---

 

1. Migración

   Esta fase implica los pasos para migrar el almacén de datos de SCSI a NVMe.

2. Apague todas las VM y anule el registro

   Apague y anule el registro de todas las VM alojadas en el almacén de datos que se migrará. Asegúrese de no eliminarlos, solo anule el registro.

3. Desmontar el volumen VMFS de todos los hosts

   Desmonte el volumen VMFS de todos los hosts ESXi una vez que se anule el registro de todas las máquinas virtuales. Esto es para asegurarse de que no esté en uso cuando se realice la comprobación de coherencia y la migración

4. Comprobar la coherencia de metadatos del volumen VMFS

   Antes de iniciar la migración, compruebe la coherencia de los metadatos en disco de VMFS. Esto garantiza que no haya inconsistencias antes de comenzar.

   1. Ejecutar VOMA (Analizador de metadatos en disco de VMware) en modo de comprobación mediante la ejecución de lo siguiente:

   voma -m vmfs -f check -d /vmfs/devices/disks/<DEVICE>:<PARTITION> -s <OUTPUT FILE>

    

   Dónde:

   DEVICE es el dispositivo SCSI que aloja el volumen VMFS6 que se está migrando

   PARTITION es el número de partición en el que se formatea el volumen VMFS en el dispositivo

   OUTPUT FILE es la ruta absoluta del archivo en el que se debe guardar la salida del comando. Este archivo se puede encontrar en /tmp si tiene suficiente espacio o cualquier volumen VMFS que no sea el que se está migrando.

   Como en:

    

   voma -m vmfs -f check -d naa.60000970000120200302533030313031:1 -s /tmp/voma.out

   El resultado debe ser similar al siguiente:

   [root@dsib0184:/dev/disks] voma -m vmfs -f check -d naa.60000970000120200302533030313031:1
   Running VMFS Checker version 2.1 in check mode
   Initializing LVM metadata, Basic Checks will be done
   
   Checking for filesystem activity
            Scsi 2 reservation successful                       st activity (4096 bytes/HB, 1024 HBs).                            
   Phase 1: Checking VMFS header and resource files
      Detected VMFS-6 file system (labeled:'SRM_UPGRADE_1') with UUID:6418928f-d0fb0a78-fa29-34800d0ed39c, Version 6:82
   Phase 2: Checking VMFS heartbeat region
   Phase 3: Checking all file descriptors.
   Phase 4: Checking pathname and connectivity.
   Phase 5: Checking resource reference counts.
   Total Errors Found:           0

   Nota: Si el comando recibe el siguiente error, el VMFS no se desmonta correctamente:

    

VOMA No se pudo verificar el dispositivo: Dispositivo o recurso ocupado

2. Analice el archivo de salida para ver si hay incoherencias en los metadatos informadas por voma. Si hay alguna, se debe abordar mediante la ejecución de voma en el modo de corrección avanzada antes de continuar. A continuación se presenta un ejemplo:

[root@dsib0184:/dev/disks] voma -m vmfs -f fix -d naa.60000970000120200302533030313031:1
Running VMFS Checker version 2.1 in fix mode
Initializing LVM metadata, Basic Checks will be done
Checking for filesystem activity
         Scsi 2 reservation successful                       st activity (4096 bytes/HB, 1024 HBs).                            
Phase 1: Checking VMFS header and resource files
   Detected VMFS-6 file system (labeled:'SRM_UPGRADE_1') with UUID:6418928f-d0fb0a78-fa29-34800d0ed39c, Version 6:82
Phase 2: Checking VMFS heartbeat region
Phase 3: Checking all file descriptors.
Phase 4: Checking pathname and connectivity.
Phase 5: Checking resource reference counts.
Total Errors Found:           0
Total Errors Fixed:           0
Total Partially Fixed errors: 0

 

3. Recopile y guarde el volcado de metadatos de VMFS. Esto sería necesario si se observan incoherencias en los metadatos en los pasos posteriores. 

Consulte https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.html para obtener más detalles sobre el uso voma En Check, Advanced Fix Mode o Dump Mode.

Desconectar LUN SCSI de hosts ESXi

Desconecte el LUN SCSI de cada host ESXi en el VC. Consulte el artículo de la base de conocimientos https://kb.vmware.com/s/article/2004605 para conocer los pasos detallados.

 

Detener la presentación de LUN SCSI desde el arreglo.

Los pasos para anular la presentación del LUN SCSI son específicos del arreglo de almacenamiento. Los clientes deben consultar la documentación específica del arreglo sobre el procedimiento.

 

Presente el dispositivo como NVMe a un host ESXi.

Los pasos para volver a presentar el dispositivo mediante NVMe son específicos del arreglo de almacenamiento. Los clientes deben consultar la documentación específica del arreglo sobre el procedimiento. 

Inicie la reexaminación del dispositivo en el host.

Una vez que el dispositivo se presenta al host ESXi mediante NVMe, el descubrimiento suele ser inmediato. Sin embargo, si el dispositivo no aparece, vuelva a analizar uno o más adaptadores mediante la interfaz de usuario o la CLI de vSphere:
 

esxcli storage core adapter rescan -a

 

Compruebe la coherencia de metadatos del volumen VMFS después de la conversión.

En el host ESXi que tiene acceso al dispositivo, vuelva a ejecutar voma en modo de comprobación para validar que los metadatos en disco de VMFS sigan siendo coherentes. Cualquier incoherencia en los metadatos se debe investigar antes de continuar. 
Voma utiliza el comando SCSI-2 reserve para bloquear el dispositivo a fin de evitar cualquier acceso o modificación simultáneos del volumen VMFS cuando la sesión de voma está activa. Sin embargo, los dispositivos NVMe no admiten un equivalente de una reserva SCSI-2. Para solucionar esto, el usuario debe pasar el comando "-N" a VOMA cuando el dispositivo de back-end es NVMe. Por ejemplo:

• Ejecutar VOMA (Analizador de metadatos en disco de VMware) en modo de comprobación mediante la ejecución de lo siguiente:

 

voma -m vmfs -f check -N -d /vmfs/devices/disks/<DEVICE>:<PARTITION> -s <OUTPUT FILE> 

Cuando… voma se invoca con "-N", se muestra el siguiente mensaje de advertencia. 

 

########################################################################
# Warning !!! #
# #
# You are about to execute VOMA without device reservation. #
# Any access to this device from other hosts when VOMA is running #
# can cause severe data corruption #
# #
# This mode is supported only under VMware Support supervision. #
########################################################################
VMware ESXi Question:
Do you want to continue (Y/N)?
0) _Yes
1) _No

Seleccione un número entre 0 y 1:
Esto es para notificar que es responsabilidad del usuario evitar que el volumen se monte o se acceda simultáneamente desde otros hosts mientras la sesión de voma actual está en curso. Si se siguieron los pasos descritos aquí y el dispositivo se asignó y descubrió en un solo host ESXi, entonces debería ser seguro continuar. El usuario debe ingresar "0" en el símbolo del sistema para continuar con el modo de comprobación de voma. A continuación, se muestra un ejemplo:
 

[root@dsib0180:~] voma -m vmfs -f check -N -d /vmfs/devices/disks/eui.03025330303130420000976000012020:1

Ejecución de VMFS Checker versión 2.1 en modo
de comprobación Inicialización de metadatos de LVM, se realizan
comprobaciones básicas Comprobación de la actividad
del sistema de archivos La compatibilidad con reservas no está presente para los dispositivos NVMe actividad st (4096 bytes/HB, 1024 HB).                                 \
Realizando la comprobación de ejecución del sistema de archivos..|

########################################################################
#   Warning !!!                                                        #
#                                                                      #
#   You are about to execute VOMA without device reservation.          #
#   Any access to this device from other hosts when VOMA is running    #
#   can cause severe data corruption                                   #
#                                                                      #
#   This mode is supported only under VMware support supervision.      #
########################################################################

VMware ESXi Question:
Do you want to continue (Y/N)?

0) _Yes
1) _No

Select a number from 0-1: 0

Phase 1: Checking VMFS header and resource files
   Detected VMFS-6 file system (labeled:'Temp_Datastore') with UUID:64359f88-dd0fd27e-af5a-34800d0ed39c, Version 6:82
Phase 2: Checking VMFS heartbeat region
Phase 3: Checking all file descriptors.
Phase 4: Checking pathname and connectivity.
Phase 5: Checking resource reference counts.
Total Errors Found:           0

Seleccione un número del 0 al 1:

0 Fase 1: Comprobación del encabezado VMFS y los archivos
de recursos Se detectó un sistema de archivos VMFS-6 (etiquetado:'Temp_Datastore') con UUID:64359f88-dd0fd27e-af5a-34800d0ed39c, Version 6:82
Fase 2: Comprobación de la región
de latido de VMFS, fase 3: Comprobación de todos los descriptores de archivos.
Fase 4: Comprobando el nombre de ruta y la conectividad.
Fase 5: Comprobación de conteos de referencias de recursos.
Total de errores encontrados:           0

Volver a firmar el volumen VMFS 

Ahora que el dispositivo se presenta como NVMe, es necesario actualizar la firma que se encuentra en el almacén de datos. Esto se debe a que la firma actual se basa, en parte, en el WWN del dispositivo cuando se presenta mediante SCSI. Dado que el ID del dispositivo NVMe es diferente, se debe generar una nueva firma. Por lo tanto, en el mismo host ESXi que se utilizó en los dos pasos anteriores, ejecute lo siguiente para volver a firmar el volumen:

1. Aunque es redundante, vuelva a examinar el sistema de archivos mediante la ejecución del comando:

 

esxcli storage filesystem rescan

2. A continuación, ejecute el siguiente comando para obtener una lista de LUN de instantáneas de VMFS:

 

esxcli storage vmfs snapshot list

El dispositivo NVMe recién presentado debe estar presente, aunque, según el entorno, podría haber otras instantáneas no relacionadas con este proceso.

3. Vuelva a firmar el volumen VMFS mediante la ejecución de lo siguiente:

esxcli storage vmfs snapshot resignature --volume-label=<label>|–volume-uuid=<id>  

A continuación, se muestra un ejemplo:
 

[root@dsib0180:~] esxcli storage filesystem rescan
[root@dsib0180:~] esxcli storage vmfs snapshot list
64359f88-dd0fd27e-af5a-34800d0ed39c
   Volume Name: Temp_Datastore
   VMFS UUID: 64359f88-dd0fd27e-af5a-34800d0ed39c
   Can mount: true
   Reason for un-mountability:
   Can resignature: true
   Reason for non-resignaturability:
   Unresolved Extent Count: 1
[root@dsib0180:~] esxcli storage vmfs snapshot resignature -l Temp_Datastore

 

Cambiar el nombre del almacén de datos VMFS (opcional)

Cuando se vuelve a firmar un volumen VMFS, la etiqueta del volumen VMFS lleva como prefijo la etiqueta "snap" seguida de una cadena alfanumérica. Por ejemplo, el almacén de datos VMFS en el paso anterior ahora se denomina: snap-5c42a2bc-Temp_Datastore Si lo desea, vuelva a cambiar el nombre del almacén de datos al nombre original y elimine el prefijo.

Compruebe la coherencia de metadatos del volumen VMFS después de volver a firmar.

Una vez más, valide que los metadatos de VMFS en disco sean coherentes después de volver a firmar. Ejecute voma en modo de comprobación en el volumen VMFS. Consulte la sección 2.8 para ver la línea de comandos de voma, que debe incluir el indicador "-N". Verifique si voma informa incoherencias. Continúe si voma no informa ningún error. 

Presente el dispositivo como NVMe a todos los hosts ESXi del clúster.

Si no hubo problemas en ninguno de los pasos anteriores, el dispositivo ahora se puede presentar mediante NVMe a todos los hosts ESXi del clúster. Como se indicó, los dispositivos NVMe se reconocen de inmediato, pero si no es así, vuelva a analizar los adaptadores mediante la interfaz de usuario o la CLI de vSphere. Verifique que el volumen VMFS6 esté montado y que se pueda acceder a él en todos los hosts.

Registre y encienda todas las VM

Registre todas las VM alojadas en el almacén de datos y enciéndalas. Verifique que las VM se enciendan correctamente y que puedan acceder a los VMDK. Como práctica recomendada, el usuario puede registrar y encender máquinas virtuales en un solo ESXi. Una vez que se realicen correctamente, se podrán migrar a otros hosts.

Nota: Cuando se encienden las VM desde la interfaz de usuario de vCenter, es posible que aparezca una ventana emergente como la que se muestra a continuación. Esto solicita al usuario que registre si la VM se copió o transfirió. Seleccione "Lo copié" en la ventana emergente.

 

 

---

 

Después de la migración

Verifique el impacto en cualquier característica clave y realice cualquier limpieza si es necesario. 

1.4 Compruebe la cantidad de dispositivos y las rutas a cada host ESXi 3
1.5 Compruebe si hay características no soportadas 4
1.6 Compruebe el posible impacto posterior a la migración en las características soportadas 4
2.  Migración 4
2.2 Desmontar el volumen VMFS de todos los hosts 5
2.3 Comprobar la coherencia de metadatos del volumen VMFS.
5 2.9 Volver a firmar el volumen VMFS 10
2.10 Cambiar el nombre del almacén de datos VMFS (opcional) 11
2.11 Comprobar la coherencia de metadatos del volumen VMFS después de volver a firmar. 11
2.12 Presentar el dispositivo como NVMe a todos los hosts ESXi del clúster 11
2.13 Registrar y encender todas las VM 11
3. Después de la migración. 12

Descripción general

Con el crecimiento de la adopción de NVMe, más clientes buscan migrar datos de SCSI a NVMe. En este documento, se describe uno de los métodos eficientes, aunque disruptivos, para migrar SCSI a NVMe conocido como migración offline. La migración del almacén de datos VMFS offline de SCSI a NVMe no implica la transferencia de datos. El dispositivo que se presentó anteriormente a un host o clúster ESXi como un dispositivo SCSI, deja de presentarse y, a continuación, se vuelve a presentar como un dispositivo NVMe. A continuación, el almacén de datos VMFS se vuelve a firmar y se pone a disposición de los hosts, conservando su contenido de VM. Los detalles de los pasos de migración offline se describen a continuación.

Alcance

• Los pasos para la migración offline, que se describen en las secciones siguientes, se aplican únicamente a los almacenes de datos VMFS6.
• Los pasos cubren los aspectos funcionales de la migración y no las características de rendimiento de las cargas de trabajo posteriores a la migración.
• La validación de escala (cantidad de migraciones simultáneas, etc.) o límites (rutas máximas por dispositivo, VMDK máximos por VM, etc.) no está dentro del alcance.
• Los términos dispositivo, volumen y LUN se utilizan indistintamente en el documento.
• La migración offline requiere que todas las VM del almacén de datos VMFS se apaguen antes de iniciarse.  

Pasos de migración offline

La migración offline de un almacén de datos VMFS6 de SCSI a NVMe consta de tres fases. Cada fase puede implicar varias comprobaciones o pasos.

Antes de la migración

Esta fase preparatoria incluye comprobaciones para comprender las características del entorno y las características que están en uso. Esta fase es necesaria para determinar si la migración offline es factible en el entorno y también para comprender el impacto posterior a la migración. A continuación se enumeran algunas de las comprobaciones importantes. Esta no es una lista exhaustiva, sino que abarca las comprobaciones más comunes en un entorno de cliente estándar.

Compruebe el modo de bloqueo del volumen VMFS.

En primer lugar, asegúrese de que el LUN sea compatible con el modo ATS. La migración se debe intentar solo si el almacén de datos VMFS6 utiliza el modo de bloqueo solo de ATS y no utiliza reservas de SCSI-2. 

Para determinar el modo de bloqueo de un volumen determinado, ejecute el comando esxcli storage vmfs lockmode list -l <volume name/label> en un host ESXi con acceso al almacén de datos. La migración offline solo se admite si el modo de bloqueo para el volumen VMFS6 es "ATS". El modo "ATS+SCSI" no es compatible.

Un ejemplo de un volumen que admite la migración offline:

esxcli storage vmfs lockmode list -l testVol1
Volume Name UUID                                Type   Locking Mode ATS Compatible ATS Upgrade Modes ATS Incompatibility Reason

----------- ----------------------------------- ------ ------------ -------------- ----------------- --------------------------

testVol1    5d1c5b0f-xxxxxxxx-xxxx-246e9xxxxdb0 VMFS-6 ATS          true           No upgrade needed

An example of a volume not supporting offline migration:

esxcli storage vmfs lockmode list -l testVol2
 Volume Name UUID                                Type   Locking Mode ATS Compatible ATS Upgrade Modes ATS Incompatibility Reason

----------- ----------------------------------- ------ ------------ -------------- ----------------- --------------------------

testVol2    63510e51-xxxxxxxx-xxxx-246e9xxxxde6 VMFS-6 ATS+SCSI     false          None              Device does not support ATS

1.2 Compruebe si hay alguno vmdk de cualquier VM en el almacén de datos seleccionado se utiliza como RDM (física o virtual)

Si una VM en el almacén de datos seleccionado tiene un RDM en modo SCSI, no se le puede permitir migrar a NVMe. No hay ningún comando de VMware para descubrir si una VM tiene un RDM; sin embargo, el plug-in de VSI de Dell enumera el tipo de disco para cada VM. A continuación, se muestra una captura de pantalla de la vista en VSI que enumerará si alguna VM (nombre de tiempo de ejecución) tiene un RDM.

 

Si una VM tiene un RDM, este debe eliminarse de la VM, convertirse o transferirse a otro almacén de datos antes de la migración.

1.3 Verificación claim rules/settings mapeo al dispositivo que aloja el almacén de datos VMFS.

Si hay reglas de reclamación personalizadas en el dispositivo SCSI antes de la migración, es probable que no se apliquen al dispositivo cuando se presenten mediante NVMe. Los dispositivos NVMe no se presentan con campos de proveedor y modelo separados cuando se accede a ellos a través de una consulta. Los campos están juntos y, por lo tanto, se necesita una nueva regla de notificación si así se desea. Además, las reglas de notificación basadas en identificadores de dispositivos, por ejemplo, World Wide Name (WWN) fallarán, ya que el identificador SCSI y el identificador NVMe son distintos.
De manera predeterminada, VMware reclama los dispositivos NVMe recién presentados con el plug-in de rutas predeterminado de HPP.

1.4 Compruebe la cantidad de dispositivos y las rutas a cada host ESXi.

NVMe admite menos dispositivos y rutas que SCSI para cada host ESXi. Si la cantidad de dispositivos SCSI supera los límites de NVMe, no será posible convertir todos los almacenes de datos en el mismo host ESXi. Como solución, los clientes pueden emplear más hosts ESXi o consolidar almacenes de datos antes o después de la conversión con Storage vMotion. 

1. SCSI: 1024 dispositivos/4096 rutas
2. NVMe: 256 dispositivos/2048 rutas

1.5 Compruebe si hay características no soportadas. 

Algunas características de VMware actualmente no son compatibles con NVMe. Compruebe la compatibilidad antes de la migración.
Por ejemplo, las siguientes características no son compatibles actualmente con NVMe que se ejecuta en ESXi (hasta la versión 8.0U1). 
 

Característica	Breve descripción	Observaciones
Agrupación en clústeres de invitados	Función de VMDK en clúster que admite soluciones de alta disponibilidad, como el clúster de conmutación por error de Windows Server (WSFC)	Un almacén de datos VMFS con VMDK en clúster habilitado no se puede migrar.
SRM	La replicación basada en arreglos con SRM no es compatible con NVMe.	La migración de almacenes de datos relacionados con la replicación de arreglos de SRM hace que la solución sea inútil.

Nota: La lista anterior no es exhaustiva. Los clientes deben consultar la documentación específica del arreglo con respecto al impacto de la migración en las características críticas. 

 

Verifique el impacto potencial de la aceleración posterior a la migración en las características compatibles.

La falta de integración de las siguientes características puede cambiar el rendimiento de ciertas operaciones en NVMe en comparación con SCSI.
 

Característica	Naturaleza del impacto	Medidas que deben adoptarse
Transferencia acelerada de hardware: XCOPY	En la actualidad, no existe un comando equivalente a XCOPY. VMware En su lugar, se utilizará el administrador de transferencia de datos de software. Esto podría disminuir el rendimiento de las operaciones que normalmente usan la primitiva, como la clonación o SvMotion.	Ninguno
Write Same/UNMAP	Si un dispositivo NVMe no es compatible con el equivalente NVMe de los ceros de escritura o unmap, podría haber un impacto en el rendimiento.	Ninguno

Migración

Esta fase implica los pasos para migrar el almacén de datos de SCSI a NVMe.

Apague todas las VM y anule el registro

Apague y anule el registro de todas las VM alojadas en el almacén de datos que se migrará. Asegúrese de no eliminarlos, solo anule el registro.

Desmontar el volumen VMFS de todos los hosts

Desmonte el volumen VMFS de todos los hosts ESXi una vez que se anule el registro de todas las máquinas virtuales. Esto es para asegurarse de que no esté en uso cuando se realice la comprobación de coherencia y la migración. 

Compruebe la coherencia de metadatos del volumen VMFS.

Antes de iniciar la migración, compruebe la coherencia de los metadatos en disco de VMFS. Esto garantiza que no haya inconsistencias antes del principio.

1. Ejecutar VOMA (Analizador de metadatos en disco de VMware) en modo de comprobación mediante la ejecución de lo siguiente:

voma -m vmfs -f check -d /vmfs/devices/disks/<DEVICE>:<PARTITION> -s <OUTPUT FILE>

Donde:
DEVICE es el dispositivo SCSI que aloja el volumen VMFS6 que se está migrando.
PARTITION es el número de partición en el que se formatea el volumen VMFS en el dispositivo.
OUTPUT FILE es la ruta absoluta del archivo en el que se debe guardar la salida del comando. Este archivo se puede encontrar en /tmp si tiene suficiente espacio o cualquier volumen VMFS que no sea el que se está migrando.

Por ejemplo:

voma -m vmfs -f check -d naa.60000970000120200302533030313031:1 -s /tmp/voma.out

El resultado debe ser similar al siguiente:
 

[root@dsib0184:/dev/disks] voma -m vmfs -f check -d naa.60000970000120200302533030313031:1
Running VMFS Checker version 2.1 in check mode
Initializing LVM metadata, Basic Checks will be done

Checking for filesystem activity
         Scsi 2 reservation successful                       st activity (4096 bytes/HB, 1024 HBs).                            
Phase 1: Checking VMFS header and resource files
   Detected VMFS-6 file system (labeled:'SRM_UPGRADE_1') with UUID:6418928f-d0fb0a78-fa29-34800d0ed39c, Version 6:82
Phase 2: Checking VMFS heartbeat region
Phase 3: Checking all file descriptors.
Phase 4: Checking pathname and connectivity.
Phase 5: Checking resource reference counts.
Total Errors Found:           0

Nota: Si el comando recibe el siguiente error, VMFS no se desmontó correctamente:

VOMA no pudo comprobar el dispositivo: Dispositivo o recurso ocupado

2. Analice el archivo de salida para ver si hay incoherencias en los metadatos informadas por voma. Si hay alguna, se debe abordar mediante la ejecución de voma en el modo de corrección avanzada antes de continuar. A continuación se presenta un ejemplo:

[root@dsib0184:/dev/disks] voma -m vmfs -f fix -d naa.60000970000120200302533030313031:1
Running VMFS Checker version 2.1 in fix mode
Initializing LVM metadata, Basic Checks will be done
Checking for filesystem activity
         Scsi 2 reservation successful                       st activity (4096 bytes/HB, 1024 HBs).                            
Phase 1: Checking VMFS header and resource files
   Detected VMFS-6 file system (labeled:'SRM_UPGRADE_1') with UUID:6418928f-d0fb0a78-fa29-34800d0ed39c, Version 6:82
Phase 2: Checking VMFS heartbeat region
Phase 3: Checking all file descriptors.
Phase 4: Checking pathname and connectivity.
Phase 5: Checking resource reference counts.
Total Errors Found:           0
Total Errors Fixed:           0
Total Partially Fixed errors: 0

 

3. Recopile y guarde el volcado de metadatos de VMFS. Esto sería necesario si se observan incoherencias en los metadatos en los pasos posteriores. 

Consulte https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.html para obtener más detalles sobre el uso voma En Check, Advanced Fix Mode o Dump Mode.

Desconectar LUN SCSI de hosts ESXi

Desconecte el LUN SCSI de cada host ESXi en el VC. Consulte el artículo de la base de conocimientos https://kb.vmware.com/s/article/2004605 para conocer los pasos detallados.

Detener la presentación de LUN SCSI desde el arreglo.

Los pasos para anular la presentación del LUN SCSI son específicos del arreglo de almacenamiento. Los clientes deben consultar la documentación específica del arreglo sobre el procedimiento.

Presente el dispositivo como NVMe a un host ESXi.

Los pasos para volver a presentar el dispositivo mediante NVMe son específicos del arreglo de almacenamiento. Los clientes deben consultar la documentación específica del arreglo sobre el procedimiento. 

Inicie la reexaminación del dispositivo en el host.

Una vez que el dispositivo se presenta al host ESXi mediante NVMe, el descubrimiento suele ser inmediato. Sin embargo, si el dispositivo no aparece, vuelva a analizar uno o más adaptadores mediante la interfaz de usuario o la CLI de vSphere:
 

esxcli storage core adapter rescan -a

Compruebe la coherencia de metadatos del volumen VMFS después de la conversión.

En el host ESXi que tiene acceso al dispositivo, vuelva a ejecutar voma en modo de comprobación para validar que los metadatos en disco de VMFS sigan siendo coherentes. Cualquier incoherencia en los metadatos se debe investigar antes de continuar. 
Voma utiliza el comando SCSI-2 reserve para bloquear el dispositivo a fin de evitar cualquier acceso o modificación simultáneos del volumen VMFS cuando la sesión de voma está activa. Sin embargo, los dispositivos NVMe no admiten un equivalente de una reserva SCSI-2. Para solucionar esto, el usuario debe pasar el comando "-N" a VOMA cuando el dispositivo de back-end es NVMe. Por ejemplo:

• Ejecute VOMA (Analizador de metadatos en disco de VMware) en modo de comprobación mediante la ejecución de lo siguiente:

voma -m vmfs -f check -N -d /vmfs/devices/disks/<DEVICE>:<PARTITION> -s <OUTPUT FILE> 

 

When voma is invoked with "-N" option following warning message is displayed. 
########################################################################
# Warning !!! #
# #
# You are about to execute VOMA without device reservation. #
# Any access to this device from other hosts when VOMA is running #
# can cause severe data corruption #
# #
# This mode is supported only under VMware Support supervision. #
########################################################################
VMware ESXi Question:
Do you want to continue (Y/N)?
0) _Yes
1) _No

Seleccione un número entre 0 y 1:
Esto es para notificar que es responsabilidad del usuario evitar que el volumen se monte o se acceda simultáneamente desde otros hosts mientras la sesión de voma actual está en curso. Si se siguieron los pasos descritos aquí y el dispositivo se asignó y descubrió en un solo host ESXi, entonces debería ser seguro continuar. El usuario debe ingresar "0" en el símbolo del sistema para continuar con el modo de comprobación de voma. A continuación, se muestra un ejemplo:
 

[root@dsib0180:~] voma -m vmfs -f check -N -d /vmfs/devices/disks/eui.03025330303130420000976000012020:1

Ejecución de VMFS Checker versión 2.1 en modo
de comprobación Inicialización de metadatos de LVM, se realizan
comprobaciones básicas Comprobación de la actividad
del sistema de archivos La compatibilidad con reservas no está presente para los dispositivos NVMe actividad st (4096 bytes/HB, 1024 HB).                                 \

Performing filesystem liveness check..|
########################################################################
#   Warning !!!                                                        #
#                                                                      #
#   You are about to execute VOMA without device reservation.          #
#   Any access to this device from other hosts when VOMA is running    #
#   can cause severe data corruption                                   #
#                                                                      #
#   This mode is supported only under VMware support supervision.      #
########################################################################

VMware ESXi Question:
Do you want to continue (Y/N)?

0) _Yes
1) _No

Select a number from 0-1: 0

Phase 1: Checking VMFS header and resource files
   Detected VMFS-6 file system (labeled:'Temp_Datastore') with UUID:64359f88-dd0fd27e-af5a-34800d0ed39c, Version 6:82
Phase 2: Checking VMFS heartbeat region
Phase 3: Checking all file descriptors.
Phase 4: Checking pathname and connectivity.
Phase 5: Checking resource reference counts.
Total Errors Found:           0

 

Volver a firmar el volumen VMFS 

Ahora que el dispositivo se presenta como NVMe, es necesario actualizar la firma que se encuentra en el almacén de datos. Esto se debe a que la firma actual se basa, en parte, en el WWN del dispositivo cuando se presenta mediante SCSI. Dado que el ID del dispositivo NVMe es diferente, se debe generar una nueva firma. Por lo tanto, en el mismo host ESXi que se utilizó en los dos pasos anteriores, ejecute lo siguiente para volver a firmar el volumen:

1. Aunque es redundante, vuelva a examinar el sistema de archivos mediante la ejecución del comando:

Reexamen del sistema de archivos de almacenamiento de ESXCLI

2. A continuación, ejecute el siguiente comando para obtener una lista de LUN de instantáneas de VMFS:

Lista

de instantáneas de VMFS de almacenamiento de ESXCLI El dispositivo NVMe recién presentado debe estar presente, aunque, según el entorno, podría haber otras instantáneas no relacionadas con este proceso.

3. Vuelva a firmar el volumen VMFS mediante la ejecución de lo siguiente:

esxcli storage vmfs snapshot resignature --volume-label=<label>|–volume-uuid=<id> 

 

A continuación, se muestra un ejemplo:

[root@dsib0180:~] esxcli storage filesystem rescan
[root@dsib0180:~] esxcli storage vmfs snapshot list
64359f88-dd0fd27e-af5a-34800d0ed39c
   Volume Name: Temp_Datastore
   VMFS UUID: 64359f88-dd0fd27e-af5a-34800d0ed39c
   Can mount: true
   Reason for un-mountability:
   Can resignature: true
   Reason for non-resignaturability:
   Unresolved Extent Count: 1
[root@dsib0180:~] esxcli storage vmfs snapshot resignature -l Temp_Datastore

Cambiar el nombre del almacén de datos VMFS (opcional)

Cuando se vuelve a firmar un volumen VMFS, la etiqueta del volumen VMFS lleva como prefijo la etiqueta "snap" seguida de una cadena alfanumérica. Por ejemplo, el almacén de datos VMFS en el paso anterior ahora se denomina: snap-5c42a2bc-Temp_Datastore. Si lo desea, vuelva a cambiar el nombre del almacén de datos al nombre original y elimine el prefijo.

Compruebe la coherencia de metadatos del volumen VMFS después de volver a firmar.

Una vez más, valide que los metadatos de VMFS en disco sean coherentes después de volver a firmar. Ejecute voma en modo de comprobación en el volumen VMFS. Consulte la sección 2.8 para ver la línea de comandos de voma, que debe incluir el indicador "-N". Verifique si voma informa incoherencias. Continúe si voma no informa ningún error. 

Presente el dispositivo como NVMe a todos los hosts ESXi del clúster.

Si no hubo problemas en ninguno de los pasos anteriores, el dispositivo ahora se puede presentar mediante NVMe a todos los hosts ESXi del clúster. Como se indicó, los dispositivos NVMe se reconocen de inmediato, pero si no es así, vuelva a analizar los adaptadores mediante la interfaz de usuario o la CLI de vSphere. Verifique que el volumen VMFS6 esté montado y que se pueda acceder a él en todos los hosts.

Registre y encienda todas las VM

Registre todas las VM alojadas en el almacén de datos y enciéndalas. Verifique que las VM se enciendan correctamente y que puedan acceder a los VMDK. Como práctica recomendada, el usuario puede registrar y encender máquinas virtuales en un solo ESXi. Una vez que se realicen correctamente, se podrán migrar a otros hosts.

Nota: Cuando se encienden las VM desde la interfaz de usuario de vCenter, es posible que aparezca una ventana emergente como la que se muestra a continuación. Esto solicita al usuario que registre si la VM se copió o transfirió. Seleccione "Lo copié" en la ventana emergente.

 

Después de la migración

Verifique el impacto en cualquier característica clave y realice cualquier limpieza si es necesario. 

 

Este es un proceso aprobado oficialmente por VMware para la migración de almacenes de datos offline. Las migraciones en línea de VM individuales se pueden realizar mediante Storage vMotion. VMware no tiene un KB independiente para este proceso.

PowerFlex Appliance, PowerFlex custom node, PowerMax 2000, PowerMax 2500, PowerMax 8000, PowerMax 8500, PowerStore 1000X, PowerStore 1000T, PowerStore 1200T, PowerStore 3000X, PowerStore 3000T, PowerStore 3200T, PowerStore 5000X, PowerStore 5000T , PowerStore 500T, PowerStore 5200T, PowerStore 7000X, PowerStore 7000T, PowerStore 9000X, PowerStore 9000T, PowerStore 9200T, VMAX 250F, VMAX 450F, VMAX 950F, VMware ESXi 7.x, VMware ESXi 8.x ... 表示を増やす about warranties 表示を減らす about warranties