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.