VorticPanel

Migrating from Virtualizor or VirtFusion: a step-by-step plan

How to move a KVM VPS fleet off Virtualizor or VirtFusion with a dry run first, one hypervisor at a time, and a way back for every server.

7 min read

Changing VPS panels touches every customer, every server and every IP address you have, and a bad move means tickets from all of them at once. This is the order we'd move a KVM fleet from Virtualizor or VirtFusion to VorticPanel in: connect to the old panel's API, do a dry run, move one test server, then move the fleet a hypervisor at a time. Every server can be rolled back for 3, 7 or 14 days after the last one moves, whichever you choose.

Before you start

You need three things:

  1. A VorticPanel controller. One command installs it on Debian or Ubuntu, and a small VM is enough: the minimum is 2 vCPUs and 2 GB of memory. See Installing the controller.
  2. An API credential for the old panel. On Virtualizor, an admin API key and pass from API Key Pairs. On VirtFusion, an API token from Settings → API. The import only reads through it.
  3. A decision on copy or adopt for each hypervisor, below.

Set up your node groups in VorticPanel first. The import asks which of your packages each old one becomes, and can make a new package from any old one, with its size, traffic and port speeds.

Copy or adopt

There are two ways to bring a server across, and you can mix them in one import.

Copy moves the server to one of your VorticPanel nodes. The node signs in to the old hypervisor over SSH and pulls the disk across while the server keeps running, then sends what changed again, up to twice. Only then is the server shut down, for a last pass of what changed since, and started on the new node with the same MAC address. The copy needs Python on the old hypervisor; where it's missing, the node installs it with the hypervisor's own package manager. If that can't be done, the server is shut down while its whole disk copies.

In our own test import from Virtualizor, a 1.8 GB disk came across in 14 seconds while the server ran, and the last pass had nothing left to send. Copy is the way to go when you're retiring old hardware or consolidating.

Adopt leaves the server where it is. You install VorticPanel's agent on the old hypervisor, enroll it as a node, and the import takes over each server in place: the disk is renamed into the node's storage and the server restarts once. Adopt suits hardware that's fine, where you only want a different panel on it.

Copy Adopt
Where it ends up On one of your nodes On the same hypervisor
Downtime A last pass of what changed, while it's shut down One restart
Needs SSH as root from your node to the old hypervisor The agent on the old hypervisor

Step 1: Connect and map

In the panel, go to Imports → New import, pick Virtualizor or VirtFusion, and enter the old panel's address and credential. Virtualizor usually has a self-signed certificate: the panel shows its SHA-256 fingerprint to compare before you trust it.

The import then lists the old panel's hypervisors, packages, IP ranges and servers, and asks you to map them:

  • Servers: which ones come in this import. Every server starts ticked, and the list filters by hypervisor, customer, package or IP range.
  • Packages: which of your packages each one becomes, a new one made from it, or leave it out.
  • IP ranges: keep the addresses as a new pool, treat them as part of a pool you already have, give copies new addresses from their new node, or leave the range out.
  • Hypervisors: which node group each one's servers go to.
  • Owners: when someone already has an account with you, whether to merge into it or keep them separate.

Customers keep their IP addresses only if the range is routed to the node the server lands on. For adopted servers that's always true. For copies, ask your provider to route the range to the new node first, or let the import hand out new addresses: the node sets them inside each server through its guest agent and can email the owner.

For copies, the mapping page has two more steps that let your nodes reach the old hypervisors:

  • Confirm each hypervisor's SSH host key. Check host key shows the fingerprints your nodes see; compare them with ssh-keygen -lf on the hypervisor itself, then confirm. Your nodes don't connect to a hypervisor until you've confirmed its key, and stop if the key changes.
  • Let your nodes sign in. Add keys with root password adds each copying node's key to root's authorized_keys there, as a line that only works from that node and comes off again once the import no longer needs it. The password is used once and isn't saved. If root can't sign in with a password, the page gives a command to run instead.

Step 2: The dry run

The dry run checks every server from the node that will move it: that the hypervisor shows the host key you confirmed and the node can sign in over SSH, that the server exists, how many disks it has, whether it boots BIOS or UEFI, its MAC address, and whether the hypervisor has Python. Windows servers are flagged and keep their chipset, disk bus, network card, clock and Hyper-V as closely as your nodes allow, so they boot with the drivers they already have. Each server shows an estimate of its downtime.

Anything it can't bring is listed with the reason. OpenVZ and LXC containers stay on the old panel because they can't run on KVM. A server's other disks, up to eight, come along as additional disks. Snapshots, backups, firewall rules and private networks don't come across: the dry run names the servers that had firewall rules, and any with an ISO in the CD drive.

Fix what it reports. Servers are checked again as you fix things, and your mappings are kept.

Step 3: One test server

Before moving anything that matters, move one disposable server. Watch its job log, then check:

  • it runs on its new node,
  • its address answers ping (or Remote Desktop, for Windows, which blocks ping by default),
  • the console works and the customer's panel shows it.

The panel runs the first two checks itself and shows a ✓ or ✗ next to each server. If anything is off, Roll back removes the copy and starts the original again where it was.

Step 4: The fleet, a hypervisor at a time

You can move everything in one go, but a batch per hypervisor is easier to watch. Under Servers at the top of the mapping page, choose one hypervisor in the hypervisor filter and click Import only these: every other hypervisor's servers stay on the old panel. Migrate it, check it, and Finish the import. Then start a new import from the same panel for the next hypervisor: servers an earlier import moved are skipped.

With Virtualizor, do the master server last. The hypervisors still on Virtualizor need it, and later imports connect to it.

A few more things help:

  • Tell customers the window. The import can schedule the start up to 30 days ahead and email each customer which of their servers move and how long they'll be down.
  • Install qemu-guest-agent in guests ahead of time if you're giving copies new addresses. It's how the node changes the address inside the server.
  • Move the quiet hypervisors first, and the busy ones once you know the process.

Step 5: Tidy up

Once a hypervisor's servers are adopted, the old panel's software is still on it. The finished import offers to remove it: the agent stops the old panel's services and cron jobs and moves its files aside, then checks that every server still runs and still has its network bridge. If a server stops or its bridge goes, it puts everything back. The import page also lists the same steps, for doing it by hand.

Finishing an import deletes the stored API credential. From then on, the servers are VorticPanel servers like any other: customers manage them from their panel, and your billing panel drives them through the API.

Related