[libvirt] [PATCH] qemu: blockCopy: Allow shallow block copy into a raw image

Eric Blake eblake at redhat.com
Mon Apr 27 19:06:59 UTC 2015

On 04/27/2015 06:01 AM, Peter Krempa wrote:
> The documentation states that for shallow block copy the image has to
> have the same guest visible content as backing file of the current
> image. This condition can be achieved also with a raw file (or a qcow
> without a backing file) so remove the condition that would disallow it.
> (This patch additionally fixes crash described in
>  https://bugzilla.redhat.com/show_bug.cgi?id=1215569 since it removes
>  the code)
> ---
>  src/qemu/qemu_driver.c | 10 ----------
>  1 file changed, 10 deletions(-)

This removes a bit of a safety valve that tries to prevent users from
accidentally creating corrupt images when they use the API incorrectly,
but as the safety valve didn't always work and we could actually crash,
and as the documentation has already warned the user about using it
correctly, I can probably live with it.

> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
> index 70bf7aa..f979d33 100644
> --- a/src/qemu/qemu_driver.c
> +++ b/src/qemu/qemu_driver.c
> @@ -16815,16 +16815,6 @@ qemuDomainBlockCopyCommon(virDomainObjPtr vm,
>      if (qemuDomainDetermineDiskChain(driver, vm, disk, false, true) < 0)
>          goto endjob;
> -    if ((flags & VIR_DOMAIN_BLOCK_COPY_SHALLOW) &&
> -        mirror->format == VIR_STORAGE_FILE_RAW &&
> -        disk->src->backingStore->path) {
> -        virReportError(VIR_ERR_CONFIG_UNSUPPORTED,
> -                       _("disk '%s' has backing file, so raw shallow copy "
> -                         "is not possible"),
> -                       disk->dst);
> -        goto endjob;
> -    }

However, one thing I'm not sure about: a shallow block copy with the
REUSE_EXTERNAL flag always makes sense (raw or not, because the user of
that flag knows what they are doing).  But a shallow block copy without
reusing an external file does not make sense - if libvirt is creating
the destination file, then we KNOW that the destination file does not
match the guest contents (except for the corner case where the guest is
not using the block and therefore it remains in the default state of all
0s because it is unwritten).  I'm not convinced yet that this is the
right patch.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 604 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20150427/5a292ff3/attachment-0001.sig>

More information about the libvir-list mailing list