Bug 2055284

*** Bug 2055537 has been marked as a duplicate of this bug. ***

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.

(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.

(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?

(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.

(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.

(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.

(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.

QE bot(pre verify): Set 'Verified:Tested,SanityOnly' as gating/tier1 test pass.

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.

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