Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 24 additions & 0 deletions modules/best-practices-rhacm-discovered-vm.adoc
Original file line number Diff line number Diff line change
@@ -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 changes: 17 additions & 0 deletions modules/best-practices-rhacm-managed-vm.adoc
Original file line number Diff line number Diff line change
@@ -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 changes: 0 additions & 60 deletions modules/virt-defining-apps-for-dr.adoc

This file was deleted.

13 changes: 11 additions & 2 deletions virt/backup_restore/virt-disaster-recovery.adoc
Original file line number Diff line number Diff line change
Expand Up @@ -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}"]
Expand All @@ -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]