CQA 11th March - TOC fix

documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_advanced-migration-options.adoc

@@ -45,6 +45,8 @@ include::../modules/con_scheduling-target-vms-intro.adoc[leveloffset=+1]
 
 include::../modules/about-configuring-target-vm-scheduling.adoc[leveloffset=+2]
 
+include::../modules/about-configuring-target-vm-scheduling-toc-sections.adoc[leveloffset=+1]
+
 include::../modules/target-vm-scheduling-prerequisites.adoc[leveloffset=+2]
 
 include::../modules/target-vm-scheduling-options.adoc[leveloffset=+2]

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

@@ -38,6 +38,8 @@ include::../modules/mtv-shared-disks-known-issues.adoc[leveloffset=+3]
 
 include::../modules/mtv-shared-disks-workarounds.adoc[leveloffset=+3]
 
+include::../modules/mtv-shared-disks-workarounds-toc-sections.adoc[leveloffset=+1]
+
 include::../modules/mtv-template-utility.adoc[leveloffset=+2]
 
 include::../modules/canceling-migration-cli.adoc[leveloffset=+2]
@@ -49,4 +51,4 @@ include::../modules/canceling-migration-cli-specific.adoc[leveloffset=+3]
 :vmware!:
 
 ifdef::parent-context[:context: {parent-context}]
-ifndef::parent-context[:!context:]
+ifndef::parent-context[:!context:]

documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_troubleshooting-migration.adoc

@@ -32,6 +32,8 @@ include::../modules/proc_troubleshooting-vddk-required-vsan.adoc[leveloffset=+2]
 
 include::../modules/con_troubleshooting-storage-copy-offload.adoc[leveloffset=+1]
 
+include::../modules/con_troubleshooting-storage-copy-offload-toc-sections.adoc[leveloffset=+1]
+
 include::../modules/using-must-gather.adoc[leveloffset=+1]
 
 include::../modules/collected-logs-cr-info.adoc[leveloffset=+1]

documentation/doc-Migrating_your_virtual_machines/assemblies/assembly_understanding-mtv-migration.adoc

@@ -16,10 +16,14 @@ Understand the {project-first} custom resources, services, and workflows that en
 
 include::../modules/mtv-resources-and-services.adoc[leveloffset=+1]
 
+include::../modules/mtv-resources-and-services-toc-sections.adoc[leveloffset=+1]
+
 include::../modules/mtv-workflow.adoc[leveloffset=+1]
 
 include::../modules/virt-migration-workflow.adoc[leveloffset=+2]
 
+include::../modules/virt-v2v-mtv-toc-sections.adoc[leveloffset=+1]
+
 include::../modules/virt-v2v-mtv.adoc[leveloffset=+2]
 
 include::../modules/raw-copy-mode.adoc[leveloffset=+2]

documentation/doc-Planning_your_migration/assemblies/assembly_cold-warm-migration.adoc

@@ -16,6 +16,10 @@ ifdef::context[:parent-context: {context}]
 
 include::../modules/about-cold-warm-migration.adoc[leveloffset=+1]
 
+include::../modules/about-cold-warm-migration-toc-sections.adoc[leveloffset=+1]
+
+include::../modules/warm-migration-stages-toc-sections.adoc[leveloffset=+1]
+
 include::../modules/warm-migration-stages.adoc[leveloffset=+1]
 
 include::../modules/mtv-migration-speed-comparison.adoc[leveloffset=+1]

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

@@ -26,8 +26,12 @@ include::../modules/con_navigating-mtv-pages.adoc[leveloffset=+1]
 
 include::../modules/mtv-ui.adoc[leveloffset=+1]
 
+include::../modules/mtv-ui-toc-sections.adoc[leveloffset=+1]
+
 include::../modules/mtv-overview-page.adoc[leveloffset=+1]
 
+include::../modules/mtv-overview-page-toc-sections.adoc[leveloffset=+1]
+
 include::../modules/proc_choosing-different-controller-transfer-network.adoc[leveloffset=+2]
 
 include::../modules/con_preparing-vms-for-migration.adoc[leveloffset=+1]

documentation/doc-Planning_your_migration/assemblies/assembly_planning-migration-vmware.adoc

@@ -25,10 +25,16 @@ include::../modules/creating-yaml-based-storage-maps-ui-vmware.adoc[leveloffset=
 
 include::../modules/about-storage-copy-offload.adoc[leveloffset=+1]
 
+include::../modules/about-storage-copy-offload-toc-sections.adoc[leveloffset=+1]
+
 include::../modules/proc_storage-copy-offload-steps.adoc[leveloffset=+2]
 
+include::../modules/con_copy-methods-sco-toc-sections.adoc[leveloffset=+1]
+
 include::../modules/con_copy-methods-sco.adoc[leveloffset=+2]
 
+include::../modules/proc_storage-copy-offload-general-ssh-set-up-toc-sections.adoc[leveloffset=+1]
+
 include::../modules/proc_storage-copy-offload-vib-set-up.adoc[leveloffset=+3]
 
 include::../modules/proc_storage-copy-offload-general-ssh-set-up.adoc[leveloffset=+3]

documentation/doc-Planning_your_migration/assemblies/assembly_provider-specific-requirements-for-migration.adoc

@@ -22,6 +22,8 @@ include::../modules/ostack-app-cred-auth.adoc[leveloffset=+2]
 
 include::../modules/vmware-prerequisites.adoc[leveloffset=+1]
 
+include::../modules/vmware-prerequisites-toc-sections.adoc[leveloffset=+1]
+
 include::../modules/creating-vmware-role-mtv-permissions.adoc[leveloffset=+2]
 
 include::../modules/creating-vddk-image.adoc[leveloffset=+2]
@@ -38,6 +40,8 @@ include::../modules/cnv-cnv-live-prerequisites.adoc[leveloffset=+2]
 
 include::../modules/compatibility-guidelines.adoc[leveloffset=+1]
 
+include::../modules/compatibility-guidelines-toc-sections.adoc[leveloffset=+1]
+
 ifdef::parent-context[:context: {parent-context}]
 ifndef::parent-context[:!context:]
 

documentation/doc-Planning_your_migration/assemblies/assembly_software-requirements-for-migration.adoc

@@ -20,6 +20,8 @@ include::../modules/storage-support.adoc[leveloffset=+1]
 
 include::../modules/network-prerequisites.adoc[leveloffset=+1]
 
+include::../modules/network-prerequisites-toc-sections.adoc[leveloffset=+1]
+
 include::../modules/ref_source-vm-prerequisites.adoc[leveloffset=+1]
 
 include::../modules/ref_source-vm-migration-considerations.adoc[leveloffset=+1]

documentation/modules/about-cold-warm-migration-toc-sections.adoc

@@ -0,0 +1,26 @@
+= Cold migration
+
+
+Cold migration is the default migration type. The source virtual machines are shut down while the data is copied.
+
+Cold migration converts each VM to be compatible with {ocp-short} before transferring it. If a VM cannot be converted, the migration fails immediately (fail fast). All disk blocks are copied once in a sequential process.
+
+[NOTE]
+====
+VMware only: In cold migrations, in situations in which a package manager cannot be used during the migration, {project-short} does not install the `qemu-guest-agent` daemon on the migrated VMs. This has some impact on the functionality of the migrated VMs, but overall, they are still expected to function.
+
+To enable {project-short} to automatically install `qemu-guest-agent` on the migrated VMs, ensure that your package manager can install the daemon during the first boot of the VM after migration.
+
+If that is not possible, use your preferred automated or manual procedure to install `qemu-guest-agent` manually.
+====
+
+== Warm migration
+
+Warm migration copies most of the data while the source virtual machines (VMs) remain running, minimizing downtime.
+
+The migration process has two stages:
+
+* *Precopy stage*: Most data is copied while VMs continue running. VM disks are copied incrementally using link:https://kb.vmware.com/s/article/1020128[changed block tracking (CBT)] snapshots.
+* *Cutover stage*: VMs are shut down and the remaining data is migrated. Data stored in RAM is not migrated.
+
+Warm migration transfers snapshots to {ocp-short} first, then converts the VM during the cutover stage. This means disk blocks may be copied multiple times if the VM has high utilization, but VMs remain available during most of the migration process. You must enable CBT for each source VM and each VM disk before starting a warm migration.

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

@@ -16,28 +16,3 @@ OVA migration is validated for migrating supported guest operating systems expor
 ====
 
 [id="cold-migration_{context}"]
-== Cold migration
-
-Cold migration is the default migration type. The source virtual machines are shut down while the data is copied.
-
-Cold migration converts each VM to be compatible with {ocp-short} before transferring it. If a VM cannot be converted, the migration fails immediately (fail fast). All disk blocks are copied once in a sequential process.
-
-[NOTE]
-====
-VMware only: In cold migrations, in situations in which a package manager cannot be used during the migration, {project-short} does not install the `qemu-guest-agent` daemon on the migrated VMs. This has some impact on the functionality of the migrated VMs, but overall, they are still expected to function.
-
-To enable {project-short} to automatically install `qemu-guest-agent` on the migrated VMs, ensure that your package manager can install the daemon during the first boot of the VM after migration.
-
-If that is not possible, use your preferred automated or manual procedure to install `qemu-guest-agent` manually.
-====
-
-== Warm migration
-
-Warm migration copies most of the data while the source virtual machines (VMs) remain running, minimizing downtime.
-
-The migration process has two stages:
-
-* *Precopy stage*: Most data is copied while VMs continue running. VM disks are copied incrementally using link:https://kb.vmware.com/s/article/1020128[changed block tracking (CBT)] snapshots.
-* *Cutover stage*: VMs are shut down and the remaining data is migrated. Data stored in RAM is not migrated.
-
-Warm migration transfers snapshots to {ocp-short} first, then converts the VM during the cutover stage. This means disk blocks may be copied multiple times if the VM has high utilization, but VMs remain available during most of the migration process. You must enable CBT for each source VM and each VM disk before starting a warm migration.

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

@@ -0,0 +1,8 @@
+= Use cases
+
+
+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.
+
+* *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-configuring-target-vm-scheduling.adoc

@@ -10,11 +10,3 @@
 Starting with {project-first} 2.10, you can use the _target VM scheduling_ feature to direct {project-short} to migrate virtual machines (VMs) to specific nodes of {virt} as well as to schedule when to power on the VMs. Using the feature, you can design and enforce rules that you set using either the UI or command-line interface.
 
 Previously, when you migrated VMs to {virt}, {virt} automatically determined the node the VMs would be migrated to. Although this served many customers' needs, there are certain situations in which it is useful to be able to specify the target node of a VM or the conditions under which the VM is powered on, regardless of the type of migration involved.
-
-== Use cases
-
-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.
-
-* *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-toc-sections.adoc

@@ -0,0 +1,41 @@
+= How storage copy offload works
+
+
+Without storage copy offload, {project-short} migrates a virtual disk as follows:
+
+. {project-short} reads the disk from the source storage.
+. {project-short} sends the data over a network to {virt}.
+. {virt} writes the data to its storage.
++
+This method can be slow and consume significant network and host resources.
+
+With storage copy offload, the process is streamlined:
+
+. {project-short} initiates a disk transfer request.
+. Instead of sending the data, {project-short} instructs the storage array in which the vSphere Virtual Machine File System (VMFS) datastore holds the source VMs to perform a direct copy from the source storage to the target volume, on the same array, in the correct storage class.
++
+The storage array handles the cloning of the VM disk internally, often at a much higher speed than a network-based transfer.
+
+The Forklift project, a key component of {project-short}, includes a specialized volume populator named `vsphere-xcopy-volume-populator` that directly interacts with {vmw}'s VAAI. This allows {project-short} to trigger the high-speed, array-level data copy operation for supported storage systems.
+
+[IMPORTANT]
+====
+The storage arrays must be the ones specified above. Otherwise, XCOPY performs a fallback network disk copy on the ESXi. Although a fallback network disk copy on the ESXi is usually considerably faster than a standard migration using a VDDK image over the network, it is not as quick as a properly configured storage copy offload migration.
+====
+
+[id="storage-copy-offload-works-supported-providers_{context}"]
+== Supported storage providers
+
+The following storage providers support storage copy offload:
+
+* Hitachi Vantara
+* NetApp ONTAP
+* Pure Storage FlashArray
+* Dell PowerMax
+* Dell PowerFlex
+* Dell PowerStore
+* HPE 3PAR
+* HPE Primera
+* Infinidat Infinibox
+* IBM Flashsystem
+

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

@@ -30,43 +30,3 @@ features, see https://access.redhat.com/support/offerings/techpreview/[Technolog
 ====
 
 [id="how-storage-copy-offload-works_{context}"]
-== How storage copy offload works 
-
-Without storage copy offload, {project-short} migrates a virtual disk as follows:
-
-. {project-short} reads the disk from the source storage.
-. {project-short} sends the data over a network to {virt}.
-. {virt} writes the data to its storage.
-+
-This method can be slow and consume significant network and host resources.
-
-With storage copy offload, the process is streamlined:
-
-. {project-short} initiates a disk transfer request.
-. Instead of sending the data, {project-short} instructs the storage array in which the vSphere Virtual Machine File System (VMFS) datastore holds the source VMs to perform a direct copy from the source storage to the target volume, on the same array, in the correct storage class.
-+
-The storage array handles the cloning of the VM disk internally, often at a much higher speed than a network-based transfer.
-
-The Forklift project, a key component of {project-short}, includes a specialized volume populator named `vsphere-xcopy-volume-populator` that directly interacts with {vmw}'s VAAI. This allows {project-short} to trigger the high-speed, array-level data copy operation for supported storage systems.
-
-[IMPORTANT]
-====
-The storage arrays must be the ones specified above. Otherwise, XCOPY performs a fallback network disk copy on the ESXi. Although a fallback network disk copy on the ESXi is usually considerably faster than a standard migration using a VDDK image over the network, it is not as quick as a properly configured storage copy offload migration.
-====
-
-[id="storage-copy-offload-works-supported-providers_{context}"]
-== Supported storage providers
-
-The following storage providers support storage copy offload:
-
-* Hitachi Vantara
-* NetApp ONTAP
-* Pure Storage FlashArray
-* Dell PowerMax
-* Dell PowerFlex
-* Dell PowerStore
-* HPE 3PAR
-* HPE Primera
-* Infinidat Infinibox
-* IBM Flashsystem
-

documentation/modules/compatibility-guidelines-toc-sections.adoc

@@ -0,0 +1,4 @@
+= OpenShift Operator Life Cycles
+
+
+For more information about the software maintenance Life Cycle classifications for Operators shipped by Red Hat for use with OpenShift Container Platform, see link:https://access.redhat.com/support/policy/updates/openshift_operators#platform-agnostic[OpenShift Operator Life Cycles].

documentation/modules/compatibility-guidelines.adoc

@@ -31,6 +31,3 @@ However, migrations from {rhv-short} 4.3.11 were tested with {project-short} 2.3
 ====
 
 [id="openshift-operator-life-cycles"]
-== OpenShift Operator Life Cycles
-
-For more information about the software maintenance Life Cycle classifications for Operators shipped by Red Hat for use with OpenShift Container Platform, see link:https://access.redhat.com/support/policy/updates/openshift_operators#platform-agnostic[OpenShift Operator Life Cycles].

documentation/modules/con_copy-methods-sco-toc-sections.adoc

@@ -0,0 +1,10 @@
+= Advantages of the SSH method
+
+
+The SSH method offers you the following advantages:
+
+- No VIB installation: Does not require custom VIB deployment on ESXi hosts
+- Standard SSH: Uses the standard ESXi SSH service with no custom components
+- Security: Uses secure key-based authentication with command restrictions
+- Compatibility: Works with any ESXi version that supports SSH
+- Flexibility: Easier to troubleshoot and monitor SSH connections

documentation/modules/con_copy-methods-sco.adoc

@@ -12,13 +12,3 @@ You can use either of the following two cloning (copying) methods to run storage
 vSphere Installation on Bundle (VIB) is the default method. This method uses a custom VIB installed on ESXi hosts to expose `vmkfstools` operations via the vSphere API.
 
 SSH is the recommended method. This method uses SSH to directly run `vmkfstools` commands on ESXi hosts. This method is useful when VIB installation is not possible and for the advantages that follow.
-
-== Advantages of the SSH method
-
-The SSH method offers you the following advantages:
-
-- No VIB installation: Does not require custom VIB deployment on ESXi hosts
-- Standard SSH: Uses the standard ESXi SSH service with no custom components
-- Security: Uses secure key-based authentication with command restrictions
-- Compatibility: Works with any ESXi version that supports SSH
-- Flexibility: Easier to troubleshoot and monitor SSH connections