qemu-devel
[Top][All Lists]
Advanced

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

Re: [PATCH v2 00/20] block/export: Allow exporting BDSs via FUSE


From: Stefan Hajnoczi
Subject: Re: [PATCH v2 00/20] block/export: Allow exporting BDSs via FUSE
Date: Wed, 23 Sep 2020 10:08:19 +0100

On Tue, Sep 22, 2020 at 04:58:38PM +0100, Daniel P. Berrangé wrote:
> On Tue, Sep 22, 2020 at 12:49:12PM +0200, Max Reitz wrote:
> > Based-on: <20200907182011.521007-1-kwolf@redhat.com>
> >           (“block/export: Add infrastructure and QAPI for block exports”)
> > 
> > (Though its patch 16 needs a s/= \&blk_exp_nbd/= drv/ on top.)
> > 
> > v1: https://lists.nongnu.org/archive/html/qemu-block/2019-12/msg00451.html
> > 
> > Branch: https://github.com/XanClic/qemu.git fuse-exports-v2
> > Branch: https://git.xanclic.moe/XanClic/qemu.git fuse-exports-v2
> > 
> > 
> > Hi,
> > 
> > Ever since I found out that you can mount FUSE filesystems on regular
> > files (not just directories), I had the idea of adding FUSE block
> > exports to qemu where you can export block nodes as raw images.  The
> > best thing is that you’d be able to mount an image on itself, so
> > whatever format it may be in, qemu lets it appear as a raw image (and
> > you can then use regular tools like dd on it).
> > 
> > The performance is quite bad so far, but we can always try to improve it
> > if the need arises.  For now I consider it mostly a cute feature to get
> > easy access to the raw contents of image files in any format (without
> > requiring root rights).
> 
> Aside from the iotests, so you forsee any particular use cases
> where this feature is desirable / important ?

Alice Frosi is working on a qemu-storage-daemon-based project where the
FUSE export type is useful. In this case qemu-storage-daemon is used
stand-alone without a guest or libvirt directly involved. The goal is
just to export disk images and how they are consumed is the user's
responsibility (processes, containers, guests).

> Looking at it from a security POV, I'm not thrilled about the
> idea of granting QEMU permission to use the mount syscall for
> seccomp or SELinux. IOW, I expect this feature won't be something
> we want to expose in QEMU guests managed by libvirt, which would
> limit how widely it can be used.

I have CCed Miklos Szeredi, the Linux FUSE maintainer, to check what the
options are for unprivileged mounting of a FUSE file system:

1. libfuse invokes open("/dev/fuse") + mount()
2. libfuse spawns the fusermount3 suid root helper
3. Any other options? D-Bus? etc

> QEMU can export NBD. Would it make sense to do this as an NBD
> client ? There's already https://libguestfs.org/nbdfuse.1.html
> but IIUC that exposes it as a file within a dir. Presumably
> it is not too hard to make it support exposing it directly as
> a file too.
> 
> I wonder how performance compares between your native FUSE
> impl in QEMU vs NBD FUSE ?

NBD exports are useful for networks but shouldn't preclude other export
types from being merged just because they can be implemented on top of
NBD. Native export types are simpler to manage and have less performance
overhead than stacking additional tools on top of NBD.

Stefan

Attachment: signature.asc
Description: PGP signature


reply via email to

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