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

[Anthony Liguori]

On 01/26/2012 01:35 PM, Luiz Capitulino wrote:
> On Thu, 26 Jan 2012 08:18:03 -0700
> Eric Blake<eblake at redhat.com>  wrote:
>
>> [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.
>
> Can you elaborate on this? Michal and I talked on irc about making the
> compatibility level persistent, would that help?
>
>>> 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.
>
> Not exactly, the default support of qemu-ga is qemu 1.0. This means that by
> default qemu-ga will only support qemu 1.0 even when running on qemu 2.0. This
> way the set-support-level command allows you to specify that qemu 2.0 features
> are supported.

Version numbers are meaningless.  What happens when a bunch of features get 
backported by RHEL such that qemu-ga 1.0 ends up being a frankenstein version of 
2.0?

The feature negotiation mechanism we have in QMP is the existence of a command. 
  If we're in a position where we're trying to disable part of a command, it 
simply means that we should have multiple commands such that we can just remove 
the disabled part entirely.

Regards,

Anthony Liguori