On Dec 18, 2007 4:25 PM, Karl Erisman wrote:

I'm trying to create/install domU guests all in "one" step, following Daniel's wiki page (I've found these pages really helpful, BTW): http://wiki.centos.org/HowTos/Xen/InstallingCentOSDomU

I have a few questions about this process:

I've found answers to some of them and will share them below. This took a bit of fiddling; I read xmdomain.cfg (5) and searched online, but some of this took trial-and-error, so maybe this info can save someone a few hours of valuable time.

(1) How would it be modified (w/respect to defining the disk in the domain configuration file) to use a disk layout where dom0 has N logical volumes, one for each of N domU guests?

The "disk" parameter I used successfully to indicate that a logical volume is being used as the backend storage device looks like this: disk = [ 'phy:/dev/volgroup00/LV_domU_devserver,xvda,w', ]

...and it seems that the frontend device ('xvda' in this example) MUST have the prefix 'xvd' (is this true?)! Nothing else seemed to work. Of course, several xvdX disks may be made available to the domU.

(2) Using this method (where dom0 has an LV for each domU disk), I would avoid the entire "Creating an image" step, correct?

Correct. My understanding (corrections, please) is that using logical volumes instead of image files, it should be possible to take LVM snapshots for quick backup purposes (stop domU, snapshot it, re-start domU, backup snapshot, remove snapshot -- domU can be back up and running far sooner than if it were down during an entire image file backup; additionally, the backup takes less space than the "non-lazy dd image file method" but still avoids the potential allocation problems of running out of space in image file container volumes when using the lazy method).

(3) I'm setting up a dom0 kickstart. If I proceed as described, doing this (where domU_i is the ith guest):

...

...I'd need to unmount those logical volumes before trying to kickstart the guest domUs, right?

From all I've seen, it sounds like a *running* domU partition/volume

must never be mounted in dom0 (or any other domain), even in read-only mode. So to kickstart domU instances in dom0's %post, the newly-created domU logical volumes would need to be unmounted. Additionally, they should probably be stripped out of /etc/fstab since LVM partitioning during kickstart will automatically add them there. Something like this near the front of %post (in dom0 kickstart) should do it (assuming naming convention has been followed where LVs contain "LV_domU" in their names):

# Unmount domU logical volumes and remove them from dom0's fstab mount | cut -d' ' -f1,3 | grep domU | cut -d' ' -f2 | xargs umount -l $_ perl -pi'.bak' -e 's{^.*LV_domU.*$}{}' /etc/fstab

(4) Additionally, how would domU "see" its disk during the install process? Assume I specify a backend LV_domU_i_disk logical volume (an LV in dom0 that I just described) as the disk and map it to a frontend device called 'xvda'. Again using kickstart, I expect it would look like this: ####### in domU kickstart... ####### clearpart --all --initlabel --drives=xvda #... part pv.01 --size=100 --grow --asprimary --ondisk=xvda volgroup volgroup00 --pesize=4096 pv.01 logvol /home --fstype ext3 --name=LV_home --vgname=volgroup00 --size=3072 #... #######

This works.