[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 13:15:25 UTC 2020


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




More information about the libvir-list mailing list