Exclusive Access · Invitation Only

Current Limits

Compute is in early access. This page lists what it does not do yet, so you can plan around it. It changes as the work lands; Releases says what each build adds.

Part of Compute, in early access.

Servers

  • x86_64 only. Nodes on other processors (arm64) run networking normally and report Compute as unavailable.
  • Hardware virtualization. KVM with Intel VT-x or AMD-V is what Compute is built for. Without it machines run in software emulation, many times slower — for trying things out only (CENVERO_ALLOW_EMULATION=1 at install).
  • Tested on Debian 13 so far. Debian 12 and Ubuntu 22.04/24.04 install the same way; RHEL-family hosts are not validated for Compute yet.
  • A machine stays on its node. Each node runs its own machines. In a cluster you see and manage every member's machines from any member, but you choose the node a machine is created on: there is no automatic placement, and machines cannot move between nodes. A tenant's max_vms cap counts per node.

Guests

  • Linux cloud images are what is tested. UEFI, secure boot and a TPM 2.0 can be chosen at create (Firmware), but Windows guests have not been validated yet. The firmware and the TPM cannot be changed after the machine is created.
  • Resizing. CPUs and memory can be changed on an existing machine; a running one grows live only up to the maximums it was created with, anything else applies at its next restart (Changing a machine's size). Fewer vCPUs, and more vCPUs on a machine with secure boot, always wait for a restart. The disk can only grow, while the machine is stopped.
  • Extra disks are volumes. A machine boots from one disk; more space is added as volumes, which can be attached, grown, snapshotted and backed up (The Web Console). Volumes, snapshots and backups come with Compute (Licensing). On a machine created before its node's licence included volumes, attach the first volume while the machine is stopped; after that, volumes attach while it runs.
  • Interfaces can be added and removed while a machine runs. A machine created before this was possible needs one restart before an interface can be added to it while it runs, and a new interface has to be configured inside the guest.
  • Guest agent: setting an account's password and reading the guest's own addresses work; nothing else uses the guest agent yet.

Storage

  • Snapshots and backups are for volumes, not the boot disk. Keep data that matters on a volume. The node's own backups cover its configuration and records, not disks. Deleting a machine deletes its boot disk for good.
  • Backups stay on the same server, in its disk pool, so they do not protect against losing the server. Copying backups to another server is not available yet.
  • Disks are thin. They grow as the guest writes; a full pool pauses the guests that write (see Lifecycle). A tenant's volumes can be capped per node (tenant quota-set <id> --max-volumes N --max-volume-gib N); boot disks have no per-tenant quota yet — watch compute status.
  • Images: qcow2 or raw, self-contained, up to 50 GiB, fetched over HTTP(S) with a SHA-256 or copied from a file on the node.

Networking

  • Public addresses are IPv4 only, and only the "routed to the server's main address" kind most providers sell; addresses that need their own MAC address on the uplink are not supported. DHCP does not hand out public addresses.
  • Per-machine bandwidth limits are refused for a tenant that has a bandwidth cap (the tenant's cap applies instead).
  • Only machines under a tenant are separated at their port; operator machines (no tenant) are not. Across nodes, separation is the overlay network's job.
  • Only a tenant's machines are held to their own addresses. A tenant machine may send IPv4 only from its network address or its public address (Tenants); an operator machine (no tenant) may send from any address no workload has claimed. IPv6 sources are not checked yet.
  • Docker on the same server is handled: the node lets its own workload traffic through the firewall Docker switches on, and nothing else (Operations).

Management

  • One console per node, or one for a whole cluster. Each node serves its own web console. Join the nodes into a cluster and any member's console manages every member, machine consoles included.
  • Customers cannot create their own machines yet. With a tenant key they can start, stop and restart their machines, open their consoles and reset a password in the customer portal; creating, resizing and deleting machines goes through you. A tenant key works on the node that issued it, also in a cluster.
  • The Cenvero panel does not manage your machines. Like the rest of Stratum, machines are managed on your nodes; the panel only issues licences.
  • A tenant's suspension stops its machines (and cuts their traffic); the resume starts the ones that were running. Their disks stay as they are — a suspension deletes nothing.

Security notes

  • Image checks run as root on the node. Registered images are checked (SHA-256, format, no backing or external data file) before any machine uses them; register images only from sources you trust.
  • Deleting does not wipe. A deleted machine's disk space is released without being overwritten.

See also

↓ This page as JSON ↓ All documentation as JSON