Changes to the migrations by CLI section

Signed-off-by: RichardHoch <[email protected]>
kubev2v · Dec 3, 2024 · 5eeb439 · 5eeb439
1 parent 8af29cb
commit 5eeb439
Show file tree

Hide file tree

Showing 4 changed files with 21 additions and 21 deletions.
diff --git a/documentation/doc-Migration_Toolkit_for_Virtualization/master.adoc b/documentation/doc-Migration_Toolkit_for_Virtualization/master.adoc
@@ -234,16 +234,13 @@ You can migrate virtual machines to {virt} from the command line.
 You must ensure that all xref:prerequisites_{context}[prerequisites] are met.
 ====
 
-include::modules/snip_plan-limits.adoc[]
-
 :mtv!:
 :context: cli
 include::modules/non-admin-permissions-for-ui.adoc[leveloffset=+2]
-include::modules/snip_vmware-permissions.adoc[]
 :cli!:
 :context: mtv
 
-include::modules/retrieving-vmware-moref.adoc[leveloffset=+2]
+
 
 [id="migrating-virtual-machines_{context}"]
 === Migrating virtual machines
@@ -263,34 +260,36 @@ To migrate to or from an {ocp-short} cluster that is different from the one the
 :mtv!:
 :context: vmware
 :vmware:
+
 include::modules/new-migrating-virtual-machines-cli.adoc[leveloffset=+3]
+// Do we want this snippet here?
 include::modules/snip_vmware-permissions.adoc[]
+include::modules/retrieving-vmware-moref.adoc[leveloffset=+4]
+include::modules/canceling-migration-cli.adoc[leveloffset=+4]
 :vmware!:
 :context: rhv
 :rhv:
 include::modules/new-migrating-virtual-machines-cli.adoc[leveloffset=+3]
+include::modules/canceling-migration-cli.adoc[leveloffset=+4]
 :rhv!:
 :context: ostack
 :ostack:
 include::modules/new-migrating-virtual-machines-cli.adoc[leveloffset=+3]
+include::modules/canceling-migration-cli.adoc[leveloffset=+4]
 :ostack!:
 :context: ova
 :ova:
-//include::modules/new-migrating-virtual-machines-cli.adoc[leveloffset=+3]
-//:ova!:
-//:context: ostack
-//:ostack:
 include::modules/new-migrating-virtual-machines-cli.adoc[leveloffset=+3]
+include::modules/canceling-migration-cli.adoc[leveloffset=+4]
 :ova!:
 :context: cnv
 :cnv:
 include::modules/new-migrating-virtual-machines-cli.adoc[leveloffset=+3]
+include::modules/canceling-migration-cli.adoc[leveloffset=+4]
 :cnv!:
 :context: mtv
 :mtv:
 
-include::modules/canceling-migration-cli.adoc[leveloffset=+2]
-
 [id="advanced-migration-options_{context}"]
 == Advanced migration options
 

diff --git a/documentation/modules/canceling-migration-cli.adoc b/documentation/modules/canceling-migration-cli.adoc
@@ -4,9 +4,9 @@
 
 :_content-type: PROCEDURE
 [id="canceling-migration-cli_{context}"]
-= Canceling a migration
+= Canceling a migration from the CLI
 
-You can cancel an entire migration or individual virtual machines (VMs) while a migration is in progress from the command line interface (CLI).
+You can cancel either an entire migration, or the migration of specific virtual machines (VMs), while a migration is in progress from the command line interface (CLI).
 
 .Canceling an entire migration
 
@@ -18,10 +18,11 @@ $ {oc} delete migration <migration> -n <namespace> <1>
 ----
 <1> Specify the name of the `Migration` CR.
 
-.Canceling the migration of individual VMs
+.Canceling the migration of specific VMs
 
-. Add the individual VMs to the `spec.cancel` block of the `Migration` manifest:
+. Add the specific VMs to the `spec.cancel` block of the `Migration` manifest:
 +
+.Example YAML for cancelling the migrations of two VMs
 [source,yaml,subs="attributes+"]
 ----
 $ cat << EOF | {oc} apply -f -

diff --git a/documentation/modules/new-migrating-virtual-machines-cli.adoc b/documentation/modules/new-migrating-virtual-machines-cli.adoc
@@ -353,7 +353,7 @@ spec:
 EOF
 ----
 <1> Specify the name of the VMware vSphere `Provider` CR.
-<2> Specify the Managed Object Reference (moRef) of the VMware vSphere host. To retrieve the moRef, see xref:retrieving-vmware-moref_mtv[Retrieving a VMware vSphere moRef].
+<2> Specify the Managed Object Reference (moRef) of the VMware vSphere host. To retrieve the moRef, see xref:retrieving-vmware-moref_vmware[Retrieving a VMware vSphere moRef].
 <3> Specify the IP address of the VMware vSphere migration network.
 
 [start=4]
@@ -392,7 +392,7 @@ spec:
 EOF
 ----
 <1> Allowed values are `pod` and `multus`.
-<2> You can use either the `id` _or_ the `name` parameter to specify the source network. For `id`, specify the VMware vSphere network Managed Object Reference (moRef). To retrieve the moRef, see xref:retrieving-vmware-moref_mtv[Retrieving a VMware vSphere moRef].
+<2> You can use either the `id` _or_ the `name` parameter to specify the source network. For `id`, specify the VMware vSphere network Managed Object Reference (moRef). To retrieve the moRef, see xref:retrieving-vmware-moref_vmware[Retrieving a VMware vSphere moRef].
 <3> Specify a network attachment definition for each additional {virt} network.
 <4> Required only when `type` is `multus`. Specify the namespace of the {virt} network attachment definition.
 endif::[]
@@ -593,7 +593,7 @@ spec:
 EOF
 ----
 <1> Allowed values are `ReadWriteOnce` and `ReadWriteMany`.
-<2> Specify the VMware vSphere datastore moRef. For example, `f2737930-b567-451a-9ceb-2887f6207009`. To retrieve the moRef, see xref:retrieving-vmware-moref_mtv[Retrieving a VMware vSphere moRef].
+<2> Specify the VMware vSphere datastore moRef. For example, `f2737930-b567-451a-9ceb-2887f6207009`. To retrieve the moRef, see xref:retrieving-vmware-moref_vmware[Retrieving a VMware vSphere moRef].
 endif::[]
 
 ifdef::rhv[]
@@ -803,7 +803,7 @@ EOF
 <8> By default, virtual network interface controllers (vNICs) change during the migration process. As a result, vNICs that are configured with a static IP linked to the interface name in the guest VM lose their IP.
 To avoid this, set `preserveStaticIPs` to `true`. {project-short} issues a warning message about any VMs for which vNIC properties are missing. To retrieve any missing vNIC properties, run those VMs in vSphere in order for the vNIC properties to be reported to {project-short}.
 <9> You can use either the `id` _or_ the `name` parameter to specify the source VMs.
-<10> Specify the VMware vSphere VM moRef. To retrieve the moRef, see xref:retrieving-vmware-moref_mtv[Retrieving a VMware vSphere moRef].
+<10> Specify the VMware vSphere VM moRef. To retrieve the moRef, see xref:retrieving-vmware-moref_vmware[Retrieving a VMware vSphere moRef].
 <11> Optional: You can specify up to two hooks for a VM. Each hook must run during a separate migration step.
 <12> Specify the name of the `Hook` CR.
 <13> Allowed values are `PreHook`, before the migration plan starts, or `PostHook`, after the migration is complete.
@@ -867,7 +867,7 @@ EOF
 +
 [NOTE]
 ====
-* If the migrated machines is set with a custom CPU model, it will be set with that CPU model in the destination cluster, regardless of the setting of `preserveClusterCpuModel`.
+* If the migrated machine is set with a custom CPU model, it will be set with that CPU model in the destination cluster, regardless of the setting of `preserveClusterCpuModel`.
 
 * If the migrated machine is _not_ set with a custom CPU model:
 

diff --git a/documentation/modules/snip_vmware-permissions.adoc b/documentation/modules/snip_vmware-permissions.adoc
@@ -1,9 +1,9 @@
 :_content-type: SNIPPET
 
 [IMPORTANT]
-.`forklift-controller` consistently failing to reconcile a plan, and returning an HTTP 500 error
+.`forklift-controller` consistently fails to reconcile plans, and returns an HTTP 500 error.
 ====
-There is an issue with the `forklift-controller` consistently failing to reconcile a Migration Plan, and subsequently returning an HTTP 500 error. This issue is caused when you specify the user permissions only on the virtual machine (VM).
+There is an issue with the `forklift-controller` consistently failing to reconcile a migration plan, and subsequently returning an HTTP 500 error. This issue is caused when you specify the user permissions only on the virtual machine (VM).
 
 In {project-short}, you need to add permissions at the datacenter level, which includes storage, networks, switches, and so on, which are used by the VM. You must then propagate the permissions to the child elements.