Live migration é a capacidade de mover uma máquina virtual de um host físico para outro enquanto ela continua executando, sem que as aplicações dentro dela percebam a transição. É uma das funcionalidades mais importantes da virtualização enterprise — sem ela, qualquer manutenção de hardware exigiria downtime de aplicação.
O problema que a live migration resolve
Pense na situação: você tem um cluster com 8 hosts físicos rodando 60 VMs de produção. Um dos hosts precisa de atualização de firmware — um procedimento que exige reboot do servidor. No mundo pré-virtualização, isso significava negociar janela de manutenção, notificar usuários, derrubar as aplicações e torcer para que o servidor subisse normalmente depois.
Com live migration, o procedimento é outro. Você instrui o sistema a migrar as VMs do host que vai ser reiniciado para os outros hosts do cluster. As VMs se movem enquanto estão rodando. Quando o host está vazio, você aplica a atualização e faz o reboot. Depois, as VMs podem voltar para ele — também sem downtime. Do ponto de vista dos usuários e aplicações, nada aconteceu.
É por isso que ambientes enterprise com SLA 99,99% — como os datacenters Tier III da Adentro — dependem de live migration como capacidade fundamental da plataforma, não como diferencial.
Como funciona tecnicamente — o que acontece por baixo
A live migration parece mágica, mas é engenharia cuidadosa de transferência de estado. O processo acontece em fases:
Fase 1 — Cópia inicial de memória. O hypervisor começa a copiar o conteúdo da RAM da VM para o host de destino, enquanto a VM continua rodando no host de origem. Durante essa cópia, a VM continua executando normalmente e modificando páginas de memória.
Fase 2 — Rastreamento de páginas sujas. Enquanto a cópia acontece, algumas páginas de memória são modificadas pela VM em execução (são chamadas de “dirty pages”). O hypervisor rastreia quais páginas foram modificadas após a cópia inicial.
Fase 3 — Iterações de sincronização. O hypervisor copia as dirty pages — e enquanto copia, novas páginas ficam sujas. O processo repete, em iterações cada vez mais rápidas, até que o volume de páginas pendentes seja suficientemente pequeno para ser transmitido numa janela de milissegundos.
Fase 4 — Pausa e transferência final. Em algum ponto, o hipervisor pausa a VM por milissegundos, transfere as últimas páginas sujas e o estado da CPU (registradores, estado de execução), e retoma a VM no host de destino. Essa pausa é tipicamente de 10 a 200 milissegundos — abaixo do threshold de timeout de qualquer protocolo de rede bem configurado.
Fase 5 — Atualização de rede. O host de destino anuncia via ARP gratuito que o endereço MAC da VM agora está acessível por outra interface física. Switches de rede atualizam suas tabelas de MAC, e o tráfego começa a fluir para o novo host.
Do ponto de vista das aplicações dentro da VM, houve uma pausa breve imperceptível. Conexões TCP ativas continuam — porque o estado de rede da VM foi preservado.
Live migration, cold migration e storage migration — as diferenças
Esses termos são usados com alguma ambiguidade no mercado, então vale esclarecer:
Live migration é a migração com a VM ligada, conforme descrito acima. A VM não é desligada em nenhum momento. É o método preferido quando minimizar impacto é a prioridade.
Cold migration (ou offline migration) envolve desligar a VM, mover os arquivos para o host de destino e religar. É mais simples tecnicamente — não precisa de sincronização de estado — e é a única opção quando os hosts não têm compatibilidade de CPU suficiente para live migration, ou quando a VM precisa ser movida para um ambiente de storage completamente diferente. O custo é o downtime da VM durante a transferência.
Storage migration move os discos da VM de um pool de storage para outro enquanto a VM continua rodando. A CPU e a RAM ficam no mesmo host; só o storage muda. É útil para mover VMs entre tipos de storage (por exemplo, de HDD para SSD) ou reorganizar a distribuição de I/O entre volumes. Tecnicamente mais complexa que a live migration de compute, porque implica I/O redirecionamento ativo.
Em muitos cenários de manutenção completa, você combina as duas: live migration do host enquanto mantém o storage, e depois storage migration em outra janela para rebalancear os discos.
Requisitos para a live migration funcionar
Live migration não é gratuita — ela tem requisitos que precisam estar satisfeitos:
Compatibilidade de CPU entre os hosts. O estado de CPU que precisa ser transferido assume que o host de destino tem as mesmas instruções disponíveis. Se você tiver hosts com gerações diferentes de processador, live migration pode não funcionar ou requer “CPU masking” — onde o hypervisor expõe apenas o conjunto de instruções comum a ambos os hosts, limitando a performance.
Storage compartilhado ou compatível. Na maioria das implementações de live migration, apenas a memória e o estado de CPU são transferidos — os discos da VM ficam onde estão. Para isso funcionar, ambos os hosts precisam ter acesso ao mesmo storage (SAN, NFS ou storage distribuído como Ceph). Hyper-V tem “Shared Nothing Live Migration” que copia os discos junto, mas é mais lento.
Rede de migração dedicada. Transferir gigabytes de RAM entre hosts em milissegundos exige bandwidth. Ambientes bem arquitetados têm uma rede de migração dedicada (10 GbE ou 25 GbE), separada da rede de produção das VMs, para evitar que a migração afete o tráfego de aplicação.
Hypervisors compatíveis. Live migration só funciona entre hosts com o mesmo hypervisor (KVM para KVM, ESXi para ESXi). Ferramentas como HCX da VMware permitem migração entre ambientes diferentes, mas com mais complexidade.
Suporte nos principais hypervisors
VMware vSphere (vMotion). O vMotion foi o pioneiro — VMware foi o primeiro a comercializar live migration enterprise em 2003. Funciona muito bem, é maduro e tem muitas otimizações. Requer vCenter para gerenciamento e licença adequada.
KVM com libvirt ou CloudStack. Live migration no KVM é suportada e usada em produção em escala global (AWS, Google Cloud, plataforma ACS da Adentro). Ferramentas como virsh, Proxmox e CloudStack automatizam o processo. Funciona tão bem quanto o vMotion em hardware compatível.
Hyper-V (Live Migration). Suportada em clusters Windows Server com Failover Clustering. Tem a peculiaridade de suportar “Shared Nothing Live Migration” sem storage compartilhado — mais lento, mas útil em ambientes sem SAN.
Proxmox. Live migration integrada na interface web — você arrasta a VM de um node para outro, ou define políticas de HA que disparam migração automática. Usa virsh por baixo, com abstração via GUI.
A plataforma ACS da Adentro utiliza live migration automática para manutenção de hosts sem janela de indisponibilidade para clientes. Conheça a Cloud Privada com SLA 99,99%.