How to migrate a Linux VM from Xen to KVM in OnApp clouds

Paul Morris

Paul Morris
Professional Services Manager

OnApp clouds natively support both XEN and KVM compute resources, and it’s possible to migrate XEN VMs over to KVM by following the steps below. We support migrations for both Linux and Windows VMs, but in this guide we’ll cover the Linux migration process only.

Please note that this guide assumes you have incremental backups enabled for your cloud. You will need to perform all steps as an administrator of the cloud, and you will also need root access for database changes. If you have a database password set from root you can find the mysql login details in /onapp/interface/config/database.yml.

Also note that the backup process demonstrated in this guide is only taking a copy of the primary system disk: VMs with additional disks will require further steps to migrate. You should talk to OnApp Professional Services if you need assistance with additional disks.

Ok, on with the guide.

1. Take the base template ID from the database

Access the database from root on the cp server.

[root@cloudcp ~]# mysql onapp
MariaDB [onapp]> select template_id from virtual_machines where identifier='hbqcsvfbnstyah'\G
*************************** 1. row ***************************
template_id: 500
1 row in set (0.00 sec)

We will need this later to restore the migrated image back to the base template so make a note of it.

Be careful when performing any changes on the database – make sure you have a backup first.

2. Take a backup of the VM while it is still running – this should make the next backup faster and minimize downtime

From the VM overview page go to Storage > Disks > Backup, it’s only necessary to backup the primary disk, no need to backup the swap disk as that will be created when we provision the VM on the KVM zone later.

3. Update the boot configs inside the VM

In most cases the kernel will have been upgraded since the VM was first provisioned, so we need to create a new grub.conf.kvm_virtio configuration file before we build a template. We can do this by modifying the XEN config that is already in place. It will have a few differences which we will need to change first.

#backup the files before we write to them
root@server [/boot/grub]# cp grub.conf.kvm_virtio grub.conf.kvm_virtio_bak
root@server [/boot/grub]# cp grub.conf grub.conf_orig
#make the necessary changes to the config
root@server [/boot/grub]# sed -i -e 's/xvda/vda/g' grub.conf
root@server [/boot/grub]# sed -i 's/console=tty0//g' grub.conf 
#copy it into place
root@server [/boot/grub]# cp grub.conf grub.conf.kvm_virtio
cp: overwrite `grub.conf.kvm_virtio'? y

Here I’ve taken a copy of the files and updated the config to change the block device from xvda to vda and removed the console flag from the kernel config. Then I will overwrite the grub.conf.kvm_virtio file with the updated config. Note that if you are running a template that does not support virtio, then you should overwrite the grub.conf.kvm too. In this case the block device and parameters could be slightly different but you can use the original grub.conf.kvm file to make comparisons first.

Contact our professional services team if you are unsure about any of the steps here.

4. Perform a shutdown of the VM from the UI

From the VM overview page, shutdown the VM.

5. Take a final backup whilst the VM is offline

Repeat the process in step 2 above to backup anything that may have changed before the shutdown. This backup will finish quickly as there will be few changes.

6. Make a note of the IP address, then remove it from the interface

From the VM overview page go to Networking > IP Addresses and delete the IPs, first making note of them as we will add them to the new VM later.

7. Convert the latest backup to a template

From the VM overview page go to Backups > Images, choose the latest backup and convert it to a template. Call it something sensible so we can find it easily in the next step.

8. Provision the VM on the new zone

Take note of the specifications of the original VM as you will most likely want to provision an identical VM on the new zone.

You will see the new template in the build wizard. We will update the IP address in the next step.

9. Update the IP address of the new VM

OnApp will choose an IP address at random from the network chosen when you provisioned the VM. We will remove this and add the same IP address we noted in step 5.

From the VM overview page go to Networking > IP Addresses, remove the automatically assigned IP, and manually add the IP from step 5.

Once complete hit Rebuild Network and choose the force option.

10. Update the template ID using the template_id from step 1

We will update the database to restore the base template_id we noted in step 1. Doing this will allow the end user to rebuild the VM with a clean image and not the converted backup we created to migrate.

Access the database from root on the cp server:

[root@cloudcp ~]# mysql onapp
MariaDB [onapp]> update virtual_machines set template_id='500' where identifier ='bsilnlrybtpbom';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

Be careful when performing any changes on the database. Make sure you have a backup first!

11. Update the VM’s owner

You will have performed the steps above as the admin user. If the VM was created by an end user of the cloud, you will need to change the VM’s owner.

From the VM overview page go to Tools > Change owner, and select the correct user.

12. Remove the template and clean up

Once the migration is complete you can remove the template you created earlier and delete the source VM.

Go to Templates > Template list > My templates, and delete the template

Delete the source VM from the template overview page Tools > Delete virtual server

You can choose to keep the most recent backup when removing the source VM, so you have a backup if there are any issues.

13. Login to the virtual environment and check the /etc/hosts file

Check that the correct IP address and hostname are set, as this can prevent some services from starting at boot. You can reboot the VM once more if you made any changes here.