Migração ao vivo no Proxmox: o que precisa estar certo antes

Mover uma máquina virtual ligada de um nó para outro sem derrubá-la é o recurso que transforma manutenção em rotina. Sem ele, atualizar o firmware de um servidor vira janela noturna e comunicado a cliente. Com ele, você esvazia o nó durante o expediente, faz o serviço e devolve as VMs.

O Proxmox faz isso bem. O problema é que a migração ao vivo tem pré-requisitos que só aparecem quando falham — e o momento em que você descobre costuma ser exatamente aquele em que precisa esvaziar um nó com urgência.

Como funciona, em uma frase

O Proxmox copia a memória da VM para o nó de destino enquanto ela continua rodando, acompanha as páginas que mudam durante a cópia, repete o processo com o que sobrou e, quando o resíduo fica pequeno o suficiente, congela a VM por uma fração de segundo, transfere o restante e retoma no destino.

Dessa mecânica derivam todos os requisitos. Entendida a mecânica, os problemas deixam de ser misteriosos.

Os três pré-requisitos

1. O disco precisa estar acessível no destino

É o requisito mais óbvio e o mais decisivo.

Com storage compartilhado — Ceph, NFS, iSCSI com LVM, Fibre Channel — o disco já está lá. Só a memória viaja, e a migração é rápida.

Com storage local — ZFS local, LVM local, diretório —, o Proxmox precisa copiar o disco junto. Isso funciona, e é um recurso muito útil, mas muda a escala do tempo: uma VM com 500 GB de disco em rede de 10 Gbps leva vários minutos no melhor caso, e o disco continua sendo escrito durante a cópia.

Se o desenho é de storage local com replicação ZFS entre nós, a migração aproveita a réplica existente e transfere apenas a diferença — o que reduz drasticamente o tempo. É um dos melhores argumentos a favor de configurar a replicação mesmo quando o failover automático não é o objetivo principal.

2. A CPU do destino precisa oferecer o que a VM está usando

Este é o requisito que mais causa falha inesperada, e ele merece ser entendido em vez de contornado.

A VM enxerga um conjunto de instruções da CPU. Se ela foi iniciada em um nó com processador moderno e está usando instruções que o processador do destino não tem, a migração falha — ou, pior, a VM trava depois de migrar.

O Proxmox oferece tipos de CPU para a VM, e a escolha tem consequência direta:

A regra prática para cluster:

• Cluster homogêneo, com todos os nós no mesmo modelo de processador: host é seguro e entrega o melhor desempenho.
• Cluster heterogêneo, com gerações diferentes: escolha um modelo comum compatível com o nó mais antigo. Perde-se pouco desempenho e ganha-se a liberdade de migrar qualquer VM para qualquer nó.

E o detalhe que pega: mudar o tipo de CPU exige desligar e ligar a VM. Não basta reiniciar pelo sistema operacional convidado — o processo precisa ser recriado. Ou seja, se você descobrir isso no dia da manutenção, vai precisar da parada que estava tentando evitar.

Se o cluster vai crescer com hardware novo ao longo dos anos — e vai —, definir um modelo de CPU comum desde o começo é a decisão que evita esse problema para sempre.

3. A rede precisa dar conta

A memória da VM atravessa a rede. Uma VM com 64 GB de RAM move 64 GB, mais as páginas que mudarem durante a transferência.

Em 1 Gbps, isso é da ordem de dez minutos no melhor caso — e provavelmente não termina. Em 10 Gbps, é da ordem de um minuto.

O ponto crítico não é só a velocidade média: é a relação entre a taxa de transferência e a taxa com que a VM suja páginas de memória. Se a aplicação escreve na memória mais rápido do que a rede consegue copiar, a migração nunca converge — o resíduo não diminui. É o que acontece com bancos de dados grandes e ativos em rede subdimensionada.

Recomendações que resolvem:

• Rede de migração separada da rede de VM e da rede de storage. O Proxmox permite definir qual rede usar para migração, e usar essa configuração é importante: migração saturando a rede de storage degrada todas as VMs do cluster.
• 10 Gbps como piso para cluster com VMs de memória grande.
• Migração com compressão, quando a rede é o gargalo — troca CPU por banda, e costuma valer.

Quando a migração ao vivo não é possível

Algumas configurações prendem a VM ao nó, e é bom saber quais antes de depender delas:

• Dispositivo físico repassado — GPU, placa PCI, controladora USB. O hardware está naquele servidor; não há como levá-lo junto. VM com GPU passthrough migra apenas desligada.
• Disco local não replicado e muito grande, quando a janela não comporta a cópia.
• CPU com tipo `host` entre nós de gerações diferentes.
• Recursos específicos do nó referenciados na configuração da VM — um diretório local, uma bridge que só existe ali.

Para dispositivos repassados existe uma alternativa parcial: a migração a frio, desligando e ligando no destino, que é rápida se o disco é compartilhado. Vale planejar essas VMs como exceções documentadas — todo mundo precisa saber que aquela máquina não sai do lugar sem parar.

O teste que vale fazer antes de precisar

Migração ao vivo não deveria ser exercitada pela primeira vez durante uma emergência. Um teste simples, feito uma vez por trimestre:

1. Escolha o nó mais cheio.
2. Coloque-o em modo de manutenção, para o Proxmox migrar automaticamente as VMs gerenciadas por HA.
3. Migre manualmente o que restar.
4. Cronometre. Esse número é o seu tempo real de esvaziamento de nó, e é o que define se a manutenção cabe na janela.
5. Anote as VMs que falharam e por quê.
6. Devolva as VMs e corrija as causas.

Quem faz esse teste descobre, sem pressão, as três ou quatro VMs com tipo de CPU errado ou disco local esquecido — e corrige na próxima janela de reinício, em vez de na emergência.

Migração entre clusters diferentes

Um caso que aparece em consolidação e em migração de datacenter: mover VM de um cluster para outro. O Proxmox tem suporte a isso, com a ressalva de que não é o mesmo caminho da migração dentro do cluster e exige atenção a identificadores duplicados de VM, nomes de storage e configuração de rede no destino.

Para volume grande, o caminho mais previsível costuma ser por backup e restauração no destino, com a VM parada durante a janela — mais lento, e muito mais fácil de reverter se algo der errado.

Erros comuns

• Descobrir o problema de tipo de CPU no dia da manutenção urgente.
• Usar host em cluster com processadores de gerações diferentes.
• Não perceber que mudar o tipo de CPU exige desligar e ligar a VM.
• Migração usando a mesma rede do storage, degradando o cluster inteiro.
• Rede de 1 Gbps com VMs de memória grande, e migração que não converge.
• Storage local sem replicação, com cópia de disco inteira a cada migração.
• Não documentar quais VMs não migram por causa de dispositivo repassado.
• Nunca testar o esvaziamento de um nó e não saber quanto tempo leva.
• Contar com migração ao vivo para VM que tem recurso exclusivo do nó na configuração.
• Migrar tudo de uma vez e saturar a rede, em vez de escalonar.

O que isso habilita

Cluster com migração ao vivo confiável muda a operação inteira:

• Atualização de firmware e de Proxmox durante o expediente, nó a nó.
• Troca de hardware com falha iminente sem parada para o cliente.
• Rebalanceamento de carga quando um nó fica pesado.
• Manutenção física sem comunicado de indisponibilidade.

É o recurso que transforma o cluster de "conjunto de servidores" em "capacidade fungível". Vale garantir que ele funcione antes de contar com ele.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, preparamos o cluster para que a migração funcione sempre: definição do tipo de CPU compatível com o crescimento do parque, rede de migração separada e dimensionada, replicação ZFS onde o storage é local, inventário das VMs que não migram e por quê, e o teste de esvaziamento de nó cronometrado — para você saber quanto tempo dura a sua janela de manutenção antes de precisar dela.

Você consegue esvaziar um nó agora, sem parar nada? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.