Designing Legacy Virtual Machine Platforms in OpenShift

techhadoop OCP

Designing a platform to run legacy virtual machines (VMs) natively inside Red Hat OpenShift is accomplished using OpenShift Virtualization.

OpenShift Virtualization is built on the upstream KubeVirt open-source project. It allows you to run, manage, and orchestrate standard virtual machines (Windows, RHEL, Ubuntu) side-by-side with containerized workloads on the exact same Kubernetes platform, using the same compute nodes, storage structures, and network definitions.

1. Architectural Overview

OpenShift Virtualization does not run a separate hypervisor layer like VMware ESXi or Red Hat Virtualization (RHV) alongside the cluster. Instead, it converts Kubernetes pods into hypervisors.

When you launch a VM inside OpenShift:

  • The control plane spins up a standard Kubernetes pod running a specialized wrapper process called virt-launcher.
  • Inside that pod, a standard Linux KVM (Kernel-based Virtual Machine) and QEMU instance is initialized.
  • The legacy virtual machine boots inside that container container-namespace layer.

Because the VM is running inside a standard pod framework, it inherits all native Kubernetes benefits out-of-the-box: declarative YAML management, service routing, resource scheduling, network policies, and cluster monitoring.

2. Infrastructure Design Requirements

To build a production-grade OpenShift Virtualization platform, your underlying bare-metal hardware and operating system layers must be architected for high-performance virtualization.

A. Compute Infrastructure (Bare-Metal vs. Cloud)
  • Bare-Metal Nodes (Recommended): For maximum performance, worker nodes must be physical bare-metal servers. This allows OpenShift’s Red Hat Enterprise Linux CoreOS (RHCOS) layer to pass bare-metal Intel VT-x or AMD-V hardware virtualization extensions directly down to the VM pods.
  • Nested Virtualization: If you are running OpenShift inside a cloud provider (like AWS, Azure, or GCP), you must utilize specific instance types that support nested hardware virtualization (e.g., AWS metal instances or Azure Dv3/Ev3 series).
B. High-Performance Storage Grid

Virtual machines are highly sensitive to disk I/O latency. Your storage backend must support specific access modes to enable advanced lifecycle capabilities like Live Migration.

  • Storage Provider: Deploy Red Hat OpenShift Data Foundation (ODF / Powered by Ceph) as your primary storage engine.
  • Access Modes: You must use storage classes configured for ReadWriteMany (RWX) block storage. This allows two separate cluster nodes to attach to the exact same virtual disk file simultaneously during migration events.

3. Platform Deployment: Step-by-Step Installation

Step 1: Prepare the Node Configuration via MachineConfig

Before installing the operator, ensure your bare-metal workers are optimized to host heavy virtual machine page files. Use a MachineConfig to configure the kernel if you require dedicated host tuning configurations, though the virtualization operator handles most hardware validation automatically.

Step 2: Install the OpenShift Virtualization Operator
  1. From the OpenShift Web Console, navigate to Operators -> OperatorHub.
  2. Search for OpenShift Virtualization and click Install.
  3. Accept the default namespace (openshift-cnv) and click Install.
Step 3: Initialize the Hyperconverged Cluster Control Plane

Once the operator pod is active, trigger the creation of the virtualization control plane by instantiating the HyperConverged custom resource:

YAML

apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  # Instructs the system to auto-tune VM workloads based on your cluster profile
  workloadEvaluationFrequency: 1m

4. Declarative VM Blueprint Configuration

Once OpenShift Virtualization is initialized, you define a virtual machine exactly like any other Kubernetes resource using a VirtualMachine (VM) manifest file.

The blueprint below showcases a production-ready Windows/Linux legacy VM instance complete with explicit CPU topology mappings, persistent enterprise block storage, and dual network attachments:

YAML

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: legacy-billing-app
  namespace: finance-workloads
spec:
  running: true # Ensures the VM boots immediately upon creation
  template:
    metadata:
      labels:
        kubevirt.io/domain: legacy-billing-app
    spec:
      domain:
        cpu:
          cores: 4       # Explicit virtual CPU core allocation
          sockets: 1
          threads: 1
        resources:
          requests:
            memory: 8Gi  # Memory footprint boundaries
        devices:
          disks:
            - name: root-boot-disk
              disk:
                bus: virtio # Uses high-performance paravirtualized disk controllers
          interfaces:
            - name: default-pod-network
              masquerade: {} # Primary cluster network interface
            - name: corporate-vlan-nic
              bridge: {}     # Attaches secondary flat corporate network
      volumes:
        - name: root-boot-disk
          persistentVolumeClaim:
            claimName: billing-os-disk-pvc # Points to your enterprise ODF/Ceph storage disk
      networks:
        - name: default-pod-network
          pod: {}
        - name: corporate-vlan-nic
          multus:
            networkName: engineering-vlan-100 # Multi-NIC isolation via Multus CNI

5. Advanced Day-2 Platform Capabilities

Once your legacy VMs are running inside OpenShift, you gain access to cloud-native management paradigms that traditional hypervisors struggle to emulate easily.

A. Live Migration

If a physical bare-metal host node needs hardware maintenance or a kernel patch, OpenShift Virtualization can move running VMs to another physical node with zero downtime to the application.

Because the underlying disk volume is pinned to shared ReadWriteMany ODF/Ceph storage, OpenShift copies the live memory state over the cluster network fabric while the execution plane switches nodes dynamically. You can trigger this manually via the CLI:

Bash

oc virt migrate legacy-billing-app -n finance-workloads
B. Advanced Networking via Multus CNI

Legacy applications often have hardcoded IP schemas or require direct access to physical corporate VLANs. Standard Kubernetes pods are isolated behind an internal overlay network.

OpenShift solves this using the Multus CNI. Multus lets you attach multiple network interfaces directly to a single virtual machine pod. Interface 1 can connect to the standard internal cluster network to communicate with modern microservices, while Interface 2 bridges directly into a physical corporate VLAN (VLAN 100), retaining its static external IP infrastructure seamlessly.

C. Unified Operational Monitoring

Because the VM is running inside a pod wrapper, its telemetry automatically hooks into the platform’s native Prometheus and Thanos ecosystem. You can build unified Grafana dashboards that present CPU, memory, network packet drops, and disk IOPS metrics for container workloads and legacy virtual machines right alongside each other on a single pane of glass.

Leave a Reply