Hide Forgot
Description of problem: Can't extract guest memory dump from qemu core Version-Release number of selected component (if applicable): hostkernel:3.10.0-470.el7.ppc64le guestkernel:3.10.0-470.el7.ppc64le qemu:qemu-kvm-rhev-2.6.0-13.el7.ppc64le How reproducible: 100% Steps to Reproduce: 1.Setup as below in the terminal which run the qemu-kvm proceed ulimit -c unlimited echo "/var/core.%p-%u-%g-%s-%t-%h-%e" > /proc/sys/kernel/core_pattern 2.Boot up guest with dump-guest-core=on /usr/libexec/qemu-kvm \ -name test \ -machine type=pseries,dump-guest-core=on \ -smp 4 \ -m 4096 \ -monitor stdio \ -rtc base=utc,clock=vm \ -vnc :20 \ -qmp tcp:0:4444,server,nowait \ -device virtio-scsi-pci,bus=pci.0 \ -device spapr-pci-host-bridge,id=vfiohost,index=0x1 \ -device virtio-net-pci,netdev=net0,id=nic0,mac=52:54:00:c4:e7:84 \ -netdev tap,id=net0,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown,vhost=on -device scsi-hd,id=scsi-hd0,drive=scsi-hd0-dr0,bootindex=0 \ -drive file=/root/RHEL-7.2.qcow2,if=none,id=scsi-hd0-dr0,format=qcow2,cache=none \ 3.Kill the qemu-kvm process with SIGSEGV pkill -SEGV -x qemu-kvm 4.Open the "coredump" file with gdb, and load the extension. gdb /var/core.28761-0-0-11-1401176809-hp-dl385g7-05.qe.lab.eng.nay.redhat .com-qemu-kvm (gdb) source /usr/share/qemu-kvm/dump-guest-memory.py Actual results: /usr/share/qemu-kvm/dump-guest-memory.py:No such file or directory Expected results: /usr/share/qemu-kvm/dump-guest-memory.py exist and can load the extension. Additional info: x86 qemu have this file.
Looks like dump-guest-memory.py was written for x86 only initially, but support for ppc64 has been added since QEMU 2.6.0: http://git.qemu.org/?p=qemu.git;a=commitdiff;h=368e3adc8928b278693 Mirek, do you think it would be OK to package this file into the qemu-kvm-rhev RPM for ppc64le, too, nowadays?
Sounds reasonable to me.
(In reply to Thomas Huth from comment #1) > Mirek, do you think it would be OK to package this file into the > qemu-kvm-rhev RPM for ppc64le, too, nowadays? And for AArch64. Thanks, drew
(In reply to Andrew Jones from comment #4) > (In reply to Thomas Huth from comment #1) > > Mirek, do you think it would be OK to package this file into the > > qemu-kvm-rhev RPM for ppc64le, too, nowadays? > > And for AArch64. > > Thanks, > drew Should I clone this BZ? Or can we flip flags on this one to make it multi-arch?
I think doing it for all supported arches at once would be simplest.
Yes, we can get this file into qemu-kvm-rhev as this is bringing ppc64/aarch64 closer to our x86_64 behavior.
Fix included in qemu-kvm-rhev-2.6.0-17.el7
Reproduce this bug on qemu-kvm-rhev-2.6.0-11.el7. Host: qemu-kvm-rhev-2.6.0-11.el7 3.10.0-481.el7.ppc64le Steps: Same as comment#0. Result: Program terminated with signal 11, Segmentation fault. #0 0x00003fff82e2d694 in ppoll () from /lib64/libc.so.6 Missing separate debuginfos, use: debuginfo-install alsa-lib-1.1.1-1.el7.ppc64le bzip2-libs-1.0.6-13.el7.ppc64le cyrus-sasl-lib-2.1.26-20.el7_2.ppc64le cyrus-sasl-md5-2.1.26-20.el7_2.ppc64le cyrus-sasl-plain-2.1.26-20.el7_2.ppc64le dbus-libs-1.6.12-14.el7.ppc64le elfutils-libelf-0.166-2.el7.ppc64le elfutils-libs-0.166-2.el7.ppc64le flac-libs-1.3.0-5.el7_1.ppc64le glib2-2.46.2-3.el7.ppc64le glibc-2.17-155.el7.ppc64le gmp-6.0.0-12.el7_1.ppc64le gnutls-3.3.24-1.el7.ppc64le gperftools-libs-2.4-8.el7.ppc64le gsm-1.0.13-11.el7.ppc64le json-c-0.11-4.el7_0.ppc64le keyutils-libs-1.5.8-3.el7.ppc64le krb5-libs-1.14.1-18.el7.ppc64le libICE-1.0.9-2.el7.ppc64le libSM-1.2.2-2.el7.ppc64le libX11-1.6.3-3.el7.ppc64le libXau-1.0.8-2.1.el7.ppc64le libXext-1.3.3-3.el7.ppc64le libXi-1.7.4-2.el7.ppc64le libXtst-1.2.2-2.1.el7.ppc64le libaio-0.3.109-13.el7.ppc64le libasyncns-0.8-7.el7.ppc64le libattr-2.4.46-12.el7.ppc64le libcacard-2.5.2-2.el7.ppc64le libcap-2.22-8.el7.ppc64le libcom_err-1.42.9-9.el7.ppc64le libcurl-7.29.0-32.el7.ppc64le libdb-5.3.21-19.el7.ppc64le libfdt-1.4.0-2.el7.ppc64le libffi-3.0.13-18.el7.ppc64le libgcc-4.8.5-9.el7.ppc64le libgcrypt-1.5.3-12.el7_1.1.ppc64le libgpg-error-1.12-3.el7.ppc64le libibverbs-1.2.0-2.el7.ppc64le libidn-1.28-4.el7.ppc64le libiscsi-1.9.0-7.el7.ppc64le libnl3-3.2.28-1.el7.ppc64le libogg-1.3.0-7.el7.ppc64le libpng-1.5.13-7.el7_2.ppc64le librdmacm-1.1.0-2.el7.ppc64le libselinux-2.5-4.el7.ppc64le libsndfile-1.0.25-10.el7.ppc64le libssh2-1.4.3-10.el7_2.1.ppc64le libstdc++-4.8.5-9.el7.ppc64le libtasn1-3.8-3.el7.ppc64le libusbx-1.0.20-1.el7.ppc64le libuuid-2.23.2-33.el7.ppc64le libvorbis-1.3.3-8.el7.ppc64le libxcb-1.11-4.el7.ppc64le lzo-2.06-8.el7.ppc64le nettle-2.7.1-5.el7.ppc64le nspr-4.11.0-1.el7_2.ppc64le nss-3.21.0-17.el7.ppc64le nss-softokn-freebl-3.16.2.3-14.4.el7.ppc64le nss-util-3.21.0-2.2.el7_2.ppc64le numactl-libs-2.0.9-6.el7_2.ppc64le openldap-2.4.40-12.el7.ppc64le openssl-libs-1.0.1e-58.el7.ppc64le p11-kit-0.20.7-3.el7.ppc64le pcre-8.32-15.el7_2.1.ppc64le pixman-0.34.0-1.el7.ppc64le pulseaudio-libs-6.0-8.el7.ppc64le snappy-1.1.0-3.el7.ppc64le systemd-libs-219-24.el7.ppc64le tcp_wrappers-libs-7.6-77.el7.ppc64le trousers-0.3.13-1.el7.ppc64le xz-libs-5.2.2-1.el7.ppc64le zlib-1.2.7-17.el7.ppc64le (gdb) source /usr/share/qemu-kvm/dump-guest-memory.py /usr/share/qemu-kvm/dump-guest-memory.py: No such file or directory. Test this bug on qemu-kvm-rhev-2.6.0-17.el7.ppc64le Result: (gdb) source /usr/share/qemu-kvm/dump-guest-memory.py (gdb) bt #0 0x00003fff781bd694 in ppoll () from /lib64/libc.so.6 #1 0x0000000049280b00 in ppoll (__ss=0x0, __timeout=<optimized out>, __nfds=<optimized out>, __fds=<optimized out>) at /usr/include/bits/poll2.h:77 #2 qemu_poll_ns (fds=<optimized out>, nfds=<optimized out>, timeout=<optimized out>) at qemu-timer.c:325 #3 0x000000004927fec0 in os_host_main_loop_wait (timeout=2999873939) at main-loop.c:252 #4 main_loop_wait (nonblocking=<optimized out>) at main-loop.c:506 #5 0x0000000048fa62e0 in main_loop () at vl.c:1939 #6 main (argc=<optimized out>, argv=<optimized out>, envp=<optimized out>) at vl.c:4669 So this bug has been fixed on ppc64le.
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-2673.html