Bug 1215554

Summary: [7.1_3.5.1] No VM's core dumps after kill vm in rhevh7.1
Product: Red Hat Enterprise Virtualization Manager Reporter: wanghui <huiwa>
Component: ovirt-nodeAssignee: Douglas Schilling Landgraf <dougsland>
Status: CLOSED ERRATA QA Contact: wanghui <huiwa>
Severity: high Docs Contact:
Priority: medium    
Version: 3.5.1CC: cshao, danken, fdeutsch, gklein, huiwa, leiwang, lsurette, yaniwang, ycui, ykaul
Target Milestone: ovirt-3.6.0-rcKeywords: ZStream
Target Release: 3.6.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ovirt-node-3.3.0-0.4.20150906git14a6024.el7ev Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1235346 (view as bug list) Environment:
Last Closed: 2016-03-09 14:27:47 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Node RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1220993    
Bug Blocks: 1235346    
Attachments:
Description Flags
all files in /var/log/ none

Description wanghui 2015-04-27 06:17:22 UTC 
Description of problem:
No VM's core dumps after kill vm in rhevh7.1.

Version-Release number of selected component (if applicable):
Red Hat Enterprise Virtualization Hypervisor 7.1 (20150420.0.el7ev)
ovirt-node-3.2.2-3.el7.noarch
vdsm-4.16.13.1-1.el7ev.x86_64
ovirt-node-selinux-3.2.2-3.el7.noarch
selinux-policy-3.13.1-23.el7.noarch
selinux-policy-targeted-3.13.1-23.el7.noarch

Red Hat Enterprise Virtualization Manager Version: 3.5.1-0.4.el6ev

How reproducible:
100%

Steps to Reproduce:
1. Install RHEVH-7.1-20150420.0
2. Register to RHEVM3.5.1.
3. Create VM.
4. Run command "pkill -ABRT -f 'qemu-kvm'" on host.
5. Run  ll /var/log/core/ on host.

Actual results:
1. After step5, there is no VM's core dumps in RHEV-H 7.1.

Expected results:
2. After step5, VMs core dumps are available.

Additional info:
Comment 1 Fabian Deutsch 2015-04-27 09:42:58 UTC 
Please provide the sosreport or /var/log/audit/audit.log or /var/log completely
Comment 2 wanghui 2015-04-27 10:08:16 UTC 
Created attachment 1019288 [details]
all files in /var/log/
Comment 3 Douglas Schilling Landgraf 2015-05-12 02:12:51 UTC 
Hi wanghui,

Unfortunately, I cannot reproduce your report using my own deploy environment with RHEV-H 7.1 (20150420.0.el7ev or 20150505.0.el7ev) because I got affected by BZ#1205877. Analyzing your logs I couldn't find selinux/blocker for the core not been generated. 

So, here few questions:

#1 - Could you please share the below with the vm tes1 running:
     - cat /proc/sys/kernel/core_pattern
     - Attach ps auxww 
     - Attach vdsm.conf
   
#2 - What happens if you run 'pkill -ABRT -f supervdsmServer'? Is the core generated?

#3 - Do you mind to test your report using rhev-hypervisor7-7.1-20150505.0.el7ev?

#4 - Can I have access to the machine?


For reference only:
supervdsm: enable coredumping
https://gerrit.ovirt.org/#/c/35745/
Comment 4 Douglas Schilling Landgraf 2015-05-12 21:10:21 UTC 
(In reply to Douglas Schilling Landgraf from comment #3)
> Hi wanghui,
> 
> Unfortunately, I cannot reproduce your report using my own deploy
> environment with RHEV-H 7.1 (20150420.0.el7ev or 20150505.0.el7ev) because I
> got affected by BZ#1205877. Analyzing your logs I couldn't find
> selinux/blocker for the core not been generated. 
> 
> So, here few questions:
> 
> #1 - Could you please share the below with the vm tes1 running:
>      - cat /proc/sys/kernel/core_pattern
>      - Attach ps auxww 
>      - Attach vdsm.conf
>    
> #2 - What happens if you run 'pkill -ABRT -f supervdsmServer'? Is the core
> generated?
> 
> #3 - Do you mind to test your report using
> rhev-hypervisor7-7.1-20150505.0.el7ev?
> 
> #4 - Can I have access to the machine?
> 
> 
> For reference only:
> supervdsm: enable coredumping
> https://gerrit.ovirt.org/#/c/35745/

I was able to reproduce using NFS as storage. Investigating.
Comment 5 wanghui 2015-05-13 02:24:05 UTC 
(In reply to Douglas Schilling Landgraf from comment #4)
> (In reply to Douglas Schilling Landgraf from comment #3)
> > Hi wanghui,
> > 
> > Unfortunately, I cannot reproduce your report using my own deploy
> > environment with RHEV-H 7.1 (20150420.0.el7ev or 20150505.0.el7ev) because I
> > got affected by BZ#1205877. Analyzing your logs I couldn't find
> > selinux/blocker for the core not been generated. 
> > 
> > So, here few questions:
> > 
> > #1 - Could you please share the below with the vm tes1 running:
> >      - cat /proc/sys/kernel/core_pattern
> >      - Attach ps auxww 
> >      - Attach vdsm.conf
> >    
> > #2 - What happens if you run 'pkill -ABRT -f supervdsmServer'? Is the core
> > generated?
> > 
> > #3 - Do you mind to test your report using
> > rhev-hypervisor7-7.1-20150505.0.el7ev?
> > 
> > #4 - Can I have access to the machine?
> > 
> > 
> > For reference only:
> > supervdsm: enable coredumping
> > https://gerrit.ovirt.org/#/c/35745/
> 
> I was able to reproduce using NFS as storage. Investigating.

Yes. I just used NFS as storage too.
Comment 6 Douglas Schilling Landgraf 2015-05-13 04:26:10 UTC 
This report became two. I have created a bugzilla in VDSM to handle the systemd libvirtd.service setting to enable generate coredump that I found, see BZ#1220993. When this setting is enabled and user try to generate the coredump selinux will raise AVC which is fixed by this bug.
Comment 9 wanghui 2015-11-27 04:05:53 UTC 
Test version:
rhev-hypervisor7-7.2-20151112.1.el7ev
ovirt-node-3.6.0-0.20.20151103git3d3779a.el7ev.noarch

Test steps:
1. Install rhev-hypervisor7-7.2-20151112.1.el7ev
2. Register to RHEVM 3.6.0.3-0.1.el6
3. Create VM
4. Run command "pkill -ABRT -f 'qemu-kvm'" on host
5. Run  ll /var/log/core/ on host

Test result:
1. After step5, it has the core dump file now.
# ll /var/log/core/
total 1065788
-rw-------. 1 qemu qemu 1949868032 Nov 27 03:22 core.31154.1448594563.dump

So this issue is fixed in ovirt-node-3.6.0-0.20.20151103git3d3779a.el7ev.noarch. Change the status to verified now.
Comment 11 errata-xmlrpc 2016-03-09 14:27:47 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.

https://rhn.redhat.com/errata/RHBA-2016-0378.html