Re: [libvirt] -blockdev bug (and some questions)

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.