Introduce a new 'virtio-fs' driver type for filesystem.
<filesystem type='mount' accessmode='passthrough'>
<driver type='virtio-fs'/>
<source dir='/path'/>
<target dir='/path'/>
<address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
</filesystem>
Signed-off-by: Ján Tomko <jtomko@redhat.com>
---
docs/schemas/domaincommon.rng | 1 +
src/conf/domain_conf.c | 1 +
src/conf/domain_conf.h | 1 +
src/qemu/qemu_command.c | 3 +++
src/qemu/qemu_domain.c | 4 ++++
src/qemu/qemu_domain_address.c | 3 +++
tests/qemuxml2argvdata/vhost-user-fs-fd-memory.xml | 6 ++++++
7 files changed, 19 insertions(+)
diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
index e06f892da3..f6479c95a7 100644
--- a/docs/schemas/domaincommon.rng
+++ b/docs/schemas/domaincommon.rng
@@ -2567,6 +2567,7 @@
<value>loop</value>
<value>nbd</value>
<value>ploop</value>
+ <value>virtio-fs</value>
</choice>
</attribute>
</optional>
diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
index d5aba7336f..2694e4bb68 100644
--- a/src/conf/domain_conf.c
+++ b/src/conf/domain_conf.c
@@ -476,6 +476,7 @@ VIR_ENUM_IMPL(virDomainFSDriver,
"loop",
"nbd",
"ploop",
+ "virtio-fs",
);
VIR_ENUM_IMPL(virDomainFSAccessMode,
diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
index c69d1b7ef5..54a7e7c52f 100644
--- a/src/conf/domain_conf.h
+++ b/src/conf/domain_conf.h
@@ -770,6 +770,7 @@ typedef enum {
VIR_DOMAIN_FS_DRIVER_TYPE_LOOP,
VIR_DOMAIN_FS_DRIVER_TYPE_NBD,
VIR_DOMAIN_FS_DRIVER_TYPE_PLOOP,
+ VIR_DOMAIN_FS_DRIVER_TYPE_VIRTIO_FS,
VIR_DOMAIN_FS_DRIVER_TYPE_LAST
} virDomainFSDriverType;
diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
index cbe601099f..985fcdd215 100644
--- a/src/qemu/qemu_command.c
+++ b/src/qemu/qemu_command.c
@@ -2697,6 +2697,9 @@ qemuBuildFilesystemCommandLine(virCommandPtr cmd,
if (qemuBuildFSDevCommandLine(cmd, def->fss[i], def, qemuCaps) < 0)
return -1;
break;
+ case VIR_DOMAIN_FS_DRIVER_TYPE_VIRTIO_FS:
+ /* TODO: vhost-user-fs-pci */
+ return 0;
case VIR_DOMAIN_FS_DRIVER_TYPE_LOOP:
case VIR_DOMAIN_FS_DRIVER_TYPE_NBD:
case VIR_DOMAIN_FS_DRIVER_TYPE_PLOOP:
diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
index 667cc89072..334039005c 100644
--- a/src/qemu/qemu_domain.c
+++ b/src/qemu/qemu_domain.c
@@ -7110,6 +7110,10 @@ qemuDomainDeviceDefValidateFS(virDomainFSDefPtr fs,
_("Filesystem driver type not supported"));
return -1;
+ case VIR_DOMAIN_FS_DRIVER_TYPE_VIRTIO_FS:
+ /* TODO: vhost-user-fs-pci */
+ return -0;
+
case VIR_DOMAIN_FS_DRIVER_TYPE_LAST:
default:
virReportEnumRangeError(virDomainFSDriverType, fs->fsdriver);
diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
index ea5327d475..482373991c 100644
--- a/src/qemu/qemu_domain_address.c
+++ b/src/qemu/qemu_domain_address.c
@@ -692,6 +692,9 @@ qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
case VIR_DOMAIN_FS_MODEL_LAST:
break;
}
+ case VIR_DOMAIN_FS_DRIVER_TYPE_VIRTIO_FS:
+ /* vhost-user-fs-pci */
+ return virtioFlags;
case VIR_DOMAIN_FS_DRIVER_TYPE_LOOP:
case VIR_DOMAIN_FS_DRIVER_TYPE_NBD:
diff --git a/tests/qemuxml2argvdata/vhost-user-fs-fd-memory.xml b/tests/qemuxml2argvdata/vhost-user-fs-fd-memory.xml
index 284ee329b3..ecd5b33a28 100644
--- a/tests/qemuxml2argvdata/vhost-user-fs-fd-memory.xml
+++ b/tests/qemuxml2argvdata/vhost-user-fs-fd-memory.xml
@@ -25,6 +25,12 @@
<emulator>/usr/bin/qemu-system-x86_64</emulator>
<controller type='usb' index='0' model='none'/>
<controller type='pci' index='0' model='pci-root'/>
+ <filesystem type='mount' accessmode='passthrough'>
+ <driver type='virtio-fs'/>
+ <source dir='/path'/>
+ <target dir='/path'/>
+ <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
+ </filesystem>
<input type='mouse' bus='ps2'/>
<input type='keyboard' bus='ps2'/>
<memballoon model='none'/>
--
2.21.0
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-listOn 11/1/19 6:16 AM, Ján Tomko wrote:
> Introduce a new 'virtio-fs' driver type for filesystem.
>
> <filesystem type='mount' accessmode='passthrough'>
> <driver type='virtio-fs'/>
After resolving my confusion* regarding the example and description of the
filesystem/driver element, I think this change is logical and shouldn't require
much bikeshedding :-). Although you are missing docs for the new type.
Regards,
Jim
* The last filesystem example has <driver name='loop' type='raw'/>, which
doesn't match the schema or description. I'll send a doc cleanup patch for that.
> <source dir='/path'/>
> <target dir='/path'/>
> <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
> </filesystem>
>
> Signed-off-by: Ján Tomko <jtomko@redhat.com>
> ---
> docs/schemas/domaincommon.rng | 1 +
> src/conf/domain_conf.c | 1 +
> src/conf/domain_conf.h | 1 +
> src/qemu/qemu_command.c | 3 +++
> src/qemu/qemu_domain.c | 4 ++++
> src/qemu/qemu_domain_address.c | 3 +++
> tests/qemuxml2argvdata/vhost-user-fs-fd-memory.xml | 6 ++++++
> 7 files changed, 19 insertions(+)
>
> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng
> index e06f892da3..f6479c95a7 100644
> --- a/docs/schemas/domaincommon.rng
> +++ b/docs/schemas/domaincommon.rng
> @@ -2567,6 +2567,7 @@
> <value>loop</value>
> <value>nbd</value>
> <value>ploop</value>
> + <value>virtio-fs</value>
> </choice>
> </attribute>
> </optional>
> diff --git a/src/conf/domain_conf.c b/src/conf/domain_conf.c
> index d5aba7336f..2694e4bb68 100644
> --- a/src/conf/domain_conf.c
> +++ b/src/conf/domain_conf.c
> @@ -476,6 +476,7 @@ VIR_ENUM_IMPL(virDomainFSDriver,
> "loop",
> "nbd",
> "ploop",
> + "virtio-fs",
> );
>
> VIR_ENUM_IMPL(virDomainFSAccessMode,
> diff --git a/src/conf/domain_conf.h b/src/conf/domain_conf.h
> index c69d1b7ef5..54a7e7c52f 100644
> --- a/src/conf/domain_conf.h
> +++ b/src/conf/domain_conf.h
> @@ -770,6 +770,7 @@ typedef enum {
> VIR_DOMAIN_FS_DRIVER_TYPE_LOOP,
> VIR_DOMAIN_FS_DRIVER_TYPE_NBD,
> VIR_DOMAIN_FS_DRIVER_TYPE_PLOOP,
> + VIR_DOMAIN_FS_DRIVER_TYPE_VIRTIO_FS,
>
> VIR_DOMAIN_FS_DRIVER_TYPE_LAST
> } virDomainFSDriverType;
> diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c
> index cbe601099f..985fcdd215 100644
> --- a/src/qemu/qemu_command.c
> +++ b/src/qemu/qemu_command.c
> @@ -2697,6 +2697,9 @@ qemuBuildFilesystemCommandLine(virCommandPtr cmd,
> if (qemuBuildFSDevCommandLine(cmd, def->fss[i], def, qemuCaps) < 0)
> return -1;
> break;
> + case VIR_DOMAIN_FS_DRIVER_TYPE_VIRTIO_FS:
> + /* TODO: vhost-user-fs-pci */
> + return 0;
> case VIR_DOMAIN_FS_DRIVER_TYPE_LOOP:
> case VIR_DOMAIN_FS_DRIVER_TYPE_NBD:
> case VIR_DOMAIN_FS_DRIVER_TYPE_PLOOP:
> diff --git a/src/qemu/qemu_domain.c b/src/qemu/qemu_domain.c
> index 667cc89072..334039005c 100644
> --- a/src/qemu/qemu_domain.c
> +++ b/src/qemu/qemu_domain.c
> @@ -7110,6 +7110,10 @@ qemuDomainDeviceDefValidateFS(virDomainFSDefPtr fs,
> _("Filesystem driver type not supported"));
> return -1;
>
> + case VIR_DOMAIN_FS_DRIVER_TYPE_VIRTIO_FS:
> + /* TODO: vhost-user-fs-pci */
> + return -0;
> +
> case VIR_DOMAIN_FS_DRIVER_TYPE_LAST:
> default:
> virReportEnumRangeError(virDomainFSDriverType, fs->fsdriver);
> diff --git a/src/qemu/qemu_domain_address.c b/src/qemu/qemu_domain_address.c
> index ea5327d475..482373991c 100644
> --- a/src/qemu/qemu_domain_address.c
> +++ b/src/qemu/qemu_domain_address.c
> @@ -692,6 +692,9 @@ qemuDomainDeviceCalculatePCIConnectFlags(virDomainDeviceDefPtr dev,
> case VIR_DOMAIN_FS_MODEL_LAST:
> break;
> }
> + case VIR_DOMAIN_FS_DRIVER_TYPE_VIRTIO_FS:
> + /* vhost-user-fs-pci */
> + return virtioFlags;
>
> case VIR_DOMAIN_FS_DRIVER_TYPE_LOOP:
> case VIR_DOMAIN_FS_DRIVER_TYPE_NBD:
> diff --git a/tests/qemuxml2argvdata/vhost-user-fs-fd-memory.xml b/tests/qemuxml2argvdata/vhost-user-fs-fd-memory.xml
> index 284ee329b3..ecd5b33a28 100644
> --- a/tests/qemuxml2argvdata/vhost-user-fs-fd-memory.xml
> +++ b/tests/qemuxml2argvdata/vhost-user-fs-fd-memory.xml
> @@ -25,6 +25,12 @@
> <emulator>/usr/bin/qemu-system-x86_64</emulator>
> <controller type='usb' index='0' model='none'/>
> <controller type='pci' index='0' model='pci-root'/>
> + <filesystem type='mount' accessmode='passthrough'>
> + <driver type='virtio-fs'/>
> + <source dir='/path'/>
> + <target dir='/path'/>
> + <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0'/>
> + </filesystem>
> <input type='mouse' bus='ps2'/>
> <input type='keyboard' bus='ps2'/>
> <memballoon model='none'/>
>
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
On Fri, Nov 1, 2019 at 1:15 PM Ján Tomko <jtomko@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? virtio-fs has no way to pass the target dir into the guest. Out-of-band methods exist: qemu-guest-agent could be used to mount the file system. 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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
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@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 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
On Wed, Nov 20, 2019 at 09:38:15AM +0100, Ján Tomko wrote: > 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@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. Yeah, we shouldn't have called the attribute "dir", but since we have that naming for ages now, we shouldn't change it IMHO. Just document that its a stupid historical name :-) 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 :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
© 2016 - 2026 Red Hat, Inc.