Migrating XEN (XCP-NG) Virtual machine to VMware ESXi

By Antti Hurme 24/08/2019 2 Comments 6 Min Read

There are quite a few guides out there, and by going thourgh probably hunders of sites and posts, here’s my take on migrating VMs from Citrix XEN XCP-NG to VMware ESXi. This method only requires access to source VM, XEN Server shell and VMware Conveter. No additional tools like Solardwinds V2V is needed.

NOTE: This has only been tested with Windows Guest Operating Systems from XCP-NG 7.6 to ESXi 6.5. So a fairly new setup. If you are converting Linux machines, do note that this will not work as the Xen Integration needs to be removed from the kernel. This is a completely different topic and haven’t written about it, so better continue your google fu for that one.

First we need to make a few preparations for the migration to work, do not skip these steps as you will end up with a non-bootable guest OS in VMware!

  1. Store your VM’s information in notepad, or whatever you prefer. Information needed is as following;
    • IP-Addresses of the guest
    • Drive letters (c:\, d:\ and so on)
    • Local Admin password (For Windows Recovery mode)
  2. Shutdown the Windows VM in XEN
  3. Take a snapshot of the VM in XEN
  4. Change the default RTL8139 adapter to Intel E1000 with the following command
    • xe vm-param-set platform:nic_type=”e1000″ uuid=UUID-OF-GUEST-HERE
    • Note: If you don’t do this, the default RT8139 adapter has a max link speed of 100Mbps while the intel one is a Gigabit adapter. Xen adapter does not work once integration is removed.
  5. Start the VM
  6. Login, and remove the Citrix XEN Integration from add/remove programs or msiexec /x “{ID-OF-INSTALLATION}”

Phew, quite a few steps to prepare the conversion. Hope you’ve done everything so far. And if your reading this guide with an older XEN server at your disposal, well do your homework and look up how to get the Intel e1000 adapter working. There are patch files available and so on, not sure if the command works with XEN 6.x for example. You can run the converter with the default RT8139 adapter, but it’s painful and slow.

Now it’s time to fire up your trusty VMware converter Standalone installation.

  1. Source: Powered on Windows Guest
  2. Destination: Your VMware Infrastructure Server (aka vCenter/ESXi). Note if you need to use Proxy Mode, now is the time to check that box.
  3. Destination Virtual Machine: Select your destination Folder and Guest name
  4. Destination Location: Select your destination Host/Resource Pool. Make sure you take a look at the destination datastore, that is has enough free capacity!
  5. Options:
    1. Data to copy: Personally I use thin provisioned disks. If you change the layout (for example shrink the disk), the migration will be a lot slower as it’s file based copy and not block based copy. However, you can change partition layout, like moving d:\ to it’s own independent virtual disk.
    2. Networks: VMXNet3 is quite the adapter to choose. However E1000 does work. I usually place the VM in an isolted network for intial configuration to avoid complications.
    3. Advanced Options:
      1. You can choose to syncrhonize changes (if required)
      2. Choose to power off source and power on destination
      3. Install VMware tools using the converter speeds things up.
  6. Start the converter task

Now it’s time to grab a cup of coffee and wait. VMware converter is slow, and i’ve experienced speeds around 15-25MB/s when migrating Windows VM’s. If you get around 2-3MB/s, well then you probably have the RT8139 adapter in your guest. Windows does show you the adapter type, so just check that out.

Once the conversion is complete, depending on your Advanced options the source and destionation will power on. If you selected to install VMware tools, don’t worry, it will proceed once your out of Windows Recovery. As you probably noticed, the guest VM won’t boot right away to Windows and will fail. This is due to XEN integration components being left behind, and you need to manually clean the disk. You can do this either using the recovery mode, or by mouting the disk to another VM (You could use your converter VM to do this).

The process is essentially the same, delete a bunch of files. Just take note of the drive letter when doing this. In my example the drive letter matches what you would expect to see in the recovery mode;

del d:\Windows\System32\xenagent_8_2_1_111.dll
del d:\Windows\System32\xenagent_8_2_1_111.exe
del d:\Windows\System32\xenbus_coinst_8_2_1_124.dll
del d:\Windows\System32\xenbus_monitor_8_2_1_124.dll
del d:\Windows\System32\xenbus_monitor_8_2_1_124.exe
del d:\Windows\System32\xeniface_coinst_8_2_1_111.dll
del d:\Windows\System32\xennet_coinst_8_2_1_102.dll
del d:\Windows\System32\xenvbd_coinst_8_2_2_215.dll
del d:\Windows\System32\xenvif_coinst_8_2_1_175.dll
del d:\Windows\System32\drivers\xen.sys
del d:\Windows\System32\drivers\
del d:\Windows\System32\drivers\xenbus.inf
del d:\Windows\System32\drivers\xenbus.PNF
del d:\Windows\System32\drivers\xenbus.sys
del d:\Windows\System32\drivers\xenbus_coinst.dll
del d:\Windows\System32\drivers\xenbus_monitor.dll
del d:\Windows\System32\drivers\xenbus_monitor.exe
del d:\Windows\System32\drivers\xenfilt.sys

Once those pesky remains are cleaned, reboot the VM. Now it should boot right back up to Windows. If you chose to automatically install VMware tools, then this will now begin automatically. It’s a silent installation, and the guest will reboot within 5 minutes again, even if you logged in. So don’t panic.

There’s one last thing to clean up from the guest once VMware tools have been installed. To get rid of XEN services, run the following commands;

sc delete xenagent
sc delete xenbus_monitor

That should be it, you’ve now migrated (Converted) a Windows Guest VM from Citrix XEN XCP-NG to VMware ESXi. There probably is a way to clean the system32 directory before conversion, and therefore skipping the recovery/mounting phase. If you know how to this, let me know and I’ll update the guide.

Written By

Who am I? | Linkedin

View All Articles
  1. Marcel says:

    Hi Antti.

    I was working on a Windows 2016, and it just wouldn’t work (2008R2 was much easier).
    I have added all of these in a batch in the VM before migration, to use in troubleshooting mode.


Leave a Reply

Your email address will not be published. Required fields are marked *

The reCAPTCHA verification period has expired. Please reload the page.

This site uses Akismet to reduce spam. Learn how your comment data is processed.