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. Said that we can expose it in the domain capabilities XML. Nir, would there be value in doing that for oVirt?
