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@xxxxxxxxxx - info@xxxxxxxxxx
GPG public key ID: FF5F32A8
_______________________________________________
libvirt-users mailing list
libvirt-users@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvirt-users
