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.