Bug 2083155

Summary: After Fedora 36 upgrade: Error starting domain: operation failed: Unable to find a satisfying virtiofsd
Product: [Fedora] Fedora Reporter: Jonathan Watt <jwatt>
Component: qemuAssignee: Fedora Virtualization Maintainers <virt-maint>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 36CC: agedosier, berrange, cfergeau, clalancette, crobinso, jforbes, laine, libvirt-maint, ondrejj, pbonzini, philmd, rjones, tim, veillard, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-6.2.0-10.fc36 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2022-05-23 01:14:26 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:

Description Jonathan Watt 2022-05-09 13:13:26 UTC
Description of problem:

After upgrading from Fedora 35 to 36 I can no longer start virtual machines that make a virtio-fs filesystem available to the guest OS:

```
Error starting domain: operation failed: Unable to find a satisfying virtiofsd

Traceback (most recent call last):
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 72, in cb_wrapper
    callback(asyncjob, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/asyncjob.py", line 108, in tmpcb
    callback(*args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/libvirtobject.py", line 57, in newfn
    ret = fn(self, *args, **kwargs)
  File "/usr/share/virt-manager/virtManager/object/domain.py", line 1384, in startup
    self._backend.create()
  File "/usr/lib64/python3.10/site-packages/libvirt.py", line 1353, in create
    raise libvirtError('virDomainCreate() failed')
libvirt.libvirtError: operation failed: Unable to find a satisfying virtiofsd
```

Removing the virtio-fs filesystems from the virtual machines allows the machines to start the boot process and they boot successfully.


How reproducible: 100%


Steps to Reproduce:
The virtual machines were created using a script that invokes virt-install:
https://gitlab.com/jwattt/cross-compile-ff-and-libvirt/-/blob/2a806a1025f66561fe11021ca9c09be403bc1c8a/setup-vm.bash#L230

Comment 1 Daniel Berrangé 2022-05-09 13:22:32 UTC
The virtiofsd binary was previously (mistakenly) included in the qemu-common package which meant it was installed everywhere. It has now been split out into a separate package 'qemu-virtiofsd'. The QEMU C based virtiofsd impl is deprecated by upstream, having been replaced by a Rust based impl. So actually we'd recommend installing the 'virtiofsd' RPM, rather than 'qemu-virtiofsd', to get the Rust impl.

Comment 2 Jonathan Watt 2022-05-09 14:05:18 UTC
Thanks, Daniel. Will the Rust based virtiofsd be available as/in a dnf managed package any time soon? And is there an issue/bug somewhere for that work so I can be notified when I should switch to that (rather than manually having to update the RPM periodically)?

Comment 3 Daniel Berrangé 2022-05-09 14:12:34 UTC
Oh, I thought we had it in Fedora already, but I'm mistaken. The work is in progress at least, so hopefully a package review bug will get opened soon.

Comment 4 Jonathan Watt 2022-05-10 19:46:37 UTC
 Ah, thanks. I guess Fedora 36 won't get that, so the thing to do is maybe to check `dnf provides /usr/libexec/virtiofsd` once 37 is released?

Comment 5 Daniel Berrangé 2022-05-11 08:02:42 UTC
There is a virtual Provides: vhostuser-backend(fs), which the new virtiofsd rust package will also end up providing - better to use that than rely on specific binary paths, if you just want "any" virtiofsd impl and don't care for a specific one.

Comment 6 Cole Robinson 2022-05-17 18:12:22 UTC
*** Bug 2084421 has been marked as a duplicate of this bug. ***

Comment 7 Cole Robinson 2022-05-17 18:24:53 UTC
*** Bug 2084446 has been marked as a duplicate of this bug. ***

Comment 8 Cole Robinson 2022-05-17 18:32:53 UTC
The qemu package is buggy here, the vhostuser-backend(fs) dep is on the `qemu` metapackage, but it should be on the qemu-system-XXX metapackages instead. I'll fix this shortly. It means most existing dependency chains will pull in a virtiofsd, which was the intended behavior when I split this out originally.

Comment 9 Fedora Update System 2022-05-18 10:57:41 UTC
FEDORA-2022-6ae3d4f991 has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-6ae3d4f991

Comment 10 Fedora Update System 2022-05-19 15:37:25 UTC
FEDORA-2022-6ae3d4f991 has been pushed to the Fedora 36 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-6ae3d4f991`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-6ae3d4f991

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 11 Fedora Update System 2022-05-23 01:14:26 UTC
FEDORA-2022-6ae3d4f991 has been pushed to the Fedora 36 stable repository.
If problem still persists, please make note of it in this bug report.