Bug 1805324

Summary: auto-detect virtiofsd path from vhost-user interop files
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: Ján Tomko <jtomko>
Component: libvirtAssignee: Ján Tomko <jtomko>
Status: CLOSED CURRENTRELEASE QA Contact: Lili Zhu <lizhu>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 8.2CC: bugproxy, chhu, cohuck, drjones, jsuchane, lcapitulino, lizhu, lmen, smitterl, thuth, tstaudt, virt-maint, xuzhang
Target Milestone: rcKeywords: Reopened, TestOnly, Triaged
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2021-11-19 16:19:42 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1694166, 1804196, 1805334    
Bug Blocks: 1796871, 1885765, 1928180    

Description Ján Tomko 2020-02-20 16:41:50 UTC
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

Comment 5 Jaroslav Suchanek 2021-08-06 12:38:30 UTC
Qemu part is done in bug 1804196.

Comment 6 Lili Zhu 2021-08-11 08:11:43 UTC
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

Comment 7 RHEL Program Management 2021-08-20 07:27:19 UTC
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 8 IBM Bug Proxy 2021-08-20 10:30:40 UTC
------- 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.

Comment 9 Thomas Huth 2021-08-20 12:51:29 UTC
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...

Comment 10 smitterl 2021-08-25 11:27:53 UTC
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

Comment 11 Jaroslav Suchanek 2021-08-27 12:11:49 UTC
Reopening due to wrong bot rule which closed it by accident. Lili, please set it to verified again. Thanks.

Comment 13 Ján Tomko 2021-08-27 14:45:02 UTC
(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.

Comment 14 Lili Zhu 2021-08-31 03:57:02 UTC
(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.