I suggest adding this to the new restructured versions of process_each where it should be simpler to do (it's already processing based on vg_name/vg_uuid pairs, and just needs to check if an arg name is actually a uuid).  I'll look at adding this the next time I rebase the toollib patch set.

The issue is one of locking.

VG locks are based on the VG name not the UUID.

The current code gets the VG lock based on the name from the command line, then goes to get the metadata.

This change requires it to 'guess' (lookup/search for) the right VG, then once it's got what it thinks is the right VG, take the VG lock, and then confirm that the name+uuid is still correct.

Yes, I'd forgotten about the locking implications.  In this case, processing vg uuid's would be fairly close to the way I process tags.  With tags I get the complete list of vg_name/vg_uuid pairs, and then select vgs from that list based on matching tags.  With uuid's I'd do the same but match against the uuid.
With explicit names, I do not need to get the full vg list to select from, but can go directly to processing.  So, it would be little more complicated that I'd thought, but shouldn't be too bad.

Also bug #449832 (rawhide one) and bug #1054803 (RHEL one where 2 VGs with the same name cause problems)

This commit takes vg uuids on the command line for commands using process_each_vg:

https://git.fedorahosted.org/cgit/lvm2.git/commit/?h=dev-dct-process-v7&id=d094861a4e2364ab6267c36ceb3a6b97a7b4eda0

If this looks good, I can do the same for commands using process_each_lv.

A new version of the patch that handles vg's with names that are uuids.
A uuid on the command line is first matched against a vg that has a
name matching the uuid, then an attempt is made to match the uuid
with vg uuids.

Should there be a config option to enable the new matching against vg uuids?  Existing users will have vg's with uuid names.  For them, command behavior
will change when they use these names as command args.

A command like "vgs vg_name", where vg_name is a valid uuid (generated be
the user during vgcreate), will currently lock and read only the single vg.

With this patch, the same command will use a global lock, and then lock and
read all vgs.  It does this expecting that it will need to compare the uuid
arg against vg uuid's (very similar to tag comparisons.)

Alternatives to a config option would be a command option to enable the
names to be interpreted as uuids, or a special prefix before uuids, as
is done for tags.  Some existing commands accept vg uuids without these
things, so consistency with them may be an issue.

https://git.fedorahosted.org/cgit/lvm2.git/commit/?h=dev-dct-process-v8&id=64a8fb13ab49653bc4b69822c3206b5295628256

test:
https://git.fedorahosted.org/cgit/lvm2.git/commit/?h=dev-dct-process-v8&id=bc0f5684c93278c6083b50d71bb4cf8c2e7a4fb4

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

I added a comment to bug 867376 related to using the command-line-selection syntax from that bug.  That syntax will tell us if a uuid arg is meant to
match a vg's uuid or name.  This should simplify the current patch and test.
It will also avoid the problem of uuids as names causing all vgs to be read.

Created attachment 885490 [details]
patch

Current patch.  If will need to be updated to take advantage of new uuid selection syntax (when available), and can probably be simplified because of that.

Created attachment 885491 [details]
patch

Test for the previous patch.  This will also need to be updated for the new uuid selection method.

*** Bug 1054803 has been marked as a duplicate of this bug. ***

With the new select option, we can do this with: vgs -S uuid=...