Re: [Qemu-devel] Looking for an easy way to exchange data bidirectional between host and guest (including some suggestion)

["John R. Hogerhuis" <jhoger@pobox.com>]

On Wed, 2005-06-08 at 00:15 +0200, Henrik Nordstrom wrote:
> On Mon, 6 Jun 2005, John R. Hogerhuis wrote:
> 
> > I can think of some reasons for a non-native file service that is
> > instead built into QEMU:
> 
> vvfat?
> 
> > e) Scripts to be used across farms of QEMU virtual machines will have
> > more commonalities even across different OSes. The event and content of
> > a file popping up on a machine in a given directory is a very basic form
> > of inter-process communication common in business operations.
> 
> Using something like vvfat for bi-directional IPC would be a very bad 
> move. Most guests doesn't guarantee data written on a local drive gets 
> commited to the drive in a timely fashion (can be anywhere from seconds to 
> many minutes before the data is actually written).
> 

For the kind of thing I'm referring to is not usually very time
critical. The resolution is on the order of 15 to 30 minutes to an
hour... some stores get polled for data, the accounting system imports
the data and generates some reports which feed into other systems, etc.
Nothing particularly time critical.

Often you have a process which comes through periodically polling for
files. And it's usually not bidirectional communication but I don't know
if that matters much. You are alluding to the problem with these
approaches of two different processes acting like they own the virtual
hardware. The only thing that can make it work is that in reality QEMU
actually owns the virtual drive, and just needs to present a clear
illusion to the guest that it is so. If some rules are followed by the
guest it is possible without any difficulty to write without stepping on
the guest's toes. For example if an entire drive or partition were made
read-only to the guest that would solve the problem. Without that
assumption it gets more complex depending on the file system type and
how the os treats it.

But certainly I agree it is an inherently difficult problem.

> Even if vvfat can provide what to the guest looks like FAT block 
> device access to a directory of files on the host the directory must not 
> be touched in any manner while qemu is accessing it. Providing this kind 
> of emulation is complex enough as it is.
> 
> What vvfat does is that it emulates a FAT formatted block device from a 
> directory of files on the host. Currently this emulation is read-only 
> (mostly) but it is moving towards read-write access which will when 
> completed allow the guest to not only read the files but also write new 
> content. But it is important to understand that write access is far from 
> trivial. The vvfat driver have to piece together the block level writes 
> performed by the guest and reconstruct the filestructure to know what 
> files to map this to on the host. It is not like the guest tells vvfat 
> which file it is writing to.

Of course, if I understand what you are saying it doesn't have to tell
vvfat though... all events pass through QEMU so you have a place to hook
events and there's no polling involved. The more stupid the guest's file
structure, the more feasible such a solution becomes. "Open/create" and
"write" and "seek" should be possible to recover, efficiently even, if
you maintain a hash table or other data structure which lets you go from
block # to file (or block # to free space).

I guess the event you would be missing is "close," but a idle timeout is
probably a decent heuristic. Also if the file is locked, that would have
to be mimiced.

-- John.