KubeVirt vs Harvester vs OpenNebula: Self-Hosted Virtualization Platforms 2026

Running virtual machines in your own data center or home lab has never been more flexible. While traditional hypervisors like Proxmox VE and VMware ESXi have dominated the space for years, a new generation of cloud-native virtualization platforms is emerging. These tools let you manage VMs alongside containers using the same Kubernetes-native APIs, or provide full cloud-platform orchestration across bare metal clusters.

In this guide, we compare three leading open-source self-hosted virtualization platforms: KubeVirt (Red Hat’s Kubernetes-native VM engine), Harvester (SUSE’s hyperconverged infrastructure built on KubeVirt), and OpenNebula (a mature cloud and edge computing platform). Whether you’re running a homelab, managing enterprise infrastructure, or building a multi-tenant cloud, this comparison will help you choose the right tool.

For organizations already invested in traditional hypervisor platforms, our Proxmox VE vs XCP-ng vs oVirt guide covers that side of the virtualization landscape in depth.

Why Self-Host Your Virtualization Platform?

Virtualization is the backbone of modern infrastructure. Self-hosting your virtualization platform gives you:

• Full data sovereignty — VMs, disks, and network configurations never leave your hardware
• No licensing costs — all three platforms are open source under the Apache 2.0 license
• No vendor lock-in — avoid per-CPU socket licensing and proprietary management tools
• Multi-tenant support — isolate workloads for different teams, projects, or customers
• Unified infrastructure — manage VMs and containers through a single control plane (KubeVirt and Harvester)
• Edge-ready deployments — lightweight enough to run at the edge while scaling to large data centers

If you’re building a Kubernetes cluster to host these workloads, comparing Kubernetes vs Docker Swarm vs Nomad will help you understand the orchestration layer options available.

KubeVirt: Kubernetes-Native Virtual Machines

KubeVirt is an open-source project originally created by Red Hat that extends Kubernetes with virtualization capabilities. It installs as a set of Custom Resource Definitions (CRDs) and controllers on an existing Kubernetes cluster, allowing you to define and manage VMs using the same kubectl commands and YAML manifests you already use for pods and deployments.

Key Stats

How It Works

KubeVirt runs a lightweight daemon (virt-launcher) as a pod for each VM. Inside that pod, a libvirt instance manages a QEMU/KVM process that runs the actual virtual machine. The VM’s lifecycle is managed through Kubernetes-native CRDs:

• VirtualMachine — defines a VM’s specification (CPU, memory, disks, networks)
• VirtualMachineInstance — represents a running VM (similar to Pod vs Deployment)
• VirtualMachineInstancePreset — reusable configuration templates
• VirtualMachineInstanceMigration — live migration between cluster nodes

Architecture

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

┌─────────────────────────────────────────────────┐
│                  Kubernetes Cluster              │
│                                                  │
│  ┌──────────┐  ┌──────────────┐  ┌────────────┐ │
│  │ KubeVirt │  │ Containerized│  │  Standard  │ │
│  │ Operator │  │ Data Volumes │  │   Pods     │ │
│  │ (virt-   │  │ (CDI)        │  │            │ │
│  │ operator)│  │              │  │            │ │
│  └──────────┘  └──────────────┘  └────────────┘ │
│        │                │                       │
│  ┌──────────────────────────────────────────┐   │
│  │          virt-launcher pods              │   │
│  │  ┌─────────────┐  ┌──────────────────┐  │   │
│  │  │ libvirt +   │  │  Container work- │  │   │
│  │  │ QEMU/KVM VM │  │  loads           │  │   │
│  │  └─────────────┘  └──────────────────┘  │   │
│  └──────────────────────────────────────────┘   │
└─────────────────────────────────────────────────┘

Installation

KubeVirt requires an existing Kubernetes cluster. Here’s how to install it:

1
2
3
4
5
6
7
8
9

# Install KubeVirt operator and CRDs
export KUBEVIRT_VERSION=$(curl -s https://api.github.com/repos/kubevirt/kubevirt/releases/latest | grep tag_name | head -1 | cut -d'"' -f4)

kubectl apply -f https://github.com/kubevirt/kubevirt/releases/download/${KUBEVIRT_VERSION}/kubevirt-operator.yaml

kubectl apply -f https://github.com/kubevirt/kubevirt/releases/download/${KUBEVIRT_VERSION}/kubevirt-cr.yaml

# Wait for KubeVirt to be deployed
kubectl -n kubevirt wait kv kubevirt --for condition=Available

Defining a Virtual Machine

Once installed, you define VMs as Kubernetes resources:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: ubuntu-vm
spec:
  running: true
  template:
    spec:
      domain:
        resources:
          requests:
            memory: 2Gi
        devices:
          disks:
            - name: rootdisk
              disk:
                bus: virtio
            - name: cloudinitdisk
              disk:
                bus: virtio
          interfaces:
            - name: default
              masquerade: {}
      networks:
        - name: default
          pod: {}
      volumes:
        - name: rootdisk
          containerDisk:
            image: kubevirt/ubuntu22.04-image-demo:latest
        - name: cloudinitdisk
          cloudInitNoCloud:
            userData: |-
              #cloud-config
              password: ubuntu
              chpasswd: { expire: False }

Start and access the VM:

1
2
3
4
5
6
7
8
9

# Start the VM
kubectl virt start ubuntu-vm

# Connect via serial console
kubectl virt console ubuntu-vm

# Check VM status
kubectl get vmi
kubectl virt list

Containerized Data Volumes (CDI)

KubeVirt’s CDI project handles importing, cloning, and uploading VM disk images:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: ubuntu-dv
spec:
  source:
    http:
      url: "https://cloud-images.ubuntu.com/releases/22.04/release/ubuntu-22.04-server-cloudimg-amd64.img"
  pvc:
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 20Gi
    storageClassName: longhorn

CDI supports importing from HTTP endpoints, uploading local files, cloning existing PVCs, and blank volumes for fresh installations.

Harvester: Hyperconverged Infrastructure on Kubernetes

Harvester is an open-source hyperconverged infrastructure (HCI) platform created by SUSE/Rancher. It bundles KubeVirt, Longhorn (distributed storage), and a Rancher-managed Kubernetes cluster into a single installable product. Rather than requiring a pre-existing Kubernetes cluster like KubeVirt does, Harvester installs directly on bare metal as a bootable appliance.

Key Stats

How It Works

Harvester sits between a traditional hypervisor and a full Kubernetes platform. It installs on bare metal (via ISO or PXE boot), automatically configures a multi-node Kubernetes cluster underneath, and then exposes both VM and container management through a web UI and Rancher integration.

Key components under the hood:

• KubeVirt — VM management and execution
• Longhorn — distributed block storage
• Multus CNI — multi-networking for VMs
• Harvester Network Controller — VLAN and management networking
• Rancher — cluster and VM lifecycle management UI

Installation

Harvester ships as a bootable ISO image. The installation process is similar to installing ESXi or Proxmox:

1
2
3
4
5
6
7
8
9

# Download the Harvester ISO
# From https://github.com/harvester/harvester/releases
# Write to USB or mount via BMC/iDRAC

# Installation steps (interactive console):
# 1. Select installation mode (Create new cluster / Join existing cluster)
# 2. Select network interface and IP configuration
# 3. Set admin password and management VIP
# 4. Confirm and install (reboots into Harvester)

For automated installs, Harvester supports iPXE and cloud-init configuration:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15

# harvester-config.yaml (cloud-init)
install:
  mode: create
  management_interface:
    interfaces:
      - name: eno1
    method: static
    ip: 192.168.1.100/24
    gateway: 192.168.1.1
    mtu: 1500
  dns_nameservers:
    - 8.8.8.8
  token: "my-cluster-token"
  vip: 192.168.1.200
  vip_hw_address: ""

Managing VMs in Harvester

Once installed, Harvester provides a web UI for VM management. VMs are defined using KubeVirt CRDs under the hood, but the UI abstracts the Kubernetes complexity:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

# VM definition via kubectl (same KubeVirt API)
apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
  name: web-server
  namespace: default
spec:
  running: true
  template:
    spec:
      domain:
        cpu:
          cores: 4
        resources:
          requests:
            memory: 8Gi
        devices:
          disks:
            - name: root-disk
              bootOrder: 1
              disk:
                bus: virtio
          interfaces:
            - name: vlan1
              bridge: {}
      networks:
        - name: vlan1
          multus:
            networkName: default/vlan1
      volumes:
        - name: root-disk
          persistentVolumeClaim:
            claimName: ubuntu-2204-disk

Rancher Integration

One of Harvester’s strongest features is its integration with Rancher:

1
2
3
4
5
6
7

# Import the Harvester cluster into Rancher
# From the Rancher UI: Clusters → Import Existing → Harvester
# This enables:
# - Unified VM + container management
# - Multi-cluster fleet deployment
# - Centralized monitoring with Prometheus/Grafana
# - RBAC synced across infrastructure and workloads

OpenNebula: Cloud and Edge Computing Platform

OpenNebula is one of the oldest open-source cloud management platforms, first released in 2008 by the Universidad Complutense de Madrid. It provides a full cloud orchestration stack similar to OpenStack but with a significantly simpler architecture and lower operational overhead.

Key Stats

How It Works

OpenNebula uses a front-end/back-end architecture. The Front-end runs the management daemon (oned), scheduler, and web interface (Sunstone). The Nodes run a lightweight hypervisor driver (KVM by default, though LXD and Docker are also supported) and a virtual network driver (Open vSwitch, Linux bridge, or VXLAN).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

┌────────────────────────────────────────────────┐
│               OpenNebula Front-end              │
│  ┌──────────┐  ┌───────────┐  ┌─────────────┐ │
│  │  oned    │  │ Scheduler │  │  Sunstone   │ │
│  │  daemon  │  │           │  │  (Web UI)   │ │
│  └──────────┘  └───────────┘  └─────────────┘ │
│         │              │                       │
│  ┌──────┴──────────────┴───────────────────┐   │
│  │          oneadmin CLI / API             │   │
│  └─────────────────────────────────────────┘   │
└────────────────────┬───────────────────────────┘
                     │
    ┌────────────────┼────────────────┐
    │                │                │
┌───┴────┐    ┌─────┴─────┐   ┌──────┴──────┐
│ Node 1 │    │  Node 2   │   │  Node 3     │
│ KVM+   │    │  KVM+     │   │  KVM+       │
│ one-   │    │  one-     │   │  one-       │
│ nodemgr│    │  nodemgr  │   │  nodemgr    │
└────────┘    └───────────┘   └─────────────┘

Installation

OpenNebula uses a package-based installation. Here’s a quick setup on Ubuntu:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

# Add OpenNebula repository
wget -q -O- https://downloads.opennebula.io/repo/repo.key | gpg --dearmor > /usr/share/keyrings/opennebula.gpg
echo "deb [signed-by=/usr/share/keyrings/opennebula.gpg] https://downloads.opennebula.io/repo/6.10/Ubuntu/22.04 stable opennebula" > /etc/apt/sources.list.d/opennebula.list

# Install frontend
apt update
apt install opennebula opennebula-gate opennebula-flow

# Initialize the frontend
one initialize

# Start services
systemctl enable --now opennebula sunstone opennebula-gate

# Install node packages on each compute host
apt install opennebula-node-kvm

For containerized deployments, OpenNebula can run via Docker:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

# docker-compose.yml for OpenNebula frontend
version: '3.8'
services:
  opennebula:
    image: opennebula/one:latest
    container_name: opennebula-frontend
    ports:
      - "9869:9869"    # Sunstone web UI
      - "2633:2633"    # XML-RPC API
    volumes:
      - /var/lib/one:/var/lib/one
      - /etc/one:/etc/one
    environment:
      - ONE_AUTH=oneadmin:your-password
      - DB_HOST=mariadb
    depends_on:
      - mariadb

  mariadb:
    image: mariadb:10.11
    environment:
      MYSQL_ROOT_PASSWORD: db-password
      MYSQL_DATABASE: opennebula
    volumes:
      - mariadb-data:/var/lib/mysql

volumes:
  mariadb-data:

Defining VM Templates and Virtual Networks

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49

# Create a VM template
cat << 'TEMPLATE' > vm-template.one
NAME   = "ubuntu-2204"
CPU    = "2"
MEMORY = "4096"

DISK = [
  IMAGE      = "Ubuntu-22.04-Cloud",
  IMAGE_UNAME = "oneadmin"
]

NIC = [
  NETWORK = "private-vnet",
  NETWORK_UNAME = "oneadmin"
]

GRAPHICS = [
  TYPE   = "VNC",
  LISTEN = "0.0.0.0",
  PORT   = "5900"
]

CONTEXT = [
  NETWORK = "YES",
  SSH_PUBLIC_KEY = "$USER[SSH_PUBLIC_KEY]"
]
TEMPLATE

# Register the template
onetemplate create vm-template.one

# Create a virtual network
cat << 'VNET' > vnet.one
NAME          = "private-vnet"
TYPE          = "BRIDGE"
BRIDGE        = "br0"
VN_MAD        = "bridge"
PHYDEV        = "eth0"
VLAN_ID       = "100"

AR = [
  TYPE  = "IP4",
  IP    = "10.0.1.100",
  SIZE  = "100"
]
VNET

# Register the network
onevnet create vnet.one

Deploying VMs

1
2
3
4
5
6
7
8

# Instantiate a VM from the template
onetemplate instantiate ubuntu-2204 --name web-server-01

# Check VM status
onevm list

# Connect to VM console
onevm show web-server-01

Feature Comparison

When to Choose Each Platform

Choose KubeVirt if:

• You already operate a Kubernetes cluster and want to add VM workloads without introducing a separate management stack
• Your team is comfortable with kubectl, YAML manifests, and GitOps workflows
• You want VMs and containers to share the same networking, storage, and RBAC systems
• You need fine-grained control over VM definitions through Kubernetes CRDs
• You’re running a Kubernetes distribution like K3s, k0s, or Talos Linux and want lightweight virtualization on top

Choose Harvester if:

• You want a complete HCI replacement for VMware vSphere or Proxmox with a modern web UI
• You prefer an install-it-and-forget-it bare metal deployment over manual Kubernetes setup
• You want Rancher integration for unified VM and container management across multiple clusters
• You need built-in distributed storage (Longhorn) without configuring Ceph manually
• Your team values an intuitive UI for non-Kubernetes-experts who still need VM management

Choose OpenNebula if:

• You want a full cloud-like IaaS experience similar to AWS or OpenStack but much simpler to operate
• You need multi-tenant cloud management with resource quotas, billing, and self-service portals
• You’re deploying at the edge and need a lightweight front-end with simple node agents
• You prefer a mature, battle-tested platform (since 2008) with established community support
• You need to manage hybrid environments mixing VMs, containers, and bare metal provisioning

Performance and Scalability

All three platforms use KVM as the underlying hypervisor, so raw VM performance is essentially identical. The differences lie in management overhead and scaling characteristics:

• KubeVirt scales with your Kubernetes cluster — add nodes and the control plane distributes VMs automatically. Each VM runs in its own pod with dedicated resource requests, making capacity planning straightforward. A single KubeVirt-managed cluster can handle hundreds of VMs across dozens of nodes.

• Harvester adds management overhead on top of KubeVirt due to the built-in Kubernetes cluster and Longhorn storage layer. A minimum of 3 nodes is recommended for production (the third node provides quorum for Longhorn’s distributed storage). For small deployments of 3-10 nodes, Harvester is operationally simpler than managing Kubernetes and KubeVirt separately.

• OpenNebula has the lightest management footprint. The front-end runs on a single VM or physical server and can manage hundreds of nodes. The scheduler is efficient and supports custom scheduling policies. OpenNebula has been deployed in production clusters exceeding 1,000 nodes.

FAQ

Can I migrate VMs between KubeVirt and Harvester?

Yes. Harvester uses KubeVirt under the hood, so VM definitions are largely compatible. You can export a VirtualMachine YAML manifest from Harvester and apply it to a standalone KubeVirt cluster, or import KubeVirt manifests into Harvester. The main difference is storage — Harvester uses Longhorn PVs, so you would need to migrate disk images separately or use a shared storage backend.

Does KubeVirt work with any Kubernetes distribution?

KubeVirt works with most major Kubernetes distributions including upstream Kubernetes, OpenShift, RKE2, k3s, and kind (for development). However, some distributions with custom CNI configurations or restricted security contexts may require additional setup. For homelab deployments, pairing KubeVirt with a lightweight distribution is a popular choice.

How does Harvester compare to Proxmox VE?

Harvester provides a more modern, Kubernetes-native approach compared to Proxmox. While Proxmox is a mature hypervisor management platform with LXC container support and ZFS storage, Harvester offers native container management alongside VMs, distributed storage with Longhorn, and Rancher integration. Proxmox excels at traditional virtualization; Harvester is better suited for teams wanting to converge VM and container infrastructure. See our detailed Proxmox VE vs XCP-ng vs oVirt comparison for the traditional hypervisor landscape.

Can OpenNebula run containers natively?

OpenNebula supports containers through its Docker and LXD drivers, but container orchestration is not its primary focus. For serious container workloads, you would want to run Kubernetes separately and use KubeVirt or Harvester for VMs. OpenNebula’s strength lies in VM and bare metal cloud management with strong multi-tenancy features.

Which platform supports GPU passthrough for VMs?

All three support GPU passthrough. KubeVirt uses Kubernetes device plugins to expose host GPUs to specific VMs. Harvester supports GPU passthrough through its VM configuration UI. OpenNebula supports GPU passthrough through its VM template definitions using PCI passthrough. You’ll need compatible hardware (Intel VT-d or AMD-Vi IOMMU support) and proper kernel configuration on the host.

What storage options does each platform support?

• KubeVirt supports any Kubernetes CSI storage: Longhorn, Rook-Ceph, NFS, local-path-provisioner, and more. It also supports Containerized Data Volumes (CDI) for importing disk images.
• Harvester ships with Longhorn for distributed block storage and supports external CSI drivers for additional storage backends.
• OpenNebula supports Ceph, NFS, LVM, qcow2 on shared storage, and local storage with live migration restrictions. It has built-in drivers for most enterprise storage systems.

Can I run these platforms on a single node for testing?

• KubeVirt works on single-node clusters using kind or minikube, though GPU passthrough and live migration require multiple nodes.
• Harvester officially supports single-node evaluation mode, but production requires at least 3 nodes.
• OpenNebula runs perfectly on a single machine where the front-end and compute node are the same server.