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?