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] anaconda-11.1.0.48-vgname.patch
Created attachment 131786 [details] xenguest-install-vgname.patch
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