ACM as the Fleet Control Plane for OpenShift VMs
Why RHACM 2.16 is the fleet hub for OpenShift Virtualization across clusters: inventory, Observability, policy-driven backup, live migration, and VM RBAC.
Personal site note: views expressed here are my own and do not necessarily represent Red Hat or any other organization.
Give a platform team a second OpenShift Virtualization cluster and the OpenShift console stops being a control plane. It is still the right place to build a VM, attach a localnet NIC, or debug a single virt-launcher pod. It is the wrong place to answer what is running across the estate, who can stop it, and how we move it for maintenance. Cluster-local UI does not scale. The objects do.
Each VM is still a Kubernetes VirtualMachine. That is why Red Hat Advanced Cluster Management for Kubernetes (RHACM) 2.16 has a job here. The hub already inventories and governs managed clusters. RHACM Virtualization extends that same hub to the VM workload class: search and actions, Observability, policy-driven backup, cross-cluster live migration, and fine-grained RBAC so those actions are not cluster-admin for everyone.
This post is a solution-architect field guide for that conversation. It is not an install lab. For product procedure, start with ACM 2.16 Virtualization. Cluster-local day-2 improvements in OpenShift Virtualization 4.22 still matter; they do not replace a fleet hub.
Inventory and actions from the hub
Day-2 virtualization is mostly inventory plus control. RHACM Search can list and filter VirtualMachine resources across every managed cluster that runs OpenShift Virtualization. The Fleet Virtualization console is the operational view of that inventory: one place to see what is running instead of a bookmark folder of cluster consoles.
From that console you can start, stop, restart, pause, unpause, and snapshot VMs. Those are the documented hub actions. They are enough to change the conversation from “SSH to the right cluster and find the YAML” to “the hub operates the VM fleet.” Live migration between clusters is a separate, GA capability—not another Search button to invent in a pitch.
That split matches how customers already think about containers. Nobody wants a unique operational model for “the VM clusters.” If the platform is OpenShift, the VM is a Kubernetes workload, and the hub that already knows the clusters should know the VMs.
OpenShift Virtualization 4.20.1 or later is the floor for RHACM Virtualization features. This site’s latest stable OpenShift line is 4.22, which satisfies that requirement. Confirm pairing against the ACM 2.16 support matrix for the hub and managed clusters you actually run.
Observability and right-sizing
Inventory without signals is a CMDB with a nicer theme. If the Observability service is installed on the hub, the Virtual Machine page can launch Grafana dashboards for VM metrics. That is the fleet capacity conversation: utilization, pressure, and whether a cluster is the right place to land the next workload.
RHACM 2.16 makes RightSizingRecommendation generally available. After Observability is enabled, namespace right-sizing and virtualization right-sizing are on by default. Use that as a talking point, not a Grafana workshop: the hub can recommend whether VMs are over- or under-provisioned instead of leaving every site to build its own spreadsheet.
Keep the boundary honest. Right-sizing is an Observability feature, not a substitute for storage performance testing or for the hardening work that decides who may attach devices and which networks a VM may join.
Policy-driven backup is not DR
Backup for OpenShift Virtualization VMs in RHACM is policy plus OpenShift APIs for Data Protection (OADP). Enable the backup component, place the virtualization policies, and RHACM will install and configure OADP on managed clusters according to a hub ConfigMap. The operator model is GitOps-shaped even when you never open OpenShift GitOps: labels select clusters and VMs; policies create Velero schedules; compliance tells you whether the last backup completed.
Supported storage for those VM backups is CSI or CSI with DataMover. File system backup and volume-snapshot backup are not supported for this path. Say that in the design review before someone assumes “we have OADP, so every Velero feature applies to VMs.”
Selection is a label on the VM, not a hidden controller default:
1
2
3
4
5
6
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
name: vm-name
labels:
cluster.open-cluster-management.io/backup-vm: daily_8am
The schedule name must exist in the hub cron ConfigMap. The managed cluster gets the policies when you set acm-virt-config on the ManagedCluster resource. Restore is a separate policy driven by a restore ConfigMap, including optional namespace mapping. That is backup and restore. It is not Metro or Regional DR, and it is not a replacement for application-level recovery objectives you already negotiated.
Cross-cluster live migration
Cross-cluster live migration is generally available in ACM 2.16. The point is operational: drain a cluster for upgrade, rebalance load, or move a VM to a namespace that matches a new tenancy boundary—without treating the VM as glued to the cluster where it was born.
The enablement model is hub-centric. Turn on the cnv-mtv-integrations component on MultiClusterHub. Label source and target clusters with acm/cnv-operator-install: "true". Migration Toolkit for Virtualization lands on the hub; OpenShift Virtualization is installed on those labeled managed clusters. That last sentence is an operational implication, not a footnote: do not apply the label to a cluster you did not intend to turn into a virtualization target.
Live migration is not backup. Backup is a point-in-time copy you can restore later, including onto another cluster. Live migration is a move with the VM still running. Mixing those words in a customer slide is how DR requirements get “satisfied” by a feature that does not survive a storage-domain loss.
Hosted control planes change where the API server runs; they do not remove the need for a fleet hub. See hosted vs virtualized control planes. RHACM still manages the hosted clusters and the VMs on the compute clusters underneath them.
Fine-grained RBAC for VM admins
A hub that can stop or migrate every VM in the estate is a privilege concentrator. RHACM 2.16 makes fine-grained RBAC for virtualization generally available so VM operators are not cluster-admins.
Permissions are declared on the hub with MulticlusterRoleAssignment and propagated to managed clusters. The Fleet Virtualization roles to name in the room:
| Role | What it is for |
|---|---|
acm-vm-fleet:view | Minimum access to the Fleet Virtualization console |
acm-vm-fleet:admin | Fleet console plus cluster-to-cluster live migration |
acm-vm-extended:view / acm-vm-extended:admin | Read or administer extended Kubernetes resources on source and target clusters |
acm-vm-cluster-migration:view | Migration readiness checks on the target cluster |
Details and assignment flows live in ACM secure clusters documentation. The solutions architect point is simpler than the CRD: write VM administration as a fleet role, not as cluster-admin copied to every virt namespace. That is the same least-privilege instinct as RHACS for virt-launcher workloads— a complementary control plane, not a substitute.
ACM for Virtualization
ACM for Virtualization is the same RHACM operational surface, entitled only for OpenShift Virtualization Engine clusters and the VMs on them. If the estate is VMs on OVE and nothing else, that SKU matches the buy. Mixed container and VM fleets stay on RHACM for Kubernetes. Do not let the SKU conversation replace the architecture conversation: either way, the hub is how you stop managing each virt cluster as a pet.
The solutions architect takeaway
Lead with outcomes:
- The OpenShift console does not scale to a VM fleet — RHACM 2.16 is the hub for inventory, actions, Observability, backup policy, and live migration.
- Right-sizing is GA with Observability — use it for capacity talk; do not treat it as a storage or hardening substitute.
- Backup is CSI/OADP policy, not DR — label clusters and VMs; do not claim filesystem or volume-snapshot backup on this path.
- Live migration is GA and is a move — maintenance and load, not a recovery objective; the install label has blast radius.
- RBAC is part of the feature —
acm-vm-fleet:adminis notcluster-admin.
If you already run RHACM for cluster lifecycle or GitOps ZTP, the next proof point is small: show one VirtualMachine from a spoke in Search, agree who may stop and migrate it, and decide whether Observability and the backup policies belong on the same hub. How those policies get onto the hub is a separate split—GitOps should manage ACM, not the cluster. Edge form factor still comes first—see OpenShift edge architectures— then make the fleet boring on purpose, including the VMs.
For a PoC hub, start with Advanced Cluster Management (OpenShift PoC) and OpenShift Virtualization (OpenShift PoC).
Related posts
- GitOps Should Manage ACM, Not the Cluster
- AI Agents for MTV: vSphere to OpenShift Virtualization
- What’s New in OpenShift Virtualization 4.22
- RHACS for OpenShift Virtualization Workloads
Want help applying this in your environment? Reach out to your Red Hat account team—or evaluate the pattern on a non-prod hub and two spoke clusters first.