Trin til offlinemigrering af SCSI til NVMe VMware VMFS Datastore

概要: Dette dokument beskriver, hvordan du udfører en offlinemigrering fra et VMware vSphere SCSI-datalager til et NVMeoF-datalager. Migrering af offline-VMFS-datalager fra SCSI til NVMe involverer ikke flytning af data, men kræver nedetid for de involverede VM'er. Detaljer om trinnene til offlinemigrering er beskrevet nedenfor. Denne KB gælder for alle Dell-storagesystemer, der understøtter SCSI- og NVMeoF-protokoller. Dette omfatter, men er ikke begrænset til, PowerFlex, PowerMax og PowerStore. VMware og Dell samarbejdede om denne KB. ...

この記事は次に適用されます： この記事は次には適用されません： この記事は、特定の製品に関連付けられていません。 すべての製品パージョンがこの記事に記載されているわけではありません。
他のリソースを確認する

手順

Trin til migrering af SCSI til NVMe offline VMFS-datalager

Indholdsfortegnelse

  • Migrering af SCSI til NVMe offline VMFS-datalager, trin 1
  • Oversigt
  • Omfanget
  1. Trin til offlinemigrering
    1.  Før migrering
    2. Kontrollér både antallet af enheder og stierne til hver ESXi-vært 3 
    3. Kontrollér, om der ikke er understøttede funktioner 4 
    4. Kontrollér, om eftervandringen potentielt kan påvirke understøttede funktioner 4 
  2. Migrering
    1. Afmonter VMFS-diskenheden fra alle værter 5 
    2. Kontrollér konsistensen af VMFS-diskenhedsmetadata. 5 
    3. Gensigner VMFS-diskenheden 10 
    4. Omdøb VMFS-datalageret (valgfrit) 11 
    5. Kontroller konsistensen af VMFS-diskenhedsmetadata efter gensignatur. 11 
    6. Præsenter enheden som NVMe for alle ESXi-værter i klyngen 11 
    7. Registrer og tænd for alle VM er 11 
  3. Efter migrering. 12 

 

 

Oversigt

Stigende indførelse af NVMe sætter flere kunder fokus på migrering af data fra SCSI til NVMe. Dette dokument beskriver en af de effektive, omend forstyrrende, metoder til migrering af SCSI til NVMe, der kaldes offlinemigrering. Offline VMFS-datalagermigrering fra SCSI til NVMe indebærer ikke flytning af data. Den enhed, der tidligere blev præsenteret for en ESXi-vært eller -klynge som en SCSI-enhed, vises ikke og præsenteres derefter igen som en NVMe-enhed. VMFS-datalageret signeres derefter igen og gøres tilgængeligt for værterne og bevarer dets VM-indhold. Detaljer om trinnene til offlinemigrering er beskrevet nedenfor.

Omfanget

  • Trinnene til offlineoverførsel, som er beskrevet i de efterfølgende afsnit, gælder kun for VMFS6-datalagre.
  • Trinnene dækker funktionelle aspekter af migreringen og dækker ikke ydeevnekarakteristika for arbejdsbelastninger efter migreringen.
  • Valideringen af skalering (antal samtidige migreringer osv.) eller grænser (maksimalt antal stier pr. enhed, maksimalt VMDK'er pr. VM osv.) er ikke omfattet.
  • Udtrykkene enhed, volumen og LUN bruges i flæng i dokumentet.
  • Offlineoverførsel kræver, at alle VM'er i VMFS-datalageret slukkes, før de startes.  

 

 

  1. Trin til offlinemigrering

    Offlinemigrering af et VMFS6-datalager fra SCSI til NVMe består af tre faser. Hver fase kan omfatte flere kontroller eller trin.

    1. Før migrering

      Denne forberedende fase omfatter kontrol for at forstå miljøets egenskaber og de funktioner, der er i brug. Denne fase er nødvendig for at afgøre, om offlinemigrering er mulig i miljøet, og også for at forstå virkningen efter migrering. Nogle af de vigtige kontroller er angivet nedenfor. Dette er ikke en udtømmende liste, men dækker snarere de mest almindelige kontroller i et standardkundemiljø.

    2. Se efter låsetilstand for VMFS-diskenheden

      Først skal du sikre dig, at LUN'en understøtter ATS-tilstand. Migrering bør kun forsøges, hvis VMFS6-datalageret kun bruger ATS-låsetilstand og ikke bruger SCSI-2-reservationer. 

      For at bestemme låsetilstanden for en given diskenhed skal du køre kommandoen esxcli storage vmfs lockmode list -l <volume name/label> på en ESXi-vært med adgang til datalageret. Offlineoverførsel understøttes kun, hvis låsetilstanden for VMFS6-diskenheden er "ATS". Tilstanden "ATS+SCSI" understøttes ikke.

      Et eksempel på en diskenhed, der understøtter offlineoverførsel:

       
      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. 
     
    3. 
      
      Kontroller, om nogen vmdk af enhver VM i det valgte datalager bruges som en RDM (fysisk eller virtuel)
      
      
      Hvis en VM i det valgte datalager har en RDM i SCSI-tilstand, kan den ikke få tilladelse til at migrere til NVMe. Der er ingen VMware-kommando, der gør det muligt at finde ud af, om en VM har en RDM, men Dell VSI-pluginet angiver disktypen for hver VM. Nedenfor finder du et skærmbillede af visningen i VSI, som viser, om nogen VM er (Runtime Name) har en RDM.

      Dell-systemenheder i vSphere 
      
        
      
      
      Hvis en VM har en RDM, skal RDM enten fjernes fra VM'en, konverteres, eller VM'en flyttes til et andet datalager før overførslen.
      4. 
     
    4. 
      
      1.3 Tjek kravregler/indstillinger knyttet til den enhed, der hoster VMFS-datalager
      
      
      Hvis der er nogen brugerdefinerede kravregler på SCSI-enheden før migrering, vil de sandsynligvis ikke blive anvendt på enheden, når de præsenteres ved hjælp af NVMe. NVMe-enheder får ikke separate leverandør- og modelfelter, når de tilgås via forespørgsel. Markerne er samlet, og derfor er det nødvendigt med en ny kravregel, hvis det ønskes. Derudover vil kravregler baseret på enhedsidentifikatorer, f.eks. WWN (World Wide Name), mislykkes, da SCSI-identifikatoren og NVMe-identifikatoren er forskellige.
      
       Som standard vil VMware gøre krav på nyligt præsenterede NVMe-enheder med standardsti-pluginet HPP.
      5. 
     
    5. 
      
      Kontrollér både antallet af enheder og stierne til hver ESXi-vært
      
      
      NVMe understøtter færre enheder og stier end SCSI til hver ESXi-vært. Hvis antallet af SCSI-enheder overstiger NVMe-grænserne, er det ikke muligt at konvertere alle datalagre på den samme ESXi-vært. Som en løsning kan kunder ansætte flere ESXi-værter eller konsolidere datalagre enten før eller efter konvertering ved hjælp af Storage vMotion. 
      
      
        
       
      1. SCSI – 1024 enheder/4096 stier
        2. 
       
      2. NVMe – 256 enheder/2048 stier
        3. 
      
      6. 
     
    6. 
      
      Kontroller, om der ikke er understøttede funktioner 
      
      
      Nogle VMware-funktioner understøttes i øjeblikket ikke med NVMe. Kontrollér, om der er supportabilitet før migrering.
      
      
      F.eks. understøttes følgende funktioner i øjeblikket ikke på NVMe, der kører på ESXi (til og med version 8.0U1).
         
      
      
       
        
      
         Funktion 
         Kort beskrivelse
         Bemærkninger
        
      
        
      
         Gæsteklynger
         VMDK-klyngefunktion, der understøtter løsninger med høj tilgængelighed, f.eks. Windows Server Failover Cluster (WSFC) 
         Et VMFS-datalager med klynger VMDK Aktiveret kan ikke migreres.
        
      
        
      
         SRM
         Array-baseret replikering med SRM understøttes ikke på NVMe.
         Migrering af datalagre, der er involveret i SRM-systemreplikering, gør løsningen ubrugelig.
        
      
             
      
         
      
      
       Bemærk: Ovenstående liste er ikke udtømmende. Kunderne bør kontakte den systemspecifikke dokumentation vedrørende migreringens indvirkning på de kritiske funktioner.
      
      7. 
     
    7. 
      
      Kontrollér, om eftermigreringen kan have en potentiel indvirkning på understøttede funktioner
      
      
      Den manglende integration af følgende funktioner kan ændre, hvordan visse handlinger fungerer på NVMe sammenlignet med SCSI.
      
      
      
       
        
      
         Funktion
         Påvirkningens art
         Hvad der skal gøres
        
      
        
      
         Hardwareaccelereret flytning – XCOPY
         Der er i øjeblikket ingen tilsvarende kommando til XCOPY. VMware software data mover bruges i stedet. Dette kan nedsætte ydeevnen for handlinger, der bruger det primitive, såsom kloning eller SvMotion.
         Ingen
        
      
        
      
         Skriv samme/fjern tilknytning
         Hvis en NVMe-enhed ikke understøtter NVMe-ækvivalenten til skrivenuller, eller unmap, kan der være en indvirkning på ydeevnen.
         Ingen
        
      
             
      
      8. 
    
    2. 
  

  
 

  

  
 

  
    
   
  1. 
    
    Migrering
    
    
    Denne fase omfatter trinnene til migrering af datalageret fra SCSI til NVMe.
    2. 
   
  2. 
    
    Luk alle VM er, og fjern registreringen
    
    
    Luk og fjern registreringen af alle VM'er, der hostes på datalageret, og som skal migreres. Sørg for ikke at slette dem, kun afregistrere.
    3. 
   
  3. 
    
    Afmonter VMFS-diskenheden fra alle værter
    
    
    Afmonter VMFS-diskenheden fra alle ESXi-værter, når alle VM er er afmeldt. Dette er for at sikre, at det ikke er i brug, når konsistenskontrollen og migreringen udføres
    4. 
   
  4. 
    
    Kontrollér konsistensen af VMFS-diskenhedsmetadata
    
    
    Før du starter migreringen, skal du kontrollere konsistensen af VMFS-metadata på disken. Dette sikrer, at der ikke er uoverensstemmelser, før du begynder.
    
    
      
     
    1. Kør VOMA (VMware On-Disk Metadata Analyzer) i kontroltilstand ved at køre:
      2. 
    
    
    
    voma -m vmfs -f check -d /vmfs/devices/disks/<DEVICE>:<PARTITION> -s <OUTPUT FILE>
       
    
    Hvor:
    
    
    DEVICE er den SCSI-enhed, der er vært for den VMFS6-diskenhed, der overføres
    
    
    PARTITION er det partitionsnummer, som VMFS-diskenheden formateres på enheden
    
    
    OUTPUT FILE er den absolutte sti til den fil, hvor output af kommandoen skal gemmes. Denne fil kan findes i /tmp hvis den har tilstrækkelig plads eller en anden VMFS-diskenhed end den, der migreres.
    
    
    Som i:
       
    
    voma -m vmfs -f check -d naa.60000970000120200302533030313031:1 -s /tmp/voma.out
    
    
    Outputtet skal se nogenlunde ud som følger:
    
    
    [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
    
    
    
     Bemærk: Hvis kommandoen modtager følgende fejl, er VMFS ikke frakoblet korrekt: 
     
    
       
     
    
    
    5. 
  

  
VOMA Kunne ikke kontrollere enhed: Enhed eller ressource optaget

  
    
   
  1. Analysér outputfilen for at se, om der er rapporteret uoverensstemmelser i metadata af voma. Hvis der er nogen, skal de løses ved at køre voma i tilstanden Avanceret rettelse, før du fortsætter. Følgende er et eksempel:
    2. 
  

  
[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

  
 

  
    
   
  1. Indsaml og gem VMFS-metadatadump. Dette vil være påkrævet, hvis der ses uoverensstemmelser i metadata i efterfølgende trin. 
    2. 
  

  
Se https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.htmlDette hyperlink fører dig til et websted uden for Dell Technologies. for flere oplysninger om brug voma i Check, Advanced Fix-tilstand eller Dump-tilstand.

  
Afmonter SCSI LUN fra ESXi-værter

  
Afmonter SCSI LUN fra hver ESXi-vært i VC. Se KB-artiklen https://kb.vmware.com/s/article/2004605Dette hyperlink fører dig til et websted uden for Dell Technologies. for at få detaljerede trin.

  
 

  
Stop med at præsentere SCSI LUN fra systemet.

  
Trinnene til at fjerne præsentationen af SCSI LUN er specifikke for storagesystemet. Kunderne bør se den systemspecifikke dokumentation om proceduren.

  
 

  
Præsenter enheden som NVMe for én ESXi-vært.

  
Trinnene til at præsentere enheden igen ved hjælp af NVMe er storagesystemspecifikke. Kunderne bør se den systemspecifikke dokumentation om proceduren. 

  
Start scanning af enheden på værten igen.

  
Når enheden præsenteres for ESXi-værten ved hjælp af NVMe, sker registreringen typisk øjeblikkeligt. Hvis enheden imidlertid ikke vises, skal du scanne en eller flere adaptere igen ved hjælp af vSphere UI eller CLI:

    

  
esxcli storage core adapter rescan -a

  
 

  
Kontroller konsistensen af VMFS-volumenmetadata efter konvertering.

  
På ESXi-værten, der har adgang til enheden, skal du igen køre voma i kontroltilstand for at validere, at VMFS-metadataene på disken stadig er konsistente. Eventuelle uoverensstemmelser i metadata skal undersøges, før du fortsætter. 
Voma bruger SCSI-2-reservekommandoen til at låse enheden for at forhindre samtidig adgang til eller ændring af VMFS-diskenheden, når voma-sessionen er aktiv. NVMe-enheder understøtter dog ikke en ækvivalent til en SCSI-2-reservation. For at løse dette problem skal brugeren bestå "-N" mulighed for at VOMA når backend-enheden er NVMe. F.eks.:

  
    
   
  • Kør VOMA (VMware On-Disk Metadata Analyzer) i kontroltilstand ved at køre:
    • 
  

  
 

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

  



   Hvornår voma påberåbes med "-N" vises følgende advarselsmeddelelse. 

  
 

  
########################################################################
# 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ælg et tal fra 0-1:

    Dette er for at meddele, at det er brugerens ansvar at forhindre, at diskenheden bliver monteret eller tilgås samtidigt fra andre værter, mens den aktuelle voma-session er i gang. Hvis de trin, der er beskrevet her, er blevet fulgt, og enheden kun er blevet tilknyttet og fundet på én ESXi-vært, bør det være sikkert at fortsætte. Brugeren skal indtaste "0" ved prompten for at fortsætte med voma-kontroltilstand. Et eksempel følger:

    

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

  


   Kørsel af VMFS Checker version 2.1 i kontroltilstand

   Initialisering af LVM-metadata, grundlæggende kontroller udføres

   Kontrol af filsystemaktivitet

   Reservationsunderstøttelse er ikke til stede for NVMe-enheders første aktivitet (4096 byte/HB, 1024 HBs).                                 \

   Udførelse af kontrol af filsystemets liveness..|

  
########################################################################
#   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ælg et tal fra 0-1: 


   0 Fase 1: Kontrol af VMFS-header- og ressourcefiler

    Fundent VMFS-6-filsystem (mærket:'Temp_Datastore') med UUID:64359f88-dd0fd27e-af5a-34800d0ed39c, Version 6:82

   Fase 2: Kontrol af VMFS-hjerteslagsregion

   Fase 3: Kontrol af alle filbeskrivelser.

   Fase 4: Kontrol af stinavn og forbindelse.

   Fase 5: Kontrol af antallet af ressourcereferencer.

   Samlet antal fundne fejl:           0

  
Gensigner VMFS-diskenheden 

  
Nu, hvor enheden præsenteres som NVMe, er det nødvendigt at opdatere signaturen i datalageret. Dette skyldes, at den aktuelle signatur delvist er baseret på enhedens WWN, når den præsenteres ved hjælp af SCSI. Da NVMe-enheds-id et er anderledes, skal der genereres en ny signatur. På den samme ESXi-vært, som blev brugt i de to foregående trin, skal du derfor køre følgende for at signere diskenheden igen:

  
    
   
  1. Selvom det er overflødigt, skal du scanne filsystemet igen ved at køre kommandoen:
    2. 
  

  
 

  
esxcli storage filesystem rescan

  
    
   
  1. Kør derefter følgende kommando for at få vist en liste over VMFS-snapshot-LUN'er:
    2. 
  

  
 

  
esxcli storage vmfs snapshot list

  


   Den nyligt præsenterede NVMe-enhed skal være til stede, men afhængigt af miljøet kan der være andre snapshots, der ikke er relateret til denne proces.

  
    
   
  1. Gensigner VMFS-diskenheden ved at køre følgende:
    2. 
  

  
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

  
 

  
Omdøb VMFS-datalageret (valgfrit)

  
Når en VMFS-diskenhed signeres igen, indledes VMFS-diskenhedsetiketten med tagget "snap" efterfulgt af en alfanumerisk streng. F.eks. hedder VMFS-datalageret i forrige trin nu: snap-5c42a2bc-Temp_Datastore Hvis du ønsker det, skal du omdøbe datalageret tilbage til det oprindelige navn og fjerne præfikset.

  
Kontroller konsistensen af VMFS-diskenhedsmetadata efter gensignatur.

  
Bekræft igen, at VMFS-metadataene på disken er konsistente efter gensignatur. Kør voma i kontroltilstand på VMFS-diskenheden. Se afsnit 2.8 for voma-kommandolinjen, som skal indeholde flaget "-N". Kontroller, om voma rapporterer uoverensstemmelser. Fortsæt, hvis voma ikke rapporterer nogen fejl. 

  
Præsenter enheden som NVMe for alle ESXi-værter i klyngen.

  
Hvis der ikke var nogen problemer i nogen af de foregående trin, kan enheden nu præsenteres ved hjælp af NVMe for alle ESXi-værterne i klyngen. Som nævnt genkendes NVMe-enheder med det samme, men hvis ikke, skal du scanne adapterne igen via vSphere UI eller CLI. Kontroller, at VMFS6-diskenheden er monteret og tilgængelig på alle værter.

  
Registrer og tænd for alle VM er

  
Registrer alle VM'er, der hostes på datalageret, og tænd dem. Kontrollér, at VM erne tænder korrekt og kan få adgang til VM erne. Som bedste praksis kan brugeren registrere og tænde VM er på en enkelt ESXi. Når det lykkes, kan de migreres til andre værter.

Seddel: Når du tænder VM erne fra vCenter-brugergrænsefladen, vises der muligvis et pop op-vindue som det, der vises nedenfor. Dette beder brugeren om at registrere, om VM'en blev kopieret eller flyttet. Vælg "Jeg kopierede det" i pop op-vinduet.

Besvar spørgsmål om kloning af en VM. 

  
 

  

  
 

  
Efter migrering

  
Kontroller, om de påvirker nøglefunktionerne, og udfør eventuel oprydning, hvis det er nødvendigt. 

  
1.4 Kontroller både antallet af enheder og stierne til hver ESXi-vært 3

   1.5 Kontroller, om funktioner ikke understøttes 4

   1.6 Kontrollér for potentiel indvirkning efter migrering på understøttede funktioner 4

   2.  Migrering 4

   2.2 Afmonter VMFS-diskenhed fra alle værter 5

   2.3 Kontroller ensartetheden af VMFS-diskenhedens metadata. 

   5 2.9 Gensigner VMFS-diskenheden 10

   2.10 Omdøb VMFS-datalageret (valgfrit) 11

   2.11 Kontroller konsistensen af VMFS-diskenhedens metadata efter gensignatur. 11

   2.12 Præsenter enheden som NVMe på alle ESXi-værter i klyngen 11

   2.13 Registrer og tænd for alle VM er 11

   3. Efter migrering. 12

  
Oversigt

  
Stigende indførelse af NVMe sætter flere kunder fokus på migrering af data fra SCSI til NVMe. Dette dokument beskriver en af de effektive, omend forstyrrende, metoder til migrering af SCSI til NVMe, der kaldes offlinemigrering. Offline VMFS-datalagermigrering fra SCSI til NVMe indebærer ikke flytning af data. Den enhed, der tidligere blev præsenteret for en ESXi-vært eller -klynge som en SCSI-enhed, vises ikke og præsenteres derefter igen som en NVMe-enhed. VMFS-datalageret signeres derefter igen og gøres tilgængeligt for værterne og bevarer dets VM-indhold. Detaljer om trinnene til offlinemigrering er beskrevet nedenfor.

  
Omfanget

  
    
   
  • Trinnene til offlineoverførsel, som er beskrevet i de efterfølgende afsnit, gælder kun for VMFS6-datalagre.
    • 
   
  • Trinnene dækker funktionelle aspekter af migreringen og dækker ikke ydeevnekarakteristika for arbejdsbelastninger efter migreringen.
    • 
   
  • Valideringen af skalering (antal samtidige migreringer osv.) eller grænser (maksimalt antal stier pr. enhed, maksimalt VMDK'er pr. VM osv.) er ikke omfattet.
    • 
   
  • Udtrykkene enhed, volumen og LUN bruges i flæng i dokumentet.
    • 
   
  • Offlineoverførsel kræver, at alle VM er i VMFS-datalageret slukkes, før de startes.  
    • 
  

  
Trin til offlinemigrering

  
Offlinemigrering af et VMFS6-datalager fra SCSI til NVMe består af tre faser. Hver fase kan omfatte flere kontroller eller trin.

  
Før migrering

  
Denne forberedende fase omfatter kontrol for at forstå miljøets egenskaber og de funktioner, der er i brug. Denne fase er nødvendig for at afgøre, om offlinemigrering er mulig i miljøet, og også for at forstå virkningen efter migrering. Nogle af de vigtige kontroller er angivet nedenfor. Dette er ikke en udtømmende liste, men dækker snarere de mest almindelige kontroller i et standardkundemiljø.

  
Kontrollér for låsetilstand for VMFS-diskenheden.

  
Først skal du sikre dig, at LUN'en understøtter ATS-tilstand. Migrering bør kun forsøges, hvis VMFS6-datalageret kun bruger ATS-låsetilstand og ikke bruger SCSI-2-reservationer. 


   For at bestemme låsetilstanden for en given diskenhed skal du køre kommandoen esxcli storage vmfs lockmode list -l <volume name/label> på en ESXi-vært med adgang til datalageret. Offlineoverførsel understøttes kun, hvis låsetilstanden for VMFS6-diskenheden er "ATS". Tilstanden "ATS+SCSI" understøttes ikke.


   Et eksempel på en diskenhed, der understøtter offlineoverførsel:

  
 

  
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 Kontroller, om nogen vmdk af enhver VM i det valgte datalager bruges som en RDM (fysisk eller virtuel)

  
Hvis en VM i det valgte datalager har en RDM i SCSI-tilstand, kan den ikke få tilladelse til at migrere til NVMe. Der er ingen VMware-kommando, der gør det muligt at finde ud af, om en VM har en RDM, men Dell VSI-pluginet angiver disktypen for hver VM. Nedenfor er et skærmbillede af visningen i VSI, som viser, om nogen VM'er (Runtime Name) har en RDM.

Liste over VMFS og RDM er til migrering. 


   Hvis en VM har en RDM, skal RDM enten fjernes fra VM'en, konverteres, eller VM'en flyttes til et andet datalager før overførslen.

  
1.3 Tjek claim rules/settings tilknytning til den enhed, der er vært for VMFS-datalageret.

  
Hvis der er nogen brugerdefinerede kravregler på SCSI-enheden før migrering, vil de sandsynligvis ikke blive anvendt på enheden, når de præsenteres ved hjælp af NVMe. NVMe-enheder får ikke separate leverandør- og modelfelter, når de tilgås via forespørgsel. Markerne er samlet, og derfor er det nødvendigt med en ny kravregel, hvis det ønskes. Derudover vil kravregler baseret på enhedsidentifikatorer, f.eks. WWN (World Wide Name), mislykkes, da SCSI-identifikatoren og NVMe-identifikatoren er forskellige.

   Som standard hævder VMware nyligt præsenterede NVMe-enheder med standard pathing-plugin til HPP.

  
1.4 Kontroller både antallet af enheder og stierne til hver ESXi-vært.

  
NVMe understøtter færre enheder og stier end SCSI til hver ESXi-vært. Hvis antallet af SCSI-enheder overstiger NVMe-grænserne, er det ikke muligt at konvertere alle datalagre på den samme ESXi-vært. Som en løsning kan kunder ansætte flere ESXi-værter eller konsolidere datalagre enten før eller efter konvertering ved hjælp af Storage vMotion. 

  
    
   
  1. SCSI – 1024 enheder/4096 stier
    2. 
   
  2. NVMe – 256 enheder/2048 stier
    3. 
  

  
1.5 Kontroller, om funktioner ikke understøttes. 

  
Nogle VMware-funktioner understøttes i øjeblikket ikke med NVMe. Kontrollér, om der er supportabilitet før migrering.

   F.eks. understøttes følgende funktioner i øjeblikket ikke på NVMe, der kører på ESXi (til og med version 8.0U1). 

    

  

   
    

     Funktion 
     Kort beskrivelse
     Bemærkninger
    

    

     Gæsteklynger
     VMDK-klyngefunktion, der understøtter løsninger med høj tilgængelighed, f.eks. Windows Server Failover Cluster (WSFC) 
     Et VMFS-datalager med VMDK-klynger aktiveret kan ikke overføres.
    

    

     SRM
     Array-baseret replikering med SRM understøttes ikke på NVMe.
     Migrering af datalagre, der er involveret i SRM-systemreplikering, gør løsningen ubrugelig.
    

   
  

  

Bemærk: Ovenstående liste er ikke udtømmende. Kunderne bør kontakte den systemspecifikke dokumentation vedrørende migreringens indvirkning på de kritiske funktioner. 

  
 

  
Kontrollér, om eftermigreringen potentielt kan påvirke understøttede funktioner.

  
Den manglende integration af følgende funktioner kan ændre, hvordan visse handlinger fungerer på NVMe sammenlignet med SCSI.

    

  

   
    

     Funktion
     Påvirkningens art
     Hvad der skal gøres
    

    

     Hardwareaccelereret flytning – XCOPY
     Der er i øjeblikket ingen tilsvarende kommando til XCOPY. VMware Software Data Mover vil blive brugt i stedet. Dette kan nedsætte ydeevnen for operationer, der normalt bruger det primitive, såsom kloning eller SvMotion.
     Ingen
    

    

     Skriv samme/fjern tilknytning
     Hvis en NVMe-enhed ikke understøtter NVMe-ækvivalenten til skrivenuller, eller unmap, kan der være en indvirkning på ydeevnen.
     Ingen
    

   
  

  
Migrering

  
Denne fase omfatter trinnene til migrering af datalageret fra SCSI til NVMe.

  
Luk alle VM er, og fjern registreringen

  
Luk og fjern registreringen af alle VM'er, der hostes på datalageret, og som skal migreres. Sørg for ikke at slette dem, kun afregistrere.

  
Afmonter VMFS-diskenheden fra alle værter

  
Afmonter VMFS-diskenheden fra alle ESXi-værter, når alle VM er er afmeldt. Dette er for at sikre, at det ikke er i brug, når konsistenskontrollen og migreringen udføres. 

  
Kontrollér konsistensen af VMFS-diskenhedsmetadata.

  
Før du starter migreringen, skal du kontrollere konsistensen af VMFS-metadata på disken. Dette sikrer, at der ikke er uoverensstemmelser før begyndelsen.

  
    
   
  1. Kør VOMA (VMware On-Disk Metadata Analyzer) i kontroltilstand ved at køre:
    2. 
  

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

  


   Hvor:
DEVICE er den SCSI-enhed, der er vært for den VMFS6-diskenhed, der overføres.
PARTITION er det partitionsnummer, som VMFS-diskenheden formateres på enheden.
OUTPUT FILE er den absolutte sti til den fil, hvor output af kommandoen skal gemmes. Denne fil kan findes i /tmp hvis den har tilstrækkelig plads eller en anden VMFS-diskenhed end den, der migreres.

  
F.eks.:

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

  



   Outputtet skal se nogenlunde ud som følger:

    

  
[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

  

Bemærk: Hvis kommandoen modtager følgende fejl, er VMFS ikke frakoblet korrekt:

VOMA kunne ikke kontrollere enheden: Enhed eller ressource optaget

  
    
   
  1. Analysér outputfilen for at se, om der er rapporteret uoverensstemmelser i metadata af voma. Hvis der er nogen, skal de løses ved at køre voma i tilstanden Avanceret rettelse, før du fortsætter. Følgende er et eksempel:
    2. 
  

  
[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

  
 

  
    
   
  1. Indsaml og gem VMFS-metadatadump. Dette vil være påkrævet, hvis der ses uoverensstemmelser i metadata i efterfølgende trin. 
    2. 
  

  
Se https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.htmlDette hyperlink fører dig til et websted uden for Dell Technologies. for flere oplysninger om brug voma i Check, Advanced Fix-tilstand eller Dump-tilstand.

  
Afmonter SCSI LUN fra ESXi-værter

  
Afmonter SCSI LUN fra hver ESXi-vært i VC. Se KB-artiklen https://kb.vmware.com/s/article/2004605Dette hyperlink fører dig til et websted uden for Dell Technologies. for at få detaljerede trin.

  
Stop med at præsentere SCSI LUN fra systemet.

  
Trinnene til at fjerne præsentationen af SCSI LUN er specifikke for storagesystemet. Kunderne bør se den systemspecifikke dokumentation om proceduren.

  
Præsenter enheden som NVMe for én ESXi-vært.

  
Trinnene til at præsentere enheden igen ved hjælp af NVMe er storagesystemspecifikke. Kunderne bør se den systemspecifikke dokumentation om proceduren. 

  
Start scanning af enheden på værten igen.

  
Når enheden præsenteres for ESXi-værten ved hjælp af NVMe, sker registreringen typisk øjeblikkeligt. Hvis enheden imidlertid ikke vises, skal du scanne en eller flere adaptere igen ved hjælp af vSphere UI eller CLI:

    

  
esxcli storage core adapter rescan -a

  
Kontroller konsistensen af VMFS-volumenmetadata efter konvertering.

  
På ESXi-værten, der har adgang til enheden, skal du igen køre voma i kontroltilstand for at validere, at VMFS-metadataene på disken stadig er konsistente. Eventuelle uoverensstemmelser i metadata skal undersøges, før du fortsætter. 

   Voma bruger SCSI-2-reservekommandoen til at låse enheden for at forhindre samtidig adgang til eller ændring af VMFS-diskenheden, når voma-sessionen er aktiv. NVMe-enheder understøtter dog ikke en ækvivalent til en SCSI-2-reservation. For at løse dette problem skal brugeren bestå "-N" mulighed for at VOMA når backend-enheden er NVMe. F.eks.:

  
    
   
  • Kør VOMA (VMware On-Disk Metadata Analyzer) i kontroltilstand ved at kø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

  


   Vælg et tal fra 0-1:

    Dette er for at meddele, at det er brugerens ansvar at forhindre, at diskenheden bliver monteret eller tilgås samtidigt fra andre værter, mens den aktuelle voma-session er i gang. Hvis de trin, der er beskrevet her, er blevet fulgt, og enheden kun er blevet tilknyttet og fundet på én ESXi-vært, bør det være sikkert at fortsætte. Brugeren skal indtaste "0" ved prompten for at fortsætte med voma-kontroltilstand. Et eksempel følger:

    

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

  


   Kørsel af VMFS Checker version 2.1 i kontroltilstand

   Initialisering af LVM-metadata, grundlæggende kontroller udføres

   Kontrol af filsystemaktivitet

    Reservationsunderstøttelse er ikke til stede for NVMe-enheders første 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

  


    

  
Gensigner VMFS-diskenheden 

  
Nu, hvor enheden præsenteres som NVMe, er det nødvendigt at opdatere signaturen i datalageret. Dette skyldes, at den aktuelle signatur delvist er baseret på enhedens WWN, når den præsenteres ved hjælp af SCSI. Da NVMe-enheds-id et er anderledes, skal der genereres en ny signatur. På den samme ESXi-vært, som blev brugt i de to foregående trin, skal du derfor køre følgende for at signere diskenheden igen:

  
    
   
  1. Selvom det er overflødigt, skal du scanne filsystemet igen ved at køre kommandoen:
    2. 
  

  
ESXCLI Storage File System Scanning igen

  
    
   
  1. Kør derefter følgende kommando for at få vist en liste over VMFS-snapshot-LUN'er:
    2. 
  

  
Liste over ESXCLI Storage VMFS-snapshots


   Den nyligt præsenterede NVMe-enhed skal være til stede, men afhængigt af miljøet kan der være andre snapshots, der ikke er relateret til denne proces.

  
    
   
  1. Gensigner VMFS-diskenheden ved at køre følgende:
    2. 
  

  
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

  
Omdøb VMFS-datalageret (valgfrit)

  
Når en VMFS-diskenhed signeres igen, indledes VMFS-diskenhedsetiketten med tagget "snap" efterfulgt af en alfanumerisk streng. For eksempel hedder VMFS-datalageret i det forrige trin nu: snap-5c42a2bc-Temp_Datastore. Hvis du ønsker det, skal du omdøbe datalageret tilbage til det oprindelige navn og fjerne præfikset.

  
Kontroller konsistensen af VMFS-diskenhedsmetadata efter gensignatur.

  
Bekræft igen, at VMFS-metadataene på disken er konsistente efter gensignatur. Kør voma i kontroltilstand på VMFS-diskenheden. Se afsnit 2.8 for voma-kommandolinjen, som skal indeholde flaget "-N". Kontroller, om voma rapporterer uoverensstemmelser. Fortsæt, hvis voma ikke rapporterer nogen fejl. 

  
Præsenter enheden som NVMe for alle ESXi-værter i klyngen.

  
Hvis der ikke var nogen problemer i nogen af de foregående trin, kan enheden nu præsenteres ved hjælp af NVMe for alle ESXi-værterne i klyngen. Som nævnt genkendes NVMe-enheder med det samme, men hvis ikke, skal du scanne adapterne igen via vSphere UI eller CLI. Kontroller, at VMFS6-diskenheden er monteret og tilgængelig på alle værter.

  
Registrer og tænd for alle VM er

  
Registrer alle VM'er, der hostes på datalageret, og tænd dem. Kontrollér, at VM erne tænder korrekt og kan få adgang til VM erne. Som bedste praksis kan brugeren registrere og tænde VM er på en enkelt ESXi. Når det lykkes, kan de migreres til andre værter.

Seddel: Når du tænder VM erne fra vCenter-brugergrænsefladen, vises der muligvis et pop op-vindue som det, der vises nedenfor. Dette beder brugeren om at registrere, om VM'en blev kopieret eller flyttet. Vælg "Jeg kopierede det" i pop op-vinduet.

Besvarelse af spørgsmål under kloning. 

  
Efter migrering

  
Kontroller, om de påvirker nøglefunktionerne, og udfør eventuel oprydning, hvis det er nødvendigt. 


    

                
その他の情報

        
Dette er en officielt undersøgt proces af VMware til offline datastoremigrering. Onlinemigreringer af individuelle VM er kan udføres ved hjælp af Storage vMotion. VMware har ikke en separat KB til denne 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
                    
                    ...
                    
                
            
        








                        

                            

    

        

            

                
                    
 文書のプロパティ

                
            

            

                

                        
文書番号: 000213232

                

                
                

                        
文書の種類: How To

                

                

                        
最終更新: 14 3月 2025


                

                    

                            
バージョン:  2

                    


            


        

    

    

        

            

                
                    
質問に対する他のDellユーザーからの回答を見つける

                
            

            

                

                    
                



            


        

    

    

        

            

                
                    
サポート サービス

                
            

            

                

                    お使いのデバイスがサポート サービスの対象かどうかを確認してください。