qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communi


From: Michael Roth
Subject: Re: [Qemu-devel] [RFC][PATCH v6 00/23] virtagent: host/guest RPC communication agent
Date: Wed, 16 Feb 2011 11:22:19 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7

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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]