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.) Also should this be documented elsewhere? -- /kashyap
