Partilhar via

Prepare-se para a migração sem agente do VMware

  • Artigo

Este artigo fornece uma visão geral das alterações realizadas quando você migra VMs VMware para o Azure por meio do método de migração sem agente usando a ferramenta Migração e modernização.

Nota

Esta documentação completa do cenário de migração VMware está atualmente em visualização. Para obter mais informações sobre como usar o Azure Migrate, consulte a documentação do produto Azure Migrate.

Atenção

Este artigo faz referência ao CentOS, uma distribuição Linux com status de Fim de Vida (EOL). Por favor, considere o seu uso e planejamento de acordo. Para obter mais informações, consulte as diretrizes de Fim da Vida Útil do CentOS.

Antes de migrar sua VM local para o Azure, você pode precisar de algumas alterações para tornar a VM pronta para o Azure. Essas alterações são importantes para garantir que a VM migrada possa inicializar com êxito no Azure e que a conectividade com a VM do Azure possa ser estabelecida. O Azure Migrate lida automaticamente com essas alterações de configuração para as seguintes versões do sistema operacional para Linux e Windows. Este processo chama-se Hidratação.

Nota

Se uma versão principal de um sistema operacional for suportada na migração sem agente, todas as versões secundárias e kernels serão automaticamente suportados.

Versões do sistema operacional suportadas para hidratação

  • Windows Server 2008 ou posterior
  • Red Hat Enterprise Linux 9.x, 8.x, 7.9, 7.8, 7.7, 7.6, 7.5, 7.4, 7.3, 7.2, 7.1, 7.0, 6.x
  • Fluxo do CentOS
  • SUSE Linux Enterprise Server 15 SP6, 15 SP5, 15 SP4, 15 SP3, 15 SP2, 15 SP1, 15 SP0, 12, 11 SP4, 11 SP3
  • Ubuntu 22.04, 21.04, 20.04, 19.04, 19.10, 18.04LTS, 16.04LTS, 14.04LTS
  • Kali Linux (2016, 2017, 2018, 2019, 2020, 2021, 2022)
  • Debian 11, 10, 9, 8, 7
  • Oracle Linux 9, 8, 7.7-CI, 7.7, 6

Você também pode usar este artigo para preparar manualmente as VMs para migração para o Azure para versões de sistemas operacionais não listadas acima. A um nível elevado, estas alterações incluem:

  • Validar a presença dos drivers necessários
  • Ativar o console serial
  • Configurar as definições de rede
  • Instalar o agente convidado da VM

Processo de hidratação

Você precisa fazer algumas alterações na configuração das VMs antes da migração para garantir que as VMs migradas funcionem corretamente no Azure. O Azure Migrate lida com essas alterações de configuração por meio do processo de hidratação . O processo de hidratação só é realizado para as versões dos sistemas operativos suportados do Azure fornecidas acima. Antes de migrar, talvez seja necessário executar as alterações necessárias manualmente para outras versões do sistema operacional que não estão listadas acima. Se a VM for migrada sem as alterações necessárias, a VM pode não inicializar ou você pode não ter conectividade com a VM migrada. O diagrama a seguir mostra que o Azure Migrate executa o processo de hidratação.

Passos de hidratação

Quando um usuário aciona Testar Migrar ou Migrar, o Azure Migrate executa o processo de hidratação para preparar a VM local para migração para o Azure. Para configurar o processo de hidratação, o Azure Migrate cria uma VM temporária do Azure e anexa os discos da VM de origem para executar alterações para tornar a VM de origem pronta para o Azure. A VM temporária do Azure é uma VM intermediária criada durante o processo de migração antes que a VM migrada final seja criada. A VM temporária será criada com um tipo de sistema operacional semelhante (Windows/Linux) usando uma das imagens do sistema operacional do marketplace. Se a VM local estiver executando o Windows, o disco do sistema operacional da VM local será anexado como um disco de dados à VM temporária para executar alterações. Se for um servidor Linux, todos os discos anexados à VM local serão anexados como discos de dados à VM temporária do Azure.

O Azure Migrate criará a interface de rede, uma nova rede virtual, uma sub-rede e um NSG (grupo de segurança de rede) para hospedar a VM temporária. Esses recursos são criados na assinatura do cliente. Se houver políticas conflitantes que impeçam a criação dos artefatos de rede, o Azure Migrate tentará criar a VM temporária do Azure na rede virtual e na sub-rede fornecidas como parte das opções de configurações de destino de replicação.

Depois que a máquina virtual for criada, o Azure Migrate invocará a Extensão de Script Personalizada na VM temporária usando a API REST da Máquina Virtual do Azure. O utilitário Extensão de Script Personalizado executará um script de preparação contendo a configuração necessária para a prontidão do Azure nos discos de VM locais anexados à VM temporária do Azure. O script de preparação é baixado de uma conta de armazenamento de propriedade do Azure Migrate. As regras do grupo de segurança de rede da rede virtual serão configuradas para permitir que a VM temporária do Azure acesse a conta de armazenamento do Azure Migrate para invocar o script.

Passos da Migração

Nota

Os discos de VM de hidratação não suportam a Chave Gerenciada pelo Cliente (CMK). A Chave Gerenciada da Plataforma (PMK) é a opção padrão.

Alterações realizadas durante o processo de hidratação

O script de preparação executa as seguintes alterações com base no tipo de sistema operacional da VM de origem a ser migrada. Você também pode usar esta seção como um guia para preparar manualmente as VMs para migração para versões de sistemas operacionais não suportadas para hidratação.

Alterações realizadas em servidores Windows

  1. Descubra e prepare o volume do sistema operacional Windows

    Antes de executar alterações de configuração relevantes, o script de preparação validará se o disco correto do sistema operacional foi selecionado para migração. O script de preparação examinará todos os volumes anexados visíveis para o sistema e procurará o caminho do arquivo hive do registro SYSTEM para encontrar o volume do sistema operacional de origem.

    As seguintes ações são executadas nesta etapa:

    • Monta cada partição no disco do sistema operacional conectado à VM temporária.

    • Procura os ficheiros de registo \Windows\System32\Config\System depois de montar a partição.

    • Se os arquivos não forem encontrados, a partição será desmontada e a busca pela partição correta continuará.

    • Se os arquivos não estiverem presentes em nenhuma das partições, isso pode indicar que um disco do sistema operacional incorreto foi selecionado ou que o disco do sistema operacional está corrompido. O Azure Migrate falhará no processo de migração com um erro apropriado.

    Nota

    Esta etapa não será relevante se você estiver preparando manualmente os servidores para migração.

  2. Fazer alterações relacionadas à inicialização e conectividade

    Depois que os arquivos de volume do sistema operacional de origem forem detetados, o script de preparação carregará o hive do Registro SYSTEM no editor do Registro da VM temporária do Azure e executará as seguintes alterações para garantir a inicialização e a conectividade da VM. Você precisa definir essas configurações manualmente se a versão do sistema operacional não for suportada para hidratação.

    1. Validar a presença dos drivers necessários

      Verifique se os drivers necessários estão instalados e definidos para carregar no início da inicialização. Esses drivers do Windows permitem que o servidor se comunique com o hardware e outros dispositivos conectados.

      • IntelIde.sys
      • Atapi
      • Storflt
      • Storvsc
      • VMbus

    2. Definir a política de SAN (Storage Area Network, rede de armazenamento de dados) como Tudo Online

      Isso garante que os volumes do Windows na VM do Azure usem as mesmas atribuições de letra de unidade que a VM local. Por padrão, as VMs do Azure recebem a unidade D: para usar como armazenamento temporário. Essa atribuição de unidade faz com que todas as outras atribuições de unidade de armazenamento anexadas sejam incrementadas em uma letra. Para evitar essa atribuição automática e garantir que o Azure atribua a próxima letra de unidade livre ao seu volume temporário, defina a política de rede de área de armazenamento (SAN) como Online All.

      Para definir manualmente essa configuração:

      • No servidor local, abra o prompt de comando com privilégios elevados e insira diskpart.

        Configuração Manual

      • Entre em SAN. Se a letra da unidade do sistema operacional convidado não for mantida, Offline All ou Offline Shared será retornado.

      • No prompt DISKPART, digite SAN Policy=OnlineAll. Essa configuração garante que os discos sejam colocados online e que você possa ler e gravar em ambos os discos.

        Política online do diskpart do Prompt de Comando do Administrador

  3. Definir o tipo de início DHCP

    O script de preparação também definirá o tipo de início do serviço DHCP como Automático. Isso permitirá que a VM migrada obtenha um endereço IP e estabeleça conectividade pós-migração. Verifique se o serviço DHCP está configurado e se o status está em execução.

    Definir Tipo de Início DHCP

    Para editar as configurações de inicialização do DHCP manualmente, execute o seguinte exemplo no Windows PowerShell:

    Get-Service -Name Dhcp
Where-Object StartType -ne Automatic
Set-Service -StartupType Automatic

  4. Desative o VMware Tools

    Torne o tipo de início do serviço "VMware Tools" desativado se existir, pois eles não são necessários para a VM no Azure.

    Nota

    Para se conectar a VMs do Windows Server 2003, o Hyper-V Integration Services deve ser instalado na VM do Azure. As máquinas Windows Server 2003 não têm isso instalado por padrão. Consulte este artigo para instalar e preparar a migração.

  5. Instalar o Windows Azure Guest Agent

    O Azure Migrate tentará instalar o Agente de Máquina Virtual do Microsoft Azure (Agente de VM), um processo leve e seguro que gerencia a interação da máquina virtual (VM) com o Controlador de Malha do Azure. O Agente de VM tem uma função principal na habilitação e execução de extensões de máquina virtual do Azure que habilitam a configuração pós-implantação da VM, como a instalação e configuração de software. O Azure Migrate instala automaticamente o agente de VM do Windows no Windows Server 2008 R2 e versões superiores.

    O agente da VM do Windows pode ser instalado manualmente com um pacote do Windows Installer. Para instalar manualmente o Agente da VM do Windows, transfira o programa de instalação do Agente da VM. Você também pode procurar uma versão específica nas versões do GitHub Windows IaaS VM Agent. O Agente de VM é suportado no Windows Server 2008 (64 bits) e posterior.

    Para verificar se o Agente de VM do Azure foi instalado com êxito, abra o Gerenciador de Tarefas, selecione a guia Detalhes e procure o nome do processo WindowsAzureGuestAgent.exe. A presença deste processo indica que o agente da VM está instalado. Você também pode usar o PowerShell para detetar o agente de VM.

    Instalação bem-sucedida do Agente de VM do Azure

    Depois que as alterações acima mencionadas forem realizadas, a partição do sistema será descarregada. A VM agora está pronta para migração. Saiba mais sobre as alterações para servidores Windows.

Alterações realizadas em servidores Linux

  1. Descubra e monte partições do sistema operacional Linux

    Antes de executar alterações de configuração relevantes, o script de preparação validará se o disco correto do sistema operacional foi selecionado para migração. O script coletará informações sobre todas as partições, seus UUIDs e pontos de montagem. O script examinará todas essas partições visíveis para localizar as partições /boot e /root.

    As seguintes ações são executadas nesta etapa:

    • Descubra a partição /root:
      • Monte cada partição visível e procure etc/fstab.
      • Se os arquivos fstab não forem encontrados, a partição será desmontada e a busca continuará pela partição correta.
      • Se os arquivos fstab forem encontrados, leia o conteúdo do fstab para identificar o dispositivo raiz e montá-lo como o ponto de montagem base.
    • Descubra /boot e outras partições do sistema:
      • Use o conteúdo fstab para determinar se /boot é uma partição separada. Se for uma partição separada, obtenha o nome do dispositivo da partição de inicialização a partir do conteúdo fstab ou procure a partição, que tem o sinalizador de inicialização.
      • O script continuará a descobrir e montar /boot, e outras partições necessárias em "/mnt/azure_sms_root" para construir a árvore do sistema de arquivos raiz necessária para a prisão chroot. Outras partições necessárias incluem: /boot/grub/menu.lst, /boot/grub/grub.conf, /boot/grub2/grub.cfg, /boot/grub/grub.cfg, /boot/efi (para inicialização UEFI), /var, /lib, /etc, /usr, e outros.

  2. Descubra a versão do SO

    Uma vez que a partição raiz é descoberta, o script usará os seguintes arquivos para determinar a distribuição e versão do sistema operacional Linux.

    • RHEL: etc/redhat-release
    • OL: etc/oracle-release
    • SLES: etc/SuSE-release
    • Ubuntu: etc/lsb-release
    • Debian: etc/debian_version

  3. Instale o Hyper-V Linux Integration Services e regenere a imagem do kernel

    O próximo passo é inspecionar a imagem do kernel e reconstruir a imagem init do Linux para que ela contenha os drivers Hyper-V necessários (hv_vmbus, hv_storvsc hv_netvsc) no ramdisk inicial. A reconstrução da imagem init garante que a VM será inicializada no Azure.

    O Azure é executado no hipervisor Hyper-V. Portanto, o Linux requer certos módulos do kernel para ser executado no Azure. Para preparar sua imagem do Linux, você precisa reconstruir o initrd para que pelo menos os módulos hv_vmbus e hv_storvsc kernel estejam disponíveis no ramdisk inicial. O mecanismo para reconstruir a imagem initrd ou initramfs pode variar dependendo da distribuição. Consulte a documentação ou o suporte da sua distribuição para obter o procedimento adequado. Aqui está um exemplo para reconstruir o initrd usando o utilitário mkinitrd:

    1. Encontre a lista de kernels instalados no sistema (/lib/modules)

    2. Para cada módulo, verifique se os drivers do Hyper-V já estão incluídos.

    3. Se algum desses drivers estiver faltando, adicione os drivers necessários e gere novamente a imagem para a versão correspondente do kernel.

      Nota

      Esta etapa pode não se aplicar a VMs Ubuntu e Debian, pois os drivers Hyper-V são incorporados por padrão. Saiba mais sobre as alterações.

      Um exemplo ilustrativo para a reconstrução do initrd

      • Fazer backup da imagem initrd existente
       cd /boot
 sudo cp initrd-`uname -r`.img  initrd-`uname -r`.img.bak
      • Reconstrua o initrd com os módulos hv_vmbus e hv_storvsc kernel:
         sudo mkinitrd --preload=hv_storvsc --preload=hv_vmbus -v -f initrd-`uname -r`.img `uname -r`

    A maioria das novas versões de distribuições Linux tem isso incluído por padrão. Se não estiver incluído, instale manualmente para todas as versões, exceto as chamadas, usando as etapas acima mencionadas.

  4. Habilitar o log do Console Serial do Azure

    O script fará alterações para habilitar o log do Console Serial do Azure. Habilitar o log do console ajuda a solucionar problemas na VM do Azure. Saiba mais sobre o Azure Serial Console para Linux Azure Serial Console para Linux - Máquinas Virtuais | Documentos Microsoft.

    Modifique a linha de inicialização do kernel no GRUB ou GRUB2 para incluir os seguintes parâmetros, para que todas as mensagens do console sejam enviadas para a primeira porta serial. Essas mensagens podem ajudar o suporte do Azure com a depuração de quaisquer problemas.

     console=ttyS0,115200n8 earlyprintk=ttyS0,115200 rootdelay=300

    Também recomendamos remover os seguintes parâmetros, se existirem.

    rhgb quiet crashkernel=auto

    Consulte este artigo para obter alterações específicas.

  5. Alterações de rede para conectividade

    Com base na versão do sistema operacional, o script executará as alterações de rede necessárias para conectividade com a VM migrada. As alterações incluem:

    1. Mova (ou remova) as regras do udev para evitar a geração de regras estáticas para a interface Ethernet. Essas regras causam problemas quando você clona uma máquina virtual no Azure.

      Um exemplo ilustrativo para servidores RedHat

         sudo ln -s /dev/null /etc/udev/rules.d/75-persistent-net-generator.rules
   sudo rm -f /etc/udev/rules.d/70-persistent-net.rules

    2. Remova o Network Manager, se necessário. O Network Manager pode interferir com o agente Linux do Azure para algumas versões do sistema operacional. É recomendável fazer essas alterações para servidores que executam distribuições RedHat e Ubuntu.

    3. Desinstale este pacote executando o seguinte comando:

      Um exemplo ilustrativo para servidores RedHat

         sudo rpm -e --nodeps NetworkManager

    4. Faça backup das configurações de NIC existentes e crie um arquivo de configuração de NIC eth0 com as configurações DHCP. Para fazer isso, o script criará ou editará o arquivo /etc/sysconfig/network-scripts/ifcfg-eth0 e adicionará o seguinte texto:

      Um exemplo ilustrativo para servidores RedHat

         DEVICE=eth0
   ONBOOT=yes
   BOOTPROTO=dhcp
   TYPE=Ethernet
   USERCTL=no
   PEERDNS=yes
   IPV6INIT=no
   PERSISTENT_DHCLIENT=yes
   NM_CONTROLLED=yes

    5. Redefina o arquivo etc/sysconfig/network da seguinte maneira:

      Um exemplo ilustrativo para servidores RedHat

         NETWORKING=yes
   HOSTNAME=localhost.localdomain

  6. Validação Fstab

    O Azure Migrate validará as entradas do arquivo fstab e substituirá as entradas fstab por identificadores de volume persistentes, UUIDs sempre que necessário. Isso garante que o nome da unidade/partição permaneça constante, independentemente do sistema ao qual esteja conectado.

    • Se o nome do dispositivo for um nome de dispositivo padrão (digamos /dev/sdb1), então:
      • Se for uma partição raiz ou de inicialização, ela será substituída por UUID.
      • Se a partição coexistir com a partição raiz ou de inicialização como partições padrão no mesmo disco, ela será substituída por UUID.
    • Se o nome do dispositivo for UUID/LABEL/LV, nenhuma alteração será feita.
    • Se for um dispositivo de rede (nfs, cifs, smbfs e etc), o script comentará a entrada. Para acessá-lo, você pode descomentar o mesmo e reiniciar sua VM do Azure.

  7. Instalar o Linux Azure Guest Agent

    O Azure Migrate tentará instalar o Agente Linux do Microsoft Azure (waagent), um processo leve e seguro que gerencia o provisionamento do Linux & FreeBSD e a interação da VM com o Azure Fabric Controller. Saiba mais sobre a funcionalidade habilitada para implantações de IaaS Linux e FreeBSD através do agente Linux.

    Analise a lista de pacotes necessários para instalar o agente de VM do Linux. O Azure Migrate instala o agente de VM Linux automaticamente para RHEL 9.x, 8.x/7.x/6.x, Ubuntu 14.04/16.04/18.04/19.04/19.10/20.04, SUSE 15 SP0/15 SP1/12, Debian 9/8/7 e Oracle 7/6 ao usar o método sem agente de migração VMware. Siga estas instruções para instalar o Agente Linux manualmente para outras versões do sistema operacional.

    Você pode usar o comando para verificar o status do serviço do Agente Linux do Azure para garantir que ele esteja em execução. O nome do serviço pode ser walinuxagent ou waagent. Uma vez que as mudanças de hidratação são feitas, o script irá desmontar todas as partições montadas, desativar grupos de volume e, em seguida, liberar os dispositivos.

       sudo vgchange -an <vg-name>
   sudo lockdev –flushbufs <disk-device-name>

    Saiba mais sobre as alterações para servidores Linux.

Limpar a VM temporária

Depois que as alterações necessárias forem executadas, o Azure Migrate desativará a VM temporária e liberará os discos do sistema operacional anexados (e os discos de dados). Isso marca o fim do processo de hidratação.

Depois disso, o disco modificado do sistema operacional e os discos de dados que contêm os dados replicados são clonados. Uma nova máquina virtual é criada na região de destino, na rede virtual e na sub-rede, e os discos clonados são anexados à máquina virtual. Isso marca a conclusão do processo de migração.

Mais informações