Merge pull request #83970 from ousleyp/cnv-38773

ousleyp · web-flow · commit c6ce60492cbf · 2024-12-06T16:31:39.000-05:00
CNV#38773: Regional-DR with ODF for virt
diff --git a/modules/virt-about-dr-methods.adoc b/modules/virt-about-dr-methods.adoc
@@ -18,7 +18,4 @@ Metro-DR uses synchronous replication. It writes to storage at both the primary
 [id="regional-dr_{context}"]
 == Regional-DR
 
-Regional-DR uses asynchronous replication. The data in the primary site is synchronized with the secondary site at regular intervals. For this type of replication, you can have a higher latency connection between the primary and secondary sites.
-
-:FeatureName: Regional-DR
-include::snippets/technology-preview.adoc[]
+Regional-DR uses asynchronous replication. The data in the primary site is synchronized with the secondary site at regular intervals. For this type of replication, you can have a higher latency connection between the primary and secondary sites.
diff --git a/modules/virt-defining-apps-for-dr.adoc b/modules/virt-defining-apps-for-dr.adoc
@@ -23,8 +23,6 @@ Because data volumes create persistent volume claims (PVCs) implicitly, data vol
 [discrete]
 [id="use-import-method_{context}"]
 === Use the import method when choosing a population source for your VM disk
-Use the import method to work around limitations in Regional-DR that prevent you from protecting VMs that use cloned PVCs.
-
 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.
 
 [discrete]
@@ -33,7 +31,7 @@ Select a {op-system-base} image from the software catalog to use the import meth
 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.
 
 [id="best-practices-{rh-rhacm}-discovered-vm_{context}"]
-== Best practices when defining an {rh-rhacm}-discovered virtual machine
+== 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 {VirtProductName} web console, or VMs created by any other means, such as the CLI.
 
@@ -44,8 +42,12 @@ There are several actions you can take to improve your experience and chance of
 === Protect the VM when using MTV, the {VirtProductName} 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 {VirtProductName} 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`, and `ConfigMap`. Do not label virtual machine instances (VMIs) or pods
-since {VirtProductName} creates and manages these automatically.
+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.
+====
 
 [discrete]
 [id="working-vm-contains_{context}"]
diff --git a/modules/virt-metro-dr-odf.adoc b/modules/virt-metro-dr-odf.adoc
@@ -6,14 +6,16 @@
 [id="metro-dr-odf_{context}"]
 = Metro-DR for {rh-storage-first}
 
-{VirtProductName} supports the link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.14/html-single/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/index#metro-dr-solution[Metro-DR solution for {rh-storage}], which provides two-way synchronous data replication between managed {VirtProductName} clusters installed on primary and secondary sites. This solution combines {rh-rhacm-first}, Red{nbsp}Hat Ceph Storage, and {rh-storage} components.
+{VirtProductName} supports the link:https://access.redhat.com/documentation/en-us/red_hat_openshift_data_foundation/4.17/html-single/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/index#metro-dr-solution[Metro-DR solution for {rh-storage}], which provides two-way synchronous data replication between managed {VirtProductName} clusters installed on primary and secondary sites.
 
-Use this solution during a site disaster to failover applications from the primary to the secondary site, and relocate the applications back to the primary site after restoring the disaster site.
+.Metro-DR differences
+* This synchronous solution is only available to metropolitan distance data centers with a network round-trip latency of 10 milliseconds or less. 
+* Multiple disk VMs are supported.
+* To prevent data corruption, you must ensure that storage is fenced during failover. 
++
+[TIP]
+====
+Fencing means isolating a node so that workloads do not run on it. 
+====
 
-This synchronous solution is only available to metropolitan distance data centers with a 10-millisecond latency or less.
-
-For more information about using the Metro-DR solution for {rh-storage} with {VirtProductName}, see link:https://access.redhat.com/articles/7053115[the Red{nbsp}Hat Knowledgebase] or {ibm-title}’s {rh-storage} Metro-DR documentation.
-
-[role="_additional-resources-dr"]
-.Additional resources
-* link:https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/index[Configuring OpenShift Data Foundation Disaster Recovery for OpenShift Workloads]
+For more information about using the Metro-DR solution for {rh-storage} with {VirtProductName}, see {ibm-title}'s {rh-storage} Metro-DR documentation.
diff --git a/modules/virt-regional-dr-odf.adoc b/modules/virt-regional-dr-odf.adoc
@@ -0,0 +1,16 @@
+// Module included in the following assemblies:
+//
+// * virt/backup_restore/virt-disaster-recovery.adoc
+
+:_mod-docs-content-type: CONCEPT
+[id="regional-dr-odf_{context}"]
+= Regional-DR for {rh-storage-first}
+
+{VirtProductName} supports the link:https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/html-single/configuring_openshift_data_foundation_disaster_recovery_for_openshift_workloads/index#rdr-solution[Regional-DR solution for {rh-storage}], which provides asynchronous data replication at regular intervals between managed {VirtProductName} clusters installed on primary and secondary sites.
+
+.Regional-DR differences
+* Regional-DR supports higher network latency between the primary and secondary sites.
+* Regional-DR uses RBD snapshots to replicate data asynchronously. Currently, your applications must be resilient to small variances between VM disks. You can prevent these variances by using single disk VMs.
+* Using the import method when selecting a population source for your VM disk is recommended. However, you can protect VMs that use cloned PVCs if you select a `VolumeReplicationClass` that enables image flattening. For more information, see the {rh-storage} documentation.
+
+For more information about using the Regional-DR solution for {rh-storage} with {VirtProductName}, see {ibm-title}'s {rh-storage} Regional-DR documentation.
diff --git a/modules/virt-vm-behavior-dr.adoc b/modules/virt-vm-behavior-dr.adoc
@@ -14,7 +14,7 @@ VMs typically act similarly to pod-based workloads during both relocate and fail
 
 Use relocate to move an application from the primary environment to the secondary environment when the primary environment is still accessible. During relocate, the VM is gracefully terminated, any unreplicated data is synchronized to the secondary environment, and the VM starts in the secondary environment.
 
-Becauase the terminates gracefully, there is no data loss in this scenario. Therefore, the VM operating system does not need to perform crash recovery.
+Because the VM terminates gracefully, there is no data loss. Therefore, the VM operating system will not perform crash recovery.
 
 [discrete]
 [id="dr-failover_{context}"]
diff --git a/virt/backup_restore/virt-disaster-recovery.adoc b/virt/backup_restore/virt-disaster-recovery.adoc
@@ -11,8 +11,18 @@ toc::[]
 include::modules/virt-about-dr-methods.adoc[leveloffset=+1]
 include::modules/virt-defining-apps-for-dr.adoc[leveloffset=+1]
 include::modules/virt-vm-behavior-dr.adoc[leveloffset=+1]
-include::modules/virt-metro-dr-odf.adoc[leveloffset=+1]
 
-[role="_additional-resources-dr"]
-.Additional resources
+[id="dr-solutions-rh-managed-clusters_{context}"]
+== Disaster recovery solutions for Red{nbsp}Hat managed clusters
+
+The following DR solutions combine {rh-rhacm-first}, Red{nbsp}Hat Ceph Storage, and {rh-storage} components. You can use them to failover applications from the primary to the secondary site, and to relocate the applications back to the primary site after you restore the disaster site.
+
+include::modules/virt-metro-dr-odf.adoc[leveloffset=+2]
+include::modules/virt-regional-dr-odf.adoc[leveloffset=+2]
+
+[role="_additional-resources"]
+[id="additional-resources_{context}"]
+== Additional resources
+* link:https://docs.redhat.com/en/documentation/red_hat_openshift_data_foundation/4.17/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]
