Re: [libvirt] [PATCH v2 4/5] qemu: Wire up virDomainSuspendForDuration API
On 03/16/2012 07:11 AM, Eric Blake wrote:
On 01/26/2012 12:59 PM, Michal Privoznik wrote:
> This makes use of QEMU guest agent to implement the
> virDomainSuspendForDuration API.
> ---
> src/qemu/qemu_driver.c | 93 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 93 insertions(+), 0 deletions(-)
> +
> + if (!virDomainObjIsActive(vm)) {
> + qemuReportError(VIR_ERR_OPERATION_INVALID,
> + "%s", _("domain is not running"));
> + goto cleanup;
> + }
Same question as for quiesce: putting the guest into S3 will only work
if the agent can respond, so checking merely for active is not enough.
If the guest is active but paused, then we can't talk to the agent to
issue the request. Having the common guest agent code check for this
condition will prevent the scenario of:
guest is paused
issue the pm suspend, but it times out
Actually I encounted the problem when playing dompmsuspend,
the dompmsuspend command hangs forever, so I tried to
suspend the guest with "pm-suspend" inside guest directly,
and then dompmwakeup returns quickly with success, however,
the guest wasn't waken up actually.
So there are at least two problems here:
1) dompmsuspend hangs
2) dompmwakeup returns success, while the guest wasn't waken
up actally.
For 1), I tried to create a patch with using guest agent command
"guest-ping" to ping the guest agent first before executing the
guest-suspend-* commands, and hope it could return quickly if the
guest agent isn't available or something else which cause the guest
agent doesn't response, and thus we could quit quickly, but no luck,
the "guest-ping" hangs too.
1) could be the problem of guest-agent, while 2) might be problem
of guest kenrel. It can't be problem of guest agent, as dompmwakeup
actually uses the qemu monitor command, not guest agent command.
I didn't dig into the problems further more though, it's possible
caused by my guest agent is not setup correctly, or it's not that
newer, and has bugs. But in any case, we should handle the hanging
problem.
For anyone who wanted to reproduce the problem, the guest
is FC16.
guest is resumed
guest finally acts on command
although it is always possible that a guest will suspend itself even
without action on our part. At least this isn't as bad as a stale
quiesce leaving the guest in a bad state, since on suspend, the host
will receive a qemu event about the change in guest state (there's no
event for freeze/thaw, since that is an aspect internal to the guest's
use of disks and not something inherently visible to qemu to generate an
event from).
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list