VICTOR PRODUCT / ARCHITECTURE
Victor combines Type 1 KVM virtualization with infrastructure management, placement, availability, protection and automation. Deploy dedicated Victor hosts or connect supported infrastructure, then operate your workloads through one platform.
01 / SYSTEM EXPLORER
Select a component to see its job, its boundaries and what it depends on.
victord serves the API, the embedded web console and the engine connections. Several replicas can share one database; one holds the task-leader lock and runs tasks, scheduled jobs, DRS and HA.
Victor keeps its own records in PostgreSQL. The engines keep theirs. The Helm chart can use an external database, a single bundled PostgreSQL, or a CloudNativePG cluster (operator installed first) with synchronous replication.
KVM provides hardware-assisted virtualization in the host Linux kernel. Victor’s KVM runtime uses Incus for VM and host operations, including local or shared storage and virtual networks.
Victor can also manage virtual machines as Kubernetes resources through KubeVirt, presenting pools, nodes, namespaces and VMs in the same inventory.
An offline-installable bootc image with Incus 7.0 LTS, PostgreSQL 16, victord, Prometheus and Ceph packages. Updates replace the whole image and can roll back.
Victor’s management services, PostgreSQL and the metrics store are packaged as a single VM that manages the supported cluster it runs on. Administration › Appliance manages the appliance.
The console, victorctl, the Terraform provider, the Ansible collection and the MCP server all call the same OpenAPI-described API. The vSphere bridge translates selected vSphere calls into it.
02 / THE SHAPE OF A SITE
A Victor site combines its management services with the clusters and hosts it manages. Enterprise federation brings independent sites into one administrative view.
KVM runs in the host Linux kernel and provides Type 1, bare-metal virtualization. Victor supplies the management and operational capabilities around that foundation. See hypervisor types explained for the underlying classification.
| Layer | Components | Owns |
|---|---|---|
| Clients | Web console (Classic and Victor views), victorctl, Terraform, Ansible, MCP, vSphere bridge | Nothing of their own; every call is permission-checked by victord, and every change is audited |
| Control plane | victord replicas, one task leader | Tasks, policy, placement, HA decisions, permissions, audit chain |
| State | PostgreSQL, metrics store (13 months of rollups) | Sessions, tasks, events, audit, settings, performance history |
| Virtualization | KVM-based VM clusters; optional Kubernetes VM management | Running VMs, storage pools, networks, guest devices |
| Hypervisor | KVM in the host Linux kernel | Hardware-assisted guest execution and isolation |
| Hosts | Victor Host, or supported existing virtualization hosts and Kubernetes nodes | Hardware, host operating system, local and shared storage |
03 / VM OPERATIONS
See hosts, capacity, storage, networks and VMs together. Victor applies the same task history, permissions and audit model across supported environments, and shows the available actions for each workload.
Kubernetes VM management is optional. Your runtime and storage configuration determine which console, networking, snapshot and recovery operations are available.
04 / SUPPLY CHAIN
Victor’s own images are built from scratch for amd64 and arm64, signed with cosign and carry CycloneDX SBOMs. A release build fails on any unaccepted high or critical finding in them. Bundled third-party images are pinned by digest.
The air-gap bundle holds images, the Helm chart, binaries, a Terraform provider mirror, SBOMs and docs. victor-load verifies it and loads a site registry. A Zarf package is built too.
An automated air-gap test asserts that an installed site makes no DNS lookups outside the cluster.
NEXT STEP
Bring your site layout, storage and network constraints. We will map them to Victor’s components.