On Fri, Nov 18, 2011 at 01:25:04PM +0200, Barak Azulay wrote: > On Thursday 17 November 2011 21:58:03 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. > > > > Does it mean that every time we need to add a new feature to ovirt (which may > require new API call), we'll have to wait for the appropriate qemu & libvirt > release?
No, since qemu-ga is built around primitives you will be able to build nearly anything you want on top of the basic read/write/exec (or plugin) architecture. > > 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=di > > splayKC&externalId=1008907 > > > > > This is a very good feature (which we have discussed in past many times), but > I don't think it has something to do with guest-agent being in the same repo > with qemu. > > > > 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. > > > > > This is exactly my concern about having to pass everything through libvirt & > qemu. > I'm sure we will not catch all the things we need right from the start, there > for we'll have to delay features till they are in qemu & libvirt. See above. This underscores the need for an agent that implements a low level API. > > > - 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. > > > > > Actually we have this solution already active in ovirt for windows guests, > for > linux guests we had assumed that every distro has it's own updates mechanism > (network dependant), but adding support for various linux distros is very > easy. I'll be more than happt to elaborate if needed. > > Again I don't think it's a requirement from the guest agent (or qemu) but > from > a much higher level management system I disagree. Many people use KVM today outside the realm of a "much higher level management system". I run VMs on my laptop and in this environment we still need a way to deploy guest tools easily. I would like to use a mechanism that is the same for all of my guests. This means using the tried and tested model employed by other prominent, easy to use hypervisors -- a host-supplied guest tools ISO. > > > - 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. > > > 1 - We have had such functionality in the ovirt-guest-agent and removed it > becuase of security (BTW it's very easy to add it back) > > 2 - it's not about trusting qemu, it's about trusting who ever use such an > API, meaning: that eventually there is a management system with lots of users > and permissions that allow to use this api, so the exposure is much much > bigger than just to qemu itself. keep in mind that I qemu only supply the > APIs, i find it hard to believe that it will acually do some upgrade logic on > it's own. The security problems are addressable (via auditing, guest and host side controls, etc). And as far as upgrade goes, making the agent a part of qemu will actually help. The monitor will have two APIs: one to check if a guest agent as installed and query capabilities/version (already present), and another to present a guest-tools ISO to the guest for installation/upgrade. With these two host-side APIs in place, it will be possible to provide a trivial guest-tools-upgrader that could be run when the guest tools iso is updated on the host. > > > > > > - 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. > > Hence my concern above, about having to pass every new API through qemu & > libvirt will slow down features drastically. I am sure your sentiment is shared by non-oVirt users who would now need to implement low-level guest agent features in an unrelated software stack. I think we need a separation of responsibility. Low-level general purpose agent functionality should be built into a hypervisor (qemu) API which should be consumable by higher level management systems in a natural way. -- Adam Litke <a...@us.ibm.com> IBM Linux Technology Center
