Bug 979720 - provide a --uuid command for lvchange
provide a --uuid command for lvchange
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2 (Show other bugs)
All All
unspecified Severity unspecified
: rc
: ---
Assigned To: LVM and device-mapper development team
Cluster QE
Depends On:
  Show dependency treegraph
Reported: 2013-06-29 16:36 EDT by Christoph Anton Mitterer
Modified: 2013-07-02 06:06 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-07-01 19:55:17 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
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 16:36:05 EDT

For reasons already laid out in bug #979121... it's not that uncommon to encounter PV/VG/LVs in a system with either the same name or even worse the same UUID.

pvchange, vgchange already provide ways to alter the UUID for PVs and VGs.
But lvchange misses that for the LVs.

Please add such a option.

OT questions:
1) What LVM uses... are these real UUIDs? Cause they seem to e.g. not only use hex characters.

2) Has anyone an idea what happens in a system where PV/VG/LVs with the same UUID turn up and some of them are already active and e.g. filesystems on top of them mounted? Will that continue to work.. or does everything break?

Comment 2 Zdenek Kabelac 2013-06-30 09:04:45 EDT
I guess there is some misunderstanding how the UUID works with LVs.
LV device uuid is composed from 3 pieces:


fixed prefix: LVM-
VG_uuid:      O6VNcg-q5cc-6en0-31EB-x9in-VszX-xgOkTe
LV_uuid:      3OBXO6-ZhBY-usjm-lGOE-cpku-zu1X-D1WKsd

So LV uuid needs to be unique only within the VG itself - it's valid to have same LV uuid within 2 different VGs.

Also there is no connection between filesystem and device uuid namespace.

From the system point of view - it always depends on who interprets uuid.
In case of LVM it's udev rule which creates some links.
There is no one format of UUID  (like on Windows) which would be used across whole linux system.

So IMHO there is no real reason to provide --uuid change feature for LV.
and I'd probably reject this request since it's not adding any value.

As far as the system has unique VG uuid - there could never be device with conflicting lv device uuid.

That's also a reason why lvm2 is requiring to resolve VG uuid collision - since it makes things hard to use and you get big WARNINGs for this case.

Also note that uuid for LV is only identifier which is handled within VG,
tool will refuse to store VG with duplicated LV name, and unless you
would want to put there some 'nice' letters into uuid there is not much
reason to allow to change it - but we surely advice to use  'lv names' for
this - which are nicer abbreviation for 'cryptic' uuids...
Comment 3 Christoph Anton Mitterer 2013-06-30 10:22:54 EDT
Hi Zdenek.

I see, admittedly I didn't know that the LV UUID is namespaced in the VG :)
Is this somewhere documented (and I haven't seen it) or should it be added?

So for that part I agree that technically it wouldn't be necessary to add --uuid for lvchange (but perhaps adding documentation, why this is so, if it's still missing).

There could be though some little reasons to add it (the lvchange --uuid) nevertheless:
a) There speaks nothing against having it ;-)
b) 3rd party tools may use the LV UUID (and they would encounter duplicates then)... but okay...this is actually stupid, and shouldn't be done then (when LV UUIDs are only unique within a VG)... so we rather should tell people in the manpages that LV UUIDs are unique only within an VG (and their UUIDs)... so that 3rd party tools also use both VG_UUID + LV_UUID.

I'm not sure whether I understood you with respect to the other questions, i.e. does (and how far) it break my system if I ever encounter PVs or VGs with the same UUID ... and/or VGs/LVs with the same name...
I personally see this quite often (due to cloning not only in VMs but cloning in the sense of copying whole disk images via e.g. dd)... it seems at least that the system continues to use the already active VGs/LVs and that the filesystem mountpoints upon them stay valid.

Comment 4 Alasdair Kergon 2013-07-01 19:55:17 EDT
Indeed, the LV uuid is an internal LVM implementation detail and is not something over which the user has any control.

Any problems you are seeing will be due to duplicate PV or VG uuids.  There are supported ways to change those in a controlled and correct way, such as 'vgimportclone'.

Currently LVM requires that every device visible on a system has a different PV uuid and every VG has a different VG uuid.  After cloning, UUIDs should be changed immediately, using filters as necessary.

LVs in such cloned VGs should never be activated - always make the UUIDs different first.

As such, I am closing this bugzilla.  (Bug 979725 could perhaps be changed to discuss new requirements for access to cloned/guest LVs, though I think we might have a bug or two already open for that.)
Comment 5 Christoph Anton Mitterer 2013-07-01 21:41:51 EDT

Yeah let's discuss the clone/UUID/names issues in bug #979725.

But one thing I'd like to see done here:
Is it already somewhere documented in the LVM manpages, that the LV UUIDs are only unique in combination with the VG UUIDs? At least I couldn't find it.

I think this should be added to the documentation,... as there might be 3rd party apps which (for whatever reason) use the LV UUIDs (as key or whatever)... and I shouldn't do no harm to add one or two lines to the docs which tell them about this fact :)

Comment 6 Alasdair Kergon 2013-07-02 06:06:12 EDT
It's more obvious with the older lvm1 format of metadata where the ids are just 1, 2, 3, ...

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