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

[Michael Roth <mdroth@linux.vnet.ibm.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.