Bug 532009 - "kvm_run: failed entry, reason 7" when running guest with F11 LiveCD
"kvm_run: failed entry, reason 7" when running guest with F11 LiveCD
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Justin M. Forbes
Fedora Extras Quality Assurance
Depends On:
Blocks: F11VirtTarget
  Show dependency treegraph
Reported: 2009-10-30 05:19 EDT by Alexander Todorov
Modified: 2014-09-01 08:07 EDT (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 519667
Last Closed: 2010-06-28 11:21:04 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
XML file for the f11-livecd guest (1.14 KB, text/plain)
2009-10-30 05:23 EDT, Alexander Todorov
no flags Details

  None (edit)
Description Alexander Todorov 2009-10-30 05:19:24 EDT
+++ 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):

How reproducible:

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@redhat.com on 2009-08-28 04:59:26 EDT ---

Hmm, I don't seem to be seeing this now...

--- Additional comment from twaugh@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com on 2009-09-17 07:01:02 EDT ---

Created an attachment (id=361476)

--- Additional comment from crobinso@redhat.com 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@redhat.com on 2009-09-21 10:42:37 EDT ---

twaugh: has latest libvirt fixed it for you too?

--- Additional comment from twaugh@redhat.com 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@redhat.com on 2009-09-21 12:02:17 EDT ---

Thanks Tim

--- Additional comment from crobinso@redhat.com on 2009-09-21 13:08:17 EDT ---

*** Bug 500968 has been marked as a duplicate of this bug. ***
Comment 1 Alexander Todorov 2009-10-30 05:20:28 EDT
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.
Comment 2 Alexander Todorov 2009-10-30 05:23:51 EDT
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 
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.
Comment 3 Mark McLoughlin 2009-11-19 04:49:05 EST
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?
Comment 4 Alexander Todorov 2009-11-19 05:07:22 EST
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.
Comment 5 Alexander Todorov 2009-11-19 07:24:27 EST
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.
Comment 6 Justin M. Forbes 2010-02-04 11:43:01 EST
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?
Comment 7 Bug Zapper 2010-04-28 07:01:10 EDT
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: 
Comment 8 Bug Zapper 2010-06-28 11:21:04 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.