[prev in list] [next in list] [prev in thread] [next in thread] 

List:       libvirt-users
Subject:    Re: [libvirt-users] Create qcow2 v3 volumes via libvirt
From:       Gionatan Danti <g.danti () assyoma ! it>
Date:       2018-04-30 18:42:56
Message-ID: 4c544b76d5b62ba7f915d7043c22d453 () assyoma ! it
[Download RAW message or body]

Il 30-01-2018 13:17 Gionatan Danti ha scritto:
> 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@gdanti-lenovo vmimages]# virsh vol-create-as default zzz.qcow2
> 8589934592 --format=qcow2 --backing-vol /mnt/vmimages/centos6.img
> Vol zzz.qcow2 created
> [root@gdanti-lenovo vmimages]# file zzz.qcow2
> zzz.qcow2: QEMU QCOW Image (v2), has backing file (path
> /mnt/vmimages/centos6.img), 8589934592 bytes
> [root@gdanti-lenovo vmimages]# qemu-img info zzz.qcow2
> image: zzz.qcow2
> file format: qcow2
> virtual size: 8.0G (8589934592 bytes)
> disk size: 196K
> cluster_size: 65536
> backing file: /mnt/vmimages/centos6.img
> backing file format: raw
> Format specific information:
>     compat: 0.10
>     refcount bits: 16
> 
> - when creating a snapshot, the resulting file is a qcow2 version 3
> (comapt=1.1) file. Example:
> 
> [root@gdanti-lenovo vmimages]# virsh snapshot-create-as centos6left
> --disk-only --no-metadata snap.qcow2
> Domain snapshot snap.qcow2 created
> [root@gdanti-lenovo vmimages]# file centos6left.snap.qcow2
> centos6left.snap.qcow2: QEMU QCOW Image (v3), has backing file (path
> /mnt/vmimages/centos6left.qcow2), 8589934592 bytes
> [root@gdanti-lenovo vmimages]# qemu-img info centos6left.snap.qcow2
> image: centos6left.snap.qcow2
> file format: qcow2
> virtual size: 8.0G (8589934592 bytes)
> disk size: 196K
> cluster_size: 65536
> backing file: /mnt/vmimages/centos6left.qcow2
> backing file format: qcow2
> Format specific information:
>     compat: 1.1
>     lazy refcounts: false
>     refcount bits: 16
>     corrupt: false
> 
> From what I know, this is a deliberate decision: compat=1.1 requires
> relatively recent qemu version, and creating a new volume play on the
> "safe side" of compatibility.
> 
> It is possible to create a new volume using qcow2 version 3
> (compat=1.1) format *using libvirt/virsh* (I know I can do that via
> qemu-img)? Any drawback on using version 3 format?
> 
> Thanks.

Hi all,
anyone with some thoughts on the matter?

Another question: how reliable are qcow2 ver2/3 files nowadays? Are you 
using them in production environments?
At the moment, I am using RAW files and filesystem-level snapshot to 
manage versioning; however, as virt-manager has direct support for 
managing qcow2 internal snapshots, it would be easier to deploy qcow2 
disks.

What strikes me is that, if thing have not changed, Red Hat support 
policy was to *not* support internal snapshots. So, are they reliable 
enough for production VMs?

Thanks.

-- 
Danti Gionatan
Supporto Tecnico
Assyoma S.r.l. - www.assyoma.it
email: g.danti@assyoma.it - info@assyoma.it
GPG public key ID: FF5F32A8

_______________________________________________
libvirt-users mailing list
libvirt-users@redhat.com
https://www.redhat.com/mailman/listinfo/libvirt-users
[prev in list] [next in list] [prev in thread] [next in thread]