kubev2v · anarnold97 · Apr 10, 2025 · May 15, 2025
diff --git a/documentation/modules/new-migrating-virtual-machines-cli.adoc b/documentation/modules/new-migrating-virtual-machines-cli.adoc
@@ -16,7 +16,7 @@ include::snip_no-nvme.adoc[]
 
 [NOTE]
 ====
-To migrate virtual machines (VMs) that have shared disks, see xref:mtv-shared-disks_{context}[Migrating virtual machines with shared disks]. 
+To migrate virtual machines (VMs) that have shared disks, see xref:mtv-shared-disks_{context}[Migrating virtual machines with shared disks].
 ====
 
 endif::[]
@@ -400,7 +400,7 @@ spec:
       namespace: <namespace>
 EOF
 ----
-<1> Allowed values are `pod`, `multus`, and `ignored`. Use `ignored` to avoid attaching VMs to this network for this migration. 
+<1> Allowed values are `pod`, `multus`, and `ignored`. Use `ignored` to avoid attaching VMs to this network for this migration.
 <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.
@@ -759,11 +759,11 @@ You can use the default `hook-runner` image or specify a custom image. If you sp
 
 ifdef::vmware[]
 [start=7]
-. Enter the following command to create the network attachment definition (NAD) of the transfer network used for {project-short} migrations. 
+. Enter the following command to create the network attachment definition (NAD) of the transfer network used for {project-short} migrations.
 +
-You use this definition to configure an IP address for the interface, either from the Dynamic Host Configuration Protocol (DHCP) or statically. 
+You use this definition to configure an IP address for the interface, either from the Dynamic Host Configuration Protocol (DHCP) or statically.
 +
-Configuring the IP address enables the interface to reach the configured gateway. 
+Configuring the IP address enables the interface to reach the configured gateway.
 +
 [source,yaml,subs="attributes+"]
 ----
@@ -774,7 +774,7 @@ metadata:
   name: <name_of_transfer_network>
   namespace: <namespace>
   annotations:
-    forklift.konveyor.io/route: <IP_address> 
+    forklift.konveyor.io/route: <IP_address>
 ----
 
 . Create a `Plan` manifest for the migration:
@@ -813,7 +813,7 @@ spec:
     - id: <source_vm1> <14>
     - name: <source_vm2>
       networkNameTemplate: <network_interface_template_for_this_vm> <15>
-      pvcNameTemplate: <pvc_name_template_for_this_vm> <16> 
+      pvcNameTemplate: <pvc_name_template_for_this_vm> <16>
       volumeNameTemplate: <volume_name_template_for_this_vm> <17>
       targetName: <target_name> <18>
       hooks: <19>
@@ -831,8 +831,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. +
-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}.
+<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:
 * `.NetworkName:` If the target network is `multus`, add the name of the Multus Network Attachment Definition. Otherwise, leave this variable empty.
@@ -844,22 +843,22 @@ The template follows the Go template syntax and has access to the following vari
 * `"net-{{.NetworkIndex}}"`
 * `{{if eq .NetworkType "pod"}}pod{{else}}multus-{{.NetworkIndex}}{{end}}"`
 +
-Variable names cannot exceed 63 characters. This rule applies to a network name network template, a PVC name template, a VM name template, and a volume name template. 
+Variable names cannot exceed 63 characters. This rule applies to a network name network template, a PVC name template, a VM name template, and a volume name template.
 <10> [[callout10]]Optional. Specify a template for the persistent volume claim (PVC) name for a plan.
 The template follows the Go template syntax and has access to the following variables:
 * `.VnName`: Name of the VM.
 * `.PlanName`: Name of the migration plan.
 * `.DiskIndex`: Initial volume index of the disk.
 * `.RootDiskIndex`: Index of the root disk.
-* `.Shared`: Options: `true`, for a shared volume, `false`, for a non-shared volume. 
+* `.Shared`: Options: `true`, for a shared volume, `false`, for a non-shared volume.
 +
 *Examples*
 * `"{{.VmName}}-disk-{{.DiskIndex}}"`
 * `"{{if eq .DiskIndex .RootDiskIndex}}root{{else}}data{{end}}-{{.DiskIndex}}"`
 * `"{{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 `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.
 +
 include::snip_pvcNameTemplateUseGenerateName-warn.adoc[]
@@ -875,7 +874,7 @@ The template follows the Go template syntax and has access to the following vari
 <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]. 
+<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.
@@ -887,11 +886,11 @@ endif::[]
 
 ifdef::rhv[]
 [start=6]
-. Enter the following command to create the network attachment definition (NAD) of the transfer network used for {project-short} migrations. 
+. Enter the following command to create the network attachment definition (NAD) of the transfer network used for {project-short} migrations.
 +
-You use this definition to configure an IP address for the interface, either from the Dynamic Host Configuration Protocol (DHCP) or statically. 
+You use this definition to configure an IP address for the interface, either from the Dynamic Host Configuration Protocol (DHCP) or statically.
 +
-Configuring the IP address enables the interface to reach the configured gateway. 
+Configuring the IP address enables the interface to reach the configured gateway.
 +
 [source,yaml,subs="attributes+"]
 ----
@@ -902,7 +901,7 @@ metadata:
   name: <name_of_transfer_network>
   namespace: <namespace>
   annotations:
-    forklift.konveyor.io/route: <IP_address> 
+    forklift.konveyor.io/route: <IP_address>
 ----
 
 . Create a `Plan` manifest for the migration:
@@ -970,11 +969,11 @@ endif::[]
 
 ifdef::ova[]
 [start=6]
-. Enter the following command to create the network attachment definition (NAD) of the transfer network used for {project-short} migrations. 
+. Enter the following command to create the network attachment definition (NAD) of the transfer network used for {project-short} migrations.
 +
-You use this definition to configure an IP address for the interface, either from the Dynamic Host Configuration Protocol (DHCP) or statically. 
+You use this definition to configure an IP address for the interface, either from the Dynamic Host Configuration Protocol (DHCP) or statically.
 +
-Configuring the IP address enables the interface to reach the configured gateway. 
+Configuring the IP address enables the interface to reach the configured gateway.
 +
 [source,yaml,subs="attributes+"]
 ----
@@ -985,7 +984,7 @@ metadata:
   name: <name_of_transfer_network>
   namespace: <namespace>
   annotations:
-    forklift.konveyor.io/route: <IP_address> 
+    forklift.konveyor.io/route: <IP_address>
 ----
 
 . Create a `Plan` manifest for the migration:
@@ -1039,11 +1038,11 @@ endif::[]
 
 ifdef::ostack[]
 [start=6]
-. Enter the following command to create the network attachment definition (NAD) of the transfer network used for {project-short} migrations. 
+. Enter the following command to create the network attachment definition (NAD) of the transfer network used for {project-short} migrations.
 +
-You use this definition to configure an IP address for the interface, either from the Dynamic Host Configuration Protocol (DHCP) or statically. 
+You use this definition to configure an IP address for the interface, either from the Dynamic Host Configuration Protocol (DHCP) or statically.
 +
-Configuring the IP address enables the interface to reach the configured gateway. 
+Configuring the IP address enables the interface to reach the configured gateway.
 +
 [source,yaml,subs="attributes+"]
 ----
@@ -1054,7 +1053,7 @@ metadata:
   name: <name_of_transfer_network>
   namespace: <namespace>
   annotations:
-    forklift.konveyor.io/route: <IP_address> 
+    forklift.konveyor.io/route: <IP_address>
 ----
 
 . Create a `Plan` manifest for the migration:
@@ -1108,11 +1107,11 @@ endif::[]
 
 ifdef::cnv[]
 [start=6]
-. Enter the following command to create the network attachment definition (NAD) of the transfer network used for {project-short} migrations. 
+. Enter the following command to create the network attachment definition (NAD) of the transfer network used for {project-short} migrations.
 +
-You use this definition to configure an IP address for the interface, either from the Dynamic Host Configuration Protocol (DHCP) or statically. 
+You use this definition to configure an IP address for the interface, either from the Dynamic Host Configuration Protocol (DHCP) or statically.
 +
-Configuring the IP address enables the interface to reach the configured gateway. 
+Configuring the IP address enables the interface to reach the configured gateway.
 +
 [source,yaml,subs="attributes+"]
 ----
@@ -1123,7 +1122,7 @@ metadata:
   name: <name_of_transfer_network>
   namespace: <namespace>
   annotations:
-    forklift.konveyor.io/route: <IP_address> 
+    forklift.konveyor.io/route: <IP_address>
 ----
 
 . Create a `Plan` manifest for the migration:

diff --git a/documentation/modules/ova-prerequisites.adoc b/documentation/modules/ova-prerequisites.adoc
@@ -23,18 +23,20 @@ The filename of each compressed package *must* have the `.ova` extension. Severa
 +
 When this structure is used, {project-short} scans the root folder and the first-level subfolders for compressed packages.
 +
-For example, if the NFS share is, `/nfs`, then: +
-The folder `/nfs` is scanned. +
-The folder `/nfs/subfolder1` is scanned. +
-But, `/nfs/subfolder1/subfolder2` is not scanned.
+For example, if the NFS share is, `/nfs`, then:
+
+*** The folder `/nfs` is scanned.
+*** The folder `/nfs/subfolder1` is scanned.
+*** The folder `/nfs/subfolder1/subfolder2` is not scanned.
 
 ** In extracted OVF packages.
 +
 When this structure is used, {project-short} scans the root folder, first-level subfolders, and second-level subfolders for extracted OVF packages.
 However, there can be only one `.ovf` file in a folder. Otherwise, the migration will fail.
 +
-For example, if the NFS share is, `/nfs`, then: +
-The OVF file `/nfs/vm.ovf` is scanned. +
-The OVF file `/nfs/subfolder1/vm.ovf` is scanned. +
-The OVF file `/nfs/subfolder1/subfolder2/vm.ovf` is scanned. +
-But, the OVF file `/nfs/subfolder1/subfolder2/subfolder3/vm.ovf` is not scanned.
+For example, if the NFS share is, `/nfs`, then:
+
+*** The OVF file `/nfs/vm.ovf` is scanned.
+*** The OVF file `/nfs/subfolder1/vm.ovf` is scanned.
+*** The OVF file `/nfs/subfolder1/subfolder2/vm.ovf` is scanned.
+*** The OVF file `/nfs/subfolder1/subfolder2/subfolder3/vm.ovf` is not scanned.
diff --git a/documentation/modules/rn-2.4.adoc b/documentation/modules/rn-2.4.adoc
@@ -119,7 +119,8 @@ VM with multiple disks that was migrated might not be able to boot on the target
 
 .Non-supported guest operating systems in warm migrations
 
-Warm migrations and migrations to remote OCP clusters from vSphere do not support all types of guest operating systems that are supported in cold migrations to the local OCP cluster. It is a consequence of using RHEL 8 in the former case and RHEL 9 in the latter case. +
+Warm migrations and migrations to remote OCP clusters from vSphere do not support all types of guest operating systems that are supported in cold migrations to the local OCP cluster. It is a consequence of using RHEL 8 in the former case and RHEL 9 in the latter case.
+
 See link:https://access.redhat.com/articles/1351473[Converting virtual machines from other hypervisors to KVM with virt-v2v in RHEL 7, RHEL 8, and RHEL 9] for the list of supported guest operating systems.
 
 .VMs from vSphere with RHEL 9 guest operating system may start with network interfaces that are down

diff --git a/documentation/modules/rn-2.5.adoc b/documentation/modules/rn-2.5.adoc
@@ -38,7 +38,7 @@ The old UI of {project-short} 2.3 cannot be enabled by setting `feature_ui: true
 
 .Support deployment on {ocp-name} 4.15
 
-{project-short} 2.5.6 can be deployed on {ocp-name} 4.15 clusters. 
+{project-short} 2.5.6 can be deployed on {ocp-name} 4.15 clusters.
 
 
 [id="new-features-and-enhancements-25_{context}"]
@@ -115,7 +115,8 @@ When migrating a VM with multiple disks to more than one storage classes of type
 
 .Non-supported guest operating systems in warm migrations
 
-Warm migrations and migrations to remote {ocp} clusters from vSphere do not support all types of guest operating systems that are supported in cold migrations to the local {ocp} cluster. This is a consequence of using RHEL 8 in the former case and RHEL 9 in the latter case. +
+Warm migrations and migrations to remote {ocp} clusters from vSphere do not support all types of guest operating systems that are supported in cold migrations to the local {ocp} cluster. This is a consequence of using RHEL 8 in the former case and RHEL 9 in the latter case.
+
 See link:https://access.redhat.com/articles/1351473[Converting virtual machines from other hypervisors to KVM with virt-v2v in RHEL 7, RHEL 8, and RHEL 9] for the list of supported guest operating systems.
 
 .VMs from vSphere with RHEL 9 guest operating system can start with network interfaces that are down
@@ -295,7 +296,7 @@ This issue is resolved in {project-short} {project-version}, VM with multiple di
 
 In {project-short} releases 2.4.0-2.5.3, cold migrations from vSphere to the local cluster on which {project-short} was deployed did not take a specified transfer network into account. This issue is resolved in  {project-short} 2.5.4.  link:https://issues.redhat.com/browse/MTV-846[(MTV-846)]
 
-.Fix migration of VMs with multi-boot guest operating system from vSphere 
+.Fix migration of VMs with multi-boot guest operating system from vSphere
 
 In {project-short} 2.5.6, the virt-v2v arguments include `–root first`, which mitigates an issue with multi-boot VMs where the pod fails. This is a fix for a regression that was introduced in {project-short} 2.4, in which the '--root' argument was dropped. link:https://issues.redhat.com/browse/MTV-987[(MTV-987)]