libvirt will do a graceful shutdown of KVM guests by triggering a virtual ACPI
button press. This requires ACPI be enabled for the VM, and inside the OS.

So we can check, please provide the XML config for your VM from
/etc/libvirt/qemu/[NAME].xml

And the logfile from /var/log/libvirt/qemu/[NAME].xml

Created attachment 300000 [details]
libvirt config file for machine that won't power off

These virtual machines were at various stages of a failed boot, or did not have
ACPI enabled.  

Eg the attached VM does not have a valid disk at the moment, so sits in a 100%
cpu loop at the bios.

Created attachment 300004 [details]
Logfile for above libvirt xml description

Ok, so the XML config shows that ACPI is enabled. If the guest is crashed / hung
/ failed to boot, then it is unlikely it will respond to ACPI button press
events used to trigger a shutdown. There isn't really much we can do about that,
so I'm inclined to close this NOTABUG unless the problem also occurs with a
guest that is running 'normally'

As a failsafe, in the virt-manager UI you should also be able to trigger a
'destroy' operation from the File menu of the guest console window. This is akin
to physically pulling the power plug out of the machine. Alternatively from the
command line you can do 'virsh destroy GUEST-NAME'.  

Well, it also happens for guests where ACPI was enabled in the guest VM setup,
but disabled in the guest (as was suggested by some authorities, by pressing F5
at the right point, for Windows better/acceptable WinXP VM performance).  

I had always assumed destroy would physically destroy the disk image, or some
such.  

Perhaps if the power button is pressed twice, it should ask if you wish to hard
power off?  

Hello,
I see this on F8 as well, even for virtual systems where I know shutdown worked 
before.

kernel-2.6.24.3-50.fc8.x86_64
libvirt-0.4.1-2.fc8.x86_64
virt-manager-0.5.3-2.fc8.x86_64

*** Bug 441236 has been marked as a duplicate of this bug. ***

Comment #6,

This previously worked, but it wasn't actually "shutting down" the machine, it
was effectively ripping the plug from the wall. Previously kvm did not have any
way to perform a graceful ACPI shutdown, so libvirt implemented the shutdown
command to be the same as destroy. That is probably why it previously appeared
to work. Can you ensure that you have kvm-60 or later installed?

I have kvm-60-3.fc8.x86_64 and this problem is still there.

Hello Cole,
I have these packages installed:

kvm-60-3.fc8.x86_64
qemu-0.9.0-7.fc8.x86_64

I have just noticed that this happens when I destroy the system:

$ virt-manager --no-fork
libvir: Domain error : invalid domain pointer in virDomainGetID
libvir: Domain error : invalid domain pointer in virDomainGetName
libvir: Domain error : invalid domain pointer in virDomainGetID

I'll be glad to do some testing.

Ok, so the problem is that although virt-manager enabled ACPI, and KVM enabled
ACPI, the Linux  guest kernel decided to disable ACPI, as can be seen from this
dmesg log I get:

  DMI not present or invalid.
  Using APIC driver default
  ACPI: Disabling ACPI support


From what I can tell, the problem  is that there is no DMI BIOS data, and thus
the kernel assumes its a buggy BIOS and disables ACPI.

If you pass  'acpi=force' on the guest kernel command line, then the
virt-manager/libvirt graceful shutdown will work correctly.

The core problem though is that KVM needs to supply DMI BIOS data so Linux
automagically enables ACPI

So reassign to kvm?

Well, I can't even shutdown a machine which didn't boot at all, meaning:
- start virt-manager
- create new vm, e.g. with freebsd, choose qemu or kvm, doesn't matter
- start the vm
- cancel the setup routine. The cd-image will be unmounted from the vm
- start the vm again, obviously no install media is found
- not possible to shut down the vm or send any keys via the "Send key" menu

Package versions on my machine:
libvirt-0.4.2-1.fc9.i386
virt-manager-0.5.4-3.fc9.i386
kvm-65-1.fc9.i386
qemu-0.9.1-5.fc9.i386

Use the 'Destroy' menu to forcably poweroff a machine which isn't responding.
'Shutdown' is only for doing a graceful controlled shutdown in cooperation with
the guest OS. If the guest OS is dead,then a Destroy is needed

Then the bug needs to be re-addressed as:

It is unclear how to power of a guest that is unwilling or unable to answer ACPI
events.  The shutdown button shows no user interaction, nor is there any
indication that 'destroy' means 'power off' (not say, destory my VM data).

It is also just hard to find 'Destory'.  It should appear on the toolbar,
perhaps after the user unsuccessfully presses the shut down button. 

*** Bug 443980 has been marked as a duplicate of this bug. ***

> It is also just hard to find 'Destory'.  It should appear on the toolbar,
perhaps after the user unsuccessfully presses the shut down button. 

Definitely. The funny thing is, I use the German localized version and they
translate Destroy with Delete which is even more confusing.

(In reply to comment #17)
> Definitely. The funny thing is, I use the German localized version and they
> translate Destroy with Delete which is even more confusing.

Wow! Yeah that clearly means we need to reword it. I know Dan has some patches
pending that clear this up by renaming it 'Force Poweroff' or similar. Placing
it on the toolbar as a button is probably not a good idea though given the
dangerous nature of the command. The fact is, graceful shutdown _should_ work
for all supported guests, and we shouldn't design the ui around a bug in kvm.

This bug should be moved back to the kvm issue layed out in Comment #11 though,
and someone should open a seperate bug for the 'destroy' wording, otherwise the
first 10 comments are useless.

Well, why KVM guest don't respond is a matter of guest OS and KVM bugs, but in
my case I had created situations where ACPI power off was not sufficient, and
these situations were even when ACPI worked perfectly in KVM.  ACPI not being
advertised properly for guests is indeed a separate issue.

In terms of UI, I don't see the toolbar as unsafe, if it pops up a dialog with a
warning such as 'confirm forced power off of guest? power off/cancel'

Even when KVM is working perfectly there is no guarentee whatsoever  that
'Shutdown' will actually shutdown. The semantics of shutdown are that it is a
request to the guest OS to shut itself down cleanly. The guest is under no
obligation to honor this request, and in this circumstance, 'destroy' must be
used to hard poweroff. As Cole mentions the next virt-manager release will have
a  toolbar option to choose between Shutdown, Reboot and Force poweroff.

*** Bug 444989 has been marked as a duplicate of this bug. ***

Dan added some large UI work upstream which combines the 'Console' and 'Details'
view into the same tabbed window. Along with these changes, the 'Destroy' option
was renamed 'Force Poweroff' (hopefully a bit more clear). I'll put this bug in
POST.

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

virt-manager-0.6.0-0.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/virt-manager-0.6.0-0.fc9

virt-manager-0.6.0-1.fc9 has been submitted as an update for Fedora 9.
http://admin.fedoraproject.org/updates/virt-manager-0.6.0-1.fc9

virt-manager-0.6.0-1.fc9 has been pushed to the Fedora 9 testing repository.  If problems still persist, please make note of it in this bug report.
 If you want to test the update, you can install it with 
 su -c 'yum --enablerepo=updates-testing-newkey update virt-manager'.  You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F9/FEDORA-2008-10705

virt-manager-0.6.0-1.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

The new design (and menu for different power off options) is much better!