Migração de VMware para oVirt e OLVM
O Moov migra máquinas virtuais para oVirt, Oracle Linux Virtualization Manager (OLVM) e Red Hat Virtualization usando como origem os pontos de restauração do Veeam Backup & Replication V13. O upload dos discos vai pela API REST do manager junto com o imageio, e a migração instantânea soma acesso SSH e QMP ao host. Em nenhum momento o vCenter ou o ESXi são contatados.
Baixar o appliance
- Proxmox VE8.x / 9.x
- oVirt / OLVM4.5+
- HPE VM EssentialsMorpheus 8.1.x · 9.0.x
Pré-requisitos
A ramificação 4.5 é o piso suportado. As três distribuições compartilham o mesmo manager e a mesma API, então o procedimento é idêntico nas três.
O serviço imageio é quem recebe os discos. Ele precisa estar ativo e acessível a partir do helper, e não só do manager: se o imageio estiver atrás de um firewall que abre apenas para o engine, o upload falha mesmo que a API responda bem.
A Instant VM Migration precisa falar QMP com o processo QEMU do host para fazer o pivot a quente, e chega lá por SSH. Se você só for usar Cold Migration, este requisito não se aplica. O pinning de host-key SSH é exigido em todos os caminhos desde a v1.0.38.
O storage domain de destino precisa ter capacidade para os discos das VMs da onda, mais o espaço do helper (50 GB com os valores padrão).
Passos da migração
O percurso completo, de um appliance recém-implantado até a primeira VM rodando no oVirt.
- 01Conectar o servidor Veeam
Em Conexões → Veeam, adicione seu servidor Veeam Backup & Replication V13. O Moov usa a API REST para inventariar o catálogo e a Data Integration API para publicar os discos sem modificar o backup.
- 02Adicionar oVirt ou OLVM como destino
Em Conexões → Destinos, escolha oVirt / OLVM e informe a URL do manager e as credenciais. O Moov valida no cadastro que a API REST responda e que o imageio esteja alcançável, para que o problema apareça ali e não no meio de uma onda.
- 03Implantar um helper
O helper é criado como uma VM dentro do próprio oVirt e se registra no Core por TLS mútuo com um token de uso único. Ele é descartável: é removido ao terminar a onda.
- 04Rodar o preflight
O Pre-flight Inspector varre o catálogo do Veeam e classifica cada VM por sistema operacional, discos e prontidão VirtIO. Para inventários grandes você pode filtrar por repositório e paginar os resultados.
- 05Escolher o modo e planejar a onda
A Instant VM Migration inicia a VM no oVirt a partir do backup em menos de 60 segundos e pivota depois. A Cold Migration sobe os discos por imageio e deixa a VM criada e desligada, sem precisar de SSH nem QMP.
- 06Lançar e verificar
Você acompanha o progresso por disco no console, com bytes efetivamente transferidos medidos antes de a cópia começar. Ao terminar, o agente convidado responde e a VM fica operacional no destino.
O que acontece com o sistema operacional convidado
A etapa de customize roda offline sobre o disco montado antes de a VM iniciar no oVirt, adaptando-a ao KVM. Não requer appliance auxiliar nem KVM instalado no helper.
- Os drivers VirtIO (vioscsi e viostor) são injetados em guests Windows e Linux, o que habilita o barramento virtio-scsi.
- As VMware Tools são desinstaladas para não competirem com os drivers e o agente do KVM.
- O QEMU Guest Agent é preparado, e o oVirt o usa para reportar o IP e o estado da VM no seu próprio console.
- Os IPs estáticos são reaplicados conforme o slot PCI de cada NIC, incluindo guests Windows com várias interfaces.
- Em guests que iniciam por UEFI a partição ESP é semeada ou reparada, e no Windows roda o BCD fixup.
Limites conhecidos
- A origem precisa ser um backup de imagem de VM no Veeam B&R V13. Backups de agente e de aplicação estão fora do escopo.
- A migração instantânea depende de SSH e QMP ao host. Se a sua política de segurança não permitir esse acesso, a Cold Migration continua disponível.
- Core e helpers precisam estar na mesma versão: desde a v1.0.38 o Core recusa trabalho de helpers mais antigos.
- A capacidade concorrente por helper é definida por sua CPU e RAM, aproximadamente 1 vCPU e 2 GiB por VM em voo.