Description of problem:
In a cluster installed with IPI on RHV, all VMs are created with thin disks that are dependent on the template. I open this RFE to request adding an option to create the disks as preallocated, so the OS disk will be cloned from the template to a preallocated disk.
The preallocated disks will consume more space, but have a better performance and can avoid some problems like running out of space in the storage domain or that the VM is paused during high IO writes due to RHV's mechanism of expansion of the thin disks
I see this feature especially important for the master nodes.
RHEV doesn't support creating templates with pre-allocated disks on file-based storage .
we can check the feasibility on block storage, will that help?
(In reply to Evgeny Slutsky from comment #1)
> RHEV doesn't support creating templates with pre-allocated disks on
> file-based storage .
The template can be thin provisioned, that's not a problem. What I'm requesting is creating the VMs from the template using the "clone" option, as opposed to the "thin" option that it's used now. That will create a full copy of the template disk that you can choose to be preallocated (raw). See the RHV documentation:
(In reply to Juan Orti from comment #2)
> (In reply to Evgeny Slutsky from comment #1)
> > RHEV doesn't support creating templates with pre-allocated disks on
> > file-based storage .
> The template can be thin provisioned, that's not a problem. What I'm
> requesting is creating the VMs from the template using the "clone" option,
> as opposed to the "thin" option that it's used now. That will create a full
> copy of the template disk that you can choose to be preallocated (raw). See
> the RHV documentation:
Yes, from my experiments with RHV that also doesn't work on file-based storage (NFS). @nir can you elaborate on that?
I've just tested with NFS storage selecting to clone from template and use raw disk, and it's true that the disk is created as thin provisioned. However the resulting disk image is in raw format and and the whole file size is allocated:
# egrep '^FORMAT|^TYPE' a98549af-0853-42fc-b2a2-33e1bfe97ae4.meta
# qemu-img info a98549af-0853-42fc-b2a2-33e1bfe97ae4
file format: raw
virtual size: 5 GiB (5368709120 bytes)
disk size: 640 MiB
So in my opinion this will also be a performance gain and will guarantee that all the space is available when using file-based SDs.
(In reply to Juan Orti from comment #4)
> I've just tested with NFS storage selecting to clone from template and use
> raw disk, and it's true that the disk is created as thin provisioned.
> However the resulting disk image is in raw format and and the whole file
> size is allocated:
> # egrep '^FORMAT|^TYPE' a98549af-0853-42fc-b2a2-33e1bfe97ae4.meta
> # qemu-img info a98549af-0853-42fc-b2a2-33e1bfe97ae4
> image: a98549af-0853-42fc-b2a2-33e1bfe97ae4
> file format: raw
> virtual size: 5 GiB (5368709120 bytes)
> disk size: 640 MiB
> So in my opinion this will also be a performance gain and will guarantee
> that all the space is available when using file-based SDs.
its thin indeed..
if it was preallocated: disk size >= virtual size
let's stop mixing separate concepts
A VM created from a template can be created with (in webadmin UI) "Storage Allocation" "Thin" or "Clone, which crates a linked (thin qcow on top of template base) or independent(full copy) disks. For API see https://github.com/oVirt/ovirt-engine-api-model/blob/master/src/main/java/services/VmsService.java#L229
For linked VMs qcow is the only option
For independent VMs the disk "Format" can be selected, "qcow" or "raw"
Separately, the disk can be allocated as "sparse/thin provisioned" or "preallocated"
Depending on the type of the storage domain not all combinations are possible. Also UI and API is limiting the combinations.
The dependent bugs 2056454 and 2056460 have now been created for the component implementations in the installer and the cluster API provider, respectively. The documentation updates will be tracked in those Bugzilla entries.
This Bugzilla will be updated once all necessary components have been merged and the feature is available in nightly builds.
All components needed for this RFE have now been either merged or have a pending PR, moving to POST.
Verified on - OCP version: 4.11.0-0.nightly-2022-05-18-053037
Platform: RHV 22.214.171.124-0.7.el8ev
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Important: OpenShift Container Platform 4.11.0 bug fix and security update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.