SCSI till NVMe VMware VMFS-datalager – steg för offlinemigrering

Migreringssteg för SCSI till NVMe offline VMFS-datalager

Innehållsförteckning

• Migrering av SCSI till NVMe offline VMFS-datalager steg 1
• Översikt
• Omfattning

1. Steg för offlinemigrering
   1.  Före migrering
   2. Kontrollera både antalet enheter och sökvägarna till varje ESXi-värd 3 
   3. Kontrollera om det finns funktioner som inte stöds 4 
   4. Kontrollera om det kan påverka funktioner som stöds av migreringen 4 
2. Migrering
   1. Demontera VMFS-volym från alla värdar 5 
   2. Kontrollera konsekvensen för VMFS-volymmetadata. 5 
   3. Signatur på VMFS-volym 10 på nytt 
   4. Byt namn på VMFS-datalagret (valfritt) 11 
   5. Kontrollera konsekvensen för VMFS-volymmetadata efter omsignatur. 11 
   6. Presentera enheten som NVMe för alla ESXi-värdar i klustret 11 
   7. Registrera och slå på alla virtuella maskiner 11 
3. Efter migreringen. 12 

 

---

 

Översikt

I takt med att NVMe-implementeringen ökar överväger fler kunder att migrera data från SCSI till NVMe. I det här dokumentet beskrivs en av de effektiva, om än störande, metoderna för att migrera SCSI till NVMe som kallas offlinemigrering. Offlinemigrering av VMFS-datalager från SCSI till NVMe innebär inte att data flyttas. Den enhet som tidigare presenterades för en ESXi-värd eller ett ESXi-kluster som en SCSI-enhet presenteras inte och visas sedan på nytt som en NVMe-enhet. VMFS-datalagringen signeras sedan på nytt och görs tillgänglig för värdarna, med bibehållet innehåll i den virtuella datorn. Information om stegen för offlinemigrering beskrivs nedan.

Omfattning

• Stegen för offlinemigrering, som beskrivs i efterföljande avsnitt, gäller endast för VMFS6-datalager.
• Stegen omfattar funktionella aspekter av migreringen och omfattar inte prestandaegenskaper för arbetsbelastningar efter migreringen.
• Valideringen av skala (antal samtidiga migreringar osv.) eller gränser (maximalt antal sökvägar per enhet, maximalt antal VMDK:er per virtuell dator osv.) omfattas inte.
• Termerna enhet, volym och LUN används omväxlande i dokumentet.
• Offlinemigrering kräver att alla virtuella datorer i VMFS-datalagret stängs av innan du startar.  

 

---

 

1. Steg för offlinemigrering

   Offlinemigrering av ett VMFS6-datalager från SCSI till NVMe består av tre faser. Varje fas kan omfatta flera kontroller eller steg.

   1. Före migrering

      Denna förberedande fas omfattar kontroller för att förstå miljöns egenskaper och de funktioner som används. Den här fasen krävs för att avgöra om offlinemigrering är möjlig i miljön och även för att förstå effekten efter migreringen. Några av de viktiga kontrollerna listas nedan. Detta är inte en uttömmande lista, snarare täcker den de vanligaste kontrollerna i en standardkundmiljö.

   2. Leta efter låsningsläge för VMFS-volymen

      Kontrollera först att LUN har stöd för ATS-läge. Migrering bör endast göras om VMFS6-datalagringen använder endast ATS-låsningsläge och inte använder SCSI-2-reservationer. 
      
      Om du vill ta reda på låsläget för en viss volym kör du kommandot esxcli storage vmfs lockmode list -l <volume name/label> på en ESXi-värd med åtkomst till datalagret. Offlinemigrering stöds endast om låsläget för VMFS6-volymen är "ATS". Läget "ATS+SCSI" stöds inte.
      
      Ett exempel på en volym som stöder offlinemigrering:

      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. Kontrollera om det finns några vmdk för en virtuell dator i det valda datalagret används som en RDM (fysisk eller virtuell)

      Om en virtuell dator i det valda datalagret har en RDM i SCSI-läge kan den inte tillåtas att migrera till NVMe. Det finns inget VMware-kommando för att ta reda på om en virtuell dator har en RDM, men i Dells VSI-insticksprogram visas disktypen för varje virtuell dator. Nedan visas en skärmbild av vyn i VSI som visar om några virtuella datorer (Runtime Name) har en RDM.
      
       
       

      Om en virtuell dator har en RDM måste RDM antingen tas bort från den virtuella datorn, konverteras eller så måste den virtuella datorn flyttas till ett annat datalager före migreringen.

   4. 1.3 Kontrollera anspråksregler/inställningsmappning till enheten som är värd för VMFS-datalagret

      Om det finns anpassade anspråksregler på SCSI-enheten före migreringen kommer de troligen inte att tillämpas på enheten när de presenteras med NVMe. NVMe-enheter visas inte med separata leverantörs- och modellfält när de öppnas via förfrågan. Fälten är tillsammans, och därför är en ny anspråksregel nödvändig om så önskas. Dessutom misslyckas anspråksregler som baseras på enhetsidentifierare, t.ex. World Wide Name (WWN) eftersom SCSI-identifieraren och NVMe-identifieraren är distinkta.
      Som standard gör VMware anspråk på nyligen presenterade NVMe-enheter med standardinsticksprogrammet för sökvägar HPP.

   5. Kontrollera både antalet enheter och sökvägarna till varje ESXi-värd

      NVMe har stöd för färre enheter och sökvägar än SCSI till varje ESXi-värd. Om antalet SCSI-enheter överskrider NVMe-gränserna går det inte att konvertera alla datalager på samma ESXi-värd. Som en lösning kan kunder använda fler ESXi-värdar eller konsolidera datalager antingen före eller efter konvertering med hjälp av Storage vMotion. 

      1. SCSI – 1 024 enheter/4 096 sökvägar
      2. NVMe – 256 enheter/2 048 sökvägar

   6. Kontrollera om det finns funktioner som inte stöds 

      Vissa VMware-funktioner stöds för närvarande inte med NVMe. Kontrollera om det finns stöd före migreringen.

      Följande funktioner stöds till exempel för närvarande inte på NVMe som körs på ESXi (till och med version 8.0U1).

       

      Funktion	Kortfattad beskrivning	Anmärkningar
      Gästklustring	Klustrad VMDK-funktion som stöder lösningar med hög tillgänglighet, till exempel Windows Server Failover Cluster (WSFC)	Ett VMFS-datalager med klustrad VMDK Det går inte att migrera den aktiverade.
      SRM	Disksystembaserad replikering med SRM stöds inte på NVMe.	Migrering av datalager som berörs av SRM-arrayreplikering gör lösningen oanvändbar.

       
      Obs! Ovanstående lista är inte uttömmande. Kunder bör kontrollera med den disksystemspecifika dokumentationen om migreringens inverkan på de kritiska funktionerna.

   7. Kontrollera om det kan påverka funktioner som stöds efter migreringen

      Bristen på integrering av följande funktioner kan ändra hur vissa åtgärder utförs på NVMe jämfört med SCSI.

      Funktion	Typ av påverkan	Lösning
      Accelererad förflyttning av hårdvara – XCOPY	Det finns för närvarande inget motsvarande kommando för XCOPY. VMware Software Data Mover används istället. Detta kan minska prestanda för åtgärder som använder primitiven, till exempel kloning eller SvMotion.	Inget
      Skriv samma/UNMAP	Om en NVMe-enhet inte stöder NVMe-motsvarigheten till skrivnollor eller unmapkan det påverka prestandan.	Inget

 

---

 

1. Migrering

   I den här fasen ingår stegen för att migrera datalagringen från SCSI till NVMe.

2. Stäng av alla virtuella datorer och avregistrera dig

   Stäng av och avregistrera alla virtuella datorer som finns i datalagringen som ska migreras. Var noga med att inte ta bort dem, bara avregistrera.

3. Demontera VMFS-volymen från alla värdar

   Demontera VMFS-volymen från alla ESXi-värdar när alla virtuella datorer har avregistrerats. Detta för att säkerställa att den inte används när konsekvenskontrollen och migreringen utförs

4. Kontrollera konsekvens för VMFS-volymmetadata

   Innan du påbörjar migreringen kontrollerar du konsekvensen för VMFS-metadata på disken. Detta säkerställer att det inte finns några inkonsekvenser innan du börjar.

   1. Kör VOMA (VMware On-Disk Metadata Analyzer) i kontrollläge genom att köra:

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

    

   Var:

   DEVICE är den SCSI-enhet som är värd för VMFS6-volymen som migreras

   PARTITION är det partitionsnummer som VMFS-volymen är formaterad på enheten på

   UTDATAFIL är den absoluta sökvägen till filen där utdata från kommandot måste sparas. Den här filen finns i /tmp om den har tillräckligt med utrymme eller någon annan VMFS-volym än den som migreras.

   Som i:

    

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

   Utdata bör se ut ungefär så här:

   [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

   Obs! Om kommandot tar emot följande fel avmonteras inte VMFS korrekt:

    

VOMA Det gick inte att kontrollera enheten: Enheten eller resursen är upptagen

2. Analysera utdatafilen för att se om det finns några inkonsekvenser i metadata som rapporterats av voma. Om det finns några måste de åtgärdas genom att köra voma i avancerat korrigeringsläge innan du fortsätter. Följande är ett exempel:

[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. Samla in och spara VMFS-metadatadump. Detta krävs om inkonsekvenser i metadata visas i efterföljande steg. 

Se https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.html för mer information om hur du använder voma i check, avancerat korrigeringsläge eller dumpläge.

Koppla bort SCSI LUN från ESXi-värdar

Koppla loss SCSI LUN från varje ESXi-värd i VC. Detaljerade anvisningar finns i KB-artikeln https://kb.vmware.com/s/article/2004605 .

 

Sluta presentera SCSI LUN från disksystemet.

Stegen för att ta bort SCSI LUN är specifika för lagringsdisksystemet. Kunder bör kontrollera den disksystemspecifika dokumentationen om proceduren.

 

Presentera enheten som NVMe för en ESXi-värd.

Stegen för att återpresentera enheten med NVMe är specifika för lagringsdisksystem. Kunder bör kontrollera den disksystemspecifika dokumentationen om proceduren. 

Initiera en ny genomsökning av enheten på värden.

När enheten presenteras för ESXi-värden med NVMe är identifieringen vanligtvis omedelbar. Men om enheten inte visas skannar du ett eller flera kort igen med hjälp av vSphere-användargränssnittet eller CLI:
 

esxcli storage core adapter rescan -a

 

Kontrollera konsekvensen för VMFS-volymmetadata efter konverteringen.

På ESXi-värden som har åtkomst till enheten kör du voma igen i kontrollläge för att verifiera att VMFS-metadata på disken fortfarande är konsekventa. Eventuella inkonsekvenser i metadata måste undersökas innan du fortsätter. 
Voma använder kommandot SCSI-2 reserve för att låsa enheten för att förhindra samtidig åtkomst eller ändring av VMFS-volymen när voma-sessionen är aktiv. NVMe-enheter stöder dock inte en motsvarighet till en SCSI-2-reservation. För att komma runt detta måste användaren skicka "-N" för att VOMA när backend-enheten är NVMe. Till exempel:

• Kör VOMA (VMware On-Disk Metadata Analyzer) i kontrollläge genom att köra:

 

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

När voma anropas med "-N" visas följande varningsmeddelande. 

 

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

Välj ett nummer mellan 0 och 1:
Detta är för att meddela att det är användarens ansvar att förhindra att volymen monteras eller nås samtidigt från andra värdar medan den aktuella voma-sessionen pågår. Om stegen som beskrivs här har följts och enheten har mappats och identifierats på endast en ESXi-värd bör det vara säkert att fortsätta. Användaren ska ange "0" vid uppmaningen att fortsätta med voma-kontrollläge. Ett exempel följer:
 

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

Köra VMFS Checker version 2.1 i kontrollläge
Initierar LVM-metadata, Grundläggande kontroller görs
Söker efter filsystemaktivitet
Reservationsstöd finns inte för NVMe-enheters ST-aktivitet (4096 byte/HB, 1024 HBs).                                 \
Utföra livehetskontroll för filsystemet..|

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

Välj ett tal mellan 0 och 1:

0 Fas 1: Kontrollerar VMFS-huvud och resursfiler
Identifierade VMFS-6-filsystemet (märkt:'Temp_Datastore') med UUID:64359f88-dd0fd27e-af5a-34800d0ed39c, Version 6:82
Fas 2: Kontrollera VMFS-pulsslagsregion
fas 3: Kontrollerar alla filbeskrivningar.
Fas 4: Kontrollera sökväg och anslutning.
Fas 5: Kontrollera antalet resursreferenser.
Totalt antal fel som hittades:           0

Signera VMFS-volymen på nytt 

Nu när enheten visas som NVMe är det nödvändigt att uppdatera signaturen som finns i datalagringen. Det beror på att den aktuella signaturen delvis baseras på enhetens WWN när den presenteras med SCSI. Eftersom NVMe-enhets-ID:t är annorlunda måste en ny signatur genereras. På samma ESXi-värd som användes i de två föregående stegen kör du därför följande för att signera volymen på nytt:

1. Även om det är redundant genomsöker du filsystemet igen genom att köra kommandot:

 

esxcli storage filesystem rescan

2. Kör sedan följande kommando för att hämta en lista över VMFS-ögonblicksbilder LUN:

 

esxcli storage vmfs snapshot list

Den nyligen presenterade NVMe-enheten bör finnas, men beroende på miljön kan det finnas andra snapshots som inte är relaterade till den här processen.

3. Signera VMFS-volymen på nytt genom att köra följande:

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

Ett exempel finns nedan:
 

[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

 

Byt namn på VMFS-datalagringen (valfritt)

När en VMFS-volym signeras på nytt föregås VMFS-volymetiketten av taggen "snap" följt av en alfanumerisk sträng. VMFS-datalagringen i föregående steg heter till exempel nu: snap-5c42a2bc-Temp_Datastore Om du vill kan du byta namn på datalagringen till det ursprungliga namnet och ta bort prefixet.

Kontrollera konsekvensen för VMFS-volymmetadata efter omsignatur.

Kontrollera än en gång att VMFS-metadata på disken är konsekventa efter omsignaturen. Kör voma i kontrollläge på VMFS-volymen. Se avsnitt 2.8 för voma-kommandoraden som måste innehålla flaggan "-N". Kontrollera om voma rapporterar några inkonsekvenser. Fortsätt om voma inte rapporterar några fel. 

Presentera enheten som NVMe för alla ESXi-värdar i klustret.

Om det inte uppstod några problem i något av de föregående stegen kan enheten nu presenteras med NVMe för alla ESXi-värdar i klustret. Som nämnts identifieras NVMe-enheter omedelbart, men om de inte genomsöks korten igen via vSphere-användargränssnittet eller CLI. Kontrollera att VMFS6-volymen är monterad och tillgänglig på alla värdar.

Registrera och slå på alla virtuella maskiner

Registrera alla virtuella datorer som finns i datalagret och slå på dem. Kontrollera att VM:arna startar som de ska och har åtkomst till vmdks. Som bästa praxis kan användaren registrera och starta virtuella datorer på en enda ESXi. När de lyckas kan de migreras till andra värdar.

Not: När du startar VM:arna från vCenter-användargränssnittet kan det finnas ett popup-fönster, som det som visas nedan. Detta uppmanar användaren att registrera om den virtuella datorn kopierades eller flyttades. Välj "Jag kopierade den" i popup-fönstret.

 

 

---

 

Efter migreringen

Kontrollera om eventuella viktiga funktioner påverkas och utför eventuell rensning vid behov. 

1.4 Kontrollera både antalet enheter och sökvägarna till varje ESXi-värd 3
1.5 Kontrollera om det finns funktioner som inte stöds 4
1.6 Kontrollera om det finns någon potentiell inverkan efter migreringen på funktioner som stöds 4
2.  Migration 4
2.2 Demontera VMFS-volymen från alla värdar 5
2.3 Kontrollera VMFS-volymens metadatakonsistens.
5 2.9 Signatur på nytt VMFS-volymen 10
2.10 Byt namn på VMFS-datalagret (valfritt) 11
2.11 Kontrollera VMFS-volymens metadatakonsistens efter ny signatur. 11
2.12 Presentera enheten som NVMe för alla ESXi-värdar i klustret 11
2.13 Registrera och slå på alla virtuella datorer 11
3. Efter migreringen. 12

Översikt

I takt med att NVMe-implementeringen ökar överväger fler kunder att migrera data från SCSI till NVMe. I det här dokumentet beskrivs en av de effektiva, om än störande, metoderna för att migrera SCSI till NVMe som kallas offlinemigrering. Offlinemigrering av VMFS-datalager från SCSI till NVMe innebär inte att data flyttas. Den enhet som tidigare presenterades för en ESXi-värd eller ett ESXi-kluster som en SCSI-enhet presenteras inte och visas sedan på nytt som en NVMe-enhet. VMFS-datalagringen signeras sedan på nytt och görs tillgänglig för värdarna, med bibehållet innehåll i den virtuella datorn. Information om stegen för offlinemigrering beskrivs nedan.

Omfattning

• Stegen för offlinemigrering, som beskrivs i efterföljande avsnitt, gäller endast för VMFS6-datalager.
• Stegen omfattar funktionella aspekter av migreringen och omfattar inte prestandaegenskaper för arbetsbelastningar efter migreringen.
• Valideringen av skala (antal samtidiga migreringar osv.) eller gränser (maximalt antal sökvägar per enhet, maximalt antal VMDK:er per virtuell dator osv.) omfattas inte.
• Termerna enhet, volym och LUN används omväxlande i dokumentet.
• Offlinemigrering kräver att alla virtuella datorer i VMFS-datalagret stängs av innan du startar.  

Steg för offlinemigrering

Offlinemigrering av ett VMFS6-datalager från SCSI till NVMe består av tre faser. Varje fas kan omfatta flera kontroller eller steg.

Före migrering

Denna förberedande fas omfattar kontroller för att förstå miljöns egenskaper och de funktioner som används. Den här fasen krävs för att avgöra om offlinemigrering är möjlig i miljön och även för att förstå effekten efter migreringen. Några av de viktiga kontrollerna listas nedan. Detta är inte en uttömmande lista, snarare täcker den de vanligaste kontrollerna i en standardkundmiljö.

Kontrollera om VMFS-volymen är låst i låsläge.

Kontrollera först att LUN har stöd för ATS-läge. Migrering bör endast göras om VMFS6-datalagringen använder endast ATS-låsningsläge och inte använder SCSI-2-reservationer. 

Om du vill ta reda på låsläget för en viss volym kör du kommandot esxcli storage vmfs lockmode list -l <volume name/label> på en ESXi-värd med åtkomst till datalagret. Offlinemigrering stöds endast om låsläget för VMFS6-volymen är "ATS". Läget "ATS+SCSI" stöds inte.

Ett exempel på en volym som stöder offlinemigrering:

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 Kontrollera om det finns några vmdk för en virtuell dator i det valda datalagret används som en RDM (fysisk eller virtuell)

Om en virtuell dator i det valda datalagret har en RDM i SCSI-läge kan den inte tillåtas att migrera till NVMe. Det finns inget VMware-kommando för att ta reda på om en virtuell dator har en RDM, men i Dells VSI-insticksprogram visas disktypen för varje virtuell dator. Nedan visas en skärmbild av vyn i VSI som visar om några virtuella datorer (körningsnamn) har en RDM.

 

Om en virtuell dator har en RDM måste RDM antingen tas bort från den virtuella datorn, konverteras eller så måste den virtuella datorn flyttas till ett annat datalager före migreringen.

1.3 Kontrollera claim rules/settings mappning till den enhet som är värd för VMFS-datalagring.

Om det finns anpassade anspråksregler på SCSI-enheten före migreringen kommer de troligen inte att tillämpas på enheten när de presenteras med NVMe. NVMe-enheter visas inte med separata leverantörs- och modellfält när de öppnas via förfrågan. Fälten är tillsammans, och därför är en ny anspråksregel nödvändig om så önskas. Dessutom misslyckas anspråksregler som baseras på enhetsidentifierare, t.ex. World Wide Name (WWN) eftersom SCSI-identifieraren och NVMe-identifieraren är distinkta.
Som standard gör VMware anspråk på nyligen presenterade NVMe-enheter med HPP:s standardinsticksprogram för sökvägar.

1.4 Kontrollera både antalet enheter och sökvägarna till varje ESXi-värd.

NVMe har stöd för färre enheter och sökvägar än SCSI till varje ESXi-värd. Om antalet SCSI-enheter överskrider NVMe-gränserna går det inte att konvertera alla datalager på samma ESXi-värd. Som en lösning kan kunder använda fler ESXi-värdar eller konsolidera datalager antingen före eller efter konvertering med hjälp av Storage vMotion. 

1. SCSI – 1 024 enheter/4 096 sökvägar
2. NVMe – 256 enheter/2 048 sökvägar

1.5 Kontrollera om det finns funktioner som inte stöds. 

Vissa VMware-funktioner stöds för närvarande inte med NVMe. Kontrollera om det finns stöd före migreringen.
Följande funktioner stöds till exempel för närvarande inte på NVMe som körs på ESXi (till och med version 8.0U1). 
 

Funktion	Kortfattad beskrivning	Anmärkningar
Gästklustring	Klustrad VMDK-funktion som stöder lösningar med hög tillgänglighet, till exempel Windows Server Failover Cluster (WSFC)	Det går inte att migrera ett VMFS-datalager med klustrad VMDK aktiverat.
SRM	Disksystembaserad replikering med SRM stöds inte på NVMe.	Migrering av datalager som berörs av SRM-arrayreplikering gör lösningen oanvändbar.

Obs! Ovanstående lista är inte uttömmande. Kunder bör kontrollera med den disksystemspecifika dokumentationen om migreringens inverkan på de kritiska funktionerna. 

 

Kontrollera om det kan påverka funktioner som stöds av migreringen.

Bristen på integrering av följande funktioner kan ändra hur vissa åtgärder utförs på NVMe jämfört med SCSI.
 

Funktion	Typ av påverkan	Lösning
Accelererad förflyttning av hårdvara – XCOPY	Det finns för närvarande inget motsvarande kommando för XCOPY. VMware Mjukvarudataöverförare kommer att användas i stället. Detta kan minska prestanda för åtgärder som normalt använder primitiven, till exempel kloning eller SvMotion.	Inget
Skriv samma/UNMAP	Om en NVMe-enhet inte stöder NVMe-motsvarigheten till skrivnollor eller unmapkan det påverka prestandan.	Inget

Migrering

I den här fasen ingår stegen för att migrera datalagringen från SCSI till NVMe.

Stäng av alla virtuella datorer och avregistrera dig

Stäng av och avregistrera alla virtuella datorer som finns i datalagringen som ska migreras. Var noga med att inte ta bort dem, bara avregistrera.

Demontera VMFS-volymen från alla värdar

Demontera VMFS-volymen från alla ESXi-värdar när alla virtuella datorer har avregistrerats. Detta är för att säkerställa att den inte används när konsekvenskontrollen och migreringen utförs. 

Kontrollera konsekvensen för VMFS-volymmetadata.

Innan du påbörjar migreringen kontrollerar du konsekvensen för VMFS-metadata på disken. Detta säkerställer att det inte finns några inkonsekvenser innan början.

1. Kör VOMA (VMware On-Disk Metadata Analyzer) i kontrollläge genom att köra:

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

Var:
DEVICE är SCSI-enheten som är värd för VMFS6-volymen som migreras.
PARTITION är partitionsnumret som VMFS-volymen är formaterad på enheten.
UTDATAFIL är den absoluta sökvägen till filen där utdata från kommandot måste sparas. Den här filen finns i /tmp om den har tillräckligt med utrymme eller någon annan VMFS-volym än den som migreras.

Till exempel:

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

Utdata bör se ut ungefär så här:
 

[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

Obs! Om kommandot tar emot följande fel är VMFS inte demonterat korrekt:

VOMA kunde inte kontrollera enheten: Enheten eller resursen är upptagen

2. Analysera utdatafilen för att se om det finns några inkonsekvenser i metadata som rapporterats av voma. Om det finns några måste de åtgärdas genom att köra voma i avancerat korrigeringsläge innan du fortsätter. Följande är ett exempel:

[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. Samla in och spara VMFS-metadatadump. Detta krävs om inkonsekvenser i metadata visas i efterföljande steg. 

Se https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.html för mer information om hur du använder voma i check, avancerat korrigeringsläge eller dumpläge.

Koppla bort SCSI LUN från ESXi-värdar

Koppla loss SCSI LUN från varje ESXi-värd i VC. Detaljerade anvisningar finns i KB-artikeln https://kb.vmware.com/s/article/2004605.

Sluta presentera SCSI LUN från disksystemet.

Stegen för att ta bort SCSI LUN är specifika för lagringsdisksystemet. Kunder bör kontrollera den disksystemspecifika dokumentationen om proceduren.

Presentera enheten som NVMe för en ESXi-värd.

Stegen för att återpresentera enheten med NVMe är specifika för lagringsdisksystem. Kunder bör kontrollera den disksystemspecifika dokumentationen om proceduren. 

Initiera en ny genomsökning av enheten på värden.

När enheten presenteras för ESXi-värden med NVMe är identifieringen vanligtvis omedelbar. Men om enheten inte visas skannar du ett eller flera kort igen med hjälp av vSphere-användargränssnittet eller CLI:
 

esxcli storage core adapter rescan -a

Kontrollera konsekvensen för VMFS-volymmetadata efter konverteringen.

På ESXi-värden som har åtkomst till enheten kör du voma igen i kontrollläge för att verifiera att VMFS-metadata på disken fortfarande är konsekventa. Eventuella inkonsekvenser i metadata måste undersökas innan du fortsätter. 
Voma använder kommandot SCSI-2 reserve för att låsa enheten för att förhindra samtidig åtkomst eller ändring av VMFS-volymen när voma-sessionen är aktiv. NVMe-enheter stöder dock inte en motsvarighet till en SCSI-2-reservation. För att komma runt detta måste användaren skicka "-N" för att VOMA när backend-enheten är NVMe. Till exempel:

• Kör VOMA (VMware On-Disk Metadata Analyzer) i kontrollläge genom att köra:

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

Välj ett nummer mellan 0 och 1:
Detta är för att meddela att det är användarens ansvar att förhindra att volymen monteras eller nås samtidigt från andra värdar medan den aktuella voma-sessionen pågår. Om stegen som beskrivs här har följts och enheten har mappats och identifierats på endast en ESXi-värd bör det vara säkert att fortsätta. Användaren ska ange "0" vid uppmaningen att fortsätta med voma-kontrollläge. Ett exempel följer:
 

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

Köra VMFS Checker version 2.1 i kontrollläge
Initierar LVM-metadata, Grundläggande kontroller görs
Söker efter filsystemaktivitet
Reservationsstöd finns inte för NVMe-enheters ST-aktivitet (4096 byte/HB, 1024 HBs).                                 \

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

 

Signera VMFS-volymen på nytt 

Nu när enheten visas som NVMe är det nödvändigt att uppdatera signaturen som finns i datalagringen. Det beror på att den aktuella signaturen delvis baseras på enhetens WWN när den presenteras med SCSI. Eftersom NVMe-enhets-ID:t är annorlunda måste en ny signatur genereras. På samma ESXi-värd som användes i de två föregående stegen kör du därför följande för att signera volymen på nytt:

1. Även om det är redundant genomsöker du filsystemet igen genom att köra kommandot:

ESXCLI – Genomsökning av lagringsfilsystemet igen

2. Kör sedan följande kommando för att hämta en lista över VMFS-ögonblicksbilder LUN:

esxcli lagring vmfs-snapshotlista

Den nyligen presenterade NVMe-enheten bör finnas, men beroende på miljön kan det finnas andra snapshots som inte är relaterade till den här processen.

3. Signera VMFS-volymen på nytt genom att köra följande:

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

 

Ett exempel finns nedan:

[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

Byt namn på VMFS-datalagringen (valfritt)

När en VMFS-volym signeras på nytt föregås VMFS-volymetiketten av taggen "snap" följt av en alfanumerisk sträng. Till exempel heter VMFS-datalagringen i föregående steg nu: snap-5c42a2bc-Temp_Datastore. Om du vill kan du byta namn på datalagringen till det ursprungliga namnet och ta bort prefixet.

Kontrollera konsekvensen för VMFS-volymmetadata efter omsignatur.

Kontrollera än en gång att VMFS-metadata på disken är konsekventa efter omsignaturen. Kör voma i kontrollläge på VMFS-volymen. Se avsnitt 2.8 för voma-kommandoraden som måste innehålla flaggan "-N". Kontrollera om voma rapporterar några inkonsekvenser. Fortsätt om voma inte rapporterar några fel. 

Presentera enheten som NVMe för alla ESXi-värdar i klustret.

Om det inte uppstod några problem i något av de föregående stegen kan enheten nu presenteras med NVMe för alla ESXi-värdar i klustret. Som nämnts identifieras NVMe-enheter omedelbart, men om de inte genomsöks korten igen via vSphere-användargränssnittet eller CLI. Kontrollera att VMFS6-volymen är monterad och tillgänglig på alla värdar.

Registrera och slå på alla virtuella maskiner

Registrera alla virtuella datorer som finns i datalagret och slå på dem. Kontrollera att VM:arna startar som de ska och har åtkomst till vmdks. Som bästa praxis kan användaren registrera och starta virtuella datorer på en enda ESXi. När de lyckas kan de migreras till andra värdar.

Not: När du startar VM:arna från vCenter-användargränssnittet kan det finnas ett popup-fönster, som det som visas nedan. Detta uppmanar användaren att registrera om den virtuella datorn kopierades eller flyttades. Välj "Jag kopierade den" i popup-fönstret.

 

Efter migreringen

Kontrollera om eventuella viktiga funktioner påverkas och utför eventuell rensning vid behov. 

 

Det här är en officiellt kontrollerad process av VMware för offlinemigrering av datalager. Onlinemigreringar av enskilda virtuella datorer kan utföras med Storage vMotion. VMware har ingen separat KB för den här processen.

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