[libvirt-users] Create qcow2 v3 volumes via libvirt

Gianluca Cecchi gianluca.cecchi at gmail.com
Tue May 1 10:35:05 UTC 2018


On Tue, May 1, 2018 at 10:45 AM, Daniel P. Berrangé <berrange at redhat.com>
wrote:

> On Tue, Jan 30, 2018 at 01:17:21PM +0100, Gionatan Danti wrote:
> > Hi all,
> > on a fully patched CentOS 7.4 x86-64, I see the following behavior:
> >
> > - when creating a new volumes using vol-create-as, the resulting file is
> a
> > qcow2 version 2 (compat=0.10) file. Example:
> >
> > [root at gdanti-lenovo vmimages]# virsh vol-create-as default zzz.qcow2
> > 8589934592 --format=qcow2 --backing-vol /mnt/vmimages/centos6.img
> > Vol zzz.qcow2 created
>
> Yes, for sake of backcompat we default to v2 unless something
> requires v3. You can't use vol-create-as to create a v3 image,
> you need to use the XML input.
>


BTW: in virt-manager of CentOS 7.4 by default qcow2 disks (see below for
zzz3.qcow2) are created with compatibility 1.1 (probably indirectly because
of its lazy refcounts feature enabled, as Daniel wrote):

[root at c7client images]# qemu-img info zzz3.qcow2
image: zzz3.qcow2
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 516K
cluster_size: 65536
Format specific information:
    compat: 1.1
    lazy refcounts: true
[root at c7client images]#

The same if I create a volume with a backing file from virt-manager (not
important if this is 0.10 or 1.1):

[root at c7client images]# qemu-img info zzz4.qcow2
image: zzz4.qcow2
file format: qcow2
virtual size: 1.0G (1073741824 bytes)
disk size: 196K
cluster_size: 65536
backing file: /var/lib/libvirt/images/zzz2.qcow2
backing file format: qcow2
Format specific information:
    compat: 1.1
    lazy refcounts: true
[root at c7client images]#


But I don't know if internally virt-manager uses virsh or qemu-img
actually....

My tests with:
libvirt-client-3.2.0-14.el7_4.9.x86_64
virt-manager-1.4.1-7.el7.noarch

The same default to 0.10 format seems true with virsh from Fedora 27 and
libvirt-client-3.7.0-4.fc27.x86_64

Gianluca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/libvirt-users/attachments/20180501/5d968d49/attachment.htm>


More information about the libvirt-users mailing list