[Qemu-devel] wiki summary

[Michael Roth]

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.

>    - distributable via ISO  - can you elaborate?

We'd eventually like to have an analogue to virtualbox/vmware guest 
tools, which ship with the hypervisor and can be deployed in a guest via 
an ISO made available in the guest as a cdrom when push-deployment isn't 
an option (guest doesnt already have some version of an agent with 
upgrade support installed). This is to avoid limiting support to 
specific distros due to lack of available packages in guest repo.

>    - upgradeable via hypervisor push - by the title it sounds like it belongs
>      to deployment, which sounds to me like it belongs to a higher management
>      level

We'd like ability to push to be available all throughout the stack. If 
device X has a callback for event Y, which is only available via version 
Z of the guest agent, we're now reliant on layers far higher up the 
stack to enable low-level functionality that's beneficial at all levels.

>
> #3 a few questions come up when I read it:
>    - some may consider those primitives as a security breach

s/some/virtually everyone/ :) Yes, this is a problem that'll need to be 
addressed. But at the end of the day, QEMU/host *must* be trusted if 
there's so be any pretense of security, since we have access to 
everything at the end of the day. Additionally, VMware has been 
successfully leveraging guest file access, automatic upgrades of guest 
tools, and exec functionality for quite some time now.

That's not to say we don't need to examine the implications closely, but 
there's precedence.

>    - I understand the motivation of being able to do everything on the guest
>      (exe) but we need to keep in mind it's various guest OSs, and it means
>      that there should be a script for every OS type. to me the option of
>      having a well defined interface is much more appealing

Agreed, and we should strive for that. But rarely is an interface 
designed so well that it never needs to change, and however well-defined 
it may be, it will grow with time and that growth entails deploying new 
guest code.

>
> Thanks
> Barak
>
>> Thanks!
>
>