Possible Bug vgrename

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hello, I'm hoping someone has an idea on how to go about working around this better.

I've run into issues working with lvm2, vgrename several times now in the past. I've got a bit more time now so I thought I'd reach out to see if there was another way of doing this.

Sometimes its necessary to access a volume group that has a naming conflict on the system being used, its usually during a temporary procedure and attaching the drive creates a temporary naming conflict, the volumes are listed as inactive and you need to access the data (often to create an emergency backup). You can easily change the name with vgrename and rescan to access the volumes, but to undo those changes it is problematic.

To revert the change usually requires additional time, and then the vgrename changes after rebooting into a recovery environment to undo the rename. Even with the volumes deactivated, as long as the volume group conflict remains, vgrename will not set the name to a conflicting name even with the force flag set (i.e. when referencing the volume using UUID).

The issue has been common enough that when I set up systems that use lvm2 I usually just randomize the volume group names with output from uuidgen but this does not help me much when the system isn't set up by me initially.

vgrename fails to change the groupname for a set of volumes referenced by UUID to a name that it knows is in conflict with any of the existing previously scanned volume group names.

Systems using encryption at-rest often will fail to boot if the volume group name has been changed, and this can all add up to quite a bit of additional time needed when resolving any issues. Even more time when a disk subsystem needs to go through a set startup sequence after each shutdown/restart (~10-15m).

Is there a way to temporarily rename (without actually renaming) the volume groups (i.e. like setting a mask for the volume group names), or is there a way to force vgrename to actually make the change even if there is an existing conflict (preferably without a reboot)?

The force flag in the documentation fails to make any changes, I ran a test to confirm just recently and confirmed this is still an issue. In most cases, the conflict, is with a root volume on the system being used so its often either not possible, or expedient to rename that volume group to resolve the naming conflict.

Appreciate any help you all can provide.

Best Regards,

Nathan Singer

_______________________________________________
linux-lvm mailing list
linux-lvm@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/




[Index of Archives]     [Gluster Users]     [Kernel Development]     [Linux Clusters]     [Device Mapper]     [Security]     [Bugtraq]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]

  Powered by Linux