Unable to mount virtio-fs shared directories since Tumbleweed 20220216 transactional-update
![](https://seccdn.libravatar.org/avatar/b6a17a4fef607ec786cc45111c32721c.jpg?s=120&d=mm&r=g)
Hi all, Host: Tumbleweed transactional-server Guest VM: Leap 15.3 (up to date) I'm unable to mount virtio-fs shared directories since Tumbleweed 20220216 transactional-update. The Guest VM is managed through libvirt tools and still work very well while the KVM host is running Tumbleweed 20220215. Here are higlights for the guest VM libvirt xml file: ---8<---------- <memoryBacking> <hugepages> <page size='2048' unit='KiB'/> </hugepages> <access mode='shared'/> </memoryBacking> --->8---------- ---8<---------- <filesystem type='mount' accessmode='passthrough'> <driver type='virtiofs' queue='1024'/> <binary path='/usr/libexec/virtiofsd' xattr='on'> <cache mode='none'/> <sandbox mode='namespace'/> <lock posix='on' flock='on'/> </binary> <source dir='/var/data/VG0-DATA'/> <target dir='VG0-DATA'/> <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </filesystem> --->8---------- For historical reasons, VG0-DATA is an XFS filesystem on LVM2 on LUKS2 encrypted disk. I can't identify anything in the diff files of the snapshot changes that is responsible for this issue: https://openqa.opensuse.org/snapshot.../diff/20220215 --- https://openqa.opensuse.org/snapshot.../diff/20220216 Latest transactional-update still do not solve this problem, my only solution for now is to stay on snapshot 20220215. I would be very grateful to anyone who can point me to a solution. Regards,
![](https://seccdn.libravatar.org/avatar/9435667f7160374bc34a8600b686aecd.jpg?s=120&d=mm&r=g)
On 07.03.2022 19:25, bjurg orsku wrote:
Hi all,
Host: Tumbleweed transactional-server Guest VM: Leap 15.3 (up to date)
I'm unable to mount virtio-fs shared directories since Tumbleweed 20220216 transactional-update.
Well, it works here on normal TW bor@tw:~> grep /host/ /etc/fstab home /host/home 9p noauto,users,trans=virtio,version=9p2000.L 00 bor@tw:~> grep -E 'VERSION_ID|PRETTY_NAME' /etc/os-release VERSION_ID="20220305" PRETTY_NAME="openSUSE Tumbleweed" bor@tw:~> If you really have transactional server, root is read-only which may or may not be relevant. What exactly "unable to mount" means? You get any error message?
The Guest VM is managed through libvirt tools and still work very well while the KVM host is running Tumbleweed 20220215.
Here are higlights for the guest VM libvirt xml file: ---8<----------
<memoryBacking> <hugepages> <page size='2048' unit='KiB'/> </hugepages> <access mode='shared'/> </memoryBacking>
--->8----------
---8<----------
<filesystem type='mount' accessmode='passthrough'> <driver type='virtiofs' queue='1024'/> <binary path='/usr/libexec/virtiofsd' xattr='on'> <cache mode='none'/> <sandbox mode='namespace'/> <lock posix='on' flock='on'/> </binary> <source dir='/var/data/VG0-DATA'/> <target dir='VG0-DATA'/> <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </filesystem>
--->8----------
For historical reasons, VG0-DATA is an XFS filesystem on LVM2 on LUKS2 encrypted disk.
I can't identify anything in the diff files of the snapshot changes that is responsible for this issue:
https://openqa.opensuse.org/snapshot.../diff/20220215 --- https://openqa.opensuse.org/snapshot.../diff/20220216
Latest transactional-update still do not solve this problem, my only solution for now is to stay on snapshot 20220215.
I would be very grateful to anyone who can point me to a solution.
Regards,
![](https://seccdn.libravatar.org/avatar/b6a17a4fef607ec786cc45111c32721c.jpg?s=120&d=mm&r=g)
@Andrei: Thank you for your interest in my issue. Your entry in the /etc/fstab file indicates that you are using 9p to mount your sharing while I am using virtio-fs, which is not the same. "unable to mount" means that inside the guest VM the share filesystem is called through the declared mount tag with the following command: ``` $ sudo mount -t virtiofs mount_tag /mnt/mount/path ``` but then, the terminal is stalled and I can't even access the mount path as root in another terminal! Nothing appears in the logs (host+guest).
![](https://seccdn.libravatar.org/avatar/9435667f7160374bc34a8600b686aecd.jpg?s=120&d=mm&r=g)
On 07.03.2022 23:23, bjurg orsku wrote:
@Andrei: Thank you for your interest in my issue. Your entry in the /etc/fstab file indicates that you are using 9p to mount your sharing while I am using virtio-fs, which is not the same.
Right, I played with virtio-fs and then decided it was too complicated for my purposes (I run qemu manually as non-root and virtiofsd must be started as root, separate daemon for each shared directory, etc).
"unable to mount" means that inside the guest VM the share filesystem is called through the declared mount tag with the following command: ``` $ sudo mount -t virtiofs mount_tag /mnt/mount/path ```
Mailing list does not magically reformat your special characters. Moreover, mailing lists are normally using plain text, so there is no way to format anything.
but then, the terminal is stalled and I can't even access the mount path as root in another terminal! Nothing appears in the logs (host+guest).
Well, it works for me on the same version I mentioned for sharing of $HOME using virtiofsd started as root. I do not use libvirt.
![](https://seccdn.libravatar.org/avatar/b6a17a4fef607ec786cc45111c32721c.jpg?s=120&d=mm&r=g)
@Andrei: I tried to answer to your message yesterday, but there was a problem with the mailing list send service... Anyway, I've taken the option to open #1196924 bug report. Many thanks for your time.
participants (2)
-
Andrei Borzenkov
-
bjurg orsku