after Martin

Author: RichardHoch

documentation/doc-Migration_Toolkit_for_Virtualization/master.adoc

@@ -426,8 +426,6 @@ include::modules/canceling-migration-cli-specific.adoc[leveloffset=+4]
 :ova:
 
 include::modules/proc_migrating-virtual-machines-cli.adoc[leveloffset=+2]
-<<<<<<< HEAD
-=======
 
 include::modules/canceling-migration-cli.adoc[leveloffset=+3]
 
@@ -440,7 +438,6 @@ include::modules/canceling-migration-cli-specific.adoc[leveloffset=+4]
 :cnv:
 
 include::modules/proc_migrating-virtual-machines-cli.adoc[leveloffset=+2]
->>>>>>> fb05b30 (beginning of draft)
 
 include::modules/canceling-migration-cli.adoc[leveloffset=+3]
 

documentation/modules/about-configuring-target-vm-scheduling.adoc

@@ -15,8 +15,6 @@ Previously, when you migrated VMs to {virt}, {virt} automatically determined the
 
 Target VM scheduling is designed to help you with the following use cases, among others: 
 
-* *Prioritizing critical workloads*: In many migrations, there are VMs that must be among the first migrated and powered up. Node selector rules let you ensure that specific VMs are migrated first to support other VMs that are migrated afterwards.
-
 * *Business continuity and disaster recovery*: You can use scheduling rules to migrate and power up critical VMs to several sites, in different time zones or otherwise geographically separated by significant distances. This allows you to deploy these VMs as strategic assets for business continuity, such as disaster recovery.
 
 * *Working with fluctuating demands*: In situations where demand for a service might vary significantly, rules for scheduling when to spin up VMs based on demand allows you to use your resources more efficiently.

documentation/modules/creating-plan-wizard-vmware.adoc

@@ -313,7 +313,9 @@ Changes you make on the *Virtual Machines* tab override any changes on the *Plan
 
 .. *VM target node selector*, *VM target labels*, and *VM target affinity rules* are options that support VM target scheduling, a feature that lets you direct {project-short} to migrate virtual machines (VMs) to specific nodes or workloads (pods) of {virt} as well as to schedule when the VMs are powered on.
 +
-For more information on the feature in general, see TBD Target VM scheduling options. For more details on using the feature with the UI, see TBD Scheduling target VMs from the user interface.
+// For more information on the feature in general, see xref:target-vm-scheduling-options_mtv[Target VM scheduling options].
+
+// For more details on using the feature with the UI, see xref:configuring-target-vm-scheduling-ui_{context}[Scheduling target VMs from the user interface].
 
 * *VM target node selector* allows you to create mandatory exact match key-value label pairs that the target node must possess. If no node on the cluster has all the labels specified, the VM is not scheduled and it remains in a `Pending` state until there is space on a node that fits the key-value label pairs.
 

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

@@ -20,8 +20,6 @@ In version 2.10.0 and later, {project-short} detects if you have selected a user
 {project-short} supports using UDNs for all providers except {virt}.
 ====
 
-For more information about UDNs, see 'About user defined networks' in _Migrating your virtual machines to Red Hat {virt}_. Migration procedures have been updated to include UDNs.
-
 [NOTE]
 ====
 You can override the default migration network of the provider by selecting a different network when you create a migration plan.