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

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?