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.
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.
- VeyronConsole, API, CLIRust
- KubernetesDesired stateMachine CRDs
- KaironPlaces and runs Machines0 pods / VM
- FluxVMOne API, every hypervisorno libvirt
- QEMU / KVMCloud HypervisorFirecrackerFluxVM HV
- 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.
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
- VirtualMachine
- virt-controller
- Pod scheduled and pulled
- virt-launcher pod, one per VM
- virt-handler
- libvirt / virtqemud
- QEMU
- KVM
Kairon 5 hops
- Machine
- kairon-controller
- kairon-node
- FluxVM REST
- KVM
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
Idle control plane CPU
9x lighter
1 VM: create to SSH
2.9x faster
5 VMs: create to SSH, p50
7.4x faster
10 VMs at once: reached SSH within 600 s
10 of 10 vs 0 of 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