Fremgangsmåte for frakoblet migrering av SCSI til NVMe VMware VMFS Datastore

Migreringstrinn for SCSI til NVMe frakoblet VMFS-datalager

Innholdsfortegnelse

• SCSI til NVMe Frakoblet VMFS-datalagermigrering Trinn 1
• Oversikt
• Omfang

1. Trinn for frakoblet overføring
   1.  Før migreringen
   2. Kontroller både antall enheter og baner til hver ESXi-vert 3 
   3. Se etter funksjoner som ikke støttes, 4 
   4. Kontrollere om det kan påvirke funksjoner som er lagt inn etter overføringen, 4 
2. Migrering
   1. Demonter VMFS-volum fra alle verter 5 
   2. Kontroller konsistens i VMFS-volummetadata. 5 
   3. Signatur VMFS volum 10 på nytt 
   4. Gi nytt navn til VMFS-datalageret (valgfritt) 11 
   5. Kontroller konsekvens av VMFS-volummetadata etter ny signatur. 11 
   6. Presentere enheten som NVMe for alle ESXi-verter i klyngen 11 
   7. Registrer deg og slå på alle VM-er 11 
3. Etter overføringen. 12 

 

---

 

Oversikt

Etter hvert som implementeringen av NVMe vokser, ser flere kunder på migrering av data fra SCSI til NVMe. Dette dokumentet beskriver en av de effektive, om enn forstyrrende, metodene for å migrere SCSI til NVMe, kjent som frakoblet migrering. Frakoblet migrering av VMFS-datalager fra SCSI til NVMe involverer ikke flytting av data. Enheten som tidligere ble presentert for en ESXi-vert eller -klynge som en SCSI-enhet, blir ikke presentert og deretter presentert på nytt som en NVMe-enhet. VMFS-datalageret signeres deretter på nytt og gjøres tilgjengelig for vertene, og beholder VM-innholdet. Nedenfor beskrives detaljer om trinnene for frakoblet overføring.

Omfang

• Trinnene for frakoblet migrering, som beskrives i de påfølgende delene, gjelder bare for VMFS6-datalagre.
• Trinn dekker funksjonelle aspekter ved overføringen og dekker ikke ytelsesegenskaper for arbeidsbelastninger som er etter overføringen.
• Validering av skala (antall samtidige migreringer osv.) eller grenser (maksimale baner per enhet, maksimalt antall VMDK-er per VM osv.) er ikke inkludert.
• Begrepene enhet, volum og LUN brukes om hverandre i dokumentet.
• Frakoblet migrering krever at alle virtuelle maskiner i VMFS-datalageret er slått av før start.  

 

---

 

1. Trinn for frakoblet overføring

   Frakoblet migrering av et VMFS6-datalager fra SCSI til NVMe består av tre faser. Hver fase kan omfatte flere kontroller eller trinn.

   1. Før migreringen

      Denne forberedende fasen inkluderer kontroller for å forstå egenskapene til miljøet og funksjonene som er i bruk. Denne fasen er nødvendig for å avgjøre om frakoblet migrering er mulig i miljøet, og også for å forstå virkningen etter overføringen. Noen av de viktige kontrollene er oppført nedenfor. Dette er ikke en uttømmende liste, men dekker de vanligste kontrollene i et standard kundemiljø.

   2. Se etter låsemodus for VMFS-volum

      Kontroller først at LUN-en støtter ATS-modus. Overføring bør bare forsøkes hvis VMFS6-datalageret bruker låsemodus bare ATS, og ikke bruker SCSI-2-reservasjoner. 
      
      For å bestemme låsemodus for et gitt volum, kjør kommandoen esxcli storage vmfs lockmode list -l <volume name/label> på en ESXi-vert med tilgang til datalageret. Frakoblet overføring støttes bare hvis låsemodusen for VMFS6-volumet er "ATS". Modusen "ATS+SCSI" støttes ikke.
      
      Et eksempel på et volum som støtter frakoblet migrering:

      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. Sjekk om noen vmdk av alle virtuelle maskiner i det valgte datalageret brukes som RDM (fysisk eller virtuell)

      Hvis en virtuell maskin i det valgte datalageret har en RDM i SCSI-modus, kan det ikke tillates å migrere til NVMe. Det finnes ingen VMware-kommando for å finne ut om en virtuell maskin har en RDM, men Dell VSI-plugin-modulen viser disktypen for hver virtuelle maskin. Nedenfor finner du et skjermbilde av visningen i VSI, som viser om noen VM-er (kjøretidsnavn) har en RDM.
      
       
       

      Hvis en virtuell maskin har en RDM, må enten RDM-en fjernes fra den virtuelle maskinen, konverteres, eller VM-en flyttes til et annet datalager før migreringen.

   4. 1.3 Sjekk tilordning av kravregler/innstillinger til enheten som er vert for VMFS-datalager

      Hvis det finnes egendefinerte kravregler på SCSI-enheten før migrering, blir de sannsynligvis ikke brukt på enheten når de presenteres ved hjelp av NVMe. NVMe-enheter vises ikke med separate leverandør- og modellfelt når de åpnes via forespørsel. Feltene er samlet, og dermed er det nødvendig med en ny kravregel hvis ønskelig. I tillegg vil kravregler basert på enhetsidentifikatorer, f.eks. World Wide Name (WWN), mislykkes siden SCSI-identifikatoren og NVMe-identifikatoren er distinkte.
      Som standard gjør VMware krav på nylig presenterte NVMe-enheter med standard baneplugin for HPP.

   5. Kontroller både antall enheter og baner til hver ESXi-vert

      NVMe støtter færre enheter og baner enn SCSI til hver ESXi-vert. Hvis antallet SCSI-enheter overskrider NVMe-grensene, er det ikke mulig å konvertere alle datalagrene på samme ESXi-vert. Som en løsning kan kundene ansette flere ESXi-verter eller konsolidere datalagre enten før eller etter konvertering ved hjelp av Storage vMotion. 

      1. SCSI – 1024 enheter/4096 baner
      2. NVMe – 256 enheter/2048 baner

   6. Se etter funksjoner som ikke støttes 

      Noen VMware-funksjoner støttes for øyeblikket ikke med NVMe. Kontroller om det kan støttes før migrering.

      Følgende funksjoner støttes for eksempel for øyeblikket ikke på NVMe som kjører på ESXi (til og med versjon 8.0U1).

       

      Funksjon	Kort beskrivelse	Kommentarer
      Gjesteklynger	VMDK-funksjon for klynger som støtter løsninger med høy tilgjengelighet, for eksempel Windows Server Failover Cluster (WSFC)	Et VMFS-datalager med klynger VMDK Aktivert kan ikke migreres.
      SRM	Arraybasert replikering med SRM støttes ikke på NVMe.	Overføring av datalagre som er involvert i SRM-arrayreplikering, gjør løsningen ubrukelig.

       
      Merk: Listen ovenfor er ikke uttømmende. Kunder bør sjekke med array-spesifikk dokumentasjon angående virkningen av overføringen på de kritiske funksjonene.

   7. Kontrollere om det kan påvirke funksjoner etter migrering på støttede funksjoner

      Mangelen på integrering av følgende funksjoner kan endre hvordan enkelte operasjoner utføres på NVMe sammenlignet med SCSI.

      Funksjon	Påvirkningens natur	Handlingen som skal utføres
      Maskinvareakselerert flytting – XCOPY	Det finnes for øyeblikket ingen tilsvarende kommando til XCOPY. VMware-programvaren Data Mover brukes i stedet. Dette kan redusere ytelsen til operasjoner som bruker det primitive, for eksempel kloning eller SvMotion.	None
      Skriv samme / UNMAP	Hvis en NVMe-enhet ikke støtter NVMe-ekvivalenten for skrivenuller eller unmap, kan det ha innvirkning på ytelsen.	None

 

---

 

1. Migrering

   Denne fasen omfatter trinnene for å overføre datalageret fra SCSI til NVMe.

2. Slå av alle virtuelle maskiner, og avregistrer deg

   Slå av, og avregistrer alle VM-er på datalageret som skal migreres. Pass på at du ikke sletter dem, bare avregistrerer.

3. Demonter VMFS-volum fra alle verter

   Demonter VMFS-volumet fra alle ESXi-verter når alle VM-er er avregistrert. Dette er for å sikre at den ikke er i bruk når konsistenskontrollen og migreringen utføres

4. Kontroller konsekvens av VMFS-volummetadata

   Før du starter migreringen, må du kontrollere konsekvensen til VMFS-metadata på disken. Dette sikrer at det ikke er noen uoverensstemmelser før du begynner.

   1. Kjør VOMA (VMware On-Disk Metadata Analyzer) i kontrollmodus ved å kjøre:

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

    

   Der:

   DEVICE er SCSI-enheten som er vert for VMFS6-volumet som overføres

   PARTITION er partisjonsnummeret som VMFS-volumet er formatert på enheten

   OUTPUT FILE er den absolutte banen til filen der utdata fra kommandoen må lagres. Denne filen kan ligge i /tmp hvis den har nok plass eller et annet VMFS-volum enn det som migreres.

   Som i:

    

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

   Utdataene skal se omtrent slik ut:

   [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

   Merk: Hvis kommandoen får følgende feil, demonteres ikke VMFS på riktig måte:

    

VOMA Kan ikke sjekke enheten: Enhet eller ressurs opptatt

2. Analyser utdatafilen for å se om det er noen metadatainkonsekvenser rapportert av voma. Hvis det er noen, må de løses ved å kjøre voma i avansert fikseringsmodus før du fortsetter. Følgende er et eksempel:

[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. Samle inn og lagre VMFS-metadatadump. Dette vil være nødvendig hvis det oppdages uoverensstemmelser i metadata i påfølgende trinn. 

Se https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.html hvis du vil ha mer informasjon om bruk av voma I CHECK, Advanced Fix Mode eller Dump Mode.

Koble SCSI LUN fra ESXi-verter

Koble SCSI LUN fra hver ESXi-vert i VC. Se KB-artikkelen https://kb.vmware.com/s/article/2004605 for detaljerte trinn.

 

Slutte å presentere SCSI LUN fra matrise.

Fremgangsmåten for å oppheve presentasjon av SCSI LUN er spesifikk for lagringsarrayet. Kunder bør sjekke med den matrisespesifikke dokumentasjonen om prosedyren.

 

Presenter enheten som NVMe for én ESXi-vert.

Fremgangsmåten for å presentere enheten på nytt ved hjelp av NVMe er lagringsarrayspesifikk. Kunder bør sjekke med den matrisespesifikke dokumentasjonen om prosedyren. 

Start ny skanning av enheten på verten.

Når enheten presenteres for ESXi-verten ved hjelp av NVMe, oppdager vi vanligvis umiddelbart. Hvis enheten imidlertid ikke vises, må du skanne én eller flere adaptere på nytt ved hjelp av vSphere-brukergrensesnittet eller CLI:
 

esxcli storage core adapter rescan -a

 

Kontroller VMFS-volummetadatakonsistens etter konvertering.

På ESXi-verten som har tilgang til enheten, kjører du igjen voma i kontrollmodus for å bekrefte at VMFS-metadataene på disken fortsatt er konsistente. Eventuelle uoverensstemmelser i metadata må undersøkes før du fortsetter. 
Voma bruker SCSI-2-reservekommandoen til å låse enheten for å forhindre samtidig tilgang eller endring av VMFS-volumet når voma-økten er aktiv. NVMe-enheter støtter imidlertid ikke en tilsvarende SCSI-2-reservasjon. For å kunne omgå dette må brukeren passere "-N" mulighet til å VOMA når backend-enheten er NVMe. Eksempel:

• Kjør VOMA (VMware On-Disk Metadata Analyzer) i kontrollmodus ved å kjøre:

 

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

Når voma påberopes med "-N" alternativet følgende advarsel vises. 

 

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

Velg et tall fra 0-1:
Dette er for å varsle om at det er brukerens ansvar å forhindre at volumet blir montert eller tilgjengelig samtidig fra andre verter mens den nåværende voma-økten pågår. Hvis trinnene som er beskrevet her, er fulgt, og enheten er kartlagt og oppdaget på bare én ESXi-vert, bør det være trygt å fortsette. Brukeren må skrive inn "0" i ledeteksten for å fortsette med voma-kontrollmodus. Et eksempel følger:
 

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

Kjører VMFS Checker versjon 2.1 i avmerkingsmodus
Initialisere LVM-metadata, grunnleggende kontroller utføres
Kontrollerer for filsystemaktivitet
Reservasjonsstøtte finnes ikke for NVMe-enheter ST-aktivitet (4096 byte/HB, 1024 HB).                                 \
Utføre livlighetskontroll av 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

Velg et tall fra 0-1:

0 Fase 1: Kontrollerer VMFS-hode- og ressursfiler
Oppdaget VMFS-6-filsystem (merket:'Temp_Datastore') med UUID:64359f88-dd0fd27e-af5a-34800d0ed39c, Version 6:82
Fase 2: Kontrollere VMFS-hjerteslagområde
fase 3: Kontrollerer alle filbeskrivelser.
Fase 4: Kontrollerer banenavn og tilkobling.
Fase 5: Kontrollere antall ressursreferanser.
Totalt antall feil funnet:           0

Signer VMFS-volumet på nytt 

Nå som enheten presenteres som NVMe, er det nødvendig å oppdatere signaturen som er på datalageret. Dette skyldes at den gjeldende signaturen delvis er basert på enhetens WWN når den presenteres ved hjelp av SCSI. Siden NVMe-enhets-ID-en er annerledes, må det genereres en ny signatur. Kjør derfor følgende på samme ESXi-vert som ble brukt i de to foregående trinnene, for å signere volumet på nytt:

1. Selv om det er overflødig, må du skanne filsystemet på nytt ved å kjøre kommandoen:

 

esxcli storage filesystem rescan

2. Deretter kjører du følgende kommando for å få en liste over LUN-er for øyeblikksbilder av VMFS:

 

esxcli storage vmfs snapshot list

Den nylig presenterte NVMe-enheten skal være til stede, men avhengig av miljøet kan det være andre øyeblikksbilder som ikke er relatert til denne prosessen.

3. Signatur VMFS-volumet på nytt ved å kjøre følgende:

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

Et eksempel er nedenfor:
 

[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

 

Gi nytt navn til VMFS-datalageret (valgfritt)

Når et VMFS-volum signeres på nytt, innledes VMFS-volumetiketten med taggen «snap» etterfulgt av en alfanumerisk streng. For eksempel er VMFS-datalageret i forrige trinn nå navngitt: snap-5c42a2bc-Temp_Datastore Hvis du vil, kan du endre navn på datalageret tilbake til det opprinnelige navnet, og fjerne prefikset.

Kontroller konsekvens av VMFS-volummetadata etter ny signatur.

Igjen må du bekrefte at VMFS-metadataene på disken er konsekvente etter ny signatur. Kjør voma i kontrollmodus på VMFS-volumet. Se pkt. 2.8 for voma-kommandolinjen som må inneholde "-N"-flagget. Bekreft om voma rapporterer eventuelle uoverensstemmelser. Fortsett hvis voma ikke rapporterer noen feil. 

Presenter enheten som NVMe for alle ESXi-verter i klyngen.

Hvis det ikke oppstod noen problemer i noen av de foregående trinnene, kan enheten nå presenteres ved hjelp av NVMe til alle ESXi-vertene i klyngen. Som nevnt gjenkjennes NVMe-enheter umiddelbart, men hvis ikke skanner du adapterne på nytt via vSphere-brukergrensesnittet eller CLI. Kontroller at VMFS6-volumet er montert og tilgjengelig på alle verter.

Registrer deg, og slå på alle virtuelle maskiner

Registrer alle VM-er som ligger på datalageret, og slå dem på. Kontroller at VM-ene slår seg på, og at de har tilgang til vmdk-ene. Anbefalt praksis er at brukeren registrerer og slår på virtuelle maskiner på én enkelt ESXi. Når det var vellykket, kunne de overføres til andre verter.

Notat: Når du slår på virtuelle maskiner fra vCenter-brukergrensesnittet, kan det hende at det finnes et popup-vindu som det som vises nedenfor. Dette ber brukeren om å registrere om VM-en ble kopiert eller flyttet. Velg "I Copied it" i popup-vinduet.

 

 

---

 

Etter migrering

Kontroller om nøkkelfunksjonene påvirkes, og utfør eventuell opprydding om nødvendig. 

1.4 Kontroller både antall enheter og baner til hver ESXi-vert 3
1.5 Se etter funksjoner som ikke støttes 4
1.6 Se etter potensiell innvirkning etter migrering på støttede funksjoner 4
2.  Migrering 4
2.2 Demonter VMFS-volum fra alle verter 5
2.3 Kontroller konsekvens av VMFS-volummetadata.
5 2.9 Undersignatur VMFS-volumet på nytt 10
2.10 Gi nytt navn til VMFS-datalageret (valgfritt) 11
2.11 Kontroller konsekvens av VMFS-volummetadata etter ny signatur. 11
2.12 Presenter enheten som NVMe for alle ESXi-verter i klyngen 11
2.13 Registrer og slå på alle VM-er 11
3. Etter overføringen. 12

Oversikt

Etter hvert som implementeringen av NVMe vokser, ser flere kunder på migrering av data fra SCSI til NVMe. Dette dokumentet beskriver en av de effektive, om enn forstyrrende, metodene for å migrere SCSI til NVMe, kjent som frakoblet migrering. Frakoblet migrering av VMFS-datalager fra SCSI til NVMe involverer ikke flytting av data. Enheten som tidligere ble presentert for en ESXi-vert eller -klynge som en SCSI-enhet, blir ikke presentert og deretter presentert på nytt som en NVMe-enhet. VMFS-datalageret signeres deretter på nytt og gjøres tilgjengelig for vertene, og beholder VM-innholdet. Nedenfor beskrives detaljer om trinnene for frakoblet overføring.

Omfang

• Trinnene for frakoblet migrering, som beskrives i de påfølgende delene, gjelder bare for VMFS6-datalagre.
• Trinn dekker funksjonelle aspekter ved overføringen og dekker ikke ytelsesegenskaper for arbeidsbelastninger som er etter overføringen.
• Validering av skala (antall samtidige migreringer osv.) eller grenser (maksimale baner per enhet, maksimalt antall VMDK-er per VM osv.) er ikke inkludert.
• Begrepene enhet, volum og LUN brukes om hverandre i dokumentet.
• Frakoblet migrering krever at alle virtuelle maskiner i VMFS-datalageret slås av før start.  

Trinn for frakoblet overføring

Frakoblet migrering av et VMFS6-datalager fra SCSI til NVMe består av tre faser. Hver fase kan omfatte flere kontroller eller trinn.

Før migreringen

Denne forberedende fasen inkluderer kontroller for å forstå egenskapene til miljøet og funksjonene som er i bruk. Denne fasen er nødvendig for å avgjøre om frakoblet migrering er mulig i miljøet, og også for å forstå virkningen etter overføringen. Noen av de viktige kontrollene er oppført nedenfor. Dette er ikke en uttømmende liste, men dekker de vanligste kontrollene i et standard kundemiljø.

Kontroller låsemodus for VMFS-volum.

Kontroller først at LUN-en støtter ATS-modus. Overføring bør bare forsøkes hvis VMFS6-datalageret bruker låsemodus bare ATS, og ikke bruker SCSI-2-reservasjoner. 

For å bestemme låsemodus for et gitt volum, kjør kommandoen esxcli storage vmfs lockmode list -l <volume name/label> på en ESXi-vert med tilgang til datalageret. Frakoblet overføring støttes bare hvis låsemodusen for VMFS6-volumet er "ATS". Modusen "ATS+SCSI" støttes ikke.

Et eksempel på et volum som støtter frakoblet migrering:

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 Sjekk om noen vmdk av alle virtuelle maskiner i det valgte datalageret brukes som RDM (fysisk eller virtuell)

Hvis en virtuell maskin i det valgte datalageret har en RDM i SCSI-modus, kan det ikke tillates å migrere til NVMe. Det finnes ingen VMware-kommando for å finne ut om en virtuell maskin har en RDM, men Dell VSI-plugin-modulen viser disktypen for hver virtuelle maskin. Nedenfor finner du et skjermbilde av visningen i VSI, som viser om noen VM-er (kjøretidsnavn) har en RDM.

 

Hvis en virtuell maskin har en RDM, må enten RDM-en fjernes fra den virtuelle maskinen, konverteres, eller VM-en flyttes til et annet datalager før migreringen.

1.3 Sjekk claim rules/settings tilordning til enheten som er vert for VMFS-datalageret.

Hvis det finnes egendefinerte kravregler på SCSI-enheten før migrering, blir de sannsynligvis ikke brukt på enheten når de presenteres ved hjelp av NVMe. NVMe-enheter vises ikke med separate leverandør- og modellfelt når de åpnes via forespørsel. Feltene er samlet, og dermed er det nødvendig med en ny kravregel hvis ønskelig. I tillegg vil kravregler basert på enhetsidentifikatorer, f.eks. World Wide Name (WWN), mislykkes siden SCSI-identifikatoren og NVMe-identifikatoren er distinkte.
Som standard hevder VMware nylig presenterte NVMe-enheter med standard pathing-plugin for HPP.

1.4 Kontroller både antall enheter og baner til hver ESXi-vert.

NVMe støtter færre enheter og baner enn SCSI til hver ESXi-vert. Hvis antallet SCSI-enheter overskrider NVMe-grensene, vil det ikke være mulig å konvertere alle datalagre på samme ESXi-vert. Som en løsning kan kundene ansette flere ESXi-verter eller konsolidere datalagre enten før eller etter konvertering ved hjelp av Storage vMotion. 

1. SCSI – 1024 enheter/4096 baner
2. NVMe – 256 enheter/2048 baner

1.5 Se etter funksjoner som ikke støttes. 

Noen VMware-funksjoner støttes for øyeblikket ikke med NVMe. Kontroller om det kan støttes før migrering.
Følgende funksjoner støttes for eksempel for øyeblikket ikke på NVMe som kjører på ESXi (til og med versjon 8.0U1). 
 

Funksjon	Kort beskrivelse	Kommentarer
Gjesteklynger	VMDK-funksjon for klynger som støtter løsninger med høy tilgjengelighet, for eksempel Windows Server Failover Cluster (WSFC)	Et VMFS-datalager med VMDK i klynge aktivert kan ikke overføres.
SRM	Arraybasert replikering med SRM støttes ikke på NVMe.	Overføring av datalagre som er involvert i SRM-arrayreplikering, gjør løsningen ubrukelig.

Merk: Listen ovenfor er ikke uttømmende. Kunder bør sjekke med array-spesifikk dokumentasjon angående virkningen av overføringen på de kritiske funksjonene. 

 

Kontroller om det kan påvirke funksjoner som er lagt inn etter overføringen.

Mangelen på integrering av følgende funksjoner kan endre hvordan enkelte operasjoner utføres på NVMe sammenlignet med SCSI.
 

Funksjon	Påvirkningens natur	Handlingen som skal utføres
Maskinvareakselerert flytting – XCOPY	Det finnes for øyeblikket ingen tilsvarende kommando til XCOPY. VMware I stedet brukes programvaredataflytteren. Dette kan redusere ytelsen til operasjoner som normalt bruker det primitive, for eksempel kloning eller SvMotion.	None
Skriv samme / UNMAP	Hvis en NVMe-enhet ikke støtter NVMe-ekvivalenten for skrivenuller eller unmap, kan det ha innvirkning på ytelsen.	None

Migrering

Denne fasen omfatter trinnene for å overføre datalageret fra SCSI til NVMe.

Slå av alle virtuelle maskiner, og avregistrer deg

Slå av, og avregistrer alle VM-er på datalageret som skal migreres. Pass på at du ikke sletter dem, bare avregistrerer.

Demonter VMFS-volum fra alle verter

Demonter VMFS-volumet fra alle ESXi-verter når alle VM-er er avregistrert. Dette er for å sikre at den ikke er i bruk når konsistenskontrollen og migreringen utføres. 

Kontroller konsistens i VMFS-volummetadata.

Før du starter migreringen, må du kontrollere konsekvensen til VMFS-metadata på disken. Dette sikrer at det ikke er noen uoverensstemmelser før begynnelsen.

1. Kjør VOMA (VMware On-Disk Metadata Analyzer) i kontrollmodus ved å kjøre:

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

Where:
DEVICE er SCSI-enheten som er vert for VMFS6-volumet som migreres.
PARTITION er partisjonsnummeret som VMFS-volumet er formatert på enheten på.
OUTPUT FILE er den absolutte banen til filen der utdata fra kommandoen må lagres. Denne filen kan ligge i /tmp hvis den har nok plass eller et annet VMFS-volum enn det som migreres.

Eksempel:

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

Utdataene skal se omtrent slik ut:
 

[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

Merk: Hvis kommandoen får følgende feil, er ikke VMFS demontert riktig:

VOMA kunne ikke sjekke enheten: Enhet eller ressurs opptatt

2. Analyser utdatafilen for å se om det er noen metadatainkonsekvenser rapportert av voma. Hvis det er noen, må de løses ved å kjøre voma i avansert fikseringsmodus før du fortsetter. Følgende er et eksempel:

[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. Samle inn og lagre VMFS-metadatadump. Dette vil være nødvendig hvis det oppdages uoverensstemmelser i metadata i påfølgende trinn. 

Se https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.html hvis du vil ha mer informasjon om bruk av voma I CHECK, Advanced Fix Mode eller Dump Mode.

Koble SCSI LUN fra ESXi-verter

Koble SCSI LUN fra hver ESXi-vert i VC. Se KB-artikkelen https://kb.vmware.com/s/article/2004605 for detaljerte trinn.

Slutte å presentere SCSI LUN fra matrise.

Fremgangsmåten for å oppheve presentasjon av SCSI LUN er spesifikk for lagringsarrayet. Kunder bør sjekke med den matrisespesifikke dokumentasjonen om prosedyren.

Presenter enheten som NVMe for én ESXi-vert.

Fremgangsmåten for å presentere enheten på nytt ved hjelp av NVMe er lagringsarrayspesifikk. Kunder bør sjekke med den matrisespesifikke dokumentasjonen om prosedyren. 

Start ny skanning av enheten på verten.

Når enheten presenteres for ESXi-verten ved hjelp av NVMe, oppdager vi vanligvis umiddelbart. Hvis enheten imidlertid ikke vises, må du skanne én eller flere adaptere på nytt ved hjelp av vSphere-brukergrensesnittet eller CLI:
 

esxcli storage core adapter rescan -a

Kontroller VMFS-volummetadatakonsistens etter konvertering.

På ESXi-verten som har tilgang til enheten, kjører du igjen voma i kontrollmodus for å bekrefte at VMFS-metadataene på disken fortsatt er konsistente. Eventuelle uoverensstemmelser i metadata må undersøkes før du fortsetter. 
Voma bruker SCSI-2-reservekommandoen til å låse enheten for å forhindre samtidig tilgang eller endring av VMFS-volumet når voma-økten er aktiv. NVMe-enheter støtter imidlertid ikke en tilsvarende SCSI-2-reservasjon. For å kunne omgå dette må brukeren passere "-N" mulighet til å VOMA når backend-enheten er NVMe. Eksempel:

• Kjør VOMA (VMware On-Disk Metadata Analyzer) i kontrollmodus ved å kjøre:

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

Velg et tall fra 0-1:
Dette er for å varsle om at det er brukerens ansvar å forhindre at volumet blir montert eller tilgjengelig samtidig fra andre verter mens den nåværende voma-økten pågår. Hvis trinnene som er beskrevet her, er fulgt, og enheten er kartlagt og oppdaget på bare én ESXi-vert, bør det være trygt å fortsette. Brukeren må skrive inn "0" i ledeteksten for å fortsette med voma-kontrollmodus. Et eksempel følger:
 

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

Kjører VMFS Checker versjon 2.1 i avmerkingsmodus
Initialisere LVM-metadata, grunnleggende kontroller utføres
Kontrollerer for filsystemaktivitet
Reservasjonsstøtte finnes ikke for NVMe-enheter ST-aktivitet (4096 byte/HB, 1024 HB).                                 \

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

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

0) _Yes
1) _No

Select a number from 0-1: 0

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

 

Signer VMFS-volumet på nytt 

Nå som enheten presenteres som NVMe, er det nødvendig å oppdatere signaturen som er på datalageret. Dette skyldes at den gjeldende signaturen delvis er basert på enhetens WWN når den presenteres ved hjelp av SCSI. Siden NVMe-enhets-ID-en er annerledes, må det genereres en ny signatur. Kjør derfor følgende på samme ESXi-vert som ble brukt i de to foregående trinnene, for å signere volumet på nytt:

1. Selv om det er overflødig, må du skanne filsystemet på nytt ved å kjøre kommandoen:

Skanning av ESXCLI-lagringsfilsystem

2. Deretter kjører du følgende kommando for å få en liste over LUN-er for øyeblikksbilder av VMFS:

ESXCLI VMFS-øyeblikksbildeliste

for lagring Den nylig presenterte NVMe-enheten skal være til stede, men avhengig av miljøet kan det være andre øyeblikksbilder som ikke er relatert til denne prosessen.

3. Signatur VMFS-volumet på nytt ved å kjøre følgende:

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

 

Et eksempel er nedenfor:

[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

Gi nytt navn til VMFS-datalageret (valgfritt)

Når et VMFS-volum signeres på nytt, innledes VMFS-volumetiketten med taggen «snap» etterfulgt av en alfanumerisk streng. For eksempel er VMFS-datalageret i forrige trinn nå navngitt: snap-5c42a2bc-Temp_Datastore. Hvis du vil, kan du endre navn på datalageret tilbake til det opprinnelige navnet, og fjerne prefikset.

Kontroller konsekvens av VMFS-volummetadata etter ny signatur.

Igjen må du bekrefte at VMFS-metadataene på disken er konsekvente etter ny signatur. Kjør voma i kontrollmodus på VMFS-volumet. Se pkt. 2.8 for voma-kommandolinjen som må inneholde "-N"-flagget. Bekreft om voma rapporterer eventuelle uoverensstemmelser. Fortsett hvis voma ikke rapporterer noen feil. 

Presenter enheten som NVMe for alle ESXi-verter i klyngen.

Hvis det ikke oppstod noen problemer i noen av de foregående trinnene, kan enheten nå presenteres ved hjelp av NVMe til alle ESXi-vertene i klyngen. Som nevnt gjenkjennes NVMe-enheter umiddelbart, men hvis ikke skanner du adapterne på nytt via vSphere-brukergrensesnittet eller CLI. Kontroller at VMFS6-volumet er montert og tilgjengelig på alle verter.

Registrer deg, og slå på alle virtuelle maskiner

Registrer alle VM-er som ligger på datalageret, og slå dem på. Kontroller at VM-ene slår seg på, og at de har tilgang til vmdk-ene. Anbefalt praksis er at brukeren registrerer og slår på virtuelle maskiner på én enkelt ESXi. Når det var vellykket, kunne de overføres til andre verter.

Notat: Når du slår på virtuelle maskiner fra vCenter-brukergrensesnittet, kan det hende at det finnes et popup-vindu som det som vises nedenfor. Dette ber brukeren om å registrere om VM-en ble kopiert eller flyttet. Velg "I Copied it" i popup-vinduet.

 

Etter migrering

Kontroller om nøkkelfunksjonene påvirkes, og utfør eventuell opprydding om nødvendig. 

 

Dette er en offisielt kontrollert prosess av VMware for frakoblet datalagermigrering. Migrering online av individuelle VM-er kan utføres ved hjelp av Storage vMotion. VMware har ikke en separat KB for denne prosessen.

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