Re: [Qemu-devel] [libvirt] [PATCH RFC 0/4] Allow hibernation on guests

[Michael Roth <mdroth@linux.vnet.ibm.com>]

On 01/30/2012 09:58 AM, Eric Blake wrote:
> On 01/30/2012 07:44 AM, Luiz Capitulino wrote:
>> I think we should do the following then:
>>
>>   1. Drop the set-support-level command
>>   2. Split the guest-suspend command into guest-suspend-ram, guest-suspend-hybrid,
>>      guest-suspend-disk
>>   3. Libvirt should query for _QEMU_'s 'wakeup' command before issuing
>>      the guest-suspend-ram command
>>
>> Michal, Michael, do you agree?
>
> I'm not Michal, but speaking for libvirt, this definitely sounds like
> the way to go.
>
> Questions:
>
> Should libvirt also check for 'wakeup' before attempting
> guest-suspend-hybrid?
>
> With guest-suspend-disk, what happens when the suspend completes?  Does
> this look like a normal case of the guest powering down, which qemu then
> passes as an event to libvirt and libvirt then ends the qemu process?
> That would mean that the only difference from a normal guest shutdown is
> that on the next guest boot the guest's disk image allows to recover
> state from disk rather than booting from scratch; either way, a new qemu
> process is created to resume the guest, and qemu is doing nothing
> different in how it starts the guest (it's just that the guest itself
> does something different based on what it stored into the disk images
> before shutting down).
>
> Also, I know there has been talk about a qemu-ga command to resync
> clocks after a resume from S3 and/or 'loadvm'; is this command fully in
> place yet, and is it another command that libvirt should be checking for
> prior to allowing any S3 attempts?
>

Hi Eric,

I'm not aware of a clock re-sync command being worked on.. are we maybe 
talking about the guest-sync command qemu-ga currently has in place to 
re-sync the protocol stream after a client-side timeout?