[libvirt] [PATCH 6/9] conf: qemu: add virtio-fs fsdriver type

Ján Tomko jtomko at redhat.com
Wed Nov 20 08:38:15 UTC 2019


On Mon, Nov 04, 2019 at 09:56:28AM +0100, Stefan Hajnoczi wrote:
>On Fri, Nov 1, 2019 at 1:15 PM Ján Tomko <jtomko at redhat.com> wrote:
>>
>> Introduce a new 'virtio-fs' driver type for filesystem.
>>
>> <filesystem type='mount' accessmode='passthrough'>
>>   <driver type='virtio-fs'/>
>>   <source dir='/path'/>
>>   <target dir='/path'/>
>
>What happens with the target dir?
>

For virtio-fs, it is used the same way as with 9pfs - it is passed as
the tag and meant as a suggestion for the guest for where to mount the
filesystem.

For LXC, libvirt actually does the mounting so the target dir path is
honored.

I could use some other example in the documentation that does not look
as a path if that's too confusing. I'm not sure whether deviating
from the existing pattern and using something like:
  <target tag='myfs'/>
is worth it.

>virtio-fs has no way to pass the target dir into the guest.

Also, I see that the mount syntax changed from -t virtio_fs to -t
virtiofs - is that the new preferred spelling that should be preserved
here?

>Out-of-band methods exist: qemu-guest-agent could be used to mount the
>file system.

Doing that automatically is out of scope of libvirt. But to allow higher
layers to do that, libvirt would need to expose the 'guest-exec'
command.

Jano

>Another approach is to add a uevent to the virtiofs.ko
>guest driver and let udev configuration decide what to do (e.g.
>automount under /run/media/virtio-fs/$TAG or similar).
>
>Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20191120/5d6858b9/attachment-0001.sig>


More information about the libvir-list mailing list