On Wed, 2007-04-04 at 20:27 +0530, Deependra Shekhawat wrote: > Sorry. I guess I pointed to wrong area. I understood what you plan to > do. > Can you please tell me how should I proceed in step by step manner. I > also plan to migrate my RHEL5 installation on physical machine to a > xen virtual machine. > Thanks in advance. I've been working on the same thing. I'm very close to having it all figured out. Here's a nutshell version: 1. Create a Xen guest config file for the "new" guest (the one you are converting from a bare-metal system). This is easiest if you install the xen and kernel-xen packages on the machine you are converting and reboot into the Xen kernel. 2. There are a few options for allocating storage space for guests; pick the one you want. In either case, don't forget about a swap partition; make sure there is enough space for that too. I just create a root and a swap partition on mine. 2a. If you want to have an image file for the new guest's disk, use dd to create a disk image file large enough for all the partitions you want. 2b. If you are going to use shared storage (fibre channel, iSCSI, AoE, clvm/GFS, etc.) then create the appropriate storage location. This is the method that I prefer. 3. Create partitions on the new storage. 3a. If you went with 2a, then use losetup to make the image file a device (like /dev/loop0) and use fdisk on that. 3b. If you went with 2b, device nodes are simpler to work with. 4. Format the new storage partitions and prep the swap partitions. For either 2a or 2b, you will need to use kpartx to make the necessary device nodes properly for the partitions within your image file. 4a. If you went with 2a, then run something like "kpartx -a /dev/loop0". You can then format /dev/mapper/loop0p# and use mkswap on whichever partition you were setting up as the swap device for the guest. 4b. If you went with 2b, then run something like "kpartx -a /dev/vg0/new-guest". You can them format /dev/mapper/new-guestp# and use mkswap on which partition you were setting up as the swap device for the guest. 5. Mount the new guest's data partitions (such as at /mnt/new-guest or whatever). 6. Copy the entire contents of the filesystems for the system you are converting. You have to pay careful attention to the virtual filesystems (/proc/, /sys/, etc.) and the /dev/ directory. It's best to create a for loop that will run "cp -a" for all directories in / except for those, then deal with creating some of the basics that you need to have within the /dev/ directory manually with mknod (or by reinstalling the right package(s), such as filesystem, IIRC). 7. Edit configuration files within the guest image, such as /etc/inittab, /etc/fstab, the hostname, networking configuration and so on. 8. Edit the initrd found within the guest image. Fedora & Red Hat's mkinitrd hard codes some things into the /init nash script found within their initrd images, you're going to have to add in the xenblk.so driver (in the /lib/ directory in the initrd) and make sure that /init loads it. The easiest way of doing this is by copying over an initrd image from a guest that was created using virt-install or virt-manager, though I've successfully had edited the initrd for new guests several times (and in just a couple of minutes). 9. You could run "rpm -e kernel" within the guest if you want to clear up the clutter. Don't worry, you'll still have the kernel-xen package installed, which is the only one that you need or can even use in the guests anyway. If you are going to do this, best do it chroot'ed or wait until you have the guest up and running. 10. Unmount all the guest partitions. 11. Use kpartx (with it's -d switch) to properly take down the partitions it created earlier. 12. If you went with 2a, use "losetup -d /dev/loop0" to cleanly "close up" the image file. 13. Test it. One catch on RHEL5 (without updates installed), I found that SELinux was interfering with xend's attempts to create the block device within the guest domains. I'm going to try to track that down soon, but I haven't had time to test it with the latest updated policy (is there an errata SELinux targeted policy yet for RHEL5?). Hopefully, I'll have that solved before the end of this week. As you can see, there are a few steps to go through, but it shouldn't be very hard to do. As always, make sure your backups are good before fiddling with the system, just in case something goes wrong. HTH. [snip] -- Lamont Peterson <lamont@xxxxxxxxxxxx> Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] NOTE: All messages from this email address should be digitally signed with my 0xDC0DD409 GPG key. It is available on the pgp.mit.edu keyserver as well as other keyservers that sync with MIT's.Guru
Attachment:
signature.asc
Description: This is a digitally signed message part
-- Fedora-xen mailing list Fedora-xen@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-xen
