<div dir="ltr">Yeah you are more or less correct. I think this is an upstream QEMU bug, as QEMU is stopping the CPUs but not firing the SHUTDOWN event. I shall report there.</div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 12 July 2014 00:23, Guido Günther <span dir="ltr"><<a href="mailto:agx@sigxcpu.org" target="_blank">agx@sigxcpu.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Fri, Jul 11, 2014 at 06:33:12AM +0000, Michael D wrote:<br>
> Package: libvirt-bin<br>
> Version: 1.2.4-1~bpo70+1<br>
> Severity: important<br>
><br>
> Hi,<br>
><br>
> I am currently using qemu-x86_64 version 2.0.0 (Debian<br>
> 2.0.0+dfsg-4~bpo70+1) along with libvirt, both backported. When a normal<br>
> QEMU guest is created, and then inside it "halt" is executed. The guest<br>
> will shut down and cease processing, however libvirt will not recognize<br>
> this and still mark the guest as running. The correct action is to send a<br>
> SIGTERM to QEMU. This appears to occur correctly when running on Ubuntu so<br>
> I am filing the bug against this package.<br>
<br>
No it's not since you tell the quest OS to quit, not libvirt. KVM will<br>
exit if the guest os will shutdown gracefully. If this isn't the case<br>
for all you're guests you need to check there.<br>
Cheers,<br>
 -- Guido<br>
</blockquote></div><br></div>