Features - kcore hypervisor

Read this first

A failed host update boots the previous generation.
Windows Server and Windows desktop guests run.
One physical GPU can be assigned to one VM. NVIDIA vGPU, many VMs on one card, is not available.
Live migration needs shared Ceph storage. Control-plane replication across datacenters is not vSphere HA.
kcore-migrate inventories vCenter or Proxmox and converts exported disks to qcow2 or raw. It does not read disks straight from vCenter. Cutover is a project. See the import guide and kcore-migrate.
Price is per CPU socket per year. The evaluation ISO is free. Download it from GitHub Releases.

Bare-metal install

A provisioner configures servers over IPMI and Redfish. It netboots kcore with UEFI HTTP boot.

A failed update boots the previous generation

Host updates are one transaction. If an update fails, the machine boots the previous generation.

✓
Immutable Base System
The host OS is read-only. Configuration lives in Nix, not scattered across /etc.
✓
Boot into Previous Generation
Every NixOS generation is kept. Select a previous one at boot or switch remotely.
✓
Download the ISO
Official ISOs are produced from flake.nix. Download the evaluation ISO. You do not build it.

Current generation

↓

Apply update

↓

Update fails

↓

Boot the previous generation

For platform teams

Terraform, the API, and MCP come after the limits above. They do not remove those limits.

Infrastructure as Code

VMs are resources in Terraform. You write HCL, run terraform apply, and the provider talks to the kcore API over gRPC. Standard workflow, no special tooling.

📝
Real Terraform Provider
Written in Go using the Terraform Plugin SDK. Not a shell wrapper.
🔄
Git-friendly
HCL and YAML are text files. Diff them, review them, track changes over time.
📊
Desired State
The controller stores desired state. Node agents reconcile. Standard controller pattern.

# Provider kcorehypervisor/kcore 0.5.0
resource "kcore_vm" "web" {
  name               = "web"
  cpu                = 2
  memory_bytes       = 4294967296
  storage_backend    = "filesystem"
  storage_size_bytes = 53687091200
  image_url          = "https://example.com/debian.qcow2"
  image_sha256       = "<sha256>"

  nic {
    network = "production"
  }
}

resource "kcore_vm" "db" {
  name               = "db"
  cpu                = 4
  memory_bytes       = 8589934592
  storage_backend    = "lvm"
  storage_size_bytes = 214748364800
  image_url          = "https://example.com/debian.qcow2"
  image_sha256       = "<sha256>"

  nic {
    network = "production"
  }
}

AI Agent Integration

kcore includes an MCP (Model Context Protocol) server. Any MCP-compatible AI agent can list nodes, create VMs, check status, and generate Terraform configs through it.

🤖
MCP Server
Runs alongside the controller. Exposes tools for VM and node management over MCP.
💡
Terraform Output
Agents generate HCL you can read and modify. No black-box deployments.
📈
Query Infrastructure
Agents can check VM status, node health, and resource usage to help you troubleshoot.

User:

"Create a web cluster with 3 servers, load balanced, with a PostgreSQL database"

⚡ AI Processing

AI Agent:

"I'll create that infrastructure for you:"

✓ 3x web servers (4GB RAM each)
✓ 1x PostgreSQL (8GB RAM)
✓ Load balancer configured
✓ Network policies applied

✓ All resources deployed successfully

How kcore Compares

Feature	kcore	Traditional VMs	Container Orchestration
Atomic Updates	✓	✗	✓
Boots the previous generation	✓	✗	✗
Infrastructure as Code	✓	Partial	✓
Full OS Isolation	✓	✓	✗
Legacy App Support	✓	✓	Limited

What kcore does