At work we have been using Onapp for almost a year now, and we have had a pretty bad run with it, possibly due to how we were using it.
The good points
- A fantastic GUI
- A simple user panel
- Fantastic technical support at levels 1 and 2
But, we also had a few bad:
- Issues with networks in Onapp
- Issues with migrating between hypervisors
I wont go on about it, as the team were fantastic in trying to work through the issues, but in the end, we lost too much confidence.
We made the decision to move from Onapp (Xen) to VMware, and we had some issues.
The VMware converter cant see any disks in the Onapp VMs! So we couldnt use the converter. All of the methods suggested in moving Xen VMs to VMware involved a lot of downtime and was intensive on the disks as it was a clone of the disk essentially. It also means that if you want to use thin provisioning in VMware, you will use space you don’t need. The imaging process will mark the free space on the disk as used to VMware thin provisioning.
After a long testing process involving many tests many ways, we settled on doing a rsync of the file system. I couldn’t find any information on a Onapp -> VMware conversion online, so i have posted my method here.
I am still working out how to do the 1 windows VM we have, when i find a way, i shall update this!
Update! Found a way. DiskIO. Make sure the source SAN is very low on IOPS, and the converter will work fine.
The below could be used for pretty much any Linux -> Linux migrations
On the source server:
Run the commands:
CentOS: yum install kernel kernel-devel
Ubuntu: None needed
Debian: apt-get install linux-image-amd64 rsync (you may need to add contrib non-free to the apt line top get rsync)
Enable SSH and password auth over ssh.
Open up SSH in the firewall
On the destination server:
Create a new VM in VMWare for the server
Boot the VM to the CentOS Rescue media (or another live distro of your choice)
Partition and format the disk:
lvm pvcreate /dev/sda2
lvm vgcreate vglocal /dev/sda2
lvm lvcreate -L2048 -nswap vglocal
lvm lvcreate -l100%FREE -nroot vglocal
mkfs.ext3 -L/ /dev/vglocal/root
Partitions – only if requested
Get the data:
mount /dev/vglocal/root /mnt/sysimage (LVM) OR mount /dev/sda3 /mnt/sysimage (partitions)
mount /dev/sda1 /mnt/sysimage/boot (partitions)
rsync -avpor –delete –exclude=proc –exclude=sys -e ssh [email protected]<sourceserverIP>:/ /mnt/sysimage
rerun this command as many times as you want to pickup all data (ie, if you are preparing days in advance)
When you are ready to do the switch from Onapp to VMware for real:
stop the services on Onapp (mysql, httpd, etc etc – anything that will change files)
Run the rsync one final time
turn off the Onapp instance and then proceed with the rest. It should take you about 15 minutes
Modify the fstab file
Edit it to include the boot line and adjust the partitions as needed.
You should end up with:
/dev/sda1 /boot ext2 defaults,noatime 1 1
/dev/vglocal/root / ext3 defaults,noatime 1 2 (LVM) OR /dev/sda3 / ext3 defaults,noatime 1 2
<rest of things, dont touch>
/dev/vglocal/swap swap swap defaults 0 0 (LVM) OR /dev/sda2 swap swap defaults 0 0
Modify as per fstab
Modify some other aspects:
comment out anything in there and add:
alias eth0 e1000
(if the server has a second NIC, also do this line again for eth1)
vi /mnt/sysimage/etc/sysconfig/network-scripts/ifcfg-eth# OR vi /mnt/sysimage/etc/network/interfaces
comment out the MAC address line if there is one
rm -rf *xen*
Remove all xen images. You should be left with one kernel only
make sure default is the correct number, where the first entry is 0
Modify the lines that say /boot/whatever to be /whatever (remove /boot, but leave the first /)
Modify the root= to read root=/dev/sda3 OR /dev/vglocal/root
Reboot the machine at this point to the distros live CD, if you are already in it, you need to reboot again
chroot into the system
mount /dev/vglocal/root OR mount /dev/sda3 /mnt/sysimage
mount /dev/sda1 /mnt/sysimage/boot
mount –bind /sys /mnt/sysimage/sys
mount –bind /dev /mnt/sysimage/dev
mount –bind /proc /mnt/sysimage/proc
grub-install –recheck /dev/sda
For Debian and Ubuntu, run:
mv /boot/menu.lst /boot/menu.onapp.lst
mkinitrd -f <latest kernel.img file>.img <the kernel version>
chkconfig sendmail off (this is needed if your network wont come up first go)
Let it boot without intervention to ensure all reboots ok!
Install the VMware tools
Hello there Alek
I have trying out your method. to migrate some system out of our OnApp environment. And at this point i’m stuck on the following step(s)
Modify as per fstab
* The problem here are, it is an symbolic link to a read only file i can’t change*
“And if i could edit it. i’m a bit unsure what to edit”
Modify some other aspects:
vi /mnt sysimage/etc/modprobe.conf
This file doesn’t exist
what i did to get here:
installed a centos 7 and boot into rescue mode (had to do this, since i didn’t have rsync,yum,and so on, in rescue mode before i installed the vm.
After that i made a secondary disk. “sdb” and follow along your guide.
The plan was to edit the fstab and all other files, to make sure that after all the edit, the system would boot on sdb and not sda.
Awesome to see that someone is still using this guide!
So that guide was originally written for CentOS 6. A few (a lot) of things have changed when going to CentOS 7 so a few things will need to be adapted.
mtab is similar to fstab, but rewritten on boot. In CentOS 7 this changed to a symlink in /proc. You do not need to modify this file now and you can skip this step.
modprobe also changed, this should be safe to ignore as the kernel changed how modules get loaded.
Your method should work fine, but I would suggest installing grub from a rescue environment / live environment.
You can use any live distro that has rysnc to do the initial sync. You only need the specific one for the later parts where you are reinstalling grub
If the rescue environment doesn’t have rsync, you should be able to wget / curl down a rpm and install it to the live environment.
Rescue environments are very lightweight, the live media should have rsync etc etc which would be better to use. That said, there is nothing wrong with how you are approaching this, it might just take a tad longer.
All the best with it! Let me know how you go.