Introduction

Last year a customer asked me to migrate tens of Ubuntu machines from XenServer to OpenStack. The customer had version 6.2 running of XenServer, so in a LAB environment I built my own XenServer v6.2. I created some basic Ubuntu 12.04, 14.04 and 16.04 virtual machines with different sets of disk configurations (with and without LVM, multiple and single disks) and I exported them. I added support for VHD disks to my migration street (see Migrate to OpenStack), so I could add them in OpenStack. Unfortunately it was not that simple, I found 2 best practices for 2 issues:

• XenServer export: Export without compression. If you want you can compress later with tools like tar.
• Unbootable Ubuntu virtual machines (black screen after grub menu) may be fixed by the Boot-repair-disk.

Note: I did not try other Linux distributions or Windows virtual machines.

Export issues

Soon I discovered that a compressed exported (check box in the export wizard) disk is unreadable with the tools that I use. An export without compression was unusable with the libguestfs-tools, but the disks can be converted with the qemu-img convert tool. So, with a conversion to RAW or QCOW2 I could use the exported disks with the libguestfs-tools in KVM.

Broken grub?

There I hit another issue. The Ubuntu machines did not boot up completely, after Grub we had a black screen and a blinking cursor. I found out that the Boot-repair-disk fixes the issue. After further investigation I found out that the disk mounts all logical volumes, uninstalls all grub packages (grub*-common) from the virtual machines and reinstalls grub (packages: grub-pc grub-common grub-gfxpayload-lists grub-pc-bin grub2-common) from an Ubuntu repository.

Note: I discovered that this issue also applies to virtual machines that were created on XenServer 6.2 that was later upgraded to XenServer 7. I also had this issue when I tried to import the virtual machine on VirtualBox.

Offline boot-repair-disk

Our isolated migration environment does not have an Internet connection, so I had to come up with an other solution: Our own repository server with the necessary packages. A new virtual machine (Ubuntu 16.04) machine was born and resides in the same virtual network as the imported virtual machine. There are several instructions for building a repository server, like on Ubuntu Help wiki. I created 3 directories, for precise, trusty and xenial and put the deb-files (see previous) in it. The files can be downloaded from the Ubuntu repository https://packages.ubuntu.com/.

I used a customized SystemRescueCd  with a script that chroots to the vm, uninstalls grub*-common and then installs the packages from the repo server.