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.
- 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
address@hidden
https://fedorahosted.org/mailman/listinfo/vdsm-devel