Do vxinitrd after kernel upgrade

Just a quick reminder. If you have your root disk on a Linux box encapsulated then don’t forget to recreate initrd image after the kernel has been updated.

/usr/lib/vxvm/bin/vxinitrd /boot/VxVM_initrd.img 'uname -r'

Otherwise you’ll end up being welcomed by the following message once you reboot.

Kernel panic - not syncing: Attempted to kill init!

Have a nice day!

vxdmpadm path activate weirdness

Just stumbled upon a strange behavior of vxdmpadm which requires further investigation.
The problem I’ve faced with during an attempt to set certain path “active” to loadbalance the data flow on HDS between its controllers. The built-in help clearly states that:

# vxdmpadm setattr help

vxdmpadm setattr path
 pathtype=

pathtype can be either:
        active
        nomanual
        nopreferred
        preferred [priority=]
        primary
        secondary
        standby

So I dully expected it to work as declared but instead I got the following error:

# vxdmpadm getsubpaths  ctlr=c2
NAME         STATE[A]   PATH-TYPE[M] DMPNODENAME  ENCLR-TYPE   ENCLR-NAME   ATTRS
================================================================================
c2t50060E800042A5F0d81s2 ENABLED(A) PRIMARY      hds9500-alua0_0051 HDS9500-ALUA hds9500-alua0   -
c2t50060E800042A5F3d81s2 ENABLED    SECONDARY    hds9500-alua0_0051 HDS9500-ALUA hds9500-alua0   -
c2t50060E800042A5F0d82s2 ENABLED(A) SECONDARY    hds9500-alua0_0052 HDS9500-ALUA hds9500-alua0   -
c2t50060E800042A5F3d82s2 ENABLED    PRIMARY      hds9500-alua0_0052 HDS9500-ALUA hds9500-alua0   -

# vxdmpadm getsubpaths  ctlr=c3
NAME         STATE[A]   PATH-TYPE[M] DMPNODENAME  ENCLR-TYPE   ENCLR-NAME   ATTRS
================================================================================
c3t50060E800042A5F1d81s2 ENABLED(A) PRIMARY      hds9500-alua0_0051 HDS9500-ALUA hds9500-alua0   -
c3t50060E800042A5F2d81s2 ENABLED    SECONDARY    hds9500-alua0_0051 HDS9500-ALUA hds9500-alua0   -
c3t50060E800042A5F1d82s2 ENABLED(A) SECONDARY    hds9500-alua0_0052 HDS9500-ALUA hds9500-alua0   -
c3t50060E800042A5F2d82s2 ENABLED    PRIMARY      hds9500-alua0_0052 HDS9500-ALUA hds9500-alua0   -

# vxdmpadm setattr path c2t50060E800042A5F3d82s2 pathtype=active
VxVM vxdmpadm ERROR V-5-1-10357  Invalid argument or attribute specified.

Looks like I’ll need to investigate deeper to find the culprit but as a workaround just disabled the second path to force a failover to another one I tried to make active.

Update.
As always RTFM rules and I must admin that my apprehension, that with option one could change the state listed in the second column to active, was completely wrong. In the man page it’s lucidly written that pathtype=active is used to change a standby path to active.

# vxdmpadm setattr path c2t50060E800042A5F3d81s2 pathtype=standby
# vxdmpadm getsubpaths 

NAME         STATE[A]   PATH-TYPE[M] DMPNODENAME  ENCLR-NAME   CTLR   ATTRS
================================================================================
c2t50060E800042A5F3d81s2 ENABLED    SECONDARY    hds9500-alua0_0051 hds9500-alua0 c2     STANDBY

# vxdmpadm setattr path c2t50060E800042A5F3d81s2 pathtype=active
# vxdmpadm getsubpaths 

NAME         STATE[A]   PATH-TYPE[M] DMPNODENAME  ENCLR-NAME   CTLR   ATTRS
================================================================================
c2t50060E800042A5F3d81s2 ENABLED    SECONDARY    hds9500-alua0_0051 hds9500-alua0 c2       -

Since in my case the path was already active it would be strange to make it active for the second time and as a result I got the error. So actually there were two options:

  • Use vxdmpadm disable
  • Use vxdmpadm setattr path pathtype=standby/active

So, folks, never underestimate the documentation. ;-)

Missing voolboot file

If executing ” vxdctl enable” you receive the following error:

VxVM vxdctl ERROR V-5-1-1589 enable failed: Volboot file not loaded

then this sequence could help you to resolve the problem:

vxio set 10
vxconfigd -d
vxdctl init
vxdctl enable

Good luck.