mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
68 lines
2.8 KiB
Plaintext
68 lines
2.8 KiB
Plaintext
// Module included in the following assemblies:
|
|
//
|
|
// * virt/about_virt/virt-supported-limits.adoc
|
|
|
|
:_mod-docs-content-type: REFERENCE
|
|
[id="virt-tested-maximums_{context}"]
|
|
= Tested maximums for {VirtProductName}
|
|
|
|
[role="_abstract"]
|
|
The following limits apply to a large-scale {VirtProductName} 4.x environment. They are based on a single cluster of the largest possible size. When you plan an environment, remember that multiple smaller clusters might be the best option for your use case.
|
|
|
|
[id="vm-maximums_{context}"]
|
|
== Virtual machine maximums
|
|
|
|
The following maximums apply to virtual machines (VMs) running on {VirtProductName}. These values are subject to the limits specified in link:https://access.redhat.com/articles/rhel-kvm-limits[Virtualization limits for Red Hat{nbsp}Enterprise Linux with KVM].
|
|
|
|
[cols="1,1,1",subs="attributes+"]
|
|
|===
|
|
|Objective (per VM) |Tested limit |Theoretical limit
|
|
|
|
|Virtual CPUs |216 vCPUs |255 vCPUs
|
|
|Memory |6 TB |16 TB
|
|
|Single disk size |20 TB |100 TB
|
|
|Hot-pluggable disks |255 disks |N/A
|
|
|===
|
|
|
|
[NOTE]
|
|
====
|
|
Each VM must have at least 512 MB of memory.
|
|
====
|
|
|
|
[id="host-maximums_{context}"]
|
|
== Host maximums
|
|
|
|
The following maximums apply to the {product-title} hosts used for {VirtProductName}.
|
|
|
|
[cols="1,1,1",subs="attributes+"]
|
|
|===
|
|
|Objective (per host) |Tested limit |Theoretical limit
|
|
|
|
|Logical CPU cores or threads |Same as {op-system-base-full} |N/A
|
|
|RAM |Same as {op-system-base} |N/A
|
|
|Simultaneous live migrations |Defaults to 2 outbound migrations per node, and 5 concurrent migrations per cluster |Depends on NIC bandwidth
|
|
|Live migration bandwidth |No default limit |Depends on NIC bandwidth
|
|
|===
|
|
|
|
[id="cluster-maximums_{context}"]
|
|
== Cluster maximums
|
|
|
|
The following maximums apply to objects defined in {VirtProductName}.
|
|
|
|
[cols="1,1,1",subs="attributes+"]
|
|
|===
|
|
|Objective (per cluster) |Tested limit |Theoretical limit
|
|
|
|
|Number of attached PVs per node |N/A |CSI storage provider dependent
|
|
|Maximum PV size |N/A |CSI storage provider dependent
|
|
|Hosts |500 hosts (100 or fewer recommended) ^[1]^ |Same as {product-title}
|
|
|Defined VMs |10,000 VMs ^[2]^ |Same as {product-title}
|
|
|===
|
|
. If you use more than 100 nodes, consider using {rh-rhacm-first} to manage multiple clusters instead of scaling out a single control plane. Larger clusters add complexity, require longer updates, and depending on node size and total object density, they can increase control plane stress.
|
|
+
|
|
Using multiple clusters can be beneficial in areas like per-cluster isolation and high availability.
|
|
. The maximum number of VMs per node depends on the host hardware and resource capacity. It is also limited by the following parameters:
|
|
|
|
* Settings that limit the number of pods that can be scheduled to a node. For example: `maxPods`.
|
|
* The default number of KVM devices. For example: `devices.kubevirt.io/kvm: 1k`.
|