Bug 197326 - Allow xenguest-install specify a volume group name
Allow xenguest-install specify a volume group name
Product: Fedora
Classification: Fedora
Component: anaconda (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeremy Katz
Depends On:
  Show dependency treegraph
Reported: 2006-06-30 04:11 EDT by Mark McLoughlin
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-03-19 16:15:23 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
anaconda- (3.00 KB, patch)
2006-06-30 04:11 EDT, Mark McLoughlin
no flags Details | Diff
xenguest-install-vgname.patch (1.00 KB, patch)
2006-06-30 04:12 EDT, Mark McLoughlin
no flags Details | Diff

  None (edit)
Description Mark McLoughlin 2006-06-30 04:11:32 EDT
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.
Comment 1 Mark McLoughlin 2006-06-30 04:11:32 EDT
Created attachment 131785 [details]
Comment 2 Mark McLoughlin 2006-06-30 04:12:24 EDT
Created attachment 131786 [details]
Comment 3 Jeremy Katz 2006-07-03 23:37:31 EDT
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.
Comment 4 David Juran 2006-12-13 10:21:30 EST
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.
Comment 5 Jeremy Katz 2007-03-19 16:15:23 EDT
Still don't think this is the right thing to do; we really should just fix the
lvm tools intead

Note You need to log in before you can comment on or make changes to this bug.