Bug 1336367 - [z-stream clone - 3.6.7] Growing backing file length in qcow2 header causes 'Backing file name too long' error.
Summary: [z-stream clone - 3.6.7] Growing backing file length in qcow2 header causes '...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: vdsm
Version: 3.6.5
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ovirt-3.6.7
: 3.6.7
Assignee: Adam Litke
QA Contact: Elad
URL:
Whiteboard:
Depends On: 1333627
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-05-16 09:39 UTC by rhev-integ
Modified: 2021-08-30 12:10 UTC (History)
18 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, when creating snapshots the backing volume reference included an image directory component. Each time a snapshot was merged, the image directory component of the backing volume reference was duplicated until the backing volume reference became too long. In this state the image could not be used. Now, since all volumes of an image always reside in the same directory, the image directory component has been removed from new backing volume references. Now the backing volume references do not grow in length after snapshots are merged.
Clone Of: 1333627
Environment:
Last Closed: 2016-06-29 16:22:42 UTC
oVirt Team: Storage
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHV-43206 0 None None None 2021-08-30 12:10:30 UTC
Red Hat Knowledge Base (Solution) 2298331 0 None None None 2016-05-16 09:39:55 UTC
Red Hat Product Errata RHBA-2016:1365 0 normal SHIPPED_LIVE vdsm 3.6.7 bug fix and enhancement update 2016-06-29 20:19:18 UTC
oVirt gerrit 57284 0 master MERGED storage: Do not reference image dir in backing volume path 2021-01-12 09:58:14 UTC
oVirt gerrit 57419 0 ovirt-3.6 MERGED storage: Do not reference image dir in backing volume path 2021-01-12 09:58:11 UTC
oVirt gerrit 83124 0 master MERGED core: Remove check for max images in chain 2021-01-12 09:58:14 UTC

Comment 2 Elad 2016-06-13 11:47:21 UTC
Steps:

1. Created a VM with 1 Disk, Raw (iSCSI preallocated)
2. Snapshot it 3 times:
   (Base) [A] <- [B] <- [C] <- [D] (Leaf)
3. Removed B


The backing file is the image id:

[root@blond-vdsf c51bf8d8-c508-4f42-8857-5a8d2a7d3774]# pwd
/rhev/data-center/mnt/blockSD/2fdf22e8-b272-4795-a940-34ecd57af2c6/images/c51bf8d8-c508-4f42-8857-5a8d2a7d3774
[root@blond-vdsf c51bf8d8-c508-4f42-8857-5a8d2a7d3774]# tree
.
├── 16ab7f99-966b-4620-b7ef-aaed31e3d83f -> /dev/2fdf22e8-b272-4795-a940-34ecd57af2c6/16ab7f99-966b-4620-b7ef-aaed31e3d83f
├── 77f9a5c0-a628-4772-a9b3-512758b318d3 -> /dev/2fdf22e8-b272-4795-a940-34ecd57af2c6/77f9a5c0-a628-4772-a9b3-512758b318d3
└── f42045f2-d5f7-4c7d-85e7-bc967f6f1c78 -> /dev/2fdf22e8-b272-4795-a940-34ecd57af2c6/f42045f2-d5f7-4c7d-85e7-bc967f6f1c78

0 directories, 3 files




[root@blond-vdsf c51bf8d8-c508-4f42-8857-5a8d2a7d3774]# qemu-img info 16ab7f99-966b-4620-b7ef-aaed31e3d83f
image: 16ab7f99-966b-4620-b7ef-aaed31e3d83f
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 0
cluster_size: 65536
backing file: f42045f2-d5f7-4c7d-85e7-bc967f6f1c78
backing file format: qcow2
Format specific information:
    compat: 0.10
    refcount bits: 16



======================
The VM is fully operational.
======================

Verified using:
vdsm-4.17.31-0.el7ev.noarch
rhevm-3.6.7.2-0.1.el6.noarch

Comment 3 Elad 2016-06-13 12:29:22 UTC
Correction: the backing file (f42045f2-d5f7-4c7d-85e7-bc967f6f1c78) is snapshot B as expected.

Comment 4 Allon Mureinik 2016-06-13 12:43:18 UTC
Clonned doctext from the 4.0 bug

Comment 6 errata-xmlrpc 2016-06-29 16:22:42 UTC
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://access.redhat.com/errata/RHBA-2016:1365


Note You need to log in before you can comment on or make changes to this bug.