Bug 746007 - After using 'shutdown' on a xen guest, virt-manager still reports guest is running
Summary: After using 'shutdown' on a xen guest, virt-manager still reports guest is ru...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 16
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
: 733433 746503 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-10-13 15:41 UTC by Tim Flink
Modified: 2012-07-05 23:44 UTC (History)
16 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2012-07-05 23:44:32 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
screenshot of xm, virsh and virt-manager showing status (315.65 KB, image/png)
2011-10-13 15:41 UTC, Tim Flink
no flags Details

Description Tim Flink 2011-10-13 15:41:42 UTC
Created attachment 528059 [details]
screenshot of xm, virsh and virt-manager showing status

Description of problem:
When I shutdown a xen guest, vmm still shows it as running even though virsh and xm don't (see attached screenshot).

This means that I can't start the domain from virt-manager again because the only options are shutdown related (pause, force-off etc.)

Version-Release number of selected component (if applicable):
virt-manager-0.9.0-6.fc16

How reproducible:
Every time

Steps to Reproduce:
1. start Xen domain
2. stop xen domain
  
Actual results:
xen domain still shows up as running in virt-manager after it has been stopped and the domain cannot be "powered on" from virt-manager

Expected results:
Xen domain shows up as stopped in virt-manager, able to "power on" domain from virt-manager

Comment 1 Cole Robinson 2012-01-29 18:51:55 UTC
This is a libvirt issue, present in f16 and current upstream. The issue is that invoking shutdown() on a xen guest leaves it reporting domain state 0 (unknown) for the vm object that was shut down. However, if you re-fetch the domain object, it reports the correct state of 5 (shutoff). So something is funky in xen or the xen driver.

This doesn't seem to affect the 'destroy'/'force poweroff' command

Reproducer:

$ cat test.py 
import libvirt
import time

conn = "xen:///"
vmname = "xenlivecd"

conn = libvirt.open(conn)
vm = conn.lookupByName(vmname)

if vm.info()[0] == libvirt.VIR_DOMAIN_SHUTOFF:
    print "Starting %s" % vmname
    vm.create()
    time.sleep(5)

print "Shutting off %s" % vmname
vm.shutdown()
time.sleep(5)

print "Domain state is %s" % vm.info()[0]
print "Refreshed domain state is %s" % conn.lookupByName(vmname).info()[0]
print "Old domain is still %s" % vm.info()[0]

$ sudo python test.py 
Starting xenlivecd
Shutting off xenlivecd
Domain state is 0
Refreshed domain state is 5
Old domain is still 0


Reassigning to libvirt but this could be a xen issue.

Comment 2 Cole Robinson 2012-01-29 18:52:53 UTC
*** Bug 733433 has been marked as a duplicate of this bug. ***

Comment 3 Cole Robinson 2012-04-10 19:14:45 UTC
Possible patch upstream:

https://www.redhat.com/archives/libvir-list/2012-April/msg00023.html

Comment 4 Cole Robinson 2012-06-07 19:40:14 UTC
*** Bug 746503 has been marked as a duplicate of this bug. ***

Comment 5 Fedora Update System 2012-06-24 23:54:46 UTC
libvirt-0.9.6.1-1.fc16 has been submitted as an update for Fedora 16.
https://admin.fedoraproject.org/updates/libvirt-0.9.6.1-1.fc16

Comment 6 Fedora Update System 2012-06-26 00:55:25 UTC
Package libvirt-0.9.6.1-1.fc16:
* should fix your issue,
* was pushed to the Fedora 16 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing libvirt-0.9.6.1-1.fc16'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-9913/libvirt-0.9.6.1-1.fc16
then log in and leave karma (feedback).

Comment 7 Fedora Update System 2012-07-05 23:44:32 UTC
libvirt-0.9.6.1-1.fc16 has been pushed to the Fedora 16 stable repository.  If problems still persist, please make note of it in this bug report.


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