Platform
Platform architecture
Kyvernon consists of the Kyvernon VMM hypervisor on every host, a replicated control plane, storage and network services, and a compatibility layer for the vSphere APIs. All functions are available through one native API.
Key facts
| Item | Detail |
|---|---|
| Hypervisor | Kyvernon VMM, written in Rust, runs guests on the hardware virtualization of the host processor through the host kernel |
| Firmware and security devices | UEFI with Secure Boot, BIOS, virtual TPM 2.0 |
| Console | Graphical console in the browser, opened with a WebSocket ticket that works once |
| Backup | Persistent change tracking per disk, NBD export of a consistent snapshot |
| Live migration | Between hosts over TLS, in the cluster release Planned |
| vSphere API | 196 of 972 vim25 methods plus the REST, datastore and OVF surfaces, see compatibility |
Components
| Component | Function |
|---|---|
| Kyvernon VMM | Runs virtual machines on the hardware virtualization of the host processor |
| Host agent | Manages Kyvernon VMM, storage and networking on one host |
| Control plane | Inventory, scheduling, high availability, identity, tasks and audit log |
| Storage services | Storage pools, virtual disk formats, snapshots, backup export |
| Network services | Virtual switches, VLAN and overlay segments, routing, firewall |
| Compatibility layer | vSphere SOAP, REST, datastore and OVF endpoints |
Kyvernon VMM
Kyvernon VMM is the hypervisor of the platform. It is written in Rust and runs guests directly on Intel VT-x and AMD-V through the host kernel.
- Virtual CPU scheduling, guest memory and interrupt delivery
- Device models: virtio block, network, SCSI, console, balloon, random number generator, vsock and shared file system
- UEFI firmware with Secure Boot, BIOS firmware for guests installed in BIOS mode, virtual TPM 2.0
- Snapshots and dirty page tracking for change tracking and live migration
- PCI passthrough
- Guest agent channel
Unsafe code is restricted to two isolated modules for kernel calls and memory mapping. All device models are memory-safe Rust.
Guest operating systems at first release: current Linux distributions and Windows Server with virtio drivers. The migration tooling installs virtio drivers in imported guests.
Control plane
The control plane runs as a group of controllers per management domain. Inventory and configuration are replicated with Raft. No external database is required.
- Inventory of datacenters, clusters, hosts, virtual machines, storage pools, networks, folders, tags and permissions
- Task engine with progress, results and events for every operation
- Scheduler for initial placement, load balancing, affinity rules and maintenance evacuation, with the reason for every decision recorded
- Identity with OIDC and SAML federation, roles and privileges
- Append-only audit log, exportable as JSON, CEF or syslog over TLS
- Task, event and audit history is stored on disk in the controller's store file, with only an index in memory, so the controller's memory does not grow with the length of the history
Host software
Each host runs one agent process. Hosts boot from a minimal, signed, immutable image with A/B partitions. An upgrade installs to the inactive partition; a failed boot returns to the previous image.
Storage
| Item | Detail |
|---|---|
| Storage pools | Local directory, ZFS, LVM thin, NFS, iSCSI, Fibre Channel with multipath |
| Distributed storage | Ceph RBD, planned for a later release |
| Disk format | qcow2 by default, raw optional |
| Change tracking | Persistent dirty bitmaps per disk |
| Backup export | NBD export of a consistent snapshot with changed-block information |
Networking
| Item | Detail |
|---|---|
| Virtual switching | Open vSwitch on every host, OVN across the cluster |
| Segments | VLAN and Geneve overlay |
| Routing | Distributed routers with NAT and gateway firewall |
| Firewall | Stateful rules per virtual NIC, based on tags and groups |
| vSphere objects | Standard switches, distributed switches and port groups |
The distributed firewall checks traffic at the network adapter of each virtual machine, on the host where the machine runs, in both directions. Rules use groups, tags and named services, are evaluated in four ordered categories, and apply to provider and tenant scopes. Existing virtual machines move to enforcement in steps: a monitor mode first, then enforcement with a confirmation timer. See how the distributed firewall works.
Product tour
Development build with sample data.
Interfaces
| Interface | Protocol |
|---|---|
| Native API | gRPC and REST, OpenAPI 3.1, versioned under /v1 |
| Web UI | Browser, WCAG 2.2 AA |
| CLI | kyvernon command-line client |
| vSphere endpoints | SOAP /sdk, REST /api and /rest, /folder, /nfc |
| Metrics and traces | Prometheus /metrics, OpenTelemetry |
| Events | Webhooks with HMAC signatures and CloudEvents, syslog, CEF |
Measured figures
| Measurement | Result | Method |
|---|---|---|
| Network between two virtual machines, 1 TCP stream | 16 Gbit/s | iperf3 between two guests on one host over virtio-net, median of 3 runs |
| Network between two virtual machines, 4 TCP streams | 25.6 Gbit/s | Same setup, 4 parallel streams |
| Power-on to SSH login | 18 to 21 s | Ubuntu 24.04 cloud image with cloud-init, 2 vCPU, 2 GiB, from the power-on request until SSH answers, 3 runs |
| Linked clone | 0.19 s | Median of 40 and of 80 clones made through the API |
| Snapshot including memory | 1.35 s | Guest with 2 GiB, guest paused for 1.30 s |
| Sequential disk, write and read | 1,438 and 1,579 MiB/s | fio, 1 MiB blocks, queue depth 4, direct I/O, 4 GiB data disk on the host SSD with the host page cache in the path, median of 3 runs |
| Virtual machines running on one host | 88 | 8 scenario guests plus 80 linked clones started in batches of 10; no limit of the platform was reached, the memory assigned to the measurement was the bound |
| API response time | 20 to 40 ms | Median of 30 requests each for govc and native API calls against the controller, 7 virtual machines in the inventory |
Lab host: Dell R630, 2 x Intel Xeon E5-2630 v4, 121 GiB memory, Ubuntu guests, Kyvernon VMM, measured on 5 November 2026 with a development build. The figures are measurements on one machine, not specifications.
Design targets
| Item | Target |
|---|---|
| Hosts per cluster | 128 |
| Hosts per management domain | 2,500 |
Published configuration maximums replace these targets once they are measured on reference hardware.