In short
KoaVM copies the VM disks from the source node to an Incus node and boots them with the same IP and the same MAC. In near-live mode the disk is copied while the VM is running and downtime is about 10 seconds; in cold mode the VM shuts down and downtime lasts as long as the copy. If anything goes wrong, the source VM starts again as it was.
What you need
- An Incus node connected to KoaVM: a server with Incus, ZFS, LVM, dir or btrfs storage, and
qemu-utils. How to connect it is in the guide, on the Nodes page. - SSH access to the source nodes: root or a user with passwordless
sudo. Add the panel's key (you'll find it in Migration) toauthorized_keyson the source nodes and on the Incus nodes. - The IPs must be able to reach the new node: same network as the old node, or movable provider IPs (OVHcloud, Hetzner) that the panel moves by itself via API.
- Optional but recommended: the old panel's API (SolusVM, Virtualizor, Proxmox). With it KoaVM knows hostname, IP and customer of each VM and, after the move, suspends the VM in the old panel.
Step by step
- Connect the source in Migration › Connect a source: panel type, nodes, API.
- Scan: KoaVM lists VMs, disks, IPs and state (running or stopped).
- Prepare: for each VM pick the customer (existing or new), the target node and the mode.
- Checks: node space, network, IPs, access. If a check fails, the VM doesn't start and the panel says why.
- Start now or at a set time (for example at night), with at most N migrations at once.
- Customer emails: if enabled, each customer gets a notice before and after, with the time and expected downtime.
How long it takes
Times depend on disk size and on the network between nodes. In our lab (nested nodes, so slower than real servers):
| VM | From | Disk | Mode | Copy | Downtime |
|---|---|---|---|---|---|
| pve-web1 | Proxmox VE | 2 disks, 10 + 3 GB, LVM-thin | near-live | 245 s | 13.8 s |
| pve-web3 | Proxmox VE | 6 GB, LVM-thin | near-live | 113 s | 13.2 s |
| vps-a | KVM/libvirt | qcow2 20 GB | near-live | 27 s | 8.8 s |
| solus-web1 | SolusVM 2 | qcow2 10 GB | near-live | 23 s | 15.8 s |
| pve-web2 | Proxmox VE | UEFI, qcow2 8 GB | cold, scheduled | 34 s | 45.5 s |
In every test: no lost writes, identical second disk (same checksum), same IP and MAC.
Practical tips
- Start with a test VM of your own, then with customers without critical services.
- For large VMs use scheduling at night: the mirror copy works while the VM is running, but it uses bandwidth.
- VMs that are off at the source stay off: no surprises for customers who keep them stopped.
- For Windows, cold migration is the simplest: downtime equals the copy time.
- After the move, check the step log in the VM detail: everything is there, timings included.
Help
For the first 20 providers we do the migration together, for free. Join the waitlist or write to info@koavm.com. Coming from a specific panel? SolusVM, Virtualizor, VirtFusion.