Description of problem: libvirt needs to look into the correct path to find the virtiofsd.json file: $ cat /usr/share/qemu/vhost-user/50-qemu-virtiofsd.json { "description": "QEMU virtiofsd vhost-user-fs", "type": "fs", "binary": "/usr/local/libexec/virtiofsd" } Expected results: Asking for a virtiofs filesystem should be possible without specifying a binary: <filesystem type='mount' accessmode='passthrough'> <driver type='virtiofs'/> <source dir='/path'/> <target dir='mount_tag'> </filesystem> Additional info: See the following qemu-kvm bug requesting consistent paths: https://bugzilla.redhat.com/show_bug.cgi?id=1804196
Qemu part is done in bug 1804196.
Verify this bug with: libvirt-7.6.0-1.module+el8.5.0+12097+2c77910b.x86_64 qemu-kvm-6.0.0-27.module+el8.5.0+12121+c40c8708.x86_64 1. check the virtiofsd.json file # cat /usr/share/qemu/vhost-user/50-qemu-virtiofsd.json { "description": "QEMU virtiofsd vhost-user-fs", "type": "fs", "binary": "/usr/libexec/virtiofsd" <==binary path is updated } 2. prepare a guest with the following xml ... <filesystem type='mount' accessmode='passthrough'> <driver type='virtiofs'/> <source dir='/path'/> <target dir='mount_tag'/> <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </filesystem> ... 3. start the guest # virsh start avocado-vt-vm1 Domain 'avocado-vt-vm1' started 4. check the guest xml <filesystem type='mount' accessmode='passthrough'> <driver type='virtiofs'/> <binary path='/usr/libexec/virtiofsd'/> <=== virtiofsd binary been added automatically <source dir='/path'/> <target dir='mount_tag'/> <alias name='fs0'/> <address type='pci' domain='0x0000' bus='0x07' slot='0x00' function='0x0'/> </filesystem> As the testing result matches with the expected result, mark the bug as verified
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release. Therefore, it is being closed. If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
------- Comment From tstaudt.com 2021-08-20 06:28 EDT------- I guess this should not have been closed, but this has only been mirrored to IBM for our information, so this is for Red Hat to decide.
Yes, it's quite unfortunate that the bot closes bugs in VERIFIED state, too ... but since this would have been closed in a couple of weeks anyway, I'm not sure whether it makes much sense to re-open it again now...
TBH, it looks like this was CLOSED as WONTFIX because of the stale bug engine rule, but erroneously as WONTFIX and message "no plans to address it further or fix it in an upcoming release"; Lili already had VERIRIED this BZ. @Lili, IIUC all TestOnly bzs must be set CLOSED manually, is that true? If so, should we better change the status to CLOSED/CURRRENTRELEASE or back to VERIFIED? Also, I misunderstood the BZ so I re-ran Lili's verification, just taking note of the scenarios. I'm wondering if the error message should be improved when the binary is not found? (point 2. below), what do you think? 1. Don't define //binary@path in domain xml, don't change path in 50-qemu-virtiofsd.json ==> Machine starts and directory can be mounted. (Also, write a file correctly.) # virsh dumpxml --inactive avocado-vt-vm1 ... <filesystem type='mount' accessmode='passthrough'> <driver type='virtiofs'/> <source dir='/mnt'/> <target dir='mount_tag'/> <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0009'/> </filesystem> ... # virsh dumpxml avocado-vt-vm1 ... <filesystem type='mount' accessmode='passthrough'> <driver type='virtiofs'/> <binary path='/usr/libexec/virtiofsd'/> <source dir='/mnt'/> <target dir='mount_tag'/> <alias name='fs0'/> <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0009'/> </filesystem> ... 2. Change virtiofsd path, rename to virtiofsdaemon, link from /sbin ==> Machine shows error on start error: Failed to start domain 'avocado-vt-vm1' error: internal error: virtiofsd died unexpectedly # journalctl -eu libvirtd --no-hostname ... Aug 25 07:02:51 libvirtd[168720]: internal error: End of file from qemu monitor Aug 25 07:03:17 libvirtd[168720]: internal error: virtiofsd died unexpectedly ... 3. Update path in 50-qemu-virtiofsd.json to point to new path in /sbin ==> Machine starts and directory can be mounted. (Also, read a file correctly.) # ps aux|grep virtiofsd root 170493 0.0 0.0 84784 5228 ? Sl 07:07 0:00 /sbin/virtiofsd --fd=40 -o source=/mnt
Reopening due to wrong bot rule which closed it by accident. Lili, please set it to verified again. Thanks.
(In reply to smitterl from comment #10) > 2. Change virtiofsd path, rename to virtiofsdaemon, link from /sbin > ==> Machine shows error on start > error: Failed to start domain 'avocado-vt-vm1' > error: internal error: virtiofsd died unexpectedly > Yes, the error message is misleading. But that's out of scope of this bug.
(In reply to smitterl from comment #10) > TBH, it looks like this was CLOSED as WONTFIX because of the stale bug > engine rule, but erroneously as WONTFIX and message "no plans to address it > further or fix it in an upcoming release"; Lili already had VERIRIED this BZ. > > @Lili, IIUC all TestOnly bzs must be set CLOSED manually, is that true? If > so, should we better change the status to CLOSED/CURRRENTRELEASE or back to > VERIFIED? Also, I misunderstood the BZ so I re-ran Lili's verification, just > taking note of the scenarios. I'm wondering if the error message should be > improved when the binary is not found? (point 2. below), what do you think? > > 1. Don't define //binary@path in domain xml, don't change path in > 50-qemu-virtiofsd.json > ==> Machine starts and directory can be mounted. (Also, write a file > correctly.) > # virsh dumpxml --inactive avocado-vt-vm1 > ... > <filesystem type='mount' accessmode='passthrough'> > <driver type='virtiofs'/> > <source dir='/mnt'/> > <target dir='mount_tag'/> > <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0009'/> > </filesystem> > ... > # virsh dumpxml avocado-vt-vm1 > ... > <filesystem type='mount' accessmode='passthrough'> > <driver type='virtiofs'/> > <binary path='/usr/libexec/virtiofsd'/> > <source dir='/mnt'/> > <target dir='mount_tag'/> > <alias name='fs0'/> > <address type='ccw' cssid='0xfe' ssid='0x0' devno='0x0009'/> > </filesystem> > ... > > 2. Change virtiofsd path, rename to virtiofsdaemon, link from /sbin > ==> Machine shows error on start > error: Failed to start domain 'avocado-vt-vm1' > error: internal error: virtiofsd died unexpectedly > > # journalctl -eu libvirtd --no-hostname > ... > Aug 25 07:02:51 libvirtd[168720]: internal error: End of file from qemu > monitor > Aug 25 07:03:17 libvirtd[168720]: internal error: virtiofsd died unexpectedly > ... > > 3. Update path in 50-qemu-virtiofsd.json to point to new path in /sbin > ==> Machine starts and directory can be mounted. (Also, read a file > correctly.) > # ps aux|grep virtiofsd > root 170493 0.0 0.0 84784 5228 ? Sl 07:07 0:00 > /sbin/virtiofsd --fd=40 -o source=/mnt Thanks very much for the testing. Filed a bug 1999372 to track this issue.