mirror of
https://github.com/openshift/openshift-docs.git
synced 2026-02-05 12:46:18 +01:00
CNV-51253: Clean up for DITA migration before updating docs
This commit is contained in:
Ashleigh Brennan
24
modules/best-practices-rhacm-discovered-vm.adoc
Normal file
24
modules/best-practices-rhacm-discovered-vm.adoc
Normal 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
17
modules/best-practices-rhacm-managed-vm.adoc
Normal 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.
|
||||
@@ -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.
|
||||
@@ -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]
|
||||
|
||||
Reference in New Issue
Block a user