Virtualize a Server with Minimal Downtime
Even though the files on the virtual machine are identical to the physical machine, the virtual machine will not boot correctly at this point until you make some changes to the boot settings. This works best from within a chroot environment, so type:
$ sudo chroot /mnt/sda1
before you run the rest of the commands. Be sure to replace /mnt/sda1 with the mountpoint for your root partition if it is different.
The first change you need to make within the chroot environment is to restore your bootloader. If you use GRUB, look at /boot/grub/menu.lst or /boot/grub/grub.conf. If you use LILO, look at /etc/lilo.conf. Check for any devices that may have changed. In particular, if you switched from an IDE to a SCSI device, from a RAID to a non-RAID or changed the root partition order, be sure to make changes here to reflect that. Next, if you use GRUB, type:
# grub-install /dev/sda
Change /dev/sda to match the primary disk device from which you will boot. If you use LILO, type:
After your bootloader has been installed, check /etc/fstab and confirm that any drive, partition or device changes you made in your bootloader config file also were changed here.
Many servers these days use an initrd file to load modules that are essential for the boot process but that don't necessarily fit in the kernel image. Often, this initrd file contains only the modules that suit your hardware, so when you make the switch to new hardware, such as is the case with VMware's virtual SCSI controllers, you need to create a fresh initrd that has these new modules in it.
On a Red Hat system, edit either /etc/modules.conf or /etc/modprobe.conf for RHEL 4, and remove any references to scsi_hostadapter you find there. If you configured your virtual machine to use VMware's virtual BusLogic SCSI controller, replace those references with the following:
alias scsi_hostadapter BusLogic
If you chose VMware's LSI Logic SCSI controller, add the following lines instead:
alias scsi_hostadapter mptbase alias scsi_hostadapter1 mptscsih
Obviously, these modules are specific to VMware virtualization, so if you want to attempt this with another virtualization technology, you will need to look up which SCSI modules it uses and make sure they are referenced here.
Now, you are ready to create a new initrd. Find the location of the initrd your server last used from your /boot/grub/menu.lst, /boot/grub/grub.conf or /etc/lilo.conf file, and then move it out of the way so you can create a new one safely. Then, run mkinitrd with the path to the initrd file to create and the name of the current kernel. For my example server, I am using the Red Hat 2.4.21-32.0.1.ELsmp kernel, so I would type:
# mv /boot/initrd-2.4.21-32.0.1.ELsmp.img ↪/boot/initrd-2.4.21-32.0.1.ELsmp.img.bak # mkinitrd /boot/initrd-2.4.21-32-0.1.ELsmp ↪2.4.21-32-0.1.ELsmp
As I said before, this is the method Red Hat uses to create initrd files. Unfortunately, different distributions use different methods. For instance, Debian's mkinitrd stores configuration files under /etc/mkinitrd, and the mkinitrd command uses slightly different options, so you might need to do some extra research to create a new initrd for your server's distribution.
At this point, you can reboot the virtual machine. Confirm that your physical machine no longer has its original IP address, or otherwise, simply power it off to be safe. If your server runs a hardware configuration service like kudzu, it most likely will prompt you at boot time because it has detected changes in the server's hardware. Be sure to select Keep Configuration for any old SCSI or network hardware it mentions, and select Ignore for any new SCSI or network hardware; however, you safely can remove old video, sound, USB and similar hardware if you are prompted.
Once the machine has booted completely, confirm that all system services have started and that you are connected to the network. I have noticed on some Red Hat systems that the network card's MAC address has been hard-coded into the configuration file, and as that has changed on the new virtual hardware, the network won't resume. In this case, simply edit the configuration file for your network card under /etc/sysconfig/network-scripts/ (often ifcfg-eth0), and either remove the reference to the MAC address or change it to reflect the new MAC address. Then, restart the networking service.
Practice this procedure on a few test machines to be sure you have all the steps down for your particular network before attempting it on a live production machine. Nothing is worse than scrambling to fix strange initrd issues on a virtual machine while the physical server is down and your maintenance window is ticking away. You will find that the more often you perform these migrations, the faster you can do them—you even might be able to stagger them and complete a few at the same time.
Kyle Rankin is a Senior Systems Administrator in the San Francisco Bay Area and the author of a number of books, including Knoppix Hacks and Ubuntu Hacks for O'Reilly Media. He is currently the president of the North Bay Linux Users' Group.
Kyle Rankin is a director of engineering operations in the San Francisco Bay Area, the author of a number of books including DevOps Troubleshooting and The Official Ubuntu Server Book, and is a columnist for Linux Journal.
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- Home Automation with Raspberry Pi
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development