Compartilhar via

Preparar-se para migração sem agente do VMware

  • Artigo

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

Observação

Essa documentação do cenário de migração de VMware de ponta a ponta está atualmente em versão prévia. Para obter mais informações sobre como usar as Migrações para Azure, consulte a documentação do produto Migrações para Azure.

Cuidado

Este artigo faz referência ao CentOS, uma distribuição Linux que está em status de fim do serviço (EOL). Considere seu uso e planejamento adequadamente. Para obter mais informações, confira as Diretrizes de Fim do Suporte do CentOS.

Antes de migrar sua VM local para o Azure, talvez você precise fazer algumas alterações para tornar a VM pronta para o Azure. Essas alterações são importantes para garantir que a VM migrada possa ser inicializada com êxito no Azure e a conectividade com a VM do Azure possa ser estabelecida. As Migrações para Azure manipulam automaticamente essas alterações de configuração para as seguintes versões de sistema operacional para Linux e Windows. Esse processo é chamado Hidratação.

Observação

Se uma versão principal de um sistema operacional tiver suporte na migração sem agente, todas as versões secundárias e kernels serão automaticamente compatíveis.

Versões do sistema operacional com suporte 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
  • CentOS Stream
  • 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 em versões de sistemas operacionais não listadas acima. Em um alto nível, essas alterações incluem:

  • Validar a presença dos drivers necessários
  • Habilitar o console serial
  • Definir as configurações de rede
  • Instalar o agente convidado da VM

Processo de hidratação

É necessário fazer algumas alterações na configuração das VMs antes da migração para garantir que as VMs migradas funcionem corretamente no Azure. As Migrações para Azure controlam essas alterações de configuração por meio do processo de hidratação. O processo hidratação é executado apenas para as versões dos sistemas operacionais com suporte do Azure mencionados acima. Antes de migrar, talvez seja necessário executar manualmente as alterações necessárias para outras versões de sistema operacional que não estejam listadas acima. Se a VM for migrada sem as alterações necessárias, a VM poderá não inicializar ou talvez você não tenha conectividade com a VM migrada. O diagrama a seguir mostra que as Migrações para Azure executam o processo hidratação.

Etapas da hidratação

Quando um usuário dispara Migração de Teste ou Migrar, as Migrações para Azure executam o processo de hidratação para preparar a VM local para migração ao Azure. Para configurar o processo hidratação, as Migrações para Azure criam uma VM temporária do Azure e anexam os discos da VM de origem para realizar 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 final migrada final seja criada. A VM temporária será criada com um tipo de sistema operacional similar (Windows/Linux) usando uma das imagens do sistema operacional do marketplace. Se a VM local estiver em execuçã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.

As Migrações para Azure criarão 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, as Migrações para Azure tentarão criar a VM temporária do Azure na rede virtual e na sub-rede fornecida como parte das opções de configurações de destino de replicação.

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

Etapas da migração

Observação

Os discos de VM de hidratação não dão suporte a chaves gerenciadas pelo cliente (CMK). A chave de criptografia gerenciada pela 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. Também é possível usar esta seção como um guia para preparar manualmente as VMs para migração de versões de sistemas operacionais sem suporte para a hidratação.

Alterações realizadas em servidores Windows

  1. Descobrir e preparar o volume do sistema operacional Windows

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

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

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

    • Pesquisa por arquivos do registro Windows\System32\Config\System depois de montar a partição.

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

    • 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 o disco do sistema operacional está corrompido. As Migrações para Azure apresentarão falha no processo de migração com um erro apropriado.

    Observação

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

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

    Depois que os arquivos de volume do sistema operacional de origem forem detectados, o script de preparação carregará o hive do registro do SISTEMA 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ê precisará definir essas configurações manualmente se a versão do sistema operacional não tiver suporte para hidratação.

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

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

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

    2. Definir a política de SAN (rede de área de armazenamento) como Todos Online

      Isso verifica se os volumes do Windows na VM do Azure usam as mesmas atribuições de letra da unidade que a VM local. Por padrão, é atribuída a unidade D: às VMs do Azure para uso como armazenamento temporário. Essa atribuição de unidades faz todas as outras atribuições de unidade de armazenamento anexadas serem incrementadas em uma letra. Para evitar essa atribuição automática e verificar se o Azure atribui a próxima letra da unidade livre ao volume temporário, defina a política de SAN (rede de área de armazenamento) como Todos Online.

      Para definir manualmente essa configuração:

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

        Configuração Manual

      • Insira SAN. Se a letra da unidade do sistema operacional convidado não for mantida, Todos Offline ou Compartilhados Offline será retornado.

      • No prompt DISKPART, insira SAN Policy=OnlineAll. Essa configuração garante que os discos sejam colocados online e que você possa fazer leituras e gravações em ambos os discos.

        Política online do Prompt de comando do administrador do diskpart

  3. Definir o tipo de início do 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 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 do DHCP

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

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

  4. Desabilitar Ferramentas do VMware

    Faça com que a inicialização-tipo do serviço "Ferramentas do VMware" seja desabilitada, se existir, pois não é necessário para a VM no Azure.

    Observação

    Para se conectar às VMs do Windows Server 2003, instale o Hyper-V Integration Services na VM do Azure. Os computadores com Windows Server 2003 não têm esse serviço instalado por padrão. Veja este artigo para instalar e preparar para a migração.

  5. Instalar o agente convidado do Azure do Windows

    As Migrações para Azure tentarão instalar o Agente de VM (Máquina Virtual) do Microsoft Azure é um processo seguro e leve que gerencia a interação da máquina virtual (VM) com o Controlador de Malha do Azure. O Agente de VM tem como função primária a 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 instalação e configuração de software. As Migrações para Azure instalam automaticamente o agente de VM do Windows no Windows Server 2008 R2 e versões posteriores.

    O agente de VM do Windows pode ser instalado manualmente com um pacote do Windows Installer. Para instalar manualmente o Agente de VM do Windows, faça o download do instalador do Agente de VM. Você também pode pesquisar uma versão específica nas GitHub Versões do Agente de VM IaaS do para Windows. O Agente de VM tem suporte 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 pesquise pelo nome de processo WindowsAzureGuestAgent.exe. A presença desse processo indica que o agente de VM está instalado. Também é possível usar o PowerShell para detectar do agente de VM.

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

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

Alterações realizadas em servidores Linux

  1. Descobrir e montar partições do sistema operacional Linux

    Antes de executar as alterações de configuração relevantes, o script de preparação validará se o disco do sistema operacional correto foi selecionado para a migração. O script coletará informações sobre todas as partições, suas 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 realizadas nesta etapa:

    • Descobrir a partição /root:
      • Monte cada partição visível e pesquise por etc/fstab.
      • Se os arquivos fstab não forem encontrados, a partição será desmontada e a pesquisa continuará para encontrar a partição correta.
      • Se os arquivos fstab forem encontrados, leia o conteúdo de fstab para identificar o dispositivo raiz e montá-lo como o ponto de montagem base.
    • Descobrir /boot e outras partições do sistema:
      • Use o conteúdo de 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 do conteúdo fstab ou pesquise pela partição, que tem o sinalizador de inicialização.
      • O script prosseguirá para descobrir e montar /boot e outras partições necessárias em "/mnt/azure_sms_root" para criar a árvore do sistema de arquivos raiz necessária para chroot jail. 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 outras.

  2. Descobrir a versão do sistema operacional

    Depois que a partição raiz for descoberta, o script usará os seguintes arquivos para determinar a distribuição e a 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. Instalar o Hyper-V Linux Integration Services e regenerar a imagem do kernel

    A próxima etapa é inspecionar a imagem do kernel e recompilar a imagem de inicialização do Linux para que ela contenha os drivers Hyper-V necessários (hv_vmbus, hv_storvsc, hv_netvsc) no ramdisk inicial. A recompilação da imagem de inicialização verifica se a VM será inicializada no Azure.

    O Azure é executado no hipervisor Hyper-V. Portanto, o Linux exige que determinados módulos do kernel sejam executados no Azure. Para preparar a imagem do Linux, é necessário recompilar o initrd para que pelo menos os módulos do kernel hv_vmbus e hv_storvsc estejam disponíveis no ramdisk inicial. O mecanismo para recriar a imagem initrd ou initramfs pode variar dependendo da distribuição. Consulte a documentação da distribuição ou suporte para o procedimento adequado. Aqui está um exemplo para recompilar o initrd usando o utilitário mkinitrd:

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

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

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

      Observação

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

      Um exemplo ilustrativo para recompilar a initrd

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

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

  4. Habilitar o log do Console Serial do Azure

    Em seguida, o script fará alterações para habilitar o registro em log do Console Serial do Azure. A habilitação do registro em log do console ajuda a solucionar problemas na VM do Azure. Saiba mais sobre o Console Serial do Azure para Linux em Console Serial do Azure para Linux – Máquinas Virtuais | Microsoft Docs.

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

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

    Além disso, é recomendável remover os seguintes parâmetros, se existirem.

    rhgb quiet crashkernel=auto

    Confira este artigo para ver as 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 de udev para evitar a geração de regras estáticas da interface Ethernet. Essas regras causam problemas ao clonar 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 Gerenciador de Rede, se necessário. O Gerenciador de Rede pode interferir no agente do 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 ao executar 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 o arquivo de configuração de NIC eth0 com as configurações de 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 forma:

      Um exemplo ilustrativo para servidores RedHat

         NETWORKING=yes
   HOSTNAME=localhost.localdomain

  6. Validação de Fstab

    As Migrações para Azure validarão as entradas do arquivo fstab e substituirão 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 está anexada.

    • 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 remover marca de comentário dele e reinicializar a VM do Azure.

  7. Instalar o Agente Convidado do Azure

    As Migrações para Azure tentarão instalar o Agente do Linux do Microsoft Azure (waagent), um processo seguro e leve que gerencia o provisionamento do Linux e FreeBSD e a interação da VM com o Controlador de Malha do Azure. Saiba mais sobre a funcionalidade habilitada para implantações de IaaS do Linux e FreeBSD por meio do agente do Linux.

    Examine a lista de pacotes necessários para instalar o agente de VM do Linux. As Migrações do Azure instalam automaticamente o agente de VM do Linux 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 usarem o método de migração do VMware sem agente. Siga estas instruções para instalar manualmente o Agente do Linux para outras versões de sistema operacional.

    Você pode usar o comando para verificar o status do serviço do Agente do Linux do Azure para garantir que ele está em execução. O nome do serviço pode ser walinuxagent ou waagent. Depois que as alterações de hidratação são feitas, o script desmonta todas as partições montadas, desativa os grupos de volumes e, em seguida, libera 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 são executadas, as Migrações para Azure reduzem a VM temporária e libera os discos do sistema operacional anexados (e discos de dados). Isso marca o fim do processo de hidratação.

Depois disso, o disco do sistema operacional modificado 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.

Saiba mais