[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: blockdev-snapshot
From: |
Peter Krempa |
Subject: |
Re: blockdev-snapshot |
Date: |
Fri, 25 Oct 2019 10:22:41 +0200 |
User-agent: |
Mutt/1.12.1 (2019-06-15) |
On Wed, Oct 23, 2019 at 13:20:21 +0200, Peter Krempa wrote:
> Hi,
[...]
> QEMU now does not consider 'libvirt-1-format' part of the backing chain.
> I presume this happens as the blockdev-add step above [1] has
> backing:null and blockdev-snapshot does not fix it in any way. Then once
> a reopen happens the backing is dropped as per the specification.
>
> Libvirt uses backing:null to prevent qemu from opening the images in the
> backing-file field as that would fail anyways due to image locking.
>
> Similarly we can't use backing:nodename-of-the-currently-active-image
> as it's currently in write mode and using it as a backing fails:
>
> Node 'libvirt-1-format' is busy: node is used as backing hd of
> 'libvirt-3-format'
>
> So this leaves us with one option only. We can omit the backing file
> name and format during blockdev-create, blockdev-add it and then use
> change-backing-file QMP command to update the backing store string once
> the image is opened.
Actually this will work only for the "standard" case of a new image
being used for a snapshot. Unfortunately libvirt historically allowed
passing pre-formatted images to be installed as the overlay (virsh
snapshot-create DOMNAME SNAPSHOTXML --reuse-external). In such case the
image may contain the backing-file field specified by the user. Not
using backing:null would then attempt to open the backing file.
As of this I think that 'blockdev-snapshot' should re-write the
internals such that a reopen will not try to modify the backing file as
specified with blockdev-add after it's installed as an overlay.