After some researching and reading some ITRC, I found a way to get the age of the system. This is done with reading and decrypting the LVM header from the system disks. At first, we need to find out which disks are in vg00:
# vgdisplay -v vg00 | grep "PV Name" PV Name /dev/dsk/c2t0d0 PV Name /dev/dsk/c3t8d0 #
As you know, the first 8kbytes are the header on the disk, after that comes the PVRA (Physical Volume Reserved Area) in the next 8 bytes, containing the VGID and PVID. You can read the data from the disk after the first 8k with absolute debugger this way:
# echo "0x2008?4D" | adb /dev/dsk/c3t8d0 2008: 1708284819 1143225580 1708284819 1142954341 #
A short explanation to this: 0×2008 is a hex value which is exactly 8200 in decimal. (8192 bytes + 8 bytes = 8200 bytes) The ? is a separator character, after that comes 4D which stands there to tell the debugger that we want the output in decimal, 4 word long. In the upper output the first number is 1708284819, which stands for the CPUID, it refers to the system on which the VG was created. You can query the CPUID with the uname -i command:
# uname -i 1708284819 #
The second column is the so called VGID, technically it is a simple timestamp and it refers to the time the VG was created, it is in unix format. We can convert it to a much human-readable format with adb:
# echo 1143225580=Y | adb 2005 Sep 10 05:39:44 #
As we investigate a disk in the vg00, we can assume that the OS was installed around that time. So it is a good way to approximate the install time of a system. The third column is the CPUID again, it is the CPUID of the system on which the PVID header was created. And the last one is the timestamp of the PVID creation, also in unix format:
# echo 1142954341=Y | adb 2005 May 26 05:32:17 #
So from the above output we can assume the pvcreate was ran around 2005 May 26 05:32:17, and around 7 minutes later the vg00 was created. To verify this, let’s see the header on the other disk:
# echo "0x2008?4D" | adb /dev/dsk/c2t0d0 2008: 1708284819 1142954341 1708284819 1142954341 # echo "0x2008?4D" | adb /dev/dsk/c3t8d0 2008: 1708284819 1143225580 1708284819 1142954341 # echo 1143225580=Y | adb 2005 Sep 10 05:39:44 # echo 1142954341=Y | adb 2005 May 26 05:32:17 #
As you can see, the system in our example was installed around 2005 May 26 05:32:17, and after some months a mirror has been added to vg00 in september. For some non-vg00 disks, it can be that in a clustered environment a PV/VG was created on the other node, in this case the CPUID doesn’t match with the system. It can also be that after ServiceGuard HA package migration the disks of the VG were assigned to a new system, this can also affect the CPUID.