unique device files for vgexport vgimport with mksf in service guard

[Michael Roeder]

Hello,

i have an "optical" problem with my HW configuration.

Node1 (2xFWD controllers):
/dev/vghome
/dev/dsk/c3t4d0
/dev/dsk/c3t14d0
disk 21 8/8.4.0 sdisk CLAIMED DEVICE SEAGATE ST34371W
/dev/dsk/c3t4d0 /dev/rdsk/c3t4d0
disk 25 8/8.14.0 sdisk CLAIMED DEVICE SEAGATE ST34371W
/dev/dsk/c3t14d0 /dev/rdsk/c3t14d0

On Node1 with 1 FWD Controller, i didn't find the devices:
disk 7 8/8.4.0 sdisk CLAIMED DEVICE SEAGATE ST34371W
disk 11 8/8.14.0 sdisk CLAIMED DEVICE SEAGATE ST34371W

I habe run mksf -e to create them, i've got
/dev/dsk/c0t4d0 /dev/rdsk/c0t4d0
and
/dev/dsk/c0t14d0 /dev/rdsk/c0t14d0
but i liked the same as on Node1.
I did rmsf and created new with
mksf -H "8/8.4.0" /dev/dsk/c3t4d0
mksf -H "8/8.4.0" /dev/rdsk/c3t4d0
and so on.

Well, the problem is, vgimport is searching for c0t4d0:
vgimport -s -p -v -m /etc/cmcluster/maps/vghome.map /dev/vghome
Beginning the import process on Volume Group "/dev/vghome".
vgimport: Physical volume "/dev/dsk/c0t1d0" is not a block special file.
vgimport: Physical volume "/dev/dsk/c0t2d0" is not a block special file.
vgimport: Physical volume "/dev/dsk/c0t3d0" is not a block special file.
vgimport: Physical volume "/dev/dsk/c0t4d0" is not a block special file.
vgimport: Physical volume "/dev/dsk/c0t11d0" is not a block special file.
vgimport: Physical volume "/dev/dsk/c0t12d0" is not a block special file.
vgimport: Physical volume "/dev/dsk/c0t13d0" is not a block special file.
vgimport: Physical volume "/dev/dsk/c0t14d0" is not a block special file.

I have run mksf -e again and i've got additional
disk 7 8/8.4.0 sdisk CLAIMED DEVICE SEAGATE ST34371W
/dev/dsk/c0t4d0 /dev/rdsk/c0t4d0
/dev/dsk/c3t4d0 /dev/rdsk/c3t4d0

With /dev/dsk/c0t4d0, i can vgimport:
vgimport -s -p -v -m /etc/cmcluster/maps/vghome.map /dev/vghome
Beginning the import process on Volume Group "/dev/vghome".
Logical volume "/dev/vghome/lvhome" has been successfully created
with lv number 1.
Logical volume "/dev/vghome/lvexport" has been successfully created
with lv number 2.
Volume group "/dev/vghome" has been successfully created.

Is there any possibility to use the same device files as on node1? (/dev/dsk/c3t4d0 /dev/rdsk/c3t4d0)

Thanks.

Michael

[Tim Adamson_1]

Not sure if I understand your problem correctly.

But if you have all the disks available (including device files) and have created all the necessary vol groups and lvols and filesystems, then create the mapfile again:

# vgexport -s -p -m /tmp/vgmapfile /dev/vg??

Copy /tmp/vgmapfile to other node.

# mkdir /dev/vg??
# mknod /dev/vg??/group c 64 0x0?0000 (make sure this is the same as primary node)

# vgimport -s -m /tmp/vgmapfile /dev/vg??


You don't have to worry about device files or anything as the import process uses the VGID on the disk headers.

Hope that helps


Tim

[Michael Roeder]

Hi Tim,

i did vgexport like you, copied to node2, created device files and tried vgimport. With the c0t.d0 as device files, everything works fine.

I liked it with c3t4d0 as on node1, it looks good when it's the same device on both nodes.
The problem is:
node1:
c0t.d. is 1st HVD controler
c1t.d. ist SE SCSI
c2t.d. is 2nd HVD controller

on node2, there is only 1 HVD controller.
c0t.d. is HVD controler
c1t.d. ist SE SCSI

Maybe my mksf -H "8/8.4.0" /dev/dsk/c3t4d0 was wrong or is not possible.

The man page says, with vgimport -s, you can't use the pv_path option. Maybe i have to start with c0t.d.

[Tim Adamson_1]

Michael,

Unless your second system is setup identically, then you wont be able to use the exact same device files.

I agree that it does make for easier management if they are the same. However, your second system has one less controller.

It is possible to force the controller on the second node to use c3 instead of c0 if that is what you really want.


Tim

[Thomas J. Harrold]

You don't need the special files to use the same minor ID on both nodes. They can be different. MC/SG only cares about the VG name. Don't stress out about making everything identical. It's not required. That's what makes MC/SG so flexible.

-tjh

[Michael Roeder]

I know, Thomas. But, maybe, i'll upgrade with one more HVD controller later. You can get an old one for a few $. I would use the slot with the hardware path 8/4.x.y which ist c0t.d. on node1.

Tim, you wrote, "It is possible to force the controller on the second node to use c3 instead of c0 if that is what you really want."

Yes, that's it. Can you tell me how? Which manual?

[Stephen Doud]

.... an answer to your question above:
UXSGKBRC00005958
Title: Changing I/O Instance Numbers On A ServiceGuard Server

The document above also requires this document:
KBRC00004879
Title: How to change the instance numbers of ext_bus and dev files

Regards,
StephenD.

[Michael Roeder]

Stephen,

i didn't find any of the documents/Titles on itrc.hp.com. Any more hints?

[Tim Adamson_1 · Accepted solution]

You sure are game Michael :-)

Please note that it can be extremely dangerous to change the instance number of the card. Use at your own risk.

Please ensure you have a good, bootable make_tape_recovery tape as a fallback.

# ioscan -f | grep -e INTERFACE -e DEVICE | grep -v target | awk '{print $3, $1, $2}' > /newcfg

Edit /newcfg and change the ext_bus to the number you want (ie, 3). Make sure you get the right one!!!

Bring down the system to run level 1.

# init 1

Apply the ioconfig change:

# /sbin/ioinit -f /newcfg -r

The system will reboot immediately if the change is successful.

Warnings like 'Input is identical to kernel' can be ignored.

Hopefully it works!!!!

Good luck. If you have problems, post again and hopefully someone can provide a soultion.


Tim

[Stephen Doud]

The documents I gave you are available in the ITRC.HP.COM technical knowledge database.

Login to the ITRC.HP.COM site first (using the bar on the left and your system handle).
USING the "maintenance and support for hp products" window, look in the "self-solve tools"
section and click on the "search technical knowledge base" link.

In the resulting window, scroll the selectable item to "search by doc. ID" and load
UXSGKBRC00005958 into the search string box and "go".

Repeat for UXSGKBRC00005958.

Though stated as risky in the prior response, I don't get calls saying the procedures did not
work. That said, unless you have a burning need to match dev special file paths between servers, ServiceGuard works even if they aren't matched.

-=Stephen

[Michael Roeder]

Hello Stephen,

i tried it again - both documents - but i had no luck.
Either the documents are HP only or for HP partners.
I tried US and Europe sites. Can you find them?

Note: Your search produced no results. It is either too specific or has spelling errors. Try a different search string or change your search criteria selection.

US site:
http://www5.itrc.hp.com/service/cki/search.do?category=c0&mode=id&searchString=UXSGKBRC00005958&searchCrit=allwords&docType=Security&docType=Patch&docType=EngineerNotes&docType=BugReports&docType=Hardware&docType=ReferenceMaterials&docType=ThirdParty&search.x=23&search.y=8

German site:
http://www2.itrc.hp.com/service/cki/search.do?category=c0&mode=text&searchString=UXSGKBRC00005958&searchCrit=allwords&docType=Security&docType=Patch&docType=EngineerNotes&docType=BugReports&docType=Hardware&docType=ReferenceMaterials&docType=ThirdParty&search.x=27&search.y=10

[Michael Roeder]

Tim,

that was perfect. 10 pts.

I guess that i only would have hat to change
8/8 ext_bus 0
in
8/8 ext_bus 3

Do it:
# /sbin/ioinit -f /newcfg -r
Remove old device files
# rmsf /dev/rdsk/c0t*
Create new vith c3:
# insf ???e

Class I H/W Path Driver S/W State H/W Type Description
=====================================================================
disk 4 8/8.1.0 sdisk CLAIMED DEVICE SEAGATE ST32171W
/dev/dsk/c3t1d0 /dev/rdsk/c3t1d0

Perfect.

Change the HW-Path in lvmtab:
# strings /etc/lvmtab
/dev/vg00
w[B-?:
/dev/dsk/c1t6d0
/dev/dsk/c1t5d0
/dev/vghome
/dev/dsk/c0t4d0
/dev/dsk/c0t14d0

Repair my vghome:
bash-2.04# vgexport /dev/vghome
bash-2.04# strings /etc/lvmtab
/dev/vg00
w[B-?:
/dev/dsk/c1t6d0
/dev/dsk/c1t5d0

Create new and import:
/dev/vghome
cr--r--r-- 1 root sys 64 0x040000 Aug 24 20:23 group

# vgimport -s -v -m /etc/cmcluster/maps/vghome.map /dev/vghome
# strings /etc/lvmtab
/dev/vg00
w[B-?:
/dev/dsk/c1t6d0
/dev/dsk/c1t5d0
/dev/vghome
/dev/dsk/c3t4d0
/dev/dsk/c3t14d0

Start cluster:
# cmrunnode
cmrunnode : Waiting for cluster to form......
cmrunnode : Cluster successfully formed.
cmrunnode : Check the syslog files on all nodes in the cluster
cmrunnode : to verify that no warnings occurred during startup.
bash-2.04# cmviewcl

CLUSTER STATUS
clhp up

NODE STATUS STATE
haley up running
helios up running

PACKAGE STATUS STATE PKG_SWITCH NODE
pkgHome up running enabled helios

Yes, it worked! That's exactly what i wanted.

Thank you one more time.

P.S.: Anybody knows how to get the documents UXSGKBRC00005958 and KBRC00004879 (see above - well i switched German site: and US site: )?

[Victor BERRIDGE]

Hi,
As already mentionned, to search such docs, you will have to go, to ?? maintenance and support for hp products
?? technical knowledge base
and search by Keyword from here, I tried one and got the result:
http://www4.itrc.hp.com/service/cki/enterService.do?category=c0

UXSGKBRC00005958:

http://www4.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000068695434


This is the other:
http://www4.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000069332604

Good luck
Victor

[Michael Roeder]

I don't understand the problem with HP's search, neither "search by keyword" nor "search by doc ID" would find anything.

Note: Your search produced no results. ...

The curiosity is, i can retrieve the docs from the links of Victor.

Thanks.

P.S.: I did the update with more SCSI-Controllers, new devices were inserted on host2 exactly as on host1. I worked perfect for me.