Do Hyper-V para o Proxmox: o caminho e as armadilhas

A migração do Hyper-V para o Proxmox é tecnicamente mais simples do que a do VMware, e tem um conjunto próprio de armadilhas — quase todas relacionadas ao fato de que a maioria das VMs é Windows, e Windows não gosta de trocar de hardware virtual sem preparação.

A regra que resume o artigo inteiro: prepare a VM antes de movê-la, não depois. Quase todo problema desta migração vem de inverter essa ordem.

O inventário, antes de qualquer conversão

Levante para cada VM:

• Sistema operacional e versão. Windows antigo tem tratamento próprio.
• Geração da VM no Hyper-V. Geração 1 usa BIOS; geração 2 usa UEFI, e isso precisa corresponder no destino.
• Discos: quantos, tamanho, fixo ou dinâmico, e onde estão.
• Rede: quais switches virtuais, quais VLANs, endereços fixos ou por DHCP.
• Serviços de integração instalados.
• Recursos especiais: disco de passagem, placa dedicada, chave de proteção por USB.
• Dependências: quem conversa com quem, o que roda naquela VM.
• Janela aceitável de indisponibilidade para aquela carga.
• Licenças vinculadas ao hardware ou ao identificador da máquina.

O último item causa mais retrabalho do que o esperado: softwares que licenciam pelo identificador da máquina ou pelo endereço MAC vão pedir reativação. Levante isso antes e tenha as chaves em mãos.

A preparação: o que fazer com a VM ainda no Hyper-V

Esta é a parte que define o resultado. Com a VM ainda rodando na origem:

1. Backup completo e validado. Sempre o primeiro passo.
2. Anotar a configuração de rede — endereço, máscara, gateway, DNS. Ao trocar a placa virtual, o Windows cria uma interface nova e a configuração antiga fica associada a um adaptador que não existe mais. Ter isso anotado economiza um acesso por console desconfortável.
3. Instalar os drivers VirtIO enquanto a VM ainda está no Hyper-V. Eles ficam disponíveis para o Windows carregar quando o hardware mudar. É o passo que mais evita tela azul no primeiro boot.
4. Ajustar o carregamento do driver de disco, garantindo que o Windows consiga iniciar com a controladora nova. Sem isso, o sistema não encontra o disco de boot e falha no primeiro arranque.
5. Desinstalar os serviços de integração do Hyper-V. Eles não servem no destino e podem causar conflito.
6. Desabilitar software que amarra ao hardware — agentes de backup do Hyper-V, ferramentas do fabricante.
7. Desligar a VM ordenadamente. Não exporte disco de VM ligada.

Para VMs Linux, a preparação é bem mais simples: os drivers VirtIO já estão no kernel. O cuidado é com referências a dispositivos por nome antigo na configuração de inicialização e de rede — prefira identificação por rótulo ou identificador único.

A conversão do disco

O Hyper-V usa VHDX (ou VHD, em ambientes antigos). O Proxmox trabalha com qcow2 e raw.

O caminho usual é converter o arquivo de disco para o formato de destino e importá-lo na VM criada no Proxmox. A operação é direta e o principal cuidado é espaço em disco: você precisa de espaço para a origem e para o destino simultaneamente, e disco dinâmico pequeno no Hyper-V pode virar arquivo muito maior se convertido sem atenção ao formato.

Vale planejar também a banda e o tempo: copiar vários terabytes pela rede é a etapa mais longa do projeto e precisa caber na janela. Para volumes grandes, uma opção é copiar o disco antes, com a VM ainda ligada, e fazer uma cópia incremental final durante a janela — o que reduz a parada ao essencial.

Criar a VM no Proxmox: as escolhas que importam

A linha do BIOS é a causa número um de "a VM não inicia depois da migração". Geração 2 no Hyper-V significa UEFI, e criar a VM com BIOS legado no Proxmox produz um disco que não arranca.

O primeiro boot e o que fazer depois

1. Iniciar e acompanhar pelo console. Se houver tela azul por driver de disco, a preparação do passo 4 não foi feita — e a correção é possível, mas é bem mais trabalhosa com a VM já migrada.
2. Instalar o pacote completo de drivers VirtIO, se ainda não estava.
3. Instalar o agente de convidado e confirmar que o Proxmox mostra o endereço da VM.
4. Reconfigurar a rede. O Windows vê uma placa nova; aplique a configuração anotada.
5. Remover dispositivos ocultos referentes ao hardware antigo, que permanecem registrados e podem segurar a configuração de endereço.
6. Reativar o que pedir ativação.
7. Validar a aplicação, não apenas o sistema. Serviço respondendo, integração funcionando, usuário conseguindo usar.
8. Ajustar memória e núcleos ao uso real, aproveitando a oportunidade — muita VM migrada carrega superdimensionamento antigo.

O roteiro de ondas

Migrar tudo em um fim de semana é receita para problema. O que funciona:

Onda 0 — piloto. Uma VM sem importância, de preferência com o mesmo sistema operacional do grosso do parque. O objetivo é medir tempo e descobrir os problemas do procedimento. Cronometre cada etapa.

Onda 1 — baixo impacto. Homologação, ferramentas internas, servidores secundários. Volume suficiente para consolidar o procedimento.

Onda 2 — produção não crítica. Cargas importantes com janela flexível.

Onda 3 — crítico. Por último, com o procedimento maduro, tempos conhecidos e a equipe confiante.

Entre as ondas, revise o procedimento com o que foi aprendido. E mantenha o ambiente Hyper-V de pé até o fim — ele é o seu plano de volta.

O plano de volta

Enquanto a VM original existe desligada no Hyper-V, voltar é simples: religa lá e redireciona. A janela de rollback se fecha quando a VM migrada começa a receber escrita que importa.

Defina antes:

• Por quanto tempo a origem fica intacta. Semanas, não dias.
• Critério de abortar para cada VM — o que caracteriza falha da migração.
• Quem decide, nomeado.
• Como o tráfego volta: DNS com tempo de vida reduzido, ou reconfiguração conhecida.

E reduza o tempo de vida dos registros DNS dias antes da janela. É a preparação mais barata e a mais esquecida.

Coexistência durante a transição

Por semanas ou meses, os dois ambientes vão conviver. O que precisa estar resolvido:

• Rede. VMs no Proxmox e no Hyper-V precisam se enxergar, nas mesmas VLANs. Planeje isso antes da primeira onda.
• Active Directory. Controladores de domínio merecem cuidado especial: migre um por vez, confirmando a replicação entre eles antes de seguir. Nunca migre todos simultaneamente.
• Backup. Durante a transição você opera dois esquemas. Confirme que nada ficou sem cobertura no meio.
• Monitoramento cobrindo os dois ambientes.

Erros comuns

• Não instalar os drivers VirtIO antes de mover a VM.
• Não preparar o carregamento do driver de disco, e ter tela azul no primeiro boot.
• Criar a VM com BIOS legado quando a origem era geração 2.
• Esquecer o disco EFI em VM com UEFI.
• Não anotar a configuração de rede antes de trocar a placa virtual.
• Manter os serviços de integração do Hyper-V instalados.
• Exportar disco de VM ligada.
• Não calcular espaço para origem e destino simultaneamente.
• Subestimar o tempo de cópia de discos grandes.
• Migrar todos os controladores de domínio de uma vez.
• Não reduzir o tempo de vida do DNS com antecedência.
• Apagar as VMs de origem logo após a migração.
• Migrar tudo em uma única janela, sem piloto.
• Não instalar o agente de convidado, e ficar com backup inconsistente.
• Supor que trocar de hipervisor elimina a licença do Windows.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, conduzimos migrações a partir do Hyper-V de ponta a ponta: inventário com mapeamento de dependências e licenças, preparação das VMs na origem com drivers e ajustes de boot, conversão e importação, criação das VMs com as escolhas corretas de firmware e controladora, validação de aplicação, planejamento das ondas com tempos medidos no piloto, coexistência de rede entre os dois ambientes e plano de volta com critérios escritos. E aproveitamos a migração para corrigir o superdimensionamento acumulado, que costuma devolver capacidade significativa.

Vai sair do Hyper-V e não sabe por onde começar? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.