Bug 197326 - Allow xenguest-install specify a volume group name
Summary: Allow xenguest-install specify a volume group name
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: anaconda
Version: rawhide
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Jeremy Katz
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-06-30 08:11 UTC by Mark McLoughlin
Modified: 2007-11-30 22:11 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2007-03-19 20:15:23 UTC
Type: ---
Embargoed:


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

Description Mark McLoughlin 2006-06-30 08:11:32 UTC
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 08:11:32 UTC
Created attachment 131785 [details]
anaconda-11.1.0.48-vgname.patch

Comment 2 Mark McLoughlin 2006-06-30 08:12:24 UTC
Created attachment 131786 [details]
xenguest-install-vgname.patch

Comment 3 Jeremy Katz 2006-07-04 03:37:31 UTC
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 15:21:30 UTC
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 20:15:23 UTC
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.