Migration from XenServer

This guide explains how to migrate the virtual server from Citrix XenServer to OnApp Cloud.

You use this guide at your own risk. We will not be held liable for any damages caused during the migration process. 

On this page:

Migration from XenServer

Prepare for .xva Export

  1. Create a temporary Logical Volume called export001:

    #> vgdisplay | grep "VG Name" | awk '{print $3}' | xargs -i lvcreate {} -L200G -n export001

  2. Format the Logical Volume ext3:

    #> mke2fs -j /dev/mapper/[VolGrp]-export001

  3. Create a directory for mount:

    #> mkdir /tmp/export

  4. Mount the Logical Volume:

    #> mount /dev/mapper/[VolGrp]-export001 /tmp/export

Export and Transfer vda File

Run xe vm-list and identify the uuid of the relevant VS.

  1. Export the vda file:

    #> cd /tmp/export
bash#> xe vm-export vm=[UUID] filename=vm1.xva

  2. Transfer the file over to our temporary server:

    #> scp vm1.xva root@[TEMP_SERVER_IP]:/tmp/

Prepare Temporary Server

  1. Download and install cmake: 

    #> yum install gcc gcc-c++ openssl-devel
#> wget http://www.cmake.org/files/v2.8/cmake-2.8.4.tar.gz 
#> tar xzvf cmake-2.8.4.tar.gz
#> cd cmake-2.8.4
#> ./configure
#> gmake
#> make install

  2. Download and install xvatool: 

    #> wget http://datahack.se/datastore/xvatool/xvatool-1.1.tar.gz  
#> tar xzvf xvatool-1.1.tar.gz
#> cd xvatool-1.1
#> cmake 
#> make install

Convert the .xva File

  1. Convert the xva to img: 

    #> cd /tmp
#> mkdir VM1
#> tar -xf vm1.xva -C VM1
#> chmod -R 755 VM1xvatool -p disk-export VM1/Ref\:X/ disk.raw


  2. Identify the partitions and mount them up as necessary.

    Every server will most likely contain different partitions and different partition types, so… 

  3. You can identify what physical partitions the server has by running the following command:

    #> kpartx -a -v disk.raw  

    From here you will need to mount up each partition individually until you find the / partition. Once you have found this, you will be able to cat the fstab and see the partition layout. If possible it would be easier to view this on the running XenServer VS.

  4. Any partition that you are unable to mount as a loop device will most likely be a partition containing LVM data, so you will need to do the following to identify these:

    #> vgscan
#> lvscan

  5. Now you can mount up the server ready for OnApp export. In the example below, we have a fairly simple CentOS x64 installation using LVM with a raw ext3 boot partition. Here's a copy of the original fstab for your reference:

    [root@test ~]# cat /etc/fstab 
/dev/VolGroup00/LogVol00 /                 ext3    defaults        1 1
LABEL=/boot             /boot              ext3    defaults        1 2
tmpfs                   /dev/shm           tmpfs   defaults        0 0
devpts                  /dev/pts           devpts  gid=5,mode=620  0 0
sysfs                   /sys               sysfs   defaults        0 0
proc                    /proc              proc    defaults        0 0
/dev/VolGroup00/LogVol01 swap              swap    defaults        0 0

  6. Now we have this information and can mount up the server locally:

    #> mkdir /tmp/mnt
#> lvchange -ay VolGroup00/LogVol00
#> mount /dev/mapper/VolGroup00-LogVol00 /tmp/mnt/

  7. As the /boot partition is a raw ext3 partition, we  can just mount it as a loop device:

    #> mount -o loop /dev/mapper/loop1p1 /tmp/mnt/boot/ 

    We are ignoring the swap partition here. It will be added later when the VS is imported into OnApp.

  8. Now you can see your complete VS mounted up on my temporary server: 

    [root@tmpserver1 mnt]# ls -al
total 186
drwxr-xr-x  23 root root  4096 Jul  5 14:07 .
drwxrwxrwt   5 root root  4096 Jul  5 14:14 ..
drwxr-xr-x   2 root root  4096 Jun 15 16:55 bin
drwxr-xr-x   4 root root  1024 Jun 15 15:47 boot
drwxr-xr-x   4 root root  4096 Jul  5 13:29 dev
drwxr-xr-x  75 root root  4096 Jul  5 13:42 etc
drwxr-xr-x   2 root root  4096 Mar 11  2009 home
drwxr-xr-x  11 root root  4096 Jun 15 16:55 lib
drwxr-xr-x   7 root root  4096 Jun 15 16:55 lib64
drwx------   2 root root 16384 Jun 15 15:44 lost+found
drwxr-xr-x   2 root root  4096 Mar 11  2009 media
drwxr-xr-x   2 root root  4096 Sep  4  2009 misc
drwxr-xr-x   2 root root  4096 Mar 11  2009 mnt
drwxr-xr-x   2 root root  4096 Mar 11  2009 opt
dr-xr-xr-x 122 root root     0 Jul  4 12:13 proc
rwxr-xr-x   2 root root 12288 Jun 15 16:55 poweroff
drwxr-x---   2 root root  4096 Jun 29 11:50 root
drwxr-xr-x   2 root root 12288 Jun 15 16:55 sbin
drwxr-xr-x   2 root root  4096 Jun 15 15:44 selinux
drwxr-xr-x   2 root root  4096 Mar 11  2009 srv
drwxr-xr-x   2 root root  4096 Jun 15 15:44 sys
drwxrwxrwt   3 root root  4096 Jun 29 11:51 tmp
drwxr-xr-x  14 root root  4096 Jun 15 15:46 usr
drwxr-xr-x  19 root root  4096 Jun 15 15:46 var

Import to OnApp Cloud


Before performing further actions, SSH into your temporary server (ideally you would not do this directly on the OnApp compute resource or CP as you will be installing RPMs.)

Make Changes for the OnApp Cloud Import

To prepare for the OnApp Cloud Import:

  1. Chroot the mounted image and make the following changes: 

    #> cd /tmp/mnt
#> chroot .
#> rm poweroff
#> rpm -e xe-guest-utilities
#> rpm -e xe-guest-utilities-xenstore
#> chkconfig --del kudzu

  2. Update fstab with the following data: 

    /dev/sda1 /                       ext3    defaults        1 1/dev/sda2 swap                    swap    defaults        0 0 

  3. Update /boot/grub/grub.conf and alter a few things: 

    kernel /boot/vmlinuz-[kernel-version.[distro]xen ro root=/dev/sda1 console=tty0

    Make sure the location of the initrd and the kernel are correct. Make sure /dev/sda1 is set to root. Make sure console is set to tty0.

  4. Update the following in /etc/inittab:

    The first console should be configured to run on tty in all runlevels. In most cases, this line (1:2345:respawn:/sbin/mingetty tty1) should be the only line not commented out. You will most likely need to comment on the Xen-specific line.

  5. Exit chroot environment before you continue:

    #> exit

  6. Create the OnApp package: 

    #> cd /tmp/mnt
#> tar -czvf /root/ExampleOnAppExport.tar.gz

Import the OnApp Cloud Image

  1.  SSH into the OnApp CP server.

  2. Transfer over the template to the OnApp template store (On the OnApp CP server):

    #> scp root@[TEMP_SERVER_IP]:/root/ExampleOnAppExport.tar.gz /onapp/templates/

Insert Template in the Database and Finish up

  1. Add the MySQL entry into OnApp: 

    #> grep password /onapp/interface/config/database.yml #> mysql -u root -p[password] onapp

  2. For CentOSdistros: 

    INSERT INTO templates 
      VALUES(
'19', # Template ID, increment by 1 each time or just leave as '' for auto-increment 
 'my_new_template_name', # An alias name for you new template
 '2010-12-01 22:20:25', # Template create date/time
'1.0', # Version, update as necessary
'[you_new_template_name].tar.gz', # File name (the gzip you created above
'linux', # The OS, should always be linux or windows ?
'ubuntu', # The distro, ubuntu for ubuntu and debian, rhel for centos
'1', # allow swap, always 1 for linux
'active', # stats, always active
'', # checksum, run mdksum [you_new_template_name].tar.gz
'1', #allow resize without reboot, 1 for centos, 0 for ubuntu
'10', # minimum disk space, check the size of your volume before tarballing it.
NULL, # userid, leave as null unless you know it
NULL # template size, leave as null
); 

  3. Here is our example from earlier: 

    INSERT INTO templates VALUES ('','onapp-test001','2011-07-05 12:58:55','2011-07-05 12:59:05','1.0','v5zarb85et9box_20110705135855','linux','rhel',1,'active','4c46ba5f7af2eb6a472800f534cb3d8a',1,8,2,316976,1,'x64',NULL,NULL,1,NULL);

  4. The final step is now to create the VS via either the OnApp Control Panel UI or the OnApp API using the template created above.

    You will also need to clean up, remove the template file and database entry, and remove the LogVol from the Citrix installation using lvremove.