I guess there is some misunderstanding how the UUID works with LVs.
LV device uuid is composed from 3 pieces:

LVM-O6VNcgq5cc6en031EBx9inVszXxgOkTe3OBXO6ZhBYusjmlGOEcpkuzu1XD1WKsd

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...

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.


Thanks,
Chris.

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.)

Hi...

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 :)


Cheers,
Chris.

It's more obvious with the older lvm1 format of metadata where the ids are just 1, 2, 3, ...