[Top][All Lists]

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

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

From: Daniel P . Berrangé
Subject: Re: [Qemu-devel] [RFC PATCH 0/7] virtio-fs: shared file system for virtual machines3
Date: Wed, 12 Dec 2018 12:30:59 +0000
User-agent: Mutt/1.10.1 (2018-07-13)

On Mon, Dec 10, 2018 at 05:31:44PM +0000, Dr. David Alan Gilbert (git) wrote:
> From: "Dr. David Alan Gilbert" <address@hidden>
> 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. 

|: 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 :|

reply via email to

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