Bug 1805324 - auto-detect virtiofsd path from vhost-user interop files
Summary: auto-detect virtiofsd path from vhost-user interop files
Keywords:
Status: VERIFIED
Alias: None
Product: Red Hat Enterprise Linux Advanced Virtualization
Classification: Red Hat
Component: libvirt
Version: 8.2
Hardware: All
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Ján Tomko
QA Contact: Lili Zhu
URL:
Whiteboard:
Depends On: 1804196 1694166 1805334
Blocks: 1796871 1885765 1928180
TreeView+ depends on / blocked
 
Reported: 2020-02-20 16:41 UTC by Ján Tomko
Modified: 2021-09-03 15:06 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-08-20 07:27:19 UTC
Type: Bug
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 191751 0 None None None 2021-03-02 17:04:11 UTC
Red Hat Bugzilla 1999372 1 unspecified NEW Error unclear when starting guest with wrong virtiofsd path 2021-09-06 12:41:58 UTC

Internal Links: 1886739 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@de.ibm.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.


Note You need to log in before you can comment on or make changes to this bug.