VMware to oVirt and OLVM migration
Moov migrates virtual machines to oVirt, Oracle Linux Virtualization Manager (OLVM) and Red Hat Virtualization using Veeam Backup & Replication V13 restore points as the source. Disk upload goes through the manager REST API together with imageio, and instant migration additionally uses SSH and QMP against the host. vCenter and ESXi are never contacted.
Download the appliance
- Proxmox VE8.x / 9.x
- oVirt / OLVM4.5+
- HPE VM EssentialsMorpheus 8.1.x · 9.0.x
Prerequisites
The 4.5 branch is the supported floor. All three distributions share the same manager and the same API, so the procedure is identical on each.
The imageio service is what receives the disks. It has to be running and reachable from the helper, not only from the manager: if imageio sits behind a firewall that only opens for the engine, the upload fails even though the API answers fine.
Instant VM Migration needs to speak QMP to the host QEMU process to pivot while running, and it gets there over SSH. If you only plan to use Cold Migration this does not apply. SSH host-key pinning is enforced on every path since v1.0.38.
The destination storage domain needs capacity for the disks of the VMs in the wave, plus the helper footprint (50 GB with the defaults).
Migration steps
The full run, from a freshly deployed appliance to the first VM running on oVirt.
- 01Connect the Veeam server
Under Connections → Veeam, add your Veeam Backup & Replication V13 server. Moov uses the REST API to inventory the catalog and the Data Integration API to publish disks without modifying the backup.
- 02Add oVirt or OLVM as a target
Under Connections → Targets, pick oVirt / OLVM and enter the manager URL and credentials. Moov validates at registration that the REST API answers and that imageio is reachable, so the problem surfaces there and not halfway through a wave.
- 03Deploy a helper
The helper is created as a VM inside oVirt itself and registers with the Core over mutual TLS using a single-use token. It is disposable: it is removed when the wave finishes.
- 04Run preflight
The Pre-flight Inspector scans the Veeam catalog and classifies each VM by operating system, disks and VirtIO readiness. For large inventories you can filter by repository and paginate the results.
- 05Pick a mode and plan the wave
Instant VM Migration boots the VM on oVirt from the backup in under 60 seconds and pivots afterwards. Cold Migration uploads the disks through imageio and leaves the VM created and powered off, with no need for SSH or QMP.
- 06Launch and verify
You follow per-disk progress in the console, with real transferred bytes measured before the copy starts. When it finishes, the guest agent responds and the VM is operational on the target.
What happens to the guest operating system
The customize stage runs offline against the mounted disk before the VM boots on oVirt, adapting it to KVM. No auxiliary appliance and no KVM installed on the helper are required.
- VirtIO drivers (vioscsi and viostor) are injected into Windows and Linux guests, which enables the virtio-scsi bus.
- VMware Tools are uninstalled so they do not compete with the KVM drivers and agent.
- The QEMU Guest Agent is prepared, which oVirt uses to report the IP and VM state in its own console.
- Static IPs are reapplied according to each NIC PCI slot, including Windows guests with several interfaces.
- On guests that boot via UEFI the ESP partition is seeded or repaired, and on Windows the BCD fixup runs.
Known limits
- The source must be a VM image backup in Veeam B&R V13. Agent and application backups are out of scope.
- Instant migration depends on SSH and QMP to the host. If your security policy does not allow that access, Cold Migration remains available.
- Core and helpers must be on the same version: since v1.0.38 the Core refuses work from older helpers.
- Concurrent capacity per helper is set by its CPU and RAM, roughly 1 vCPU and 2 GiB per in-flight VM.