[Qemu-devel] wiki summary

[Barak Azulay]

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?  


> 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.


> >    - 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


> >    - 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. 

> 
> >    - 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.


> 
> > Thanks
> > Barak
> > 
> >> Thanks!