Bug 979724
Summary: | allow to specify the desired UUID for the --uuid parameters of [pv,vg,lv]change | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 6 | Reporter: | Christoph Anton Mitterer <calestyo> |
Component: | lvm2 | Assignee: | LVM and device-mapper development team <lvm-team> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Cluster QE <mspqa-list> |
Severity: | unspecified | Docs Contact: | |
Priority: | unspecified | ||
Version: | 6.6 | CC: | agk, bmr, dwysocha, heinzm, jbrassow, msnitzer, prajnoha, prockai, thornber, zkabelac |
Target Milestone: | rc | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-10-10 00:50:52 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Christoph Anton Mitterer
2013-06-29 21:35:39 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). 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. 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. 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. 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. (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 > https://git.fedorahosted.org/cgit/lvm2.git/tree/man/pvchange.8.in > https://git.fedorahosted.org/cgit/lvm2.git/tree/man/pvcreate.8.in 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. |