Last week I performed a live physical to virtual migration for a customer. Ghetto style.
I was actually surprised by its simplicity and how well it turned out in the end.
Basically what I did was boot the target server to a live environment in order to be able to have raw access to the disk. In this case I’ve used FAI’s Sysinfo mode, but booting any Linux Live CD would have worked equally well. After it’s booted I’ve created the the necessary partitions, created filesytems and mounted them. When those steps were done it was time to sync data and make the virtual system bootable.
Usually I would advise against this kind of migration but in this case there was only static data involved.
It worked out well for me, but your mileage may vary.
Alright here’s what I did step by step…
1. Backup partition layout and MBR
source:~ # sfdisk -d /dev/sda > /tmp/source-partitions source:~ # dd if=/dev/sda of=/tmp/source-mbr.img bs=512 count=1 source:~ # scp /tmp/source-* target:/tmp/
2. Restore partition layout and MBR
target:~ # dd if=/tmp/source-mbr.img of=/dev/sda bs=446 count=1 target:~ # sfdisk /dev/xvda < /tmp/source-partitions
3. Create a filesystem on each partition
target:~ # for partition in xvda1 xvda6 xvda7 xvda8 xvda9 xvda10; do mkfs.ext4 /dev/$partition; done
4. Create a swap space
mkswap /dev/xvda2 swapon /dev/xvda2
5. Mount the newly created partitions
target:~ # mount /dev/xvda1 /mnt/tmp/ target:~ # mount /dev/xvda6 /mnt/tmp/var/ target:~ # mount /dev/xvda7 /mnt/tmp/tmp/ target:~ # mount /dev/xvda8 /mnt/tmp/usr target:~ # mount /dev/xvda9 /mnt/tmp/home/ target:~ # mount /dev/xvda10 /mnt/tmp/data/
6. Synchronise data from source to target
target:~ # for i in $(seq 1 10); do rsync -av --delete --progress \ --exclude=/dev \ --exclude=/sys \ --exclude=/proc \ --exclude=/mnt/ \ --exclude=/media/ \ source:/* /mnt/tmp/; done target:~ #
Repeat this step until you’re confident nothing has changed anymore.
7. Enter the synchronized environment
target:~ # mount -t proc none /mnt/tmp/proc target:~ # mount --rbind /dev /mnt/tmp/dev target:~ # chroot /mnt/tmp /bin/bash chroot:~ # source /etc/profile
8. Fix fstab entries
(only for Xen vm’s)
chroot:~ # sed -i 's+/dev/sda+/dev/xvda+g' /etc/fstab chroot:~ # vim /etc/fstab
9. Fix network settings
chroot:~ # vim /etc/network/interfaces
10. Make the system bootable
chroot:~ # grep -v rootfs /proc/mounts > /etc/mtab chroot:~ # grub-install --no-floppy /dev/xvda chroot:~ # update-grub
Once you’ve run the above commands it’s time to exit the chroot, unmount all partitions and reboot
into your migrated environment. Enjoy!
Hi,
The title of your post draw my attention. But as far as I can conclude from your post, you booted with a live cd which requires the machines services (when not booted in to down during your operation. Or am I wrong?
I also did a p2v lately and used Clonezilla which more or less does the same of what you did in an automated fashion.
Hi Vincent,
If I’m not mistaking the CloneZilla solution requires both servers to boot a live cd environment, thus disrupting the services.
Using the method I’ve written down only the target server is booted with a live cd or in this case pxe environment.
No services on the main (source) server are disrupted until you make the final switch to the new server. Which shouldn’t take more than a few minutes at worst.
I see, it seems read over this line :
Basically what I did was boot the target server”
It also explains this which I found rather weird
Ah, there you go. 🙂
Thanks for warning me about the dd typo!
target:~ # dd if=/dev/sda of=/tmp/source-mbr.img bs=512 count=1
should have been:
target:~ # dd if=/tmp/source-mbr.img of=/dev/sda bs=446 count=1