Chapter 1. Virtualization

• Installation policy

  The acm-dr-virt-install installation policy installs OpenShift APIs for Data Protection and configures the oadp.openshift.io.DataProtectionApplication resource on the cluster where this policy is placed.

  For the hub cluster, the policy verifies that OpenShift APIs for Data Protection is installed in the open-cluster-management-backup namespace, and that the DataProtectionApplication resource exists and has the required configuration. The policy does not attempt to install OpenShift APIs for Data Protection, or create the DataProtectionApplication resource on the hub cluster.

  When you enable the cluster-backup option on the MultiClusterHub resource, the backup chart installs the OpenShift APIs for Data Protection. When you enable the cluster-backup-option, you create the DataProtectionApplication on the hub cluster.

  Table 1.1. Installation policy templates

  Template	Description
  check-config-file	Verifies that the ConfigMap that is defined by the acm-virt-config label set on the ManagedCluster resource exists on the hub cluster, in the open-cluster-management-backup namespace.
  check-oadp-channel	Verifies if there is an OpenShift APIs for Data Protection version installed on the cluster, and that it matches the version installed by the policy.
  check-dpa-config	Verifies that the DataProtectionApplication resource exists, has the expected configuration, and has a status of Reconciled. Verifies that the BackupStorageLocation exists and is in the Available status phase.
  install-oadp-copy-config	Creates the namespace where OpenShift APIs for Data Protection gets installed, if this namespace is not found. Copies the OpenShift APIs for Data Protection secret and installs OpenShift APIs for Data Protection, but only for managed clusters. Creates the DataProtectionApplication resource as defined by the acm-virt-config label, but only for the managed clusters. The user must manually create the OpenShift APIs for Data Protection and DataProtectionApplication on the hub cluster.

• Backup policy

  The acm-dr-virt-backup backup policy backs up the kubevirt.io.VirtualMachine resources that has the cluster.open-cluster-management.io/backup-vm: schedule_cron_name label.

  Table 1.2. Backup policy templates

  Template	Description
  check-cron-schedule-valid	Shows a violation error if there is any cron schedule name used by a virtual machine cluster.open-cluster-management.io/backup-vm label which is not found in the ConfigMap for the cron schedules. The name of the ConfigMap for the cron schedules is defined by the schedule_hub_config_name property and is available within the open-cluster-management-backup namespace.
  check-backup-status-completed	If the schedule is not paused, it verifies that the status is Enabled. Finds the latest backup generated by this schedule and verifies that the status is Completed. If any DataUpload has been created for this backup, the status is Completed. Shows a violation if any of these conditions are not True.
  create-virt-backup	Creates Velero schedules for all virtual machine resources with a cluster.open-cluster-management.io/backup-vm label. Creates one schedule for each cron job schedule found with the virtual machines label. Backs up the virtual machine sharing the same cron job schedule within the same backup. Creates the Velero schedule resource only if the acm-dr-virt-install policy is compliant.

• Restore policy

  The acm-dr-virt-restore restore policy restores the kubevirt.io.VirtualMachine resources by UID. The policy creates Velero restore resources on clusters using the information from the ConfigMap that is identified by the restore_hub_config_name property from the acm-dr-virt-config ConfigMap.

  Table 1.3. Restore policy templates

  Template	Description
  check-velero-restore-status	Verifies that the restore resource with the name defined by the clusterID_restoreName property exists and has a status of Completed.
  create-velero-restore	If the clusterID_restoreName property value is not empty, and the clusterID matches this cluster UID, it creates a Velero restore resources using the properties defined with the ConfigMap that is identified by the restore_hub_config_name. Creates the Velero restore resource only if the acm-dr-virt-install policy is compliant.

Next steps

• See Virtualization policy ConfigMap overview for ConfigMap properties, schedule configuration, and restore ConfigMap examples.

• Example of a acm-dr-virt-schedule-cron ConfigMap

  Use the acm-dr-virt-schedule-cron ConfigMap to define the valid cron job schedules to use when you are scheduling a virtual machine backup. The acm-dr-virt-schedule-cron ConfigMap is created by the hub cluster backup component in the open-cluster-management-backup namespace and includes the following YAML:

  apiVersion: v1
  kind: ConfigMap
      metadata:
          name: acm-dr-virt-schedule-cron
          namespace: open-cluster-management-backup
      data:
          hourly: "0 */1 * * *"
          every_2_hours: "0 */2 * * *"
          every_3_hours: "0 */3 * * *"
          every_4_hours: "0 */4 * * *"
          every_5_hours: "0 */5 * * *"
          every_6_hours: "0 */6 * * *"
          twice_a_day: "0 */12 * * *"
          daily_8am: "0 8 * * *"
          every_sunday: "0 0 * * 0"

• Example VirtualMachine with a daily backup schedule

  You can use any of the schedules created by the acm-dr-virt-schedule-cron ConfigMap to set the backup schedule for a kubevirt.io.VirtualMachine. For example, if you want to backup a virtual machine every day at 8am, add the following label to the virtual machine resource:

  apiVersion: kubevirt.io/v1
  kind: VirtualMachine
  metadata:
    name: vm-name
    labels:
      cluster.open-cluster-management.io/backup-vm: daily_8am

  Since this acm-dr-virt-schedule-cron ConfigMap is created and managed by the hub cluster backup component, you cannot change any of the existing cron properties or delete them. The properties are recreated when the content is reconciled. You can only add new properties to the existing ones. For example, if you want to create a cron job to run every Saturday, add the following label to the existing acm-dr-virt-schedule-cron properties: every_sunday: "0 0 * * SAT".

• Example of complete restore operation in the acm-dr-virt-restore-config ConfigMap

  Use the acm-dr-virt-restore-config ConfigMap to define the restore operations to be implemented by the acm-dr-virt-restore policy. Use the hub cluster backup component in the open-cluster-management-backup namespace to create the ConfigMap. For an example of a complete restore operation, see the following YAML sample:

  kind: ConfigMap
  apiVersion: v1
  metadata:
   name: acm-dr-virt-restore-config
   namespace: open-cluster-management-backup
  data:
   2a054d24-3235-4249-9c81-f58ebc6110c7_backupName: acm-rho-virt-schedule-every-10-hours-20250120230438
   2a054d24-3235-4249-9c81-f58ebc6110c7_restoreName: restore-20250120230438
   2a054d24-3235-4249-9c81-f58ebc6110c7_vmsUID: 2a054d24-3235-4249-9c81-f58ebc6110c7
   2a054d24-3235-4249-9c81-f58ebc6110c7_namespaceMapping: backup-ns-1=restore-ns-1{{ backup-ns-2=restore-ns-2}}

  • 2a054d24-3235-4249-9c81-f58ebc6110c7 is the cluster ID where the restore operation is complete. acm-rho-virt-schedule-every-10-hours-20250120230438 is the name of the backup that is used for the restore operation example.
  • restore-20250120230438 is the name of the Restore resource that is created as a result of this restore operation.
  • 2a054d24-3235-4249-9c81-f58ebc6110c7 is the UID of the virtual machine backed up with the acm-rho-virt-schedule-every-10-hours-20250120230438 backup to be restored.
  • namespaceMapping is an optional property and is used to restore resources in a different namespace than the initial resource. Any source namespaces not included in the map is restored into namespaces of the same name. backup-ns-1=restore-ns-1 backup-ns-2=restore-ns-2 is a space separated list of namespace mapping. In this sample, backup resources created within the backup-ns-1 namespace are restored within the restore-ns-1 namespace. The restore-ns-1 is created on the restore cluster if it does not exist. Similarly, resources created within the backup-ns-2 are restored within the restore-ns-2 namespace.

• Virtualization policies for your restore operations scenarios

  • If you set the clusterID_restoreName property from the acm-dr-virt-restore-config ConfigMap to an empty value, then the restore resource created by the acm-dr-virt-restore policy on the cluster with clusterID gets deleted.
  • If you set the clusterID_restoreName property from the acm-dr-virt-restore-config ConfigMap to a non-empty value, then the acm-dr-virt-restore policy creates a Velero Restore resource . The name of the Velero restore resource matches the clusterID_restoreName value. If the restore resource with this name is deleted from the restore cluster, the acm-dr-virt-restore policy recreates the resource, which results in the restore operation running again.

• Important considerations for your restore operations scenarios

  • Do not delete the restore resource if you do not want to run the restore again.
  • Remove the value for the clusterID_restoreName parameter on the acm-dr-virt-restore-config ConfigMap when the restore operation gets verified to start. Doing this prevents you from having to rerun the restore operation if the acm-dr-virt-restore policy is disabled and enabled again. When you disable the acm-dr-virt-restore policy, all resources created by it on the restore cluster get cleaned up and recreated when you enable the policy again.

Additional resources

• Defining policies with ConfigMap resources