Objects such as volume groups or hosts that are being replicated in a PBR/PBHA config exist as individual objects with local IDs on each FlashSystem Cluster, although they actually are considered as unique objects in a cluster-overarching context.
When using (automation-)tools which gather information via REST API / CLI about those (replicated) objects on a per-system basis, you may get the information about such a replicated object multiple times with potentially different characteristics, as the information will be gathered multiple times from multiple sources (here: individual clusters), while each system may refer the object with differing local IDs and characteristics.
If you want to post-process this information, you may need to determine which information can be tied together to one single object. This gets challenging, since there is no universal unique identifier (apart from the object name which is not a good choice from a programming perspective) by which the information from multiple sources can be tied together again.
While a "storage partition" and a "volume" object are equipped with a UUID that is identical on all clusters that are sharing this object, there is no such equivalent for the objects "host" and "volume group". Even the replication policy ID can be different for each cluster.
Example:
A monitoring tool is gathering the output of "lsvolumegroup" from Cluster A and from Cluster B who are in a PBHA relationship. Queries via REST API against both clusters will provide two json results which contain each let's say a volume group called "pbr-vg1" - but one time referred as volume group id 0 (on Cluster A) and one time referred as volume group id 3 (on Cluster B). How can the monitoring tool determine that the volume group id 0 from Cluster A is in fact the same object like the volume group id 3 from Cluster B when postprocessing and interpreting the json information?
Right now this only possible by assuming that the object name is identical on both sides and is not changeable as long as it is part of an active replication config.
But what if a future release of Storage Virtualize allows object renaming in active PBR or PBHA configs?
How can the monitoring/automation tool then keep track that it is still the same object, when it appeared as "pbr-vg1" in first scan iteration and suddenly appears as "pbr-vg1new" in a later scan iteration?
So that's why all objects that may appear in such a context should be equipped with an UUID that keeps unchanged for the entire lifetime of the object - in order to be able to properly orchestrate information that is coming from multiple clusters and keep track of the objects across all contexts