Tech

A manual Linux migration into OnApp, from start to finish

Paul Morris

Paul Morris
Professional Services Manager

In this article we’ll take a look at how to manually migrate a Linux virtual machine into OnApp from any destination environment, using an exported raw disk image.

First let’s fetch the image from FTP. In this example this image has been exported from a VMware environment and is already in a raw format, so we will not need to use the vmware-mount tools here. Whereas something like a qcow2 image would need to be converted to a raw format using qemu-img.

The basic migration process described below will work for any raw disk image regardless of where it has been exported from. However the OS distribution inside the disk image must be supported by OnApp.

Ok, let’s fetch the image from FTP:

cd /home/onapp/import/image/bnx01 ftp> get bnx01-flat.vmdk
local: bnx01-flat.vmdk remote: bnx01-flat.vmdk 227 Entering Passive Mode (82,134,122,22,244,23). 150 Opening BINARY mode data connection for bnx01-flat.vmdk (32212254720 bytes). 226 Transfer complete.
 32212254720 bytes received in 586 secs (54984.75 Kbytes/sec)
. ftp> quit 221 Goodbye.

At this stage we are unsure of exactly how the source environment has been configured. If the system disk is using LVM to manage partitions, we would need to activate the logical volumes before we can map the partitions. In my example below there is no LVM present, so we can simply run kpartx directly on the disk image and list the partitions with the -l flag once activated.

Map the partitions inside the disk image:

[root@cp bnx01]# kpartx -a bnx01-flat.vmdk [root@cp bnx01]# kpartx -l bnx01-flat.vmdk 
loop1p1 : 0 54525952 /dev/loop1 2048
loop1p2 : 0 2 /dev/loop1 54530046
loop1p5 : 0 8382464 /dev/loop1 54530048

In this example we have a very simple layout with only a single system partition and swap space. One important thing to remember is that OnApp supports a single partition for Linux virtual machines, so any additional partitions such as /boot, /home would need to be consolidated in the steps below, before the data is transferred. This can easily be done by mounting the correct partitions before we run the rsync.

We should mount the system partition to verify what distribution is running inside the disk image, as we will need this information in the step below. We can also take this opportunity to verify the partition layout.

[root@cp bnx01]# mount /dev/mapper/loop1p1 mnt/
[root@cp bnx01]# cd mnt/ [root@cp mnt]# chroot .
root@cp / $ cat /etc/debian_version 
wheezy/sid root@cp / $ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/sda1 26G 17G 7.9G 68% /
sysfs 26G 17G 7.9G 68% /sys
udev 26G 17G 7.9G 68% /dev
devpts 26G 17G 7.9G 68% /dev/pts
[root@cp mnt]# exit

At this stage we will need to build the virtual machine inside OnApp. We must choose the correct distribution from our information above, and the correct specifications and disk size should also be set when provisioning. Once the provisioning is complete, shut down the virtual machine and identify the virtual disk and datastore identifiers using the OnApp Control Panel GUI, as we will need these in the next steps.

https://demo2.onapp.com/virtual_machines/hrdugifu88nm6k Primary disk: https://demo2.onapp.com/virtual_machines/hrdugifu88nm6k/disks/722 Disk Identifier: 4ydhvtfkmsrje2
Datastore Identifier: lgnx53mqopcshb
Disk size: 32 GB

Once we have the relevant information and the destination virtual machine has been shut down, we can mount the destination disk on the OnApp backup server or hypervisor. I always try to use the backup server where possible to avoid any additional workloads in the control domain of the hypervisors.

In our example below you can see that the destination platform is running OnApp’s distributed storage system, so we will use the API to bring the vdisk online. If your destination platform is running shared or local storage you can simply use lvchange to activate the logical volume.

[root@cp bnx01]#ssh root@10.9.10.52
[root@10.9.10.52 ~]# onappstore getid
unicasthosts= backends=10.200.6.1 ipaddr=10.9.10.52 result=SUCCESS uuid=3344435579 completion_time=0 [root@10.9.10.52 ~]# onappstore online uuid=4ydhvtfkmsrje2 frontend_uuid=3344435579
result=SUCCESS completion_time=10 [root@10.9.10.52 ~]# kpartx -a /dev/mapper/4ydhvtfkmsrje2 
[root@10.9.10.52 ~]# mount /dev/mapper/4ydhvtfkmsrje2p1 /mnt

Once we have the source and destination volume active and prepared, we can transfer the data across and tidy up.

[root@cp bnx01]#rsync -avx /home/onapp/import/image/bnx01/mnt/ root@10.9.10.52:/mnt/ [root@10.9.10.52 ~]# umount /mnt
[root@10.9.10.52 ~]# kpartx -d /dev/mapper/4ydhvtfkmsrje2
 [root@10.9.10.52 ~]# onappstore offline uuid=4ydhvtfkmsrje2
result=SUCCESS completion_time=12

Modifications to fstab/menu.lst/devices.map were necessary, as the block device name had changed. It would also be necessary to change the kernel path here if you were to remove a /boot partition. A RebuildNetwork was performed to reconfigure network settings inside the virtual environment and a ResetRootPassword to update the root password to match that in the OnApp Control Panel.

Please note that when manually migrating servers into OnApp there could be possible issues with the way OnApp supports the virtual environment. Any of the steps above could differ depending on configurations inside the virtual environment and various configuration settings inside OnApp.

If you have any questions on manual migration into OnApp, please contact our professional services team for assistance – we’re happy to help.