KoaVM
Guide pages

Guide · For administrators

Migration from other panels

KoaVM moves VMs from other panels to the KoaVM nodes keeping the same IP and MAC, cold or near-live (about 10 seconds of downtime).

VPSs at a provider where you have no access to the hypervisor (Vultr, Hetzner, DigitalOcean, OVH, Contabo…) are instead imported from the inside, over SSH: see “From another provider (over SSH)” below.

Sources

In Migration › Connect a source: SolusVM 1, SolusVM 2, Virtualizor, Proxmox VE, OpenStack or any KVM/libvirt node.

  • Nodes (required): the addresses of the servers where the VMs run, with root or a user with passwordless sudo. The panel reads them over SSH with its key.
  • Panel API (optional): adds hostname, IP and customer of each VM and, after the move, suspends the VM in the old panel.

Add the panel key (on the Migration page) to authorized_keys on the source nodes and on the KoaVM nodes. The KoaVM nodes need qemu-utils.

OpenStack

OpenStack needs the API (Keystone v3) with an application credential: create it in Horizon (Identity › Application Credentials) or with openstack application credential create koavm. With the admin role the panel sees the VMs of all projects (and the project becomes the suggested client name); without it, only those of the credential's project. If the catalog has several regions, write the one of the VMs.

Compute nodes (SSH) are optional:

  • VMs on the connected compute nodes move as from libvirt: cold or near-live, with the same MAC and the same IP if it is in a panel block linked to the destination node. Disks on Ceph are copied near-live too (a cold copy needs the Ceph user keyring on the node);
  • the other VMs are copied through the API: Nova snapshots the boot disk (or Cinder copies the volumes, the boot one included), the panel downloads it from Glance checking its checksum and writes it on the KoaVM node. “Cold” first shuts the VM down in OpenStack (consistent copy); “near-live” copies it while running (consistent as after a power cut) and leaves it on. The images, snapshots and temporary volumes created in OpenStack are removed at the end.

In both cases the VM arrives on KoaVM adjusted like imported VPSs: on first boot cloud-init (present in images for OpenStack) configures the network with the KoaVM IP, which is new if the OpenStack one is not in a panel block; users, passwords, SSH keys and host keys stay as they were. The firmware (UEFI or BIOS) is read from the image or, if missing, from the copied disk. With suspend at the source panel the VM is shut down and locked in OpenStack (nobody restarts it by mistake). The flavor ephemeral disk is not copied (the check says so).

How a VM moves

  1. Scan: the panel finds the VMs, disks and IPs.
  2. For each VM choose the customer (existing or new), the destination node and the mode.
  3. Checks: before starting the panel verifies space, network, IPs and access; if something is wrong it says so and does not start.
  4. Start now or at a set time, at most N migrations at once (in Settings).

The modes:

  • Cold: the VM shuts down, the disk is copied, the VM starts again on KoaVM. Downtime equals the copy time.
  • Near-live: the disk is mirrored while the VM runs, then one restart on the new node (about 10 seconds of downtime).

All the VM's disks move; ZFS, LVM, dir and btrfs storage work on the KoaVM nodes. A VM that is off at the source stays off.

Cancelling a migration

In the Status column, next to the progress, there is Cancel:

  • queued (scheduled too): the migration leaves the queue, the VPS prepared on KoaVM goes away and the IP is free again;
  • copying: the copy stops and everything goes back to how it was, as when something goes wrong (see below).

From the switchover on (cold: copy finished; near-live: the moment the VM moves to the new node) it can no longer be cancelled: the button goes away and the migration runs to the end. A cancelled VM can be migrated again. If the customer got the notice, they also get an email that the move is cancelled.

If something goes wrong

The source VM goes back to how it was and starts again; with provider IPs the IP goes back to the previous server. The VM detail shows the error and the log of the steps.

Customer emails

With emails turned on (Settings) the customer gets a notice before and after the move, with the time and the expected downtime.

From another provider (over SSH)

For a Linux VPS at any provider: the panel logs into the VPS over SSH, copies the disk from the inside while the VPS keeps running and starts it again on a KoaVM node with a new IP. Nothing is needed from the provider, only SSH access.

What the VPS needs

  • Linux x86_64 with the system on an ext4, xfs or btrfs partition (LVM, software RAID and encrypted disks are not supported yet);
  • cloud-init installed (apt install cloud-init or dnf install cloud-init): on the first boot on KoaVM it configures the new network;
  • SSH tunnels allowed (AllowTcpForwarding yes, the default);
  • the root user, or a user with passwordless sudo.

The KoaVM nodes need qemu-utils (as for migration) and an IP block: the imported VPS takes an IP from the node, so the block must have public IPs for it to be reachable from outside.

How it works

  1. Migration › Import from another provider: address, port and user of the VPS, then the password (used only once to put the panel's key in authorized_keys, and not saved) or the panel's key, which you add yourself.
  2. Check: the panel reads the system, disk, filesystem, cloud-init and running databases without changing anything. Items in red must be fixed on the VPS before starting; the check also tells you how long the copy will take.
  3. Choose the client (existing or new), plan, node (or automatic) and hostname. The new VPS's disk is at least as big as the source's, even if the plan has less.
  4. Start the import. The copy runs in several passes: the first copies the whole disk with the VPS running, the next ones only what has changed, the last freezes the filesystems and copies the latest changes, so the copy is consistent like a snapshot. Since 1.10 the panel tracks the disk writes while copying (kernel events): the passes after the first re-read only the written pieces, so the freeze lasts a few seconds even on large or slow disks; if tracking is not available the whole disk is re-read and the freeze lasts as long as a full read. While the disk is frozen, programs that write wait; running databases can be stopped during the last pass (offered when there are any) and start again right after.
  5. On the node the panel adjusts the copied disk (old network configuration set aside, cloud-init reading KoaVM's configuration, fstab lines of disks that were not copied commented out, fallback UEFI loader) and starts the VPS. Users, passwords, SSH keys, host keys and software stay as they were.

When the import is finished the working folder and the panel's key are removed from the source VPS, which stays on (or shuts down, if you chose so). Writes made on the source VPS after the last pass do not reach KoaVM: stop the services or shut it down, then update DNS and firewalls with the new IP.

Until the last pass the import can be cancelled from the list; if something goes wrong the VPS on KoaVM is removed, the IP is freed and the source VPS stays as it was (databases started again included). A failed import can be retried from the same list.