Merge pull request #751 from RichardHoch/MTV-3188_rcm_cli

MTV-3188 RCM in CLI documentation

Author: anarnold97

documentation/modules/new-migrating-virtual-machines-cli.adoc

@@ -573,10 +573,9 @@ spec:
       namespace: <namespace>
 EOF
 ----
-<1> Allowed values are `pod` and `multus`.
-<2> Specify a network attachment definition for each additional {virt} network. Specify the
-`namespace` either by using the `namespace property` or with a name built as follows: `<network_namespace>/<network_name>`.
-<3> Required only when `type` is `multus`. Specify the namespace of the {virt} network attachment definition.
+<1> Allowed values are `pod`, `ignored`, and `multus`.
+<2> Specify the network name. When the `type` is `multus`, use the {virt} network attachment definition name.
+<3> Required only when the `type` is `multus`. Specify the namespace of the {virt} network attachment definition. 
 endif::[]
 
 ifdef::vmware[]
@@ -813,20 +812,22 @@ spec:
   networkNameTemplate: <network_interface_template> <9>
   pvcNameTemplate: <pvc_name_template> <10>
   pvcNameTemplateUseGenerateName: true <11>
+  skipGuestConversion: false <12>
   targetNamespace: <target_namespace>
-  volumeNameTemplate: <volume_name_template> <12>
-  vms: <13>
-    - id: <source_vm1> <14>
+  useCompatibilityMode: true <13>
+  volumeNameTemplate: <volume_name_template> <14>
+  vms: <15>
+    - id: <source_vm1> <16>
     - name: <source_vm2>
-      networkNameTemplate: <network_interface_template_for_this_vm> <15>
-      pvcNameTemplate: <pvc_name_template_for_this_vm> <16>
-      volumeNameTemplate: <volume_name_template_for_this_vm> <17>
-      targetName: <target_name> <18>
-      hooks: <19>
+      networkNameTemplate: <network_interface_template_for_this_vm> <17>
+      pvcNameTemplate: <pvc_name_template_for_this_vm> <18>
+      volumeNameTemplate: <volume_name_template_for_this_vm> <19>
+      targetName: <target_name> <20>
+      hooks: <21>
         - hook:
             namespace: <namespace>
-            name: <hook> <20>
-          step: <step> <21>
+            name: <hook> <22>
+          step: <step> <23>
 
 EOF
 ----
@@ -837,7 +838,7 @@ EOF
 <5> Specify the name of the `NetworkMap` CR.
 <6> Specify a storage mapping even if the VMs to be migrated are not assigned with disk images. The mapping can be empty in this case.
 <7> Specify the name of the `StorageMap` CR.
-<8> By default, virtual network interface controllers (vNICs) change during the migration process. As a result, vNICs that are configured with a static IP address linked to the interface name in the guest VM lose their IP address. +
+<8> By default, virtual network interface controllers (vNICs) change during the migration process. As a result, vNICs that are configured with a static IP address linked to the interface name in the guest VM lose their IP address.
 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> [[callout9]]Optional. Specify a template for the network interface name for the VMs in your plan.
 The template follows the Go template syntax and has access to the following variables:
@@ -865,28 +866,37 @@ The template follows the Go template syntax and has access to the following vari
 * `"{{if .Shared}}shared-{{end}}{{.VmName}}-{{.DiskIndex}}"`
 +
 <11> Optional:
-* When set to `true`, {project-short} adds one or more randonly generated alphanumeric characters to the name of the PVC in order to ensure all PVCs have unique names.
-* When set to `false`, if you specify a `pvcNameTemplate`, {project-short} does not add such charchters to the name of the PVC.
+* When set to `true`, {project-short} adds one or more randomly generated alphanumeric characters to the name of the PVC in order to ensure all PVCs have unique names.
+* When set to `false`, if you specify a `pvcNameTemplate`, {project-short} does not add such characters to the name of the PVC.
 +
 include::snip_pvcNameTemplateUseGenerateName-warn.adoc[]
 +
-<12> [[callout12]]Optional: Specify a template for the volume interface name for the VMs in your plan.
+<12> Determines whether VMs are converted before migration using the `virt-v2v` tool, which makes the VMs compatible with {virt}.
+* When set to `false`, the default value, {project-short} migrates VMs using `virt-v2v`.
+* When set to `true`, {project-short} migrates VMs using raw copy mode, which copies the VMs without converting them first.
++
+Raw copy mode copies VMs without converting them with `virt-v2v`. This allows for faster conversions, migrating VMs running a wider range of operating systems, as well as supporting migrating disks encrypted using Linux Unified Key Setup (LUKS) without needing keys. However, VMs migrated using raw copy mode might not function properly on {virt}. For more information on `virt-v2v`, see xref:virt-v2v-mtv_mtv[How {project-short} uses the virt-v2v tool]. 
++
+<13> Determines whether the migration uses VirtIO devices or compatibility devices (SATA bus, E1000E NIC) when `skipGuestConversion` is `true`, that is, when raw copy mode is used for the migration. The setting of `useCompatibilityMode` has no effect when `skipGuestConversion` is `false`, because `virt-v2v` conversion always uses VirtIO devices.
+* When set to `true`, the default setting, {project-short} uses compatibility devices (SATA bus, E1000E NIC) in the migration process to ensure that the VMs can be booted after migration.
+* When set to `false`, {project-short} uses high-performance VirtIO devices in the migration process, and `virt-v2v` ensures that the VMs can be booted after migration. Before using this option, verify that VirtIO drivers are already installed in the source VMs.
+<14> [[callout14]]Optional: Specify a template for the volume interface name for the VMs in your plan.
 The template follows the Go template syntax and has access to the following variables:
 ** `.PVCName`: Name of the PVC mounted to the VM using this volume.
 ** `.VolumeIndex`: Sequential index of the volume interface (0-based).
 +
 *Examples*
 ** `"disk-{{.VolumeIndex}}"`
 ** `"pvc-{{.PVCName}}"`
-<13> You can use either the `id` or the `name` parameter to specify the source VMs.
-<14> Specify the VMware vSphere VM moRef. To retrieve the moRef, see xref:retrieving-vmware-moref_vmware[Retrieving a VMware vSphere moRef].
-<15> Optional: Specify a network interface name for the specific VM. Overrides the value set in `spec:networkNameTemplate`. Variables and examples as in xref:callout9[callout 9].
-<16> Optional: Specify a PVC name for the specific VM. Overrides the value set in `spec:pvcNameTemplate`. Variables and examples as in xref:callout10[callout 10].
-<17> Optional: Specify a volume name for the specific VM. Overrides the value set in `spec:volumeNameTemplate`. Variables and examples as in xref:callout12[callout 12].
-<18> Optional: {project-short} automatically generates a name for the target VM. You can override this name by using this parameter and entering a new name. The name you enter must be unique and it must be a valid Kubernetes subdomain. Otherwise, the migration fails automatically.
-<19> Optional: Specify up to two hooks for a VM. Each hook must run during a separate migration step.
-<20> Specify the name of the `Hook` CR.
-<21> Allowed values are `PreHook`, before the migration plan starts, or `PostHook`, after the migration is complete.
+<15> You can use either the `id` or the `name` parameter to specify the source VMs.
+<16> Specify the VMware vSphere VM moRef. To retrieve the moRef, see xref:retrieving-vmware-moref_vmware[Retrieving a VMware vSphere moRef].
+<17> Optional: Specify a network interface name for the specific VM. Overrides the value set in `spec:networkNameTemplate`. Variables and examples as in xref:callout9[callout 9].
+<18> Optional: Specify a PVC name for the specific VM. Overrides the value set in `spec:pvcNameTemplate`. Variables and examples as in xref:callout10[callout 10].
+<19> Optional: Specify a volume name for the specific VM. Overrides the value set in `spec:volumeNameTemplate`. Variables and examples as in xref:callout14[callout 14].
+<20> Optional: {project-short} automatically generates a name for the target VM. You can override this name by using this parameter and entering a new name. The name you enter must be unique, and it must be a valid Kubernetes subdomain. Otherwise, the migration fails automatically.
+<21> Optional: Specify up to two hooks for a VM. Each hook must run during a separate migration step.
+<22> Specify the name of the `Hook` CR.
+<23> Allowed values are `PreHook` before the migration plan starts or `PostHook` after the migration is complete.
 +
 include::snip_vmware-name-change.adoc[]
 endif::[]