| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • Stop wasting time looking for files and revisions. Connect your Gmail, DriveDropbox, and Slack accounts and in less than 2 minutes, Dokkio will automatically organize all your file attachments. Learn more and claim your free account.

View
 

LinuxP2V

Page history last edited by PBworks 14 years, 3 months ago

How to P2V a Linux Machine

 

The original poster from whom I derived these instructions describes a method to P2V a Linux machine, which unfortunately requires the modification of the configuration of the source machine. This is usually unacceptable to clients (with good reason). I have adapted this method slightly so that I don't have to make modifications to the source machine, and I've modified the instructions accordingly.

 

This method can be adapted without much intelligence to P2P or V2P a Linux box. In addition, this process itself is not that hard. The post is long, but the activities are not. The original post was at this URL.

 

For a Linux VM to boot, the BusLogic scsi driver must be either loaded into the kernel at boot or compiled into a new kernel. Many Linux installations use a two-stage boot process, consisting of an "initrd" (i.e., initial RAM disk) followed by the normal boot process. The initial RAM disk is used to load drivers, etc., into the kernel before switching to the root disk.

 

To check what loadable modules have been loaded into the kernel:

 

lsmod

 

Check for initrd by displaying the contents of the bootloader:

 

more /etc/grub.conf

more /etc/lilo.conf

 

Example grub configuration: (all paths are relative from /boot)

 

default=0

timeout=10

splashimage=(hd0,0)/grub/splash.xpm.gz

title Red Hat Linux (2.4.20-8)

root (hd0,0)

kernel /vmlinuz-2.4.20-8 ro root=LABEL=/

initrd /initrd-2.4.20-8.img

 

According to the grub configuration, on boot an initial RAM disk image is being used before passing control to the root ide or scsi disk. The contents of the RAM disk consists of whatever is in initrd-2.4.20-8.img. There is a procedure to check the image file's contents, which we will explore later.

 

If the initrd line is not in the grub or lilo configuration then check for two things:

 

Go to the /boot directory and type more config-2.4.20-8 and look for:

 

- CONFIG_BLK_DEV_RAM=Y

- CONFIG_BLK_DEV_INITRD=Y

 

If the two lines cannot be found it means that RAM disk and initrd support were not compiled into the kernel. This means you must compile scsi support into a new kernel - you cannot load them into the kernel at boot. This option has not been explored at all by myself, but it would be desireable to do such a thing without writing to the disk of the source machine. Such a thing should not be too difficult, but would certainly require extra steps and effort.

 

If the two lines are present, but the initrd line is missing from the grub or lilo configuration, then an initrd image file has to be generated using mkinitrd or something similar.

 

Assuming you are still reading, you have likely decided that initrd support is available to you. Now you are ready to Ghost your source machine. This "lesson" does not attempt to teach you how to do this. You may use any imaging process you are familiar with.

 

After the imaging is complete, you need to boot the new machine (in our case, a VM) from a Linux rescue CD. Redhat Advanced and Enterprise Server include a nice rescue mode which you can access by booting with linux rescue at the boot: prompt. You simply need access to the filesystem of your ghosted drive. Assuming that filesystem is based on ext2 or ext3, a Redhat or any other linux rescue CD should get you where you need to be. Heck - you can even mount the virtual disk to any other Linux VM if you need to. You just need to get inside that ghosted drive and start manipulating a few files. This "lesson" is also not going to teach you how to do that, either. Use the Redhat CD.

 

From here on, we're going to assume you've mounted your ghosted filesystem, and that you've even chrooted into it. "chroot" is the extent of documentation I'm going to give you here, too. The Redhat rescue environment explains how to do this in more detail.

 

Back to the initrd image file. Hack into it by:

 

cd /boot

gzip -dc initrd-2.4.20-8.img > /tmp/initrd.ext2

mkdir /mnt/initrd

mount -o loop /tmp/initrd.ext2 /mnt/initrd

cd /mnt/initrd

 

There should be a directory structure and a file called linuxrc, which will load device drivers, etc., from the initial root disk (i.e., the RAM disk). To add BusLogic scsi support, the following lines should be added to "linuxrc".

 

echo "Loading scsi_mod.o module"

insmod /lib/scsi_mod.o

echo "Loading sd_mod.o module"

insmod /lib/sd_mod.o

echo "Loading BusLogic.o module"

insmod /lib/BusLogic.o

 

The object "o" files must be copied into the "lib" directory.

 

cd /lib/modules/2.4.20-8/kernel/drivers/scsi

cp BusLogic.o /mnt/initrd/lib

cp scsi_mod.o /mnt/initrd/lib

cp sd_mod.o /mnt/initrd/lib

 

Unmount /mnt/initrd. The changes/additions will be saved in /tmp/initrd.ext2.

 

umount /mnt/initrd

 

Compress a new image. Rename the existing image, first!

 

cd /boot

mv initrd-2.4.20-8.img initrd-2.4.20-8.img.old

gzip -c /tmp/initrd.ext2 > /boot/initrd-2.4.20-8.img

 

Make sure the Linux server is not booting into X Server. Change the bootlevel to "3" by modifying /etc/inittab.

 

Repair the Bootloader

 

Linux will not reboot properly because the bootloader has been overwritten. Follow this procedure to repair a grub bootloader.

 

You can use grub-install /dev/hda, but when going from ide to scsi, the device names will change. The following can be used instead.

 

grub

grub> root (hd0,0)

Filesystem type is Ext2fs, partition type is 0x83

grub> setup (hd0,0)

grub> quit

 

This will install grub in the MBR of the first hard disk.

 

If you've gone from ide to scsi, chances are your device names have changed. Which means that at the very least, your swap partition will be wrong in /etc/fstab. Edit and fix that to what the appropriate sdxN partition will be. Or what you expect it to be. Worst case, your swap won't work the first time you reboot, and you'll then know what partition to specify in /etc/fstab.

 

Reboot the machine.

 

Linux should now boot in the VM. (The BusLogic scsi driver will load via initrd). KUDZU will activate and prompt you to remove drivers that are no longer needed. Go ahead and remove them.

 

When going from ide to scsi, some device links may get broken. You can check to see if your CDrom device is broken:

 

dmesg | grep CD

 

It will tell you what the CD is linked to, say hda in this case. Create a new link if you need to:

 

ln -s /dev/hda /dev/cdrom

 

(the correct permissions for the CD device is brw-r--r--)

 

Now the CD should be available. Try to stay away from the X Windows environment until you get the VMWare Tools installed. Once you've done so, go back into /etc/inittab and set your runlevel back to 5 (assuming it was 5 originally).

 

To get the Linux VM to work with DHCP

 

Edit the following files in the guest operating system. If only one of these files exist, then make the change for that file only.

 

/etc/sysconfig/network-scripts/ifcfg-eth[n]

/etc/sysconfig/networking/devices/ifcfg-eth[n]

 

where, in both cases, [n] is the number of the Ethernet adapter -- for example, eth0.

 

Add the following section to each of these two files:

 

check_link_down () {

return 1;

}

 

Then, run the command ifup eth[n] (where [n] is the number of the Ethernet adapter) or restart the guest operating system.

Comments (0)

You don't have permission to comment on this page.