You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
= Additional hardware requirements for {VirtProductName}
7
-
7
+
= Physical resource overhead requirements
8
8
9
9
{VirtProductName} is an add-on to {product-title} and imposes additional overhead that you must account for when planning a cluster. Each cluster machine must accommodate the following overhead requirements in addition to the {product-title} requirements. Oversubscribing the physical resources in a cluster can affect performance.
If your environment includes a Single Root I/O Virtualization (SR-IOV) network device or a Graphics Processing Unit (GPU), allocate 1 GiB additional memory overhead for each device.
46
45
47
-
48
46
[id="CPU-overhead_{context}"]
49
47
== CPU overhead
50
48
@@ -64,12 +62,10 @@ CPU overhead for worker nodes ≈ 2 cores + CPU overhead per virtual machine
64
62
65
63
Each worker node that hosts virtual machines must have capacity for 2 additional cores (2000 millicores) for {VirtProductName} management workloads in addition to the CPUs required for virtual machine workloads.
66
64
67
-
68
65
.Virtual machine CPU overhead
69
66
70
67
If dedicated CPUs are requested, there is a 1:1 impact on the cluster CPU overhead requirement. Otherwise, there are no specific rules about how many CPUs a virtual machine requires.
Storage overhead per virtual machine depends on specific requests for resource allocation within the virtual machine. The request could be for ephemeral storage on the node or storage resources hosted elsewhere in the cluster. {VirtProductName} does not currently allocate any additional ephemeral storage for the running container itself.
Copy file name to clipboardExpand all lines: virt/install/preparing-cluster-for-virt.adoc
+52-47Lines changed: 52 additions & 47 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,71 +1,84 @@
1
1
:_content-type: ASSEMBLY
2
2
include::_attributes/common-attributes.adoc[]
3
3
[id="preparing-cluster-for-virt"]
4
-
= Configuring your cluster for {VirtProductName}
5
-
:context: preparing-cluster-for-virt
4
+
= Preparing your cluster for {VirtProductName}
5
+
:context: virt-installation-requirements
6
6
7
7
toc::[]
8
8
9
-
Before you install {VirtProductName}, ensure that your {product-title}cluster meets the following requirements:
9
+
Review this section before you install {VirtProductName} to ensure that your cluster meets the requirements.
10
10
11
-
* Your cluster must be installed on
12
-
xref:../../installing/installing_bare_metal/preparing-to-install-on-bare-metal.adoc#installing-bare-metal[on-premise bare metal] infrastructure with {op-system-first} workers. You can use any installation method including user-provisioned, installer-provisioned, or assisted installer to deploy your cluster.
13
-
+
14
-
[NOTE]
11
+
[IMPORTANT]
15
12
====
16
-
{VirtProductName} only supports {op-system} worker nodes. RHEL 7 or RHEL 8 nodes are not supported.
13
+
You can use any installation method, including user-provisioned, installer-provisioned, or assisted installer, to deploy {product-title}. However, the installation method and the cluster topology might affect {VirtProductName} functionality, such as snapshots or live migration.
17
14
====
18
15
19
-
* You can install {VirtProductName} on Amazon Web Services (AWS) bare metal instances. Bare metal instances offered by other cloud providers are not supported.
20
-
+
21
-
--
22
-
ifdef::openshift-enterprise[]
23
-
:FeatureName: Installing OpenShift Virtualization on AWS bare metal instances
You can install {VirtProductName} on a single node cluster, also known as xref:../../installing/installing_sno/install-sno-preparing-to-install-sno.adoc#install-sno-about-installing-on-a-single-node_install-sno-preparing[Single Node OpenShift] (SNO). SNO does not support high availability, which results in the following differences:
28
19
29
-
* Shared storage is required to enable live migration.
20
+
* xref:../../nodes/pods/nodes-pods-priority.adoc#priority-preemption-other_nodes-pods-priority[Pod disruption budgets] are not supported.
21
+
* xref:../../virt/live_migration/virt-live-migration.adoc#virt-live-migration[Live migration] is not supported.
22
+
* Templates or virtual machines that use data volumes or storage profiles must not have the xref:../../virt/live_migration/virt-configuring-vmi-eviction-strategy.adoc#virt-configuring-vmi-eviction-strategy[`evictionStrategy`] set.
30
23
31
-
* You must manage your Compute nodes according to the number and size of the virtual machines that you want to host in the cluster.
24
+
.FIPS mode
32
25
33
-
* If you have limited internet connectivity, you can xref:../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[configure proxy support in Operator Lifecycle Manager] to access the Red Hat-provided OperatorHub. If you are using a restricted network with no internet connectivity, you must xref:../../operators/admin/olm-restricted-networks.adoc#olm-restricted-networks[configure Operator Lifecycle Manager for restricted networks].
26
+
If you install your cluster in xref:../../installing/installing-fips.adoc#installing-fips-mode_installing-fips[FIPS mode], no additional setup is required for {VirtProductName}.
34
27
35
-
* If your cluster uses worker nodes with different CPUs, live migration failures can occur because different CPUs have different capacities. To avoid such failures, use CPUs with appropriate capacity for each node and set node affinity on your virtual machines to ensure successful migration. See xref:../../nodes/scheduling/nodes-scheduler-node-affinity.adoc#nodes-scheduler-node-affinity-configuring-required_nodes-scheduler-node-affinity[Configuring a required node affinity rule] for more information.
* If FIPS mode is xref:../../installing/installing-fips.adoc#installing-fips[enabled for your cluster], no additional setup is needed for {VirtProductName}. Support for FIPS cryptography must be enabled before the operating system that your cluster uses boots for the first time.
== How to maintain high availability of virtual machines
47
+
[id="restricted-networks-environments_{context}"]
48
+
== Restricted network environments
57
49
58
-
There are three options to maintain high availability (HA) of virtual machines:
50
+
If you install {VirtProductName} in a restricted environment with no internet connectivity, you must xref:../../operators/admin/olm-restricted-networks.adoc#olm-restricted-networks[configure Operator Lifecycle Manager for restricted networks].
51
+
52
+
If you have limited internet connectivity, you can xref:../../operators/admin/olm-configuring-proxy-support.adoc#olm-configuring-proxy-support[configure proxy support in Operator Lifecycle Manager] to access the Red Hat-provided OperatorHub.
53
+
54
+
[id="live-migration_{context}"]
55
+
== Live migration
56
+
57
+
Live migration has the following requirements:
58
+
59
+
* Shared storage with `ReadWriteMany` (RWX) access mode
60
+
* Sufficient RAM and network bandwidth
61
+
* Appropriate CPUs with sufficent capacity on the worker nodes. If the CPUs have different capacities, live migration might be very slow or fail.
62
+
63
+
[id="snapshots-and-cloning_{context}"]
64
+
== Snapshots and cloning
65
+
66
+
See xref:../../virt/virtual_machines/virtual_disks/virt-features-for-storage.adoc#virt-features-for-storage[{VirtProductName} storage features] for snapshot and cloning requirements.
67
+
68
+
// The HA section actually belongs to OpenShift, not Virt
You can configure one of the following high-availability (HA) options for your cluster:
59
73
60
74
* Automatic high availability for xref:../../installing/installing_bare_metal_ipi/ipi-install-overview.adoc#ipi-install-overview[installer-provisioned infrastructure] (IPI) is available by deploying xref:../../machine_management/deploying-machine-health-checks.adoc#machine-health-checks-about_deploying-machine-health-checks[machine health checks].
61
75
+
62
76
[NOTE]
63
77
====
64
-
In {VirtProductName} clusters installed using installer-provisioned infrastructure and with MachineHealthCheck properly configured, if a node fails the MachineHealthCheck and becomes unavailable to the cluster, it is recycled. What happens next with VMs that ran on the failed node depends on a series of conditions. See xref:../../virt/virtual_machines/virt-create-vms.adoc#virt-about-runstrategies-vms_virt-create-vms[About RunStrategies for virtual machines] for more detailed information about the potential outcomes and how RunStrategies affect those outcomes.
78
+
In {product-title} clusters installed using installer-provisioned infrastructure and with MachineHealthCheck properly configured, if a node fails the MachineHealthCheck and becomes unavailable to the cluster, it is recycled. What happens next with VMs that ran on the failed node depends on a series of conditions. See xref:../../virt/virtual_machines/virt-create-vms.adoc#virt-about-runstrategies-vms_virt-create-vms[About RunStrategies for virtual machines] for more detailed information about the potential outcomes and how RunStrategies affect those outcomes.
65
79
====
66
80
67
-
68
-
* Automatic high availability for both IPI and non-IPI is available by using the xref:../../nodes/nodes/eco-node-health-check-operator.adoc#node-health-check-operator[Node Health Check Operator] on any {product-title} cluster to deploy the `NodeHealthCheck` controller. The controller identifies unhealthy nodes and uses the Self Node Remediation Operator to remediate the unhealthy nodes.
81
+
* Automatic high availability for both IPI and non-IPI is available by using the xref:../../nodes/nodes/eco-node-health-check-operator.adoc#node-health-check-operator[Node Health Check Operator] on the {product-title} cluster to deploy the `NodeHealthCheck` controller. The controller identifies unhealthy nodes and uses the Self Node Remediation Operator to remediate the unhealthy nodes.
69
82
+
70
83
--
71
84
ifdef::openshift-enterprise[]
@@ -81,11 +94,3 @@ endif::[]
81
94
====
82
95
Without an external monitoring system or a qualified human monitoring node health, virtual machines lose high availability.
0 commit comments