diff --git a/modules/best-practices-rhacm-discovered-vm.adoc b/modules/best-practices-rhacm-discovered-vm.adoc new file mode 100644 index 000000000000..54d485a21621 --- /dev/null +++ b/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. diff --git a/modules/best-practices-rhacm-managed-vm.adoc b/modules/best-practices-rhacm-managed-vm.adoc new file mode 100644 index 000000000000..b53a13747bfe --- /dev/null +++ b/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. diff --git a/modules/virt-defining-apps-for-dr.adoc b/modules/virt-defining-apps-for-dr.adoc deleted file mode 100644 index 65dd7449e9e8..000000000000 --- a/modules/virt-defining-apps-for-dr.adoc +++ /dev/null @@ -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. \ No newline at end of file diff --git a/virt/backup_restore/virt-disaster-recovery.adoc b/virt/backup_restore/virt-disaster-recovery.adoc index c70faa8a2411..7b35529b5c2c 100644 --- a/virt/backup_restore/virt-disaster-recovery.adoc +++ b/virt/backup_restore/virt-disaster-recovery.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] \ No newline at end of file +* 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]