[Qemu-devel] Re: A new direction for vmchannel?

[Daniel P. Berrange]

On Fri, Jan 23, 2009 at 08:45:33AM -0600, Anthony Liguori wrote:
> The userspace configuration aspects of the current implementation of 
> vmchannel are pretty annoying.  Moreover, we would like to make use of 
> something like vmchannel in a kernel driver and I fear that it's going 
> to be difficult to do that.
> 
> So here's an alternative proposal.
> 
> Around 2.6.27ish, Eric and I added 9p over virtio support to v9fs.  This 
> is all upstream.  We backported the v9fs modules all the way back to 
> 2.6.18.  I have a 9p client and server library and patches available for 
> QEMU.  We were using this for a file system pass through but we could 
> also use it as a synthetic file system in the guest (like sysfs).
> 
> The guest would just have to mount a directory in a well known location, 
> and then you could get vmchannel like semantics by just opening a file 
> read/write.  Better yet though would be if we actually exposed vmchannel 
> as 9p so that management applications could implement sysfs-like 
> hierarchies.
> 
> I think there could be a great deal of utility in something like.  For 
> portability to Windows (if an app cared), it would have to access the 
> mount point through a library of some sort.  We would need a Windows 
> virtio-9p driver that exposed the 9p session down to userspace.  We 
> could then use our 9p client library in the portability library for Windows.
> 
> Virtually all of the code is available for this today, the kernel bits 
> are already upstream, there's a reasonable story for Windows, and 
> there's very little that the guest can do to get in the way of things.
> 
> The only thing that could potentially be an issue is SELinux.  I assume 
> you'd have to do an SELinux policy for the guest application anyway 
> though so it shouldn't be a problem.

For use cases where you are exposing metadata from the host to the guest
this would be a very convenient approach indeed. As asked elsewhere in this
thread, my main thought would be about how well it suits a application that
wants a generic stream based connection between host & guest ? Efficient 
integration into a poll(2) based event loop would be key to that. Regular
files don't offer that kind of ability ordinarily, and not clear whether 
fifo's would be provided for in p9fs between host/guest ?

In any case, if we have a usable p9fs backend for QEMU, I don't see why we 
shouldn't integrate that in QEMU, regardless of whether it serves the more 
general vmchannel use cases. Sharing filesystems is an interesting idea in
its own right after all. 

I also really don't like guest deployment / configuration complexity that
is accompanying the NIC device based vmchannel approach. There are just 
far too many things that can go wrong with it wrt the guest OS & apps using
networking. IMHO, the core motivation of vmchannel is to have a secure 
guest <->  host data transport that can we relied upon from the moment 
guest userspace appears, preferrably with zero guest admin configuration
requirements, and no need for authentication keys to establish guest 
identity. UNIX domain sockets are a great example of this ideal, providing 
a reliable data stream for the localhost before network makes any appearance,
with builtin client authentication via SCM_CREDS.

Regards,
Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|