Re: [Qemu-devel] [RFC PATCH 0/7] virtio-fs: shared file system for virtual machines3

["Daniel P. Berrangé" <berrange@redhat.com>]

On Wed, Dec 12, 2018 at 01:52:03PM +0000, Dr. David Alan Gilbert wrote:
> * Daniel P. Berrangé (berrange@redhat.com) wrote:
> > On Mon, Dec 10, 2018 at 05:31:44PM +0000, Dr. David Alan Gilbert (git) wrote:
> > > From: "Dr. David Alan Gilbert" <dgilbert@redhat.com>
> > > 
> > > Hi,
> > >   This is the first RFC for the QEMU side of 'virtio-fs';
> > > a new mechanism for mounting host directories into the guest
> > > in a fast, consistent and secure manner.  Our primary use
> > > case is kata containers, but it should be usable in other scenarios
> > > as well.
> > > 
> > > There are corresponding patches being posted to Linux kernel,
> > > libfuse and kata lists.
> > > 
> > > For a fuller design description, and benchmark numbers, please see
> > > Vivek's posting of the kernel set here:
> > > 
> > > https://marc.info/?l=linux-kernel&m=154446243024251&w=2
> > > 
> > > We've got a small website with instructions on how to use it, here:
> > > 
> > > https://virtio-fs.gitlab.io/
> > > 
> > > and all the code is available on gitlab at:
> > > 
> > > https://gitlab.com/virtio-fs
> > > 
> > > QEMU's changes
> > > --------------
> > > 
> > > The QEMU changes are pretty small; 
> > > 
> > > There's a new vhost-user device, which is used to carry a stream of
> > > FUSE messages to an external daemon that actually performs
> > > all the file IO.  The FUSE daemon is an external process in order to
> > > achieve better isolation for security and resource control (e.g. number
> > > of file descriptors) and also because it's cleaner than trying to
> > > integrate libfuse into QEMU.
> > 
> > Overall I like the virtio-fs architecture more than the virtio-vsock+NFS
> > approach, as virtio-fs feels simpler and closer to virtio-9p with the
> > latter's proxy backends.
> > 
> > I never really liked the idea of having to mess around with the host
> > NFS server to exposed filesystems to guests, as that's systemwide
> > service.  The ability to have an isolated virtio-fs backend process
> > per filesystem share per guest is simpler from a mgmt pov.
> > 
> > One think I would like to see though is a general purpose, production
> > quality backend impl that is shipped by the QEMU project.  It is fine
> > if projects like Kata want to write a custom impl tailored to their
> > specific needs, but I think QEMU should have something as standard that
> > isn't just demoware. 
> 
> Our patches sent to libfuse may provide that - after we tidy them up a
> bit more; but it is the result of adding the fuse example code to qemu's
> contrib vhost-user example code.    Given that this is the intersection
> of so many projects I'm not sure I care which project distributes a
> working implementation.

Right, but that's my point - the stuff in QEMU's contrib/ directories is
just demoware - not something we actually support as QEMU maintainers,
nor expect users to run in production. Likewise for stuff in libfuse
example/ directory AFAIK.

IMHO we need something whose support status is on a par with what you'd
get if we had the impl in-process for the main QEMU system emulator.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|