The test case scenario is a conversion from an HP BL460 to a Version 4 ESX VM, with LSI Logic parallel virtual SCSI controller and one e1000 vnic.
Linux version is Red Hat 5.5 x64
UPDATE: I've made some encouraging experiments with 6.2 also
Important: this method does not guarantee data consistency, as the disk will be copied while active, but it's usually good enought to bring up a bootable copy of the source machine where you can later restore a consistent backup.
On the other hand, this procedure gives way less downtime than a cold clone, and you can test the cloning process without halting the source machine.
Onward I will call the source machine "P" and the destination machine "V".
Take note of the P disk configuration
# fdisk -l /dev/cciss/c0d0
Disk /dev/cciss/c0d0: 146.7 GB, 146778685440 bytes
255 heads, 32 sectors/track, 35132 cylinders
Units = cylinders of 8160 * 512 = 4177920 bytes
Device Boot Start End Blocks Id System
/dev/cciss/c0d0p1 1 25 101984 83 Linux
/dev/cciss/c0d0p2 26 23961 97658880 8e Linux LVM
This is an HP machine with a SmartArray controller.
Create a new VM, called V, with a disk at least as big a the P one: in this case I've created a 147GB vmdk.
Boot the V VM into rescue mode.
boot: linux rescue
Start the network interface and assign an IP enabled for SSH with the P machine.
Skip searching for existing installations.
All the following commands are to be executed on the V machine.
Now dump the P hard drive to the V vmdk:
# ssh root@P "cat /dev/cciss/c0d0 | gzip -1 | cat" | gzip -d >/dev/sda
note that this compresses the data over the wire, as this usually leads to faster transfers, even more if the disk has many empty sectors.
After completion, an fdisk should display the same partition table of the P machine on the V machine
# fdisk -l /dev/sda
Disk /dev/sda: 157.8 GB, 157840048128 bytes
255 heads, 32 sectors/track, 37779 cylinders
Units = cylinders of 8160 * 512 = 4177920 bytes
Device Boot Start End Blocks Id System
/dev/sda1 1 25 101984 83 Linux
/dev/sda2 26 23961 97658880 8e Linux LVM
Reboot V into rescue mode again
boot: linux rescue
This time choose to search for existing installations, as it should find the new disk content.
# chroot /mnt/sysimage
Make sure the LVM has seen the new disk
# pvscan
PV /dev/sda2 VG VolGroup00 lvm2 [93.13 GB / 59.13 GB free]
If you don't see the PV, check /etc/lvm/lvm.conf for any filter other than the default one.
Modify the boot modules list taking as an example those of another identically configured VM.
This is the modprobe.conf of a tipical ESX VM.
# vi /etc/modprobe.conf
alias eth0 e1000
alias scsi_hostadapter mptbase
alias scsi_hostadapter1 mptspi
alias scsi_hostadapter2 ata_piix
Rebuild the initial ram disk, as referenced in the grub.conf
# mkinitrd -v -f /boot/initrd-2.6.18-194.el5.img 2.6.18-194.el5
Reinstall grub, just to be safe (it should be already there from the disk cloning process).
# grub-install /dev/sda
Now note that, after reboot, the V machine will start with the same IP address of the original P one.
If it doesn't suit your need, change the IP address in /etc/sysconfig/network-scripts/ifcfg-eth0
Now you can reboot the V machine.
If the M machine was at runlevel 5, the V machine may start with corrupted graphics because of the different video driver of the VM.
Switch to runlevel 3 and reconfigure X with
# system-config-display --reconfig
Now you can proceed with vmware-tools installation as usual on VMs.
thanks for sharing, taking the same case (CentOS5) and it worked very well
ReplyDeleteRegards
great post! I've tried it on a Centos 6.0 server and it worked like a charm on the first attempt.
ReplyDeleteTHANX!!!!
Thanks!
ReplyDeletepvscan did not show any disks. By removing the filter in /etc/lvm/lvm.conf and then regenerate an initrd solved my problem.
Hi Alessandro,
ReplyDeletegreat manual, thank you. But when I'm executing the command:
ssh root@P "cat /dev/cciss/c0d0 | gzip -1 | cat" | gzip -d >/dev/sda
I'm getting message:
cat: invalid option -- g
Are you sure in the syntax of the command?
Thank you in advance!
Vladimir
Command were tested.
DeleteAre you sure your boot disk is on /dev/cciss?
roughly how long should it take to dump the P disk to the V disk? My disk is question is 100GB.
ReplyDeletethat's really dependent on how much of your 100GB is actually used and squizable.
Deleteanyway, since the procedure is non-disruptive, you can dry-run it and see how long it'll take.
in my experience, gzip will saturate one core of the source machine, pushing it to 100% usage, but it can't compress fast enough to saturate a 100Mb Ethernet.
transferring the full uncompressed disk will take about 3 hours on a 100Mb, so I guess you'll be faster than that.
Amazing super easy P2V!
ReplyDeleteReally can't believe this worked after I read some of the complicated coldboot conversion tutorials out there and with virtually no downtime! Thanks for the write-up!
ReplyDelete