Insights · OpenShift
OpenShift Virtualization (CNV): Running VMs Alongside Containers
Overview
OpenShift virtualization — delivered by the Container-native Virtualization (CNV) operator built on KubeVirt — lets platform teams run full virtual machines on the same nodes, storage, and networking fabric as container workloads. For enterprises with VMware estates, Windows servers, or appliances that cannot containerize overnight, CNV is a consolidation play: one control plane, one RBAC model, one observability stack.
CNV is not a free vSphere replacement on day one. You need adequate compute headroom for virt-launcher pods, storage classes that support ReadWriteMany or block modes for VM disks, and network attachments via Multus when VMs require VLANs isolated from pod overlay networks. Planning OpenShift virtualization means mapping VM classes, migration windows, and operational runbooks before flipping the first import.
This article covers CNV architecture, storage and networking decisions, migration tooling from VMware (Migration Toolkit for Virtualization, MTV), and how platform engineering teams govern VMs with the same quota, backup, and disaster-recovery expectations as stateful pods.
Need help implementing this?
Talk to engineers who deploy these patterns on OpenShift in production—not generic advisory decks.
CNV Architecture and Operator Dependencies
The CNV operator installs KubeVirt controllers, virt-handler DaemonSets on nodes, virt-api, and virt-controller deployments. VMs are defined with VirtualMachine, VirtualMachineInstance, and DataVolume custom resources. The hypervisor runs inside virt-launcher pods scheduled on nodes labeled for bare-metal or nested virtualization capability — verify CPU flags and KVM module availability before promising VM density.
CNV depends on OpenShift scheduling, storage, and networking primitives. HostPath and local storage work for labs; production demands CSI-backed persistent volumes with adequate IOPS for database VMs. Snapshots and clones use VolumeSnapshotClass resources aligned with your storage vendor. Install CNV from OperatorHub on a stable OCP version listed in the CNV compatibility matrix — mismatched pairings are unsupported.
Node maintenance uses the same drain semantics as pods: evict VMIs gracefully, respect PodDisruptionBudget equivalents, and use node maintenance modes provided by KubeVirt during firmware upgrades. Failing to quiesce guest OS disks before hard kill produces filesystem corruption identical to pulling a physical power cable.
CNV version skew relative to OCP blocks upgrades — verify the combined matrix before scheduling cluster bumps. HyperConvergedCluster CR status should report healthy before large migration waves. Keep a rollback plan for CNV operator upgrades independent of platform CVO timeline.
Storage and Networking for OpenShift Virtualization Workloads
DataVolumes import ISO, registry, or HTTP sources and populate PVCs consumed by VM disks. Use storage profiles to bind default storage classes and volume modes per namespace. For Windows VMs, pre-create golden images with virtio drivers and sysprep templates — booting from unoptimized images wastes support hours on disk driver BSODs.
Multus CNI attaches secondary interfaces to VMIs when workloads need direct L2 access — common in lift-and-shift networking models that mirror VLAN segmentation from VMware port groups. OVN-Kubernetes remains the primary pod network; plan IP address management carefully when bridging VM and container traffic on shared segments.
Services and Routes expose container apps; VMs typically use NodePort, LoadBalancer Services, or external bridges for RDP, SSH, and legacy protocols. Document which exposure pattern each migrated VM class uses — security teams will ask. Ingress controllers do not terminate RDP; do not conflate the two.
MAC address spoofing and bridge CNI plugins require elevated CNI permissions — review Multus NetworkAttachmentDefinition specs with network architects. IPAM pools for secondary networks should integrate with corporate IPAM to avoid duplicate assignments that break Active Directory or DHCP scopes.
Live Migration, HA, and Capacity Planning
KubeVirt live migration moves running VMIs between nodes when storage is shared and CPU features are compatible. Enable dedicated migration networks to prevent memory copy traffic from saturating production NICs. Set eviction strategies on VirtualMachine objects — LiveMigrate vs Shutoff — based on SLA tiers.
High availability for VMs differs from pod replica HA: typically one VMI per VM with rapid restart on another node after failure, not horizontal scale-out. Pair CNV with monitoring alerts on virt-launcher restarts, memory ballooning, and storage latency. Oversubscribing CPU on virt nodes causes steal time and angry database admins.
Capacity planning should model peak vCPU and RAM per node including pod workloads on the same cluster — mixed virt/container clusters are operationally convenient but resource-contentious. Use dedicated infra and worker pools via machine sets and node labels when SLAs demand isolation.
Run cluster capacity reports weekly during migration programs — MTV imports can fill nodes faster than autoscaler adds capacity if machine sets max out. Pre-provision virt-capable nodes with correct labels before cutover weekend to avoid pending VMIs.
Migrating from VMware with MTV and OpenShift Virtualization
Migration Toolkit for Virtualization (MTV) — installed via operator — maps VMware VMs to OpenShift Virtualization resources using provider credentials, network maps, and storage maps. Warm migrations cut over with minimal downtime when VMware tools and guest agents cooperate; cold migrations suit maintenance windows. Validate OS licensing, especially Windows Server activation, before bulk import.
Not every VM belongs on CNV long term. Platform engineering teams should tag candidates: retire, replatform to containers, or sustain as VM on OCP. Stateless Linux apps often land faster as Deployments than as perpetually migrated VMIs. Use MTV as a bridge, not an excuse to avoid application rationalization.
Post-migration, apply the same backup, patch, and vulnerability scanning rigor as containers. Guest OS patching remains the application owner's job; CNV only supplies the hypervisor layer. Integrate VM backups with OADP (OpenShift API for Data Protection) or vendor solutions that snapshot PVCs consistently.
MTV migration plans should include rollback to VMware for critical tiers until soak period ends. Maintain parallel DNS or load-balancer cutover runbooks — big-bang DNS flips without rehearsal cause multi-hour outages when ARP caches or TTLs misbehave.
Governance and Day-2 Operations for CNV
Apply ResourceQuotas to virt namespaces — a single 32 vCPU VM can exhaust a project quota meant for microservices. RBAC separates VM admins from namespace developers; use OpenShift groups mapped from corporate IdP. Audit who can create DataVolumes that import arbitrary external images.
Observability: Prometheus metrics from virt components and node exporters on hypervisor nodes feed the same Grafana stacks as container monitoring. Log guest console output via virt-launcher when troubleshooting boot failures. These OpenShift virtualization practices align CNV with enterprise platform standards rather than treating VMs as a shadow IT island.
Multi-cluster strategies — hub-spoke GitOps, disaster recovery, geo replication — extend to VM workloads when storage replication supports it. Plan cluster boundaries before migrating hundreds of VMIs; retroactive multi-cluster management is costly. Our multi-cluster management article picks up where single-cluster CNV success leaves off.
Windows licensing and SQL Server BYOL rules differ on virtualized infrastructure — involve licensing specialists before migrating revenue-critical databases. Linux VMs may need subscription-manager registration on RHEL guests even when running on OCP virt nodes.
Performance tuning for database VMIs includes virtio-scsi queues, dedicated CPU pinning, and hugepages where supported — default virt-launcher resources suit dev VMs, not production OLTP.
Monitoring and Troubleshooting OpenShift Virtualization
KubeVirt metrics expose VMI phase, memory usage, and migration progress — dashboard them beside node CPU steal time. Virt-launcher OOMKills indicate undersized VM requests.
Must-gather for CNV includes virt-launcher logs and events — train support staff on differences from pod-only debugging. Console VNC access is break-glass; prefer audited SSH or RDP paths.
Capacity alerts should fire before virt nodes hit 90% allocatable memory — live migration needs headroom on destination nodes. OpenShift virtualization at scale is proactive ops, not reactive ticket queues.
Run regular virt capacity workshops with VMware and container owners — mixed estates need shared forecasting when both VM and pod growth compete for the same machine sets.
Security and Compliance for OpenShift Virtualization Workloads
VMIs run with SCC policies like containers — audit privileged virt-launcher exceptions separately from application pods.
Scan golden images for CVEs before import — a compromised Windows ISO becomes every migrated server's foundation.
Network segmentation via Multus should mirror VMware VLAN policies auditors already approved — explain mapping in migration docs.
OpenShift virtualization under compliance review requires guest OS hardening evidence, not only hypervisor controls — CNV does not patch Windows for you.
Explore further
Related services
- ServiceOpenShift Migration Services
Related technology
- TechnologyOpenShift
Related reading
Need help with OpenShift?
Talk to engineers who implement these patterns in production—not generic advisory decks.