Live migration de um guest KVM com o seu storage, passo a passo

Mover uma máquina virtual em execução entre hosts sem storage partilhado parece magia até o ter feito algumas vezes. Depois é uma checklist: confirmar que os hosts são compatíveis, preparar o destino para que o guest encontre tudo o que espera, executar um comando, e saber quando não tentar. Aqui fica essa checklist para KVM simples com libvirt.

O que acontece realmente durante uma live migration

Com --copy-storage-all, o libvirt pede ao QEMU no destino que crie o guest, e depois transmite o disco enquanto o guest continua a correr e a escrever. Assim que o disco está em mirror, a memória é copiada em rondas: cada ronda envia as páginas que o guest sujou durante a anterior. Quando o conjunto de páginas sujas restante é suficientemente pequeno para ser enviado dentro do downtime permitido, o guest é pausado, as últimas páginas e o estado dos dispositivos atravessam, e ele retoma no destino. A pausa é habitualmente de algumas centenas de milissegundos. As ligações de rede sobrevivem porque o guest mantém o seu MAC e o seu endereço IP, e o switch aprende a nova localização com os primeiros pacotes do guest.

Tudo o que pode correr mal é uma discrepância entre o que o guest espera e o que o destino oferece. Por isso, verifique isso primeiro.

Primeiro passo: decida entre live e a frio

A live migration é a ferramenta certa quando a origem e o destino são compatíveis e o ritmo de escrita do guest é moderado. É a ferramenta errada quando tudo muda ao mesmo tempo: uma geração de CPU diferente, uma topologia de rede diferente e uma versão de hypervisor diferente na mesma mudança. Nesse caso o caminho seguro é a frio: desligar o guest de forma limpa, copiar o disco, defini-lo no destino, arrancá-lo e manter a origem intocada como rollback.

Um primary de base de dados com um ritmo de páginas sujas muito elevado pode também nunca convergir. Meça antes de tentar:

virsh domdirtyrate-calc <guest> --seconds 5
virsh domstats <guest> --dirtyrate

Segundo passo: verifique a compatibilidade de CPU

O modelo de CPU do guest tem de existir no destino. Se o guest usa host-passthrough, as CPU dos dois hosts têm, na prática, de coincidir. Compare a definição do guest com o host de destino:

virsh dumpxml <guest> > guest.xml                       # on the source
xmllint --xpath '//cpu' guest.xml > guest-cpu.xml
virsh hypervisor-cpu-compare guest-cpu.xml              # on the destination

identical ou superset significa avançar. incompatible significa ou alterar o guest para um modelo de CPU nomeado que ambos os hosts suportem (no seu próximo reboot) ou movê-lo a frio.

Terceiro passo: prepare a rede do destino

Cada bridge, ou VLAN sobre uma bridge, a que as interfaces do guest se ligam tem de existir no destino com o mesmo nome, e tem de transportar as mesmas VLAN no uplink:

virsh domiflist <guest>      # on the source: which bridges
ip -br link show type bridge # on the destination: do they exist?

Uma bridge em falta faz a migração falhar de forma limpa logo no início. Uma bridge que existe mas assenta num uplink sem a VLAN migra com sucesso e deixa o guest inacessível, o que é pior. Verifique também o lado do switch.

Quarto passo: prepare o storage do destino

O destino precisa de um sítio onde o disco aterre, num caminho que o libvirt gere como storage pool:

virsh pool-define-as images dir --target /var/lib/libvirt/images
virsh pool-start images && virsh pool-autostart images

Para a maioria das topologias o libvirt cria a imagem de destino por si. Para as invulgares, crie-a antecipadamente com exatamente o mesmo tamanho virtual e formato da origem:

qemu-img info --output=json /var/lib/libvirt/images/<guest>.qcow2   # note virtual-size
qemu-img create -f qcow2 /var/lib/libvirt/images/<guest>.qcow2 <virtual-size>

Quinto passo: migre

A partir do host de origem, com acesso SSH por chave ao destino como o utilizador do libvirt:

virsh migrate --live --persistent --undefinesource \
  --copy-storage-all --auto-converge --verbose \
  <guest> qemu+ssh://<destination>/system

• --live mantém o guest em execução.
• --copy-storage-all faz mirror do disco completo. (Existe --copy-storage-inc para discos cuja imagem base já está no destino.)
• --auto-converge limita ligeiramente a CPU do guest se a memória estiver a ser suja mais depressa do que pode ser enviada, para que também os guests ocupados terminem.
• --persistent e --undefinesource movem a definição com o guest, para que não reapareça no host antigo no próximo arranque.

Usamos o caminho de migração direto em vez de --tunnelled quando o storage é copiado. Enquanto corre, acompanhe o progresso a partir de um segundo terminal:

virsh domjobinfo <guest>

domjobinfo mostra os dados restantes, o ritmo de páginas sujas e o downtime esperado. Se claramente não estiver a convergir, virsh domjobabort <guest> interrompe o trabalho e deixa o guest a correr na origem, intocado.

Sexto passo: verifique à chegada

Verifique, a partir de fora do guest:

virsh list --all                      # running on the destination only
virsh domblklist <guest>              # disk at the expected path
virsh domifaddr <guest> --source arp  # address visible on the network

Se o guest é um load balancer ou uma réplica de base de dados, confirme que retomou o seu papel (estado VRRP, threads de replicação) em vez de o presumir.

Só depois disso remova a imagem de disco antiga da origem, ou melhor, mantenha-a até ao próximo ciclo de manutenção.

A sua checklist

• Live ou a frio decidido de propósito, com o ritmo de páginas sujas medido para guests ocupados.
• Modelo de CPU comparado com o host de destino.
• Cada bridge e VLAN presente no destino, incluindo os uplinks do switch.
• Um storage pool no destino, espaço livre suficiente e uma imagem pré-criada onde a topologia o exige.
• O comando migrate executado com cópia de storage e auto converge, acompanhado com domjobinfo.
• O guest verificado a partir de fora, e a cópia de origem mantida até ter a certeza.

Se quiser mover guests sem os desligar, ou precisar de um caminho para sair do seu hypervisor atual, teremos todo o gosto em ajudar.

CTA

Fale com um engenheiro

Related

Relacionados: Live migration e saída de hypervisor · Private cloud em KVM com OLVM · Mude para nós sem alterar endereços: extensão Layer 2