Virtualization on Backend Engineering Strategy Tools

OpenStack

Thu, 14 May 2026 00:00:00 +0000

OpenStack is an open-source IaaS platform — it turns a pool of bare-metal servers into a self-service cloud: virtual machines, block storage, networking, and object storage, all driven by API.

https://www.openstack.org/

Scale and fit

There is a rough spectrum of virtualization tools, and picking the wrong tier is a common mistake:

Proxmox / VMware / Hyper-V — the right choice when you want to run virtual machines. SMB, homelab, or a small ops team managing infrastructure directly. Reasonable setup cost, manageable operational overhead, one or a few admins in control. Think of it as a VMware replacement.

OpenStack — the right choice when you are building a cloud, not just running VMs. Multi-tenant infrastructure where teams self-service their own compute, networking, and storage via API. The operational complexity is real and significant; it pays off when the cloud-like abstraction is the actual product, or when the scale justifies the overhead.

The rule of thumb: if the question is “how do I replace VMware?”, the answer is Proxmox. If the question is “how do I build a private cloud platform?”, the answer might be OpenStack.

Core Components

Service	Code Name	What it does
Compute	Nova	Schedules and manages VM lifecycle
Networking	Neutron	Virtual networks, routers, floating IPs, security groups
Block Storage	Cinder	Persistent volumes attached to VMs
Image Service	Glance	Stores and serves OS images
Identity	Keystone	Auth, service catalog, RBAC
Dashboard	Horizon	Web UI (optional)
Object Storage	Swift	S3-like object storage (optional)
Bare Metal	Ironic	Provisions physical machines instead of VMs

You do not need all of them. A minimal useful deployment is Nova + Neutron + Cinder + Glance + Keystone.

OpenStack on Kubernetes

OpenStack services are just applications — and they can run as Kubernetes workloads. Two projects make this practical:

OpenStack-Helm — official Helm charts for deploying OpenStack services on an existing Kubernetes cluster. Each service (Nova, Neutron, Cinder, etc.) becomes a Helm release. Upgrades follow standard rolling deployment patterns.

Atmosphere (by VEXXHOST) — a higher-level operator built on top of OpenStack-Helm. Adds Ansible automation, health checks, and a more opinionated deployment model. Targets production use.

The practical implication: you can run a Talos cluster and deploy OpenStack on top of it — OpenStack as a tenant of Kubernetes rather than a separate platform. This inverts the usual relationship (where Kubernetes runs on top of OpenStack) and is an interesting architectural option for homelab and small private cloud deployments.

Fairbanks (Dutch hosting company specialising in sovereign private clouds) does exactly this in production. Their talk OpenStack on Talos Linux is the clearest real-world example of the pattern.

Deployment Options

Kolla-Ansible
https://docs.openstack.org/kolla-ansible/latest/
Containerised OpenStack deployed via Ansible. Production-grade, well-maintained. The practical choice for homelab and small-scale production deployments. Each service runs in its own container.

DevStack
https://docs.openstack.org/devstack/latest/
All-in-one development install. Not for production or anything you want to survive a reboot. Good for learning the API surface.

Canonical OpenStack (Juju / Sunbeam)
https://ubuntu.com/openstack
Ubuntu-opinionated deployment. Sunbeam is a newer minimal footprint option. Good if you’re already in the Ubuntu/Juju ecosystem.

Concepts Worth Understanding

Flavors — VM sizing templates (vCPU, RAM, disk). You define these; instances pick from them.

Security Groups — stateful firewall rules applied per-port. Default-deny inbound.

Floating IPs — externally routable IPs that can be associated/disassociated from instances dynamically.

Availability Zones — logical groupings of compute nodes. Useful for fault isolation even at small scale.

Hypervisors — Nova supports KVM (default), QEMU, VMware, and others. KVM on Linux is the standard.

Relevance to the Lab

The LLM training experiment plans to use OpenStack as the IaaS layer over the blade nodes in ASGARD — Nova for compute scheduling, Neutron for cluster networking, Cinder for shared model/dataset storage backed by Ceph.

Proxmox Cluster in the homelab

Thu, 14 May 2026 00:00:00 +0000

Getting a three-node Proxmox VE cluster running in the homelab.

The goal is a shared virtualization platform for running VMs and LXC containers across the rack. Also, a good excuse to kick the tires on Proxmox itself so, naturally, let’s needlessly complicate things with some self-imposed constraints:

run it clustered
don’t use any hardware already earmarked for other projects

Hardware

I am going try and use three IBM rack servers from the inventory.

Asset ID	Hostname	Model	Form Factor	RAM	CPU
SYS-001	FREJA	IBM System x3550 M1 (7978)	1U	24GB	single
SYS-002	TYR	IBM System x3650 M1 (7979)	2U	64GB	dual
SYS-003	TOR	IBM System x3650 M1 (7979)	2U	64GB	dual

Three nodes satisfies Corosync quorum without needing a qdevice — losing one node still leaves a majority.

Installation

In progress.

Cluster formation

In progress.

Proxmox VE

Thu, 14 May 2026 00:00:00 +0000

Proxmox VE (Virtual Environment) is an open-source Type 1 hypervisor built on Debian. It runs KVM for full virtual machines and LXC for lightweight containers, managed through a web UI or API. The subscription model is optional — the community edition is fully functional without a paid license; the subscription gives access to the enterprise update repository and support.

Comparison

Platform	License	VMs (KVM)	Containers	Clustering	Web UI
Proxmox VE	Open-source (optional sub)	Yes	Yes (LXC)	Yes	Yes
VMware ESXi	Commercial	Yes	No	Yes (vCenter)	Yes
Standalone KVM	Open-source	Yes	No	Manual	No
oVirt	Open-source	Yes	No	Yes	Yes

Proxmox is the practical choice when you want VMware-style management without the licensing cost, or when you want to run both VMs and containers on the same node.

Core concepts

Node — a physical host running Proxmox VE. Managed independently or as part of a cluster.

Cluster — multiple nodes joined together. Share a unified management view and allow live migration of VMs between nodes. Uses Corosync for distributed consensus.

Quorum — clusters require a majority of nodes to be reachable to avoid split-brain. Minimum useful cluster size is 3 nodes (loss of one node still leaves a majority). Two-node clusters need a quorum device (qdevice) to function safely.

VM — full virtual machine backed by QEMU/KVM. Hardware-level isolation. Arbitrary OS.

Container (CT) — LXC container. Shares the host kernel; lower overhead than a VM. Linux-only. Useful for services where you want process-level isolation without a full OS.

Storage pool — where disks and images live. Supported backends: local directory, LVM, LVM-thin, ZFS, NFS, CIFS, and Ceph (via rbd). ZFS and Ceph are the most capable options for a cluster — ZFS for local redundancy, Ceph for shared storage across nodes.

Proxmox VE documentation
Proxmox community forum
Corosync documentation
Ceph — distributed storage backend for Proxmox clusters
OpenStack — the next tier up the scale spectrum
Proxmox cluster in the homelab

KubeVirt

Mon, 01 Jan 2024 00:00:00 +0000

See Virtualization — KVM and KubeVirt for full coverage of both KVM and KubeVirt.

Virtualization — KVM and KubeVirt

Mon, 01 Jan 2024 00:00:00 +0000

KVM is the Linux kernel’s native hypervisor. KubeVirt extends Kubernetes to run virtual machines using KVM under the hood. They are the same virtualization layer at different levels of abstraction — KVM on bare metal, KubeVirt in a Kubernetes cluster.

KVM

Kernel-based Virtual Machine. KVM turns the Linux kernel into a hypervisor using hardware virtualization extensions (Intel VT-x, AMD-V). Virtual machines run as regular Linux processes backed by QEMU for device emulation. Managed via libvirt and its CLI tools (virsh, virt-install) or the virt-manager GUI.

# Create a VM from an ISO
virt-install \
 --name ubuntu-vm \
 --ram 4096 \
 --vcpus 2 \
 --disk path=/var/lib/libvirt/images/ubuntu.qcow2,size=40 \
 --cdrom /tmp/ubuntu.iso \
 --os-variant ubuntu22.04

# List running VMs
virsh list

# Start/stop
virsh start ubuntu-vm
virsh shutdown ubuntu-vm

# Connect to console
virsh console ubuntu-vm

KVM gives near-native performance for CPU-bound workloads. Network and disk I/O use virtio drivers for efficient paravirtualised I/O. Live migration moves a running VM between hosts without downtime if shared storage is available.

KubeVirt

KubeVirt adds VirtualMachine and VirtualMachineInstance CRDs to Kubernetes. VMs are defined as Kubernetes resources, scheduled by the Kubernetes scheduler, and managed alongside containers. Under the hood, each VM runs as a pod containing a QEMU-KVM process.

apiVersion: kubevirt.io/v1
kind: VirtualMachine
metadata:
 name: ubuntu-vm
spec:
 running: true
 template:
 spec:
 domain:
 devices:
 disks:
 - name: rootdisk
 disk:
 bus: virtio
 resources:
 requests:
 memory: 4Gi
 cpu: "2"
 volumes:
 - name: rootdisk
 containerDisk:
 image: kubevirt/fedora-cloud-container-disk-demo

The virtctl CLI complements kubectl for VM-specific operations:

virtctl start ubuntu-vm
virtctl stop ubuntu-vm
virtctl console ubuntu-vm # serial console
virtctl ssh ubuntu-vm # SSH via the Kubernetes API
virtctl migrate ubuntu-vm # live migrate to another node

CDI — Containerized Data Importer

KubeVirt is typically paired with CDI, which imports VM disk images from URLs, container registries, or PVCs into DataVolume resources that VMs can boot from. CDI handles the data flow; the VM definition just references the DataVolume.

Why VMs in Kubernetes

Some workloads can’t be containerised — legacy applications expecting a full OS, Windows workloads, software with kernel module requirements. KubeVirt lets those workloads live in the same cluster as containers, managed with the same tooling, subject to the same scheduling and networking policies.

Virtualization on Backend Engineering Strategy Tools

OpenStack

Scale and fit

Core Components

OpenStack on Kubernetes

Deployment Options

Concepts Worth Understanding

Relevance to the Lab

Proxmox Cluster in the homelab

Hardware

Installation

Cluster formation

Proxmox VE

Comparison

Core concepts

Related

KubeVirt

Virtualization — KVM and KubeVirt

KVM

KubeVirt

CDI — Containerized Data Importer

Why VMs in Kubernetes

Resources