* Daniel P. Berrangé (berra...@redhat.com) wrote: > On Mon, Dec 10, 2018 at 05:31:44PM +0000, Dr. David Alan Gilbert (git) wrote: > > From: "Dr. David Alan Gilbert" <dgilb...@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. Dave > 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 :| -- Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
