From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=60105 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PqR5O-0006i6-DD for qemu-devel@nongnu.org; Fri, 18 Feb 2011 09:13:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PqR5N-0005RO-2f for qemu-devel@nongnu.org; Fri, 18 Feb 2011 09:13:30 -0500 Received: from e5.ny.us.ibm.com ([32.97.182.145]:40699) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PqR5N-0005Lj-0H for qemu-devel@nongnu.org; Fri, 18 Feb 2011 09:13:29 -0500 Received: from d01dlp01.pok.ibm.com (d01dlp01.pok.ibm.com [9.56.224.56]) by e5.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1IDmOjP032203 for ; Fri, 18 Feb 2011 08:48:47 -0500 Received: from d01relay04.pok.ibm.com (d01relay04.pok.ibm.com [9.56.227.236]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 4241A38C85FB for ; Fri, 18 Feb 2011 09:07:52 -0500 (EST) Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d01relay04.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1IE7pvh187856 for ; Fri, 18 Feb 2011 09:07:52 -0500 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p1IE7ncw031511 for ; Fri, 18 Feb 2011 07:07:50 -0700 Message-ID: <4D5E7D35.7090207@linux.vnet.ibm.com> Date: Fri, 18 Feb 2011 08:07:49 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent References: <1295270117-24760-1-git-send-email-mdroth@linux.vnet.ibm.com> <4D5BF581.3050803@redhat.com> <4D5C07CB.4040709@linux.vnet.ibm.com> <4D5CDBD0.2060900@redhat.com> <4D5D3331.1000707@linux.vnet.ibm.com> <4D5E69EB.5040805@redhat.com> In-Reply-To: <4D5E69EB.5040805@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jes Sorensen Cc: agl@linux.vnet.ibm.com, stefanha@linux.vnet.ibm.com, markus_mueller@de.ibm.com, marcel.mittelstaedt@de.ibm.com, Michael Roth , qemu-devel@nongnu.org, ryanh@us.ibm.com, abeekhof@redhat.com, Luiz Capitulino On 02/18/2011 06:45 AM, Jes Sorensen wrote: > On 02/17/11 15:39, Michael Roth wrote: > >> On 02/17/2011 02:26 AM, Jes Sorensen wrote: >> >>> On 02/16/11 18:22, Michael Roth wrote: >>> worry is that we are adding a lot of complexity into QEMU on the host >>> side which is going to be difficult to audit, especially with things >>> like the HTML and XML processing. If we separated host side processing >>> into a separate command, we could better protect ourselves against a >>> situation where a rogue guest could kill QEMU and possibly exploit it on >>> the host side. I think we should seriously look at moving the agent >>> processing code out of main QEMU and into a standalone command, maybe >>> qemu-va-host or something like that. >>> >> I don't think the problem is really so fundamental...if you saw a >> host-side crash it's most likely a bug/sloppy error-handling in >> virtagent. Malformed xml (from version mismatches, transports errors, >> etc) shouldn't crash xmlrpc-c... it's using a libxml parser that just >> returns an error on unexpected xml...we just need to make sure we handle >> errors appropriately. >> > Hi Michael, > > It may not be so fundamental, but it still makes me wary. XMLRPC > handling is quite high level and introduces the potential of errors that > are outside of our direct control. Personally I don't see the big > benefit of having virtagent terminate in QEMU, Live migration. If it's a separate daemon, then live migration gets fugly. If xmlrpc-c is a PoS, then we ought to look at using something else. But let's understand what's happening first before drawing any conclusions. Regards, Anthony Liguori > if anything it actually > makes me wary. I would quite like to see the monitor moved out of QEMU > as well and into it's own process - the simpler we make QEMU in this > regard, the more secure it will be to run. Using either a fork() > approach or simply a separate process that connects to the QEMU process > seems a very reasonable approach IMHO. > > >> Can you provide some details on what you ran and what the error message >> was? >> > It's a bit tricky, I was running a my tests over VNC on a remote system > (think trans-Atlantic latency) while having 10 people watch while I > typed the commands. It seemed that pretty much every agent command was > causing it, including ping, but unfortunately I didn't save the backtrace. > > Cheers, > Jes > >