Étapes de migration hors ligne SCSI vers NVMe VMware VMFS Datastore

Étapes de migration hors ligne du datastore VMFS SCSI vers NVMe

Sommaire

• Étapes 1 de la migration du datastore VMFS hors ligne SCSI vers NVMe
• Présentation
• Champ d’application

1. Étapes de migration hors ligne
   1.  Avant la migration
   2. Vérifiez le nombre d’appareils et de chemins d’accès à chaque hôte ESXi 3 
   3. Rechercher des fonctionnalités non prises en charge 4 
   4. Vérifier l’impact potentiel de la post-migration sur les fonctionnalités prises en charge 4 
2. Migration
   1. Démontage d’un volume VMFS de tous les hôtes 5 
   2. Vérifiez la cohérence des métadonnées du volume VMFS. 5 
   3. Re-signature du volume VMFS 10 
   4. Renommer le datastore VMFS (facultatif) 11 
   5. Vérifiez la cohérence des métadonnées du volume VMFS après la resignature. 11 
   6. Présenter l’appareil en tant que NVMe à tous les hôtes ESXi du cluster 11 
   7. Enregistrer et mettre sous tension toutes les machines virtuelles 11 
3. Après la migration. 12 

 

---

 

Présentation

Avec l’adoption croissante de NVMe, de plus en plus de clients envisagent de migrer leurs données de SCSI vers NVMe. Ce document décrit l’une des méthodes efficaces, bien qu’avec interruption, de migration SCSI vers NVMe, connue sous le nom de migration hors ligne. La migration d’un datastore VMFS hors ligne de SCSI vers NVMe n’implique pas le déplacement des données. L’appareil précédemment présenté à un hôte ou à un cluster ESXi en tant qu’appareil SCSI n’est pas présenté, puis à nouveau en tant qu’appareil NVMe. Le datastore VMFS est ensuite resigné et mis à la disposition des hôtes, tout en conservant le contenu de sa machine virtuelle. Les détails des étapes de migration hors ligne sont décrits ci-dessous.

Champ d’application

• Les étapes de migration hors ligne, décrites dans les sections suivantes, s’appliquent uniquement aux datastores VMFS6.
• Les étapes couvrent les aspects fonctionnels de la migration et ne couvrent pas les caractéristiques de performances des charges applicatives après la migration.
• La validation de l’échelle (nombre de migrations simultanées, etc.) ou des limites (nombre maximal de chemins par appareil, nombre maximal de VMDK par machine virtuelle, etc.) n’est pas incluse.
• Les termes appareil, volume et LUN sont utilisés de manière interchangeable dans le document.
• La migration hors ligne nécessite la mise hors tension de toutes les machines virtuelles du datastore VMFS avant le démarrage.  

 

---

 

1. Étapes de migration hors ligne

   La migration hors ligne d’un datastore VMFS6 de SCSI vers NVMe se compose de trois phases. Chaque phase peut comporter plusieurs vérifications ou étapes.

   1. Avant la migration

      Cette phase préparatoire comprend des vérifications visant à comprendre les caractéristiques de l’environnement et les fonctionnalités utilisées. Cette phase est nécessaire pour déterminer si la migration hors ligne est réalisable dans l’environnement et également pour comprendre l’impact après la migration. Certaines des vérifications importantes sont répertoriées ci-dessous. Cette liste n’est pas exhaustive, elle couvre plutôt les vérifications les plus courantes dans un environnement client standard.

   2. Vérifier le mode de verrouillage du volume VMFS

      Tout d’abord, assurez-vous que la LUN prend en charge le mode ATS. La migration ne doit être tentée que si le datastore VMFS6 utilise le mode de verrouillage ATS uniquement et n’utilise pas de réservations SCSI-2. 
      
      Pour déterminer le mode de verrouillage d’un volume donné, exécutez la commande esxcli storage vmfs lockmode list -l <volume name/label> sur un hôte ESXi ayant accès au datastore. La migration hors ligne est prise en charge uniquement si le mode de verrouillage du volume VMFS6 est « ATS ». Le mode ATS+SCSI n’est pas pris en charge.
      
      Exemple de volume prenant en charge la migration hors ligne :

      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. Vérifiez s’il y en a vmdk de n’importe quelle machine virtuelle du datastore sélectionné est utilisée en tant que RDM (physique ou virtuel)

      Si une machine virtuelle du datastore sélectionné dispose d’un RDM en mode SCSI, elle ne peut pas être autorisée à migrer vers NVMe. Il n’existe aucune commande VMware permettant de découvrir si une machine virtuelle dispose d’un RDM, mais le Dell VSI Plugin répertorie le type de disque pour chaque machine virtuelle. Vous trouverez ci-dessous une capture d’écran de la vue VSI qui indique si des VM (nom d’exécution) ont un RDM.
      
       
       

      Si une machine virtuelle dispose d’un RDM, ce dernier doit être supprimé de la machine virtuelle, converti ou déplacé vers un autre datastore avant la migration.

   4. 1.3 Vérifier le mappage des règles/paramètres de demande au périphérique hébergeant le datastore VMFS

      S’il existe des règles de revendication personnalisées sur l’appareil SCSI avant la migration, elles ne seront probablement pas appliquées à l’appareil lorsqu’elles seront présentées à l’aide de NVMe. Les appareils NVMe ne sont pas présentés avec des champs de fournisseur et de modèle distincts lorsqu’ils sont accessibles via une demande. Les champs sont réunis, et par conséquent, une nouvelle règle de revendication est nécessaire si vous le souhaitez. En outre, les règles de revendication basées sur des ID d’appareil, par exemple, World Wide Name (WWN), échoueront car l’ID SCSI et l’ID NVMe sont distincts.
      Par défaut, VMware revendique les appareils NVMe nouvellement présentés avec le plugin de chemin par défaut de HPP.

   5. Vérifiez le nombre d’appareils et de chemins d’accès à chaque hôte ESXi

      NVMe prend en charge moins de périphériques et de chemins que SCSI vers chaque hôte ESXi. Si le nombre de périphériques SCSI dépasse les limites NVMe, il n’est pas possible de convertir tous les datastores sur le même hôte ESXi. Pour résulter cette solution, les clients peuvent utiliser davantage d’hôtes ESXi ou consolider les datastores avant ou après la conversion à l’aide de Storage vMotion. 

      1. SCSI - 1 024 appareils/4 096 chemins
      2. NVMe - 256 appareils/2 048 chemins

   6. Rechercher des fonctionnalités non prises en charge 

      Certaines fonctionnalités VMware ne sont actuellement pas prises en charge avec NVMe. Vérifiez la capacité de prise en charge avant la migration.

      Par exemple, les fonctionnalités suivantes ne sont actuellement pas prises en charge sur NVMe exécuté sur ESXi (jusqu’à la version 8.0U1).

       

      Fonctionnalité	Brève description	Remarques
      Clustering d’invités	Fonctionnalité VMDK en cluster qui prend en charge les solutions de haute disponibilité telles que Windows Server Failover Cluster (WSFC)	Un datastore VMFS avec des clusters VMDK Enabled ne peut pas être migré.
      SRM	La réplication basée sur une baie avec SRM n’est pas prise en charge sur NVMe.	La migration des datastores impliqués dans la réplication de baie SRM rend la solution inutile.

       
      Remarque : La liste ci-dessus n’est pas exhaustive. Les clients doivent consulter la documentation propre à la baie pour connaître l’impact de la migration sur les fonctionnalités stratégiques.

   7. Vérifier l’impact potentiel de la post-migration sur les fonctionnalités prises en charge

      Le manque d’intégration des fonctionnalités suivantes peut modifier la façon dont certaines opérations sont exécutées sur NVMe par rapport à SCSI.

      Fonctionnalité	Nature de l’impact	Action à réaliser
      Déplacement accéléré par matériel - XCOPY	Il n’existe actuellement aucune commande équivalente à XCOPY. Le logiciel VMware Data Mover est utilisé à la place. Cela peut diminuer les performances des opérations qui utilisent la primitive, telles que le clonage ou SvMotion.	Aucune
      Write Same/UNMAP	Si un périphérique NVMe ne prend pas en charge l’équivalent NVMe des zéros d’écriture ou unmap, il peut y avoir un impact sur les performances.	Aucune

 

---

 

1. Migration

   Cette phase comprend les étapes de migration du datastore de SCSI vers NVMe.

2. Mettre toutes les machines virtuelles hors tension et annuler l’enregistrement

   Mettez hors tension et annulez l’enregistrement de toutes les machines virtuelles hébergées sur le datastore à migrer. Veillez à ne pas les supprimer, annulez simplement l’enregistrement.

3. Démontez le volume VMFS de tous les hôtes

   Démontez le volume VMFS de tous les hôtes ESXi une fois que toutes les machines virtuelles sont désinscrites. Cela permet de s’assurer qu’il n’est pas en cours d’utilisation lors de la vérification de cohérence et de la migration

4. Vérifier la cohérence des métadonnées de volume VMFS

   Avant de lancer la migration, vérifiez la cohérence des métadonnées sur disque VMFS. Cela permet de s’assurer qu’il n’y a pas d’incohérences avant de commencer.

   1. Exécutez VOMA (VMware On-Disk Metadata Analyzer) en mode vérification en exécutant la commande suivante :

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

    

   Où :

   DEVICE est le périphérique SCSI hébergeant le volume VMFS6 en cours de migration

   PARTITION est le numéro de partition sur lequel le volume VMFS est formaté sur le périphérique

   OUTPUT FILE est le chemin absolu du fichier dans lequel la sortie de la commande doit être enregistrée. Ce fichier peut se trouver dans /tmp s’il dispose de suffisamment d’espace ou d’un volume VMFS autre que celui en cours de migration.

   Comme dans :

    

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

   Le résultat doit ressembler à ce qui suit :

   [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

   Remarque : Si la commande reçoit l’erreur suivante, cela signifie que le VMFS n’est pas démonté correctement :

    

VOMA Échec de la vérification de l’appareil : Périphérique ou ressource occupé

2. Analysez le fichier de sortie pour voir s’il existe des incohérences de métadonnées signalées par voma. S’il y en a, ils doivent être résolus en exécutant voma en mode de correction avancée avant de continuer. Voici un exemple :

[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. Collectez et enregistrez le vidage des métadonnées VMFS. Cela est nécessaire si des incohérences de métadonnées sont observées dans les étapes suivantes. 

Consultez https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.html pour plus d’informations sur l’utilisation voma en mode Check, Advanced Fix ou Dump.

Détacher une LUN SCSI des hôtes ESXi

Détachez la LUN SCSI de chaque hôte ESXi du VC. Consultez l’article de la base de connaissances https://kb.vmware.com/s/article/2004605 pour connaître les étapes détaillées.

 

Arrêter la présentation d’une LUN SCSI à partir de la baie.

La procédure de désaffichage de la LUN SCSI est spécifique à la baie de stockage. Les clients doivent consulter la documentation spécifique à la baie sur la procédure.

 

Présentez l’appareil en tant que NVMe à un hôte ESXi.

Les étapes à suivre pour présenter à nouveau l’appareil à l’aide de NVMe sont spécifiques à la baie de stockage. Les clients doivent consulter la documentation spécifique à la baie sur la procédure. 

Lancez une nouvelle analyse de l’appareil sur l’hôte.

Une fois que l’appareil est présenté à l’hôte ESXi à l’aide de NVMe, la découverte est généralement immédiate. Toutefois, si l’appareil n’apparaît pas, relancez l’analyse d’un ou de plusieurs adaptateurs à l’aide de l’interface utilisateur ou de l’interface CLI vSphere :
 

esxcli storage core adapter rescan -a

 

Vérifiez la cohérence des métadonnées du volume VMFS après la conversion.

Sur l’hôte ESXi qui a accès à l’appareil, exécutez à nouveau voma en mode vérification pour vérifier que les métadonnées sur disque VMFS sont toujours cohérentes. Toute incohérence de métadonnées doit être examinée avant de continuer. 
Voma utilise la commande SCSI-2 reserve pour verrouiller le périphérique afin d’empêcher tout accès simultané ou modification du volume VMFS lorsque la session voma est active. Toutefois, les périphériques NVMe ne prennent pas en charge l’équivalent d’une réservation SCSI-2. Pour contourner ce problème, l’utilisateur doit transmettre la commande «-N" pour VOMA lorsque l’appareil back-end est NVMe. Par exemple :

• Exécutez VOMA (VMware On-Disk Metadata Analyzer) en mode vérification en exécutant la commande suivante :

 

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

Lorsque voma est invoqué par "-N", le message d’avertissement suivant s’affiche. 

 

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

Sélectionnez un nombre compris entre 0 et 1 :
Cela permet d’indiquer qu’il est de la responsabilité de l’utilisateur d’empêcher le volume d’être monté ou accessible simultanément à partir d’autres hôtes pendant que la session voma actuelle est en cours. Si les étapes décrites ici ont été suivies et que l’appareil a été mappé et détecté sur un seul hôte ESXi, vous pouvez continuer en toute sécurité. L’utilisateur doit saisir « 0 » à l’invite pour continuer avec le mode de vérification voma. En voici un exemple :
 

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

Exécution de VMFS Checker version 2.1 en mode
de vérification Initialisation des métadonnées LVM, les vérifications de base sont effectuées
Vérification de l’activité
du système de fichiers Réservation La prise en charge n’est pas présente pour l’activité ST des appareils NVMe (4 096 octets/HB, 1 024 HB).                                 \
Performing file system 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

Sélectionnez un nombre compris entre 0 et 1 :

0 Phase 1 : Vérification des fichiers
d’en-tête et de ressources VMFS Système de fichiers VMFS-6 détecté (étiqueté :'Temp_Datastore') avec UUID:64359f88-dd0fd27e-af5a-34800d0ed39c, Version 6:82
Phase 2 : Vérification de la région
de pulsations VMFS Phase 3 : Vérification de tous les descripteurs de fichiers.
Étape 4 : Vérification du chemin d’accès et de la connectivité.
Étape 5 : Vérification du nombre de références de ressources.
Nombre total d’erreurs trouvées :           0

Re-signature du volume VMFS 

Maintenant que l’appareil est présenté comme NVMe, il est nécessaire de mettre à jour la signature qui se trouve sur le datastore. Cela est dû au fait que la signature actuelle est basée, en partie, sur le WWN du périphérique lorsqu’il est présenté à l’aide de SCSI. Étant donné que l’ID de l’appareil NVMe est différent, une nouvelle signature doit être générée. Par conséquent, sur le même hôte ESXi que celui utilisé lors des deux étapes précédentes, exécutez la commande suivante pour re-signer le volume :

1. Bien que redondante, relancez l’analyse du système de fichiers en exécutant la commande :

 

esxcli storage filesystem rescan

2. Exécutez ensuite la commande suivante pour obtenir la liste des LUN de snapshot VMFS :

 

esxcli storage vmfs snapshot list

L’appareil NVMe nouvellement présenté doit être présent, bien que selon l’environnement, il puisse y avoir d’autres snapshots sans rapport avec ce processus.

3. Re-signature du volume VMFS en exécutant la commande suivante :

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

En voici un exemple :
 

[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

 

Renommer le datastore VMFS (facultatif)

Lorsqu’un volume VMFS est re-signé, le libellé du volume VMFS est précédé de la balise « snap » suivie d’une chaîne alphanumérique. Par exemple, le datastore VMFS de l’étape précédente est maintenant nommé snap-5c42a2bc-Temp_Datastore Si vous le souhaitez, renommez le datastore avec le nom d’origine en supprimant le préfixe.

Vérifiez la cohérence des métadonnées du volume VMFS après la resignature.

Une fois de plus, vérifiez que les métadonnées VMFS sur disque sont cohérentes après la resignature. Exécutez voma en mode vérification sur le volume VMFS. Reportez-vous à la section 2.8 pour la ligne de commande voma qui doit inclure la balise « -N ». Vérifiez si voma signale des incohérences. Continuez si Voma ne signale aucune erreur. 

Présentez l’appareil en tant que NVMe à tous les hôtes ESXi du cluster.

S’il n’y a eu aucun problème lors de l’une des étapes précédentes, l’appareil peut désormais être présenté à l’aide de NVMe à tous les hôtes ESXi du cluster. Comme indiqué, les appareils NVMe sont reconnus immédiatement, mais si ce n’est pas le cas, relancez l’analyse des adaptateurs via l’interface utilisateur ou l’interface CLI vSphere. Vérifiez que le volume VMFS6 est monté et accessible sur tous les hôtes.

Enregistrer et mettre sous tension toutes les machines virtuelles

Enregistrez toutes les machines virtuelles hébergées sur le datastore et mettez-les sous tension. Vérifiez que les machines virtuelles sont bien mises sous tension et qu’elles peuvent accéder aux VMDK. Il est recommandé à l’utilisateur d’enregistrer et de mettre sous tension des machines virtuelles sur un seul ESXi. Une fois les tests réussis, ils peuvent être migrés vers d’autres hôtes.

Note: Lors de la mise sous tension des machines virtuelles à partir de l’interface utilisateur vCenter, il peut y avoir une fenêtre contextuelle telle que celle illustrée ci-dessous. Cela invite l’utilisateur à enregistrer si la machine virtuelle a été copiée ou déplacée. Sélectionnez « Je l’ai copié » dans la fenêtre contextuelle.

 

 

---

 

Après la migration

Vérifiez l’impact sur les fonctionnalités clés et effectuez un nettoyage si nécessaire. 

1.4 Vérifiez le nombre d’appareils et de chemins d’accès à chaque hôte ESXi 3
1.5 Vérification des fonctionnalités non prises en charge 4
1.6 Vérification de l’impact potentiel post-migration sur les fonctionnalités prises en charge 4
2.  Migration 4
2.2 Démontage du volume VMFS de tous les hôtes 5
2.3 Vérifiez la cohérence des métadonnées du volume VMFS.
5 2.9 Re-signature du volume VMFS 10
2.10 Renommage du datastore VMFS (facultatif) 11
2.11 Vérifiez la cohérence des métadonnées du volume VMFS après la resignature. 11
2.12 Présenter l’appareil en tant que NVMe à tous les hôtes ESXi du cluster 11
2.13 Enregistrer et mettre sous tension toutes les machines virtuelles 11
3. Après la migration. 12

Présentation

Avec l’adoption croissante de NVMe, de plus en plus de clients envisagent de migrer leurs données de SCSI vers NVMe. Ce document décrit l’une des méthodes efficaces, bien qu’avec interruption, de migration SCSI vers NVMe, connue sous le nom de migration hors ligne. La migration d’un datastore VMFS hors ligne de SCSI vers NVMe n’implique pas le déplacement des données. L’appareil précédemment présenté à un hôte ou à un cluster ESXi en tant qu’appareil SCSI n’est pas présenté, puis à nouveau en tant qu’appareil NVMe. Le datastore VMFS est ensuite resigné et mis à la disposition des hôtes, tout en conservant le contenu de sa machine virtuelle. Les détails des étapes de migration hors ligne sont décrits ci-dessous.

Champ d’application

• Les étapes de migration hors ligne, décrites dans les sections suivantes, s’appliquent uniquement aux datastores VMFS6.
• Les étapes couvrent les aspects fonctionnels de la migration et ne couvrent pas les caractéristiques de performances des charges applicatives après la migration.
• La validation de l’échelle (nombre de migrations simultanées, etc.) ou des limites (nombre maximal de chemins par appareil, nombre maximal de VMDK par machine virtuelle, etc.) n’est pas incluse.
• Les termes appareil, volume et LUN sont interchangeables dans le document.
• La migration hors ligne nécessite la mise hors tension de toutes les machines virtuelles du datastore VMFS avant le démarrage.  

Étapes de migration hors ligne

La migration hors ligne d’un datastore VMFS6 de SCSI vers NVMe se compose de trois phases. Chaque phase peut comporter plusieurs vérifications ou étapes.

Avant la migration

Cette phase préparatoire comprend des vérifications visant à comprendre les caractéristiques de l’environnement et les fonctionnalités utilisées. Cette phase est nécessaire pour déterminer si la migration hors ligne est réalisable dans l’environnement et également pour comprendre l’impact après la migration. Certaines des vérifications importantes sont répertoriées ci-dessous. Cette liste n’est pas exhaustive, elle couvre plutôt les vérifications les plus courantes dans un environnement client standard.

Vérifiez le mode de verrouillage du volume VMFS.

Tout d’abord, assurez-vous que la LUN prend en charge le mode ATS. La migration ne doit être tentée que si le datastore VMFS6 utilise le mode de verrouillage ATS uniquement et n’utilise pas de réservations SCSI-2. 

Pour déterminer le mode de verrouillage d’un volume donné, exécutez la commande esxcli storage vmfs lockmode list -l <volume name/label> sur un hôte ESXi ayant accès au datastore. La migration hors ligne est prise en charge uniquement si le mode de verrouillage du volume VMFS6 est « ATS ». Le mode ATS+SCSI n’est pas pris en charge.

Exemple de volume prenant en charge la migration hors ligne :

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 Vérifiez le cas échéant vmdk de n’importe quelle machine virtuelle du datastore sélectionné est utilisée en tant que RDM (physique ou virtuel)

Si une machine virtuelle du datastore sélectionné dispose d’un RDM en mode SCSI, elle ne peut pas être autorisée à migrer vers NVMe. Il n’existe aucune commande VMware permettant de découvrir si une machine virtuelle dispose d’un RDM, mais le Dell VSI Plugin répertorie le type de disque pour chaque machine virtuelle. Vous trouverez ci-dessous une capture d’écran de la vue dans VSI qui répertorie si des machines virtuelles (nom d’exécution) ont un RDM.

 

Si une machine virtuelle dispose d’un RDM, ce dernier doit être supprimé de la machine virtuelle, converti ou déplacé vers un autre datastore avant la migration.

1.3 Vérification claim rules/settings mappage à l’appareil hébergeant le datastore VMFS.

S’il existe des règles de revendication personnalisées sur l’appareil SCSI avant la migration, elles ne seront probablement pas appliquées à l’appareil lorsqu’elles seront présentées à l’aide de NVMe. Les appareils NVMe ne sont pas présentés avec des champs de fournisseur et de modèle distincts lorsqu’ils sont accessibles via une demande. Les champs sont réunis, et par conséquent, une nouvelle règle de revendication est nécessaire si vous le souhaitez. En outre, les règles de revendication basées sur des ID d’appareil, par exemple, World Wide Name (WWN), échoueront car l’ID SCSI et l’ID NVMe sont distincts.
Par défaut, VMware revendique les appareils NVMe nouvellement présentés avec le plugin de chemin par défaut HPP.

1.4 Vérifiez le nombre d’appareils et de chemins d’accès à chaque hôte ESXi.

NVMe prend en charge moins de périphériques et de chemins que SCSI vers chaque hôte ESXi. Si le nombre de périphériques SCSI dépasse les limites NVMe, il n’est pas possible de convertir tous les datastores sur le même hôte ESXi. Pour résulter cette solution, les clients peuvent utiliser davantage d’hôtes ESXi ou consolider les datastores avant ou après la conversion à l’aide de Storage vMotion. 

1. SCSI - 1 024 appareils/4 096 chemins
2. NVMe - 256 appareils/2 048 chemins

1.5 Recherchez les fonctionnalités non prises en charge. 

Certaines fonctionnalités VMware ne sont actuellement pas prises en charge avec NVMe. Vérifiez la capacité de prise en charge avant la migration.
Par exemple, les fonctionnalités suivantes ne sont actuellement pas prises en charge sur NVMe exécuté sur ESXi (jusqu’à la version 8.0U1). 
 

Fonctionnalité	Brève description	Remarques
Clustering d’invités	Fonctionnalité VMDK en cluster qui prend en charge les solutions de haute disponibilité telles que Windows Server Failover Cluster (WSFC)	Un datastore VMFS avec VMDK en cluster activé ne peut pas être migré.
SRM	La réplication basée sur une baie avec SRM n’est pas prise en charge sur NVMe.	La migration des datastores impliqués dans la réplication de baie SRM rend la solution inutile.

Remarque : La liste ci-dessus n’est pas exhaustive. Les clients doivent consulter la documentation propre à la baie pour connaître l’impact de la migration sur les fonctionnalités stratégiques. 

 

Vérifiez l’impact potentiel de la post-migration sur les fonctionnalités prises en charge.

Le manque d’intégration des fonctionnalités suivantes peut modifier la façon dont certaines opérations sont exécutées sur NVMe par rapport à SCSI.
 

Fonctionnalité	Nature de l’impact	Action à réaliser
Déplacement accéléré par matériel - XCOPY	Il n’existe actuellement aucune commande équivalente à XCOPY. VMware Software Data Mover sera utilisé à la place. Cela peut diminuer les performances des opérations qui utilisent normalement la primitive, telles que le clonage ou SvMotion.	Aucune
Write Same/UNMAP	Si un périphérique NVMe ne prend pas en charge l’équivalent NVMe des zéros d’écriture ou unmap, il peut y avoir un impact sur les performances.	Aucune

Migration

Cette phase comprend les étapes de migration du datastore de SCSI vers NVMe.

Mettre toutes les machines virtuelles hors tension et annuler l’enregistrement

Mettez hors tension et annulez l’enregistrement de toutes les machines virtuelles hébergées sur le datastore à migrer. Veillez à ne pas les supprimer, annulez simplement l’enregistrement.

Démontez le volume VMFS de tous les hôtes

Démontez le volume VMFS de tous les hôtes ESXi une fois que toutes les machines virtuelles sont désinscrites. Cela permet de s’assurer qu’il n’est pas en cours d’utilisation lors de la vérification de cohérence et de la migration. 

Vérifiez la cohérence des métadonnées du volume VMFS.

Avant de lancer la migration, vérifiez la cohérence des métadonnées sur disque VMFS. Cela permet de s’assurer qu’il n’y a pas d’incohérences avant le début.

1. Exécutez VOMA (VMware On-Disk Metadata Analyzer) en mode vérification en exécutant la commande suivante :

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

Où :
DEVICE est le périphérique SCSI hébergeant le volume VMFS6 en cours de migration.
PARTITION est le numéro de partition sur lequel le volume VMFS est formaté sur le périphérique.
OUTPUT FILE est le chemin absolu du fichier dans lequel la sortie de la commande doit être enregistrée. Ce fichier peut se trouver dans /tmp s’il dispose de suffisamment d’espace ou d’un volume VMFS autre que celui en cours de migration.

Par exemple :

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

Le résultat doit ressembler à ce qui suit :
 

[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

Remarque : Si la commande reçoit l’erreur suivante, cela signifie que le VMFS n’est pas démonté correctement :

VOMA n’a pas pu vérifier l’appareil : Périphérique ou ressource occupé

2. Analysez le fichier de sortie pour voir s’il existe des incohérences de métadonnées signalées par voma. S’il y en a, ils doivent être résolus en exécutant voma en mode de correction avancée avant de continuer. Voici un exemple :

[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. Collectez et enregistrez le vidage des métadonnées VMFS. Cela est nécessaire si des incohérences de métadonnées sont observées dans les étapes suivantes. 

Consultez https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.html pour plus d’informations sur l’utilisation voma en mode Check, Advanced Fix ou Dump.

Détacher une LUN SCSI des hôtes ESXi

Détachez la LUN SCSI de chaque hôte ESXi du VC. Consultez l’article de la base de connaissances https://kb.vmware.com/s/article/2004605 pour connaître les étapes détaillées.

Arrêter la présentation d’une LUN SCSI à partir de la baie.

La procédure de désaffichage de la LUN SCSI est spécifique à la baie de stockage. Les clients doivent consulter la documentation spécifique à la baie sur la procédure.

Présentez l’appareil en tant que NVMe à un hôte ESXi.

Les étapes à suivre pour présenter à nouveau l’appareil à l’aide de NVMe sont spécifiques à la baie de stockage. Les clients doivent consulter la documentation spécifique à la baie sur la procédure. 

Lancez une nouvelle analyse de l’appareil sur l’hôte.

Une fois que l’appareil est présenté à l’hôte ESXi à l’aide de NVMe, la découverte est généralement immédiate. Toutefois, si l’appareil n’apparaît pas, relancez l’analyse d’un ou de plusieurs adaptateurs à l’aide de l’interface utilisateur ou de l’interface CLI vSphere :
 

esxcli storage core adapter rescan -a

Vérifiez la cohérence des métadonnées du volume VMFS après la conversion.

Sur l’hôte ESXi qui a accès à l’appareil, exécutez à nouveau voma en mode vérification pour vérifier que les métadonnées sur disque VMFS sont toujours cohérentes. Toute incohérence de métadonnées doit être examinée avant de continuer. 
Voma utilise la commande SCSI-2 reserve pour verrouiller le périphérique afin d’empêcher tout accès simultané ou modification du volume VMFS lorsque la session Voma est active. Toutefois, les périphériques NVMe ne prennent pas en charge l’équivalent d’une réservation SCSI-2. Pour contourner ce problème, l’utilisateur doit transmettre la commande «-N" pour VOMA lorsque l’appareil back-end est NVMe. Par exemple :

• Exécutez VOMA (VMware On-Disk Metadata Analyzer) en mode vérification en exécutant :

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

Sélectionnez un nombre compris entre 0 et 1 :
Cela permet d’indiquer qu’il est de la responsabilité de l’utilisateur d’empêcher le volume d’être monté ou accessible simultanément à partir d’autres hôtes pendant que la session voma actuelle est en cours. Si les étapes décrites ici ont été suivies et que l’appareil a été mappé et détecté sur un seul hôte ESXi, vous pouvez continuer en toute sécurité. L’utilisateur doit saisir « 0 » à l’invite pour continuer avec le mode de vérification voma. En voici un exemple :
 

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

Exécution de VMFS Checker version 2.1 en mode
de vérification Initialisation des métadonnées LVM, les vérifications de base sont effectuées
Vérification de l’activité
du système de fichiers Réservation La prise en charge n’est pas présente pour l’activité ST des appareils NVMe (4 096 octets/HB, 1 024 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

 

Re-signature du volume VMFS 

Maintenant que l’appareil est présenté comme NVMe, il est nécessaire de mettre à jour la signature qui se trouve sur le datastore. Cela est dû au fait que la signature actuelle est basée, en partie, sur le WWN du périphérique lorsqu’il est présenté à l’aide de SCSI. Étant donné que l’ID de l’appareil NVMe est différent, une nouvelle signature doit être générée. Par conséquent, sur le même hôte ESXi que celui utilisé lors des deux étapes précédentes, exécutez la commande suivante pour re-signer le volume :

1. Bien que redondante, relancez l’analyse du système de fichiers en exécutant la commande :

Nouvelle analyse du système de fichiers de stockage ESXCLI

2. Exécutez ensuite la commande suivante pour obtenir la liste des LUN de snapshot VMFS :

Liste

de snapshots VMFS de stockage ESXCLI L’appareil NVMe nouvellement présenté doit être présent, bien que selon l’environnement, il puisse y avoir d’autres snapshots sans rapport avec ce processus.

3. Re-signature du volume VMFS en exécutant la commande suivante :

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

 

En voici un exemple :

[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

Renommer le datastore VMFS (facultatif)

Lorsqu’un volume VMFS est re-signé, le libellé du volume VMFS est précédé de la balise « snap » suivie d’une chaîne alphanumérique. Par exemple, le datastore VMFS de l’étape précédente s’appelle désormais snap-5c42a2bc-Temp_Datastore. Si vous le souhaitez, renommez le datastore avec le nom d’origine en supprimant le préfixe.

Vérifiez la cohérence des métadonnées du volume VMFS après la resignature.

Une fois de plus, vérifiez que les métadonnées VMFS sur disque sont cohérentes après la resignature. Exécutez voma en mode vérification sur le volume VMFS. Reportez-vous à la section 2.8 pour la ligne de commande voma qui doit inclure la balise « -N ». Vérifiez si voma signale des incohérences. Continuez si Voma ne signale aucune erreur. 

Présentez l’appareil en tant que NVMe à tous les hôtes ESXi du cluster.

S’il n’y a eu aucun problème lors de l’une des étapes précédentes, l’appareil peut désormais être présenté à l’aide de NVMe à tous les hôtes ESXi du cluster. Comme indiqué, les appareils NVMe sont reconnus immédiatement, mais si ce n’est pas le cas, relancez l’analyse des adaptateurs via l’interface utilisateur ou l’interface CLI vSphere. Vérifiez que le volume VMFS6 est monté et accessible sur tous les hôtes.

Enregistrer et mettre sous tension toutes les machines virtuelles

Enregistrez toutes les machines virtuelles hébergées sur le datastore et mettez-les sous tension. Vérifiez que les machines virtuelles sont bien mises sous tension et qu’elles peuvent accéder aux VMDK. Il est recommandé à l’utilisateur d’enregistrer et de mettre sous tension des machines virtuelles sur un seul ESXi. Une fois les tests réussis, ils peuvent être migrés vers d’autres hôtes.

Note: Lors de la mise sous tension des machines virtuelles à partir de l’interface utilisateur vCenter, il peut y avoir une fenêtre contextuelle telle que celle illustrée ci-dessous. Cela invite l’utilisateur à enregistrer si la machine virtuelle a été copiée ou déplacée. Sélectionnez « Je l’ai copié » dans la fenêtre contextuelle.

 

Après la migration

Vérifiez l’impact sur les fonctionnalités clés et effectuez un nettoyage si nécessaire. 

 

Il s’agit d’un processus officiellement approuvé par VMware pour la migration de datastores hors ligne. Les migrations en ligne de machines virtuelles individuelles peuvent être effectuées à l’aide de Storage vMotion. VMware ne dispose pas d’un article de base de connaissances distinct pour ce processus.

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