Bug 1182388

Summary: adding the panic device should be permitted but have no effect for POWER
Product: Red Hat Enterprise Linux 7 Reporter: Luyao Huang <lhuang>
Component: libvirtAssignee: Andrea Bolognani <abologna>
Status: CLOSED ERRATA QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1CC: dgibson, dyuan, dzheng, gsun, michen, mzhan, ngu, rbalakri, weizhan, xuhan, ypu
Target Milestone: rcKeywords: Upstream
Target Release: ---   
Hardware: ppc64   
OS: Linux   
Whiteboard:
Fixed In Version: libvirt-1.2.17-1.el7 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-11-19 06:08:05 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:

Description Luyao Huang 2015-01-15 01:53:38 UTC
Description of problem:
adding the panic device should be permitted but have no effect for POWER

Version-Release number of selected component (if applicable):
libvirt-1.2.8-10.el7.ppc64

How reproducible:
100%

Steps to Reproduce:
1.# virsh dumpxml virt-tests-lhuang
...
<panic>
</panic>
...

2.# virsh start virt-tests-lhuang
error: Failed to start domain virt-tests-lhuang
error: unsupported configuration: your QEMU is too old to support pvpanic

3.

Actual results:
guest cannot start with panic device

Expected results:
adding the panic device should be permitted but have no effect for POWER

BTW libvirt output 'qemu too old' seems not correct in this place

Additional info:

thanks David Gibson's advise and information:
the POWER guest firmware interfaces essentially have the functionality of the pvpanic device built in.

So, I think we should file a libvirt bug - adding the panic device
should be permitted but have no effect for POWER.

Comment 1 Andrea Bolognani 2015-06-01 12:14:26 UTC
The issue has been resolved by the following commit:

commit 7bd769e0ab86d7345c6331f3a4ca9b0317efae2b
Author: Andrea Bolognani <abologna>
Date:   Thu May 28 16:39:12 2015 +0200

    qemu: Allow panic device for pSeries guests
    
    The guest firmware provides the same functionality as the pvpanic
    device, which is not available in QEMU on pSeries, so the domain
    XML should be allowed to contain the <panic> element.
    
    On the other hand, unlike the pvpanic device, the guest firmware
    can't be configured, so report an error if an address has been
    provided in the XML.
    
    Resolves: https://bugzilla.redhat.com/show_bug.cgi?id=1182388

v1.2.16-4-g7bd769e

Comment 3 Dan Zheng 2015-07-03 07:55:43 UTC
This bug can be reproduced  with following package version
  libvirt-1.2.16-1.el7.ppc64le
  qemu-kvm-rhev-2.3.0-5.el7.ppc64le
  kernel-3.10.0-282.el7.ppc64le

Retest it with the following package version, this bug is fixed.
  libvirt-1.2.17-1.el7.ppc64le
  qemu-kvm-rhev-2.3.0-5.el7.ppc64le
  kernel-3.10.0-282.el7.ppc64le

Scenarios:
1. Edit with <panic> in XML and guest can be started.
...
<panic/>
...
# virsh start dzhengvm1
Domain dzhengvm1 started

2. Edit with <panic></panic> and guest can be started.
...
<panic></panic>
...
# virsh start dzhengvm1
Domain dzhengvm1 started

3. Add <address> element between <panic> and guest fails to start.
    <panic>
      <address type='isa' iobase='0x505'/>
    </panic>
# virsh start dzhengvm1
error: Failed to start domain dzhengvm1
error: unsupported configuration: setting the panic device address is not supported for pSeries guests

Comment 4 Dan Zheng 2015-07-07 06:34:20 UTC
4. Set auto_dump_path in qemu.conf and the dump file can be created in the specified directory.
4.1 Edit qemu.conf and set auto_dump_path= "/var/lib/libvirt/qemu/dump2"
4.2 Edit XML with <on_crash>coredump-restart</on_crash>
4.3 Restart libvirtd and start guest. Within the guest, stop kdump service and make it crash.
    # systemctl stop kdump
    # echo c>/proc/sysrq-trigger
4.4 Check the dump file is created in  "/var/lib/libvirt/qemu/dump2", and crash tool can analyse it correctly.
4.5 The guest state is changed from running (booted)=> crashed (panicked) => running (crashed)
4.6 Edit XML with <on_crash>coredump-destroy</on_crash> and retry step 4.3 and 4.4, and guest state is changed from running (booted) to crashed (panicked) to shut off (crashed).

5. Set bypass_cache for the auto dump in qemu.conf
5.1 Edit qemu.conf and set auto_dump_bypass_cache=0 , keep  auto_dump_bypass_cache as default (disabled) and auto_dump_bypass_cache=1 respectively.
5.2 Edit XML with <on_crash>coredump-restart</on_crash> and <on_crash>coredump-destroy</on_crash> respectively.
5.3 Restart libvirtd and start guest. Within the guest, stop kdump service and make it crash.
5.4 When coredump-restart, the guest state is changed from running (booted)=> crashed (panicked) => running (crashed).
    when coredump-destroy, the guest state is changed from running (booted)=> crashed (panicked) => shut off (crashed).
5.5 Before the guest finish crashing, execute the command on another terminal.
     # cat /proc/$(lsof -w /var/lib/libvirt/qemu/dump/*|awk '/libvirt_i/{print $2}')/fdinfo/*1*
    In case auto_dump_bypass_cache=0 and default value(disabled),  
    pos:        4211090448  
    flags:        0200001      ===> the third value is '0' as expected.

    In case auto_dump_bypass_cache=1,
    pos:        4107272192
    flags:      0600001      ===> the third value is '0', but expected value is '4'. It is an issue. See bug
https://bugzilla.redhat.com/show_bug.cgi?id=1240494

6.  Check the dumped images can be analysed with crash tool successfully
6.1 Start the guest and execute # virsh dump guest /tmp/dump
6.2 Ensure kernel-debuginfo and kernel-debuginfo-common are in same version as the kernel version in the guest.
In host:
[root@ibm-p8-kvm-01-qe tmp]# rpm -qa|grep kernel-debuginfo
kernel-debuginfo-common-ppc64le-3.10.0-282.el7.ppc64le
kernel-debuginfo-3.10.0-282.el7.ppc64le
In guest:
[root@localhost ~]# uname -r
3.10.0-282.el7.ppc64le

6.3 Run crash tool on host, but crash throws error.
# crash /usr/lib/debug/lib/modules/3.10.0-282.el7.ppc64le/vmlinux  /tmp/dump

crash 7.1.1-2.el7
...
This program has absolutely no warranty.  Enter "help warranty" for details.

crash: invalid or unsupported host architecture for KVM: PPC64

See the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1240497

7. on_crash event test scenarios
7.1 Edit XML with <on_crash>coredump-destroy</on_crash> and start guest.
7.2 In guest, stop kdump and crash the guest
7.3 The guest status is changed to crashed (panicked) and then shut off (crashed).
7.4 Dump file is created in specified directory.
7.5 Try with <on_crash>coredump-restart</on_crash>, and restart libvirtd after guest os is crashed and dump file is created. The guest state should be crashed (panicked) for a moment and finally
7.6 Try with <on_crash>restart</on_crash>, other result is same with 7.5 except for no dump file created.
7.7 Try with <on_crash>destroy</on_crash>, other result is same with 7.1 except for no dump file created.
7.8 Try with <on_crash>preserve</on_crash>, the guest keeps in crashed status and no dump file is created. The guest can be destroyed successfully.
7.9 Do virsh dump on guest and the guest is still in running state.
7.10 Restart libvirtd, , the guest's status is right for different on_crash settings

Comment 6 errata-xmlrpc 2015-11-19 06:08:05 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-2015-2202.html