Red Hat Bugzilla – Bug 147361
Fix duplicate VG name handling.
Last modified: 2007-11-30 17:07:16 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.
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.
Also be aware of vgxport/vgimport. A tougher case to solve would be booting with two IDE disks both containing root filesystems.
*** Bug 155043 has been marked as a duplicate of this bug. ***
*** Bug 180444 has been marked as a duplicate of this bug. ***
*** Bug 180575 has been marked as a duplicate of this bug. ***
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.
*** Bug 168723 has been marked as a duplicate of this bug. ***
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.
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.
(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).
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.
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.)
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.
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