Migrate from VMware to XCP-ng
Since VMware 6 is now end of life (EOL), if you're one of their customers you might be exploring other virtualization options. This might be due to, among other reasons, their new licensing model and recent acquisition by Broadcom. Of course, migrating away from VMware sounds a little scary. Due to the closed source nature of VMware, it is sometimes difficult to find migration tools, and even when they exist, it is never as simple as it seems - as each infrastructure has its own constraints. The conversion process itself can take several days depending on your storage configuration and number of VMs you need to migrate.
You're in luck though, many users have already made the move to XCP-ng and we've amassed great expertise in this area. In this blogpost I'll share all the useful elements to help you undertake this migration.
We suppose you are reading this post because maybe you heard about XCP-ng. But why migrate to XCP-ng and not something else?
🚀 Why XCP-ng?
Before discussing a migration, let's recap the obvious reasons to make the transition:
- Fully Open Source with a great diverse and active community: you will never be alone, and the "Broadcom threat" is mitigated!
- Secure: XCP-ng is using Xen at its core, and security is one of our priorities, with all security updates (along with the rest) being 100% free.
- Easy to use: unlike other Open Source alternatives, XCP-ng is meant to be easy to use, -an appliance-, especially if you don't have Linux skills.
- Similarity with VMware: as a type 1 hypervisor, with similar components, XCP-ng can be compared to ESXi and Xen Orchestra to vCenter (and even VEEAM!).
- Broad hardware compatibility: keep your existing hardware if you want, XCP-ng will work fine on it. Even if it's not cutting-edge!
- You are backed: Open Source doesn't mean without professional support! Vates is the main developer behind XCP-ng, able to provide 24/7 support in 1h response time.
- Simple and transparent licensing: no need to have a five year degree in VMware licensing to plan your budget. Just visit our pricing page to learn the support cost.
🧭 How to migrate?
There's multiple ways to make a VM migration from VMware to XCP-ng. The first thing you need to know: we are here to assist you in the whole process! From giving you some advice to actually performing it for you, we provide a broad range of skills to reduce your migration investment (time and money) without any commitment or cost on your side. Yes, it's part of our support.
The automated way: XO V2V
We are working on various options to get some automation for larger infrastructures. The first one we did is a small script able to read OVF files and automatically create the corresponding VMs on destination. However, it depends a lot on the VMware version, so instead, we decided to work on a more streamlined way to achieve that, directly integrated in Xen Orchestra. And we did it! This is the tool we call Xen Orchestra "V2V", or "VMware to Vates".
Another goal is to achieve this migration the same way that we do in Xen Orchestra natively for XCP-ng: continuous replication. In short, the idea will be to export a first snapshot of the VM (on VMware side): this can take time but the VM will still be running, so it's also transparent. When this first "full" replication is done, we could shutdown the VM, export only the new blocks since the snapshot, and finally start it on destination (XCP-ng side). This way, we could reduce the downtime a LOT, especially for big VMs. And obviously, it can be somehow automated so you don't have to even track the progress.
Pros:
- Natively managed: this is directly integrated into Xen Orchestra.
- Very small downtime: shutdown, replicate only the delta and boot on destination!
- Automated: you could do that by selecting multiple VMs and let the software do the rest for you.
Cons:
- In some cases, if it doesn't work, you might try the other options.
From the UI
It's pretty simple. In your Xen Orchestra UI, go into the main menu in the left, on the "Import" then "From VMware" option:
After giving the vCenter credentials, you can click on "Connect" and go to the next step:
On this screen, you will basically select which VM to replicate, and to which pool, storage and network. When it's done, just click on "Import" and there you go!
From the CLI
You can also use the CLI to do it. In very short, it looks like this, using xo-cli:
xo-cli vm.importFromEsxi host=<VSPHERE_IP> user=<VSPHERE_USER> password=<VSHPERE_PWD> sslVerify=<true|false> vm=<VSPHERE_VM_ID> sr=<SR_UUID> network=<NETWORK_UUID>As you can see, it's pretty obvious. Just gather all the information needed to contact the VMware side (IP, credentials, ssl check or not and the ID of the VM). On the XCP-ng side, just provide the destination SR and network.
Now, you can see the transfer progress in the "Task" view of your Xen Orchestra UI. As soon it's done, you can directly boot the VM!
Alternatives
If you want to test other solutions, we are also presenting alternatives so you can have a whole panel of things to try.
The OVA way
The idea behind this migration process is pretty simple. OVA exports are supported in VMware 6.x. An OVA is a big single file using the Open Virtualization Format, which is a standard. Inside this OVA, you have an XML describing the metadata (VM name, description…), and then your disks in the VMDK format.
That's why an OVA (even with a VMDK format inside) can be imported in XCP-ng via Xen Orchestra, the vCenter equivalent. This is documented here:
Of course, there are a few things to consider when doing a migration like this, especially if you have a very large number of VMs to migrate.
Pros:
- Safe: since the exported VM can be tested on destination while the original can still run on source.
- Standard and free: OVA is an industry standard, and supported for free in both VMware and XCP-ng/Xen Orchestra.
- Simple: the process is very simple to achieve, no need to train.
Cons:
- Downtime to plan: the OVA can only be exported while the VM is off (except if you export a clone, but all blocks written after the clone won't be on the imported VM. If you can sync after, it's fine!). This can take a while, and your VMs won't be reachable until it's fully exported AND imported on destination.
- Needs some space: you need an intermediary storage where you can export then import the OVA file. If your VMs are small, it's OK.
- Manual process: even if it's simple to do, it can be cumbersome if you have a lot of VMs to migrate.
CloneZilla
This options is an alternative to the OVA. In a nutshell, you'll insert a CloneZilla live CD in your existing VMware VM, and boot on it. In the meantime, you also have a VM on the destination with the right metadata (same name and disks), which you'll also boot with CloneZilla.
Then, from the VM console, you can tell the source VM running CloneZilla to send all the blocks to the destination VM, also running CloneZilla. As soon it's done, you can safely shutdown the original VM and boot the copy on destination!
Pros:
- Fast: no need to export and import sequentially, you send directly the blocks from one VM to another.
- No need for extra space: no intermediary storage needed!
- Flexible: it works for any VM or even physical machines.
- Free: CloneZilla is free software.
Cons:
- Some downtime to plan: even if the downtime will be reduced vs the OVA way, it's still required to do the export/import while the VM is off.
- Setup time: not complex, but need various operations until you can start the replication for one VM. If you have a lot of VMs, this can take some human effort.
🗺️ Other considerations
Migrating from VMware to XCP-ng is not just a technical operation on one VM, it's a process. And the duration of the migration depends on various factors. Let's see them!
Number of VMs
Obviously, the more VMs you have to migrate, the longer the process will take. It is important to measure the size of your infrastructure before embarking on such a migration process. If you have hundreds or even thousands of VMs you want to migrate, you may want to consider using an export/import script to automate this. This is something we can help with!
Disk size
The size of your VM disks is important. Remember that on XCP-ng you can't have disks larger than 2TiB each. Even without exceeding this limit, the larger a VM is, the longer and riskier the process will be.
It's a good idea to clean up your disks before starting the migration process so that you only export the data you are sure you want to keep.
Hardware performance and compatibilities
Beyond the volume of VMs and data you wish to transfer, you must also take into account the performance of your hardware itself. SSD or HDD? Network hardware performance? RAM and CPU availability? All these elements will have an impact on your migration.
As far as hardware compatibility is concerned, the good news is that XCP-ng is compatible with almost any x86 hardware available on the market - we are ready to support any infrastructure that runs on x86 servers.
🧑💻 Our migration assistance
We can help you to get started with XCP-ng. Our experts are highly skilled and experienced in setting up, managing and troubleshooting XCP-ng.
There is no reason to embark on a project like this alone, and accompanying you and showing you the best way forward is part of our XCP-ng Pro support.
Read more on why our support is very different than anyone else:
Olivier Lambert
🫶 Become a partner
Beyond virtual infrastructure users, you may also be a solution integrator for your customers and you might be looking for an alternative to VMware.
You can already join our partner program for Xen Orchestra and we are in the process of creating a partner program around Vates solutions. We would be happy to discuss the options we can offer you!
🎯 Conclusion
The transition from VMware vSphere to XCP-ng is not as difficult as it seems. The biggest hurdle is re-organizing your infrastructure and updating policies and procedures to accommodate the new architecture and functionality of XCP-ng. If you are looking at migrating from VMware 6 and you don't want to do that alone, our pro support is here to assist you from the design of your future infrastructure to the actual implementation of it.
Want to test it first and build a proof of concept? No paywall, just download and try!
