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.