By default, the required packages to enable the kdump service are included within the Oracle VM Server installation, but it is good practice to check that these are installed before continuing with any configuration work. You can do this by running the following command:

# rpm -qa | grep kexec-tools

If the kexec-tools package is not installed, you must install it manually.

Oracle VM Server makes use of GRUB2 to handle the boot process. In this step, you must configure GRUB2 to pass the crashkernel parameter to the Xen kernel at boot. This can be done by editing the /etc/default/grub file and modifying the GRUB_CMDLINE_XEN variable by appending the appropriate crashkernel parameter.

The crashkernel parameter specifies the amount of space used in memory to load the crash kernel that is used to generate the dump file, and also specifies the offset which is the beginning of the crash kernel region in memory. The minimum amount of RAM that may be specified for a crash kernel is 512 MB and this should be offset by 64 MB. This would result in a configuration that looks similar to the following:

GRUB_CMDLINE_XEN="dom0_mem=max:6144M allowsuperpage dom0_vcpus_pin \
dom0_max_vcpus=20 crashkernel=512M@64M"

This setting is sufficient for the vast majority of systems, however on systems that make use of a significant number of large drivers, the crash kernel may need to be allocated more space in memory. If you force a dump and it fails to generate a core file, you may need to increase the amount of memory allocated to the crash kernel.

When you have finished modifying /etc/default/grub, you must rebuild the system GRUB2 configuration that is used at boot time. This is done by running:

# grub2-mkconfig -o /boot/grub2/grub.cfg

Kdump is able to store vmcore files in a variety of locations, including network accessible filesystems. By default, vmcore files are stored in /var/crash/, but this may not be appropriate depending on your disk partitioning and available space. The filesystem where the vmcore files are stored must have enough space to match the amount of memory available to Oracle VM Server for each dump.

Since the installation of Oracle VM Server only uses as much disk space as is required, a 'spare' partition is frequently available on a new installation. This partition is left available for use for hosting a local repository or for alternate use such as for hosting vmcore files generated by kdump. If you opt to use it for this purpose, you must first correctly identify and take note of the UUID of the partition and then format it with a usable filesystem.

The following steps serve as an illustration of how you might prepare the local spare partition.

System configuration directing how the kdump service runs is defined in /etc/sysconfig/kdump, while specific kdump configuration variables are defined in /etc/kdump.conf. Changes may need to be made to either of these files depending on your environment. However, the default configuration should be sufficient to run kdump initially without any problems. The following list identifies potential configuration changes that you may wish to make:

You can enable the kdump service to run at every boot by running the following command:

# chkconfig kdump on

You must restart the kdump service at this point to allow it to detect the changes that have been made to the kdump configuration and to determine whether a kdump crash kernel has been generated and is up to date. If the kernel image needs to be updated, kdump does this automatically, otherwise it restarts without any attempt to rebuild the crash kernel image:

# service kdump restart 
Stopping kdump:                   [  OK  ]
 Detected change(s) the following file(s): 
    /etc/kdump.conf 
Rebuilding /boot/initrd-4.1.12-25.el6uek.x86_64kdump.img 

Starting kdump:                   [  OK  ]

You can confirm that the kernel loaded for dom0 is correctly configured, by running the following command and checking that output is returned to show that your crashkernel parameter is in use:

# xl dmesg|grep -i crashkernel
(XEN) Command line: placeholder dom0_mem=max:6144M allowsuperpage dom0_vcpus_pin
        dom0_max_vcpus=20 crashkernel=512M@64M

You can also check that the appropriate amount of memory is reserved for kdump by running the following:

# xl dmesg|grep -i kdump 
(XEN) Kdump: 512MB (524288kB) at 0x4000000

or alternately:

# kexec --print-ckr-size 
536870912

You can check that the kdump service is running by checking the service status:

# service kdump status
Kdump is operational 

If there are no errors in /var/log/messages or on the console, you can assume that kdump is running correctly.

To test that kdump is able to generate a vmcore and store it correctly, you can trigger a kernel panic by issuing the following commands:

# echo 1 > /proc/sys/kernel/sysrq
# echo c > /proc/sysrq-trigger

After you have triggered a kernel panic and the system has successfully rebooted, you may check that the vmcore file was properly generated:

If you find that a vmcore file is not being created or that the system hangs without automatically rebooting, you may need to adjust your configuration. The most common problem is that there is insufficient memory allocated for the crash kernel to run and complete its operations. Your starting point to resolving issues with kdump is always to try increasing the reserved memory that is specified in your GRUB2 configuration.