Bug 979724 - allow to specify the desired UUID for the --uuid parameters of [pv,vg,lv]change
allow to specify the desired UUID for the --uuid parameters of [pv,vg,lv]change
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2 (Show other bugs)
6.6
All All
unspecified Severity unspecified
: rc
: ---
Assigned To: LVM and device-mapper development team
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-06-29 17:35 EDT by Christoph Anton Mitterer
Modified: 2013-10-09 20:50 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-10-09 20:50:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Christoph Anton Mitterer 2013-06-29 17:35:39 EDT
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 04:52:48 EDT
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 05:09:57 EDT
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 19:07:40 EDT
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 19:30:53 EDT
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 19:40:55 EDT
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 04:13:02 EDT
(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 08:55:51 EDT
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.