vg not activated after reboot

[himacs]

Hi Admins,

VG03 not activated after reboot.I manually activated the same and mounted all LVs.

I found below info from rc.log
mountall: cannot mount /dev/vg03/lvol2
mountall: diagnostics from mount
vxfs mount: Cannot open /dev/vg03/lvol2: No such device or address
mountall: cannot mount /dev/vg03/lvol1
mountall: diagnostics from mount
vxfs mount: Cannot open /dev/vg03/lvol1: No such device or address

Please tell me where should i check to know the root cause.

Regards
himacs

[himacs]

Hi

I found below info from syslog

vmunix: 0/6/1/0/4/0: Fabric Name Server rejected GPN_FT query.
Feb 12 22:19:04 uaedxbpdcdmsp02 vmunix: Reason code: unable to perform request;
Feb 12 22:19:04 uaedxbpdcdmsp02 vmunix: Explanation: FC-4 Type not registered.
Feb 12 22:19:04 uaedxbpdcdmsp02 vmunix: This may indicate that the HBA port is not part of a zone.
Feb 12 22:19:04 uaedxbpdcdmsp02 vmunix: Please check zone configuration on your switch.
Feb 12 22:19:04 uaedxbpdcdmsp02 vmunix:
Feb 12 22:19:06 uaedxbpdcdmsp02 syslog: rm_log_init: fopen of file /etc/opt/resmon/log/client.log failed: Permission denied

Regards
himacs

[Jorge Pons]

Hi

Can you post:
/etc/fstab
ioscan -funC disk

Regards, Jorge

[Manix]

Check /etc/lvmrc file & see any if any exclusions out there & AUTO_VG_ACTIVATE=1

post the output for the commands below.
vgdisplay -v /dev/vg03
/etc/fstab

Thanks
Manix

[Emil Velez]

in most cases /etc/lvmrc should activate all of the volume groups listed in /etc/lvmtab and /etc/lvmtab_p

You can edit the file and do a custom vg activation to only activate vg00. Check if somebody did that. It is a common practice in a serviceguard cluster environment to activate only vg00 at boot time since the packages activate the other volume groups.

I sometimes forget to configure this and it is not critical since the other volume groups that belong to packages have the cluster flag and fail to be activated by /etc/lvmrc but generate a error early in the boot process (before the rc scripts)

Good luck

[Wouter Jagers]

hi,

The messages in your second post point out issues with the SAN connection. If this VG is on external disks, you will need to look there.

# vgdisplay -v vg03 | grep -i 'pv name'
# ioscan -fnCdisk

In that case, if vg03's disks are SAN disks, they'll probably be NO_HW in the ioscan output.

cheers
Wout

[himacs]

Hi

This is a active cluster node and vg03 not part of cluster.

when checked in lvmrc, AUTO_VG_ACTIVATE=1..but vg03 manually activated

fstab holds the entry for vg03 lvs

vgdisplay -v /dev/vg03
--- Volume groups ---
VG Name /dev/vg03
VG Write Access read/write
VG Status available
Max LV 255
Cur LV 2
Open LV 2
Max PV 255
Cur PV 1
Act PV 1
Max PE per PV 1016
VGDA 2
PE Size (Mbytes) 32
Total PE 539
Alloc PE 188
Free PE 351
Total PVG 0
Total Spare PVs 0
Total Spare PVs in use 0

--- Logical volumes ---
LV Name /dev/vg03/lvol1
LV Status available/syncd
LV Size (Mbytes) 3008
Current LE 94
Allocated PE 94
Used PV 1

LV Name /dev/vg03/lvol2
LV Status available/syncd
LV Size (Mbytes) 3008
Current LE 94
Allocated PE 94
Used PV 1


--- Physical volumes ---
PV Name /dev/dsk/c6t7d6
PV Name /dev/dsk/c4t7d6 Alternate Link
PV Status available
Total PE 539
Free PE 351
Autoswitch On
Proactive Polling On



cat /etc/fstab
# System /etc/fstab file. Static information about the file systems
# See fstab(4) and sam(1M) for further details on configuring devices.
/dev/vg00/lvol3 / vxfs delaylog 0 1
/dev/vg00/lvol1 /stand vxfs tranflush 0 1
/dev/vg00/lvol4 /tmp vxfs delaylog 0 2
/dev/vg00/lvol5 /home vxfs delaylog 0 2
/dev/vg00/lvol6 /opt vxfs delaylog 0 2
/dev/vg00/lvol7 /usr vxfs delaylog 0 2
/dev/vg00/lvol8 /var vxfs delaylog 0 2
/dev/vg00/lvol9 /oracle vxfs delaylog 0 2
/dev/vg03/lvol1 /opt/omni vxfs delaylog 0 2
/dev/vg03/lvol2 /var/opt/omni vxfs delaylog 0 2


Regards
himacs

[himacs]

Hi Wouter,

vg03 disks are SAN disks and shows CLAIMED in ioscan output.

Another server rebooted with same issue.This is not cluster node.lvmrc shows AUTO_VG_ACTIVATION=1.But VG vgoradata not activated automatically.fstab holds VG info and ioscan shows all disks claimed.

Regards
himacs

[himacs]

Hi All,

As per my knowledge /sbin/bcheckrc script going through each filesystem and running fsck and making sure that it is clean and then activating the volume group.

So how can i check whether /sbin/bcheckrc found any issue with vg03/vgoradata .

please suggest.

Regards
himacs

[Ismail Azad]

Hi,

I am not sure what you are exactly trying to do right now himacs but yes /sbin/bcheckrc does check the fstab file at boot time.

The O.S activates every VG configured at boot time when the control variable AUTO_VG_ACTIVATE is set as 1 and it's typically always 1 in a non - clustered environment when you do not want serviceguard to do anything regarding "activation" of that volume group.

This is only regarding your last statement... Why don't you just try....
/sbin/bcheckrc stop
/sbin/bcheckrc start
:)

Regards
Ismail Azad

[Rita C Workman]

Here's something to try:

Move /var and /opt higher in the order in your /etc/fstab file.

Change the pass number of /opt/omni and /var/opt/omni to 3.

Regards,
Rita

[Jose Mosquera]

Hi,

What about your HBAs status?
#ioscan -fnCfc
Devices (generally /dev/td[0-1]) must be CLAIMED.

Then check the driver state (must be Driver state = ONLINE)for devices above displayed:
# fcmsutil /dev/td0
# fcmsutil /dev/td1

Rgds.

[himacs]

Hi Rita,

Thanks for the suggestion.Please tell me whats the advantages by increasing the pass number of /opt/omni.

Jose,All the devices are in claimed state and as earlier said i have manually activated the VG and its serving fine now.

Regards
himacs