Bug 823646

Summary:	Revert delay on kdump bridge
Product:	Red Hat Enterprise Linux 6	Reporter:	Mike Burns <mburns>
Component:	ovirt-node	Assignee:	Joey Boggs <jboggs>
Status:	CLOSED ERRATA	QA Contact:	Virtualization Bugs <virt-bugs>
Severity:	high	Docs Contact:
Priority:	unspecified
Version:	6.4	CC:	acathrow, bsarathy, chetan, gouyang, jboggs, leiwang, mburns, ovirt-maint, shcao, ycui, yuachen
Target Milestone:	beta
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	ovirt-node-2.5.0-3.el6	Doc Type:	Bug Fix
Doc Text:	After kdump was configured with a remote NFS server, the dump file was not created in the NFS directory, so kdump did not work. The link_delay option, which was introduced to fix a prior issue, has now been removed, so kdump on a biosdevname interface with a bridge works as expected.	Story Points:	---
Clone Of:	812865	Environment:
Last Closed:	2013-02-28 16:31:03 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	812865, 817157
Bug Blocks:

Description Mike Burns 2012-05-21 19:14:57 UTC

+++ This bug was initially created as a clone of Bug #812865 +++

Original fix for the below problem was to add Delay=60 to the kdump bridge.  This can be reverted when bug 817157 is fixed.



Description of problem:
 Kdump doesn't work after configure the remote nfs server


 Version-Release number of selected component (if applicable):
 rhev-hypervisor6-6.3-20120411.1

 How reproducible:
 100%

 Steps to Reproduce:
 1. Install rhevh on local host
 2. Configure network
 3. Scroll down to Kernel Dump, choose setup nfs configuration
 4. Enter the nfs server address, and confirm the input address;[attachment RemoteNFS.png]
 5. Change to shell mode, and input "echo c > /proc/sysrq-trigger", to make the system coredump;
 6. After the system reboot, check the dump file on the remote nfs input before.

 Actual results:
 There is folder nfs:/path/var/crash in the nfs directory.
 But there is no dump file named with the dump time.
 [attachment NoDumpFile.png]

 Expected results:
 There is dump file named with the dump time in the nfs:/path/var/crash.

 Additional info:
 This a regression test.

Comment 1 Mike Burns 2012-05-21 19:18:55 UTC

    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
Without the fix to bug 817157, kdump on a biosdevname interface with a bridge will not function correctly.

Comment 2 RHEL Program Management 2012-07-10 08:22:56 UTC

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

Comment 3 RHEL Program Management 2012-07-11 01:48:46 UTC

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Comment 4 Mike Burns 2012-07-13 20:17:47 UTC

delay on bridge is not needed,  bug 817157 was fixed in 6.3 GA.

Comment 7 Ying Cui 2012-11-05 08:03:21 UTC

Verified this bug on build rhev-hypervisor6-6.4-20121031.0.el6, kdump on a biosdevname interface with a bridge works good after configure the remote nfs server.

Test steps:
 1. Install rhevh on local host
 2. Configure network(biosdevname interface with a bridge)
 3. Scroll down to Kernel Dump, choose setup nfs configuration
 4. Enter the nfs server address, and confirm the input address;
 5. Change to shell mode, and input "echo c > /proc/sysrq-trigger", to make the system coredump;
 6. After the system reboot, check the dump file on the remote nfs input before.

Test results:
There is dump file named with the dump time in the nfs:/path/var/crash.

So the bug is fixed, change bug status to VERIFIED.

Comment 10 errata-xmlrpc 2013-02-28 16:31:03 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0556.html