Error Message

On console you will see the system load the kdump ramdisk and fail when trying to find the VxDMP Device.
“No volume groups found”
As the only device to scan is “/dev/vx/dmp”, but VxDMP is not available in the initramfs (ramdisk) used by kdump;
therefore not available during kdump boot.

As part of VxDMP Native support we update the lvm.conf global filters to reject all devices and accept only the VxDMP devices. The kdump ramdisk (initramfs) when configured is done so with the new lvm.conf modified by our VERITAS Volume Manager (VxVM) scripts. 

When a system panic occurs and is switched to the kdump initramfs (ramdisk) it fails. The reason is kdump does include the vxdmp module during ramdisk load; therefore the VxDMP device is not available early during kdump boot up.

Workaround 1: The case where kdump is configured on / root file system under VxDMP native support.
 
1. Backup the VxVM version of lvm.conf:
 
# cp /etc/lvm/lvm.conf /etc/lvm/lvm.conf.vxvm
cp: overwrite `/etc/lvm/lvm.conf.vxvm'? y
 
2. Copy the original lvm.conf back (lvm.conf prior to enabling VxDMP Native):
 
# cp /etc/lvm/lvm.conf.orig /etc/lvm/lvm.conf
cp: overwrite `/etc/lvm/lvm.conf'? y
 
3. Remove kdump initrd:
 
# rm -rf /boot/initrd-2.6.32-504.el6.x86_64kdump.img
 
4. Restart kdump this will also rebuild the initramfs:
 
# service kdump restart
Stopping kdump:                                            [  OK  ]
No kdump initial ramdisk found.                            [WARNING]
Rebuilding /boot/initrd-2.6.32-504.el6.x86_64kdump.img
Starting kdump:                                            [  OK  ]
 
5. Copy the backed up VxVM version of lvm.conf back. This will ensure that after panic and reboot the system comes back up with VxDMP Native device:
 
# cp /etc/lvm/lvm.conf.vxvm /etc/lvm/lvm.conf
cp: overwrite `/etc/lvm/lvm.conf'? y
 

Warning:  The next command will panic the system. Only to be done as part of testing!

# echo c > /proc/sysrq-trigger
 
Drawback of the workaround:
 
The drawback here is that customer will have to run this every time they have to generate kdump
since the kdump initrd will be recreated once the kdump service is restarted.
So the customer will have to perform these steps each and every time after reboot.

Note: You can configure steps 1-5 in /etc/init.d/rc.local so that is done after every reboot.
 
Workaround 2: Configure the kdump device on a separate disk not managed by VxDMP.
 
Add the filter for the dump device in accept section in lvm.conf file.

Again we need to make sure that the DUMP device is *not configured* on root device i.e “/”.

Once the device is accepted in lvm.conf, it will not come under VxDMP and will continue to be monitored by Linux Native Multipathing.
 
Permanent fix:
 
Veritas is planning an enhancement in release for 7.1 

Additional Notes:
 

VERITAS DMP (VxDMP) Native support was not designed with kdump functionality in mind.

Currently if you enable VxDMP Native support on a boot disk and later on if the system panics,
kdump will not function and no vmcore will be dumped to the dump device.
 

ETrack: 3754715