It’s been a wild couple months.
Lately I’ve performed a number of physical to virtual conversions (P2V) from legacy hardware to VMWare ESXi 4.0. This isn’t exactly a simple process as anyone who has accomplished or undertaken something like this can affirm but it is interesting. The issues I ran into were the product of good intentions combined with sloth and a small amount of stubbornness. The solution was time intensive but now that I understand the limitations I think I’m comfortable sharing how I got things back in action.
My physical machine is a 12 year old beige box running Debian 3.0 (Sarge) with a 2.2.17 Kernel. The general hardware specs were a Celeron Mendocino CPU running at 366 MHz, 64MB of SDRAM, and a 10 GB IDE harddrive. The virtual host has 2 Xeon quad-core CPUs at 3 GHz and 32 GB of DDR-2 with a 1 Terabyte SAS RAID5 array and gigabit ethernet. Fiat to Ferrari is the comparison I’m thinking of but it might be more apt to say we’re going from bicycle to motorcycle.
The physical machine, for what it’s worth, was engineered cleverly but it is readily apparent to me that this is one of the many problems I will have to resolve – I’ll elaborate:
Early Linux kernels came in a couple general varieties but it was very common, especially when drive space was limited, to trim down the Kernel as much as possible. This has a couple outcomes, and Kernel slimness is still relevant today, like freeing up valued hard drive space and ensuring that your Kernel loads very quickly. In this case the Kernel was built using a config file and installed as a compressed Kernel image along with the tools required to decompress it. Fantastically small, really, but we’ll encounter an issue shortly that resulted in no small amount of cursing.
Step one involved running VMWare Converter Standalone from a Windows XP workstation and connection to a remote Linux machine using SSH credentials. You will know if connecting is a success if you are capable of retrieving machine settings. Step two involves selecting the destination which I chose as an Infrastructure machine and submitted it’s IP address and relevant user credentials. Step three, most ambiguous of steps, was the reconfiguration of the VM I was creating. I chose to keep the exact settings of my physical machine with one exception: I assigned a BusLogic disk controller instead of leaving it IDE. This is because my ESXi host has no IDE controller and will fail to emulate IDE devices. To be honest I learned this during a trial run and was well aware that I’d have to make this change just to get started. I could convert it and reconfigure after the fact but it is actually just as easy to make this change now. The process runs and, after about an hour, it completes based largely on the 10GB disk geometry though it bears noting that about 2.2GB of the 10GB volume contained data.
I did not power down the physical machine at this point, despite having a copy, because I know I will have to work to get my VM online and because it will take some amount of time. During this process I can leave the physical machine up and running without much fear of conflicts occurring.
Over on my ESXi box I check the settings and disable the NICs because if this does come online, and it won’t in my case, I don’t want it interrupting another running machine. I can work on the VM without a network card, though, as you will soon see. When I boot the VM it throws an error because it fails to find a bootable drive which is in no way unexpected. One problem I quickly identify is that my VM is booting a Linux Kernel with absolutely no built-in SCSI or SATA module and this is why I get an immediate boot error. The solution is to mount media for this version of Linux and rebuild the Kernel and I choose to do this the lazy way with a Ubuntu 9.04 LiveDVD I have laying around which also necessitates the addition of a second virtual DVD drive. I choose to mount the LiveDVD to my VM and use CTRL-ALT-INSERT to reboot and press the ESC key to get the boot selector. I choose my DVD drive and the LiveDVD boots up without harming the VM. I then mount the .iso for Debian 3.1 to my second DVD drive.
I usually choose to snapshot the VM at this point just in case I do something painfully stupid. There’s some myths about me I should dispel and fortunately I’ve got little ego: I’ve done painfully stupid things but I’ve learned from them.
The next step is to rebuild an analogue of the VM as if it were a physical machine and to do that you need to do a couple different things. First thing I do is create a mount-point for the disk image I’ve converted and I find out what it should be using “fdisk -l” and it tells me I have a swap of 1GB and a 9GB Linux partition at /dev/sda2 and /dev/sda1 respectively. I don’t care about swapspace but I want to be able to manipulate my root partition so I make a mount point and mount it using “mkdir /mnt/root” and “mount /dev/sda1 /mnt/root” which doesn’t give me any errors.
The next step is to mount a few fancy directories using the bind command because we’re going to have to chroot this sucker like so:
mount -o bind /dev /mnt/root/dev
mount -o bind /proc /mnt/root/proc
chroot /mnt/root
So those commands bind the LiveDVD /dev and /proc to my VM’s eventual disk and then I chroot myself into that disk. The side-effect of this process is that my Debian CD is now mounted as /dev/cdrom1 and I can make a mountpoint and mount it to my filesystem in short order.
I also take this opportunity to use a lesser known apt command so I can grab sources from this CD: apt-cdrom -s add /dev/cdrom1
then I run apt-get update to ensure it is added to my apt sources list. It is deceptively simple to assume this is an unnecessary action but it is going to become a requirement for some of the things we need to do. We need to build a new kernel with support for the “new” SCSI disk we’re going to be using and we need to make sure the machine boots properly. This would be another good time to create a snapshot if you’re looking for extra guidance – anything that works, as a rule, you should snapshot – we can delete the snapshots once we’re up and running.
The next thing I did was inspect the bootloader, which was LILO, which I will be replacing with GRUB. The easiest way to accomplish this task is to run “apt-get remove lilo” and then “apt-get install grub” which accomplishes one of the steps. I also snapshot at this point and use CTRL-ALT-INSERT to force a restart. What I see is that now I get a nasty kernel panic instead of just a boot failure. I restore my snapshot to save some time and we can move on to rebuilding our kernel.
First thing to do when rebuilding the kernel is to pop over to /usr/local/src and verify that sources and a kernel config already exist. I find the config linked to /boot/config-2.2.22-gibberish and when I look inside I see that my BusLogic controller is being loaded as a module. I find my sources in /usr/local/src/linux which are the 2.2.22 kernel sources. I am missing initrd-tools so I install those using apt-get. I change my directory to /usr/local/src/linux and run “make menuconfig” to get a config menu for my kernel. I keep it simple and only change the BusLogic support from Module to built-in after loading the config file from /boot/. When I’m done I use “make dep” and then “make kpkg-clean” before installing the newly created kernel using “dpkg -i /usr/src/<kernel name>.deb”
Finally I run “update-grub” and perform one more snapshot before my dry-run reboot.
This time my VM boots up just fine albeit with some errors because I have disabled my VM NICs. This is easily fixed by clicking on the VM in my inventory and clicking settings and lastly enabling the NICs. Bringing my VM online for an unrelated reason required the addition of a static route but otherwise my VM is operating as expected and much more quickly and reliably than the physical machine which I disable on schedule.
And that is how I generally approach this kind of project – the process is fairly similar with RHEL/CentOS/Fedora but Gentoo is another matter – and I hope this has been helpful. It took me a few days to accomplish this.

Leave a comment
Comments feed for this article