Veyron · Kairon · FluxVM

Real VMs.
No pods pretending.

The command center for virtual machines on Kubernetes. One console, one API, one CLI, with every VM running straight on KVM. No virt-launcher, no libvirt, no waiting.

veyron · /console
Veyron Mission Control: a live fleet map with hosts and VMs
0pods per VM
14xlighter idle control plane
7.4xfaster to SSH, 5 VMs
4hypervisors, one API

How it works

One click in the console.
Straight to KVM.

Four layers, each doing one job. Hover a layer to see what it does.

  1. VeyronConsole, API, CLIRust
  2. KubernetesDesired stateMachine CRDs
  3. KaironPlaces and runs Machines0 pods / VM
  4. FluxVMOne API, every hypervisorno libvirt
  5. QEMU / KVMCloud HypervisorFirecrackerFluxVM HV
  6. Linux KVMyour hardware

Speed

Same VM. Same node.
Watch who gets to SSH first.

A replay of the measured run, sped up 10x. Both sides boot the same Ubuntu 24.04 image on the same QEMU.

0.0 s measured
KaironMachine → kairon-node → FluxVM → KVM—
Waiting
KubeVirt v1.9.0VM → Pod → virt-launcher → libvirt → QEMU—
Waiting

Running SSH ready

Create to Running and create to SSH banner, p50. 2026-10-04, Xeon E-2336, k3s, 1 vCPU / 512 MiB guest. Method and raw JSON.

Why it’s faster

Same KVM at the bottom.
Half the stack in between.

KubeVirt 8 hops

  1. VirtualMachine
  2. virt-controller
  3. Pod scheduled and pulled
  4. virt-launcher pod, one per VM
  5. virt-handler
  6. libvirt / virtqemud
  7. QEMU
  8. KVM

Kairon 5 hops

  1. Machine
  2. kairon-controller
  3. kairon-node
  4. FluxVM REST
  5. KVM
virt-launcher podlibvirtdomain XMLcontainerDisk pull+ 4 hypervisors+ eBPF VM edge

Benchmark

Pod-per-VM is the bottleneck.
We removed it.

One node, one script driving both platforms, run back to back against KubeVirt v1.9.0.

Idle control plane memory

14x lighter

Kairon63 MiB
KubeVirt905 MiB

Idle control plane CPU

9x lighter

Kairon3.5m
KubeVirt30.2m

1 VM: create to SSH

2.9x faster

Kairon23.7 s
KubeVirt67.6 s

5 VMs: create to SSH, p50

7.4x faster

Kairon24.8 s
KubeVirt184.7 s

10 VMs at once: reached SSH within 600 s

10 of 10 vs 0 of 10

Kairon
10/10
KubeVirt
0/10

Being fair about it: per-VM memory is the same, because both run the same QEMU. The N=10 run was on a shared lab host, so read it as “the pod-per-VM path breaks first under pressure”, not as KubeVirt’s density ceiling. The win is the control plane and the start path, which is exactly the part you wait on. Full method and caveats.

The console

Feels like an Apple app.
Runs your whole fleet.

Frosted nav with mega-menus, a ⌘K palette for everything, a live fleet map and a details panel that slides in from any row.

Everything day 2 needs

Built in, not bolted on.

Current OS templates

Ubuntu 26.04, Debian 13, Fedora 44, EL10, Windows Server 2025 and 11. Pick, size, boot, or install from your own ISO.

Day-2 as buttons

Hotplug, bulk actions, node maintenance, guest patching, disk reclaim, self-healing.

Protect

Snapshots, clones, backups, DR failback, Ceph snapshots and S3 backups through Atlas.

GPU and Windows

GPU passthrough with a live-migration guard. A versioned image catalog with uploads, golden images, sysprep, domain join, RDP guardrails. No CDI.

Secure

Admin, write and read-only roles, OIDC SSO, and a SOC with SIEM export.

No database

State lives in Kubernetes. Unsupported actions return 501 with a reason, never a fake success.

Get started

Two commands to your first VM.

# build on the node, deploy to veyron-system
git clone https://github.com/zyvorai/veyron.git && cd veyron
./scripts/deploy-remote.sh <node-host> <ssh-user>

# then open https://<node-ip>:30151/console, or:
veyron create demo --template ubuntu-24.04 --cpus 2 --memory 4Gi

Ready to retire virt-launcher?