Serviceguard

[khilari]

Hi people, i want to ask about serviceguard. So here is the situation. I got a shared disk, put lvm on it. VGexport the /tmp/map file and also ftp it on the other server. Made the volume group in the other serve. Now when i run vgimport on the other server it says it couldnt access the physical volumes for that volume group vg01.
Any ideas????

[melvyn burnard]

Well this is more of an LVM question, but here goes.
Did you use the -s option for the vgexport?
If yes, then I suuggest that maybe the physical discs are NOT visible on the second node.
Post the commands you used and verify that you have the discs visible AND they have device files.

[Jeff_Traigle]

How did you do the vgexport? Did you use the -s option? If not, I think vgexport simply lists the device files for each LV in the VG. If those device files aren't identical on the other server, you would get that kind of error.

[A. Clay Stephenson]

First of all, don't expect the pathnames to the PV's to be the same on different nodes; only rarely will the two be the same. Also, you must run an ioscan -f after connecting new devices and then execute an insf to create the new device nodes. This must be done on each node. The easist way to do this is by using the '-s' option of vgexport and vgimport. This will add the VGID to the mapfile and rather than specifying PV paths, the system will now scan the disks looking for matching VGID's. You still must do the ioscan/insf so that the new host can "see" the new devices.

[Doug O'Leary]

Hey;

There's a couple of potential pitfalls. The first, and most obvious, is that the second system doesn't see the disks associated w/vg01.

Another potential problem is how you exported &/| imported the vg:

Sys1#: vgexport -s -m vg01.map vg01
Sys1#: scp vg01.map Sys2:/tmp

Sys2#: mkdir /dev/vg01
Sys2#: minor=$(ssh Sys1 ls -ld /dev/vg01/group | awk '{print $6}')
Sys2#: mknod /dev/vg01group c 64 ${minor}
Sys2#: vgimport -s -m /tmp/vg01.map vg01

HTH;

Doug

[Steven E. Protter]

Shalom khilari,

First, on the second node:

ioscan -fnC disk

See if the disks in question are visible. There could be a problem with cabling or the disk array if not.

If the disks are visible, make sure the volume group is deactivated on the first node.

vgchange -a n /dev/vg01

Post back any errors after trying this procedure.

SEP

[khilari]

Well, the ioscan -fnkC disk on both servers gives the same c3t6d0.
On the first server (newPC):
1)i put the disk under lvm.
2) then i vgexport with the -s option
3) ftp /tmp/map onto the other server (newFIN).

On (newFIN)
1) I made the group file for the volume group, no problem there.
2)Now when i run the vgimport command with -s it doesnt work, it says it couldnt access the physical volumes.

and on newPC when i run vgchange -a n vg01 it says DEVICE BUSY.

[Doug O'Leary · Accepted solution]

Hey;

If you exported/imported the vg as you described, then we can only conclude that /dev/dsk/c3t6d0 on each server are not pointing to the same physical disk. The -s option exports the vg with the VGID embedded in the map file. The vgimport command scans all disks available to the system looking for that VGID. If it can't find it, it's becasue it's not assigned.

Just to make sure we're clear on the concept, MCSG clusters use shared disks - in other words disks that are available to both systems simultaneously.

Assuming you're clear on that concept, you will have to investigate/update the disk layout on each system to get them pointing to the same physical set of disks.

HTH;

Doug O'Leary

[khilari]

Kindly see the attachment, i think that the two servers dont have a shared volume, the disk names are the same but if u see the hardware path u will see a difference. I just want to double check that the two servers dont have a shared volume.

I am attaching the disk configuration.

[khilari]

Server1:
# ioscan -fnkC disk
Class I H/W Path Driver S/W State H/W Type Description
==========================================================================
disk 0 1/0/0/3/0.6.0 sdisk CLAIMED DEVICE HP 36.4GMAU3036NC
/dev/dsk/c0t6d0 /dev/rdsk/c0t6d0
disk 1 1/0/0/3/1.2.0 sdisk CLAIMED DEVICE _NEC DVD_RW ND-
3540A
/dev/dsk/c1t2d0 /dev/rdsk/c1t2d0
disk 2 1/0/1/1/0/1/1.6.0 sdisk CLAIMED DEVICE HP 36.4G
MAU3036NC
/dev/dsk/c3t6d0 /dev/rdsk/c3t6d0
disk 3 1/0/6/1/0.8.0.110.0.0.0 sdisk CLAIMED DEVICE HP
A6189B
/dev/dsk/c6t0d0 /dev/rdsk/c6t0d0
disk 4 1/0/6/1/0.8.0.110.0.0.1 sdisk CLAIMED DEVICE HP
A6189B
/dev/dsk/c6t0d1 /dev/rdsk/c6t0d1

Server 2:

# ioscan -fnkC disk
Class I H/W Path Driver S/W State H/W Type Description
==========================================================================
disk 0 1/0/0/3/0.6.0 sdisk CLAIMED DEVICE HP 36.4GMAU3036NC
/dev/dsk/c0t6d0 /dev/rdsk/c0t6d0
disk 1 1/0/0/3/1.2.0 sdisk CLAIMED DEVICE _NEC DVD_RW ND-
3540A
/dev/dsk/c1t2d0 /dev/rdsk/c1t2d0
disk 2 1/0/1/1/0/1/1.6.0 sdisk CLAIMED DEVICE HP 36.4G
MAU3036NC
/dev/dsk/c3t6d0 /dev/rdsk/c3t6d0
disk 3 1/0/6/1/0.8.0.108.0.0.0 sdisk CLAIMED DEVICE HP
A6189B
/dev/dsk/c6t0d0 /dev/rdsk/c6t0d0
disk 4 1/0/6/1/0.8.0.108.0.0.1 sdisk CLAIMED DEVICE HP
A6189B
/dev/dsk/c6t0d1 /dev/rdsk/c6t0d1

[melvyn burnard]

well the discs on the c6 interface may be shared, but it certainly looks like the disc on c3 is NOT.
Verify your hardware connectivity

[rariasn]

Verify hardware conectionsfor disc3 and disc4

Server1:

disk 3 1/0/6/1/0.8.0.108.0.0.0 sdisk CLAIMED DEVICE HP
A6189B
/dev/dsk/c6t0d0 /dev/rdsk/c6t0d0
disk 4 1/0/6/1/0.8.0.108.0.0.1 sdisk CLAIMED DEVICE HP
A6189B
/dev/dsk/c6t0d1 /dev/rdsk/c6t0d1

Server2:

disk 3 1/0/6/1/0.8.0.110.0.0.0 sdisk CLAIMED DEVICE HP
A6189B
/dev/dsk/c6t0d0 /dev/rdsk/c6t0d0
disk 4 1/0/6/1/0.8.0.110.0.0.1 sdisk CLAIMED DEVICE HP
A6189B
/dev/dsk/c6t0d1 /dev/rdsk/c6t0d1

On Server2:

ioscan -fnC|grep "0.8.0.108.0.0.0"
ioscan -fnC|grep "0.8.0.108.0.0.0"

ran