Bug 1471138 - Creating VM from template no longer allows specification of Preallocated disks, only "RAW" or "QCOW2"
Creating VM from template no longer allows specification of Preallocated disk...
Status: NEW
Product: ovirt-engine
Classification: oVirt
Component: General (Show other bugs)
4.0
x86_64 Linux
unspecified Severity medium (vote)
: ovirt-4.2.0
: ---
Assigned To: Tal Nisan
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2017-07-14 09:42 EDT by Rolf Fokkens
Modified: 2017-09-28 04:47 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Storage
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.2+


Attachments (Terms of Use)
Choises when creating a new disk: Thin Provision and Preallocated (123.36 KB, image/x-xcf)
2017-07-15 10:18 EDT, Rolf Fokkens
no flags Details
Choises when creating a using a Template: RAW and QCOW2 (59.83 KB, image/png)
2017-07-15 10:19 EDT, Rolf Fokkens
no flags Details

  None (edit)
Description Rolf Fokkens 2017-07-14 09:42:28 EDT
Description of problem:
When creating a new VM using a Template, the Template's disk will be created as Thin-Provisioned whether you choose RAW or QCOW2 does not matter. Prior oVirt releases (e.g.) allowed specification of "Preformatted" or "Thin-Provisioned".

Our installation uses Local storage, so the images are created on XFS.

Version-Release number of selected component (if applicable):
Ovirt Engine 4.0.4.4-1.el7.centos

How reproducible:
100%

Steps to Reproduce:
1. Just create a VM based on a Templated
2. Try to make the disks Preallocated
3. Note that you fail attempting to do so

Actual results:
Always Thin Provisioned disk images on XFS/Local storage

Expected results:
Choice between Thin Provisioned an Preallocated, like oVirt 3.6

Additional info:
Comment 1 Yaniv Kaul 2017-07-14 18:40:41 EDT
RAW on file-based storage is raw-sparse, is that what you are seeing?
Comment 2 Rolf Fokkens 2017-07-15 05:49:35 EDT
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.
Comment 3 Rolf Fokkens 2017-07-15 10:05:47 EDT
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.
Comment 4 Rolf Fokkens 2017-07-15 10:18 EDT
Created attachment 1298908 [details]
Choises when creating a new disk: Thin Provision and Preallocated
Comment 5 Rolf Fokkens 2017-07-15 10:19 EDT
Created attachment 1298909 [details]
Choises when creating a using a Template: RAW and QCOW2
Comment 6 Rolf Fokkens 2017-07-15 10:21:34 EDT
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.
Comment 7 Allon Mureinik 2017-07-16 04:56:42 EDT
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.
Comment 8 Rolf Fokkens 2017-07-16 09:46:57 EDT
I added bug #1471505 which is somewhat related to "XFS & Thin Provisioning"
Comment 9 Yaniv Kaul 2017-07-17 16:02:58 EDT
(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.
Comment 10 Yaniv Kaul 2017-07-17 16:34:32 EDT
(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.
Comment 11 Rolf Fokkens 2017-07-17 16:54:12 EDT
There's a bugzilla report in the XFS issue now: @1471505
Comment 12 Rolf Fokkens 2017-07-17 17:11:28 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.