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

[Michal Privoznik]

On 16.03.2012 07:52, Osier Yang wrote:
> 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.

This was my approach as well:

https://www.redhat.com/archives/libvir-list/2012-February/msg00055.html

Although I've used waiting with timeout; therefore making any fail
harmless. Because if we timeout on guest-sync which doesn't change the
state of guest, we don't issue any subsequent state-changing command.

I should reorder my TODO list and post the patch again. The sooner the
better.