qemu-devel
[Top][All Lists]
Advanced

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

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


From: Eric Blake
Subject: Re: [Qemu-devel] [libvirt] [PATCH RFC 0/4] Allow hibernation on guests
Date: Mon, 30 Jan 2012 08:58:09 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111222 Thunderbird/9.0

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?

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]