On Fri, Mar 13, 2020 at 14:05:54 +0100, Kashyap Chamarthy wrote:
On Fri, Mar 13, 2020 at 01:08:47PM +0100, Peter Krempa wrote:
> On Wed, Mar 11, 2020 at 11:09:40 -0500, Eric Blake wrote:
> > On 3/10/20 10:54 AM, Peter Krempa wrote:
>
> [...]
>
> > The comments are good at explaining the situation - we have a window of qemu
> > releases that regress when using -blockdev, but as long as oVirt can force
> > either the old -drive behavior or insist on new-enough libvirt coupled with
> > new-enough qemu that restores the write-only-reopen feature that we need,
> > then oVirt won't hit the regression. I'm not sure how you plan to
advertise
> > to oVirt if this is a new-enough libvirt + detection of new-enough qemu to
> > tell oVirt they don't need to cobble libvirt into using -drive rather than
> > -blockdev (they might solve that by minimum required versions, rather than
> > having to ask libvirt), but answering that question doesn't interfere with
> > the validity of this patch.
>
> I'm not sure about the value of exposing this particular situation since
> it's a regression of behaviour which is being rectified. The code
> driving it in oVirt will stay the same and the only thing that could be
> changed is the error message reported. oVirt probably wants just
> blacklist the 3 releases that are broken.
Just for the record, can you please note the three affected libvirt
releases? (It'll help us refer to your response when answering
users/admins at a future time.)
It affects libvirt-5.10, libvirt-6.0 and libvirt-6.1.
Also should this be documented elsewhere?
I can add a news.xml entry