Bug 1130739

Summary:

cloned qcow2 image file has full size

Product:

[Community] Virtualization Tools

Reporter:

Toralf Förster <toralf.foerster>

Component:

libvirt

Assignee:

Libvirt Maintainers <libvirt-maint>

Status:

CLOSED NEXTRELEASE

QA Contact:

Severity:

medium

Docs Contact:

Priority:

unspecified

Version:

unspecified

CC:

berrange, crobinso, gscrivan, jtomko, rbalakri, toralf.foerster

Target Milestone:

---

Target Release:

---

Hardware:

i686

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2015-07-10 07:18:15 UTC

Type:

Bug

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Attachments:

Description	Flags
debug log output	none

Description Toralf Förster 2014-08-17 09:01:33 UTC

Description of problem:
space wasted

Version-Release number of selected component (if applicable):
1.0.1

How reproducible:


Steps to Reproduce:
1.clone a KVM
2.
3.

Actual results:

n22 /var/lib/libvirt/images # ll
total 13153688
-rw------- 1 root root 8591507456 Aug 16 23:10 Gentoo-clone.qcow2
-rw------- 1 root root 4877910016 Aug 16 23:27 Gentoo.qcow2


Expected results:


Additional info:

Comment 1 Toralf Förster 2014-08-18 19:22:56 UTC

Thinking longer about this it should be rather a request-for-enhancement to offer the option to compress the cloned image by the way.

Comment 2 Ján Tomko 2014-08-21 11:39:46 UTC

I don't think this is a bug in libvirt because libvirt can't even create a fully allocated qcow2 image on request.

Could you share the output of 'virt-manager --debug' when cloning the volume?

Comment 3 Toralf Förster 2014-08-21 15:36:23 UTC

Created attachment 929240 [details]
debug log output

ofc here it is

Comment 4 Ján Tomko 2014-08-25 14:08:05 UTC

Oh, I see, libvirt doesn't know it's a qcow2 volume since virt-manager requests 'raw':
[Thu, 21 Aug 2014 17:29:19 virt-manager 12161] DEBUG (storage:701) Creating storage volume 'Gentoo-clone1.qcow2' with xml:
<volume>
  <name>Gentoo-clone1.qcow2</name>
  <capacity>8591507456</capacity>
  <allocation>2533773312</allocation>
  <target>
    <format type="raw"/>
  </target>
</volume>

And we explicitly set the allocation to the capacity of original:

    /* Make sure allocation is at least as large as the destination cap,
     * to make absolutely sure we copy all possible contents */
    if (newvol->target.allocation < origvol->target.capacity)
        newvol->target.allocation = origvol->target.capacity;

We can't really fulfill the 'allocation' requirement if it's less than the data contained in the source volume.

Maybe treating (allocation < capacity) as "create a sparse volume" or just treating it as a minimum would make sense here and hopefully not break anything.

Comment 5 Ján Tomko 2015-07-10 07:18:15 UTC

Now pushed upstream:
commit dd519a294b22646b8dab26627707a525556df4d4
Author:     Prerna Saxena <prerna.ibm.com>
AuthorDate: 2015-06-26 17:13:26 +0530
Commit:     Ján Tomko <jtomko>
CommitDate: 2015-07-10 08:54:10 +0200

    Fix cloning of raw, sparse volumes
    
    When virsh vol-clone is attempted on a raw file where capacity > allocation,
    the resulting cloned volume has a size that matches the virtual-size of
    the parent; in place of matching its actual, disk size.
    This patch fixes the cloned disk to have same _allocated_size_ as
    the parent file from which it was cloned.
    
    Ref: http://www.redhat.com/archives/libvir-list/2015-May/msg00050.html
    
    Also fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1130739
    
    Signed-off-by: Prerna Saxena <prerna.ibm.com>
    Signed-off-by: Ján Tomko <jtomko>

git describe: v1.2.17-74-gdd519a2