MTV-5019 Preparing the MTV repo for AEM migration

Signed-off-by: Richard Hoch <rhoch@redhat.com>

Author: RichardHoch

documentation/doc-Planning_your_migration/assemblies/assembly_migrating-vms-web-console.adoc

@@ -20,7 +20,7 @@ You must ensure that all prerequisites are met. For more information, see link:{
 
 VMware only: You must have the minimal set of link:{mtv-plan}assembly_provider-specific-requirements-for-migration_mtv#vmware-privileges_mtv[VMware privileges].
 
-VMware only: Creating a link:{mtv-plan}assembly_provider-specific-requirements-for-migration_mtv#proc_creating-vddk-image_mtv[VMware Virtual Disk Development Kit (VDDK)] image will increase migration speed.
+VMware only: link:{mtv-plan}assembly_provider-specific-requirements-for-migration_mtv#proc_creating-vddk-image_mtv[Creating a VMware VDDK image] increases migration speed.
 ====
 
 include::../modules/con_navigating-mtv-pages.adoc[leveloffset=+1]

documentation/modules/common-attributes.adoc

@@ -47,6 +47,6 @@
 :abstract-planning: Install the {project-first} Operator and configure {project-short} to plan a cold or warm migration of virtual machines to Red Hat {virt} on an OpenShift platform. Map the source and destination infrastructure for your migration, including storage and networking, and create validation rules.
 //migrating guide
 :migrating-guide-title: Migrating your virtual machines to Red Hat {virt}
-:subtitle-migrating: Migrating virtual machines from VMware vSphere, {rhv-full} or {osp} platforms, or other platforms to Red Hat {virt} by using the {project-full}
+:subtitle-migrating: Migrating virtual machines from {vmw} vSphere, {rhv-full} or {osp} platforms, or other platforms to Red Hat {virt} by using the {project-full}
 :abstract-migrating: Run your migration plan by using either the {project-first} user interface in the Red Hat OpenShift web console or the command-line interface.
 

documentation/modules/con_about-cold-warm-migration.adoc

@@ -1,4 +1,4 @@
-// Module included in the following assemblies:
+s// Module included in the following assemblies:
 //
 // * documentation/doc-Planning_your_migration/assemblies/assembly_cold-warm-migration.adoc
 
@@ -12,5 +12,5 @@ Choose cold migration for VMs that are shut down and warm migration for running
 
 [NOTE]
 ====
-OVA migration is validated for migrating supported guest operating systems exported from {vmw} vSphere. For third-party networking or security appliances, check with the vendor for native QCOW2 or KVM images.
+OVA migration is validated for migrating supported guest operating systems exported from {vmw} vSphere. For third-party networking or security appliances, check with the vendor for native QCOW2 or Kernel-based Virtual Machine (KVM) images.
 ====

documentation/modules/con_about-mtv.adoc

@@ -7,7 +7,7 @@
 You can use the {project-first} to migrate virtual machines (VMs) from the following source providers to {virt} destination providers:
 
 * {vmw} vSphere
-* {rhv-full} 
+* {rhv-full}
 * {osp}
 * Open Virtual Appliances (OVAs) that were created by {vmw} vSphere
 * Remote {virt} clusters
@@ -16,9 +16,9 @@ You can use the {project-first} to migrate virtual machines (VMs) from the follo
 
 {project-short} supports three types of migration: cold, warm, and live.
 
-Cold migration is available for all of the source providers listed above. This type of migration migrates VMs that are powered *_off_* and does not require common stored storage. 
+Cold migration is available for all of the source providers listed above. This type of migration migrates VMs that are powered *_off_* and does not require shared storage.
 
-Warm migration is available only for {vmw} vSphere and {rhv-full}. This type of migration migrates VMs that are powered *_on_* and does require common stored storage. 
+Warm migration is available only for {vmw} vSphere and {rhv-full}. This type of migration migrates VMs that are powered *_on_* and does require shared storage.
 
 Live migration is available *_only_* for migrations between {virt} clusters or between namespaces on the same {virt} cluster. It requires {project-short} version 2.10 or later and {virt} version 4.20 or later. 
 

documentation/modules/con_about-rego-files.adoc

@@ -7,9 +7,9 @@
 = About Rego files
 
 [role="_abstract"]
-Validation rules are written in Rego, the Open Policy Agent (OPA) native query language. The rules are stored as `.rego` files in the `/usr/share/opa/policies/io/konveyor/forklift/<provider>` directory of the `Validation` pod.
+Validation rules are written in Rego, the Open Policy Agent (OPA) native query language. The rules are stored as `.rego` files in the `/usr/share/opa/policies/io/konveyor/forklift/_<provider>_` directory of the `Validation` pod.
 
-Each validation rule is defined in a separate `.rego` file and tests for a specific condition. If the condition evaluates as `true`, the rule adds a `{“category”, “label”, “assessment”}` hash to the `concerns`. The `concerns` content is added to the `concerns` key in the inventory record of the VM. The web console displays the content of the `concerns` key for each VM in the provider inventory.
+Each validation rule is defined in a separate `.rego` file and tests for a specific condition. If the condition evaluates as `true`, the rule adds a hash containing the `category`, `label`, and `assessment` keys to the `concerns`. The `concerns` content is added to the `concerns` key in the inventory record of the virtual machine (VM). The web console displays the content of the `concerns` key for each VM.
 
 The following `.rego` file example checks for distributed resource scheduling enabled (`has_drs_enabled`) in the cluster of a VMware VM:
 

documentation/modules/con_ova-scope-and-limitations.adoc

@@ -9,7 +9,7 @@
 
 [role="_abstract"]
 
-OVA migration is validated for migrating supported guest operating systems exported from {vmw} vSphere. For third-party networking or security appliances, check with the vendor for native QCOW2 or KVM images.
+OVA migration is validated for migrating supported guest operating systems exported from {vmw} vSphere. For third-party networking or security appliances, check with the vendor for native QCOW2 or Kernel-based Virtual Machine (KVM) images.
 
 The OVA import process utilizes `virt-v2v` to prepare guest operating systems for KVM. Vendor-supplied appliances often use proprietary bootloaders or disk layouts that are incompatible with this conversion. Moreover, converting a vendor OVA may invalidate vendor support agreements. 
 

documentation/modules/con_planning-intro.adoc

@@ -8,8 +8,9 @@
 = Planning a migration
 
 [role="_abstract"]
-You can use the Migration Toolkit for Virtualization (MTV) to plan your migration of virtual machines from the
-following source providers to OpenShift Virtualization destination providers:
+You can use the Migration Toolkit for Virtualization (MTV) to plan your migration of virtual machines (VMs) from specific source providers to OpenShift Virtualization destination providers.
+
+The supported source providers are:
 
 * {vmw} vSphere
 * {rhv-full} 
@@ -19,17 +20,16 @@ following source providers to OpenShift Virtualization destination providers:
 
 [NOTE]
 ====
-OVA migration is validated for migrating supported guest operating systems exported from {vmw} vSphere. For third-party networking or security appliances, check with the vendor for native QCOW2 or KVM images.
+OVA migration is validated for migrating supported guest operating systems exported from {vmw} vSphere. For third-party networking or security appliances, check with the vendor for native QCOW2 or Kernel-based Virtual Machine (KVM) images.
 ====
 
 [id="types-of-migration_{context}"]
 == Types of migration
-
 {project-short} supports three types of migration: cold, warm, and live.
 
-* Cold migration is available for all of the source providers listed above. This type of migration migrates VMs that are powered *_off_* and does not require common stored storage. 
+* Cold migration is available for all of the preceding source providers. This type of migration migrates VMs that are powered _off_ and does not require shared storage.
 
-* Warm migration is available only for {vmw} vSphere and {rhv-full}. This type of migration migrates VMs that are powered *_on_* and does require common stored storage. 
+* Warm migration is available only for {vmw} vSphere and {rhv-full}. This type of migration migrates VMs that are powered _on_ and requires shared storage.
 
 * Live migration is available *_only_* for migrations between {virt} clusters or between namespaces on the same {virt} cluster. It requires {project-short} version 2.10 or later and {virt} version 4.20 or later. 
 

documentation/modules/proc_accessing-default-validation-rules.adoc

@@ -29,8 +29,8 @@ $ cd /usr/share/opa/policies/io/konveyor/forklift/<provider>
 +
 where:
 
-provider::
-Specifies the provider. Valid options: `vmware` or `ovirt`.
+<provider>::
+Specifies the <provider>. Valid options: `vmware` or `ovirt`.
 
 . Search for the default policies:
 +

documentation/modules/proc_adding-source-provider.adoc

@@ -128,7 +128,7 @@ If you have Administrator privileges, you can see all projects, otherwise, you c
 +
 Do one of the following:
 
-** Select the *Skip VMWare Virtual Disk Development Kit (VDDK) SDK acceleration (not recommended)*.
+** Select the *Skip {vmw} Virtual Disk Development Kit (VDDK) SDK acceleration (not recommended)*.
 
 ** Enter the path in the *VDDK init image* text box. Format: `<registry_route_or_server_path>/vddk:<tag>`.
 

documentation/modules/proc_running-migration-plan.adoc

@@ -29,6 +29,11 @@ The *Plans* list displays the source and target providers, the number of virtual
 +
 The plan's *Status* changes to *Running*, and the migration's progress is displayed.
 +
+[WARNING]
+====
+Do not take a snapshot of a VM after you start a migration. Taking a snapshot after a migration starts might cause the migration to fail.
+====
++
 ifdef::vmware,rhv[]
 *Warm migration only*:
 
@@ -50,11 +55,6 @@ A `PreFlightInspection` during warm migration enables early detection of issues
 .. In the *Migration type* column of the migration plan, click *Edit cutover*.
 .. In the *Edit cutover* window, set the date and time of the cutover, and then click *Set cutover*.
 endif::vmware,rhv[]
-+
-[WARNING]
-====
-Do not take a snapshot of a VM after you start a migration. Taking a snapshot after a migration starts might cause the migration to fail.
-====
 
 . Optional: Click the links in the migration's *Status* to see its overall status and the status of each VM:
 
@@ -74,22 +74,18 @@ vMotion, including svMotion, and relocation must be disabled for VMs that are be
 endif::[]
 
 
-. Optional: To view your migration's logs, either as it is running or after it is completed, perform the following actions:
+. To view your migration's logs, either as it is running or after it is completed:
 
 .. Click the *Virtual machines* tab.
-.. Click the arrow (*>*) to the left of the virtual machine whose migration progress you want to check.
-+
-The VM's details are displayed.
+.. Click the arrow (*>*) before the name of the virtual machine whose migration progress you want to check.
 +
 .. In the *Pods* section, in the *Pod links* column, click the *Logs* link.
 +
-The *Logs* tab opens.
-+
 [NOTE]
 ====
-Logs are not always available. The following are common reasons for logs not being available:
+Logs might not be available for the following common reasons:
 
-* The migration is from {virt} to {virt}. In this case, `virt-v2v` is not involved, so no pod is required.
+* The migration is from {virt} to {virt}. In this case, the `virt-v2v` utility is not involved, so no pod is required.
 * No pod was created.
 * The pod was deleted.
 * The migration failed before running the pod.