[Qemu-devel] wiki summary

[Dor Laor]

On 11/25/2011 12:07 PM, Daniel P. Berrange wrote:
> On Thu, Nov 24, 2011 at 02:40:07PM +0200, Dor Laor wrote:
>> On 11/17/2011 09:58 PM, Michael Roth wrote:
>>> On 11/17/2011 10:34 AM, Barak Azulay wrote:
>>>> On Thursday 17 November 2011 02:48:50 Michael Roth wrote:
>>>>> I've tried to summarize the pros/cons, points, and proposals outlined in
>>>>> this thread at the following wiki:
>>>>>
>>>>> http://www.ovirt.org/wiki/Guest_agent_proposals
>>>>>
>>>>> Please feel free to add/edit as needed. If you don't have an account on
>>>>> ovirt.org let me know.
>>>>>
>>>>
>>>> Thanks Michael, it's a good start.
>>>>
>>>>
>>>> A few questions about the qemu-ga's requirements:
>>>>
>>>> #1
>>>>     - same repo ? why is this a requirement ?
>>>
>>> Or git submodule. Main reasons are that integration with QMP requires
>>> that qemu be able to generate marshaling code from a guest agent schema
>>> definition of commands/parameters, and that qemu needs to be able to
>>> consume guest agent extensions internally. A few examples that came up
>>> in this thread were opening new virtio-serial channel via agent calls,
>>> and registering device callbacks/driving state machine changes for guest
>>> agent events. Since we'd like to pursue a push-deployment model where
>>> QEMU can deploy a specific, compatible version of the agent to a
>>> bootstrapped guest (qemu-ga pre-installed via guest distro or ISO
>>> package), having code changes in-sync with repo would be necessary.
>>>
>>> VMware has a similar model for handling guest tools upgrades, where the
>>> hypervisor pushes upgrades based on host hypervisor level:
>>>
>>> http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1008907
>>>
>>> The alternative is strict APIs with backward-compatibility with
>>> down-level agents, which complicates things tremendously on the QEMU
>>> side, and pretty much everywhere in the stack. Just keeping libvirt in
>>> sync with QMP has proven difficult and that's just on the host, with a
>>> common distro and fairly close development communities. Extending this
>>> kind of synchronization out to multiple guest distros with varying
>>> levels of guest agents makes this far harder.
>>
>> Using QMP is an advantage, I agree.
>> However it can be used by another option - move the QMP schema out
>> of qemu.git so all projects like libvirt, agents, vdsm, etc will be
>> able to consume it directly.
>>
>> This way, adding a new (agent) command will immediately propagate to
>> all of the stack instead of each component to implement it
>> differently (while it would still be possible).
>> That's what libguestfs scheme do today.
>
> That kind of idea doesn't really help much in practice, because it is
> presuming that the API you want to expose is identical at every level
> in the stack. If that were really the case, then you wouldn't really
> have different levels in the stack in the first place. An API exposed
> at the libvirt level may well map to multiple API calls at the QEMU
> level, and and API call at the VDSM level may map to multiple API
> calls at the libvirt level, etc.
>
> libguestfs is doing something different here - they have one API and
> they are exposed that API, at the same level of granularity in other
> languages. That is very different from stacking APIs with different
> levels of abstraction. When you're stacking APIs you cannot avoid the
> fact that you need to create a design that is suitable for the level
> of abstraction you need at each layer.

You're right, but Barak's concern was that each new command will now 
need to be represented differently by each API in the stack. That's 
cause a significant slow down of the development cycle.

While we should keep have a rich and different API in the various layers 
(agent, qmp, libvirt, vdsm,..), we can use a QMP pass through mode for 
others. Some times this is tricky, and one command generated by layer x 
might contradict another created by layer y. In the agent case, it can 
utilized in most cases since most commands are read-only.

QMP/qAPI is a stable api and all layers in the stack can relay on it. 
Libvirt passes it through as well as you know :)

Again, some commands like fs-freeze shouldn't be pass through-ed but 
plenty of others like mem info, fs content, app list, etc can be used.

>
> Regards,
> Daniel