I don't think it's worth doing anything when reusing external files. The reuse option was added to allow relative paths, but the user has to set up the backing file properly. The documentation states:

For block copy:
"The destination will be created unless the VIR_DOMAIN_BLOCK_COPY_REUSE_EXT flag is present stating that the file was pre-created with the correct format and metadata and sufficient size to hold the copy."

For snapshots:
"However, if @flags includes VIR_DOMAIN_SNAPSHOT_CREATE_REUSE_EXT, then the destination files must be pre-created manually with the correct image format and metadata including backing store path (this allows a management app to pre-create files with relative backing file names, rather than the default of creating with absolute backing file names). Note that setting incorrect metadata in the pre-created image may lead to the VM being unable to start."

As this is basically a workaround for bug 1127226 and it's well documented that the users have to pass correct metadata in the backing chain I don't think there's anything to do for us. Using the external files should not be a common thing to do.

(In reply to Peter Krempa from comment #1)
> I don't think it's worth doing anything when reusing external files. The
> reuse option was added to allow relative paths, but the user has to set up
> the backing file properly. The documentation states:
> 
> For block copy:
> "The destination will be created unless the VIR_DOMAIN_BLOCK_COPY_REUSE_EXT
> flag is present stating that the file was pre-created with the correct
> format and metadata and sufficient size to hold the copy."
> 
> For snapshots:
> "However, if @flags includes VIR_DOMAIN_SNAPSHOT_CREATE_REUSE_EXT, then the
> destination files must be pre-created manually with the correct image format
> and metadata including backing store path (this allows a management app to
> pre-create files with relative backing file names, rather than the default
> of creating with absolute backing file names). Note that setting incorrect
> metadata in the pre-created image may lead to the VM being unable to start."
> 

Users do create a backing chain with correct format and metadata in step 1(see comment 0), right?

Problem is in step3. 
If users create external snapshot using the existing file with right sequence(here is a then b then c), then there will be no problem. 

If can not fix this, at least note it in our document(libvirt.org)?


> As this is basically a workaround for bug 1127226 and it's well documented
> that the users have to pass correct metadata in the backing chain I don't
> think there's anything to do for us. Using the external files should not be
> a common thing to do.

(In reply to Shanzhi Yu from comment #2)
> (In reply to Peter Krempa from comment #1)
> > I don't think it's worth doing anything when reusing external files. The
> > reuse option was added to allow relative paths, but the user has to set up
> > the backing file properly. The documentation states:
> > 
> > For block copy:
> > "The destination will be created unless the VIR_DOMAIN_BLOCK_COPY_REUSE_EXT
> > flag is present stating that the file was pre-created with the correct
> > format and metadata and sufficient size to hold the copy."
> > 
> > For snapshots:
> > "However, if @flags includes VIR_DOMAIN_SNAPSHOT_CREATE_REUSE_EXT, then the
> > destination files must be pre-created manually with the correct image format
> > and metadata including backing store path (this allows a management app to
> > pre-create files with relative backing file names, rather than the default
> > of creating with absolute backing file names). Note that setting incorrect
> > metadata in the pre-created image may lead to the VM being unable to start."
> > 
> 
> Users do create a backing chain with correct format and metadata in step
> 1(see comment 0), right?

Ah, now I see the problem. I had to carefully check the reproducer steps as I've misread them at first.

> 
> Problem is in step3. 
> If users create external snapshot using the existing file with right
> sequence(here is a then b then c), then there will be no problem. 

The problem is that you pre-create three (a/a, b/b, c/c) layers of images in your reproducer steps and use the last one (c/c) as the snapshot. Qemu in the live step uses just the image you passed to it thus it disregards the 'images/b/b' and 'images/a/a' from it's backing chain, while libvirt does re-detect the backing chain.

In case libvirt would track the metadata properly this would not happen as the images in the backing chain that is displayed would be as it's tracked by qemu.

> 
> If can not fix this, at least note it in our document(libvirt.org)?

While this is still a user error, this particular problem is not documented. I'll try to come up with a wording that might explain that only the image passed to the API is added to the backing chain by the hypervisor and other are ignored.

For now, I've documented that only one layer is inserted into the backing chain in the live definition:

commit d56707766e3ce7f505719f5adf753bfefd9f7c9a
Author: Peter Krempa <pkrempa>
Date:   Fri Apr 10 10:48:34 2015 +0200

    lib: snapshot: Explain that only one layer of images is inserted
    
    When creating a snapshot with _REUSE_EXTERNAL when the pre-created image
    does not directly link to the current active layer libvirt would
    re-detect the backing chain incorrectly and it would not match with
    qemu's view. Since the configuration is an operator mistake, document
    that only the top layer image gets inserted.

diff --git a/src/libvirt-domain-snapshot.c b/src/libvirt-domain-snapshot.c
index ac858ba..55826fd 100644
--- a/src/libvirt-domain-snapshot.c
+++ b/src/libvirt-domain-snapshot.c
@@ -177,8 +177,9 @@ virDomainSnapshotGetConnect(virDomainSnapshotPtr snapshot)
  * the correct image format and metadata including backing store path
  * (this allows a management app to pre-create files with relative backing
  * file names, rather than the default of creating with absolute backing
- * file names). Note that setting incorrect metadata in the pre-created
- * image may lead to the VM being unable to start.
+ * file names). Note that only the file specified in the snapshot XML is
+ * inserted as a snapshot thus setting incorrect metadata in the pre-created
+ * image may lead to the VM being unable to start or other block jobs may fail.
  *
  * Be aware that although libvirt prefers to report errors up front with
  * no other effect, some hypervisors have certain types of failures where

v1.2.14-131-gd567077

Until we properly fix tracking of the backing chain, the steps above will break it but the user is advised not to do that.

Verify this bug with libvirt-1.2.15-2.el7.x86_64

Steps: 

# rpm -qf /usr/src/debug/libvirt-1.2.15/src/libvirt-domain-snapshot.c
libvirt-debuginfo-1.2.15-2.el7.x86_64

# sed -n 177,183p /usr/src/debug/libvirt-1.2.15/src/libvirt-domain-snapshot.c 
 * the correct image format and metadata including backing store path
 * (this allows a management app to pre-create files with relative backing
 * file names, rather than the default of creating with absolute backing
 * file names). Note that only the file specified in the snapshot XML is
 * inserted as a snapshot thus setting incorrect metadata in the pre-created
 * image may lead to the VM being unable to start or other block jobs may fail.
 *

So according the comment, this bug has been fixed from doc sides.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://rhn.redhat.com/errata/RHBA-2015-2202.html