Red Hat Bugzilla – Bug 700468
Reboot and Shut Down item in Virtual Machine menu don't work
Last modified: 2012-08-07 16:02:52 EDT
Description of problem:
I have F15 installed in my VM and VM itself is running on F15, too. When I press either Reboot or Shut Down items from main menu in Virtual Machine, screen gets black (text mode) with only text cursor displayed for some time (approx. 1 to 3 minutes) and then come back to gnome without rebooting/shutting down.
Version-Release number of selected component (if applicable):
rpm -q virt-manager
Steps to Reproduce:
1. run F15 in VM
2. press Reboot or Shut Down item in main menu
3. wait and see what is done
Screen switches to text mode for some time and then returns back
VM should restart/shut down
Force off is the only way to kill running VM from outside, this works well.
It seems working well when RHEL-5 is running in VM, so maybe it is not problem in VM.
What about doing 'shutdown -h now' on the command line from inside the VM? Or using gnome UI to shutdown? If that doesn't work, please reassign to systemd or gnome-power-manager
When I run "shutdown -h now", system in VM shuts down correctly, but VM doesn't recognize this (it still offers Restart, Shut Down and Force off, but not Run in the main menu, even if the system is running no more).
Then if I try to Force it off again, error is printed: "Error shutting down domain: Requested operation is not valid: domain is not running" and the following trace is in details:
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/engine.py", line 911, in _do_destroy_domain
File "/usr/share/virt-manager/virtManager/domain.py", line 1168, in destroy
File "/usr/lib64/python2.7/site-packages/libvirt.py", line 346, in destroy
if ret == -1: raise libvirtError ('virDomainDestroy() failed', dom=self)
libvirtError: Requested operation is not valid: domain is not running
After that VM is correctly off again and I can press Run.
However, this is not happening every-time, "shutdown -h now" command sometimes works as expected, system shuts down and is able to run again without problems. I haven't found the case when it behaves incorrectly yet, maybe when VM is running for a longer time.
So I'm still not sure where the problem is, while there are some known problems with suspending F15 (which is not running in VM, see bug #698135), so feel free to reassign this.
Note: pressing Reboot or Shut down from VM's main menu fails every-time.
Jan, if you can reproduce that issue with virt-manager getting out of sync, please file a separate virt-manager bug, and include the relevant output of ~/.virt-manager/virt-manager.log
For the original issue, if the virt-manager shutdown button is triggering _any_ behavior change in the guest, virt-manager/libvirt are at least doing their job. So my guess is that whatever is handling the acpi shutdown signal isn't doing it's job? Reassigning to gnome-power-manager for now
See also bug 741375 against F16, where the default acpi behavior for an F16 guest still prevents host-initiated clean shutdown.
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.
(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached 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, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.
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: