From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=49028 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ppl5C-0001f5-OG for qemu-devel@nongnu.org; Wed, 16 Feb 2011 12:22:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ppl5B-0002Gw-G4 for qemu-devel@nongnu.org; Wed, 16 Feb 2011 12:22:30 -0500 Received: from e4.ny.us.ibm.com ([32.97.182.144]:46750) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ppl5B-0002Gl-DP for qemu-devel@nongnu.org; Wed, 16 Feb 2011 12:22:29 -0500 Received: from d01relay03.pok.ibm.com (d01relay03.pok.ibm.com [9.56.227.235]) by e4.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id p1GH3gP5015871 for ; Wed, 16 Feb 2011 12:03:42 -0500 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay03.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p1GHMROe179616 for ; Wed, 16 Feb 2011 12:22:27 -0500 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p1GHMQlG000501 for ; Wed, 16 Feb 2011 12:22:27 -0500 Message-ID: <4D5C07CB.4040709@linux.vnet.ibm.com> Date: Wed, 16 Feb 2011 11:22:19 -0600 From: Michael Roth 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> In-Reply-To: <4D5BF581.3050803@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, qemu-devel@nongnu.org, aliguori@linux.vnet.ibm.com, ryanh@us.ibm.com, abeekhof@redhat.com On 02/16/2011 10:04 AM, Jes Sorensen wrote: > On 01/17/11 14:14, Michael Roth wrote: >> These patches apply to master (1-14-2011), and can also be obtained from: >> git://repo.or.cz/qemu/mdroth.git virtagent_v6 >> >> CHANGES IN V6: >> >> - Added a sentinel value to reliably detect the start of an "http" hdr. Used to skip past partially sent http content from previous "sessions" >> - Added http hdr tag (currently hardcoded for testing, will switch to uuid) to filter out valid-but-unexpected content in channel from previous "sessions" >> - Added timeout mechanism to avoid hanging monitor when agent isn't running >> - Added timed back-off on read's from a virtio-serial that result in ret=0 to avoid spinning if host isn't connected. >> - Added daemonize flags to qemu-va >> - Added sane defaults for channel type and virtio-serial port path >> - Various bug fixes for state machine/job handling logic >> > > Hi Michael, > > I was running some testing here of virtagent and demoing it to some of > my colleagues and ran into a problem that raised an interesting question. > > My test system was an older Fedora 11 system, which meant I had to > rebuild qemu, while I kept my test image and the qemu-va binary that I > had built on a Fedora 14 system. > > What happened was that either due to the differences in platform, or > maybe due to lag in updating the windows over vnc, agent commands would > end up crashing qemu on the host. I am not sure whether this was due to > timeouts or incompatibility of the libraries, however the question > raised is whether it is good security wise to pull XMLRPC processing > into QEMU this way? Instead maybe it would be better to move it out into > it's own process that uses virtio-serial through QEMU for it's > communication? > > In addition I think we need to consider a mechanism to make sure that > the host and guest side are really compatible. > > Just a few things to consider. > > Cheers, > Jes Resending due to mail delivery failure: Hi Jes, We've seen similar behavior. I think it comes down to qemu-va being linked against shared objects in the host that don't necessarily coincide with what's in the guest. It's somewhat misleading that we currently build qemu-va along with the binary, since qemu-va is not meant to be used on the host, and the version built on the host is not meant to be used in the guest. Really the guest binary, qemu-va, should be built in a proper build environment for that particular guest. Long term it may make sense to have a "guest-utils" target that isn't part of the normal host-build process to reflect binaries with these kinds of requirements. For now I think we'll may just end up removing qemu-va from the default make target, and only build it explicitly with "make qemu-va". Thanks, Mike P.S. Hoping to have the execute-RPCs-in-seperate-threads work done soon so we can get back to integrating your patches.