Supported migration network for MTV

documentation/doc-Migration_Toolkit_for_Virtualization/master.adoc

@@ -192,8 +192,8 @@ You can create a migration plan by using the {ocp} web console to specify a sour
 
 For your convenience, there are two procedures to create migration plans, starting with either a source provider or with specific VMs:
 
-* To start with a source provider, see xref:creating-migration-plan-2-6-3_provider[Creating a migration plan starting with a source provider].
-* To start with specific VMs, see xref:creating-migration-plan-2-6-3_vms[Creating a migration plan starting with specific VMs].
+* To start with a source provider, see xref:creating-migration-plan-2-7_provider[Creating a migration plan starting with a source provider].
+* To start with specific VMs, see xref:creating-migration-plan-2-7_vms[Creating a migration plan starting with specific VMs].
 
 [WARNING]
 ====
@@ -208,12 +208,12 @@ include::modules/snip_plan-limits.adoc[]
 :context: provider
 :provider:
 
-include::modules/creating-migration-plan-2-6-3.adoc[leveloffset=+3]
+include::modules/creating-migration-plan-2-7.adoc[leveloffset=+3]
 
 :provider!:
 :context: vms
 :vms:
-include::modules/creating-migration-plan-2-6-3.adoc[leveloffset=+3]
+include::modules/creating-migration-plan-2-7.adoc[leveloffset=+3]
 
 :vms!:
 :context: mtv
@@ -352,8 +352,6 @@ include::modules/collected-logs-cr-info.adoc[leveloffset=+3]
 include::modules/accessing-logs-ui.adoc[leveloffset=+3]
 include::modules/accessing-logs-cli.adoc[leveloffset=+3]
 
-// comment to create PR
-
 == Additional information
 
 include::modules/mtv-performance-addendum.adoc[leveloffset=+2]

documentation/modules/creating-migration-plan-2-6-3.adoc

@@ -56,6 +56,12 @@ To specify a different root device, in the *Settings* section, click the Edit ic
 +
 If the conversion fails because the boot device provided is incorrect, it is possible to get the correct information by looking at the conversion pod logs.
 
+* *{ocp-short} transfer network*: You can configure an {ocp-short} network in the ocp-short} web console by clicking *Networking > NetworkAttachmentDefinitions*.
++
+To learn more about the different types of networks {ocp-short} supports, see https://docs.openshift.com/container-platform/4.16/networking/multiple_networks/understanding-multiple-networks.html#additional-networks-provided [Additional Networks In OpenShift Container Program].
++
+If you want to change the MTU of the {ocp-short} transfer network, you must also change the MTU of the VMware migration network. For more information see xref:selecting-migration-network-for-vmware-source-provider_vmware[Selecting a migration network for a VMware source provider].
+
 . {rhv-short} source providers only (Optional):
 
 * *Preserving the CPU model of VMs that are migrated from {rhv-short}*: Generally, the CPU model (type) for {rhv-short} VMs is set at the cluster level, but it can be set at the VM level, which is called a custom CPU model.

documentation/modules/creating-migration-plan-2-7.adoc

@@ -0,0 +1,74 @@
+// * documentation/doc-Migration_Toolkit_for_Virtualization/master.adoc
+
+:_mod-docs-content-type: PROCEDURE
+[id="creating-migration-plan-2-7_{context}"]
+ifdef::provider[]
+= Creating a migration plan starting with a source provider
+
+You can create a migration plan based on a source provider, starting on the *Plans for virtualization* page. Note the specific options for migrations from VMware or {rhv-short} providers.
+
+.Procedure
+
+. In the {ocp} web console, click *Plans for virtualization* and then click *Create Plan*.
++
+The *Create migration plan* wizard opens to the *Select source provider* interface.
+. Select the source provider of the VMs you want to migrate.
++
+The *Select virtual machines* interface opens.
+. Select the VMs you want to migrate and click *Next*.
+endif::[]
+
+ifdef::vms[]
+= Creating a migration plan starting with specific VMs
+
+You can create a migration plan based on specific VMs, starting on the *Providers for virtualization* page. Note the specific options for migrations from VMware or {rhv-short} providers.
+
+.Procedure
+
+. In the {ocp} web console, click *Providers for virtualization*.
+. In the row of the appropriate source provider, click *VMs*.
++
+The *Virtual Machines* tab opens.
+. Select the VMs you want to migrate and click *Create migration plan*.
+endif::[]
++
+The *Create migration plan* pane opens. It displays the source provider's name and suggestions for a target provider and namespace, a network map, and a storage map.
+. Enter the *Plan name*.
+. Make any needed changes to the editable items.
+. Click *Add mapping* to edit a suggested network mapping or a storage mapping, or to add one or more additional mappings.
+. Click *Create migration plan*.
++
+{project-short} validates the migration plan and the *Plan details* page opens, indicating whether the plan is ready for use or contains an error. The details of the plan are listed, and you can edit the items you filled in on the previous page. If you make any changes, {project-short} validates the plan again.
+
+. VMware source providers only (All optional):
+
+* *Preserving static IPs of VMs*: By default, virtual network interface controllers (vNICs) change during the migration process. This results in vNICs that are set with a static IP in vSphere losing their IP. To avoid this by preserving static IPs of VMs, click the Edit icon next to *Preserve static IPs* and toggle the *Whether to preserve the static IPs* switch in the window that opens. Then click *Save*.
++
+{project-short} then issues a warning message about any VMs with a Windows operating system 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}.
+
+* *Entering a list of decryption passphrases for disks encrypted using Linux Unified Key Setup (LUKS)*: To enter a list of decryption passphrases for LUKS-encrypted devices, in the *Settings* section, click the Edit icon next to *Disk decryption passphrases*, enter the passphrases, and then click *Save*. You do not need to enter the passphrases in a specific order - for each LUKS-encrypted device, {project-short} tries each passphrase until one unlocks the device.
+
+* *Specifying a root device*: Applies to multi-boot VM migrations only. By default, {project-short} uses the first bootable device detected as the root device.
++
+To specify a different root device, in the *Settings* section, click the Edit icon next to *Root device* and choose a device from the list of commonly-used options, or enter a device in the text box.
++
+{project-short} uses the following format for disk location: `/dev/sd<disk_identifier><disk_partition>`. For example, if the second disk is the root device and the operating system is on the disk's second partition, the format would be: `/dev/sdb2`. After you enter the boot device, click *Save*.
++
+If the conversation fails because the boot device is incorrect, review the conversation pod logs for the correct information.
+
+* *{ocp-short} transfer network*: You can configure an {ocp-short} network in the ocp-short} web console by clicking *Networking > NetworkAttachmentDefinitions*.
++
+To learn more about the different types of networks {ocp-short} supports, see https://docs.openshift.com/container-platform/4.16/networking/multiple_networks/understanding-multiple-networks.html#additional-networks-provided [Additional Networks In OpenShift Container Program].
++
+If you want to adjust the maximum transmission unit (MTU) of the {ocp-short} transfer network, you must also change the MTU of the VMware migration network. For more information see xref:selecting-migration-network-for-vmware-source-provider_vmware[Selecting a migration network for a VMware source provider].
+
+. {rhv-short} source providers only (Optional):
+
+* *Preserving the CPU model of VMs that are migrated from {rhv-short}*: Generally, the CPU model (type) for {rhv-short} VMs is set at the cluster level, but it can be set at the VM level, which is called a custom CPU model.
+By default, {project-short} sets the CPU model on the destination cluster as follows: {project-short} preserves custom CPU settings for VMs that have them, but, for VMs without custom CPU settings, {project-short} does not set the CPU model. Instead, the CPU model is later set by {virt}.
++
+To preserve the cluster-level CPU model of your {rhv-short} VMs, in the *Settings* section, click the Edit icon next to *Preserve CPU model*. Toggle the *Whether to preserve the CPU model* switch, and then click *Save*.
+
+. If the plan is valid,
+.. You can run the plan now by clicking *Start migration*.
+.. You can run the plan later by selecting it on the *Plans for virtualization* page and following the procedure in xref:running-migration-plan_mtv[Running a migration plan].

documentation/modules/selecting-migration-network-for-virt-provider.adoc

@@ -15,9 +15,16 @@ If you do not select a migration network, the default migration network is the `
 You can override the default migration network of the provider by selecting a different network when you create a migration plan.
 ====
 
+include::snip-mtu-value.adoc[]
+
 .Procedure
 
-. In the {ocp} web console, click *Migration* -> *Providers for virtualization*.
-. On the right side of the provider, select *Select migration network* from the {kebab}.
-. Select a network from the list of available networks and click *Select*.
+. In the {ocp} web console, click *Migration* -> *Plans for virtualization*.
+. Click the plan you want to work with.
++
+The *Plan details* page opens.
+. In the *Settings* section, click the Edit icon next to the *Transfer network*.
++
+The *Edit migration plan transfer network* window opens.
+. Select a network from the list of available networks and click *Save*.
 //. Click the network number in the *Networks* column beside the provider to verify that the selected network is the default migration network.

documentation/modules/selecting-migration-network-for-vmware-source-provider.adoc

@@ -11,6 +11,7 @@ You can select a migration network in the {ocp} web console for a source provide
 Using the default network for migration can result in poor performance because the network might not have sufficient bandwidth. This situation can have a negative effect on the source platform because the disk transfer operation might saturate the network.
 
 include::snip_vmware_esxi_nfc.adoc[]
+include::snip-mtu-value.adoc[]
 
 .Prerequisites
 

documentation/modules/snip-mtu-value.adoc

@@ -0,0 +1,6 @@
+:_content-type: SNIPPET
+
+[NOTE]
+====
+If you input any value of maximum transmission unit (MTU) besides the default value in your migration network, you must also input the same value in the {ocp-short} transfer network that you use For more information about the {ocp-short} transfer network, see xref:creating-migration-plan-2-7_provider[Creating a migration plan starting with a source provider] or xref:creating-migration-plan-2-7_vms[Creating a migration plan starting with specific VMs].
+====