[libvirt] -blockdev bug (and some questions)
Peter Krempa
pkrempa at redhat.com
Mon Oct 7 15:30:36 UTC 2019
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.
More information about the libvir-list
mailing list