+++ This bug was initially created as a clone of Bug #519667 +++ Description of problem: After shutting down a guest, libvirtd is no longer running. /var/log/messages says: Aug 27 11:44:58 worm libvirtd: 11:44:58.794: error : qemudDomainGetMemoryBalloon:3229 : operation failed: could not query memory balloon allocation Version-Release number of selected component (if applicable): libvirt-0.7.0-6.fc12.x86_64 qemu-0.10.91-0.8.rc1.fc12.x86_64 kernel-2.6.31-0.174.rc7.git2.fc12.x86_64 qemu-system-x86-0.10.91-0.8.rc1.fc12.x86_64 How reproducible: 100% Steps to Reproduce: 1.Start guest. 2.Shut down guest. 3.Attempt to start guest. Actual results: libvirtd is no longer running. Expected results: Still running after guest is shut down. --- Additional comment from twaugh on 2009-08-28 04:59:26 EDT --- Hmm, I don't seem to be seeing this now... --- Additional comment from twaugh on 2009-08-28 05:01:47 EDT --- ...and of course it just happened again, while shutting down an F-11 guest. --- Additional comment from markmc on 2009-09-04 09:06:09 EDT --- I can't reproduce this Was it a segfault? Can you get a stack trace? --- Additional comment from berrange on 2009-09-10 05:00:44 EDT --- Can you provide the guest configuration file which exhibits this crash. Also is this being seen with a guest whose disks are on NFS as per your other bugs ? --- Additional comment from twaugh on 2009-09-17 06:53:57 EDT --- It turns out libvirtd is still running but virt-manager's connection to it is broken. No, the disks are not on NFS. $ ls -Z /home/twaugh/VM/RHEL54.img -rw-rw-r--. root root system_u:object_r:virt_image_t:s0 /home/twaugh/VM/RHEL54.img --- Additional comment from twaugh on 2009-09-17 07:01:02 EDT --- Created an attachment (id=361476) RHEL54.xml --- Additional comment from crobinso on 2009-09-17 10:48:17 EDT --- I was hitting this issue as well, but not anymore after updating libvirt to latest rawhide version (libvirt-0.7.1-1.fc12.x86_64). Tim, can you give that a shot? Guest was win2003, no fancy setup, just a single ide disk. shutdown (not destroy) caused the issue. virsh list would show 'nostate' for the VM, and all 'info' calls would fail with "could not query memory balloon'. There is another bug filed to handle virt-manager's poor behavior in coping with this situation (bz 522168). --- Additional comment from markmc on 2009-09-21 10:42:37 EDT --- twaugh: has latest libvirt fixed it for you too? --- Additional comment from twaugh on 2009-09-21 11:39:34 EDT --- I'm not seeing it break with libvirt-0.7.1-4.fc12.x86_64. --- Additional comment from markmc on 2009-09-21 12:02:17 EDT --- Thanks Tim --- Additional comment from crobinso on 2009-09-21 13:08:17 EDT --- *** Bug 500968 has been marked as a duplicate of this bug. ***
I'm seeing this on F11 with latest updates and libvirt-0.6.2-18.fc11.i586 when trying to start F1 livecd as domU.
Created attachment 366773 [details] XML file for the f11-livecd guest /var/log/libvirt/qemu/f11-livecd.log says: LC_ALL=C PATH=/sbin:/usr/sbin:/bin:/usr/bin /usr/bin/qemu-kvm -S -M pc -m 512 -smp 1 -name f11-livecd -uuid 6bc23955-6bd2-1d01-df26-a84350f41c5e -monitor pty -pidfile /var/run/libvirt/qemu//f11-livecd.pid -boot d -drive file=/root/Fedora-11-i686-Live.iso,if=ide,media=cdrom,index=2 -net nic,macaddr=54:52:00:2b:b5:b4,vlan=0 -net tap,fd=18,vlan=0 -serial pty -parallel none -usb -vnc 127.0.0.1:0 char device redirected to /dev/pts/1 char device redirected to /dev/pts/2 kvm_run: failed entry, reason 7 rax 0000000000000000 rbx 0000000000000000 rcx 0000000000000000 rdx 0000000000000623 rsi 0000000000000000 rdi 0000000000000000 rsp 0000000000000000 rbp 0000000000000000 r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 0000000000000000 r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 0000000000000000 rip 000000000000fff0 rflags 00023002 cs f000 (000f0000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ds 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) es 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) ss 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) fs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) gs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) tr 0000 (fffbd000/00002088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) gdt 0/ffff idt 0/ffff cr0 60000010 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 kvm_run returned -8 SELinux is in permissive mode.
Thanks for the report Alexander Could you give us more information on the host machine? e.g. is this is an amd64 machine with a 32 bit kernel? http://fedoraproject.org/wiki/How_to_debug_Virtualization_problems gives some tips on the kind of info that can be helpful It looks like the underlying problem is in the kernel - libvirt just isn't handling the problem very well - so I'm moving the bug to the kernel Avi, any ideas? Is this a VMEXIT_CR7_READ SVM exit code?
Hi Mark, the system I believe was ibm-firefly.rhts which has a 32bit CPU. I've reserved it again and will re-test and try to attach more info.
This system is currently beeing moved to the new inventory system. It's not available for test at the moment. I'll try in several days.
Any updates on this? Is this still happening in F12? The F-11 livecd won't be respun, so is there any reason to keep this bug opened?
This message is a reminder that Fedora 11 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 11. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '11'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 11's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 11 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.