thr3ads.net - libvirt users - Re: [libvirt-users] Create qcow2 v3 volumes via libvirt [Apr 2018]

If this information is useful, please help other people find it:
Share via:

Gionatan Danti

2018-Jan-30 12:17 UTC

[libvirt-users] Create qcow2 v3 volumes via libvirt

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.

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

Gionatan Danti

2018-Apr-30 18:42 UTC

head link

Re: [libvirt-users] Create qcow2 v3 volumes via libvirt

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

Daniel P. Berrangé

2018-May-01 08:45 UTC

head link

[libvirt-users] Create qcow2 v3 volumes via libvirt

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.

Either force the use of v3:

  <volume>
    <name>demo.qcow2</name>
    <capacity>1073741824</capacity>
    <target>
      <format type='qcow2'/>
      <compat>1.1</compat>
    </target>
  </volume>

Or request some feature that implies v3:


  <volume>
    <name>demo.qcow2</name>
    <capacity>1073741824</capacity>
    <target>
      <format type='qcow2'/>
      <features>
        <lazy_refcounts/>
      </features>
    </target>
  </volume>

and pass this XML to virsh vol-create

> 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?
The only drawback is OS compatibility. 

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Daniel P. Berrangé

2018-May-01 08:56 UTC

head link

Re: [libvirt-users] Create qcow2 v3 volumes via libvirt

On Mon, Apr 30, 2018 at 08:42:56PM +0200, Gionatan Danti
wrote:> Another question: how reliable are qcow2 ver2/3 files nowadays? Are you
> using them in production environments?
qcow2 is widely used in production at large scale in general. Just not
with internal snapshots - almost everything uses external snapshots,
aka backing file chains.
> 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?
The QEMU community still tends to discourage use of internal snapshots.
There are not even any QMP monitor commands to use them - you are forced
to use the legacy HMP interface to QEMU for mgmt. All of the workaround
providing interesting block storage mgmt is focused on external snapshots
(aka the backing_file option). There are some technical downsides to
internal snapshots IIUC, such as inability to free the space used by the
internal snapshot when it is deleted, loading/saving snapshots blocks
execution of the guest OS, and probably more I've forgotten about.

The only nice thing about internal snapshots is simplicity of mgmt, and
that is a very nice thing indeed, which is why virt-manager has code
to support that - it was much easier to add that code for external
snapshots. Just a shame about all the downsides :-(

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Gianluca Cecchi

2018-May-01 10:35 UTC

head link

Re: [libvirt-users] Create qcow2 v3 volumes via libvirt

On Tue, May 1, 2018 at 10:45 AM, Daniel P. Berrangé <berrange@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@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@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@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@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@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

Possibly Parallel Threads

Search for more apparently analagous threads

libvirt users - Apr 2018 - Re: Create qcow2 v3 volumes via libvirt

[libvirt-users] Create qcow2 v3 volumes via libvirt

Re: [libvirt-users] Create qcow2 v3 volumes via libvirt

[libvirt-users] Create qcow2 v3 volumes via libvirt

Re: [libvirt-users] Create qcow2 v3 volumes via libvirt

Re: [libvirt-users] Create qcow2 v3 volumes via libvirt

Possibly Parallel Threads