openshift/openshift-docs
1
0
Fork 0
mirror of https://github.com/openshift/openshift-docs.git synced 2026-02-05 21:46:22 +01:00
Code Issues Releases Activity

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

Browse Source
This commit is contained in:
Ashleigh Brennan
2025-08-29 09:59:21 -05:00
committed by openshift-cherrypick-robot
parent c630755517
commit d02db9bbfa
4 changed files with 52 additions and 62 deletions
Download Patch File Download Diff File Expand all files Collapse all files

24
modules/best-practices-rhacm-discovered-vm.adoc Normal file
View File

@@ -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.

17
modules/best-practices-rhacm-managed-vm.adoc Normal file
View File

@@ -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.

60
modules/virt-defining-apps-for-dr.adoc
View File

@@ -1,60 +0,0 @@
// Module included in the following assemblies:
//
// * virt/backup_restore/virt-disaster-recovery.adoc
:_mod-docs-content-type: CONCEPT
[id="virt-defining-apps-for-dr_{context}"]
= Defining applications for disaster recovery
Define applications for disaster recovery by using VMs that {rh-rhacm-first} manages or discovers.
[id="best-practices-{rh-rhacm}-managed-vm_{context}"]
== Best practices when defining an {rh-rhacm}-managed VM
An {rh-rhacm}-managed application that includes a VM must be created by using a GitOps workflow and by creating an {rh-rhacm} application or `ApplicationSet`.
There are several actions you can take to improve your experience and chance of success when defining an {rh-rhacm}-managed VM.
[discrete]
[id="use-a-pvc-and-populator_{context}"]
=== 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.
[discrete]
[id="use-import-method_{context}"]
=== 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.
[discrete]
[id="use-pull-node_{context}"]
=== 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.
[id="best-practices-{rh-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.
There are several actions you can take to improve your experience and chance of success when defining an {rh-rhacm}-discovered VM.
[discrete]
[id="protect-the-vm_{context}"]
=== Protect 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.
====
[discrete]
[id="working-vm-contains_{context}"]
=== Include 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.
[discrete]
[id="part-of-larger-app_{context}"]
=== Include the VM as part of a larger logical application
This includes other pod-based workloads and VMs.

13
virt/backup_restore/virt-disaster-recovery.adoc
View File

@@ -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/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]
* 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]