qemu-block
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]