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. -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
