Bug 1651262

Summary: Stale domain information: "in shutdown" state
Product: [Fedora] Fedora Reporter: Jan Pokorný [poki] <jpokorny>
Component: libvirtAssignee: Libvirt Maintainers <libvirt-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: agedosier, berrange, clalancette, crobinso, itamar, jdenemar, jforbes, jpokorny, laine, libvirt-maint, phrdina, veillard
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-12-11 20:49:08 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Requested log file none

Description Jan Pokorný [poki] 2018-11-19 14:53:50 UTC 
I am not sure this will be very helpful, since this doesn't look very
reproducible, and I can't quite tell at which point this started.

Anyway, using
> libvirt-daemon-4.9.0-1.fc30.x86_64
> virt-manager-2.0.0-1.fc30.noarch
and installing a new Fedora 29 (server edition) VM using network
install, I went through multiple restart cycles, sometimes graceful
sometimes perhaps not, and then, after some time of working with
that VM, I've noticed virt-manager shows the VM as "Shutting Down"
(and inactive by icon), while I am using it happily, without
a sign of degradation one could imagine on the graceful way
of the machine towards a shutdown.

It's not a problem of virt-manager, though:

# virsh dominfo fedora29 | grep State
> State:          in shutdown

Please let me know how can I get closer to what happened here.
Comment 1 Cole Robinson 2018-11-19 15:04:19 UTC 
Thanks for the report. Please provide ~/.cache/virt-manager/virt-manager.log it may provide some details.
Comment 2 Pavel Hrdina 2018-11-19 15:23:04 UTC 
This might be the issue fixed by upstream commit <e47949357ba268e7e8c3adea7c262b84fa002302>.

Reproduce should be simple, start new guest and let it fully boot, click on "Reboot".  This should trigger ACPI reboot and in that case the state will remain "in shutdown".
Comment 3 Jan Pokorný [poki] 2018-11-19 15:26:51 UTC 
Created attachment 1507300 [details]
Requested log file

The situation is still current so if there are any live steps
I could use to diagnose the problem, please let me know.
Comment 4 Jan Pokorný [poki] 2018-11-19 19:22:09 UTC 
As an Update, did run "poweroff" in quest and the state reported by
libvirt (virt-manager) switched correctly:

# virsh dominfo fedora29 | grep State
> State:          shut off
Comment 5 Jiri Denemark 2018-11-20 08:06:36 UTC 
I think Pavel is right and this is already fixed upstream by

commit e47949357ba268e7e8c3adea7c262b84fa002302
Refs: v4.9.0-21-ge47949357b
Author:     Jiri Denemark <jdenemar>
AuthorDate: Wed Nov 7 14:34:52 2018 +0100
Commit:     Jiri Denemark <jdenemar>
CommitDate: Thu Nov 8 09:08:58 2018 +0100

    qemu: Don't ignore resume events

    Since commit v4.7.0-302-ge6d77a75c4 processing RESUME event is mandatory
    for updating domain state. But the event handler explicitly ignored this
    event in some cases. Thus the state would be wrong after a fake reboot
    or when a domain was rebooted after it crashed.

    BTW, the code to ignore RESUME event after SHUTDOWN didn't make sense
    even before making RESUME event mandatory. Most likely it was there as a
    result of careless copy&paste from qemuProcessHandleStop.

    The corresponding debug message was clarified since the original state
    does not have to be "paused" only and while we have a "resumed" event,
    the state is called "running".

    https://bugzilla.redhat.com/show_bug.cgi?id=1612943

    Signed-off-by: Jiri Denemark <jdenemar>
Comment 6 Cole Robinson 2018-12-11 20:49:08 UTC 
Fixed in libvirt 4.10.0