Bug 1471138

RAW on file-based storage is raw-sparse, is that what you are seeing?

You are right For example, the following image file is the result of "the issue":

[root@tghkvm21 0c9f9f33-72be-457d-a695-da57592c6402]# ls -lh
total 4.4G
-rw-rw----. 1 vdsm kvm  64G Jul 15 11:43 6cc44c6d-aece-414f-835f-82b652536061
-rw-rw----. 1 vdsm kvm 1.0M Jul 14 10:37 6cc44c6d-aece-414f-835f-82b652536061.lease
-rw-r--r--. 1 vdsm kvm  317 Jul 14 19:58 6cc44c6d-aece-414f-835f-82b652536061.meta
[root@tghkvm21 0c9f9f33-72be-457d-a695-da57592c6402]# du -h 6cc44c6d-aece-414f-835f-82b652536061
4.4G	6cc44c6d-aece-414f-835f-82b652536061
[root@tghkvm21 0c9f9f33-72be-457d-a695-da57592c6402]# 

In ovirt engine it is identified as "Allocation Policy" "Thin Provision".

We did some experimenting with raw-sparse in the past, but ran into this issue:

https://blog.codecentric.de/en/2017/04/xfs-possible-memory-allocation-deadlock-kmem_alloc/

Very large (multi TB) sparse disk images ran into fragmentation over time, breaking xfs. We never reported at bugzilla, because we could easily get around this issue by using Preallocated disk images.

I verified on oVirt 4.1: samen issue. For us is is aan issue, because raw-sparse is not an option for the mentioned stability reasons.

Created attachment 1298908 [details]
Choises when creating a new disk: Thin Provision and Preallocated

Created attachment 1298909 [details]
Choises when creating a using a Template: RAW and QCOW2

Actually it's weird:

* when creating a new disk the options are offered "Preallocated" and "Thin Provision".
* when creating a VM based on a template the options are offered "RAW" and "QCOW2"

To me this doesn't make sense: they're both about creating a disk.

This was actually an intentional change.
Yaniv, let's revisit this decision for 4.2 and see what we're doing here.

I wonder if we have a reasonable way of forcing a disk to be preallocated.

I added bug #1471505 which is somewhat related to "XFS & Thin Provisioning"

(In reply to Rolf Fokkens from comment #2)
> You are right For example, the following image file is the result of "the
> issue":
> 
> [root@tghkvm21 0c9f9f33-72be-457d-a695-da57592c6402]# ls -lh
> total 4.4G
> -rw-rw----. 1 vdsm kvm  64G Jul 15 11:43 6cc44c6d-aece-414f-835f-82b652536061
> -rw-rw----. 1 vdsm kvm 1.0M Jul 14 10:37
> 6cc44c6d-aece-414f-835f-82b652536061.lease
> -rw-r--r--. 1 vdsm kvm  317 Jul 14 19:58
> 6cc44c6d-aece-414f-835f-82b652536061.meta
> [root@tghkvm21 0c9f9f33-72be-457d-a695-da57592c6402]# du -h
> 6cc44c6d-aece-414f-835f-82b652536061
> 4.4G	6cc44c6d-aece-414f-835f-82b652536061
> [root@tghkvm21 0c9f9f33-72be-457d-a695-da57592c6402]# 
> 
> In ovirt engine it is identified as "Allocation Policy" "Thin Provision".
> 
> We did some experimenting with raw-sparse in the past, but ran into this
> issue:
> 
> https://blog.codecentric.de/en/2017/04/xfs-possible-memory-allocation-
> deadlock-kmem_alloc/
> 
> Very large (multi TB) sparse disk images ran into fragmentation over time,
> breaking xfs. We never reported at bugzilla, because we could easily get
> around this issue by using Preallocated disk images.

I think it's critical to provide a bugzilla report on XFS about this.

(In reply to Allon Mureinik from comment #7)
> This was actually an intentional change.
> Yaniv, let's revisit this decision for 4.2 and see what we're doing here.
> 
> I wonder if we have a reasonable way of forcing a disk to be preallocated.

I would like to believe that at least for file-system level, using 'fallocate' would suffice ( https://bugzilla.redhat.com/show_bug.cgi?id=1391859 ). So in this case we'll move from raw-sparse to raw-sparse on fallocated space.

There's a bugzilla report in the XFS issue now: @1471505

Regarding fallocate: plain fallocate reserves space, but does nog create a disk layout for the data until needed, see #1129205

So there will be a risk of considerable fragmentation, resulting in potential performance issues and (apparently) potential XFS kmem_alloc issues. And apart from the kmem_alloc issue: as a user I really need the option to choose true Preallocation for performance reasons.

VM template can be created now with raw-preallocated file disk via REST-API only. 

When creating VM template using the UI the following rules will take place:
 - QCow -> always SPARSE

 - RAW + File -> SPARSE - there is no actual benefit to create template disk as 
   preallocation regards to the i/o and the disk creation time.

 - RAW + Block -> PREALLOCATED

An RFE is created in order to discuss whether we need to add the option to choose the disk allocation policy in the UI when creating a VM template (bug 1573413).

*** Bug 1616445 has been marked as a duplicate of this bug. ***

Referenced in VDSM v4.30.3 despite this bug is on ovirt-engine product.

Verified on 4.3.0-0.4.master.20190106162157.gitd96a412.el7.

Created via REST VM template both options:
- raw-preallocated file disk.
- raw-thin file disk.

This bugzilla is included in oVirt 4.3.0 release, published on February 4th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.0 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.