EVA diskgroup objectid

[Cmorrall]

Using sssu and the command "ls disk_group full xml" will produce among other a line like:
00010710B4080560BE48070000A0000000000400

How is this ID generated, and can I relate this to the parent EVA? The obvious answer would be to look at but the value is the same for all disk groups across every EVA I have ever seen.

Knowing how is created is however of less use than knowing if this ID is:
a) globally unique
b) never changes, if for example the disk group name changes
c) is never reused, for example the disk group is deleted and a new one is created, possibly with the same name.

The above would also apply for

[Bert Zefat]

The only thing I know from the EVA is that all object can have numbers related to an array in the memory of the EVA. So will for example DR 1 have id 8000 and DR 2 8001 (just examples). So that the number is the same at all EVA's can be explained as the register array on each EVA is the same,it points to a unique DR, but the numberin an other EVA can point to a totaly differenct size / setup DR.
If for example DR 8001 is deleted, the next DR created will have 8001 again.

I hope I make a bit sence here.

[Cmorrall]

Although I'll look into DR Groups at some point, right now I would really like a definite answer on the , and if it's globally unique. I can always find out which EVA it belongs to by styding the total output, but I need to be sure it never changes if you change the disk group name or delete it and create a new disk group.

[Uwe Zessin]

Charles,

all these details are completely undocumented. Let's be realistic: even if somebody gives you an answer about the uniqueness of some UUIDs today it could change with the next firmware revision. (Remember how the SSSU 'SHOW' output changed its formatting any couple of releases?)

[Cmorrall]

Resurrecting an old thread, the need for more info on the id format has been renewed.

This time, it has been brought to my attention the following:
Look at the output from "ls system full xml"
...
08000710B4080560D2470B000070000000000200
...

Extract characters 9 to 27 from the string, you get B4080560D2470B00007.

Then do "ls disk_group full xml"
...
00010710B4080560D2470B000070000000000400
Same extraction, and you have a match.

This is also found in for example in hosts, vdisks and luns. Not in individual physical disks though. Seems like created "soft" objects share the same partial string, but not "hard" objects like controllers and disks.

Someone out there must have some knowledge about these structures, they can't be completely random.

[Uwe Zessin]

Look at the controller back-end port WWNs.
When I checked it some years ago and unless this has changed:
Most of these bits come for the (at that time current) master controller's WWN.

> Someone out there must have some knowledge about these structures,
> they can't be completely random.

The original designer ;-)

The question is whether (s)he is willing/allowed to talk about these details or the company claims those are confidential.


It is hard enough to talk though L1/L2 and get some information about the SSSU tags when looking after a problem...

[Cmorrall]

I'm not able to correlate the backend wwn from either controller to the extract from the objectid I found. Perhaps there is some calculation that needs to be made, but it's nothing obvious.

Thanks for trying Uwe, I'll see what I can dig up elsewhere.