CQA (26 feb 26) - MTV report

documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_migrating-from-cnv.adoc

@@ -9,9 +9,7 @@ ifdef::context[:parent-context: {context}]
 [role="_abstract"]
 Run your {virt} migration plan from the MTV UI or from the command-line.
 
-== Prerequisites
-
-* You have planned your migration from {virt}.
+include::../modules/con_prerequisites-migrating-cnv.adoc[leveloffset=+1]
 
 :context: cnv
 :cnv:

documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_migrating-from-osp.adoc

@@ -11,9 +11,7 @@ ifdef::context[:parent-context: {context}]
 [role="_abstract"]
 Run your {osp} migration plan from the MTV UI or from the command-line.
 
-== Prerequisites
-
-* You have planned your migration from {osp}.
+include::../modules/con_prerequisites-migrating-osp.adoc[leveloffset=+1]
 
 :context: ostack
 :ostack:

documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_migrating-from-ova.adoc

@@ -13,9 +13,7 @@ Run your OVA migration plan from the MTV UI or from the command-line.
 
 include::../modules/con_ova-scope-and-limitations.adoc[leveloffset=+1]
 
-== Prerequisites
-
-* You have planned your migration from OVA.
+include::../modules/con_prerequisites-migrating-ova.adoc[leveloffset=+1]
 
 :context: ova
 :ova:

documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_migrating-from-rhv.adoc

@@ -11,9 +11,7 @@ ifdef::context[:parent-context: {context}]
 [role="_abstract"]
 Run your {rhv-full} migration plan from the MTV UI or from the command-line.
 
-== Prerequisites
-
-* You have planned your migration from {rhv-full}.
+include::../modules/con_prerequisites-migrating-rhv.adoc[leveloffset=+1]
 
 :context: rhv
 :rhv:

documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_migrating-from-vmware.adoc

@@ -12,9 +12,7 @@ ifdef::context[:parent-context: {context}]
 [role="_abstract"]
 Run your VMware migration plan from the MTV UI or from the command-line.
 
-== Prerequisites
-
-* You have planned your migration from VMware vSphere.
+include::../modules/con_prerequisites-migrating-vmware.adoc[leveloffset=+1]
 
 :context: vmware
 :vmware:

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

@@ -15,6 +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:
 
-* *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.
+* *Business continuity and disaster recovery*: You can use scheduling rules to migrate and power on 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 upon demand allows you to use your resources more efficiently.

documentation/modules/about-storage-copy-offload.adoc

@@ -15,7 +15,7 @@ You can migrate {vmw} virtual machines (VMs) that are in a storage array network
 
 You enable storage copy offload by configuring the storage map in your migration plan to point to your storage array instead of the network you usually use for migration. When you start the migration plan, {project-short} migrates your VMs by copying them to the storage array you choose and using `XCOPY` to copy them directly to {virt}, instead of transmitting the contents of your VMs to {virt}.
 
-The storage copy offload feature has some unique configuration prerequisites, which are discussed in link:https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/2.10/html/planning_your_migration_to_red_hat_openshift_virtualization/assembly_planning-migration-vmware_mtv#proc_storage-copy-offload-steps[Planning and running storage copy offload migrations]. Once you configure your system, you can migrate plans using storage copy offload by using either the {project-short} UI or its CLI. Instructions for using storage offload have been integrated into the procedures for migrating {vmw} VMs for both the UI and CLI.
+The storage copy offload feature has some unique configuration prerequisites, which are discussed in link:https://docs.redhat.com/en/documentation/migration_toolkit_for_virtualization/2.10/html/planning_your_migration_to_red_hat_openshift_virtualization/assembly_planning-migration-vmware_mtv#proc_storage-copy-offload-steps[Planning and running storage copy offload migrations]. Once you configure your system, you can migrate plans by using storage copy offload with either the {project-short} UI or its CLI. Instructions for using storage offload have been integrated into the procedures for migrating {vmw} VMs for both the UI and CLI.
 
 You must ensure that your migration plans do not mix VDDK mappings with copy-offload mappings. Because the migration controller copies disks either through CDI volumes (VDDK) or through Volume Populators (copy-offload), all storage pairs in the plan must either include copy-offload details (a `Secret` + product) or none of them must. Otherwise, the plan fails.
 

documentation/modules/adding-hook-using-ui.adoc

@@ -29,14 +29,14 @@ You can run one pre-migration hook, one post-migration hook, or one of each per
 .. In the *Pre migration hook* section, toggle the *Enable hook* switch to *Enable pre migration hook*.
 .. Enter the *Hook runner image*. If you are specifying the `spec.playbook`, you need to use an image that has an `ansible-runner`.
 .. Optional: Enter the *Service account* name. The service account must have the necessary RBAC permissions to manage cluster resources and at least write access for the `openshift-mtv` namespace where hooks execute.
-.. Paste your hook as a YAML file in the *Ansible playbook* text box. 
+.. Paste your hook as a YAML file in the *Ansible Playbook* text box. 
 
 . For a post-migration hook, perform the following steps:
 
 .. In the *Post migration hook*, toggle the *Enable hook* switch to *Enable post migration hook*.
 .. Enter the *Hook runner image*. If you are specifying the `spec.playbook`, you need to use an image that has an `ansible-runner`.
 .. Optional: Enter the *Service account* name. The service account must have the necessary RBAC permissions to manage cluster resources and at least write access for the `openshift-mtv` namespace where hooks execute.
-.. Paste your hook as a YAML file in the *Ansible playbook* text box.
+.. Paste your hook as a YAML file in the *Ansible Playbook* text box.
 
 . At the top of the tab, click *Update hooks*.
 +

documentation/modules/compatibility-guidelines.adoc

@@ -27,7 +27,7 @@ Generally it is advised to upgrade {rhv-full} Manager to the previously mentione
 
 Therefore, it is recommended to upgrade {rhv-short} to the supported version above before the migration to {virt}.
 
-However, migrations from {rhv-short} 4.3.11 were tested with {project-short} 2.3, and might work in practice in many environments using {project-short} {project-version}. In this case, it is recommended to upgrade {rhv-full} Manager to the previously mentioned supported version before the migration to {virt}.
+However, migrations from {rhv-short} 4.3.11 were tested with {project-short} 2.3, and might work in practice in many environments by using {project-short} {project-version}. In this case, it is recommended to upgrade {rhv-full} Manager to the previously mentioned supported version before the migration to {virt}.
 ====
 
 [id="openshift-operator-life-cycles"]

documentation/modules/con_about-configuring-importer-pods.adoc

@@ -8,7 +8,7 @@
 = About scheduling importer pods
 
 [role="_abstract"]
-{project-full} uses `virt-v2v` convertor pods, or _importer pods_, to transfer data from VMware source virtual machines (VMs) to target VMs. 
+{project-full} uses `virt-v2v` converter pods, or _importer pods_, to transfer data from VMware source virtual machines (VMs) to target VMs. 
 
 By default, {virt} assigns the nodes to which these importer pods transfer data. However, for cold migrations from VMware VMs, you can schedule the destination nodes for the importer pods.
 

documentation/modules/con_common-migration-issues.adoc

@@ -20,7 +20,7 @@ Verify that you have created a network mapping that correctly links the source n
 To resolve this issue:
 
 . Create the required network attachment definition in {virt}.
-. Update or recreate your network mapping to reference the correct destination network.
+. Update or re-create your network mapping to reference the correct destination network.
 . Validate that the network mapping shows a `Ready` status before starting the migration.
 
 *Why does warm migration fail with a snapshot error?*
@@ -50,7 +50,7 @@ Invalid VM names include those that:
 * Use uppercase letters
 * Use a name that differs from the VM's files or folder name on the datastore
 
-{project-short} automatically adjusts non-compliant VM names in the target cluster by replacing invalid characters. Alternatively, you can rename target VMs in the {project-short} UI during migration plan creation.
+{project-short} automatically adjusts noncompliant VM names in the target cluster by replacing invalid characters. Alternatively, you can rename target VMs in the {project-short} UI during migration plan creation.
 
 For {vmw} environments, you can use Storage vMotion to rename the VM before migration. This migration process automatically renames the VM's files and folder on the datastore to match the new name you have given it in the vSphere Client. Alternatively, you can manually remove the VM from inventory, rename the files and folders, edit the `.vmx` file to update the references, and then re-add the VM to the inventory.
 

documentation/modules/con_prerequisites-migrating-cnv.adoc

@@ -0,0 +1,12 @@
+// Module included in the following assemblies:
+//
+// * documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_migrating-from-cnv.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="con_prerequisites-migrating-cnv_{context}"]
+= Prerequisites
+
+[role="_abstract"]
+Ensure that you have completed the planning steps before running your {virt} migration.
+
+* You have planned your migration from {virt}.

documentation/modules/con_prerequisites-migrating-osp.adoc

@@ -0,0 +1,12 @@
+// Module included in the following assemblies:
+//
+// * documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_migrating-from-osp.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="con_prerequisites-migrating-osp_{context}"]
+= Prerequisites
+
+[role="_abstract"]
+Ensure that you have completed the planning steps before running your {osp} migration.
+
+* You have planned your migration from {osp}.

documentation/modules/con_prerequisites-migrating-ova.adoc

@@ -0,0 +1,12 @@
+// Module included in the following assemblies:
+//
+// * documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_migrating-from-ova.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="con_prerequisites-migrating-ova_{context}"]
+= Prerequisites
+
+[role="_abstract"]
+Ensure that you have completed the planning steps before running your OVA migration.
+
+* You have planned your migration from OVA.

documentation/modules/con_prerequisites-migrating-rhv.adoc

@@ -0,0 +1,12 @@
+// Module included in the following assemblies:
+//
+// * documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_migrating-from-rhv.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="con_prerequisites-migrating-rhv_{context}"]
+= Prerequisites
+
+[role="_abstract"]
+Ensure that you have completed the planning steps before running your {rhv-full} migration.
+
+* You have planned your migration from {rhv-full}.

documentation/modules/con_prerequisites-migrating-vmware.adoc

@@ -0,0 +1,12 @@
+// Module included in the following assemblies:
+//
+// * documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_migrating-from-vmware.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="con_prerequisites-migrating-vmware_{context}"]
+= Prerequisites
+
+[role="_abstract"]
+Ensure that you have completed the planning steps before running your VMware migration.
+
+* You have planned your migration from VMware vSphere.

documentation/modules/con_troubleshooting-storage-copy-offload.adoc

@@ -6,6 +6,7 @@
 [id="con_troubleshooting-storage-copy-offload_{context}"]
 = Troubleshooting storage copy offload
 
+[role="_abstract"]
 This section describes problems that are unique to storage copy offload and how you can resolve them.
 
 [id=sco-vsphere-esxi-connectivity_{context}]
@@ -15,7 +16,7 @@
 +
 *Description*: Sometimes a remote ESXi execution fails, returning a SOAP error with no apparent root cause message.
 +
-*Explanation*: Because vSphere invokes some SOAP/REST endpoints on the ESXi, a connection can fail because of standard error reasons that vanish after the next try.
+*Explanation*: Because vSphere invokes some SOAP or REST endpoints on the ESXi, a connection can fail because of standard error reasons that vanish after the next try.
 +
 *Solution*: If the populator fails, the migration can be restarted. Try to restart or retry the populator, or restart the migration.
 
@@ -30,7 +31,7 @@
 +
 *Explanation*: If the VIB is installed, but `/etc/init.d/hostd` did not restart, then the `vmkfstools` namespace in `esxcli` is either not updated or does not exist. If that namespace does not exist, it means that this is the first usage, probably right after the first use.
 +
-*Solution*: Use SSH to log in to the ESXi and run `/etc/init.d/hostd restart`. Wait for a few seconds until the ESXi renews the connection with vSphere.
+*Solution*: Use SSH to log in to the ESXi host and run `/etc/init.d/hostd restart`. Wait for a few seconds until the ESXi renews the connection with vSphere.
 
 [id=sco-ssh-issues_{context}]
 == SSH error messages
@@ -43,9 +44,9 @@
 
 ** The SSH is disabled.
 +
-*Solution*: Manually enable an SSH connection on the ESXi host by using the commands in {mtv-mig}assembly_planning-migration-vmware_mtv#proc_storage-copy-offload-manual-ssh-set-up_vmware[Setting up storage copy offload using manually generated SSH keys].
+*Solution*: Manually enable an SSH connection on the ESXi host by using the commands in {mtv-mig}assembly_planning-migration-vmware_mtv#proc_storage-copy-offload-manual-ssh-set-up_vmware[Setting up storage copy offload by using manually generated SSH keys].
 
 ** There is a problem with the network connectivity.
 +
 *Solution*: Verify that the ESXi management network is accessible from the migration pods.
 

documentation/modules/configuring-plan-settings-vmware.adoc

@@ -7,7 +7,7 @@
 = Configuring VMware migration plan settings
 
 [role="_abstract"]
-After you create a migration plan using the {project-full} wizard, the *Plan details* page opens. This page contains important settings that do not appear in the wizard but can affect your migration. You can configure these settings immediately after creating the plan or return to configure them later before running the plan.
+After you create a migration plan by using the {project-full} wizard, the *Plan details* page opens. This page contains important settings that do not appear in the wizard but can affect your migration. You can configure these settings immediately after creating the plan or return to configure them later before running the plan.
 
 .Prerequisites
 
@@ -188,7 +188,7 @@ Additionally, both target affinity and target anti-affinity rules allow you to i
 *** Click the *Edit* icon.
 *** Click *Add affinity rule*.
 *** Select the *Type* of affinity rule from the list. Valid options: Node Affinity, Workload (pod) Affinity, Workload (pod) Anti-Affinity.
-*** Select the *Condition* rom the list. Valid options: Preferred during scheduling (soft condition), Required  during scheduling (hard condition).
+*** Select the *Condition* from the list. Valid options: Preferred during scheduling (soft condition), Required  during scheduling (hard condition).
 *** Soft condition only: Enter a numerical *Weight*. The higher the weight, the stronger the preference. Valid options: whole numbers from 1-100.
 *** Enter a *Typology key*, the key for the node label that the system uses to denote the domain.
 *** Optional: Select the *Workload labels* that you want to set by doing the following:

documentation/modules/creating-plan-wizard-cnv-live.adoc

@@ -109,7 +109,7 @@ If they are both {virt} clusters, have someone with `cluster-admin` privileges e
 
 . To add a hook, select the appropriate *Enable hook* checkbox.
 . Enter the *Hook runner image*.
-. Enter the *Ansible playbook* of the hook in the window.
+. Enter the *Ansible Playbook* of the hook in the window.
 +
 [NOTE]
 ====

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

@@ -137,7 +137,7 @@ To learn more about the different types of networks {ocp-short} supports, see li
 
 . To add a hook, select the appropriate *Enable hook* checkbox.
 . Enter the *Hook runner image*.
-. Enter the *Ansible playbook* of the hook in the window.
+. Enter the *Ansible Playbook* of the hook in the window.
 +
 [NOTE]
 ====

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

@@ -139,7 +139,7 @@ To learn more about the different types of networks {ocp-short} supports, see li
 
 . To add a hook, select the appropriate *Enable hook* checkbox.
 . Enter the *Hook runner image*.
-. Enter the *Ansible playbook* of the hook in the window.
+. Enter the *Ansible Playbook* of the hook in the window.
 +
 [NOTE]
 ====

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

@@ -138,7 +138,7 @@ To learn more about the different types of networks {ocp-short} supports, see li
 
 . To add a hook, select the appropriate *Enable hook* checkbox.
 . Enter the *Hook runner image*.
-. Enter the *Ansible playbook* of the hook in the window.
+. Enter the *Ansible Playbook* of the hook in the window.
 +
 [NOTE]
 ====

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

@@ -148,7 +148,7 @@ To learn more about the different types of networks {ocp-short} supports, see li
 
 . To add a hook, select the appropriate *Enable hook* checkbox.
 . Enter the *Hook runner image*.
-. Enter the *Ansible playbook* of the hook in the window.
+. Enter the *Ansible Playbook* of the hook in the window.
 +
 [NOTE]
 ====

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

@@ -173,7 +173,7 @@ Migrating shared disks might slow down the migration process.
 
 . To add a hook, select the appropriate *Enable hook* checkbox.
 . Enter the *Hook runner image*.
-. Enter the *Ansible playbook* of the hook in the window.
+. Enter the *Ansible Playbook* of the hook in the window.
 +
 [NOTE]
 ====

documentation/modules/issue_templates/issue.md

@@ -2,11 +2,11 @@
 
 (Describe the problem. Don't worry if the problem occurs in more than one checklist. You only need to mention the checklist where you see a problem. We will fix the module.)
 
-## What is the problem?
+## What is the problem
 
 (Paste the text or a screenshot here. Remember to include the **task number** so that we know which module is affected.)
 
-## What is the solution?
+## What is the solution
 
 (Correct text, link, or task.)