Passaggi per la migrazione offline del datastore VMFS VMware da SCSI a NVMe VMware VMFS

Procedura di migrazione del datastore VMFS offline da SCSI a NVMe

Sommario

• Procedura 1 per la migrazione del datastore VMFS offline da SCSI a NVMe
• Panoramica
• Ambito

1. Passaggi per la migrazione offline
   1.  Prima della migrazione
   2. Controllare sia il numero di dispositivi che i percorsi su ciascun host ESXi 3 
   3. Verifica della presenza di funzionalità non supportate 4 
   4. Verifica del potenziale impatto della post-migrazione sulle funzionalità supportate 4 
2. Migrazione
   1. Smontare il volume VMFS da tutti gli host 5 
   2. Controllare la coerenza dei metadati del volume VMFS. 5 
   3. Firma ripetuta del volume VMFS 10 
   4. Rinominare il datastore VMFS (opzionale) 11 
   5. Verificare la coerenza dei metadati del volume VMFS dopo la nuova firma. 11 
   6. Presentare il dispositivo come NVMe a tutti gli host ESXi nel cluster 11 
   7. Registrazione e accensione di tutte le VM 11 
3. Post-migrazione. 12 

 

---

 

Panoramica

Con la crescente adozione di NVMe, sempre più clienti stanno valutando la migrazione dei dati da SCSI a NVMe. Questo documento descrive uno dei metodi efficienti, seppur interattivi, per la migrazione da SCSI a NVMe, noto come migrazione offline. La migrazione offline del datastore VMFS da SCSI a NVMe non comporta lo spostamento dei dati. Il dispositivo presentato in precedenza a un host o cluster ESXi come dispositivo SCSI, non viene presentato e quindi ripresentato come dispositivo NVMe. Il datastore VMFS viene quindi firmato nuovamente e reso disponibile agli host, conservando il contenuto della VM. I dettagli dei passaggi di migrazione offline sono descritti di seguito.

Ambito

• I passaggi per la migrazione offline, descritti nelle sezioni successive, sono applicabili solo ai datastore VMFS6.
• I passaggi riguardano gli aspetti funzionali della migrazione e non le caratteristiche delle prestazioni dei carichi di lavoro dopo la migrazione.
• La convalida della scalabilità (numero di migrazioni simultanee e così via) o dei limiti (numero massimo di percorsi per dispositivo, numero massimo di VMDK per macchina virtuale e così via) non rientra nell'ambito.
• I termini dispositivo, volume e LUN sono usati in modo intercambiabile nel documento.
• La migrazione offline richiede che tutte le VM nel datastore VMFS siano spente prima dell'avvio.  

 

---

 

1. Passaggi per la migrazione offline

   La migrazione offline di un datastore VMFS6 da SCSI a NVMe è costituita da tre fasi. Ogni fase può comportare più controlli o passaggi.

   1. Prima della migrazione

      Questa fase preparatoria prevede verifiche per comprendere le caratteristiche dell'ambiente e le funzionalità in uso. Questa fase è necessaria per determinare se la migrazione offline è fattibile nell'ambiente e anche per comprendere l'impatto post-migrazione. Di seguito sono elencati alcuni dei controlli importanti. Non si tratta di un elenco esaustivo, ma copre i controlli più comuni in un ambiente standard del cliente.

   2. Verificare la modalità di blocco del volume VMFS

      Innanzitutto, assicurarsi che la LUN supporti la modalità ATS. La migrazione deve essere tentata solo se il datastore VMFS6 utilizza la modalità di blocco solo ATS e non utilizza le prenotazioni SCSI-2. 
      
      Per determinare la modalità di blocco di un determinato volume, eseguire il comando esxcli storage vmfs lockmode list -l <volume name/label> su un host ESXi con accesso al datastore. La migrazione offline è supportata solo se la modalità di blocco per il volume VMFS6 è "ATS". La modalità "ATS+SCSI" non è supportata.
      
      Esempio di volume che supporta la migrazione offline:

      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. Controlla se c'è vmdk di qualsiasi VM nel datastore selezionato viene utilizzata come RDM (fisico o virtuale)

      Se una macchina virtuale nel datastore selezionato dispone di un RDM in modalità SCSI, non è possibile consentirle la migrazione a NVMe. Non esiste alcun comando VMware per rilevare se una macchina virtuale dispone di un RDM, tuttavia il plug-in Dell VSI elenca il tipo di disco per ogni macchina virtuale. Di seguito è riportata una schermata della vista in VSI che elenca se le VM (nome runtime) dispongono di un RDM.
      
       
       

      Se una macchina virtuale dispone di un RDM, prima della migrazione è necessario rimuovere RDM dalla macchina virtuale, convertirlo oppure spostarlo in un altro datastore.

   4. 1.3 Controllare il mapping delle regole/impostazioni di attestazione al dispositivo che ospita il datastore VMFS

      Se sono presenti regole di claim personalizzate sul dispositivo SCSI prima della migrazione, è probabile che non vengano applicate al dispositivo quando viene presentato tramite NVMe. I dispositivi NVMe non vengono presentati con campi vendor e model separati quando vi si accede tramite una richiesta di informazioni. I campi sono insieme e quindi è necessaria una nuova regola di attestazione se lo si desidera. Inoltre, le regole di attestazione basate sugli identificatori dei dispositivi, ad esempio World Wide Name (WWN), avranno esito negativo poiché l'ID SCSI e l'ID NVMe sono distinti.
      Per impostazione predefinita, VMware rivendica i dispositivi NVMe appena presentati con il plug-in di percorso predefinito HPP.

   5. Controllare sia il numero di dispositivi che i percorsi su ciascun host ESXi

      NVMe supporta un numero inferiore di dispositivi e percorsi rispetto a SCSI per ogni host ESXi. Se il numero di dispositivi SCSI supera i limiti NVMe, non è possibile convertire tutti i datastore sullo stesso host ESXi. Come soluzione, i clienti possono utilizzare più host ESXi o consolidare i datastore prima o dopo la conversione utilizzando Storage vMotion. 

      1. SCSI: 1024 dispositivi/4096 percorsi
      2. NVMe: 256 dispositivi/2048 percorsi

   6. Verificare la presenza di funzionalità non supportate 

      Alcune funzionalità di VMware non sono attualmente supportate con NVMe. Verificare la supportabilità prima della migrazione.

      Ad esempio, le seguenti funzionalità non sono attualmente supportate su NVMe in esecuzione su ESXi (fino alla versione 8.0U1).

       

      Funzione	Breve descrizione	Osservazioni
      Guest Clustering	Funzionalità VMDK in cluster che supporta soluzioni ad alta disponibilità come Windows Server Failover Cluster (WSFC)	Un datastore VMFS con VMDK Non è possibile eseguire la migrazione di Enabled.
      SRM	La replica basata su array con SRM non è supportata su NVMe.	La migrazione dei datastore coinvolti nella replica dell'array SRM rende la soluzione inutile.

       
      Nota: L'elenco di cui sopra non è esaustivo. I clienti devono consultare la documentazione specifica dell'array per informazioni sull'impatto della migrazione sulle funzionalità critiche.

   7. Verifica del potenziale impatto della post-migrazione sulle funzionalità supportate

      La mancanza di integrazione delle seguenti funzionalità può modificare il modo in cui alcune operazioni vengono eseguite su NVMe rispetto a SCSI.

      Funzione	Natura dell'impatto	Azione da effettuare
      Spostamento accelerato dell hardware - XCOPY	Attualmente non esiste un comando equivalente a XCOPY. Viene invece utilizzato VMware Software Data Mover. Ciò potrebbe ridurre le prestazioni delle operazioni che utilizzano la primitiva, ad esempio la clonazione o SvMotion.	None
      Scrivi uguale/UNMAP	Se un dispositivo NVMe non supporta l'equivalente NVMe di scritture zero o unmap, potrebbe verificarsi un impatto sulle prestazioni.	None

 

---

 

1. Migrazione

   Questa fase prevede la migrazione del datastore da SCSI a NVMe.

2. Spegnere tutte le VM e annullare la registrazione

   Spegnere e annullare la registrazione di tutte le VM ospitate sul datastore di cui eseguire la migrazione. Assicurarsi di non eliminarli, ma solo di annullare la registrazione.

3. Smontare il volume VMFS da tutti gli host

   Una volta annullata la registrazione di tutte le VM, smontare il volume VMFS da tutti gli host ESXi. In questo modo si garantisce che non sia in uso quando vengono eseguiti il controllo di coerenza e la migrazione

4. Controllo della coerenza dei metadati del volume VMFS

   Prima di avviare la migrazione, verificare la coerenza dei metadati VMFS su disco. In questo modo si garantisce che non vi siano incongruenze prima di iniziare.

   1. Eseguire VOMA (VMware On-Disk Metadata Analyzer) in modalità di controllo eseguendo:

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

    

   Dove:

   DEVICE è il dispositivo SCSI che ospita il volume VMFS6 di cui viene eseguita la migrazione

   PARTITION è il numero della partizione in base alla quale viene formattato il volume VMFS sul dispositivo

   OUTPUT FILE è il percorso assoluto del file in cui deve essere salvato l'output del comando. Questo file può trovarsi in /tmp se dispone di spazio sufficiente o di qualsiasi volume VMFS diverso da quello di cui si esegue la migrazione.

   Come in:

    

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

   L'output dovrebbe essere simile al seguente:

   [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

   Nota: Se il comando riceve il seguente errore, il VMFS non viene disinstallato correttamente:

    

VOMA Impossibile controllare il dispositivo: Dispositivo o risorsa occupato

2. Analizzare il file di output per verificare se sono presenti incoerenze dei metadati segnalate da voma. Se ce ne sono, devono essere risolti eseguendo voma in modalità avanzata di correzione prima di continuare. Di seguito è riportato un esempio:

[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. Raccogliere e salvare il dump dei metadati VMFS. Questa operazione è necessaria se nei passaggi successivi vengono rilevate incoerenze dei metadati. 

Consultare https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.html per ulteriori dettagli sull'utilizzo di voma In modalità Check, Advanced Fix Mode o Dump Mode.

Scollegamento della LUN SCSI dagli host ESXi

Scollegare la LUN SCSI da ciascun host ESXi nel VC. Per la procedura dettagliata, consultare la https://kb.vmware.com/s/article/2004605 dell'articolo della Knowledge Base.

 

Interrompere la presentazione di LUN SCSI dall'array.

I passaggi per rimuovere la LUN SCSI sono specifici dell'array di storage. I clienti devono consultare la documentazione specifica dell'array sulla procedura.

 

Presentare il dispositivo come NVMe a un host ESXi.

I passaggi per presentare nuovamente il dispositivo utilizzando NVMe sono specifici dell'array di storage. I clienti devono consultare la documentazione specifica dell'array sulla procedura. 

Avviare una nuova scansione del dispositivo sull host.

Una volta che il dispositivo viene presentato all host ESXi utilizzando NVMe, il rilevamento è in genere immediato. Tuttavia, se il dispositivo non viene visualizzato, ripetere la scansione di una o più schede utilizzando l'interfaccia utente di vSphere o la CLI:
 

esxcli storage core adapter rescan -a

 

Controllare la coerenza dei metadati del volume VMFS dopo la conversione.

Sull host ESXi che ha accesso al dispositivo, eseguire nuovamente voma in modalità di controllo per convalidare che i metadati VMFS su disco siano ancora coerenti. Eventuali incoerenze dei metadati devono essere analizzate prima di procedere. 
Voma utilizza il comando reserve SCSI-2 per bloccare il dispositivo al fine di impedire qualsiasi accesso o modifica simultaneo del volume VMFS quando la sessione VOMA è attiva. Tuttavia, i dispositivi NVMe non supportano l'equivalente di una prenotazione SCSI-2. Per risolvere questo problema, l'utente deve passare il "-N" opzione per VOMA quando il dispositivo back-end è NVMe. Ad esempio:

• Eseguire VOMA (VMware On-Disk Metadata Analyzer) in modalità di controllo eseguendo:

 

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

Quando voma viene invocato con "-N", viene visualizzato il seguente messaggio di avvertenza. 

 

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

Selezionare un numero da 0 a 1:
per notificare che è responsabilità dell'utente impedire che il mounting o l'accesso al volume venga eseguito contemporaneamente da altri host mentre è in corso la sessione voma corrente. Se sono stati seguiti i passaggi descritti qui e il dispositivo è stato mappato e rilevato su un solo host ESXi, dovrebbe essere sicuro procedere. L'utente deve immettere "0" quando richiesto per continuare con la modalità di controllo voma. Di seguito è riportato un esempio:
 

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

Esecuzione di VMFS Checker versione 2.1 in modalità
di controllo Inizializzazione dei metadati LVM, base I controlli vengono eseguiti
Controllo dell'attività
del file system Il supporto per la prenotazione non è presente per i dispositivi NVMe Attività st (4096 byte/HB, 1024 HBs).                                 \
Esecuzione del controllo dell'attività del file system..|

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

Selezionare un numero da 0 a 1:

0 Fase 1: Controllo dell'intestazione VMFS e dei file
di risorse File system VMFS-6 rilevato (etichettato:'Temp_Datastore') con UUID:64359f88-dd0fd27e-af5a-34800d0ed39c, Version 6:82
Fase 2. Verifica della regione
heartbeat VMFS Fase 3: Controllo di tutti i descrittori di file.
Fase 4: Verifica del nome del percorso e della connettività.
Fase 5: Controllo del numero di riferimenti alle risorse.
Totale errori trovati:           0

Firma ripetuta del volume VMFS 

Ora che il dispositivo viene presentato come NVMe, è necessario aggiornare la firma presente sul datastore. Ciò è dovuto al fatto che la firma corrente si basa, in parte, sul WWN del dispositivo quando viene presentato utilizzando SCSI. Poiché l'ID dispositivo NVMe è diverso, è necessario generare una nuova firma. Pertanto, sullo stesso host ESXi utilizzato nei due passaggi precedenti, eseguire quanto segue per firmare nuovamente il volume:

1. Anche se ridondante, ripetere la scansione del file system eseguendo il comando:

 

esxcli storage filesystem rescan

2. Quindi, eseguire il comando seguente per ottenere un elenco di LUN di istantanee VMFS:

 

esxcli storage vmfs snapshot list

Il dispositivo NVMe appena presentato dovrebbe essere presente, anche se, a seconda dell'ambiente, potrebbero essere presenti altre istantanee non correlate a questo processo.

3. Firma di nuovo del volume VMFS eseguendo quanto segue:

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

Di seguito è riportato un esempio:
 

[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

 

Rinominare il datastore VMFS (opzionale)

Quando un volume VMFS viene firmato nuovamente, l'etichetta del volume VMFS è preceduta dal tag "snap" seguito da una stringa alfanumerica. Ad esempio, il datastore VMFS nel passaggio precedente è ora denominato: snap-5c42a2bc-Temp_Datastore Se si desidera, rinominare nuovamente il datastore con il nome originale, rimuovendo il prefisso.

Verificare la coerenza dei metadati del volume VMFS dopo la nuova firma.

Ancora una volta, verificare che i metadati VMFS su disco siano coerenti dopo la nuova firma. Eseguire voma in modalità di controllo sul volume VMFS. Vedere la sezione 2.8 per la riga di comando voma che deve includere il flag "-N". Verificare se voma segnala eventuali incongruenze. Procedere se voma non segnala alcun errore. 

Presentare il dispositivo come NVMe a tutti gli host ESXi nel cluster.

Se non si sono verificati problemi in nessuno dei passaggi precedenti, il dispositivo può ora essere presentato utilizzando NVMe a tutti gli host ESXi nel cluster. Come indicato, i dispositivi NVMe vengono riconosciuti immediatamente, ma in caso contrario ripetere la scansione delle schede tramite l'interfaccia utente di vSphere o la CLI. Verificare che il volume VMFS6 sia montato e accessibile su tutti gli host.

Registrazione e accensione di tutte le VM

Registrare tutte le VM in hosting sul datastore e accenderle. Verificare che le VM si accendano correttamente e che possano accedere ai vmdk. Come best practice, l'utente può registrare e accendere le VM su un singolo ESXi. Una volta eseguito correttamente il processo, è possibile eseguirne la migrazione ad altri host.

Nota: Quando si accendono le VM dall'interfaccia utente di vCenter, potrebbe essere visualizzata una finestra pop-up come quella mostrata di seguito. In questo modo viene richiesto all'utente di registrare se la macchina virtuale è stata copiata o spostata. Seleziona "L'ho copiato" nel pop-up.

 

 

---

 

Post-migrazione

Verificare l'impatto sulle funzionalità principali ed eseguire l'eventuale pulizia, se necessario. 

1.4 Controllare sia il numero di dispositivi che i percorsi su ciascun host ESXi 3
1.5 Verificare la presenza di funzionalità non supportate 4
1.6 Verificare il potenziale impatto post-migrazione sulle funzionalità supportate 4
2.  Migrazione 4
2.2 Disinstallazione del volume VMFS da tutti gli host 5
2.3 Controllo della coerenza dei metadati del volume VMFS.
5 2.9 Rifirmare il volume VMFS 10
2.10 Rinominare il datastore VMFS (opzionale) 11
2.11 Controllare la coerenza dei metadati del volume VMFS dopo la nuova firma. 11
2.12 Presentazione del dispositivo come NVMe a tutti gli host ESXi nel cluster 11
2.13 Registrazione e accensione di tutte le VM 11
3. Post-migrazione. 12

Panoramica

Con la crescente adozione di NVMe, sempre più clienti stanno valutando la migrazione dei dati da SCSI a NVMe. Questo documento descrive uno dei metodi efficienti, seppur interattivi, per la migrazione da SCSI a NVMe, noto come migrazione offline. La migrazione offline del datastore VMFS da SCSI a NVMe non comporta lo spostamento dei dati. Il dispositivo presentato in precedenza a un host o cluster ESXi come dispositivo SCSI, non viene presentato e quindi ripresentato come dispositivo NVMe. Il datastore VMFS viene quindi firmato nuovamente e reso disponibile agli host, conservando il contenuto della VM. I dettagli dei passaggi di migrazione offline sono descritti di seguito.

Ambito

• I passaggi per la migrazione offline, descritti nelle sezioni successive, sono applicabili solo ai datastore VMFS6.
• I passaggi riguardano gli aspetti funzionali della migrazione e non le caratteristiche delle prestazioni dei carichi di lavoro dopo la migrazione.
• La convalida della scalabilità (numero di migrazioni simultanee e così via) o dei limiti (numero massimo di percorsi per dispositivo, numero massimo di VMDK per macchina virtuale e così via) non rientra nell'ambito.
• I termini dispositivo, volume e LUN sono usati in modo intercambiabile nel documento.
• La migrazione offline richiede che tutte le VM nel datastore VMFS siano spente prima dell'avvio.  

Passaggi per la migrazione offline

La migrazione offline di un datastore VMFS6 da SCSI a NVMe è costituita da tre fasi. Ogni fase può comportare più controlli o passaggi.

Prima della migrazione

Questa fase preparatoria prevede verifiche per comprendere le caratteristiche dell'ambiente e le funzionalità in uso. Questa fase è necessaria per determinare se la migrazione offline è fattibile nell'ambiente e anche per comprendere l'impatto post-migrazione. Di seguito sono elencati alcuni dei controlli importanti. Non si tratta di un elenco esaustivo, ma copre i controlli più comuni in un ambiente standard del cliente.

Verificare la modalità di blocco del volume VMFS.

Innanzitutto, assicurarsi che la LUN supporti la modalità ATS. La migrazione deve essere tentata solo se il datastore VMFS6 utilizza la modalità di blocco solo ATS e non utilizza le prenotazioni SCSI-2. 

Per determinare la modalità di blocco di un determinato volume, eseguire il comando esxcli storage vmfs lockmode list -l <volume name/label> su un host ESXi con accesso al datastore. La migrazione offline è supportata solo se la modalità di blocco per il volume VMFS6 è "ATS". La modalità "ATS+SCSI" non è supportata.

Esempio di volume che supporta la migrazione offline:

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 Controlla se c'è vmdk di qualsiasi VM nel datastore selezionato viene utilizzata come RDM (fisico o virtuale)

Se una macchina virtuale nel datastore selezionato dispone di un RDM in modalità SCSI, non è possibile consentirle la migrazione a NVMe. Non esiste alcun comando VMware per rilevare se una macchina virtuale dispone di un RDM, tuttavia il plug-in Dell VSI elenca il tipo di disco per ogni macchina virtuale. Di seguito è riportata una schermata della vista in VSI che elenca se le VM (nome runtime) dispongono di RDM.

 

Se una macchina virtuale dispone di un RDM, prima della migrazione è necessario rimuovere RDM dalla macchina virtuale, convertirlo oppure spostarlo in un altro datastore.

1.3 Controllo claim rules/settings mapping al dispositivo che ospita il datastore VMFS.

Se sono presenti regole di claim personalizzate sul dispositivo SCSI prima della migrazione, è probabile che non vengano applicate al dispositivo quando viene presentato tramite NVMe. I dispositivi NVMe non vengono presentati con campi vendor e model separati quando vi si accede tramite una richiesta di informazioni. I campi sono insieme e quindi è necessaria una nuova regola di attestazione se lo si desidera. Inoltre, le regole di attestazione basate sugli identificatori dei dispositivi, ad esempio World Wide Name (WWN), avranno esito negativo poiché l'ID SCSI e l'ID NVMe sono distinti.
Per impostazione predefinita, VMware rivendica i dispositivi NVMe appena presentati con il plug-in di percorso predefinito HPP.

1.4 Controllare sia il numero di dispositivi che i percorsi su ciascun host ESXi.

NVMe supporta un numero inferiore di dispositivi e percorsi rispetto a SCSI per ogni host ESXi. Se il numero di dispositivi SCSI supera i limiti NVMe, non sarà possibile convertire tutti i datastore sullo stesso host ESXi. Come soluzione, i clienti possono utilizzare più host ESXi o consolidare i datastore prima o dopo la conversione utilizzando Storage vMotion. 

1. SCSI: 1024 dispositivi/4096 percorsi
2. NVMe: 256 dispositivi/2048 percorsi

1.5 Verificare la presenza di funzionalità non supportate. 

Alcune funzionalità di VMware non sono attualmente supportate con NVMe. Verificare la supportabilità prima della migrazione.
Ad esempio, le seguenti funzionalità non sono attualmente supportate su NVMe in esecuzione su ESXi (fino alla versione 8.0U1). 
 

Funzione	Breve descrizione	Osservazioni
Guest Clustering	Funzionalità VMDK in cluster che supporta soluzioni ad alta disponibilità come Windows Server Failover Cluster (WSFC)	Non è possibile migrare un datastore VMFS con VMDK in cluster abilitato.
SRM	La replica basata su array con SRM non è supportata su NVMe.	La migrazione dei datastore coinvolti nella replica dell'array SRM rende la soluzione inutile.

Nota: L'elenco di cui sopra non è esaustivo. I clienti devono consultare la documentazione specifica dell'array per informazioni sull'impatto della migrazione sulle funzionalità critiche. 

 

Verificare il potenziale impatto della post-migrazione sulle funzioni supportate.

La mancanza di integrazione delle seguenti funzionalità può modificare il modo in cui alcune operazioni vengono eseguite su NVMe rispetto a SCSI.
 

Funzione	Natura dell'impatto	Azione da effettuare
Spostamento accelerato dell hardware - XCOPY	Attualmente non esiste un comando equivalente a XCOPY. VMware Verrà invece utilizzato Software Data Mover. Ciò potrebbe ridurre le prestazioni delle operazioni che normalmente utilizzano la primitiva, ad esempio la clonazione o SvMotion.	None
Scrivi uguale/UNMAP	Se un dispositivo NVMe non supporta l'equivalente NVMe di scritture zero o unmap, potrebbe verificarsi un impatto sulle prestazioni.	None

Migrazione

Questa fase prevede la migrazione del datastore da SCSI a NVMe.

Spegnere tutte le VM e annullare la registrazione

Spegnere e annullare la registrazione di tutte le VM ospitate sul datastore di cui eseguire la migrazione. Assicurarsi di non eliminarli, ma solo di annullare la registrazione.

Smontare il volume VMFS da tutti gli host

Una volta annullata la registrazione di tutte le VM, smontare il volume VMFS da tutti gli host ESXi. In questo modo si garantisce che non sia in uso quando vengono eseguiti il controllo di coerenza e la migrazione. 

Controllare la coerenza dei metadati del volume VMFS.

Prima di avviare la migrazione, verificare la coerenza dei metadati VMFS su disco. In questo modo si garantisce che non vi siano incongruenze prima dell'inizio.

1. Eseguire VOMA (VMware On-Disk Metadata Analyzer) in modalità di controllo eseguendo:

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

Dove:
DEVICE è il dispositivo SCSI che ospita il volume VMFS6 di cui si sta eseguendo la migrazione.
PARTITION è il numero della partizione in base alla quale viene formattato il volume VMFS sul dispositivo.
OUTPUT FILE è il percorso assoluto del file in cui deve essere salvato l'output del comando. Questo file può trovarsi in /tmp se dispone di spazio sufficiente o di qualsiasi volume VMFS diverso da quello di cui si esegue la migrazione.

Ad esempio:

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

L'output dovrebbe essere simile al seguente:
 

[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

Nota: Se il comando riceve il seguente errore, VMFS non viene disinstallato correttamente:

VOMA non è riuscito a controllare il dispositivo: Dispositivo o risorsa occupato

2. Analizzare il file di output per verificare se sono presenti incoerenze dei metadati segnalate da voma. Se ce ne sono, devono essere risolti eseguendo voma in modalità avanzata di correzione prima di continuare. Di seguito è riportato un esempio:

[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. Raccogliere e salvare il dump dei metadati VMFS. Questa operazione è necessaria se nei passaggi successivi vengono rilevate incoerenze dei metadati. 

Consultare https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.html per ulteriori dettagli sull'utilizzo di voma In modalità Check, Advanced Fix Mode o Dump Mode.

Scollegamento della LUN SCSI dagli host ESXi

Scollegare la LUN SCSI da ciascun host ESXi nel VC. Per la procedura dettagliata, consultare la https://kb.vmware.com/s/article/2004605 dell'articolo della Knowledge Base.

Interrompere la presentazione di LUN SCSI dall'array.

I passaggi per rimuovere la LUN SCSI sono specifici dell'array di storage. I clienti devono consultare la documentazione specifica dell'array sulla procedura.

Presentare il dispositivo come NVMe a un host ESXi.

I passaggi per presentare nuovamente il dispositivo utilizzando NVMe sono specifici dell'array di storage. I clienti devono consultare la documentazione specifica dell'array sulla procedura. 

Avviare una nuova scansione del dispositivo sull host.

Una volta che il dispositivo viene presentato all host ESXi utilizzando NVMe, il rilevamento è in genere immediato. Tuttavia, se il dispositivo non viene visualizzato, ripetere la scansione di una o più schede utilizzando l'interfaccia utente di vSphere o la CLI:
 

esxcli storage core adapter rescan -a

Controllare la coerenza dei metadati del volume VMFS dopo la conversione.

Sull host ESXi che ha accesso al dispositivo, eseguire nuovamente voma in modalità di controllo per convalidare che i metadati VMFS su disco siano ancora coerenti. Eventuali incoerenze dei metadati devono essere analizzate prima di procedere. 
Voma utilizza il comando di riserva SCSI-2 per bloccare il dispositivo al fine di impedire qualsiasi accesso o modifica simultaneo del volume VMFS quando la sessione voma è attiva. Tuttavia, i dispositivi NVMe non supportano l'equivalente di una prenotazione SCSI-2. Per risolvere questo problema, l'utente deve passare il "-N" opzione per VOMA quando il dispositivo back-end è NVMe. Ad esempio:

• Eseguire VOMA (VMware On-Disk Metadata Analyzer) in modalità di controllo eseguendo:

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

Selezionare un numero da 0 a 1:
per notificare che è responsabilità dell'utente impedire che il mounting o l'accesso al volume venga eseguito contemporaneamente da altri host mentre è in corso la sessione voma corrente. Se sono stati seguiti i passaggi descritti qui e il dispositivo è stato mappato e rilevato su un solo host ESXi, dovrebbe essere sicuro procedere. L'utente deve immettere "0" quando richiesto per continuare con la modalità di controllo voma. Di seguito è riportato un esempio:
 

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

Esecuzione di VMFS Checker versione 2.1 in modalità
di controllo Inizializzazione dei metadati LVM, base I controlli vengono eseguiti
Controllo dell'attività
del file system Il supporto per la prenotazione non è presente per i dispositivi NVMe Attività st (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

 

Firma ripetuta del volume VMFS 

Ora che il dispositivo viene presentato come NVMe, è necessario aggiornare la firma presente sul datastore. Ciò è dovuto al fatto che la firma corrente si basa, in parte, sul WWN del dispositivo quando viene presentato utilizzando SCSI. Poiché l'ID dispositivo NVMe è diverso, è necessario generare una nuova firma. Pertanto, sullo stesso host ESXi utilizzato nei due passaggi precedenti, eseguire quanto segue per firmare nuovamente il volume:

1. Anche se ridondante, ripetere la scansione del file system eseguendo il comando:

Nuova scansione del file system di storage ESXCLI

2. Quindi, eseguire il comando seguente per ottenere un elenco di LUN di istantanee VMFS:

Elenco

delle istantanee VMFS di storage ESXCLI Il dispositivo NVMe appena presentato dovrebbe essere presente, anche se, a seconda dell'ambiente, potrebbero essere presenti altre istantanee non correlate a questo processo.

3. Firma di nuovo del volume VMFS eseguendo quanto segue:

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

 

Di seguito è riportato un esempio:

[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

Rinominare il datastore VMFS (opzionale)

Quando un volume VMFS viene firmato nuovamente, l'etichetta del volume VMFS è preceduta dal tag "snap" seguito da una stringa alfanumerica. Ad esempio, il datastore VMFS nel passaggio precedente è ora denominato: snap-5c42a2bc-Temp_Datastore. Se si desidera, rinominare nuovamente il datastore con il nome originale, rimuovendo il prefisso.

Verificare la coerenza dei metadati del volume VMFS dopo la nuova firma.

Ancora una volta, verificare che i metadati VMFS su disco siano coerenti dopo la nuova firma. Eseguire voma in modalità di controllo sul volume VMFS. Vedere la sezione 2.8 per la riga di comando voma che deve includere il flag "-N". Verificare se voma segnala eventuali incongruenze. Procedere se voma non segnala alcun errore. 

Presentare il dispositivo come NVMe a tutti gli host ESXi nel cluster.

Se non si sono verificati problemi in nessuno dei passaggi precedenti, il dispositivo può ora essere presentato utilizzando NVMe a tutti gli host ESXi nel cluster. Come indicato, i dispositivi NVMe vengono riconosciuti immediatamente, ma in caso contrario ripetere la scansione delle schede tramite l'interfaccia utente di vSphere o la CLI. Verificare che il volume VMFS6 sia montato e accessibile su tutti gli host.

Registrazione e accensione di tutte le VM

Registrare tutte le VM in hosting sul datastore e accenderle. Verificare che le VM si accendano correttamente e che possano accedere ai vmdk. Come best practice, l'utente può registrare e accendere le VM su un singolo ESXi. Una volta eseguito correttamente il processo, è possibile eseguirne la migrazione ad altri host.

Nota: Quando si accendono le VM dall'interfaccia utente di vCenter, potrebbe essere visualizzata una finestra pop-up come quella mostrata di seguito. In questo modo viene richiesto all'utente di registrare se la macchina virtuale è stata copiata o spostata. Seleziona "L'ho copiato" nel pop-up.

 

Post-migrazione

Verificare l'impatto sulle funzionalità principali ed eseguire l'eventuale pulizia, se necessario. 

 

Si tratta di un processo ufficialmente controllato da VMware per la migrazione del datastore offline. Le migrazioni online delle singole macchine virtuali possono essere eseguite utilizzando Storage vMotion. VMware non dispone di un articolo KB separato per questo processo.

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