Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
First Last Prev Next    This bug is not in your last search results.
Bug 147361 - Fix duplicate VG name handling.
Fix duplicate VG name handling.
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: lvm2 (Show other bugs)
4.0
i686 Linux
high Severity medium
: ---
: ---
Assigned To: Alasdair Kergon
:
: 155043 168723 180444 180575 (view as bug list)
Depends On:
Blocks: 162704 181409 185129 185133 185483
  Show dependency tree / graph
 
Reported: 2005-02-07 11:43 EST by Daniel Hauck
Modified: 2007-11-30 17:07 EST (History)
6 users (show)

See Also:
Fixed In Version: RHBA-2006-0504
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-08-10 17:44:31 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2006:0504 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2006-08-10 00:00:00 EDT

  None (edit)
Description Daniel Hauck 2005-02-07 11:43:14 EST 
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

Description of problem:
Common scenario:
Upgrading HD -- 
 1. Install new HD and OS
 2. Connect old HD using USB case
 3. Recover/Import data from old HD

This scenario fails miserably when LVM with system install defaults. 
Reason: Volume Group names are identical on new (/dev/hda) and old
(/dev/sda) drives.  "/dev/mapper" will only read/access one of those
volume groups while ignoring the other.  No LVM tool was able to
access the old HD's group for the purpose of renaming.  Any reference
to the group name was confused with the live group name which could
not be changed while in use. (System cannot be used without active
volumes)



Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1. Install new HD and OS
2. Connect old HD using USB case
3. Attempt recover/import data from old HD


Actual Results:  Unable to access old data from drive due to LVM's
confusion as to which media to access based on identical VolGroup00 name.

Expected Results:  Should be able to mount old drive and recover data.

Additional info:

The solution was to move the old HD to another machine not actively
using LVM but with LVM tools installed.  (Happily, my FC2 machine was
exactly that.)  I was able to rename the volume group name and then
move it back the new system, mount and access the data.

I have been unable to discover a way this could be done in a
single-computer scenario, however, and this could cause real problems
for users wishing to upgrade their hard drives while keeping their old
data.  This is not a problem when not using LVM.

I am hopeful this not uncommon scenario is addressed in some way for FC4.
Comment 1 Alasdair Kergon 2005-02-08 10:14:29 EST 
You need to add filters to /etc/lvm/lvm.conf to tell the lvm2 tools to ignore
the added disk.

If you need to access it, you'll need to run an instance of lvm2 with a
different lvm.conf file (via environment variable) addressing only the extra
disk and rename the VG with that.
Comment 2 Alasdair Kergon 2005-02-18 11:03:29 EST 
Also be aware of vgxport/vgimport.

A tougher case to solve would be booting with two IDE disks both containing root
filesystems.
Comment 3 Alasdair Kergon 2006-02-01 10:19:51 EST 
*** Bug 155043 has been marked as a duplicate of this bug. ***
Comment 4 Alasdair Kergon 2006-02-10 15:16:30 EST 
*** Bug 180444 has been marked as a duplicate of this bug. ***
Comment 5 Alasdair Kergon 2006-02-10 15:41:09 EST 
*** Bug 180575 has been marked as a duplicate of this bug. ***
Comment 6 Larry Troan 2006-02-13 19:38:24 EST 
Engineering is treating this as a bug. Therefore not clear whether a PM ACK is 
needed. Adding PM ACK just in case it's needed. Engineering already appears to
be working the issue (Bug 147361) which is on the RHEL4U4Proposed list.
Comment 7 Alasdair Kergon 2006-03-15 10:31:24 EST 
*** Bug 168723 has been marked as a duplicate of this bug. ***
Comment 11 Alasdair Kergon 2006-04-12 17:34:29 EDT 
At the cost of some efficiency, the code now distinguishes internally between
different VGs that have the same name.  Most pieces of code that gathered the
vgname now also gather the vgid.

Previously, all functions had to use the VG name to reference VGs.  The option
of using the vgid now exists, and I've started to convert a few of the more
important functions.

If there are several VGs with the same name, a warning message is displayed and
one is chosen to be the one that functions doing a VG name lookup see.  It is
the first VG encountered, but if that one is exported and a subsequent one is
not, the non-exported one takes precedence.

So far, I have converted the command-line expansions for 'all VGs' and 'all PVs'
to use vgids instead of names so everything should appear now, and I've also
fixed it so command-line PVs will be attached to their correct VG.

So 'pvs -a -o+vg_uuid' should show now everything correctly, I hope.
Comment 12 Alasdair Kergon 2006-04-12 18:11:49 EDT 
So the difficult part of this is now done.  Needs further testing, and need to
consider:

(a) Extending the algorithm that chooses which VG to use so it checks the system
id too and gives precedence to a non-exported VG created on the current machine;

(b) Whether to extend any command lines e.g. to facilitate renaming a particular
one of the duplicate VGs.
Comment 13 Alasdair Kergon 2006-04-13 13:37:23 EDT 
(a) is now done.  If there are two VGs called VolGroup00, it will use the one
created on the current machine.  NB So far it just uses 'uname -n' so has a
network dependency (eg hostname could change between when VG metadata was last
updated and when tool is run).
Comment 14 Alasdair Kergon 2006-04-13 13:46:06 EDT 
For (b):

Added --partial to pvs.

So pvs -P -o vg_name,vg_uuid /dev/sda3

should now give correct details of the VG that sda3 is in, even if there's more
than one VG with the same name, and some disks in the VG are missing.
Comment 15 Alasdair Kergon 2006-04-13 17:06:43 EDT 
vgrename now accepts a VG uuid in place of the old VG name and also allows an
exported VG to be renamed.

I think these changes are sufficient for this release.

(There's still a memory leak to track down in the cache when renaming a VG with
the same name as an existing one; worked around that for now by invalidating the
cache after the operation until the problem gets fixed.)
Comment 34 Peter Jones 2006-07-25 10:55:57 EDT 
Another bug needs to be filed against anaconda for 4.5, so we can add support
for this new functionality provided by lvm2.  Until then, all previous
workarounds still apply.
Comment 36 Red Hat Bugzilla 2006-08-10 17:44:40 EDT 
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2006-0504.html
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.