From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:33811) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RRPBu-0005SN-2K for qemu-devel@nongnu.org; Fri, 18 Nov 2011 09:13:22 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RRPBp-0004sU-N8 for qemu-devel@nongnu.org; Fri, 18 Nov 2011 09:13:18 -0500 Received: from e4.ny.us.ibm.com ([32.97.182.144]:39942) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RRPBp-0004ry-JC for qemu-devel@nongnu.org; Fri, 18 Nov 2011 09:13:13 -0500 Received: from /spool/local by e4.ny.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 18 Nov 2011 09:13:05 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pAIEAQAQ234082 for ; Fri, 18 Nov 2011 09:10:27 -0500 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id pAIEALwm005793 for ; Fri, 18 Nov 2011 07:10:21 -0700 Date: Fri, 18 Nov 2011 08:10:09 -0600 From: Adam Litke Message-ID: <20111118141009.GQ2726@us.ibm.com> References: <201111151924.41357.bazulay@redhat.com> <201111171834.48040.bazulay@redhat.com> <4EC5674B.30807@linux.vnet.ibm.com> <201111181325.05439.bazulay@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201111181325.05439.bazulay@redhat.com> Subject: Re: [Qemu-devel] wiki summary List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Barak Azulay Cc: Gal Hammer , vdsm-devel@lists.fedorahosted.org, arch@ovirt.org, qemu-devel@nongnu.org, Michael Roth 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 IBM Linux Technology Center