[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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



On Mon, 30 Jan 2012 11:07:10 -0600
Michael Roth <mdroth linux vnet ibm com> wrote:

> 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?

Yes.

> > 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?

Yes.

> > 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).

Exactly.

> > 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?

I've heard some conversations about doing what Eric is saying, but I don't
have any details either.

Eric, do you know whom is assigned to work on that on the qemu side?


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]