Kdump does not function when VERITAS DMP native is enabled.

book

Article ID: 100015653

calendar_today

Updated On:

Description

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 early during boot.
Cause
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.

Resolution

Workaround 1: The case where kdump is configured on / root file system under VxDMP native support.
 
1. Copy vxvm lvm.conf:
 
# cp /etc/lvm/lvm.conf /etc/lvm/lvm.conf.vxvm
cp: overwrite `/etc/lvm/lvm.conf.vxvm'? y
 
2. Copy 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 VxVM 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
 

Note:  The next command will panic the system. Only to be done as part of testing!
 
# echo c > /proc/sysrq-trigger
 
Drawback:
 
The drawback here is that customer will have to run this everytime 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 seperate disk not to be 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 “/”.

If we accept the device, 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:

Issue/Introduction

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 encounter or manually panic the system. Kdump will not function. No vmcore will be retrieved.