Bug 1130739 - cloned qcow2 image file has full size
Summary: cloned qcow2 image file has full size
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: i686
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-08-17 09:01 UTC by Toralf Förster
Modified: 2016-01-22 08:34 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-07-10 07:18:15 UTC


Attachments (Terms of Use)
debug log output (37.83 KB, text/plain)
2014-08-21 15:36 UTC, Toralf Förster
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1298065 None None None Never

Internal Links: 1298065

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@linux.vnet.ibm.com>
AuthorDate: 2015-06-26 17:13:26 +0530
Commit:     Ján Tomko <jtomko@redhat.com>
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@linux.vnet.ibm.com>
    Signed-off-by: Ján Tomko <jtomko@redhat.com>

git describe: v1.2.17-74-gdd519a2


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