RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 979724 - allow to specify the desired UUID for the --uuid parameters of [pv,vg,lv]change
Summary: allow to specify the desired UUID for the --uuid parameters of [pv,vg,lv]change
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.6
Hardware: All
OS: All
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: LVM and device-mapper development team
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-06-29 21:35 UTC by Christoph Anton Mitterer
Modified: 2013-10-10 00:50 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-10 00:50:52 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Christoph Anton Mitterer 2013-06-29 21:35:39 UTC
Hi.

It would be nice, if the --uuid parameters of [pv,vg,lv]change [0] supported a special keyword like mke2fs's "random".
If that is given, the respective tool should create a new random UUID and the user doesn't have to give one explicitly.


Cheers,
Chris.


[0] Well lvchange doesn't yet have one but see: bug #979720

Comment 2 Bryn M. Reeves 2013-07-01 08:52:48 UTC
From man pvchange/vgchange:

       -u, --uuid
              Generate new random UUID for specified physical volumes.

It should really mention that you can also provide a string to set the UUID to a particular value (e.g. when recreating PVs).

Comment 3 Zdenek Kabelac 2013-07-01 09:09:57 UTC
You could only recreate given UUID if you restore metadata:

pvcreate --uuid  uuid  --restorefile file

There is no change operation for this supported in metadata.

Comment 4 Christoph Anton Mitterer 2013-07-01 23:07:40 UTC
Bryn is right of course and I didn't read carefully enough.

So let's change the ticket to the following:
1) Document that you can also specify a specific UUID to --uuid, if that already works (it seems it doesn't):

2) If it doesn't, it might be useful to have this implemented, especially when one's trying to do recovery works.


Zdenek, it doesn't seem to be true that one can only use pvcreate's --uuid with --restorefile... just tried it and it works.

Cheers,
Chris.

Comment 5 Alasdair Kergon 2013-07-01 23:30:53 UTC
pvcreate -u was sorted out last year.  Look at the upstream man page:

       -u, --uuid uuid
              Specify  the  uuid  for the device.  Without this option, pvcre‐
              ate(8) generates a random uuid.  All of  your  physical  volumes
              must  have  unique  uuids.   You  need to use this option before
              restoring a backup of LVM metadata onto a replacement  device  -
              see  vgcfgrestore(8).   As such, use of --restorefile is compul‐
              sory unless the --norestorefile is used.


vgcreate -u has existed for a long time.  I'm not aware of any genuine need to specify the uuid instead of having a random one selected.

The LV component of LV uuids is entirely an internal LVM matter and the current design does not permit the user to have any control over it, and so an lvcreate -u option would make no sense.


So I don't think there's anything to change here, but the bugzilla could act as a placeholder to bring the pvcreate behaviour into line with upstream if the last RHEL6 release hasn't picked it up yet.

Comment 6 Christoph Anton Mitterer 2013-07-01 23:40:55 UTC
Hey Alasdair,

Where? http://www.sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/LVM2/man/pvchange.8.in?rev=1.7&content-type=text/plain&cvsroot=lvm2 still shows:

  .BR \-u ", " \-\-uuid
  Generate new random UUID for specified physical volumes.


ftp://sources.redhat.com/pub/lvm2/ seems to be down? Not sure now whether Debian has the most recent LVM version (it's 2.02.98)... and at least there, the manpage is as I've quoted.


With the only reason for vgchange (or basically any other tool) to allow a UUID specified instead of having on randomly created, is disaster recovery... like that you bricked your header, don't have any backups and try to recreate the same header.
I even did this once for ext4... but I don't know the internal details of LVM well enough to tell whether one has any chances then at all... and whether it may make sense therefore.
I'd guess it could be possible with simple VG schemas, where one has only few PVs, and PEs linearly allocated...

Anyway... I don't consider this very important, so from that POV you may close the issue.


With respect to LVs,.. when I originally asked for this, I wasn't aware that LV UUIDs are unique only within their VG...
So as said over at bug #979725, I still think it wouldn't be too bad to make it mutable, but it's not that important than.


Cheers,
Chris.

Comment 7 Zdenek Kabelac 2013-07-02 08:13:02 UTC
(In reply to Christoph Anton Mitterer from comment #6)
> Hey Alasdair,
> 
> Where?
> http://www.sourceware.org/cgi-bin/cvsweb.cgi/~checkout~/LVM2/man/pvchange.8.
> in?rev=1.7&content-type=text/plain&cvsroot=lvm2 still shows:
> 
>   .BR \-u ", " \-\-uuid
>   Generate new random UUID for specified physical volumes.
> 
> 

Well you've probably missed the changed location of the lvm2 project tree:

http://sourceware.org/lvm2/

git clone git://git.fedorahosted.org/git/lvm2.git 

https://git.fedorahosted.org/cgit/lvm2.git/tree/man/pvchange.8.in

> ftp://sources.redhat.com/pub/lvm2/ seems to be down? Not sure now whether
> Debian has the most recent LVM version (it's 2.02.98)... and at least there,
> the manpage is as I've quoted.

Unfortunately Debian project decided to deviate from upstream code in some areas (udev) - so for this moment I'd suggest to avoid Debian packages and build
the sources from upstream git tree.
 
> With the only reason for vgchange (or basically any other tool) to allow a
> UUID specified instead of having on randomly created, is disaster
> recovery... like that you bricked your header, don't have any backups and
> try to recreate the same header.

Please find some google text how the recovery is supposed to be made with
lvm tools -  i.e.:

https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Logical_Volume_Manager_Administration/mdatarecover.html

Comment 9 Christoph Anton Mitterer 2013-07-02 12:55:51 UTC
Ah.. I had thee CVS address from there, and just didn't read the "Source code prior to 7th June 2012" heading ;-)

Yeah,... I know about the bad situation regarding LVM2 in Debian... it's really a shame, since the problem with the udev rules are by far not the only and the most annoying thing...
*sigh*


Well...since all other possible "open" things mentioned within this (i.e. mentioning of the uniqueness of LV UUIDs only within their VG)... we can close the bug, IMHO.


Note You need to log in before you can comment on or make changes to this bug.