Skip to content

Commit a1d0e34

Browse files
authored
Merge pull request #101620 from danielclowers/CNV-57760_2-dclowers
CNV-57760_2-dclowers: DOC: cross-cluster VM migrations TP
2 parents dbfc28d + 24f5bb2 commit a1d0e34

8 files changed

+388
-0
lines changed

_topic_maps/_topic_map.yml

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -5013,6 +5013,12 @@ Topics:
50135013
File: virt-configuring-live-migration
50145014
- Name: Initiating and canceling live migration
50155015
File: virt-initiating-live-migration
5016+
- Name: Enabling cross-cluster live migration for virtual machines
5017+
File: virt-enabling-cclm-for-vms
5018+
- Name: Configuring a cross-cluster live migration network
5019+
File: virt-configuring-cross-cluster-live-migration-network
5020+
- Name: About Migration Toolkit for Virtualization providers
5021+
File: virt-about-mtv-providers
50165022
# Node maintenance mode
50175023
- Name: Nodes
50185024
Dir: nodes
Lines changed: 32 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,32 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * virt/live_migration/virt-about-mtv-providers.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="virt-configuring-root-ca-for-providers_{context}"]
7+
= Configuring the root certificate authority for providers
8+
9+
[role="_abstract"]
10+
You must configure an {product-title} provider for each cluster that you are including in the migration, and each provider requires a certificate authority (CA) for the cluster. It is important to configure the root CA for the entire cluster to avoid CA expiration, which causes the provider to fail.
11+
12+
.Procedure
13+
14+
. Run the following command against the cluster for which you are creating the provider:
15+
+
16+
[source,terminal]
17+
----
18+
$ oc get cm kube-root-ca.crt -o=jsonpath={.data.ca\\.crt}
19+
----
20+
21+
. Copy the printed certificate.
22+
23+
. In the {mtv-first} web console, create a provider and select *{VirtProductName}*.
24+
25+
. Paste the certificate into the *CA certificate* field, as shown in the following example:
26+
+
27+
[source,terminal]
28+
----
29+
-----BEGIN CERTIFICATE-----
30+
<CA_certificate_content>
31+
-----END CERTIFICATE-----
32+
----
Lines changed: 188 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,188 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * virt/live_migration/virt-about-mtv-providers.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="virt-creating-long-lived-account-and-token_{context}"]
7+
== Creating the long-lived service account and token to use with MTV providers
8+
9+
[role="_abstract"]
10+
When you register an {VirtProductName} provider in the {mtv-first} web console, you must supply credentials that allow MTV to interact with the cluster. Creating a long-lived service account and cluster role binding gives MTV persistent permissions to read and create virtual machine resources during migration.
11+
12+
.Procedure
13+
14+
. Create the cluster role as shown in the following example:
15+
+
16+
[source,yaml]
17+
----
18+
apiVersion: rbac.authorization.k8s.io/v1
19+
kind: ClusterRole
20+
metadata:
21+
name: live-migration-role
22+
rules:
23+
- apiGroups:
24+
- forklift.konveyor.io
25+
resources:
26+
- '*'
27+
verbs:
28+
- get
29+
- list
30+
- watch
31+
- apiGroups:
32+
- ""
33+
resources:
34+
- secrets
35+
- namespaces
36+
- configmaps
37+
- persistentvolumes
38+
- persistentvolumeclaims
39+
verbs:
40+
- get
41+
- list
42+
- watch
43+
- create
44+
- update
45+
- patch
46+
- delete
47+
- apiGroups:
48+
- k8s.cni.cncf.io
49+
resources:
50+
- network-attachment-definitions
51+
verbs:
52+
- get
53+
- list
54+
- watch
55+
- apiGroups:
56+
- storage.k8s.io
57+
resources:
58+
- storageclasses
59+
verbs:
60+
- get
61+
- list
62+
- watch
63+
- apiGroups:
64+
- kubevirt.io
65+
resources:
66+
- virtualmachines
67+
- virtualmachines/finalizers
68+
- virtualmachineinstancemigrations
69+
verbs:
70+
- get
71+
- list
72+
- watch
73+
- create
74+
- update
75+
- patch
76+
- delete
77+
- apiGroups:
78+
- kubevirt.io
79+
resources:
80+
- kubevirts
81+
- virtualmachineinstances
82+
verbs:
83+
- get
84+
- list
85+
- watch
86+
- apiGroups:
87+
- cdi.kubevirt.io
88+
resources:
89+
- datavolumes
90+
- datavolumes/finalizers
91+
verbs:
92+
- get
93+
- list
94+
- watch
95+
- create
96+
- update
97+
- patch
98+
- delete
99+
- apiGroups:
100+
- apps
101+
resources:
102+
- deployments
103+
verbs:
104+
- get
105+
- list
106+
- watch
107+
- create
108+
- update
109+
- patch
110+
- delete
111+
- apiGroups:
112+
- instancetype.kubevirt.io
113+
resources:
114+
- virtualmachineclusterpreferences
115+
- virtualmachineclusterinstancetypes
116+
verbs:
117+
- get
118+
- list
119+
- watch
120+
- apiGroups:
121+
- instancetype.kubevirt.io
122+
resources:
123+
- virtualmachinepreferences
124+
- virtualmachineinstancetypes
125+
verbs:
126+
- get
127+
- list
128+
- watch
129+
- create
130+
- update
131+
- patch
132+
- delete
133+
----
134+
135+
. Create the cluster role by running the following command:
136+
+
137+
[source,terminal]
138+
----
139+
$ oc create -f <filename>.yaml
140+
----
141+
142+
. Create a service account by running the following command:
143+
+
144+
[source,terminal]
145+
----
146+
$ oc create serviceaccount <service_account_name> -n <service_account_namespace>
147+
----
148+
149+
. Create a cluster role binding that links the service account to the cluster role, by running the following command:
150+
+
151+
[source,terminal]
152+
----
153+
$ oc create clusterrolebinding <service_account_name> --clusterrole=<cluster_role_name> --serviceaccount=<service_account_namespace>:<service_account_name>
154+
----
155+
156+
. Create a secret to hold the token by saving the following manifest as a YAML file:
157+
+
158+
[source,yaml]
159+
----
160+
apiVersion: v1
161+
kind: Secret
162+
metadata:
163+
name: <name_of_secret>
164+
namespace: <namespace_for_service_account>
165+
annotations:
166+
kubernetes.io/service-account.name: <service_account_name>
167+
type: kubernetes.io/service-account-token
168+
----
169+
170+
. Apply the manifest by running the following command:
171+
+
172+
[source,terminal]
173+
----
174+
$ oc apply -f <filename>.yaml
175+
----
176+
177+
. After the secret is populated, run the following command to get the service account bearer token:
178+
+
179+
[source,terminal]
180+
----
181+
$ TOKEN_BASE64=$(oc get secret "<name_of_secret>" -n "<namespace_bound_to_service_account>" -o jsonpath='{.data.token}')
182+
TOKEN=$(echo "$TOKEN_BASE64" | base64 --decode)
183+
echo "$TOKEN"
184+
----
185+
186+
. Copy the printed token.
187+
188+
. In the {mtv-first} web console, when you create a provider and select *{VirtProductName}*, paste the token into the *Service account bearer token* field.
Lines changed: 52 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,52 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * virt/live_migration/virt-enabling-cclm-for-vms.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="virt-setting-mtv-lm-feature-gates_{context}"]
7+
= Setting a live migration feature gate in the {mtv-first}
8+
9+
[role="_abstract"]
10+
You enable the {product-title} live migration feature gate in the {mtv-first} to allow virtual machines to migrate between clusters during cross-cluster live migration. This feature gate must be enabled in both clusters that participate in the migration.
11+
12+
.Prerequisites
13+
14+
* You have installed the {oc-first}.
15+
16+
* You must have cluster admin privileges.
17+
18+
* The `virt-synchronization-controller` pods must be running.
19+
20+
.Procedure
21+
22+
* To enable the feature gate by modifying the CR, run the following command:
23+
+
24+
[source,terminal]
25+
----
26+
$ oc patch ForkliftController forklift-controller -n openshift-mtv --type json -p '[{"op": "add", "path": "/spec/feature_ocp_live_migration", "value": "true"}]'
27+
----
28+
29+
.Verification
30+
31+
* Verify that the feature gate is enabled by checking the `ForkliftController` custom resource (CR). Run the following command:
32+
+
33+
[source,terminal]
34+
----
35+
$ oc get ForkliftController forklift-controller -n openshift-mtv -o yaml
36+
----
37+
+
38+
Confirm that the `feature_ocp_live_migration` key value is set to `true`, as shown in the following example:
39+
+
40+
[source,yaml]
41+
----
42+
apiVersion: forklift.konveyor.io/v1beta1
43+
kind: ForkliftController
44+
metadata:
45+
name: forklift-controller
46+
namespace: openshift-mtv
47+
spec:
48+
feature_ocp_live_migration: "true"
49+
feature_ui_plugin: "true"
50+
feature_validation: "true"
51+
feature_volume_populator: "true"
52+
----
Lines changed: 44 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,44 @@
1+
// Module included in the following assemblies:
2+
//
3+
// * virt/live_migration/virt-enabling-cclm-for-vms.adoc
4+
5+
:_mod-docs-content-type: PROCEDURE
6+
[id="virt-setting-openshiftv-lm-feature-gates_{context}"]
7+
= Setting a live migration feature gate for each cluster in {VirtProductName}
8+
9+
[role="_abstract"]
10+
To enable cross-cluster live migration, you must set a feature gate for each of the two clusters in {VirtProductName}.
11+
12+
.Prerequisites
13+
14+
* You have installed the {oc-first}.
15+
16+
* You must have cluster admin privileges.
17+
18+
* The `virt-synchronization-controller` pods must be running.
19+
20+
.Procedure
21+
22+
* Set the feature gate by running the following command for each cluster:
23+
+
24+
[source,terminal]
25+
----
26+
$ oc patch hyperconverged kubevirt-hyperconverged -n openshift-cnv --type json -p '[{"op":"replace", "path": "/spec/featureGates/decentralizedLiveMigration", "value": true}]'
27+
----
28+
29+
.Verification
30+
31+
* To verify that the feature gate enablement is successful for each cluster, run the following command in the {VirtProductName} namespace to locate the synchronization pods:
32+
+
33+
[source,terminal]
34+
----
35+
$ oc get -n {CNVNamespace} pod | grep virt-synchronization
36+
----
37+
+
38+
Example output:
39+
+
40+
[source,terminal]
41+
----
42+
virt-synchronization-controller-898789f8fc-nsbsm 1/1 Running 0 5d1h
43+
virt-synchronization-controller-898789f8fc-vmmfj 1/1 Running 0 5d1h
44+
----
Lines changed: 22 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,22 @@
1+
:_mod-docs-content-type: ASSEMBLY
2+
include::_attributes/common-attributes.adoc[]
3+
include::_attributes/attributes-openshift-dedicated.adoc[]
4+
[id="virt-about-mtv-providers"]
5+
= About {mtv-first} providers
6+
:context: virt-about-mtv-providers
7+
8+
toc::[]
9+
10+
[role="_abstract"]
11+
To migrate a virtual machine (VM) across {product-title} clusters, you must configure an {product-title} provider for each cluster that you are including in the migration. If MTV is already installed on a cluster, a local provider already exists.
12+
13+
:FeatureName: Cross-cluster live migration
14+
include::snippets/technology-preview.adoc[]
15+
16+
.Next steps
17+
18+
* See link:https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/2.9/html-single/installing_and_using_the_migration_toolkit_for_virtualization/index#adding-source-provider_cnv[Adding a Red Hat {VirtProductName} source provider] and link:https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/2.9/html-single/installing_and_using_the_migration_toolkit_for_virtualization/index#adding-source-provider_dest_cnv[Adding an {VirtProductName} destination provider].
19+
20+
include::modules/virt-configuring-root-ca-for-providers.adoc[leveloffset=+1]
21+
22+
include::modules/virt-creating-long-lived-account-and-token.adoc[leveloffset=+1]
Lines changed: 17 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,17 @@
1+
:_mod-docs-content-type: ASSEMBLY
2+
include::_attributes/common-attributes.adoc[]
3+
include::_attributes/attributes-openshift-dedicated.adoc[]
4+
[id="virt-configuring-cross-cluster-live-migration-network"]
5+
= Configuring a cross-cluster live migration network
6+
:context: virt-configuring-cross-cluster-live-migration-network
7+
8+
toc::[]
9+
10+
Cross-cluster live migration requires that the clusters be connected in the same network. Specifically, `virt-handler` pods must be able to communicate.
11+
12+
:FeatureName: Cross-cluster live migration
13+
include::snippets/technology-preview.adoc[]
14+
15+
include::modules/nw-multus-bridge-object.adoc[leveloffset=+1]
16+
17+
include::modules/virt-configuring-secondary-network-vm-live-migration.adoc[leveloffset=+1]

0 commit comments

Comments
 (0)