Bug 1651262 - Stale domain information: "in shutdown" state
Summary: Stale domain information: "in shutdown" state
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: rawhide
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2018-11-19 14:53 UTC by Jan Pokorný [poki]
Modified: 2018-12-11 20:49 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-12-11 20:49:08 UTC
Type: Bug

Attachments (Terms of Use)
Requested log file (33.42 KB, text/plain)
2018-11-19 15:26 UTC, Jan Pokorný [poki]
no flags Details

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@redhat.com>
AuthorDate: Wed Nov 7 14:34:52 2018 +0100
Commit:     Jiri Denemark <jdenemar@redhat.com>
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".


    Signed-off-by: Jiri Denemark <jdenemar@redhat.com>

Comment 6 Cole Robinson 2018-12-11 20:49:08 UTC
Fixed in libvirt 4.10.0

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