Bug 684793 - Requesting qcow2 allocation should preallocate metadata, currently does nothing?
Summary: Requesting qcow2 allocation should preallocate metadata, currently does nothing?
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt
Version: 7.0
Hardware: Unspecified
OS: Unspecified
low
medium
Target Milestone: rc
: 7.0
Assignee: Ján Tomko
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-03-14 14:23 UTC by Cole Robinson
Modified: 2014-06-18 00:38 UTC (History)
8 users (show)

Fixed In Version: libvirt-1.0.1-1.el7
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-06-13 12:14:41 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Cole Robinson 2011-03-14 14:23:07 UTC
Apparently requesting a fully allocated qcow2 storage volume has no effect. According to:

http://www.ilsistemista.net/index.php/virtualization/11-kvm-io-slowness-on-rhel-6.html?start=6

qemu-img has an option to preallocate qcow2 metadata. We should probably do that so the 'fully allocate' checkbox in virt-manager does something useful.


Looks like the invocation is:

qemu-img create -f qcow2 -o preallocation=metadata

Comment 1 RHEL Program Management 2011-04-04 02:06:37 UTC
Since RHEL 6.1 External Beta has begun, and this bug remains
unresolved, it has been rejected as it is not proposed as
exception or blocker.

Red Hat invites you to ask your support representative to
propose this request, if appropriate and relevant, in the
next release of Red Hat Enterprise Linux.

Comment 5 Ján Tomko 2012-11-14 10:00:27 UTC
I proposed an upstream patch, interpreting non-zero allocation as a request to preallocate metadata, which got rejected:
https://www.redhat.com/archives/libvir-list/2012-November/msg00423.html

Latest version proposes a flag for virStorageVolCreateXML instead.
https://www.redhat.com/archives/libvir-list/2012-November/msg00546.html

Comment 6 Ján Tomko 2012-12-10 11:09:32 UTC
VIR_STORAGE_VOL_CREATE_PREALLOC_METADATA flag has been added upstream by:
commit 1c9a2fb1aef1729ac86cd6648b5c2b7584f5f698
Author:     Ján Tomko <jtomko@redhat.com>
AuthorDate: 2012-12-05 11:48:07 +0100
Commit:     Michal Privoznik <mprivozn@redhat.com>
CommitDate: 2012-12-07 11:46:48 +0100

    storage: allow metadata preallocation when creating qcow2 images
    
    Add VIR_STORAGE_VOL_CREATE_PREALLOC_METADATA flag to virStorageVolCreateXML
    and virStorageVolCreateXMLFrom. This flag requests metadata
    preallocation when creating/cloning qcow2 images, resulting in creating
    a sparse file with qcow2 metadata. It has only slightly larger disk usage
    compared to new image with no allocation, but offers higher performance.

exposed in virsh since:

commit 790dfee5eaf8600282da5a3d61bf807516f1b87e
Author:     Ján Tomko <jtomko@redhat.com>
AuthorDate: 2012-12-05 11:48:08 +0100
Commit:     Michal Privoznik <mprivozn@redhat.com>
CommitDate: 2012-12-07 11:46:48 +0100

    virsh: allow metadata preallocation when creating volumes
    
    Add --prealloc-metadata flag to these commands:
    vol-clone
    vol-create
    vol-create-as
    vol-create-from

Comment 7 zhe peng 2012-12-24 06:38:28 UTC
verify with build:
libvirt-1.0.1-1.el7.x86_64
qemu-kvm-1.2.0-21.el7.x86_64
3.6.0-0.29.el7.x86_64

test vol-create:

step:

1:prepare vol xml file

# cat vol-test.xml
<volume>
  <name>vol-test</name>
  <key>/var/lib/libvirt/images/vol-test</key>
  <source>
  </source>
  <capacity>10737418240</capacity>
  <allocation>3179753472</allocation>
  <target>
    <path>/var/lib/libvirt/images/vol-test</path>
    <format type='qcow2'/>
    <permissions>
      <mode>0644</mode>
      <owner>36</owner>
      <group>36</group>
      <label>system_u:object_r:nfs_t</label>
    </permissions>
  </target>
</volume>

2: # virsh vol-create default vol-test.xml --prealloc-metadata

check img info

# qemu-img info vol-test
image: vol-test
file format: qcow2
virtual size: 10G (10737418240 bytes)                --------check the size same with xml capacity
disk size: 1.7M
cluster_size: 65536

#ll /var/lib/libvirt/images/
-rw-r--r--. 1   36 kvm  10739318784 Dec 21 01:11 vol-test

test vol-create-as:

 step :

1: # virsh vol-create-as default vol-test.qcow2 4194304000 --allocation 3024347136 --format qcow2 --prealloc-metadata

Vol vol-test2.qcow created

check img info

#qemu-img info vol-test.qcow2

image: vol-test2.qcow2
file format: qcow2
virtual size: 3.9G (4194304000 bytes)         ------check the size same with specific
disk size: 720K
cluster_size: 65536

test vol-create-from:

step:

1: prepare vol xml

<volume>
  <name>vol-test3</name>
  <key>/var/lib/libvirt/images/vol-test3</key>
  <source>
  </source>
  <capacity>10737418240</capacity>
  <allocation>3179753472</allocation>
  <target>
    <path>/var/lib/libvirt/images/vol-test3</path>
    <format type='qcow2'/>
    <permissions>
      <mode>0644</mode>
      <owner>36</owner>
      <group>36</group>
      <label>system_u:object_r:nfs_t</label>
    </permissions>
  </target>
</volume>

2:# virsh vol-create-from default vol-test.xml /var/lib/libvirt/images/vol-test2 --prealloc-metadata

vol-test2 is an existing img

check img info

#qemu-img info vol-test3

image: vol-test3
file format: qcow2
virtual size: 10G (10737418240 bytes)     -----check ths size same with xml capacity
disk size: 1.7M
cluster_size: 65536

for vol-clone:

1: # virsh vol-clone /var/lib/libvirt/images/vol-test2 test2_clone2.img --prealloc-metadata

vol-test2 is an existing img

check img info

#qemu-img info test2_clone2.img

image: test2_clone2.img
file format: qcow2
virtual size: 10G (10737418240 bytes)
disk size: 1.7M
cluster_size: 65536

# ll test2_clone2.img

-rw-r--r--. 1 36 kvm 10739318784 Dec 21 03:42 test2_clone2.img

four cmd with --prealloc-metadata flag all worked well , move to verified

Comment 8 Ludek Smid 2014-06-13 12:14:41 UTC
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.


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