As mudanças de licenciamento do VMware reacenderam uma pergunta que muita equipe vinha adiando: e se eu saísse dessa dependência? A boa notícia é que migrar para o Proxmox VE é um caminho conhecido. A notícia realista é que fazer isso bem exige planejamento — não improviso.

Este guia mostra como estruturar a migração para que a operação continue rodando enquanto você troca a base.

Antes de mover qualquer VM: inventário e diagnóstico

Migração ruim começa quando alguém pula esta etapa. Antes de tocar em produção, você precisa de um retrato fiel do ambiente atual:

• Quantas VMs, com quais recursos (vCPU, RAM, disco) e qual criticidade.
• Dependências entre sistemas — o que não pode cair junto.
• Requisitos de rede: VLANs, IPs, firewall, latência.
• Janelas de manutenção possíveis para cada serviço.
• Sistema operacional e modo de boot de cada VM (BIOS legado ou UEFI).
• Consumo real medido, não o alocado — é comum encontrar VMs com o dobro da CPU que usam.

Esse inventário define a ordem de migração: começa-se pelo que é menos crítico, valida-se o processo, e só então avança-se para os sistemas sensíveis.

Aproveite o levantamento para uma limpeza honesta. Quase todo ambiente tem VMs desligadas há meses, ambientes de teste esquecidos e discos órfãos. Migrar lixo custa tempo, espaço e risco — o inventário é a hora de decidir o que simplesmente não vai.

Dimensionar o destino corretamente

Um erro comum é reproduzir no Proxmox exatamente o hardware que rodava VMware, sem revisar. O Proxmox VE tem características próprias — especialmente se você vai usar Ceph para armazenamento distribuído, que pede mais nós, mais rede e um planejamento específico de disco.

Dimensione CPU, RAM, storage e rede para o comportamento real das cargas, não para o número que estava na planilha antiga. RAM costuma ser o recurso que limita primeiro em ambientes densos.

Duas decisões de projeto merecem atenção especial antes da primeira VM sair do lugar:

• Backend de armazenamento. Ceph hiperconvergente, ZFS local com replicação ou storage externo por NFS/iSCSI resolvem problemas diferentes e têm requisitos diferentes de nós e de rede. Escolher isso no meio da migração é retrabalho garantido.
• Topologia de rede. Bridges, bonding para redundância de link e separação entre rede de gestão, rede de cluster, rede de armazenamento e rede de VMs. Cluster e Ceph em interface compartilhada com tráfego de produção é a receita conhecida de instabilidade difícil de diagnosticar.

Como as VMs realmente migram

Existem caminhos, e a escolha depende do seu ambiente:

1. Importação assistida a partir do ESXi: o Proxmox VE traz um importador nativo que se conecta ao host ou ao vCenter, lista as VMs e traz disco e configuração. É o caminho mais rápido para volume, e funciona com a VM origem desligada no momento da cópia final.
2. Importação direta de disco: para casos pontuais, você copia o VMDK e importa o disco para a VM criada no destino, convertendo para o formato do storage escolhido. Dá mais controle sobre cada detalhe da configuração.
3. Recriação e restauração: cria-se a VM nova no Proxmox, instala-se o sistema limpo e restauram-se apenas os dados a partir do backup. Mais trabalhoso, mas é a oportunidade de deixar para trás anos de configuração acumulada.
4. Replicação no nível da aplicação: bancos de dados, controladores de domínio e serviços em cluster costumam migrar melhor pelos próprios mecanismos — réplica, failover, promoção do nó novo. Downtime medido em segundos, sem copiar disco.

Em ambientes reais, os quatro caminhos convivem. A pergunta não é "qual método usar", e sim "qual método para qual VM".

Windows: o detalhe que faz toda a diferença

Atenção aos drivers: uma VM Windows que vinha do VMware precisa dos VirtIO para render bem no KVM. Pular isso resulta em VM lenta — ou que não inicia — e a impressão errada de que "o Proxmox é pior", quando o problema é driver.

A sequência que evita dor de cabeça:

• Instale os drivers VirtIO ainda no ambiente VMware, antes de mover. O sistema já sobe no destino conhecendo o hardware novo.
• Remova o VMware Tools e instale o qemu-guest-agent, que devolve desligamento gracioso, relato de IP e consistência de snapshot.
• Migre primeiro com controladora compatível e troque para VirtIO SCSI depois que o sistema estiver de pé, se preferir o caminho conservador.
• Confira o modo de boot: VM em UEFI exige OVMF e disco EFI no destino. Migrar UEFI como se fosse BIOS resulta em tela preta.
• Ajuste a placa de rede para VirtIO e revalide IP fixo, rota e DNS.

Linux: menos atrito, mas confira dois pontos

VMs Linux costumam migrar sem drama, desde que:

• O initramfs inclua os módulos VirtIO — caso contrário o sistema não encontra o disco no boot.
• O fstab referencie partições por UUID em vez de caminho de dispositivo, que pode mudar de nome no destino.
• O open-vm-tools saia e o qemu-guest-agent entre.

Validar antes de desligar o antigo

Nunca desligue o ambiente VMware no mesmo dia. O padrão saudável é:

• Migrar em ambiente de validação ou com a VM ainda disponível na origem.
• Testar aplicação, rede, desempenho e backup no destino.
• Só cortar o antigo depois que o novo provou estabilidade.

Manter os dois lados por um período custa um pouco mais, mas é o que separa uma migração tranquila de um fim de semana perdido.

Vale ainda escrever o plano de rollback antes de cada onda: o que exatamente é feito se a VM não subir bem no destino, quem decide voltar, e em quanto tempo. Rollback combinado é decisão técnica; rollback improvisado às três da manhã é aposta.

Checklist de validação por VM

Antes de declarar uma máquina migrada:

1. Sistema inicia sozinho após reboot completo, sem intervenção.
2. Aplicação responde, com teste funcional feito por quem usa o sistema.
3. Desempenho de disco e rede medido e comparado com a linha de base.
4. Agente de convidado ativo, desligamento gracioso funcionando.
5. Monitoramento coletando métricas da VM no ambiente novo.
6. Backup executado no PBS e uma restauração de teste concluída.
7. Documentação atualizada: recursos, IPs, dependências, responsável.

Ordem de execução: migre em ondas

Ondas pequenas e sucessivas superam qualquer tentativa de virada única. Um sequenciamento que funciona:

• Onda 0 — laboratório: cluster montado, storage validado, PBS operante, uma VM descartável migrada de ponta a ponta para calibrar o processo e cronometrar cada etapa.
• Onda 1 — baixo risco: serviços internos, homologação, ferramentas de apoio. É aqui que o time ganha repertório.
• Onda 2 — produção não crítica: sistemas com janela flexível e usuários tolerantes a uma pausa curta.
• Onda 3 — crítico: bancos, ERP, autenticação, o que sustenta receita. Com plano detalhado, janela negociada e rollback pronto.
• Onda 4 — descomissionamento: só depois que tudo está estável, o ambiente antigo é desligado — e apenas depois de confirmar que nenhum backup ou licença depende dele.

O papel do backup na migração

O PBS deve estar operante antes de a primeira VM crítica ir para produção no Proxmox. Migração é justamente o momento de maior risco — é quando você quer ter para onde voltar.

Além disso, manter o backup do ambiente antigo intacto durante toda a transição é regra, não zelo excessivo. A rede de segurança só é útil se existir nos dois lados.

Depois da migração, a operação muda

Concluir a cópia não encerra o projeto. O ambiente novo pede rotinas que precisam existir desde a primeira semana: política de backup com verificação e retenção, HA configurado e testado com queda proposital de nó, monitoramento com alerta que chega a alguém, e um plano de atualização do cluster que não dependa de improviso.

Erros comuns que custam caro

• Cluster de dois nós, sem quórum adequado nem QDevice.
• Rede de cluster e de armazenamento compartilhando a mesma interface física.
• Ceph subdimensionado em número de nós ou em rede.
• Migração de VM Windows sem VirtIO, seguida da conclusão errada sobre desempenho.
• Ambiente antigo desligado antes da primeira restauração de teste no novo.
• Nenhuma janela de estabilização entre a última onda e o descomissionamento.

Onde a Solvefy/Cloud entra

Somos parceiros oficiais Proxmox e conduzimos migrações do VMware do diagnóstico à sustentação: inventário, dimensionamento, execução em lote, validação e a rede de segurança do backup. A operação continua enquanto trocamos a base por baixo dela.

Está avaliando sair do VMware? Faça um diagnóstico gratuito da sua infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.