Migração KVM Live ou Near-Live do LVM para o backend do sistema de arquivos

Question

Minha máquina de convidado tem 2 partições (80GB + 1TB). Ambos estão no LVM. Eu quero transferir todos os discos para outra máquina com o mínimo de tempo de inatividade. Eu transferi outra máquina com nc. Demora 4 dias e durante a transferência minha VM estava desligada.

Tentei fazer um instantâneo depois de transferir páginas sujas. Mas AFAIK com LVM não é possível. Minha máquina de destino não tem configuração LVM e espaço livre não particionado. Portanto, nos discos da máquina de destino, devem existir imagens de arquivo não processadas.

<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none'/>
  <source dev='/dev/vg-datastore/lv-vm-1138'/>
  <target dev='vda' bus='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/>
</disk>
<disk type='block' device='disk'>
  <driver name='qemu' type='raw' cache='none'/>
  <source dev='/dev/vg-datastore-sata/lv-vm-1138-2'/>
  <target dev='vdb' bus='virtio'/>
  <address type='pci' domain='0x0000' bus='0x00' slot='0x08' function='0x0'/>
</disk>

Host de origem:

• CPU: CPU Intel (R) Xeon (R) D-1520 @ 2.20GHz
• SO: 16.04.1 LTS
• Kernel: 4.2.0-34-generic
• qemu-kvm: 1: 2.3 + dfsg-5ubuntu9.2
• QEMU: 2.3.0
• libvirt: 1.2.16

Host de destino:

• CPU: CPU Intel (R) Xeon (R) D-1520 @ 2.20GHz
• SO: 16.04 LTS
• Kernel: 4.4.0-28-generic
• qemu-kvm: 1: 2.5 + dfsg-5ubuntu10.2
• QEMU: 2.5.0
• libvirt: 1.3.1

Answer 1

O KVM / libvirt suporta a migração ao vivo da VM com migração de armazenamento (uma configuração de nada compartilhado), embora com algumas limitações. Seu principal problema é que os pools de armazenamento têm configurações diferentes, portanto, não tenho certeza de que libvirt migrará a imagem da VM sem problemas.

O comando para fazer uma migração ao vivo + cópia de armazenamento é:

virsh migrate  --live --copy-storage-all --persistent qemu+ssh://root@/system

Este comando presume que você tenha uma conexão válida baseada em libvirt para o host remoto.

Se você tiver problemas para migrar seus discos virtuais, poderá tentar criar arquivos de disco virtual de destino de stub com a execução (no host de destino) algo semelhante a fallocate /dev/vg-datastore/lv-vm-1138 -l 80G e /dev/vg-datastore-sata/lv-vm-1138-2 -l 1T .

De qualquer forma, devido a diferenças entre os anfitriões, isso pode ser uma estrada esburacada.

Uma maneira mais simples de migrar suas imagens de VM é usar uma abordagem de cópia de disco incremental, usando blocksync . Resumindo:

• quando a VM estiver em execução, faça uma primeira cópia dos discos virtuais no host de destino. Esta primeira cópia será incoerente e não confiável, mas funcionará como uma "semente" para a próxima cópia;
• no momento apropriado, desligue a VM e execute uma segunda cópia dos discos virtuais. Esta segunda cópia transferirá apenas os blocos alterados e será muito mais rápida que a primeira;
• quando terminar, defina o domínio virtual e inicie a VM no host de destino.

Observe que o programa blocksync vinculado é uma versão com bifurcação pessoal com base no script original (que, por a propósito, é uma versão melhorada de este script ). Obviamente, assumo NO RESPONSABILITY como código e sugiro que você teste completamente antes de usá-lo em máquinas virtuais de produção / arquivos de disco. Como sempre, você DEVE ter um backup confirmado antes de fazer qualquer coisa.

EDITAR: como sugerido no comentário abaixo, outro ótimo software para sincronizar um dispositivo de bloco / arquivo de imagem virtual é bdsync . A abordagem é basicamente a mesma: obter uma primeira cópia "primária" do arquivo de disco enquanto a VM está em execução, interromper a VM e fazer outra cópia final. No passado, até perguntei a bdsync developer sobre uma questão semelhante; veja aqui para mais informações .