From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:53454) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQS1H-0006iP-Ss for qemu-devel@nongnu.org; Tue, 15 Nov 2011 18:02:27 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RQS1D-0004dc-PB for qemu-devel@nongnu.org; Tue, 15 Nov 2011 18:02:23 -0500 Received: from e4.ny.us.ibm.com ([32.97.182.144]:33563) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RQS1D-0004dR-LW for qemu-devel@nongnu.org; Tue, 15 Nov 2011 18:02:19 -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 ; Tue, 15 Nov 2011 18:02:16 -0500 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id pAFN1BAZ232426 for ; Tue, 15 Nov 2011 18:01:13 -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 pAFN11pQ029824 for ; Tue, 15 Nov 2011 16:01:01 -0700 Message-ID: <4EC2EF2C.7010100@linux.vnet.ibm.com> Date: Tue, 15 Nov 2011 17:01:00 -0600 From: Michael Roth MIME-Version: 1.0 References: <201111151924.41357.bazulay@redhat.com> In-Reply-To: <201111151924.41357.bazulay@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; 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: Barak Azulay Cc: Gal Hammer , arch@ovirt.org, qemu-devel@nongnu.org, vdsm-devel@lists.fedorahosted.org 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) Won't be implemented until we finish the QMP conversion to QAPI since that's a prereq to implementing a QMP server with proper async support (needed for communication with a potentially non-responsive guest agent). But once it's in guest extensions are completely transparent to QMP/libvirt, which is highly desirable from a management perspective since you're coding against a single API/transport. > - Supports ? Documented in qemu.git/qapi-schema.json: mdroth@illuin:~/w/qemu.git$ grep command qapi-schema-guest.json # Such clients should also preceed this command { 'command': 'guest-sync' { 'command': 'guest-ping' } { 'command': 'guest-info', { 'command': 'guest-shutdown', 'data': { '*mode': 'str' } } { 'command': 'guest-file-open', { 'command': 'guest-file-close', { 'command': 'guest-file-read', { 'command': 'guest-file-write', { 'command': 'guest-file-seek', { 'command': 'guest-file-flush', { 'command': 'guest-fsfreeze-status', { 'command': 'guest-fsfreeze-freeze', { 'command': 'guest-fsfreeze-thaw', There's a wiki page with additional details: > - So far linux only Windows port is *almost* there. I have patches to build/run it on windows but there are some remaining bugs, and guest-fsfreeze* and guest-shutdown* are gonna need windows-specific command implementations. > - 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) > In terms of completeness/support for ovirt (and node/cluster-level management frameworks in general), the ovirt-guest-agent certainly seems like a win. The main problem with convergence within the qemu space is that we can't have guest extensions to qemu-driven guest events like, say, hotplug or shutdown be managed by an external agent: the functionality, specificity, and assurances required are not things that are necessarily suited for ovirt-guest-agent; the scope is very different. And the same holds true in the other direction: I don't, personally at least, foresee qemu-ga ever doing things like providing a list of logged in users on a system or handling SSO, though if there are those who'd like to take qemu-ga in that direction I think that's fine. But practically-speaking, it's unavoidable that qemu-specific management tooling will need to communicate with qemu (via QMP/libqmp/HMP/etc, or by proxy via libvirt). It's through those same channels that the qemu-ga interfaces will ultimately be exposed, so the problem of qemu-ga vs. ovirt-guest-agent isn't really any different than the problem of QMP's system_powerdown/info_balloon/etc vs. ovirt-guest-agent's Shutdown/Available_Ram/etc: it's a policy decision rather than argument for choosing one project over another. > > 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. > > git @ git://gerrit.ovirt.org/ovirt-guest-agent > > Thoughts ? > > Thanks > Barak Azulay > > [1] http://www.ovirt.org/news-and-events/workshop > [2] http://www.ovirt.org/wiki/File:Ovirt-guest-agent.odp > [3] http://www.ovirt.org/wiki/Ovirt_guest_agent >