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