Etapas de migração off-line do datastore VMware VMFS de SCSI para NVMe

Etapas de migração de datastore VMFS off-line de SCSI para NVMe

Sumário

• Etapas 1 de migração de datastore VMFS off-line de SCSI para NVMe
• Visão geral
• Scope

1. Etapas da migração off-line
   1.  Pré-migração
   2. Verifique o número de dispositivos e caminhos para cada host do ESXi 3 
   3. Verificar se há recursos incompatíveis 4 
   4. Verifique o possível impacto da pós-migração nos recursos compatíveis 4 
2. Migração
   1. Desmonte o volume VMFS de todos os hosts 5 
   2. Verifique a consistência dos metadados do volume VMFS. 5 
   3. Assinatura nova do volume VMFS 10 
   4. Renomear o datastore VMFS (opcional) 11 
   5. Verifique a consistência dos metadados do volume VMFS após uma nova assinatura. 11 
   6. Apresente o dispositivo como NVMe a todos os hosts do ESXi no cluster 11 
   7. Registre e ligue todas as VMs 11 
3. Pós-migração. 12 

 

---

 

Visão geral

Com o crescimento da adoção do NVMe, mais clientes buscam migrar dados de SCSI para NVMe. Este documento descreve um dos métodos eficientes, embora disruptivos, de migração de SCSI para NVMe, conhecido como migração off-line. A migração off-line do datastore VMFS de SCSI para NVMe não envolve a movimentação de dados. O dispositivo que foi apresentado anteriormente a um host ou cluster do ESXi como um dispositivo SCSI não é apresentado e, em seguida, apresentado novamente como um dispositivo NVMe. Em seguida, o datastore VMFS é assinado novamente e disponibilizado aos hosts, mantendo seu conteúdo de VM. Os detalhes das etapas de migração off-line são descritos abaixo.

Scope

• As etapas para migração off-line, descritas nas seções subsequentes, são aplicáveis apenas a datastores VMFS6.
• As etapas abrangem aspectos funcionais da migração e não abrangem características de desempenho das cargas de trabalho após a migração.
• A validação de escala (número de migrações simultâneas etc.) ou limites (máximo de caminhos por dispositivo, máximo de VMDKs por VM etc.) não está no escopo.
• Os termos dispositivo, volume e LUN são usados de modo intercambiável no documento.
• A migração off-line exige que todas as VMs no datastore VMFS sejam desligadas antes de iniciar.  

 

---

 

1. Etapas da migração off-line

   A migração off-line de um datastore VMFS6 de SCSI para NVMe consiste em três fases. Cada fase pode envolver várias verificações ou etapas.

   1. Pré-migração

      Essa fase preparatória inclui verificações para entender as características do ambiente e os recursos que estão em uso. Essa fase é necessária para determinar se a migração off-line é viável no ambiente e também para entender o impacto após a migração. Algumas das verificações importantes estão listadas abaixo. Esta não é uma lista completa, mas abrange as verificações mais comuns em um ambiente padrão do cliente.

   2. Verifique o modo de bloqueio do volume VMFS

      Primeiro, certifique-se de que a LUN seja compatível com o modo ATS. A migração deve ser tentada somente se o datastore VMFS6 estiver usando o modo de bloqueio somente ATS e não usar reservas SCSI-2. 
      
      Para determinar o modo de bloqueio de um determinado volume, execute o comando esxcli storage vmfs lockmode list -l <volume name/label> em um host do ESXi com acesso ao datastore. A migração off-line só será compatível se o modo de bloqueio do volume VMFS6 for "ATS". O modo "ATS+SCSI" não é compatível.
      
      Um exemplo de um volume compatível com migração off-line:

      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. Verifique se há algum vmdk de qualquer VM no datastore selecionado é usado como um RDM (físico ou virtual)

      Se uma VM no datastore selecionado tiver um RDM no modo SCSI, não será permitido migrar para o NVMe. Não há nenhum comando VMware para detectar se uma VM tem um RDM, no entanto, o plug-in Dell VSI lista o tipo de disco para cada VM. Veja abaixo uma captura de tela da visualização no VSI que lista se alguma VM (nome de tempo de execução) tem um RDM.
      
       
       

      Se uma VM tiver um RDM, ele deverá ser removido da VM, convertido ou movido para outro datastore antes da migração.

   4. 1.3 Verifique as regras/configurações de reivindicação mapeadas para o dispositivo que hospeda o datastore VMFS

      Se houver regras de declaração personalizadas no dispositivo SCSI antes da migração, elas provavelmente não serão aplicadas ao dispositivo quando forem apresentadas usando NVMe. Os dispositivos NVMe não são apresentados com campos de fornecedor e modelo separados quando acessados por meio de consulta. Os campos estão juntos e, portanto, uma nova regra de reivindicação é necessária, se desejado. Além disso, as regras de declaração baseadas em identificadores de dispositivo, por exemplo, World Wide Name (WWN), falharão, pois o identificador SCSI e o identificador NVMe são distintos.
      Por padrão, a VMware reivindicará dispositivos NVMe recém-apresentados com o plug-in de caminho padrão do HPP.

   5. Verifique o número de dispositivos e caminhos para cada host do ESXi

      O NVMe dá suporte a menos dispositivos e caminhos do que SCSI para cada host do ESXi. Se o número de dispositivos SCSI exceder os limites de NVMe, não será possível converter todos os datastores no mesmo host do ESXi. Como solução, os clientes podem empregar mais hosts do ESXi ou consolidar datastores antes ou depois da conversão usando o Storage vMotion. 

      1. SCSI - 1.024 dispositivos/4.096 caminhos
      2. NVMe - 256 dispositivos/2.048 caminhos

   6. Verificar se há recursos incompatíveis 

      Alguns recursos da VMware não são compatíveis com NVMe no momento. Verifique a capacidade de suporte antes da migração.

      Por exemplo, os recursos a seguir não são compatíveis atualmente com o NVMe em execução no ESXi (até a versão 8.0U1).

       

      Recurso	Breve descrição	Observações
      Organização por clusters convidados	Recurso de VMDK em cluster que dá suporte a soluções de alta disponibilidade, como o WSFC (Windows Server Failover Cluster)	Um datastore VMFS com cluster VMDK Não é possível migrar habilitado.
      SRM	A replicação baseada em array com SRM não é compatível com NVMe.	A migração de datastores envolvidos com a replicação de array do SRM torna a solução inútil.

       
      Nota: A lista acima não é exaustiva. Os clientes devem consultar a documentação específica do array sobre o impacto da migração nos recursos essenciais.

   7. Verifique o possível impacto da pós-migração nos recursos compatíveis

      A falta de integração dos recursos a seguir pode alterar o desempenho de determinadas operações no NVMe em comparação com o SCSI.

      Recurso	Natureza do impacto	Ações a serem tomadas
      Movimentação acelerada por hardware — XCOPY	No momento, não há nenhum comando equivalente a XCOPY. Em vez disso, o Data Mover de software VMware é usado. Isso pode diminuir o desempenho das operações que usam o primitivo, como clonagem ou SvMotion.	Nenhuma
      Write Same/UNMAP	Se um dispositivo NVMe não for compatível com o equivalente NVMe de zeros de gravação ou unmap, pode haver um impacto sobre o desempenho.	Nenhuma

 

---

 

1. Migração

   Essa fase envolve as etapas para migrar o datastore de SCSI para NVMe.

2. Desligue todas as VMs e cancele o registro

   Desligue e cancele o registro de todas as VMs hospedadas no datastore a ser migrado. Certifique-se de não excluí-los, apenas cancele o registro.

3. Desmonte o volume VMFS de todos os hosts

   Desmonte o volume VMFS de todos os hosts do ESXi depois que todas as VMs tiverem o registro cancelado. Isso serve para garantir que ele não esteja em uso quando a verificação de consistência e a migração forem realizadas

4. Verifique a consistência de metadados do volume VMFS

   Antes de iniciar a migração, verifique a consistência dos metadados em disco do VMFS. Isso garante que não haja inconsistências antes de começar.

   1. Execute VOMA (VMware On-Disk Metadata Analyzer) no modo de verificação executando:

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

    

   Onde:

   DEVICE é o dispositivo SCSI que hospeda o volume VMFS6 que está sendo migrado

   PARTITION é o número da partição na qual o volume VMFS está formatado no dispositivo

   OUTPUT FILE é o caminho absoluto do arquivo no qual a saída do comando deve ser salva. Este arquivo pode ser localizado em /tmp se ele tiver espaço suficiente ou qualquer volume VMFS diferente do que está sendo migrado.

   Como em:

    

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

   O resultado deve ser semelhante ao seguinte:

   [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 o comando receber o seguinte erro, o VMFS não será desmontado corretamente:

    

VOMA Falha ao verificar o dispositivo: Dispositivo ou recurso ocupado

2. Analise o arquivo de saída para ver se há alguma inconsistência de metadados relatada por voma. Se houver, então eles devem ser resolvidos executando voma No modo de correção avançado antes de continuar. Por exemplo:

[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. Colete e salve o dump de metadados do VMFS. Isso será necessário se alguma inconsistência de metadados for vista em etapas subsequentes. 

Consulte https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.html para obter mais detalhes sobre como usar voma Em cheque, Advanced Fix Mode ou Dump mode.

Desconectar a LUN SCSI dos hosts do ESXi

Desconecte a LUN SCSI de cada host do ESXi no VC. Consulte o artigo da base de conhecimento https://kb.vmware.com/s/article/2004605 para obter as etapas detalhadas.

 

Pare de apresentar a LUN SCSI do array.

As etapas para cancelar a apresentação da LUN SCSI são específicas para o storage array. Os clientes devem consultar a documentação específica do array sobre o procedimento.

 

Apresente o dispositivo como NVMe a um host do ESXi.

As etapas para reapresentar o dispositivo usando o NVMe são específicas do storage array. Os clientes devem consultar a documentação específica do array sobre o procedimento. 

Inicie a nova varredura do dispositivo no host.

Depois que o dispositivo é apresentado ao host do ESXi usando NVMe, a detecção geralmente é imediata. No entanto, se o dispositivo não aparecer, examine novamente um ou mais adaptadores usando a interface do usuário do vSphere ou a CLI:
 

esxcli storage core adapter rescan -a

 

Verifique a consistência de metadados do volume VMFS após a conversão.

No host do ESXi que tem acesso ao dispositivo, execute novamente voma no modo de verificação para confirmar se os metadados em disco do VMFS ainda são consistentes. Todas as inconsistências de metadados devem ser investigadas antes de continuar. 
Voma usa o comando de reserva SCSI-2 para bloquear o dispositivo a fim de impedir qualquer acesso simultâneo ou modificação do volume VMFS quando a sessão voma está ativa. No entanto, os dispositivos NVMe não são compatíveis com o equivalente a uma reserva SCSI-2. Para contornar isso, o usuário deve passar a "-N" opção para VOMA quando o dispositivo de back-end é NVMe. Por exemplo:

• Execute VOMA (VMware On-Disk Metadata Analyzer) no modo de verificação executando:

 

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

No voma é invocado com "-N" A seguinte mensagem de aviso é exibida. 

 

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

Selecione um número de 0-1:
Isso é para notificar que é responsabilidade do usuário impedir que o volume seja montado ou acessado simultaneamente de outros hosts enquanto a sessão voma atual estiver em andamento. Se as etapas descritas neste documento tiverem sido seguidas e o dispositivo tiver sido mapeado e detectado em apenas um host do ESXi, será seguro prosseguir. O usuário deve digitar "0" no prompt para continuar com o modo de verificação de voma. Segue um exemplo:
 

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

Executando o VMFS Checker versão 2.1 no modo
de verificação Inicializando metadados do LVM, verificações básicas são feitas
Verificando a atividade
do file system O suporte de reserva não está presente para a atividade st de dispositivos NVMe (4.096 bytes/HB, 1.024 HBs).                                 \
Realizando a verificação da integridade do 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

Selecione um número de 0-1:

0 Fase 1: Verificando arquivos de cabeçalho e recurso
do VMFS File system VMFS-6 detectado (rotulado:'Temp_Datastore') com UUID:64359f88-dd0fd27e-af5a-34800d0ed39c, Version 6:82
Fase 2: Verificação da região
de heartbeat do VMFS Fase 3: Verificando todos os descritores de arquivo.
Fase 4: Verificando o nome do caminho e a conectividade.
Fase 5: Verificando contagens de referência de recursos.
Total de erros encontrados:           0

Assine novamente o volume VMFS 

Agora que o dispositivo é apresentado como NVMe, é necessário atualizar a assinatura que está no datastore. Isso ocorre porque a assinatura atual é baseada, em parte, no WWN do dispositivo quando apresentado usando SCSI. Como o ID do dispositivo NVMe é diferente, uma nova assinatura deve ser gerada. Portanto, no mesmo host do ESXi que foi usado nas duas etapas anteriores, execute o seguinte para reassinar o volume:

1. Embora redundante, verifique novamente o file system executando o comando:

 

esxcli storage filesystem rescan

2. Em seguida, execute o seguinte comando para obter uma lista de LUNs de snapshot VMFS:

 

esxcli storage vmfs snapshot list

O dispositivo NVMe recém-apresentado deve estar presente, embora dependendo do ambiente possa haver outros snapshots não relacionados a esse processo.

3. Assine novamente o volume VMFS executando o seguinte:

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

Veja um exemplo abaixo:
 

[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

 

Renomear o datastore VMFS (opcional)

Quando um volume VMFS é assinado novamente, o rótulo do volume VMFS tem como prefixo a marca "snap" seguida por uma string alfanumérica. Por exemplo, o datastore VMFS na etapa anterior agora tem o nome: snap-5c42a2bc-Temp_Datastore Se desejado, renomeie o datastore para o nome original, removendo o prefixo.

Verifique a consistência dos metadados do volume VMFS após uma nova assinatura.

Mais uma vez, confirme se os metadados do VMFS em disco são consistentes após uma nova assinatura. Execute o voma no modo de verificação no volume VMFS. Consulte a seção 2.8 para obter a linha de comando voma, que deve incluir o indicador "-N". Verifique se a voma está relatando alguma inconsistência. Prossiga se a voma não relatar nenhum erro. 

Apresente o dispositivo como NVMe a todos os hosts do ESXi no cluster.

Se não houve problemas em nenhuma das etapas anteriores, agora, o dispositivo pode ser apresentado usando NVMe a todos os hosts do ESXi no cluster. Conforme observado, os dispositivos NVMe são reconhecidos imediatamente, mas, se não, examine novamente os adaptadores por meio da interface do usuário ou da CLI do vSphere. Verifique se o volume VMFS6 está montado e acessível em todos os hosts.

Registre e ligue todas as VMs

Registre todas as VMs hospedadas no datastore e ligue-as. Verifique se as VMs estão sendo inicializadas com sucesso e se conseguem acessar os vmdks. Como prática recomendada, o usuário pode registrar e ligar VMs em um único ESXi. Depois de bem-sucedidos, eles poderiam ser migrados para outros hosts.

Nota: Ao ligar as VMs a partir da interface do usuário do vCenter, pode haver uma janela pop-up como a mostrada abaixo. Isso solicita que o usuário registre se a VM foi copiada ou movida. Selecione "I Copied" no pop-up.

 

 

---

 

Pós-migração

Verifique se há algum impacto sobre os principais recursos e faça uma limpeza, se necessário. 

1.4 Verifique o número de dispositivos e caminhos para cada host do ESXi 3
1.5 Verifique se há recursos incompatíveis 4
1.6 Verifique se há um possível impacto pós-migração nos recursos compatíveis 4
2.  Migração 4
2.2 Desmontar o volume VMFS de todos os hosts 5
2.3 Verifique a consistência dos metadados do volume VMFS.
5 2.9 Assinatura nova do volume VMFS 10
2.10 Renomeie o datastore VMFS (opcional) 11
2.11 Verifique a consistência dos metadados do volume VMFS após a nova assinatura. 11
2.12 Apresente o dispositivo como NVMe a todos os hosts do ESXi no cluster 11
2.13 Registre e ligue todas as VMs 11
3. Pós-migração. 12

Visão geral

Com o crescimento da adoção do NVMe, mais clientes buscam migrar dados de SCSI para NVMe. Este documento descreve um dos métodos eficientes, embora disruptivos, de migração de SCSI para NVMe, conhecido como migração off-line. A migração off-line do datastore VMFS de SCSI para NVMe não envolve a movimentação de dados. O dispositivo que foi apresentado anteriormente a um host ou cluster do ESXi como um dispositivo SCSI não é apresentado e, em seguida, apresentado novamente como um dispositivo NVMe. Em seguida, o datastore VMFS é assinado novamente e disponibilizado aos hosts, mantendo seu conteúdo de VM. Os detalhes das etapas de migração off-line são descritos abaixo.

Scope

• As etapas para migração off-line, descritas nas seções subsequentes, são aplicáveis apenas a datastores VMFS6.
• As etapas abrangem aspectos funcionais da migração e não abrangem características de desempenho das cargas de trabalho após a migração.
• A validação de escala (número de migrações simultâneas etc.) ou limites (máximo de caminhos por dispositivo, máximo de VMDKs por VM etc.) não está no escopo.
• Os termos dispositivo, volume e LUN são usados de forma intercambiável no documento.
• A migração off-line exige que todas as VMs no datastore VMFS sejam desligadas antes de iniciar.  

Etapas da migração off-line

A migração off-line de um datastore VMFS6 de SCSI para NVMe consiste em três fases. Cada fase pode envolver várias verificações ou etapas.

Pré-migração

Essa fase preparatória inclui verificações para entender as características do ambiente e os recursos que estão em uso. Essa fase é necessária para determinar se a migração off-line é viável no ambiente e também para entender o impacto após a migração. Algumas das verificações importantes estão listadas abaixo. Esta não é uma lista completa, mas abrange as verificações mais comuns em um ambiente padrão do cliente.

Verifique o modo de bloqueio do volume VMFS.

Primeiro, certifique-se de que a LUN seja compatível com o modo ATS. A migração deve ser tentada somente se o datastore VMFS6 estiver usando o modo de bloqueio somente ATS e não usar reservas SCSI-2. 

Para determinar o modo de bloqueio de um determinado volume, execute o comando esxcli storage vmfs lockmode list -l <volume name/label> em um host do ESXi com acesso ao datastore. A migração off-line só será compatível se o modo de bloqueio do volume VMFS6 for "ATS". O modo "ATS+SCSI" não é compatível.

Um exemplo de um volume compatível com migração off-line:

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 Verifique se existe algum vmdk de qualquer VM no datastore selecionado é usado como um RDM (físico ou virtual)

Se uma VM no datastore selecionado tiver um RDM no modo SCSI, não será permitido migrar para o NVMe. Não há nenhum comando VMware para detectar se uma VM tem um RDM, no entanto, o plug-in Dell VSI lista o tipo de disco para cada VM. Veja abaixo uma captura de tela da visualização no VSI que listará se alguma VM (nome de tempo de execução) tem um RDM.

 

Se uma VM tiver um RDM, ele deverá ser removido da VM, convertido ou movido para outro datastore antes da migração.

1.3 Verifique claim rules/settings mapeamento para o dispositivo que hospeda o datastore VMFS.

Se houver regras de declaração personalizadas no dispositivo SCSI antes da migração, elas provavelmente não serão aplicadas ao dispositivo quando forem apresentadas usando NVMe. Os dispositivos NVMe não são apresentados com campos de fornecedor e modelo separados quando acessados por meio de consulta. Os campos estão juntos e, portanto, uma nova regra de reivindicação é necessária, se desejado. Além disso, as regras de declaração baseadas em identificadores de dispositivo, por exemplo, World Wide Name (WWN), falharão, pois o identificador SCSI e o identificador NVMe são distintos.
Por padrão, a VMware reivindica dispositivos NVMe recém-apresentados com o plug-in de caminho padrão do HPP.

1.4 Verifique o número de dispositivos e caminhos para cada host do ESXi.

O NVMe dá suporte a menos dispositivos e caminhos do que SCSI para cada host do ESXi. Se o número de dispositivos SCSI exceder os limites de NVMe, não será possível converter todos os datastores no mesmo host do ESXi. Como solução, os clientes podem empregar mais hosts do ESXi ou consolidar datastores antes ou depois da conversão usando o Storage vMotion. 

1. SCSI - 1.024 dispositivos/4.096 caminhos
2. NVMe - 256 dispositivos/2.048 caminhos

1.5 Verifique se há recursos incompatíveis. 

Alguns recursos da VMware não são compatíveis com NVMe no momento. Verifique a capacidade de suporte antes da migração.
Por exemplo, os recursos a seguir não são compatíveis atualmente com o NVMe em execução no ESXi (até a versão 8.0U1). 
 

Recurso	Breve descrição	Observações
Organização por clusters convidados	Recurso de VMDK em cluster que dá suporte a soluções de alta disponibilidade, como o WSFC (Windows Server Failover Cluster)	Não é possível migrar um datastore VMFS com VMDK em cluster habilitado.
SRM	A replicação baseada em array com SRM não é compatível com NVMe.	A migração de datastores envolvidos com a replicação de array do SRM torna a solução inútil.

Nota: A lista acima não é exaustiva. Os clientes devem consultar a documentação específica do array sobre o impacto da migração nos recursos essenciais. 

 

Verifique o possível impacto da pós-migração nos recursos compatíveis.

A falta de integração dos recursos a seguir pode alterar o desempenho de determinadas operações no NVMe em comparação com o SCSI.
 

Recurso	Natureza do impacto	Ações a serem tomadas
Movimentação acelerada por hardware — XCOPY	No momento, não há nenhum comando equivalente a XCOPY. VMware O Data Mover de software será usado em vez disso. Isso pode diminuir o desempenho das operações que normalmente usam o primitivo, como clonagem ou SvMotion.	Nenhuma
Write Same/UNMAP	Se um dispositivo NVMe não for compatível com o equivalente NVMe de zeros de gravação ou unmap, pode haver um impacto sobre o desempenho.	Nenhuma

Migração

Essa fase envolve as etapas para migrar o datastore de SCSI para NVMe.

Desligue todas as VMs e cancele o registro

Desligue e cancele o registro de todas as VMs hospedadas no datastore a ser migrado. Certifique-se de não excluí-los, apenas cancele o registro.

Desmonte o volume VMFS de todos os hosts

Desmonte o volume VMFS de todos os hosts do ESXi depois que todas as VMs tiverem o registro cancelado. Isso é para garantir que ele não esteja em uso quando a verificação de consistência e a migração são executadas. 

Verifique a consistência dos metadados do volume VMFS.

Antes de iniciar a migração, verifique a consistência dos metadados em disco do VMFS. Isso garante que não haja inconsistências antes do início.

1. Execute VOMA (VMware On-Disk Metadata Analyzer) no modo de verificação executando:

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

Onde:
DEVICE é o dispositivo SCSI que hospeda o volume VMFS6 que está sendo migrado.
PARTITION é o número da partição na qual o volume VMFS está formatado no dispositivo.
OUTPUT FILE é o caminho absoluto do arquivo no qual a saída do comando deve ser salva. Este arquivo pode ser localizado em /tmp se ele tiver espaço suficiente ou qualquer volume VMFS diferente do que está sendo migrado.

Por exemplo:

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

O resultado deve ser semelhante ao seguinte:
 

[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 o comando receber o seguinte erro, o VMFS não será desmontado corretamente:

VOMA failed to check device: Dispositivo ou recurso ocupado

2. Analise o arquivo de saída para ver se há alguma inconsistência de metadados relatada por voma. Se houver, então eles devem ser resolvidos executando voma No modo de correção avançado antes de continuar. Por exemplo:

[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. Colete e salve o dump de metadados do VMFS. Isso será necessário se alguma inconsistência de metadados for vista em etapas subsequentes. 

Consulte https://docs.vmware.com/en/VMware-vSphere/8.0/vsphere-storage/GUID-6F991DB5-9AF0-4F9F-809C-B82D3EED7DAF.html para obter mais detalhes sobre como usar voma Em cheque, Advanced Fix Mode ou Dump mode.

Desconectar a LUN SCSI dos hosts do ESXi

Desconecte a LUN SCSI de cada host do ESXi no VC. Consulte o artigo da base de conhecimento https://kb.vmware.com/s/article/2004605 para obter as etapas detalhadas.

Pare de apresentar a LUN SCSI do array.

As etapas para cancelar a apresentação da LUN SCSI são específicas para o storage array. Os clientes devem consultar a documentação específica do array sobre o procedimento.

Apresente o dispositivo como NVMe a um host do ESXi.

As etapas para reapresentar o dispositivo usando o NVMe são específicas do storage array. Os clientes devem consultar a documentação específica do array sobre o procedimento. 

Inicie a nova varredura do dispositivo no host.

Depois que o dispositivo é apresentado ao host do ESXi usando NVMe, a detecção geralmente é imediata. No entanto, se o dispositivo não aparecer, examine novamente um ou mais adaptadores usando a interface do usuário do vSphere ou a CLI:
 

esxcli storage core adapter rescan -a

Verifique a consistência de metadados do volume VMFS após a conversão.

No host do ESXi que tem acesso ao dispositivo, execute novamente voma no modo de verificação para confirmar se os metadados em disco do VMFS ainda são consistentes. Todas as inconsistências de metadados devem ser investigadas antes de continuar. 
A Voma usa o comando de reserva SCSI-2 para bloquear o dispositivo a fim de impedir qualquer acesso simultâneo ou modificação do volume VMFS quando a sessão voma está ativa. No entanto, os dispositivos NVMe não são compatíveis com o equivalente a uma reserva SCSI-2. Para contornar isso, o usuário deve passar a "-N" opção para VOMA quando o dispositivo de back-end é NVMe. Por exemplo:

• Execute o VOMA (VMware On-Disk Metadata Analyzer) no modo de verificação executando:

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

Selecione um número de 0-1:
Isso é para notificar que é responsabilidade do usuário impedir que o volume seja montado ou acessado simultaneamente de outros hosts enquanto a sessão voma atual estiver em andamento. Se as etapas descritas neste documento tiverem sido seguidas e o dispositivo tiver sido mapeado e detectado em apenas um host do ESXi, será seguro prosseguir. O usuário deve digitar "0" no prompt para continuar com o modo de verificação de voma. Segue um exemplo:
 

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

Executando o VMFS Checker versão 2.1 no modo
de verificação Inicializando metadados do LVM, verificações básicas são feitas
Verificando a atividade
do file system O suporte de reserva não está presente para a atividade st de dispositivos NVMe (4.096 bytes/HB, 1.024 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

 

Assine novamente o volume VMFS 

Agora que o dispositivo é apresentado como NVMe, é necessário atualizar a assinatura que está no datastore. Isso ocorre porque a assinatura atual é baseada, em parte, no WWN do dispositivo quando apresentado usando SCSI. Como o ID do dispositivo NVMe é diferente, uma nova assinatura deve ser gerada. Portanto, no mesmo host do ESXi que foi usado nas duas etapas anteriores, execute o seguinte para reassinar o volume:

1. Embora redundante, verifique novamente o file system executando o comando:

Verificação nova do sistema de arquivos de armazenamento ESXCLI

2. Em seguida, execute o seguinte comando para obter uma lista de LUNs de snapshot VMFS:

Lista de snapshots

do ESXCLI Storage VMFS O dispositivo NVMe recém-apresentado deve estar presente, embora, dependendo do ambiente, possa haver outros snapshots não relacionados a esse processo.

3. Assine novamente o volume VMFS executando o seguinte:

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

 

Veja um exemplo abaixo:

[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

Renomear o datastore VMFS (opcional)

Quando um volume VMFS é assinado novamente, o rótulo do volume VMFS tem como prefixo a marca "snap" seguida por uma string alfanumérica. Por exemplo, o datastore VMFS na etapa anterior agora é nomeado: snap-5c42a2bc-Temp_Datastore. Se desejado, renomeie o datastore de volta para o nome original, removendo o prefixo.

Verifique a consistência dos metadados do volume VMFS após uma nova assinatura.

Mais uma vez, confirme se os metadados do VMFS em disco são consistentes após uma nova assinatura. Execute o voma no modo de verificação no volume VMFS. Consulte a seção 2.8 para obter a linha de comando voma, que deve incluir o indicador "-N". Verifique se a voma está relatando alguma inconsistência. Prossiga se a voma não relatar nenhum erro. 

Apresente o dispositivo como NVMe a todos os hosts do ESXi no cluster.

Se não houve problemas em nenhuma das etapas anteriores, agora, o dispositivo pode ser apresentado usando NVMe a todos os hosts do ESXi no cluster. Conforme observado, os dispositivos NVMe são reconhecidos imediatamente, mas, se não, examine novamente os adaptadores por meio da interface do usuário ou da CLI do vSphere. Verifique se o volume VMFS6 está montado e acessível em todos os hosts.

Registre e ligue todas as VMs

Registre todas as VMs hospedadas no datastore e ligue-as. Verifique se as VMs estão sendo inicializadas com sucesso e se conseguem acessar os vmdks. Como prática recomendada, o usuário pode registrar e ligar VMs em um único ESXi. Depois de bem-sucedidos, eles poderiam ser migrados para outros hosts.

Nota: Ao ligar as VMs a partir da interface do usuário do vCenter, pode haver uma janela pop-up como a mostrada abaixo. Isso solicita que o usuário registre se a VM foi copiada ou movida. Selecione "I Copied" no pop-up.

 

Pós-migração

Verifique se há algum impacto sobre os principais recursos e faça uma limpeza, se necessário. 

 

Esse é um processo oficialmente verificado pela VMware para migração de datastore off-line. Migrações on-line de VMs individuais podem ser realizadas usando o Storage vMotion. A VMware não tem um artigo da KB separado para esse 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