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