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
