Additional information:  internally, the backing file chain is may be put together by the concatenation of many pathname strings, if the filename paths are relative paths.  If this exceeds PATH_MAX (4096 under RHEL), then we will fail to either open or create snapshot images.

Note that this is not necessarily the same as the filename character limit found in the image header (e.g., the header in a qcow2 file).  While if that is too long we may have similar issues, the backing file character length issue is different because the block layer builds up the backing file pathname string dynamically on image open.

See BZ 1067576 for more information, as well as for steps on how to replicate the issue (attachment #867573 [details]).

The final long-term solution is likely to be dynamically allocating backing file and filename strings internally, and perhaps also flattening redundant relative pathname strings.

Moving to 7.2 - this is for the long-term solution, whereas BZ 1117170 is for the more immediate term solution for 7.1  This is also a RHEV bug, instead of a RHEL bug.

*** Bug 1186989 has been marked as a duplicate of this bug. ***

Does BZ 1333627 also fixes this?

That is, replacing "../<img>/<vol>" with "<vol>" in backing file field of qcow2 header.

https://gerrit.ovirt.org/#/c/57284/

(In reply to Germano Veit Michel from comment #6)
> Does BZ 1333627 also fixes this?
> 
> That is, replacing "../<img>/<vol>" with "<vol>" in backing file field of
> qcow2 header.
> 
> https://gerrit.ovirt.org/#/c/57284/

It mitigates the need to make any changes in qemu so yes we can probably close this.

Closing this (WONTFIX), per Comment #6 and Comment #7.  Fixing it in the upper layers so the condition doesn't occur is the proper solution, as well.