1. Determine which Physical Volumes belong to Volume Group /dev/vg00.

# strings /etc/lvmtab
/dev/vg00
/dev/disk/disk6
/dev/disk/disk10
...

2. Extract 8 Kb, skipping the first 8 Kb from the Physical Volumes using the dd command.
# dd if=/dev/rdisk/disk6 of=/tmp/disk6.dd bs=8k skip=1 count=1
1+0 records in
1+0 records out

# dd if=/dev/rdisk/disk10 of=/tmp/disk10.dd bs=8k skip=1 count=1

1+0 records in
1+0 records out

3. Display the content of the dump files using the od command.

# od -Ax -tx /tmp/disk6.dd
0000000 4c564d52 45433031 1e69dc32 4ad20b84
0000010 1e69dc32 4ad20b84 21eb38f 0
0000020 270 860 126 a
0000030 860 998 8 990
0000040 ac8 21ea000 b60 17
0000050 2000 82f 21eab60 1
0000060 0 10 80 2
0000070 80 88 6 82
0000080 8a 0 0 0
0000090 0 0 0 0
*
0000400 44454645 43543031 0 0
0000410 0 0 0 0

# od -Ax -tx /tmp/disk10.dd

0000000 4c564d52 45433031 1e69dc32 4b2fc49f
0000010 1e69dc32 4ad20b84 21eb38f 1
0000020 270 80 126 a
0000030 80 1b8 8 1b0
0000040 2e8 21ea000 400 17
0000050 2000 f8f 21ea400 1
0000060 0 0 0 0
*
0000400 44454645 43543031 0 0
0000410 0 0 0 0
The VGID is shown on the first and second columns of line 0000010. In this example, the VGID
on both physical volumes primary disk is1e69dc324ad20b84. Note that that the third column of
line 0000000 and the first column of line 0000010 are the same. This is the HostID portion of the
VGID.
You can verify this information creating a share mode map file using the -s option of the vgexport
command.
# vgexport -p -s -m /tmp/vg00.mapfile /dev/vg00
vgexport: Volume group "/dev/vg00" is still active.
vgexport: Preview of vgexport on volume group "/dev/vg00" succeeded.
# cat /tmp/vg00.mapfile
VGID 1e69dc324ad20b84
1 lvol1
2 lvol2
3 lvol3
4 lvol4
5 lvol5
6 lvol6
7 lvol7
8 lvol8
9 lvol9

The same information can be obtain directly from the physical volume without dumping the data
with the dd command using the xd command.
# xd -An -j8200 -N16 -tx /dev/rdisk/disk6
1e69dc32 4ad20b84 1e69dc32 4ad20b84
# od -j8k -N32 -tx /dev/rdisk/disk6
0000000 4c564d52 45433031 1e69dc32 4ad20b84
0000020 1e69dc32 4ad20b84 21eb38f 0
0000040

Create unformatted VGID reports

A quick and dirty VGID report can be created using Postfix Shell scripts.
Using Legacy Device Special Files
Based on the available device special files:
for pv in $(ls /dev/rdsk/*)
do
echo $pv
xd -An -j8200 -N16 -tx $pv 2> /dev/null
done

Example:
# for pv in $(ls /dev/rdsk/*)
> do
> echo $pv
> xd -An -j8200 -N16 -tx $pv 2> /dev/null
> done
/dev/rdsk/c0t0d0
/dev/rdsk/c2t10d0 1010101 1010101 1010101 1010101
/dev/rdsk/c2t12d0 1e69dc32 4ad7841a 1e69dc32 4ad777e4
/dev/rdsk/c2t1d0 1e69dc32 4ad20b84 1e69dc32 4ad20b84
/dev/rdsk/c2t8d0 1e69dc32 4ad25312 1e69dc32 4ad25332
/dev/rdsk/c3t0d0 1e69dc32 4b2fc49f 1e69dc32 4ad20b84

Based on a list of physical volumes from the ioscan I/O tree:

for pv in $(ioscan -fnC disk | awk '{if(NF==2) printf $1 "\n"}')
do
echo $pv
xd -An -j8200 -N16 -tx $pv 2> /dev/null
done

Example:
# for pv in $(ioscan -fnC disk | awk '{if(NF==2) printf $1 "\n"}')
> do
> echo $pv
> xd -An -j8200 -N16 -tx $pv 2> /dev/null
> done
/dev/dsk/c0t0d0
/dev/dsk/c2t1d0 1e69dc32 4ad20b84 1e69dc32 4ad20b84
/dev/dsk/c2t8d0 1e69dc32 4ad25312 1e69dc32 4ad25332
/dev/dsk/c2t10d0 1010101 1010101 1010101 1010101
/dev/dsk/c2t12d0 1e69dc32 4ad7841a 1e69dc32 4ad777e4
/dev/dsk/c3t0d0 1e69dc32 4b2fc49f 1e69dc32 4ad20b84

Using Agile Device Special Files

Based on the available device special files:
for pv in $(ls /dev/rdisk/*)
do
echo $pv
xd -An -j8200 -N16 -tx $pv 2> /dev/null
done
Example:
# for pv in $(ls /dev/rdisk/*)
> do
> echo $pv
> xd -An -j8200 -N16 -tx $pv 2> /dev/null
> done
/dev/rdisk/disk10 1e69dc32 4b2fc49f 1e69dc32 4ad20b84
/dev/rdisk/disk11
/dev/rdisk/disk6 1e69dc32 4ad20b84 1e69dc32 4ad20b84
/dev/rdisk/disk7 1e69dc32 4ad25312 1e69dc32 4ad25332
/dev/rdisk/disk8 1010101 1010101 1010101 1010101
/dev/rdisk/disk9 1e69dc32 4ad7841a 1e69dc32 4ad777e4

Based on a list of physical volumes from the ioscan I/O tree:

for pv in $(ioscan -NfnC disk | awk '/\/dev\/rdisk/ {print $2}')
do
echo $pv
xd -An -j8200 -N16 -tx $pv 2> /dev/null
done

Example:
# for pv in $(ioscan -NfnC disk | awk '/\/dev\/rdisk/ {print $2}')
> do
> echo $pv
> xd -An -j8200 -N16 -tx $pv 2> /dev/null
> done
/dev/rdisk/disk6 1e69dc32 4ad20b84 1e69dc32 4ad20b84
/dev/rdisk/disk7 1e69dc32 4ad25312 1e69dc32 4ad25332
/dev/rdisk/disk8 1010101 1010101 1010101 1010101
/dev/rdisk/disk9 1e69dc32 4ad7841a 1e69dc32 4ad777e4
/dev/rdisk/disk10 1e69dc32 4b2fc49f 0 0
/dev/rdisk/disk11

Create formatted VGID reports

Using Legacy Device Special Files
printf "%-18s | %-17s | %-17s\n" "PV" "VGID" "PVID"; \
for pv in `ls /dev/rdsk/*`
do
xd -An -j8200 -N16 $pv > /dev/null 2>&1
if [[ $? -eq 0 ]]; then
echo "$pv \c"
xd -An -j8200 -N16 -tx $pv 2> /dev/null
fi
done \
| awk '$0 ~ /dev/ {printf "%-18s | %8s %8s | %8s %8s\n", $1, $4, $5, $2, $3}' \
| sort -k 2,5

Example:
PV | VGID | PVID
/dev/rdsk/c3t0d0 | 0 0 | 1e69dc32 4b2fc49f
/dev/rdsk/c2t1d0 | 1e69dc32 4ad20b84 | 1e69dc32 4ad20b84
/dev/rdsk/c2t8d0 | 1e69dc32 4ad25332 | 1e69dc32 4ad25312
/dev/rdsk/c2t10d0 | 1010101 1010101 | 1010101 1010101
/dev/rdsk/c2t12d0 | 1e69dc32 4ad777e4 | 1e69dc32 4ad7841a

Using Agile Device Special Files

printf "%-18s | %-17s | %-17s\n" "PV" "VGID" "PVID"; \
for pv in `ls /dev/rdisk/*`
do
xd -An -j8200 -N16 $pv > /dev/null 2>&1
if [[ $? -eq 0 ]]; then
echo "$pv \c"
xd -An -j8200 -N16 -tx $pv 2> /dev/null
fi
done \
| awk '$0 ~ /dev/ {printf "%-18s | %8s %8s | %8s %8s\n", $1, $4, $5, $2, $3}' \
| sort -k 2,5

Example:
PV | VGID | PVID
/dev/rdisk/disk8 | 1010101 1010101 | 1010101 1010101
/dev/rdisk/disk6 | 1e69dc32 4ad20b84 | 1e69dc32 4ad20b84
/dev/rdisk/disk7 | 1e69dc32 4ad25332 | 1e69dc32 4ad25312
/dev/rdisk/disk9 | 1e69dc32 4ad777e4 | 1e69dc32 4ad7841a
/dev/rdisk/disk10 | 0 0 | 1e69dc32 4b2fc49f

Alternate method to obtain the Volume Group VGID

The information can be found directly on the /etc/lvmtab binary file. To crate VGID list for every
volume group, the following command can be used:
strings -t d /etc/lvmtab | grep /dev/[^d] | sort -k 2 | while read offset vg
do
xd -An -j$(($offset+1024)) -N8 -tuL /etc/lvmtab | read v1 v2
printf "%-15s %x%x\n" $vg $v1 $v2
done

Example:
# strings -t d /etc/lvmtab | grep /dev/[^d] | sort -k 2 | while read offset vg
> do
> xd -An -j$(($offset+1024)) -N8 -tuL /etc/lvmtab | read v1 v2
> printf "%-15s %x%x\n" $vg $v1 $v2
> done
/dev/vg00 1e69dc324ad20b84
/dev/vg01 1e69dc324ad25332
Reading PVID / VGID from the Volume Group Configuration File
If it is not possible to identify the PVID and VGID from a set of disks (in case that all of them are
different), you can match this values with the information record on the Volume Group Configu
ration File located at the /etc/lvmconf directory:
for vg in $(ls /etc/lvmconf/*.conf)
do
echo $vg
xd -An -j1024 -N32 -tx $vg
done

Example:
# for vg in $(ls /etc/lvmconf/*.conf)
> do
> echo $vg
> xd -An -j1024 -N32 -tx $vg
> done
/etc/lvmconf/vg00.conf
4c564d52 45433031 1e69dc32 4ad20b84
1e69dc32 4ad20b84 21eb38f 0
/etc/lvmconf/vg01.conf
4c564d52 45433031 1e69dc32 4ad25312
1e69dc32 4ad25332 21eb38f 0
/etc/lvmconf/vg02.conf
0 0 20000 1
1 11050 440 0

Alternative, the xd command can be used for the same purpose:

for vg in $(ls /etc/lvmconf/*.conf)
do
echo $vg
xd $vg | grep 00004[01]0
echo
done

Example:
# for vg in $(ls /etc/lvmconf/*.conf)
> do
> echo $vg
> xd $vg | grep 00004[01]0
> echo
> done
/etc/lvmconf/vg00.conf
0000400 4c56 4d52 4543 3031 1e69 dc32 4ad2 0b84
0000410 1e69 dc32 4ad2 0b84 021e b38f 0000 0000
/etc/lvmconf/vg01.conf
0000400 4c56 4d52 4543 3031 1e69 dc32 4ad2 5312
0000410 1e69 dc32 4ad2 5332 021e b38f 0000 0000
/etc/lvmconf/vg02.conf
0000400 0000 0000 0000 0000 0002 0000 0000 0001
0000410 0000 0001 0001 1050 0000 0440 0000 0000

take a hex dump of the lvmtab file and compare it to the output of Bill Hassell's "showLVMinfo"
script. You'll find the CPUID and VGID values *are* included in the lvmtab file in binary format.
With a quick glance, the PVIDs don't seem to be included.

The '/etc/lvmtab' is a binary data file. Hence, the 'stings' command only makes a "best attempt" to
produce printable characters from groups of 4-characters.

Aside from the device file and volume group names, a 'strings /etc/lvmtab' will not generally
expose much meaningful data. As Matti noted, an octal (or hex) dump will be more informative.

The file actually contains the physical device paths for each volume group defined to the system.
In addition, the VGID (Volume Group Identification) and some other state information about each
volume group is recorded.

One way to decode the file is (knowing its internal layout) to use Perl. I did it some years ago as
an exercise but no longer have the script.

The best way, in my opinion, to evaluate PVID and VGID information is to read the physical disk
itself as any of the aforementioned links will show. Remember that a 'vgexport' of a volume group
will remove it from '/etc/lvmtab'. You still might want to assess something more about its origin,
though, and the PVID and VGID signatures are there on the disk for the reading.

Its always important to save a mapfile for every VG using the -p -s -m options. The man page says
shared (cluster) mode but really should say -s = serial number. It makes no difference whether PVs
are shared or not -- you need the VGID in order to reconstruct (vgimport) or simply identify loose
LUNs and alternate paths. showLVMinfo has the xd command with offset to find the LVMREC
headers on any disk. lvmtab has never been openly documented and really represents just a
snapshot of the VGs. Every PV that has been (or is) part of a VG will have the LVMREC at offset
2000 and that's how vgscan and vgimport find all the disks.

Change it to the VGID of the volume group it is to be vgimport'ed into. The VGID is a unique
identifier comprised of the CPU-ID and the date and time stamp of when the desired VG was
created.

The vgchgid command is designed to change the LVM Volume Group ID (VGID) on a supplied
set of disks
when you 'pvcreate' a disk, an LVM header is written with a Physical Volume ID (PVID).
Similarly, a VGID (Volume Group ID) is written when a 'vgcreate' is done using the physical
volume. These IDs are actually composed of the 'uname -i' ID and the timestamp (in epoch
seconds) of the instantiation.

The VGID form the basis for enabling a 'vgimport -s' to find all disks that below to a volume
group. Similarly, a 'vgscan' that is run to rebuild '/etc/lvmtab' examines the previously writen
VGIDs to determine "who" belongs "where".

Reemmber with 11iv2 we have LVMv2 which is totally different and has a different LVM header.
cat display_lvmids
#!/usr/bin/sh
#
# $1 should be /dev/rdsk/c_t_d_ or /dev/rdisk/diskxxxx
#
typeset RDEV=$1
KIND=`xd -An -j 8192 -N8 -tc ${RDEV} 2> /dev/null | xargs`
if [ "$KIND" = "L V M R E C 0 1" ]; then
INFO=`xd -An -j8200 -N16 -tx ${RDEV}`
PVID=`echo ${INFO} | awk '{print $1 $2}'`
VGID=`echo ${INFO} | awk '{print $3 $4}'`
echo "${RDEV} pvid = ${PVID} vgid = ${VGID}"
elif [ "$KIND" = "L V M R E C 0 2" ]; then
VGID=`xd -An -j8208 -N84 -tc ${RDEV} | cut -c5- | cut -c 1,5,9,13,17,21,25,29,33,37,41,
45,49,53,57,61|tr -d '\n'`
echo "${RDEV} vgid = ${VGID}"
else
echo did not reconize $RDEV as a LVM disk
fi

The 'pv_lock' file is used by 'pvcreate'. It should not be modified manutally. It is used to insure
that at least one-second elapses between sucessive 'pvcreate' operations. This insures that the
PVID written to an LVM physcial disk is unique, since the PVID consists of an Epoch seconds
compon ent and the unique machine ID as seen in 'uname -i'.

root@or:/> vgdisplay -v vg00 | grep "PV Name"

PV Name /dev/dsk/c55t0d0s2
PV Name /dev/dsk/c48t0d0s2

root@or:/> xd -An -j8200 -N16 -tx /dev/dsk/c55t0d0s2 |awk '{print$1}'|grep -v "^\ "
3a6b51ec
root@or:/> xd -An -j8200 -N16 -tx /dev/dsk/c55t0d0s2 |awk '{print$4}'|grep -v "^\ "
459149ac

root@or:/> cat /etc/lvmconf/vg00.mapfile | head -1

VGID 3a6b51ec459149ac

this is 11.31 with persistent devices using lvm 2.2 so an example

output of lvmadm -l
VG Name /dev/vgdatabase
PV Name /dev/disk/disk12

VG Name /dev/vgarchive
PV Name /dev/disk/disk22

xd -An -j8200 -N16 -tx /dev/disk/disk22 |awk '{print$1}'|grep -v "^\ "

20000
xd -An -j8200 -N16 -tx /dev/disk/disk12 |awk '{print$1}'|grep -v "^\ "
20000

even without the grep displaying all values all the values are the same
xd -An -j8200 -N16 -tx /dev/disk/disk22
20000 0 41303030 30303030
xd -An -j8200 -N16 -tx /dev/disk/disk12
20000 0 41303030 30303030

i'm wondering if this relates to LVM2.2

yes it does relate, if you are using lvm2.X, you can get the info using:
For the PVID, use:
xd -An -j8208 -N17 -tc DISK
For the VGID, use:
xd -An -j8344 -N17 -tc DISK

A 'mapfile' is primarily used to assign *logical volume* IDs in lieu of defalt ones like 'lvol1',
'lvol2', etc. The use of the '-s' switch adds (during 'vgexport') the VGID of the volume group which
then allows 'vgimport' to match disks to this ID and import them.

This said, there is no problem with having the same PVID and VGID. In reality, these IDs are
nothing more than the machine identification number (as seen in 'uname -i') and the timestamp (in
Epoch seconds) built when the 'pvcreate' and 'vgcreate' were made.

You can even change the vgid using vgchgid command without changing lvmtab or special files.
During activation, the only check done on disks is that all PV in a vg have the same vgid, that
all ...
It is possible, this information vgid <-> VG is kept in /etc/lvmtab. But it is not really easy to
retrieve it:
For example:
#echo "0x40C?2x" | adb /tmp/lvmtab
40C: 2096147D 3AB1ED17
You have the vgid just before the first disk of the vg. You have to write a small c programm to do
that. The last solution is to directly retrieve the vgid on the device itself, it is always at the same
place:
#echo "0x0002010?2x" | adb /dev/dsk/c8t2d0
2010: 2096147D 3AB1ED17

To add to the information already provided, remember that the very way to rename a volume
group is to first 'vgexport' it [which removes the '/dev/vgXX' structures from the server and purges
'/etc/lvmtab' of the VG information]. Having done this, you create a new directory representing the
new VG name (e.g. /dev/myvg) and a group file with a unique minor number of your choice, and
'vgimport' the appropriate physical disk [either by matching the VGID or by specifying the actual
physical disks].
Thus, the *name* of a volume group is "known" only through the device directory structure, and
is not recorded on the physical disk(s) comprising the volume group.
strings -td /etc/lvmtab |
grep /dev |
grep -v /dev/dsk |
while read offset path; do
xd -An -j$(($offset+1024)) -N8 -tuL /etc/lvmtab |
read vgid1 vgid2
echo $path $vgid1-$vgid2
done

to get the VGID, e.g.:

# echo "0d8208?uu" | adb /dev/dsk/c11t0d0
2010: 3216063718 1046873340

BTW, here is another way to look at the VGID:

# echo "0d8208?uy" | adb /dev/dsk/c11t0d0
2010: 3216063718 2003 Mar 5 15:09:00
# uname -i
3216063718
You see that the vgcreate was issued on Mar 5 from this system.

Same applies for the PVID, which corresponds to the pvcreate timestamp.
# echo "0d8200?uy" | adb /dev/dsk/c11t0d0
2008: 3216063718 2002 Mar 11 14:36:31
The VGID is also found in /etc/lvmconf/.conf file... and this file is PERSISTENT, i.e., it is not
deleted from /etc/lvmconf directory even when VG is removed.

I don't know the exact offset but I:

1) find out the VGID of VG00 (for instance 0603a2833f71603e)

2) run the following command line:

xd -An -tx1 -v /etc/lvmconf/vg00.conf | sed 's/ \([[:xdigit:]]\)/ 0\1/g' | tr -d '[\t ]' | grep
0603a2833f71603e