Bug 2035334
Summary: | [RFE] [OCPonRHV] Provision machines with preallocated disks | ||
---|---|---|---|
Product: | OpenShift Container Platform | Reporter: | Juan Orti <jortialc> |
Component: | Installer | Assignee: | Janos Bonic <jpasztor> |
Installer sub component: | OpenShift on RHV | QA Contact: | Veronika Fuxova <vfuxova> |
Status: | CLOSED ERRATA | Docs Contact: | Eli Marcus <emarcus> |
Severity: | high | ||
Priority: | high | CC: | calfonso, emarcus, eslutsky, jpasztor, mburman, michal.skrivanek, mjankula, mkalinin, nsoffer, ocprhvteam, pelauter, ykaul |
Version: | 4.8 | Keywords: | FutureFeature |
Target Milestone: | --- | ||
Target Release: | 4.11.0 | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: |
Feature: OpenShift on RHV installation now supports preallocated disks
Reason: In high load environments preallocated disks can bring benefits in terms of performance for etcd and other OpenShift components.
Result: As requested in this RFE, the OpenShift installation on RHV now supports provisioning preallocated disks for control plane and worker nodes in case of an IPI installation. Please see the OpenShift documentation for details on enabling preallocation.
|
Story Points: | --- |
Clone Of: | Environment: | ||
Last Closed: | 2022-08-10 10:41:05 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: | |||
Bug Depends On: | 2056454, 2056460, 2078895, 2082535 | ||
Bug Blocks: |
Description
Juan Orti
2021-12-23 16:10:09 UTC
RHEV doesn't support creating templates with pre-allocated disks on file-based storage [0]. we can check the feasibility on block storage, will that help? [0] https://access.redhat.com/solutions/3369061 (In reply to Evgeny Slutsky from comment #1) > RHEV doesn't support creating templates with pre-allocated disks on > file-based storage [0]. 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: https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/html/virtual_machine_management_guide/creating_a_cloned_virtual_machine_based_on_a_template (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 [0]. > > 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: > > https://access.redhat.com/documentation/en-us/red_hat_virtualization/4.4/ > html/virtual_machine_management_guide/ > creating_a_cloned_virtual_machine_based_on_a_template 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 FORMAT=RAW TYPE=SPARSE # 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. (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 > FORMAT=RAW > TYPE=SPARSE > > # 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 4.5.0.6-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. https://access.redhat.com/errata/RHSA-2022:5069 |