From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41823) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQfnz-00070D-IW for qemu-devel@nongnu.org; Wed, 16 Nov 2011 08:45:36 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQfnt-0006Xk-16 for qemu-devel@nongnu.org; Wed, 16 Nov 2011 08:45:35 -0500 Received: from mail-iy0-f173.google.com ([209.85.210.173]:61761) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQfns-0006Xf-UI for qemu-devel@nongnu.org; Wed, 16 Nov 2011 08:45:28 -0500 Received: by iakk32 with SMTP id k32so651853iak.4 for ; Wed, 16 Nov 2011 05:45:28 -0800 (PST) Message-ID: <4EC3BE74.8000801@codemonkey.ws> Date: Wed, 16 Nov 2011 07:45:24 -0600 From: Anthony Liguori MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] converging around a single guest agent List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Ayal Baron Cc: Gal Hammer , Barak Azulay , arch@ovirt.org, qemu-devel@nongnu.org, vdsm-devel@lists.fedorahosted.org On 11/15/2011 04:39 PM, Ayal Baron wrote: > > > ----- Original Message ----- >> On 11/15/2011 11:24 AM, Barak Azulay wrote: >>> Hi, >>> >>> One of the breakout sessions during the ovirt workshop [1] was >>> about the guest >>> tools, and focused mainly on the ovirt-guest-agent [2]. >>> >>> One of the issues discussed there, was the various existing guest >>> agents out >>> there, and the need to converge the efforts to a single agent that >>> will serve >>> all. >>> >>> while 4 agents were mentioned (Matahari, vdagent, qemu-ga& >>> ovirt-guest-agent) >>> during that discussion, we narrowed it down to 2 candidates: >>> >>> qemu-ga (aka virt-agent): >>> ------------------------- >>> - Qemu specific - it was aimed for specific qemu needs (mainly >>> quiesce guest >>> I/O) >>> - Communicates directly with qemu (not implemented yet) >>> - Supports ? >>> - So far linux only >> >> But very easy to port. It also should work on just about any Unix >> since its >> only dependency is glib. Also: >> >> - exists in the QEMU repository >> >>> - written in C >>> >>> Ovirt-guest-agent: >>> ------------------ >>> - Has been around for a long time (~5 years) - considered stable >>> - Started as rhevm specific but evolved a lot since then >>> - Currently the only fully functional guest agent available for >>> ovirt >>> - Written in python >>> - Some VDI related sub components are written in C& C++ >>> - Supports a well defined list of message types / protocol [3] >>> - Supports the folowing guest OSs >>> Linux: RHEL5, RHEL6 F15, F16(soon) >>> Windows: xp, 2k3 (32/64), w7 (32/64), 2k8 (32/64/R2) >> >> The guest agent we use in QEMU exists to implement QEMU specific >> functionality. >> I think one challenge that comes up here is that the ovirt guest >> agent has a >> very different scope than the QEMU agent. The ovirt guest agent has >> a very >> ovirt-engine centric scope. >> >>> The need to converge is obvious, and now that ovirt-guest-agent is >>> opensourced >>> under the ovirt stack, and since it already produces value for >>> enterprise >>> installations, and is cross platform, I offer to join hands around >>> ovirt- >>> guest-agent and formalize a single code base that will serve us >>> all. >> >> You are basically saying, stop what you guys are doing and work on >> our code >> because it's better. That's not really convergence. >> >> If you want to talk about convergence, the discussion should start >> around >> collecting requirements. We can then figure out if the two sets of >> requirements >> are strictly overlapping or if there are any requirements that are >> fundamentally >> in opposition. > > Agreed. > > So vdsm guest agent goal is to ease administration of VMs. This is not saying much as it is quite broad so I will list what is provided today and some things we need to add: Is there a spec for the guest agent protocol? What's the current policy on compatibility? How does the guest agent protocol handle feature negotiation? Regards, Anthony Liguori