[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[libvirt] [RESEND] libvirt: xen: Shutdown detection fixes (RH-BZ#746007)



Resending this as there was no feedback overall and at least
the first change fixes the following bug:
https://bugzilla.redhat.com/show_bug.cgi?id=746007

---

The issue is easy to observe when using virt-manager as a frontend.
Its main window seems to open connections for the up/down main
display once and then only repeats DomainGetInfo on the same
connection to check whether the instance is up or shut down.

The initial open on the connection sets the domain id to -1 for
inactive managed domains. And once running, the hypervisor driver
returns the status. But after shutdown, the domain cannot be found
by the hypervisor driver and the domain info is obtained by the
xend driver. However, that expects the domain id to be -1 for
inactive domains. This is not true (anymore). In testing I found
that domain/status seems to be always present and better suited
to check whether a domain is running or not (0 for shutdown and
2 for running, there are probably other values, too).

Beside the change, which does fix this problem, the question is
whether there should be a mechanism that resets domain->id to -1
when the instance is found to be shut down. And if that should
happen, should it be done by any sub-driver or by the unified
driver.

The second problem I observed when I shut down an instance from
the vnc console provided by virt-manager. As soon as the instance
was down, the log produced internal errors about every second.

Found this again, to be related to the unified driver approach.
The call that causes the many error messages is GetVcpus. While
the instance is up, the hypervisor driver returns those. But
after shutdown, the domain cannot be found by that driver. The
xend driver works, though. So what happens is that the hypervisor
driver logs an internal error but the call succeeds because the
xend driver returns successful.

This generally opens the question whether a sub-driver should
log any errors (at least not on error level, maybe debug)?
The second patch only quiets down the one message I saw repeated
that often. There are some other errors logged without any
obvious problems interacting with the instances, but those are
by far less often.

-Stefan

Please cc: me on replies as I am (yeah still) not subscribed to
this m-l. Thanks.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]