linux-lvm.redhat.com archive mirror
 help / color / mirror / Atom feed
From: N <dundir@gmail.com>
To: linux-lvm@redhat.com
Subject: [linux-lvm] Possible Bug vgrename
Date: Mon, 21 Jun 2021 11:32:12 -0700	[thread overview]
Message-ID: <917d8044-4e7b-e54e-fe69-f60c6703a00f@gmail.com> (raw)

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@redhat.com
https://listman.redhat.com/mailman/listinfo/linux-lvm
read the LVM HOW-TO at http://tldp.org/HOWTO/LVM-HOWTO/


             reply	other threads:[~2021-06-21 18:32 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-21 18:32 N [this message]
2021-06-21 19:48 ` [linux-lvm] Possible Bug vgrename David Teigland
2021-06-21 20:00   ` Alasdair G Kergon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=917d8044-4e7b-e54e-fe69-f60c6703a00f@gmail.com \
    --to=dundir@gmail.com \
    --cc=linux-lvm@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).