[Qemu-devel] wiki summary

[Adam Litke]

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 <agl at us.ibm.com>
IBM Linux Technology Center