[libvirt] -blockdev bug (and some questions)

[Peter Krempa]

On Mon, Oct 07, 2019 at 09:34:39 -0400, Cole Robinson wrote:
> On 10/7/19 2:07 AM, Peter Krempa wrote:
> > On Sat, Oct 05, 2019 at 17:39:01 -0400, Cole Robinson wrote:

[...]

> > > More generally I have questions about why we track backingStore in the XML
> > > for an offline VM anyways? I presume this is intentional, but I don't
> > > understand the usecases. Can you provide more info or link me to somewhere
> > > if this has been discussed before?
> > 
> > As said above this is desired. The qcow2 metadata as created usually by
> > libvirt contains full absolute paths to images. This means that if you
> > want to move your image with the backing chain somewhere else you'd have
> > to tweak the metadata.
> > 
> > With blockdev you are able to fully configure this so putting a
> > 
> >       <disk type='file' device='disk'>
> >         <driver name='qemu' type='qcow2'/>
> >         <source file='/OVERLAY.qcow2'/>
> >         <backingStore type='file'>
> >           <source file='/backing.qcow2'/>
> >           </backingStore>
> >         </backingStore>
> >         <target dev='vda' bus='virtio'/>
> >       </disk>
> > 
> > will be honoured as written.
> 
> Hmm interesting. Maybe we should be raising a Validate failure if any
> <backingStore> is in the persistent XML if -blockdev isn't supported? I
> don't know if it's actually possible but just the general idea that on
> libvirt upgrade the same XML can result in different image topology sent to
> a writeable VM sounds scary.

We certainly can add a validation check. It unfortunately will not help
in cases when blockdev will already be used. Luckily it's not enabled in
libvirt yet.