Warm migration with XO

Discover how warm migration can help you to handle different and complex migration scenarios.

Warm migration with XO

This is a cool feature (pun intended) coming in our next release, which is tomorrow! I wanted to give you a preview on this exciting feature, and since it's a bit long to explain, having a dedicated article on it was the right thing to do.

First, let's give some context on why this feature was born. Imagine you have a first datacenter where all your VMs are running on Intel Xeon CPUs, and some of those VMs have pretty large disks. Now you want to migrate those to a new datacenter running on AMD EPYC CPUs. There's 3 options:

  1. Live migrate: won't work in this situation, CPUs are different vendors.
  2. Shutdown the VM: you need to shutdown the VM, then "cold" migrate to the destination. Pro: relatively simple. Con: your VM will be offline for a while.
  3. Create a continuous replication job: replicate the VM to the destination while it's running, shutdown, re-replicate the delta, and boot on destination. Then remove the source. Pro: downtime reduced, pretty solid way to migrate. Con: complicated process.

Even if it's complicated, option 3 is the most reasonable one. So we wanted to offer you this option in a simple manner, with the same simplicity of option 2. Best of both worlds, right? So automation is key.

When you click on the "Warm migration" button, you'll select the destination SR and if you want to keep the VM on the old source:

Under the hood

As soon you click OK, Xen Orchestra will do all of that automatically. Here are the details for each step happening with our previous example, on a rather large VM with a 2TiB disk, filled with 1TiB of actual data:

You have 2 different hosts with different CPU vendors, but you want to move the VM from one place to the other.
Just after you clicked the "Warm migration" button, the process will kick-in. First, a snapshot is done on the source VM, and entirely transferred to the "replicated" VM. This step is the longest one, but it happens while the original VM is running. No visible impact, despite, in this example, we have to move 1TiB worth of data.
The critical step: source VM is shutdown, a new snapshot is done and we transfer the differential between the initial and the latest snapshot. In this example, there's only 3GiB to replicate, so the downtime will be minimal (few minutes tops).
As soon this minimal diff is sent, we will boot the destination VM and remove the source one (if you tick "boot after migration" and "remove source VM after migration").

And that's it! With a simple click of a button, we did all the heavy lifting for you. Your downtime is greatly reduced and you can do this kind of migration in ANY CASE, regardless of the CPU model on destination. It's very safe.

Various use cases

Migrating from one CPU type to another isn't the only use case for this feature. For example, we have customers coming from XenServer, sometimes pretty old versions. Live migration might work, but sometimes it's risky. With the warm migration, we support risk-less migrations down from XenServer 6.5!

It's also useful when you are migrating to a completely different environment, with a different network architecture, and you know that a live migration will cause more problems than it will solve. And there's probably even more use cases than we thought!

Finally, we also decided to stay on the safe side: we made the choice to NOT toggle "start on destination" and "remove on source" by default, so it won't be destructive if you click on this migration without thinking about the implications.