Re: [Qemu-devel] wiki summary

[Michael Roth]

On 11/18/2011 05:25 AM, 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?

Exactly the opposite if you deploy ovirt functionality using Adam's 
proposal (use qemu-ga to deploy/exec ovirt scripts in guest via ovirt 
management layer, we could potentially provide a higher-level mechanism 
to simplify the process:

for instance:

`guest-script-exec script_name <args> <optional_localpath_to_script>`

for instance, that'll push the latest version of the script to some 
standard location in the guest if it's not present in the guest, or the 
md5sum doesn't match the host version, then exec it. I think, since 
you're already using JSON, we could embed the JSON requests/responses 
via using a special case `guest-script-exec-json` call so the parsing is 
virtually transparent on your end.

libvirt/qemu/qmp would only need to be aware of the primitives, you can 
extend your guest agent functionality simply by updating the scripts 
available to your management tooling on the host.

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

To be beneficial from a development/integration perspective, the host 
level would need to be kept in sync with the guest agent level, same 
repo or git submodule is the best way to handle this.

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

Not with Adam's proposal. It's something we're specifically trying to 
avoid as well and was a core design goal for qemu-ga: make QMP/libvirt 
aware of low-level primitives, let higher level tooling build 
higher-level interfaces/functionality from those. QMP/libvirt do not 
need to be made aware of your changes, though with some work, we could 
potentionally utilize your agent functionality at those levels as well 
(something like the guest-script-exec-json I mentioned above)

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

We need to consider low-level requirements: virtio drivers for instance, 
and guest extensions that integrate closely with QEMU itself. QEMU needs 
to be useable in and of itself: relying on high-level management tools 
to package/deploy low-level drivers does nothing for someone who's 
trying to fire up QEMU via command-line and poke at it via QMP.

Ideally we'd have a qemu-guest-tools ISO that a stack can be built on 
from QEMU on up rather than an ovirt-guest-tools ISO that leaves QEMU 
crippled when used in isolation. We've shown how a qemu-guest-tools ISO 
can be used to build arbitrarily complex functionality higher up the 
stack while still servicing low-level, QEMU-internal functionality. 
That's not to say it couldn't be done with ovirt-guest-tools, but to me 
it seems like a much more natural/extensible approach than having QEMU 
internally reliant on something way higher up the stack.

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

Agreed. But QMP access in general should be considered root access to a 
guest: we can reboot, poke at registers, memory, etc, so guest-exec 
support is not a particularly special case in that regard. What matters 
is how you expose that functionality higher up the stack. And that's 
what will need to be assessed.

> APIs, i find it hard to believe that it will acually do some upgrade logic on
> it's own.

A particular version of QEMU will know what particular version of the 
guest agent it was coded against (ideally, the version it shipped with). 
The only logic required beyond that it someone typing 
"guest-update-agent" at a QMP console, or perhaps some lower-level image 
authoring tool injecting the code via kickstart/libguestfs/etc.

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

We've shared the same concerns from day one: qemu-ga is actually a 
mechanism to avoid this: keep the default agent low-level and simple, 
build APIs on top of it that, above the libvirt/qemu-ga/QMP layers. If 
it's a common, generally-useful interface, pull it into qemu-ga proper, 
and expose it at the QMP layer.

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