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
Copy file name to clipboardExpand all lines: hosted_control_planes/hcp-deploy/hcp-deploy-virt.adoc
+22-5Lines changed: 22 additions & 5 deletions
Original file line number
Diff line number
Diff line change
@@ -15,18 +15,35 @@ With {hcp} and {VirtProductName}, you can create {product-title} clusters with w
15
15
16
16
The {hcp} feature is enabled by default.
17
17
18
-
You can use the hosted control plane command line interface, hcp, to create an {product-title} hosted cluster. The hosted cluster is automatically imported as a managed cluster. If you want to disable this automatic import feature, see _Disabling the automatic import of hosted clusters into multicluster engine operator_.
18
+
You can use the hosted control plane command line interface, `hcp`, to create an {product-title} hosted cluster. The hosted cluster is automatically imported as a managed cluster. If you want to disable this automatic import feature, see "Disabling the automatic import of hosted clusters into multicluster engine operator".
19
+
20
+
[role="_additional-resources"]
21
+
.Additional resources
22
+
* xref:../../hosted_control_planes/hcp-prepare/hcp-enable-disable.adoc[Enabling or disabling the {hcp} feature]
23
+
* link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#ansible-config-hosted-cluster[Configuring Ansible Automation Platform jobs to run on hosted clusters]
24
+
* xref:../../hosted_control_planes/hcp-import.adoc#hcp-import-disable_hcp-import[Disabling the automatic import of hosted clusters into {mce-short}]
* xref:../../storage/persistent_storage/persistent_storage_local/persistent-storage-using-lvms.adoc[Persistent storage using LVM Storage]
27
-
* To disable the {hcp} feature or, if you already disabled it and want to manually enable it, see xref:../../hosted_control_planes/hcp-prepare/hcp-enable-disable.adoc[Enabling or disabling the {hcp} feature].
28
-
* To manage hosted clusters by running Ansible Automation Platform jobs, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#ansible-config-hosted-cluster[Configuring Ansible Automation Platform jobs to run on hosted clusters].
29
-
* If you want to disable the automatic import feature, see _Disabling the automatic import of hosted clusters into {mce-short}_.
32
+
* xref:../../storage/persistent_storage/persistent_storage_local/persistent-storage-using-lvms.adoc#persistent-storage-using-lvms[Persistent storage using Logical Volume Manager Storage]
* link:https://console.redhat.com/openshift/install/platform-agnostic/user-provisioned[Install OpenShift on any x86_64 platform with user-provisioned infrastructure]
Ensure that you meet the firewall and port requirements so that ports can communicate between the management cluster, the control plane, and hosted clusters:
10
+
11
+
* The `kube-apiserver` service runs on port 6443 by default and requires ingress access for communication between the control plane components.
12
+
13
+
** If you use the `NodePort` publishing strategy, ensure that the node port that is assigned to the `kube-apiserver` service is exposed.
14
+
** If you use MetalLB load balancing, allow ingress access to the IP range that is used for load balancer IP addresses.
15
+
16
+
* If you use the `NodePort` publishing strategy, use a firewall rule for the `ignition-server` and `Oauth-server` settings.
17
+
18
+
* The `konnectivity` agent, which establishes a reverse tunnel to allow bi-directional communication on the hosted cluster, requires egress access to the cluster API server address on port 6443. With that egress access, the agent can reach the `kube-apiserver` service.
19
+
20
+
** If the cluster API server address is an internal IP address, allow access from the workload subnets to the IP address on port 6443.
21
+
** If the address is an external IP address, allow egress on port 6443 to that external IP address from the nodes.
22
+
23
+
* If you change the default port of 6443, adjust the rules to reflect that change.
24
+
* Ensure that you open any ports that are required by the workloads that run in the clusters.
25
+
* Use firewall rules, security groups, or other access controls to restrict access to only required sources. Avoid exposing ports publicly unless necessary.
26
+
* For production deployments, use a load balancer to simplify access through a single IP address.
While the management cluster for hosted cluster virtual machines (VMs) is undergoing updates or maintenance, the hosted cluster VMs can be automatically live migrated to prevent disrupting hosted cluster workloads. As a result, the management cluster can be updated without affecting the availability and operation of the KubeVirt platform hosted clusters.
10
+
11
+
[IMPORTANT]
12
+
====
13
+
The live migration of KubeVirt VMs is enabled by default provided that the VMs use `ReadWriteMany` (RWX) storage for both the root volume and the storage classes that are mapped to the `kubevirt-csi` CSI provider.
14
+
====
15
+
16
+
You can verify that the VMs in a node pool are capable of live migration by checking the `KubeVirtNodesLiveMigratable` condition in the `status` section of a `NodePool` object.
17
+
18
+
In the following example, the VMs cannot be live migrated because RWX storage is not used.
19
+
20
+
.Example configuration where VMs cannot be live migrated
21
+
[source,yaml]
22
+
----
23
+
- lastTransitionTime: "2024-10-08T15:38:19Z"
24
+
message: |
25
+
3 of 3 machines are not live migratable
26
+
Machine user-np-ngst4-gw2hz: DisksNotLiveMigratable: user-np-ngst4-gw2hz is not a live migratable machine: cannot migrate VMI: PVC user-np-ngst4-gw2hz-rhcos is not shared, live migration requires that all PVCs must be shared (using ReadWriteMany access mode)
27
+
Machine user-np-ngst4-npq7x: DisksNotLiveMigratable: user-np-ngst4-npq7x is not a live migratable machine: cannot migrate VMI: PVC user-np-ngst4-npq7x-rhcos is not shared, live migration requires that all PVCs must be shared (using ReadWriteMany access mode)
28
+
Machine user-np-ngst4-q5nkb: DisksNotLiveMigratable: user-np-ngst4-q5nkb is not a live migratable machine: cannot migrate VMI: PVC user-np-ngst4-q5nkb-rhcos is not shared, live migration requires that all PVCs must be shared (using ReadWriteMany access mode)
29
+
observedGeneration: 1
30
+
reason: DisksNotLiveMigratable
31
+
status: "False"
32
+
type: KubeVirtNodesLiveMigratable
33
+
----
34
+
35
+
In the next example, the VMs meet the requirements to be live migrated.
36
+
37
+
.Example configuration where VMs can be live migrated
38
+
[source,yaml]
39
+
----
40
+
- lastTransitionTime: "2024-10-08T15:38:19Z"
41
+
message: "All is well"
42
+
observedGeneration: 1
43
+
reason: AsExpected
44
+
status: "True"
45
+
type: KubeVirtNodesLiveMigratable
46
+
----
47
+
48
+
While live migration can protect VMs from disruption in normal circumstances, events such as infrastructure node failure can result in a hard restart of any VMs that are hosted on the failed node. For live migration to be successful, the source node that a VM is hosted on must be working correctly.
49
+
50
+
When the VMs in a node pool cannot be live migrated, workload disruption might occur on the hosted cluster during maintenance on the management cluster. By default, the {hcp} controllers try to drain the workloads that are hosted on KubeVirt VMs that cannot be live migrated before the VMs are stopped. Draining the hosted cluster nodes before stopping the VMs allows pod disruption budgets to protect workload availability within the hosted cluster.
* The {product-title} management cluster has {VirtProductName}, version 4.14 or later, installed on it. For more information, see "Installing OpenShift Virtualization using the web console".
19
+
* The {product-title} management cluster is on-premise bare metal.
20
+
* The {product-title} management cluster is configured with OVNKubernetes as the default pod network CNI.
21
+
* The {product-title} management cluster has a default storage class. For more information, see "Postinstallation storage configuration". The following example shows how to set a default storage class:
* You have a valid pull secret file for the `quay.io/openshift-release-dev` repository. For more information, see "Install OpenShift on any x86_64 platform with user-provisioned infrastructure".
29
+
* You have installed the hosted control plane command line interface.
30
+
* You have configured a load balancer. For more information, see "Optional: Configuring MetalLB".
31
+
* For optimal network performance, you are using a network maximum transmission unit (MTU) of 9000 or greater on the {product-title} cluster that hosts the KubeVirt virtual machines. If you use a lower MTU setting, network latency and the throughput of the hosted pods are affected. Enable multiqueue on node pools only when the MTU is 9000 or greater.
32
+
33
+
* The {mce-short} has at least one managed {product-title} cluster. The `local-cluster` is automatically imported. For more information about the `local-cluster`, see "Advanced configuration" in the {mce-short} documentation. You can check the status of your hub cluster by running the following command:
34
+
+
35
+
[source,terminal]
36
+
----
37
+
$ oc get managedclusters local-cluster
38
+
----
39
+
40
+
* On the {product-title} cluster that hosts the {VirtProductName} virtual machines, you are using a `ReadWriteMany` (RWX) storage class so that live migration can be enabled.
Copy file name to clipboardExpand all lines: modules/hcp-virt-reqs.adoc
+1-56Lines changed: 1 addition & 56 deletions
Original file line number
Diff line number
Diff line change
@@ -12,59 +12,4 @@ As you prepare to deploy {hcp} on {VirtProductName}, consider the following info
12
12
* Each hosted cluster must have a cluster-wide unique name. A hosted cluster name cannot be the same as any existing managed cluster in order for {mce-short} to manage it.
13
13
* Do not use `clusters` as a hosted cluster name.
14
14
* A hosted cluster cannot be created in the namespace of a {mce-short} managed cluster.
15
-
* When you configure storage for {hcp}, consider the recommended etcd practices. To ensure that you meet the latency requirements, dedicate a fast storage device to all hosted control plane etcd instances that run on each control-plane node. You can use LVM storage to configure a local storage class for hosted etcd pods. For more information, see _Recommended etcd practices_ and _Persistent storage using logical volume manager storage_.
16
-
17
-
[id="hcp-virt-prereqs_{context}"]
18
-
== Prerequisites
19
-
20
-
You must meet the following prerequisites to create an {product-title} cluster on {VirtProductName}:
21
-
22
-
* You need administrator access to an {product-title} cluster, version 4.14 or later, specified by the `KUBECONFIG` environment variable.
23
-
* The {product-title} hosting cluster must have wildcard DNS routes enabled, as shown in the following DNS:
* The {product-title} hosting cluster must have {VirtProductName}, version 4.14 or later, installed on it. For more information, see xref:../../virt/install/installing-virt.adoc#installing-virt-web[Installing OpenShift Virtualization using the web console].
30
-
* The {product-title} hosting cluster must be configured with OVNKubernetes as the default pod network CNI.
31
-
* The {product-title} hosting cluster must have a default storage class. For more information, see xref:../../post_installation_configuration/post-install-storage-configuration.adoc#post-install-storage-configuration[Postinstallation storage configuration]. The following example shows how to set a default storage class:
* You need a valid pull secret file for the `quay.io/openshift-release-dev` repository. For more information, see link:https://console.redhat.com/openshift/install/platform-agnostic/user-provisioned[Install OpenShift on any x86_64 platform with user-provisioned infrastructure].
39
-
* You need to install the hosted control plane command line interface.
40
-
* Before you can provision your cluster, you need to configure a load balancer. For more information, see _Optional: Configuring MetalLB_.
41
-
* For optimal network performance, use a network maximum transmission unit (MTU) of 9000 or greater on the {product-title} cluster that hosts the KubeVirt virtual machines. If you use a lower MTU setting, network latency and the throughput of the hosted pods are affected. Enable multiqueue on node pools only when the MTU is 9000 or greater.
42
-
43
-
* The {mce-short} must have at least one managed {product-title} cluster. The `local-cluster` is automatically imported. For more information about the `local-cluster`, see link:https://docs.redhat.com/en/documentation/red_hat_advanced_cluster_management_for_kubernetes/2.12/html/clusters/cluster_mce_overview#advanced-config-engine[Advanced configuration] in the {mce-short} documentation. You can check the status of your hub cluster by running the following command:
44
-
+
45
-
[source,terminal]
46
-
----
47
-
$ oc get managedclusters local-cluster
48
-
----
49
-
50
-
[id="hcp-virt-firewall-port_{context}"]
51
-
== Firewall and port requirements
52
-
53
-
Ensure that you meet the firewall and port requirements so that ports can communicate between the management cluster, the control plane, and hosted clusters:
54
-
55
-
* The `kube-apiserver` service runs on port 6443 by default and requires ingress access for communication between the control plane components.
56
-
57
-
** If you use the `NodePort` publishing strategy, ensure that the node port that is assigned to the `kube-apiserver` service is exposed.
58
-
** If you use MetalLB load balancing, allow ingress access to the IP range that is used for load balancer IP addresses.
59
-
60
-
* If you use the `NodePort` publishing strategy, use a firewall rule for the `ignition-server` and `Oauth-server` settings.
61
-
62
-
* The `konnectivity` agent, which establishes a reverse tunnel to allow bi-directional communication on the hosted cluster, requires egress access to the cluster API server address on port 6443. With that egress access, the agent can reach the `kube-apiserver` service.
63
-
64
-
** If the cluster API server address is an internal IP address, allow access from the workload subnets to the IP address on port 6443.
65
-
** If the address is an external IP address, allow egress on port 6443 to that external IP address from the nodes.
66
-
67
-
* If you change the default port of 6443, adjust the rules to reflect that change.
68
-
* Ensure that you open any ports that are required by the workloads that run in the clusters.
69
-
* Use firewall rules, security groups, or other access controls to restrict access to only required sources. Avoid exposing ports publicly unless necessary.
70
-
* For production deployments, use a load balancer to simplify access through a single IP address.
15
+
* When you configure storage for {hcp}, consider the recommended etcd practices. To ensure that you meet the latency requirements, dedicate a fast storage device to all hosted control plane etcd instances that run on each control-plane node. You can use LVM storage to configure a local storage class for hosted etcd pods. For more information, see "Recommended etcd practices" and "Persistent storage using Logical Volume Manager storage".
0 commit comments