Merge pull request #98269 from abrennan89/CNV-51253

CNV-51253: Clean up for DITA migration before updating docs

Author: dfitzmau

modules/best-practices-rhacm-discovered-vm.adoc

@@ -0,0 +1,24 @@
+// Module included in the following assemblies:
+//
+// * /virt/backup_restore/virt-disaster-recovery.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="best-practices-rhacm-discovered-vm_{context}"]
+= Best practices when defining an {rh-rhacm}-discovered VM
+
+You can configure any VM in the cluster that is not an {rh-rhacm}-managed application as an {rh-rhacm}-discovered application. This includes VMs imported by using the Migration Toolkit for Virtualization (MTV), VMs created by using the {product-title} web console, or VMs created by any other means, such as the CLI.
+
+You can take several actions to improve your experience and chance of success when defining an {rh-rhacm}-discovered VM.
+
+Protecting the VM when using MTV, the {product-title} web console, or a custom VM:: Because automatic labeling is not currently available, the application owner must manually label the components of the VM application when using MTV, the {product-title} web console, or a custom VM.
++
+After creating the VM, apply a common label to the following resources associated with the VM: `VirtualMachine`, `DataVolume`, `PersistentVolumeClaim`, `Service`, `Route`, `Secret`, `ConfigMap`, `VirtualMachinePreference`, and `VirtualMachineInstancetype`. Do not label virtual machine instances (VMIs) or pods; {VirtProductName} creates and manages these automatically.
++
+[IMPORTANT]
+====
+You must apply the common label to everything in the namespace that you want to protect, including objects that you added to the VM that are not listed here.
+====
+
+Including more than the `VirtualMachine` object in the VM:: Working VMs typically also contain data volumes, persistent volume claims (PVCs), services, routes, secrets, `ConfigMap` objects, and `VirtualMachineSnapshot` objects.
+
+Including the VM as part of a larger logical application:: This includes other pod-based workloads and VMs.

modules/best-practices-rhacm-managed-vm.adoc

@@ -0,0 +1,17 @@
+// Module included in the following assemblies:
+//
+// * /virt/backup_restore/virt-disaster-recovery.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="best-practices-rhacm-managed-vm_{context}"]
+= Best practices when defining an {rh-rhacm}-managed VM
+
+When creating an {rh-rhacm}-managed application that includes a VM, you must use a GitOps workflow and create an {rh-rhacm} application or `ApplicationSet` resource.
+
+You can take several actions to improve your experience and chance of success when defining an {rh-rhacm}-managed VM.
+
+Use a PVC and populator to define storage for the VM:: Because data volumes create persistent volume claims (PVCs) implicitly, data volumes and VMs with data volume templates do not fit as neatly into the GitOps model.
+
+Use the import method when choosing a population source for your VM disk:: Select a {op-system-base} image from the software catalog to use the import method. Red{nbsp}Hat recommends using a specific version of the image rather than a floating tag for consistent results. The KubeVirt community maintains container disks for other operating systems in a Quay repository.
+
+Use `pullMethod: node`:: Use the pod `pullMethod: node` when creating a data volume from a registry source to take advantage of the {product-title} pull secret, which is required to pull container images from the Red{nbsp}Hat registry.

modules/virt-defining-apps-for-dr.adoc

@@ -9,7 +9,16 @@ toc::[]
 {VirtProductName} supports using disaster recovery (DR) solutions to ensure that your environment can recover after a site outage. To use these methods, you must plan your {VirtProductName} deployment in advance.
 
 include::modules/virt-about-dr-methods.adoc[leveloffset=+1]
-include::modules/virt-defining-apps-for-dr.adoc[leveloffset=+1]
+
+[id="virt-disaster-recovery-defining-apps_{context}"]
+== Defining applications for disaster recovery
+
+Define applications for disaster recovery by using VMs that {rh-rhacm-first} manages or discovers.
+
+include::modules/best-practices-rhacm-managed-vm.adoc[leveloffset=+2]
+
+include::modules/best-practices-rhacm-discovered-vm.adoc[leveloffset=+2]
+
 include::modules/virt-vm-behavior-dr.adoc[leveloffset=+1]
 
 [id="dr-solutions-rh-managed-clusters_{context}"]
@@ -25,4 +34,4 @@ include::modules/virt-regional-dr-odf.adoc[leveloffset=+2]
 == Additional resources
 * link:https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/latest/html/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/index[Configuring {rh-storage} Disaster Recovery for OpenShift Workloads]
 * link:https://access.redhat.com/articles/7053115[Use {rh-storage} Disaster Recovery to Protect Virtual Machines] in the Red{nbsp}Hat Knowledgebase
-* link:https://docs.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.10[Red{nbsp}Hat Advanced Cluster Management for Kubernetes 2.10]
+* link:https://docs.redhat.com/documentation/en-us/red_hat_advanced_cluster_management_for_kubernetes/2.10[Red{nbsp}Hat Advanced Cluster Management for Kubernetes 2.10]