Offline migratiestappen voor SCSI naar NVMe VMware VMFS Datastore

SCSI naar NVMe offline VMFS Datastore migratiestappen

Inhoudsopgave

• SCSI naar NVMe offline VMFS Datastore migratie stappen 1
• Overzicht
• Reikwijdte

1. Offline migratiestappen
   1.  Vóór de migratie
   2. Controleer zowel het aantal apparaten als de paden naar elke ESXi-host 3 
   3. Controleren op niet-ondersteunde functies 4 
   4. Controleer op de mogelijke impact van post-migratie op ondersteunde functies 4 
2. Migratie
   1. VMFS-volume loskoppelen van alle hosts 5 
   2. Controleer de consistentie van de metagegevens van het VMFS-volume. 5 
   3. Zet de VMFS-volume 10 opnieuw onder 
   4. Naam van de VMFS datastore wijzigen (optioneel) 11 
   5. Controleer de consistentie van VMFS-volumemetadata na het opnieuw ondertekenen. 11 
   6. Presenteer het apparaat als NVMe op alle ESXi-hosts in het cluster 11 
   7. Registreer en schakel alle VM's in 11 
3. Na de migratie. 12 

 

---

 

Overzicht

Nu de acceptatie van NVMe toeneemt, overwegen steeds meer klanten data te migreren van SCSI naar NVMe. Dit document beschrijft een van de efficiënte, zij het verstorende, methoden voor het migreren van SCSI naar NVMe, ook wel offline migratie genoemd. Offline VMFS datastore-migratie van SCSI naar NVMe omvat geen verplaatsing van data. Het apparaat dat eerder aan een ESXi-host of -cluster werd gepresenteerd als een SCSI-apparaat, wordt niet gepresenteerd en vervolgens opnieuw gepresenteerd als een NVMe-apparaat. De VMFS-datastore wordt vervolgens opnieuw ondertekend en beschikbaar gesteld aan de hosts, met behoud van de VM-inhoud. Details van de offline migratiestappen worden hieronder beschreven.

Reikwijdte

• De stappen voor offline migratie, beschreven in de volgende secties, zijn alleen van toepassing op VMFS6-datastores.
• De stappen behandelen functionele aspecten van de migratie en niet de prestatiekenmerken van workloads na de migratie.
• De validatie van schaal (aantal gelijktijdige migraties, enzovoort) of limieten (maximale paden per apparaat, maximale VMDK's per VM, enzovoort) valt niet binnen het bereik.
• De termen apparaat, volume en LUN worden in het document door elkaar gebruikt.
• Voor offline migratie moeten alle VM's in de VMFS-datastore worden uitgeschakeld voordat de migratie kan worden gestart.  

 

---

 

1. Offline migratiestappen

   Offline migratie van een VMFS6 datastore van SCSI naar NVMe bestaat uit drie fasen. Elke fase kan meerdere controles of stappen omvatten.

   1. Vóór de migratie

      Deze voorbereidende fase omvat controles om de kenmerken van de omgeving en de functies die in gebruik zijn te begrijpen. Deze fase is nodig om te bepalen of offline migratie haalbaar is in de omgeving en ook om de impact na de migratie te begrijpen. Enkele van de belangrijke controles worden hieronder opgesomd. Dit is geen uitputtende lijst, maar behandelt de meest voorkomende controles in een standaard klantomgeving.

   2. Controleren op vergrendelingsmodus van VMFS-volume

      Controleer eerst of de LUN de ATS-modus ondersteunt. Migratie moet alleen worden geprobeerd als de VMFS6-datastore de vergrendelingsmodus van alleen ATS gebruikt en geen SCSI-2-reserveringen gebruikt. 
      
      Om de vergrendelingsmodus van een bepaald volume te bepalen, voert u de opdracht uit esxcli storage vmfs lockmode list -l <volume name/label> op een ESXi-host met toegang tot de datastore. Offline migratie wordt alleen ondersteund als de vergrendelingsmodus voor het VMFS6-volume "ATS" is. De modus "ATS+SCSI" wordt niet ondersteund.
      
      Een voorbeeld van een volume dat offline migratie ondersteunt:

      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. Controleer of er sprake is van vmdk van een VM in de geselecteerde datastore wordt gebruikt als een RDM (fysiek of virtueel)

      Als een VM in de geselecteerde datastore een RDM in SCSI-modus heeft, kan deze niet naar NVMe worden gemigreerd. Er is geen VMware-opdracht om te detecteren of een VM een RDM heeft, maar de Dell VSI plug-in vermeldt het schijftype voor elke VM. Hieronder ziet u een schermafbeelding van de weergave in VSI waarin wordt weergegeven of VM's (runtimenaam) een RDM hebben.
      
       
       

      Als een VM een RDM heeft, moet de RDM ofwel uit de VM worden verwijderd, worden geconverteerd, ofwel moet de VM vóór de migratie naar een ander datastore worden verplaatst.

   4. 1.3 Toewijzing van claimregels/instellingen controleren op het apparaat dat als host fungeert voor VMFS datastore

      Als er vóór de migratie aangepaste claimregels op het SCSI-apparaat zijn, worden deze waarschijnlijk niet toegepast op het apparaat wanneer ze worden weergegeven met behulp van NVMe. NVMe-apparaten krijgen geen afzonderlijke leveranciers- en modelvelden te zien wanneer ze worden geopend via een aanvraag. De velden staan bij elkaar, en dus is een nieuwe claimregel nodig als dat gewenst is. Bovendien zullen claimregels op basis van apparaat-ID's, zoals WWN (World Wide Name), mislukken omdat de SCSI-identifier en NVMe-identifier verschillend zijn.
      Standaard claimt VMware nieuw gepresenteerde NVMe-apparaten met de standaard padplug-in van HPP.

   5. Controleer zowel het aantal apparaten als de paden naar elke ESXi-host

      NVMe ondersteunt minder apparaten en paden dan SCSI naar elke ESXi-host. Als het aantal SCSI-apparaten de NVMe-limieten overschrijdt, is het niet mogelijk om alle datastores op dezelfde ESXi-host te converteren. Als oplossing kunnen klanten meer ESXi-hosts gebruiken of datastores voor of na de conversie consolideren met behulp van Storage vMotion. 

      1. SCSI - 1024 apparaten/4096 paden
      2. NVMe - 256 apparaten/2048 paden

   6. Controleren op niet-ondersteunde functies 

      Sommige VMware-functies worden momenteel niet ondersteund met NVMe. Controleer vóór de migratie op ondersteuning.

      De volgende functies worden momenteel bijvoorbeeld niet ondersteund op NVMe die wordt uitgevoerd op ESXi (tot en met release 8.0U1).

       

      Kenmerk	Korte beschrijving	Opmerkingen
      Gastclustering	Geclusterde VMDK-functie die oplossingen met hoge beschikbaarheid ondersteunt, zoals Windows Server Failover Cluster (WSFC)	Een VMFS-datastore met geclusterde VMDK Ingeschakeld kan niet worden gemigreerd.
      SRM	Op array gebaseerde replicatie met SRM wordt niet ondersteund op NVMe.	Het migreren van datastores die betrokken zijn bij SRM-arrayreplicatie maakt de oplossing nutteloos.

       
      Opmerking: De bovenstaande lijst is niet uitputtend. Klanten moeten de arrayspecifieke documentatie raadplegen over de impact van de migratie op de kritieke functies.

   7. Controleer op mogelijke impact van post-migratie op ondersteunde functies

      Het gebrek aan integratie van de volgende functies kan de manier veranderen waarop bepaalde bewerkingen worden uitgevoerd op NVMe in vergelijking met SCSI.

      Kenmerk	Aard van de impact	Te ondernemen actie
      Hardwareversnelde verplaatsing - XCOPY	Er is momenteel geen gelijkwaardige opdracht voor XCOPY. In plaats daarvan wordt VMware software data mover gebruikt. Dit kan de prestaties verminderen van bewerkingen waarbij het primitieve wordt gebruikt, zoals klonen of SvMotion.	Geen
      Write Same/UNMAP	Als een NVMe-apparaat het NVMe-equivalent van schrijfnullen of unmap, kan er een impact zijn op de prestaties.	Geen

 

---

 

1. Migratie

   Deze fase omvat de stappen om de datastore te migreren van SCSI naar NVMe.

2. Alle VM's uitschakelen en registratie ongedaan maken

   Schakel alle VM's die worden gehost op de datastore die moet worden gehost uit en verwijder ze de registratie ervan. Zorg ervoor dat u ze niet verwijdert, alleen de registratie ongedaan maakt.

3. VMFS-volume loskoppelen van alle hosts

   Ontkoppel het VMFS-volume van alle ESXi-hosts zodra alle VM's zijn gederegistreerd. Dit is om ervoor te zorgen dat het niet in gebruik is wanneer de consistentiecontrole en migratie wordt uitgevoerd

4. Consistentie van VMFS-volumemetadata controleren

   Voordat u de migratie start, controleert u de consistentie van de VMFS-metadata op de schijf. Dit zorgt ervoor dat er geen inconsistenties zijn voordat u begint.

   1. Voer VOMA (VMware On-Disk Metadata Analyzer) in de controlemodus door het volgende uit te voeren:

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

    

   Waarbij:

   DEVICE is het SCSI-apparaat dat als host fungeert voor het VMFS6-volume dat wordt gemigreerd

   PARTITION is het partitienummer waarop het VMFS-volume op het apparaat is geformatteerd

   OUTPUT FILE is het absolute pad van het bestand waarin de uitvoer van de opdracht moet worden opgeslagen. Dit bestand vindt u in de /tmp als het voldoende ruimte of een ander VMFS-volume heeft dan het volume dat wordt gemigreerd.

   Zoals in:

    

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

   De uitvoer zou er ongeveer als volgt uit moeten zien:

   [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

   Opmerking: Als de opdracht de volgende foutmelding ontvangt, is de VMFS niet correct ontkoppeld:

    

VOMA Kan apparaat niet controleren: Apparaat of bron bezet

2. Analyseer het uitvoerbestand om te zien of er inconsistenties in de metadata zijn die worden gemeld door voma. Als die er zijn, moeten ze worden aangepakt door uit te voeren voma in de geavanceerde fix-modus voordat u verdergaat. Het volgende is een voorbeeld:

[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. Verzamel en bewaar dump voor VMFS-metadata. Dit is vereist als er in de volgende stappen inconsistenties in de metadata worden gezien. 

Raadpleeg https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.html voor meer informatie over het gebruik van voma Check, Advanced Fix Mode of Dump Mode.

SCSI LUN loskoppelen van ESXi-hosts

Koppel SCSI LUN los van elke ESXi-host in de VC. Zie het https://kb.vmware.com/s/article/2004605 in het KB-artikel voor gedetailleerde stappen.

 

Stop met het weergeven van SCSI LUN vanaf array.

De stappen voor het ongedaan maken van de presentatie van de SCSI LUN zijn specifiek voor de storage-array. Klanten dienen de arrayspecifieke documentatie over de procedure te raadplegen.

 

Presenteer het apparaat als NVMe op één ESXi-host.

De stappen voor het opnieuw presenteren van het apparaat met behulp van NVMe zijn specifiek voor storagearrays. Klanten dienen de arrayspecifieke documentatie over de procedure te raadplegen. 

Start de nieuwe scan van het apparaat op de host.

Zodra het apparaat aan de ESXi-host wordt gepresenteerd met behulp van NVMe, is de detectie meestal onmiddellijk. Als het apparaat echter niet verschijnt, scant u een of meer adapters opnieuw met behulp van de vSphere-gebruikersinterface of CLI:
 

esxcli storage core adapter rescan -a

 

Consistentie van VMFS-volumemetadata controleren na conversie.

Op de ESXi-host die toegang heeft tot het apparaat, voert u voma opnieuw uit in de controlemodus om te valideren dat de VMFS-metadata op de schijf nog steeds consistent zijn. Eventuele inconsistenties in metagegevens moeten worden onderzocht voordat we verdergaan. 
Voma gebruikt de SCSI-2 reserve-opdracht om het apparaat te vergrendelen om gelijktijdige toegang of wijziging van het VMFS-volume te voorkomen wanneer de voma-sessie actief is. NVMe-apparaten ondersteunen echter geen equivalent van een SCSI-2-reservering. Om dit te omzeilen, moet de gebruiker slagen voor de "-N" optie om VOMA wanneer het back-endapparaat NVMe is. Bijvoorbeeld:

• Voer VOMA (VMware On-Disk Metadata Analyzer) in de controlemodus door het volgende uit te voeren:

 

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

Wanneer voma wordt aangeroepen met "-N" wordt de volgende waarschuwing weergegeven. 

 

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

Selecteer een getal van 0-1:
dit is om aan te geven dat het de verantwoordelijkheid van de gebruiker is om te voorkomen dat het volume wordt geactiveerd of gelijktijdig wordt geopend vanaf andere hosts terwijl de huidige voma-sessie bezig is. Als de hier beschreven stappen zijn gevolgd en het apparaat in kaart is gebracht en gedetecteerd op slechts één ESXi-host, zou het veilig moeten zijn om door te gaan. De gebruiker moet "0" invoeren bij de prompt om door te gaan met de voma-controlemodus. Hieronder volgt een voorbeeld:
 

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

VMFS Checker versie 2.1 uitvoeren in controlemodus
Initialiseren van LVM-metadata, basiscontroles zijn uitgevoerd
Controleren op activiteit
van het bestandssysteem Ondersteuning voor reserveren is niet aanwezig voor st-activiteit van NVMe-apparaten (4096 bytes/HB, 1024 HB's).                                 \
Uitvoeren van controle van de levendigheid van het bestandssysteem..|

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

Selecteer een getal van 0-1:

0 Fase 1: VMFS-header en resourcebestanden
worden gecontroleerd VMFS-6-bestandssysteem gedetecteerd (met het label:'Temp_Datastore') met UUID:64359f88-dd0fd27e-af5a-34800d0ed39c, Version 6:82
Fase 2: Checking VMFS heartbeat region
Phase 3: Bezig met het controleren van alle bestandsbeschrijvingen.
Fase 4: De naam van het pad en de verbinding wordt gecontroleerd.
Fase 5: Controle van het aantal bronreferenties.
Totaal aantal fouten gevonden:           0

Zet opnieuw handtekening voor het VMFS-volume 

Nu het apparaat wordt gepresenteerd als NVMe, is het noodzakelijk om de handtekening in de datastore bij te werken. Dit komt omdat de huidige handtekening gedeeltelijk is gebaseerd op de WWN van het apparaat wanneer het wordt gepresenteerd met behulp van SCSI. Omdat de NVMe-apparaat-id anders is, moet er een nieuwe handtekening worden gegenereerd. Voer daarom op dezelfde ESXi-host die in de vorige twee stappen is gebruikt, het volgende uit om het volume opnieuw te ondertekenen:

1. Hoewel redundant, moet u het bestandssysteem opnieuw scannen door de volgende opdracht uit te voeren:

 

esxcli storage filesystem rescan

2. Voer vervolgens de volgende opdracht uit om een lijst met VMFS snapshot-LUN's op te halen:

 

esxcli storage vmfs snapshot list

Het nieuw gepresenteerde NVMe-apparaat zou aanwezig moeten zijn, maar afhankelijk van de omgeving kunnen er andere snapshots zijn die geen verband houden met dit proces.

3. Zet de handtekening van het VMFS-volume opnieuw door het volgende uit te voeren:

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

Hieronder ziet u een voorbeeld:
 

[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

 

Naam van de VMFS datastore wijzigen (optioneel)

Wanneer een VMFS-volume opnieuw wordt ondertekend, wordt het VMFS-volumelabel voorafgegaan door de tag "snap", gevolgd door een alfanumerieke tekenreeks. De VMFS-datastore in de vorige stap heeft nu bijvoorbeeld de volgende naam: snap-5c42a2bc-Temp_Datastore Wijzig indien gewenst de naam van de datastore terug in de oorspronkelijke naam en verwijder het voorvoegsel.

Controleer de consistentie van VMFS-volumemetadata na het opnieuw ondertekenen.

Controleer nogmaals of de VMFS-metadata op de schijf consistent zijn na het opnieuw ondertekenen. Voer voma uit in de controlemodus op het VMFS-volume. Zie sectie 2.8 voor de voma-opdrachtregel die de "-N"-vlag moet bevatten. Controleer of voma inconsistenties rapporteert. Ga verder als voma geen fouten meldt. 

Presenteer het apparaat als NVMe op alle ESXi-hosts in het cluster.

Als er geen problemen waren bij een van de vorige stappen, kan het apparaat nu via NVMe worden gepresenteerd aan alle ESXi-hosts in het cluster. Zoals opgemerkt, worden NVMe-apparaten onmiddellijk herkend, maar als dit niet het geval is, scant u de adapters opnieuw via de vSphere-gebruikersinterface of CLI. Controleer of het VMFS6-volume is gekoppeld en toegankelijk is op alle hosts.

Registreer alle VM's en schakel ze in

Registreer alle VM's die worden gehost op de datastore en schakel ze in. Controleer of de VM's met succes worden ingeschakeld en toegang hebben tot de vmdk's. Als best practice kan de gebruiker VM's registreren en inschakelen op één ESXi. Zodra dit is gelukt, kunnen ze worden gemigreerd naar andere hosts.

Notitie: Bij het inschakelen van de VM's vanuit de vCenter-gebruikersinterface kan er een pop-upvenster verschijnen zoals hieronder weergegeven. Dit vraagt de gebruiker om vast te leggen of de VM is gekopieerd of verplaatst. Selecteer "I Copied it" in de pop-up.

 

 

---

 

Na de migratie

Controleer op impact op belangrijke functies en voer indien nodig opschoning uit. 

1.4 Controleer zowel het aantal apparaten als paden naar elke ESXi-host 3
1.5 Controleer op niet-ondersteunde functies 4
1.6 Controleer op mogelijke impact na de migratie op ondersteunde functies 4
2.  Migratie 4
2.2 VMFS-volume loskoppelen van alle hosts 5
2.3 Consistentie van VMFS-volumemetadata controleren.
5 2.9 Handtekening zetten voor het VMFS-volume 10
2.10 Naam van de VMFS-datastore wijzigen (optioneel) 11
2.11 Controleer de consistentie van de VMFS-volumemetadata na het opnieuw ondertekenen. 11
2.12 Presenteer het apparaat als NVMe aan alle ESXi-hosts in het cluster 11
2.13 Registreer en schakel alle VM's in 11
3. Na de migratie. 12

Overzicht

Nu de acceptatie van NVMe toeneemt, overwegen steeds meer klanten data te migreren van SCSI naar NVMe. Dit document beschrijft een van de efficiënte, zij het verstorende, methoden voor het migreren van SCSI naar NVMe, ook wel offline migratie genoemd. Offline VMFS datastore-migratie van SCSI naar NVMe omvat geen verplaatsing van data. Het apparaat dat eerder aan een ESXi-host of -cluster werd gepresenteerd als een SCSI-apparaat, wordt niet gepresenteerd en vervolgens opnieuw gepresenteerd als een NVMe-apparaat. De VMFS-datastore wordt vervolgens opnieuw ondertekend en beschikbaar gesteld aan de hosts, met behoud van de VM-inhoud. Details van de offline migratiestappen worden hieronder beschreven.

Reikwijdte

• De stappen voor offline migratie, beschreven in de volgende secties, zijn alleen van toepassing op VMFS6-datastores.
• De stappen behandelen functionele aspecten van de migratie en niet de prestatiekenmerken van workloads na de migratie.
• De validatie van schaal (aantal gelijktijdige migraties, enzovoort) of limieten (maximale paden per apparaat, maximale VMDK's per VM, enzovoort) valt niet binnen het bereik.
• De termen apparaat, volume en LUN worden in het document door elkaar gebruikt.
• Offline migratie vereist dat alle VM's in de VMFS-datastore worden uitgeschakeld voordat u kunt beginnen.  

Offline migratiestappen

Offline migratie van een VMFS6 datastore van SCSI naar NVMe bestaat uit drie fasen. Elke fase kan meerdere controles of stappen omvatten.

Vóór de migratie

Deze voorbereidende fase omvat controles om de kenmerken van de omgeving en de functies die in gebruik zijn te begrijpen. Deze fase is nodig om te bepalen of offline migratie haalbaar is in de omgeving en ook om de impact na de migratie te begrijpen. Enkele van de belangrijke controles worden hieronder opgesomd. Dit is geen uitputtende lijst, maar behandelt de meest voorkomende controles in een standaard klantomgeving.

Controleer of het VMFS-volume in de vergrendelingsmodus zit.

Controleer eerst of de LUN de ATS-modus ondersteunt. Migratie moet alleen worden geprobeerd als de VMFS6-datastore de vergrendelingsmodus van alleen ATS gebruikt en geen SCSI-2-reserveringen gebruikt. 

Om de vergrendelingsmodus van een bepaald volume te bepalen, voert u de opdracht uit esxcli storage vmfs lockmode list -l <volume name/label> op een ESXi-host met toegang tot de datastore. Offline migratie wordt alleen ondersteund als de vergrendelingsmodus voor het VMFS6-volume "ATS" is. De modus "ATS+SCSI" wordt niet ondersteund.

Een voorbeeld van een volume dat offline migratie ondersteunt:

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 Controleer of er vmdk van een VM in de geselecteerde datastore wordt gebruikt als een RDM (fysiek of virtueel)

Als een VM in de geselecteerde datastore een RDM in SCSI-modus heeft, kan deze niet naar NVMe worden gemigreerd. Er is geen VMware-opdracht om te detecteren of een VM een RDM heeft, maar de Dell VSI plug-in vermeldt het schijftype voor elke VM. Hieronder ziet u een schermafbeelding van de weergave in VSI waarin wordt weergegeven of VM's (runtimenaam) een RDM hebben.

 

Als een VM een RDM heeft, moet de RDM ofwel uit de VM worden verwijderd, worden geconverteerd, ofwel moet de VM vóór de migratie naar een ander datastore worden verplaatst.

1.3 Controleren claim rules/settings toewijzing aan het apparaat dat als host voor de VMFS-datastore fungeert.

Als er vóór de migratie aangepaste claimregels op het SCSI-apparaat zijn, worden deze waarschijnlijk niet toegepast op het apparaat wanneer ze worden weergegeven met behulp van NVMe. NVMe-apparaten krijgen geen afzonderlijke leveranciers- en modelvelden te zien wanneer ze worden geopend via een aanvraag. De velden staan bij elkaar, en dus is een nieuwe claimregel nodig als dat gewenst is. Bovendien zullen claimregels op basis van apparaat-ID's, zoals WWN (World Wide Name), mislukken omdat de SCSI-identifier en NVMe-identifier verschillend zijn.
VMware claimt standaard nieuw gepresenteerde NVMe-apparaten met de standaard padplug-in van HPP.

1.4 Controleer zowel het aantal apparaten als de paden naar elke ESXi-host.

NVMe ondersteunt minder apparaten en paden dan SCSI naar elke ESXi-host. Als het aantal SCSI-apparaten de NVMe-limieten overschrijdt, is het niet mogelijk om alle datastores op dezelfde ESXi-host te converteren. Als oplossing kunnen klanten meer ESXi-hosts gebruiken of datastores voor of na de conversie consolideren met behulp van Storage vMotion. 

1. SCSI - 1024 apparaten/4096 paden
2. NVMe - 256 apparaten/2048 paden

1.5 Controleer op niet-ondersteunde functies. 

Sommige VMware-functies worden momenteel niet ondersteund met NVMe. Controleer vóór de migratie op ondersteuning.
De volgende functies worden momenteel bijvoorbeeld niet ondersteund op NVMe die wordt uitgevoerd op ESXi (tot en met release 8.0U1). 
 

Kenmerk	Korte beschrijving	Opmerkingen
Gastclustering	Geclusterde VMDK-functie die oplossingen met hoge beschikbaarheid ondersteunt, zoals Windows Server Failover Cluster (WSFC)	Een VMFS-datastore waarvoor geclusterde VMDK is ingeschakeld, kan niet worden gemigreerd.
SRM	Op array gebaseerde replicatie met SRM wordt niet ondersteund op NVMe.	Het migreren van datastores die betrokken zijn bij SRM-arrayreplicatie maakt de oplossing nutteloos.

Opmerking: De bovenstaande lijst is niet uitputtend. Klanten moeten de arrayspecifieke documentatie raadplegen over de impact van de migratie op de kritieke functies. 

 

Controleer op mogelijke impact van post-migratie op ondersteunde functies.

Het gebrek aan integratie van de volgende functies kan de manier veranderen waarop bepaalde bewerkingen worden uitgevoerd op NVMe in vergelijking met SCSI.
 

Kenmerk	Aard van de impact	Te ondernemen actie
Hardwareversnelde verplaatsing - XCOPY	Er is momenteel geen gelijkwaardige opdracht voor XCOPY. VMware In plaats daarvan wordt software data mover gebruikt. Dit kan leiden tot een afname van de prestaties van bewerkingen waarbij normaal gesproken het primitieve wordt gebruikt, zoals klonen of SvMotion.	Geen
Write Same/UNMAP	Als een NVMe-apparaat het NVMe-equivalent van schrijfnullen of unmap, kan er een impact zijn op de prestaties.	Geen

Migratie

Deze fase omvat de stappen om de datastore te migreren van SCSI naar NVMe.

Alle VM's uitschakelen en registratie ongedaan maken

Schakel alle VM's die worden gehost op de datastore die moet worden gehost uit en verwijder ze de registratie ervan. Zorg ervoor dat u ze niet verwijdert, alleen de registratie ongedaan maakt.

VMFS-volume loskoppelen van alle hosts

Ontkoppel het VMFS-volume van alle ESXi-hosts zodra alle VM's zijn gederegistreerd. Dit is om ervoor te zorgen dat het niet in gebruik is wanneer de consistentiecontrole en migratie wordt uitgevoerd. 

Controleer de consistentie van de metagegevens van het VMFS-volume.

Voordat u de migratie start, controleert u de consistentie van de VMFS-metadata op de schijf. Dit zorgt ervoor dat er geen inconsistenties zijn voor het begin.

1. Voer VOMA (VMware On-Disk Metadata Analyzer) in de controlemodus door het volgende uit te voeren:

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

Waar:
DEVICE is het SCSI-apparaat dat als host fungeert voor het VMFS6-volume dat wordt gemigreerd.
PARTITION is het partitienummer waarop het VMFS-volume op het apparaat is geformatteerd.
OUTPUT FILE is het absolute pad van het bestand waarin de uitvoer van de opdracht moet worden opgeslagen. Dit bestand vindt u in de /tmp als het voldoende ruimte of een ander VMFS-volume heeft dan het volume dat wordt gemigreerd.

Bijvoorbeeld:

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

De uitvoer zou er ongeveer als volgt uit moeten zien:
 

[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

Opmerking: Als de opdracht de volgende foutmelding ontvangt, is de VMFS niet goed ontkoppeld:

VOMA kan apparaat niet controleren: Apparaat of bron bezet

2. Analyseer het uitvoerbestand om te zien of er inconsistenties in de metadata zijn die worden gemeld door voma. Als die er zijn, moeten ze worden aangepakt door uit te voeren voma in de geavanceerde fix-modus voordat u verdergaat. Het volgende is een voorbeeld:

[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. Verzamel en bewaar dump voor VMFS-metadata. Dit is vereist als er in de volgende stappen inconsistenties in de metadata worden gezien. 

Raadpleeg https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.html voor meer informatie over het gebruik van voma Check, Advanced Fix Mode of Dump Mode.

SCSI LUN loskoppelen van ESXi-hosts

Koppel SCSI LUN los van elke ESXi-host in de VC. Zie het https://kb.vmware.com/s/article/2004605 in het KB-artikel voor gedetailleerde stappen.

Stop met het weergeven van SCSI LUN vanaf array.

De stappen voor het ongedaan maken van de presentatie van de SCSI LUN zijn specifiek voor de storage-array. Klanten dienen de arrayspecifieke documentatie over de procedure te raadplegen.

Presenteer het apparaat als NVMe op één ESXi-host.

De stappen voor het opnieuw presenteren van het apparaat met behulp van NVMe zijn specifiek voor storagearrays. Klanten dienen de arrayspecifieke documentatie over de procedure te raadplegen. 

Start de nieuwe scan van het apparaat op de host.

Zodra het apparaat aan de ESXi-host wordt gepresenteerd met behulp van NVMe, is de detectie meestal onmiddellijk. Als het apparaat echter niet verschijnt, scant u een of meer adapters opnieuw met behulp van de vSphere-gebruikersinterface of CLI:
 

esxcli storage core adapter rescan -a

Consistentie van VMFS-volumemetadata controleren na conversie.

Op de ESXi-host die toegang heeft tot het apparaat, voert u voma opnieuw uit in de controlemodus om te valideren dat de VMFS-metadata op de schijf nog steeds consistent zijn. Eventuele inconsistenties in metagegevens moeten worden onderzocht voordat we verdergaan. 
Voma gebruikt de SCSI-2 reserveopdracht om het apparaat te vergrendelen om gelijktijdige toegang of wijziging van het VMFS-volume te voorkomen wanneer de voma-sessie actief is. NVMe-apparaten ondersteunen echter geen equivalent van een SCSI-2-reservering. Om dit te omzeilen, moet de gebruiker slagen voor de "-N" optie om VOMA wanneer het back-endapparaat NVMe is. Bijvoorbeeld:

• Voer VOMA (VMware On-Disk Metadata Analyzer) uit in de controlemodus door het volgende uit te voeren:

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

Selecteer een getal van 0-1:
dit is om aan te geven dat het de verantwoordelijkheid van de gebruiker is om te voorkomen dat het volume wordt geactiveerd of gelijktijdig wordt geopend vanaf andere hosts terwijl de huidige voma-sessie bezig is. Als de hier beschreven stappen zijn gevolgd en het apparaat in kaart is gebracht en gedetecteerd op slechts één ESXi-host, zou het veilig moeten zijn om door te gaan. De gebruiker moet "0" invoeren bij de prompt om door te gaan met de voma-controlemodus. Hieronder volgt een voorbeeld:
 

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

VMFS Checker versie 2.1 uitvoeren in controlemodus
Initialiseren van LVM-metadata, basiscontroles zijn uitgevoerd
Controleren op activiteit
van het bestandssysteem Ondersteuning voor reserveren is niet aanwezig voor st-activiteit van NVMe-apparaten (4096 bytes/HB, 1024 HB's).                                 \

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

 

Zet opnieuw handtekening voor het VMFS-volume 

Nu het apparaat wordt gepresenteerd als NVMe, is het noodzakelijk om de handtekening in de datastore bij te werken. Dit komt omdat de huidige handtekening gedeeltelijk is gebaseerd op de WWN van het apparaat wanneer het wordt gepresenteerd met behulp van SCSI. Omdat de NVMe-apparaat-id anders is, moet er een nieuwe handtekening worden gegenereerd. Voer daarom op dezelfde ESXi-host die in de vorige twee stappen is gebruikt, het volgende uit om het volume opnieuw te ondertekenen:

1. Hoewel redundant, moet u het bestandssysteem opnieuw scannen door de volgende opdracht uit te voeren:

ESXCLI Storage File System Rescan

2. Voer vervolgens de volgende opdracht uit om een lijst met VMFS snapshot-LUN's op te halen:

ESXCLI Storage VMFS-snapshotlijst

Het nieuw gepresenteerde NVMe-apparaat moet aanwezig zijn, maar afhankelijk van de omgeving kunnen er andere snapshots zijn die geen verband houden met dit proces.

3. Zet de handtekening van het VMFS-volume opnieuw door het volgende uit te voeren:

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

 

Hieronder ziet u een voorbeeld:

[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

Naam van de VMFS datastore wijzigen (optioneel)

Wanneer een VMFS-volume opnieuw wordt ondertekend, wordt het VMFS-volumelabel voorafgegaan door de tag "snap", gevolgd door een alfanumerieke tekenreeks. De VMFS-datastore in de vorige stap heeft nu bijvoorbeeld de volgende naam: snap-5c42a2bc-Temp_Datastore. Wijzig indien gewenst de naam van de datastore in de oorspronkelijke naam en verwijder het voorvoegsel.

Controleer de consistentie van VMFS-volumemetadata na het opnieuw ondertekenen.

Controleer nogmaals of de VMFS-metadata op de schijf consistent zijn na het opnieuw ondertekenen. Voer voma uit in de controlemodus op het VMFS-volume. Zie sectie 2.8 voor de voma-opdrachtregel die de "-N"-vlag moet bevatten. Controleer of voma inconsistenties rapporteert. Ga verder als voma geen fouten meldt. 

Presenteer het apparaat als NVMe op alle ESXi-hosts in het cluster.

Als er geen problemen waren bij een van de vorige stappen, kan het apparaat nu via NVMe worden gepresenteerd aan alle ESXi-hosts in het cluster. Zoals opgemerkt, worden NVMe-apparaten onmiddellijk herkend, maar als dit niet het geval is, scant u de adapters opnieuw via de vSphere-gebruikersinterface of CLI. Controleer of het VMFS6-volume is gekoppeld en toegankelijk is op alle hosts.

Registreer alle VM's en schakel ze in

Registreer alle VM's die worden gehost op de datastore en schakel ze in. Controleer of de VM's met succes worden ingeschakeld en toegang hebben tot de vmdk's. Als best practice kan de gebruiker VM's registreren en inschakelen op één ESXi. Zodra dit is gelukt, kunnen ze worden gemigreerd naar andere hosts.

Notitie: Bij het inschakelen van de VM's vanuit de vCenter-gebruikersinterface kan er een pop-upvenster verschijnen zoals hieronder weergegeven. Dit vraagt de gebruiker om vast te leggen of de VM is gekopieerd of verplaatst. Selecteer "I Copied it" in de pop-up.

 

Na de migratie

Controleer op impact op belangrijke functies en voer indien nodig opschoning uit. 

 

Dit is een officieel gescreend proces door VMware voor offline datastoremigratie. Online migraties van afzonderlijke VM's kunnen worden uitgevoerd met behulp van Storage vMotion. VMware heeft geen aparte KB voor dit proces.

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