Mass virtual machine migration to Proxmox, KVM and HPE VM Essentials using Veeam backups.

Moov migrates virtual machines from Veeam Backup & Replication restore points onto Proxmox VE, oVirt / OLVM / RHV and HPE VM Essentials, without touching the source virtualized environment during the migration.

Download the appliance

See how it works

3
migration targets
≤ 60 s
RTO with Instant Migration
0
connections to the source environment

Source environment

out of scope

Veeam Backup & Replication V13

source: restore point

Moov appliance

core + disposable helpers

customize · NBD · pivot

Proxmox VE8.x / 9.x
oVirt / OLVM4.5+
HPE VM EssentialsMorpheus 8.1.x · 9.0.x

Supported targets

Proxmox VE

8.x / 9.x

Full support, including automatic API-token bootstrap.

oVirt / OLVM / RHV

4.5+

REST + imageio upload; SSH/QMP for instant migration.

HPE VM Essentials

Morpheus 8.1.x · 9.0.x

Instant and cold migration onto MVM nodes.

Source: Veeam Backup & Replication V13 REST API.

How it works

A Core appliance plus disposable helpers on the target hypervisor.

The source of every VM is Veeam: REST metadata or the published backup disk. Moov never connects to vCenter or ESXi.

01
Pre-flight Inspector
Scans Veeam backups, classifies each VM (OS, disks, VirtIO readiness) and estimates the capacity needed.
02
Wave planning
The operator plans a wave in the web console and picks a target host and migration mode per VM.
03
Publish and dispatch
The Core publishes the restore point from Veeam and dispatches the work to a helper, which serves the disk over NBD and drives the conversion or boot.
04
Boot and pivot
Progress streams live to the console; the VM boots, the guest agent comes online and, for instant migration, the disk pivots to local storage.

Source environment

out of scope

Veeam Backup & Replication V13

Backup repository · VBK / VIB

SOURCE

Moov Appliance

moov-core: web console · REST API (:9093)

orchestrator · embedded SQLite · local CA · mTLS

moov-helper: local helper

PRIMARY

Operator

web browser

HTTPS :9093

mTLS · gRPC

Additional helpers

HELPER

Same appliance image

Horizontal scaling of the migration

REST / SSH / libvirt

Migration targets

Proxmox VE
oVirt / OLVM / RHV
HPE VM Essentials

Active data flowManagement / consoleOut of scope

Architecture: Veeam source, Moov appliance (core + local helper), additional helpers and migration targets.

Migration modes

Two modes, depending on how much downtime each VM tolerates.

IVMR

Instant VM Migration

RTO · ≤ 60 s to boot

For critical VMs. The VM boots immediately on the target from the backup (iSCSI/NBD) while its disks migrate in the background. When the mirror completes, the pivot leaves it running entirely on target storage.

Cold

Cold Migration

RTO · 15 to 60 min per VM

Copies the disks to the target and leaves the VM created and powered off, so the operator boots it in their own window. No backup dependency at boot time.

Wave Engine

Both modes run through the Wave Engine, which schedules many VMs concurrently with per-helper capacity limits derived from the host's CPU and RAM: roughly 1 vCPU and 2 GiB per VM, with global capacity being the sum of the fleet.

No vSphere dependency

The source of every VM is Veeam. Moov never connects to vCenter or ESXi.

Drivers built in

VirtIO drivers are prepared automatically for Linux and Windows guests, including modern Windows using inbox drivers.

Network preserved

Static IPs and multi-NIC layouts are carried over to the migrated VM, or reassigned per NIC from the console.

Runs as an appliance

A self-contained image with a first-boot wizard and a web console. No external identity provider or database to stand up.

VM preparation

The Virtual Machine is made KVM-ready before it boots.

The customize stage runs offline against the mounted disk, with no auxiliary appliance and no KVM on the helper, adapting the guest OS so it boots and operates on the target.

customize · virt-v2v in-place

VirtIO driver injection
vioscsi / viostor are installed during preparation, on Windows and Linux. The injection creates the VirtIO evidence that enables the virtio-scsi bus.
IP address preserved
Static IPs are applied to every interface according to each NIC's PCI slot (multi-NIC Windows and Linux), or reassigned per NIC from the console.
VMware Tools removal
vSphere's VMware Tools are uninstalled so they don't compete with the KVM drivers and agent.
QEMU Guest Agent
QGA is prepared during customize; its ping response confirms the migrated VM is alive and enables IP queries, fsfreeze and command execution.
virtio-scsi disk bus
The paravirtualized controller becomes the default bus when there is evidence of VirtIO support in the guest, outperforming SATA/IDE.
Boot repair
BCD fixup on Windows, plus seeding or repairing the ESP partition when the guest boots via UEFI.
Sparsify optimization
Empty or zeroed blocks are discarded during conversion, cutting size and transfer time.
Target agent
On HPE VM Essentials the Morpheus agent is installed post-pivot through the QEMU Guest Agent's guest-exec.

Quickstart

From deployed appliance to multiple VMs running in ~20 minutes.

Minimum end-to-end run. Prerequisite: the appliance imported and powered on, with network access to the Veeam server and the target hypervisor.

Download the appliance

01
First boot and login
Complete the text wizard (Primary role, network, hostname, time, admin account). Note the CA fingerprint and the recovery code.
02
Connect Veeam
Under Connections → Veeam, add your Veeam B&R V13 server and test the connection until the status is healthy.
03
Add a target
Under Connections → Targets, add Proxmox VE, oVirt or HPE VM Essentials. The wizard bootstraps credentials automatically.
04
Deploy a helper
Pick the target and accept the defaults (8 vCPU / 16 GB / 50 GB). The helper registers over mTLS and becomes Active.
05
Preflight one VM
Scan the Veeam catalog, pick one VM and run the disk and hardware analysis. Confirm it lands in the Automatic bucket.
06
Launch one Instant Migration
Three-step wizard: source and VM, target and mode, placement (node, storage, network). The VM boots straight from the backup.
07
Verify the booted VM
Follow live progress: per-VM timeline, per-disk progress and event log. Once the pivot completes, the VM runs entirely on the target.

The console

The whole flow from one web console.

Dashboard: global status, outcomes of the latest migrations and capacity per target.

Live migration: per-disk progress and event log.

Preflight: Veeam catalog inventory and per-VM classification.

Connections: Veeam, targets and helpers with automatic bootstrap.

Security

Encrypted credentials, mTLS between components, no external IdP.

Local authentication
Passwords hashed with bcrypt, sessions with signed JWT and role-based access control. No external identity provider required.
Encrypted credentials
Credentials encrypted with AES-256-GCM. The master key is shown once at bootstrap as a recovery code: that code is the key, so it must be kept with the same care.
Helpers over mTLS
Helpers authenticate to the Core with mutual TLS via single-use registration tokens.
Verified artifacts
Base image, VirtIO and guest agents are checksum-verified on download.

Updates

The appliance updates itself, and its fleet of helpers.

Since v1.0.38 updating happens from the console: the appliance verifies, applies and, if anything goes wrong, returns to the previous version on its own. No reinstall, no recreating helpers, but they do need updating from the same console: a helper on the previous version is still accepted, which is exactly why it is easy to forget.

Signed bundles
Every update is signed with Ed25519 and carries a SHA-256 per file. The privileged boundary re-verifies signature and hashes before applying anything.
Two channels
Moov binaries and operating-system patches update separately, each with its own state in the console.
Automatic rollback
If the new Core cannot prove it is healthy, the appliance rolls back to the previous version without operator intervention.
Fleet in step
The appliance mirrors the Debian archive for its helpers and restarts hosts from the same table. Core and helpers must end on the same version.

Releases

What changed in the latest versions.

v1.0.40Latest

Separate networks and multi-datacenter oVirt

Supersedes v1.0.39. Separates the appliance management network from the hypervisor network, works with oVirt and OLVM managers that have several datacenters, keeps each VM disk order, and lets you choose the disk format per destination. Migrations to HPE VM Essentials become more reliable.

Separate management and infrastructure networks. Each appliance interface gets a role: management (web console, SSH, updates) or infrastructure (hypervisors, helpers, Veeam). Each role has its own routing, source address and inbound rules, and an infrastructure interface can carry its own gateway and DNS. Every change applies with an automatic revert if you do not confirm it.
oVirt and OLVM with multiple datacenters. Moov uses the SPM, storage domains and networks that belong to the host you choose. Placement shows each host datacenter and cluster, the helper wizard filters by cluster, and a placement mixing datacenters stops before anything is published.
Source disk order preserved. On Proxmox, oVirt and HPE VM Essentials, in both Instant and Cold migrations.
Disk format per destination. Format and qcow2 cluster size are set in each connection migration defaults.
More reliable HPE VM Essentials. Moov waits until the manager registers the final disk before reporting success and always uses the q35 machine type. UEFI VMs keep booting after a resize, unsupported datastores are refused with a clear error, and migrations onto Ceph RBD show a warning.
Static IP on additional helper interfaces. Interfaces added to a helper no longer depend on DHCP.
Reports without the 50-row limit. With server-side filtering and export. Waiting migrations say why they wait, and the support bundle includes the API call log.
More than 35 validation fixes. Linux guests with a separate /var partition, two Linux migrations on the same helper without colliding, and Veeam authorizing every helper address for iSCSI.

v1.0.39Previous

Boot verification and field corrections

Supersedes v1.0.38. A corrective release: three rounds of field defects, plus the operational additions several of them demanded. Several fixes run on the helper rather than the appliance, and the version gate has not moved: a 1.0.38 helper is still accepted but does not carry them. After upgrading the appliance, open Connections › Helpers › Update all.

Boot verification after every migration. The wave no longer turns green just because the disks copied: it powers the VM and waits for the guest agent, reporting verified, inconclusive or failed. Works on all three hypervisors.
A console Windows migration that never booted. The most serious defect corrected here. The wizard did not tell the helper what kind of guest it was sending, so the entire Windows preparation was skipped and the wave still reported success. If you migrated a Windows VM from the console on 1.0.38 and it did not boot, this is why.
Cold on LVM, ZFS and Ceph. Cold created the destination disk with size zero and relied on qemu-img to grow it, which only works on file-based storage. Each source disk is now measured before the VM is created and the volume is allocated at its real size.
Per-disk placement. Each disk of a VM can go to its own storage, in both Instant and Cold, and a data disk can be left out of the migration entirely. The boot disk cannot.
Multi-NIC helpers with roles. Additional interfaces on all three hypervisors, each with a management or data role. The iSCSI address list shows the role of each one and picks the data address by default.
VLAN and network selection when migrating. A VLAN tag control for Proxmox destinations, and SDN VNets offered as networks. Requested by mog54 in public issue #12.
CPU model now defaults to host. The previous default left every RHEL and Rocky 10 guest unbootable, since their glibc requires x86-64-v3. The per-VM override remains, and Instant now honors it instead of discarding it.
Capacity gate before the wave starts. It adds up the occupied size of the backups going to each storage and refuses to start when they do not fit, naming the storage, the node and the numbers. If the backend reports no metrics, it stays out of the way.

Guides by target

How to migrate VMware to each hypervisor.

Prerequisites, concrete steps and known limits for every supported target.

VMware to Proxmox VE migration

Proxmox VE 8.x and 9.x requirements, API token bootstrap and storage selection.

→

VMware to oVirt / OLVM migration

REST and imageio upload, SSH/QMP access and the specifics of oVirt 4.5 onwards.

→

VMware to HPE VM Essentials migration

MVM nodes, the post-pivot Morpheus agent and supported 8.1.x and 9.0.x versions.

→

Frequently asked questions

Do I need vCenter or ESXi access?

No. The source of every VM is Veeam, through REST metadata or the published backup disk. Moov never connects to the vSphere environment.

Which Veeam version is required?

Veeam Backup & Replication V13, through its REST API and the Data Integration API that publishes disks without modifying the backup.

Which Veeam license do I need?

Moov works with Veeam Data Platform in its Foundation, Advanced and Premium editions, under Veeam Universal License (VUL). Evaluation and NFR licenses also work, since they are full-featured by default. Veeam Backup & Replication Community Edition is not supported.

How much downtime does a critical VM take?

With Instant VM Migration the VM boots on the target from the backup (stated RTO ≤ 60 s) and later pivots to local storage with no extra window.

What about Windows drivers?

VirtIO drivers are injected automatically during customize, including modern Windows with inbox drivers and Windows Server 2025.

How many VMs can migrate at once?

The Wave Engine schedules concurrent waves; each helper runs as many VMs in parallel as its CPU and RAM allow, and global capacity is the sum of the fleet.

Under which license is Moov published?

Moov is published under the MIT license, in beta.