Red Hat Bugzilla – Bug 197326
Allow xenguest-install specify a volume group name
Last modified: 2007-11-30 17:11:36 EST
By default, we use VolGroup00 as the VG name. If you want to poke around in an
images you end up activating multiple volume groups with the same name.
With xenguest-install, you have to choose a domain name when installing, so it
seems sane to use that domain name in the volume group name to ensure we have
different VG names across domains.
Attaching patches to add a "vgname" command line option to anaconda and make
xenguest-install.py use it.
Created attachment 131785 [details]
Created attachment 131786 [details]
The problem with this is that then things aren't nearly as "expectable". Also,
volume names like that are going to get really long, which isn't ideal. I
really think the right thing to do here is to finally fix up the lvm tools to
not suck with duplicate VG names and not add more hacks to paper over it.
The use case gets even more severe if you install a Xen Guest on a whole disk.
Let me explain the trap I fell into.
I installed FC6 on cciss/c0d0 accepting all the default options. I then
installed a Xen paravirtualised guest on sda accepting all the default options.
This was a mistake )-:
Next time I rebooted Dom0, it booted from cciss/c0d0 as expected, but in the
grub.conf, it was written "root=/dev/VolGroup00/LogVol00". So it went on to
scanning for LV:s and picked up the guest's LV:s (on sda2) and since it's named
the same way as Dom0's root device it used it for it's own, read the fstab from
there and so on...
The way around this would be to let xenguest-install pass VG names to anaconda
and even better, if no VG names are specified, scan for what VG:s already exist
and use something that is not used elsewhere in the system.
Still don't think this is the right thing to do; we really should just fix the
lvm tools intead