[Qemu-devel] wiki summary

[Dor Laor]

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.

In addition, it can answer one of (justified) Barak's concerns that it 
takes too long a time to have all the stack implements commands.
Regardless, we'll want to support kind of path through verbs so we'll be 
able to execute remote WMI or Matahari commands.

>
>>     - distributable via ISO  - can you elaborate?
>
> We'd eventually like to have an analogue to virtualbox/vmware guest

Hmmm, those type-f hypervisors do not have an OS to back them up.
Unlike them, we can easily cover Linux and the ovirt project is 
supported by the major distributions. There is inherited advantage of 
relaying on the distribution for updating the agents, especially when it 
comes to security updates (will iso distribution be part of embargo 
infosec procedure now?). Imagine that bugs/flaws might be in one of your 
libraries.

> 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.

Having the (mine) above said, the ovirt-agent get pushed today by iso 
for windows, so can we call this issue a draw and remove it out from the 
discussion?

>
>>     - 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!
>>
>>
>
> _______________________________________________
> vdsm-devel mailing list
> vdsm-devel at lists.fedorahosted.org
> https://fedorahosted.org/mailman/listinfo/vdsm-devel