[Bug 207470] Need ability to handle duplicate VG names for Xen

[bugzilla at redhat.com]

Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug report.

Summary: Need ability to handle duplicate VG names for Xen


https://bugzilla.redhat.com/show_bug.cgi?id=207470





------- Additional Comments From ralston at pobox.com  2008-06-05 12:37 EST -------
The bug in comment #1 has been fixed for at least RHEL 5.1 and 5.2; vgchange now
accepts a UUID to specify the target volume group.  So, to get at the volumes of
a virtual host, you can use kpartx/vgscan/vgchange/vgrename in sequence.

The primary way I've avoided this problem is by naming the main volume group
"os" for the Xen host, and naming the main volume group "vos" for Xen guests. 
That way, I only have to rename volume groups if I want to access the
filesystems of two guests simultaneously, which occurs very infrequently. 
(Wanting to access the filesystem of a single powered-down guest is much more
common.)

With that in mind, here's a simple suggestion: if anaconda detects that it is
occurring within a paravirtualized install, or if the hardware it detects in the
system looks suspiciously like the hardware Xen would present to an HVM guest,
use a different automatic LVM volume naming scheme than "VolGroup00" (e.g.,
"VVolGroup00".)  Or consider using /dev/urandom to generate a portion of the
suggested volume group names randomly.

Not coping well with duplicate volume group names strikes me as more of a
misfeature of LVM than an outright bug, so I have my doubts as to whether it
will be possible to have LVM really "play nice" with duplicate volume group
names.  (Mounting the filesystems of other hosts probably wasn't that common of
an operation until virtualization came along...)


-- 
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.