[libvirt] [PATCH v2 4/5] qemu: Wire up virDomainSuspendForDuration API

[Osier Yang]

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 at redhat.com
> https://www.redhat.com/mailman/listinfo/libvir-list