[PATCH 5/5] qemu: blockcopy: Allow late opening of the backing chain of a shallow copy

Peter Krempa pkrempa at redhat.com
Fri Mar 13 12:08:47 UTC 2020


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?




More information about the libvir-list mailing list