vxvm: identify dg from a ctd?

[VK2COT]

Hello Doug,

You are right. Looks unusually complex.

Pity "vxdisk path" is not supported
in HP-UX 11.11. I was hoping for it
to help a bit.

Another idea. What do long listings in
these directory listings show:

/dev/vx/rdmp
/dev/vx/rdsk
/dev/rdsk

Also, could you run this commands
for the two paths (path for vxdmpinq command
is /etc/vx/diag.d or /usr/lib/vxvm/diag.d):

vxdmpinq /dev/rdsk/c8t6d0

vxdmpinq /dev/rdsk/c10t6d0

Serial numbers should be the same for the
two disks.

So, we could, in the worst case,
use simple loop for all PVs in
/dev/rdsk and run command
vxdmpinq and compare serial numbers...

I wish I had HP-UX 11.11 server to check it.
Alas, I am fully migrated to 11.31 now.

We will figure something out :)

Cheers,

VK2COT

[Doug O'Leary]

Well, that seems useful:

# /usr/lib/vxvm/diag.d/vxdmpinq /dev/rdsk/c10t6d6

Inquiry for /dev/rdsk/c10t6d6, evpd 0x0, page code 0x0
Vendor id : EMC
Product id : SYMMETRIX
Revision Number : 5670
Serial Number : 752D5000g

# /usr/lib/vxvm/diag.d/vxdmpinq /dev/rdsk/c8t6d6

Inquiry for /dev/rdsk/c8t6d6, evpd 0x0, page code 0x0
Vendor id : EMC
Product id : SYMMETRIX
Revision Number : 5670
Serial Number : 752D5000g

# grep c8t6d6 parsed
750 02d5 34524.00 c10t6d6 c8t6d6

Ah, bummer. That's the disk's meta ID number. I was hoping that was going to be the serial number of the disk group to which these disks belong. Another disk that belongs to the same disk group has a different number:

# /usr/lib/vxvm/diag.d/vxdmpinq /dev/rdsk/c8t5d6

Inquiry for /dev/rdsk/c8t5d6, evpd 0x0, page code 0x0
Vendor id : EMC
Product id : SYMMETRIX
Revision Number : 5670
Serial Number : 75231000g


The serial number also matches what I'm getting from EMC's inq command. Finding the CTDs that belong to the same disk is something I can already do.

Given /dev/dsk/c8t5d6, though, I'd like to find a way that will tell me it belongs to MCPdg.

The functions in the id_lv_scripts, posted a couple of replies back, show how it can be done on LVM disks:

# disp_vgids
vg00 f0e6846743cd2a2e
vgSCP f0e68467450064c4
vgSCP2 f0e68467450064d5

# id_vgid /dev/dsk/c8t11d0
f0e68467450064d5

So, if c8t11d0 wasn't part of the vg because the admin didn't add both disks together, pvdisplay would error out; however, we can see that the vgid in the disk header matches vgSCP2 so that disk should be in that volume group.

Thanks

Doug

[VK2COT]

Hello,

This is getting more and more interesting :)

Do these commands report anything of value:

vxdmpadm getsubpaths dmpnodename=c8t6d0

vxdmpadm getsubpaths dmpnodename=c10t6d0

vxsymquery â g sapdataMDPdg

VK2COT

[VK2COT · Accepted solution]

One more idea:

vxprivutil scan /dev/rdsk/c8t6d0

vxprivutil scan /dev/rdsk/c10t6d0

and another one:

vxprivutil dumpconfig /dev/rdsk/c8t6d0 | \
vxprint -D - -mvps

vxprivutil dumpconfig /dev/rdsk/c10t6d0 | \
vxprint -D - -mvps

Cheers,

VK2COT

[VK2COT]

Here are the examples of these commands
on HP-UX 11.31 that I built in
HP Edu labs in Australia for teaching.

# /etc/vx/type/static/vxprivutil scan /dev/rdisk/disk6_p2

diskid: 1222122236.6.loopback
group: name=rootdg id=1222122236.8.loopback
flags: private autoimport
hostid: loopback
version: 2.1
iosize: 1024
public: slice=0 offset=3168 len=70762400
private: slice=0 offset=2144 len=1024
update: time: 1233085983 seqno: 0.39
headers: 0 248
configs: count=1 len=683
logs: count=1 len=103


# /etc/vx/type/static/vxprivutil dumpconfig /dev/rdisk/disk6_p2
#Config copy 01

#Header nblocks=5464 blksize=128 hdrsize=512
#flags=0x100 (CLEAN)
#version: 4/14
#dgname: rootdg dgid: 1222122236.8.loopback
#config: tid=0.1145 nstpool=0 nrvg=0 nrlink=0 ncache=0 nvol=8 nplex=8 nsd=9 ndm=
1 nda=0 nexp=0
#pending: tid=0.1145 nstpool=0 nrvg=0 nrlink=0 ncache=0 nvol=8 nplex=8 nsd=9 ndm
=1 nda=0 nexp=0
#
#Block 5: flag=0 ref=3 offset=0 frag_size=83
#Block 7: flag=0 ref=28 offset=0 frag_size=104
#Block 8: flag=0 ref=2 offset=0 frag_size=104
...
(long report truncated for the sake of brevity).

As you can see, these commands could help
you. A simple loop of all PVs in
/dev/rdsk (legacy DSFs) or /dev/rdisk (agile
DSFs) and running the above commands through
them and comparing the results for DGIDs.

Cheers,

VK2COT

By the way, I updated my Perl script to
include the above commands for each PV,
so I wonder what report you get on your
old server:

http://www.circlingcycle.com.au/Unix-sources/HP-UX-check-OAT.pl.txt

[Doug O'Leary]

hey;

There it is! That's the trick. I *knew* there had to be a way to identify the disk group from a CTD.

# grep -e c13t1d6 -e c10t6d5 parsed1
720 4937 46082.00 c13t1d6 c16t1d6 Unknown
750 02c9 34524.00 c10t6d5 c8t6d5 MCPdg
# vxprivutil scan /dev/rdsk/c10t6d5 | grep ^group
group: name=MCPdg id=1227700780.1245.usilap35
# vxprivutil scan /dev/rdsk/c8t6d5 | grep ^group
group: name=MCPdg id=1227700780.1245.usilap35

And it errors out on disks that aren't part of vxvm:

# vxprivutil scan /dev/rdsk/c13t1d6
vxvm:vxprivutil: ERROR: scan operation failed:
No such file or directory
# ls -ld /dev/rdsk/c13t1d6
crw-r----- 1 bin sys 188 0x0d1600 Feb 6 17:22 /dev/rdsk/c13t1d6

And, just for grins, let's see how it handles an LVM disk:

# vxprivutil scan /dev/rdsk/c2t1d0
vxvm:vxprivutil: ERROR: scan operation failed:
No such file or directory


Outstanding, sir1 Thank you very much.

Doug O'Leary

[Doug O'Leary]

Hey;

vxprivutil definitely goes into the lessons learned site!

Thanks again.

Doug O'Leary