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

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3126 bytes --]

[adding qemu-devel]

On 01/26/2012 07:46 AM, Daniel P. Berrange wrote:
>> One thing, that you'll probably notice is this
>> 'set-support-level' command. Basically, it tells GA what qemu version
>> is it running on. Ideally, this should be done as soon as
>> GA starts up. However, that cannot be determined from outside
>> world as GA doesn't emit any events yet.
>> Ideally^2 this command should be left out as it should be qemu
>> who tells its own agent this kind of information.
>> Anyway, I was going to call this command in qemuProcess{Startup,
>> Reconnect,Attach}, but it won't work. We need to un-pause guest CPUs
>> so guest can boot and start GA, but that implies returning from qemuProcess*.
>>
>> So I am setting this just before 'guest-suspend' command, as
>> there is one more thing about GA. It is unable to remember anything
>> upon its restart (GA process). Which has BTW show flaw
>> in our current code with FS freeze & thaw. If we freeze guest
>> FS, and somebody restart GA, the simple FS Thaw will not succeed as
>> GA thinks FS are not frozen. But that's a different cup of tea.
>>
>> Because of what written above, we need to call set-level
>> on every suspend.
> 
> 
> IMHO all this says that the 'set-level' command is a conceptually
> unfixably broken design & should be killed in QEMU before it turns
> into an even bigger mess.
> 
> Once we're in a situation where we need to call 'set-level' prior
> to every single invocation, you might as well just allow the QEMU
> version number to be passed in directly as an arg to the command
> you are running directly thus avoiding this horrificness.

Qemu folks, would you care to chime in on this?

Exactly how is the set-level command supposed to work?  As I understand
it, the goal is that if the guest has qemu-ga 1.1 installed, but is
being run by qemu 1.0, then we want to ensure that any guest agent
command supported by qemu-ga 1.1 but requiring features of qemu not
present in qemu 1.0 will be properly rejected.

But whose job is it to tell the guest agent what version of qemu is
running?  Based on the above conversation, it looks like the current
qemu implementation does not do any handshaking on its own when the
guest agent first comes alive, which means that you are forcing the work
on the management app (libvirt).  And this is inherently racy - if the
guest is allowed to restart its qemu-ga process at will, and each
restart of that guest process triggers a need to redo the handshake,
then libvirt can never reliably know what version the agent is running at.

I think we really do need a mode where as soon as the qemu-ga process
exists, it sends an event, then the qemu side of the virtio bus responds
to that event by telling the agent what version of qemu is talking to
the agent, all prior to exposing any agent commands out to management
apps, thus making the qemu-ga set-level command an automatic part of the
handshake, and invisible to management apps.

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 620 bytes --]