RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 2055284 - Remove the qemu-virtiofsd subpackage
Summary: Remove the qemu-virtiofsd subpackage
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: qemu-kvm
Version: 9.0
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Miroslav Rezanina
QA Contact: xiagao
URL:
Whiteboard:
Depends On:
Blocks: 1997279
TreeView+ depends on / blocked
 
Reported: 2022-02-16 15:18 UTC by Sergio Lopez
Modified: 2022-06-16 03:07 UTC (History)
18 users (show)

Fixed In Version: qemu-kvm-6.2.0-11.el9
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-17 12:25:28 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Gitlab redhat/centos-stream/src qemu-kvm merge_requests 76 0 None None None 2022-02-21 08:09:33 UTC
Red Hat Issue Tracker RHELPLAN-112605 0 None None None 2022-02-16 15:21:03 UTC
Red Hat Product Errata RHBA-2022:2307 0 None None None 2022-05-17 12:26:07 UTC

Description Sergio Lopez 2022-02-16 15:18:35 UTC 
On RHEL9, we're only going to ship the Rust implementation of virtiofsd, which is shipped in the package "virtiofsd". This means we should drop the qemu-virtiofsd subpackage from the qemu-kvm package.
Comment 1 CongLi 2022-02-17 07:55:59 UTC 
*** Bug 2055537 has been marked as a duplicate of this bug. ***
Comment 2 yalzhang@redhat.com 2022-02-17 08:41:19 UTC 
Hi Sergio, please help to confirm, do we plan to drop qemu-virtiofsd and only keep virtiofsd instead? If that's true, it will introduce one regression issue, see bug 2055537, virtiofsd can not work properly to support virtio filesystem.
Comment 3 Sergio Lopez 2022-02-17 09:09:32 UTC 
(In reply to yalzhang from comment #2)
> Hi Sergio, please help to confirm, do we plan to drop qemu-virtiofsd and
> only keep virtiofsd instead? If that's true, it will introduce one
> regression issue, see bug 2055537, virtiofsd can not work properly to
> support virtio filesystem.

Yes, that's the plan.

The regression described in 2055537 doesn't mean that virtiofsd can not support the virtio filesystem, it just means it doesn't incorporate support for remote POSIX locks, mainly because in the C implementation was already partially broken (no support for blocking operations), so we decided to not introduce them until we have a complete solution.
Comment 4 yalzhang@redhat.com 2022-02-21 02:26:03 UTC 
(In reply to Sergio Lopez from comment #3)
> 
> Yes, that's the plan.
> 
> The regression described in 2055537 doesn't mean that virtiofsd can not
> support the virtio filesystem, it just means it doesn't incorporate support
> for remote POSIX locks, mainly because in the C implementation was already
> partially broken (no support for blocking operations), so we decided to not
> introduce them until we have a complete solution.

Currently when we install qemu-kvm, virtiofsd will be installed as dependency, *not* qemu-virtiofsd. And with virtiofsd, vm with filesystem setting can not start(bug 2055537), which is a regression issue.
So do we plan to fix this "partially broken" in virtiofsd in rhel 9.0?
Comment 5 Sergio Lopez 2022-02-21 07:16:15 UTC 
(In reply to yalzhang from comment #4)
> (In reply to Sergio Lopez from comment #3)
> > 
> > Yes, that's the plan.
> > 
> > The regression described in 2055537 doesn't mean that virtiofsd can not
> > support the virtio filesystem, it just means it doesn't incorporate support
> > for remote POSIX locks, mainly because in the C implementation was already
> > partially broken (no support for blocking operations), so we decided to not
> > introduce them until we have a complete solution.
> 
> Currently when we install qemu-kvm, virtiofsd will be installed as
> dependency, *not* qemu-virtiofsd. And with virtiofsd, vm with filesystem
> setting can not start(bug 2055537), which is a regression issue.
> So do we plan to fix this "partially broken" in virtiofsd in rhel 9.0?

Remote locks is not properly supported in neither qemu-virtiofsd nor virtiofsd. The latter is simply more explicit about it, rejecting enabling it. Users should NOT be using this feature.

We can open a separate BZ to track implementing the feature properly in virtiofsd (qemu-virtiofsd is deprecated, so there's no reason to fix it there too).

Sergio.
Comment 8 yalzhang@redhat.com 2022-02-21 08:46:22 UTC 
(In reply to Sergio Lopez from comment #5)
> 
> Remote locks is not properly supported in neither qemu-virtiofsd nor
> virtiofsd. The latter is simply more explicit about it, rejecting enabling
> it. Users should NOT be using this feature.
> 
> We can open a separate BZ to track implementing the feature properly in
> virtiofsd (qemu-virtiofsd is deprecated, so there's no reason to fix it
> there too).
> 
> Sergio.

Thank you for confirmation. I have updated the description a little in bug 2055537 and reopen it, let's track the issue there.
Comment 10 Daniel Berrangé 2022-02-21 10:03:52 UTC 
(In reply to Sergio Lopez from comment #5)
> (In reply to yalzhang from comment #4)
> > (In reply to Sergio Lopez from comment #3)
> > > 
> > > Yes, that's the plan.
> > > 
> > > The regression described in 2055537 doesn't mean that virtiofsd can not
> > > support the virtio filesystem, it just means it doesn't incorporate support
> > > for remote POSIX locks, mainly because in the C implementation was already
> > > partially broken (no support for blocking operations), so we decided to not
> > > introduce them until we have a complete solution.
> > 
> > Currently when we install qemu-kvm, virtiofsd will be installed as
> > dependency, *not* qemu-virtiofsd. And with virtiofsd, vm with filesystem
> > setting can not start(bug 2055537), which is a regression issue.
> > So do we plan to fix this "partially broken" in virtiofsd in rhel 9.0?
> 
> Remote locks is not properly supported in neither qemu-virtiofsd nor
> virtiofsd. The latter is simply more explicit about it, rejecting enabling
> it. Users should NOT be using this feature.

Where have we documented that users shouldn't be using this '-o flock' option ?

AFAICT it has been included in QEMU's virtiofsd impl since day 1 and the man page doesn't give any warnings about not using it. 

Despite its known implementation limitations, it feels like there's a decent chance users will have enabled this option and so experience a regression.
Comment 12 Sergio Lopez 2022-02-21 13:44:42 UTC 
(In reply to Daniel Berrangé from comment #10)
> (In reply to Sergio Lopez from comment #5)
> > (In reply to yalzhang from comment #4)
> > > (In reply to Sergio Lopez from comment #3)
> > > > 
> > > > Yes, that's the plan.
> > > > 
> > > > The regression described in 2055537 doesn't mean that virtiofsd can not
> > > > support the virtio filesystem, it just means it doesn't incorporate support
> > > > for remote POSIX locks, mainly because in the C implementation was already
> > > > partially broken (no support for blocking operations), so we decided to not
> > > > introduce them until we have a complete solution.
> > > 
> > > Currently when we install qemu-kvm, virtiofsd will be installed as
> > > dependency, *not* qemu-virtiofsd. And with virtiofsd, vm with filesystem
> > > setting can not start(bug 2055537), which is a regression issue.
> > > So do we plan to fix this "partially broken" in virtiofsd in rhel 9.0?
> > 
> > Remote locks is not properly supported in neither qemu-virtiofsd nor
> > virtiofsd. The latter is simply more explicit about it, rejecting enabling
> > it. Users should NOT be using this feature.
> 
> Where have we documented that users shouldn't be using this '-o flock'
> option ?
> 
> AFAICT it has been included in QEMU's virtiofsd impl since day 1 and the man
> page doesn't give any warnings about not using it. 
> 
> Despite its known implementation limitations, it feels like there's a decent
> chance users will have enabled this option and so experience a regression.

I *highly* doubt it. I've personally tested this feature thoroughly myself, and if you enable it, pretty much every application that does use POSIX locks will crash and burn, as they don't expect blocking locks to fail with -ENOTSUPP.
Comment 17 Yanan Fu 2022-03-03 02:49:28 UTC 
QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass.
Comment 20 xiagao 2022-03-04 06:52:29 UTC 
Verified with qemu-kvm-6.2.0-11.el9

No qemu-virtiofsd pkg included and virtiofsd pkg is as a dependency of qemu-kvm pkg.

Basic/critical function test works well.
Comment 22 errata-xmlrpc 2022-05-17 12:25:28 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: qemu-kvm), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:2307
Note You need to log in before you can comment on or make changes to this bug.