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:
>> 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:
> - 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:
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
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
> - 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
vdsm-devel mailing list