OpenShift Virtualization: Complete Guide to Container and VM Integration

Containers are the trend, but not everything can be stuffed into containers.

That Windows Server that's been running for ten years, old software with licenses tied to MAC addresses, black box applications where no one knows where the source code is... these things can't be containerized in the short term, but you still want unified management.

OpenShift Virtualization's solution is: Make VMs first-class citizens in Kubernetes too.

This article will provide a complete introduction to OpenShift Virtualization, from technical principles to actual deployment, helping you evaluate this hybrid architecture solution. If you're not familiar with OpenShift yet, we recommend first reading the OpenShift Complete Guide.

---

Introduction to OpenShift Virtualization

What is OpenShift Virtualization?

OpenShift Virtualization is an add-on feature for OpenShift that allows you to run both containers and virtual machines on the same platform.

Traditional architecture:

┌─────────────────┐  ┌─────────────────┐
│  Container      │  │  Virtualization │
│  Platform       │  │  Platform       │
│  (Kubernetes)   │  │  (VMware/KVM)   │
│  ┌───┐ ┌───┐   │  │  ┌───┐ ┌───┐   │
│  │Pod│ │Pod│   │  │  │VM │ │VM │   │
└──┴───┴─┴───┴───┘  └──┴───┴─┴───┴───┘
     Two systems, two management interfaces

OpenShift Virtualization architecture:

┌─────────────────────────────────────┐
│         OpenShift Unified Platform   │
│  ┌───┐ ┌───┐ ┌─────┐ ┌─────┐       │
│  │Pod│ │Pod│ │VM   │ │VM   │       │
│  │   │ │   │ │(Pod)│ │(Pod)│       │
└──┴───┴─┴───┴─┴─────┴─┴─────┴───────┘
          One system, one management interface

Technical Foundation: KubeVirt

OpenShift Virtualization is based on the open-source project KubeVirt:

• CNCF incubating project
• Enables Kubernetes to manage VMs
• VMs run inside special Pods (virt-launcher)
• Uses Kubernetes API to operate VM lifecycle

KubeVirt's design philosophy: A VM is just a special type of Pod.

Scheduling, networking, and storage all use Kubernetes native mechanisms—just what's running inside isn't a container, but a virtual machine.

Why "Containerize VMs"?

Scenario One: Hybrid Workloads

A company has:

• Newly developed microservices (containers)
• Legacy monolithic applications (VMs)
• Wants unified management and monitoring

Scenario Two: VMware Migration

VMware licensing costs keep increasing, want to migrate to open source solutions, but:

• Too many applications, impossible to containerize everything
• Need a transition solution

Scenario Three: Development and Testing Environments

Developers need to:

• Test containerized applications
• Also test legacy versions on VMs
• Don't want to maintain two environments

---

Core Features

VM Lifecycle Management

OpenShift Virtualization supports complete VM lifecycle operations:

Operation	Description	CLI Command
Create	Create VM from template or YAML	oc apply -f vm.yaml
Start	Start a stopped VM	virtctl start my-vm
Stop	Graceful shutdown	virtctl stop my-vm
Restart	Reboot	virtctl restart my-vm
Pause	Pause execution	virtctl pause my-vm
Delete	Delete VM	oc delete vm my-vm

VirtualMachine YAML Example:

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: my-vm
spec:
  running: true
  template:
    spec:
      domain:
        cpu:
          cores: 2
        memory:
          guest: 4Gi
        devices:
          disks:
          - name: rootdisk
            disk:
              bus: virtio
          interfaces:
          - name: default
            masquerade: {}
      networks:
      - name: default
        pod: {}
      volumes:
      - name: rootdisk
        dataVolume:
          name: my-vm-disk

Live Migration

Live Migration can move a VM from one Node to another without downtime:

# Trigger Live Migration
virtctl migrate my-vm

# Check migration status
oc get vmim

Live Migration uses:

• Node maintenance without service interruption
• Resource balancing
• Hardware upgrades

Live Migration Requirements:

• Shared storage (accessible by all Nodes)
• Sufficient network bandwidth
• Enough resources on target Node

Snapshots and Backups

VM snapshots let you save state at a point in time:

apiVersion: snapshot.kubevirt.io/v1alpha1
kind: VirtualMachineSnapshot
metadata:
  name: my-vm-snapshot
spec:
  source:
    apiGroup: kubevirt.io
    kind: VirtualMachine
    name: my-vm

Restore snapshot:

apiVersion: snapshot.kubevirt.io/v1alpha1
kind: VirtualMachineRestore
metadata:
  name: my-vm-restore
spec:
  target:
    apiGroup: kubevirt.io
    kind: VirtualMachine
    name: my-vm
  virtualMachineSnapshotName: my-vm-snapshot

Template Management

OpenShift Virtualization includes multiple built-in VM templates:

• RHEL 7/8/9
• CentOS Stream
• Fedora
• Windows Server (requires your own license)

You can also create custom templates with pre-configured CPU, memory, network settings.

---

Architecture Design

Component Architecture

OpenShift Virtualization main components:

Component	Function
virt-controller	Manages VM lifecycle
virt-handler	Agent on each Node
virt-launcher	Pod containing the VM
virt-api	Provides API endpoint
CDI (Containerized Data Importer)	Imports VM disk images

Architecture diagram:

┌─────────────────────────────────────────────┐
│                 Control Plane                │
│  ┌───────────────┐  ┌───────────────┐       │
│  │ virt-api      │  │ virt-controller│       │
│  └───────────────┘  └───────────────┘       │
├─────────────────────────────────────────────┤
│                  Worker Node                 │
│  ┌───────────────┐  ┌───────────────────┐   │
│  │ virt-handler  │  │ virt-launcher (Pod)│   │
│  │               │  │  ┌─────────────┐  │   │
│  │               │  │  │    VM       │  │   │
│  └───────────────┘  └──┴─────────────┴──┘   │
└─────────────────────────────────────────────┘

Network Design

OpenShift Virtualization supports multiple network modes:

Mode	Description	Use Case
Pod Network (masquerade)	VM uses Pod network	General purpose, simple
Bridge	Direct connection to physical network	Needs fixed IP
SR-IOV	Direct access to physical NIC	High performance needs

Pod Network (default):

VM uses same network as Pods, accesses external through NAT:

spec:
  template:
    spec:
      networks:
      - name: default
        pod: {}
      domain:
        devices:
          interfaces:
          - name: default
            masquerade: {}

Bridge Network:

VM directly bridges to physical network, can have independent IP:

spec:
  template:
    spec:
      networks:
      - name: bridge-net
        multus:
          networkName: br-external
      domain:
        devices:
          interfaces:
          - name: bridge-net
            bridge: {}

Storage Design

VM disks are managed with DataVolume, with PVC underneath:

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: my-vm-disk
spec:
  source:
    http:
      url: "https://download.example.com/rhel9.qcow2"
  pvc:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 50Gi
    storageClassName: ocs-storagecluster-ceph-rbd

Storage Type Selection:

Access Mode	Description	Supports Live Migration
ReadWriteOnce (RWO)	Single node read/write	No
ReadWriteMany (RWX)	Multi-node read/write	Yes

Live Migration requires RWX storage (like ODF, NFS).

---

Installation and Configuration

Prerequisites

Hardware Requirements:

• CPU supporting virtualization (Intel VT-x or AMD-V)
• Worker Node minimum 16GB RAM
• SSD storage recommended

Software Requirements:

• OpenShift 4.12 or newer
• Bare Metal or environment supporting nested virtualization

Verify Virtualization Support:

# Check on Worker Node
cat /proc/cpuinfo | grep -E "(vmx|svm)"

Install Operator

Via Web Console:

1. Go to Operators → OperatorHub
2. Search for OpenShift Virtualization
3. Click Install
4. Select openshift-cnv namespace
5. Wait for installation to complete

Via CLI:

# Create Namespace
apiVersion: v1
kind: Namespace
metadata:
  name: openshift-cnv
---
# Create OperatorGroup
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: kubevirt-hyperconverged-group
  namespace: openshift-cnv
spec:
  targetNamespaces:
  - openshift-cnv
---
# Subscribe to Operator
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: hco-operatorhub
  namespace: openshift-cnv
spec:
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  name: kubevirt-hyperconverged
  channel: stable

Create HyperConverged

After installing the Operator, create a HyperConverged resource to enable functionality:

apiVersion: hco.kubevirt.io/v1beta1
kind: HyperConverged
metadata:
  name: kubevirt-hyperconverged
  namespace: openshift-cnv
spec:
  infra: {}
  workloads: {}

Wait for all Pods to be ready:

oc get pods -n openshift-cnv

---

Creating Virtual Machines

Create from Template

Web Console provides the simplest method:

1. Go to Virtualization → Catalog
2. Select an OS template (e.g., RHEL 9)
3. Configure name, CPU, memory
4. Select storage type
5. Click Create VirtualMachine

Install from ISO

Upload ISO and create VM:

# Create DataVolume to store ISO
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: windows-iso
spec:
  source:
    upload: {}
  pvc:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 6Gi
---
# Create blank disk
apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: windows-disk
spec:
  source:
    blank: {}
  pvc:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 100Gi

Upload ISO:

virtctl image-upload dv windows-iso \
  --image-path=/path/to/windows.iso \
  --uploadproxy-url=https://cdi-uploadproxy-openshift-cnv.apps.cluster.example.com

Import Existing VMs

Import from QCOW2 or VMDK:

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: imported-disk
spec:
  source:
    http:
      url: "https://example.com/vm-disk.qcow2"
  pvc:
    accessModes:
    - ReadWriteOnce
    resources:
      requests:
        storage: 50Gi

---

VMware Migration

For enterprises wanting to leave VMware, OpenShift Virtualization provides MTV (Migration Toolkit for Virtualization).

MTV Tool Introduction

MTV can automate:

• Discovery of VMware vSphere environment
• Selection of VMs to migrate
• Disk format conversion (VMDK → QCOW2)
• Migration to OpenShift Virtualization

Install MTV

Install Migration Toolkit for Virtualization from OperatorHub:

apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
  name: mtv-operator
  namespace: openshift-mtv
spec:
  source: redhat-operators
  sourceNamespace: openshift-marketplace
  name: mtv-operator
  channel: release-v2.6

Migration Planning

Step 1: Create Provider

Connect to VMware vCenter:

apiVersion: forklift.konveyor.io/v1beta1
kind: Provider
metadata:
  name: vmware-source
  namespace: openshift-mtv
spec:
  type: vsphere
  url: https://vcenter.example.com/sdk
  secret:
    name: vmware-credentials

Step 2: Create NetworkMap

Map VMware networks to OpenShift networks:

apiVersion: forklift.konveyor.io/v1beta1
kind: NetworkMap
metadata:
  name: network-mapping
  namespace: openshift-mtv
spec:
  map:
  - source:
      id: network-123
    destination:
      type: pod
  provider:
    source:
      name: vmware-source

Step 3: Create StorageMap

Map storage:

apiVersion: forklift.konveyor.io/v1beta1
kind: StorageMap
metadata:
  name: storage-mapping
  namespace: openshift-mtv
spec:
  map:
  - source:
      id: datastore-456
    destination:
      storageClass: ocs-storagecluster-ceph-rbd
  provider:
    source:
      name: vmware-source

Step 4: Create Plan and Execute

apiVersion: forklift.konveyor.io/v1beta1
kind: Plan
metadata:
  name: migration-plan
  namespace: openshift-mtv
spec:
  provider:
    source:
      name: vmware-source
    destination:
      name: host
  map:
    network:
      name: network-mapping
    storage:
      name: storage-mapping
  vms:
  - id: vm-789
    name: web-server-01

VMware migration is a major project requiring thorough planning. Book an architecture consultation and let us help you develop a migration strategy.

---

Best Practices

Resource Planning

CPU:

• Don't over-commit CPU
• Production environment recommended CPU reservation ratio < 150%

Memory:

• VM memory is actual usage, not like containers
• Planning should calculate total memory of all VMs

Storage:

• Use SSD or high-performance storage
• Live Migration requires RWX storage
• Reserve enough space for snapshots

Security Configuration

Network Isolation:

• Use Network Policy to isolate VM traffic
• Place sensitive VMs in separate namespaces

Access Control:

• Use RBAC to limit who can manage VMs
• Sensitive operations (like deletion) require additional permissions

# Limit to only start/stop VMs, not delete
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: vm-operator
rules:
- apiGroups: ["kubevirt.io"]
  resources: ["virtualmachines"]
  verbs: ["get", "list", "watch", "update", "patch"]
- apiGroups: ["kubevirt.io"]
  resources: ["virtualmachineinstances"]
  verbs: ["get", "list", "watch"]

Monitoring and Logging

Monitoring:

• VM metrics automatically integrate with OpenShift Monitoring
• Can use Prometheus to query VM CPU, memory, network

Logging:

• VM internal logs require Guest Agent installation
• Guest Agent also provides additional metrics

---

FAQ

Q1: How does OpenShift Virtualization performance compare to VMware?

Performance depends on underlying hardware and configuration. KubeVirt uses QEMU/KVM, which is Linux native virtualization technology with mature and stable performance. For general workloads, performance differences are minimal. High-performance needs (like databases) can be optimized with SR-IOV networking and dedicated storage.

Q2: Can all VMs be migrated over?

Most Linux and Windows VMs can be migrated. But some situations need attention: (1) VMs using VMware-specific features (like vSphere HA) need to redesign high availability mechanisms; (2) Software with licenses tied to hardware may need re-licensing; (3) Some old OS versions may need driver adjustments.

Q3: Does Live Migration interrupt service?

Normally no. Live Migration copies memory first, then switches execution location at the end—switch time is usually just milliseconds. But if VM memory write is very frequent, may need multiple iteration copies, extending migration time.

Q4: Can I mix container and VM applications?

Yes. This is the core value of OpenShift Virtualization. Containers and VMs can: (1) Be exposed using the same Service; (2) Call each other through Services; (3) Share monitoring and logging. For example, frontend runs containers, backend database runs VMs.

Q5: How is licensing calculated?

OpenShift Virtualization is included in OpenShift Container Platform subscription, no additional fee required. But note: (1) OS licenses inside VMs (like Windows) need separate handling; (2) Software licenses for migrated VMs may need verification; (3) Hardware resource costs should be factored in.

---

Want to Unify VM and Container Management?

OpenShift Virtualization is the answer, but architecture design must be done right. From storage planning to network design, every decision affects subsequent migration costs and operations efficiency.

Book an architecture consultation and let us evaluate your hybrid workload requirements.

---

Reference Resources

• OpenShift Complete Guide
• OpenShift Architecture Deep Dive
• OpenShift Installation Tutorial
• OpenShift Pricing Analysis
• OpenShift Advanced Feature Configuration
• OpenShift Learning Path
• Red Hat OpenShift Virtualization Documentation