Experimental (preview) features

SimpleVirt v1.0 ships seven capabilities as previews. They are built, they are in the binary, and they are off. A preview is a capability the vendor does not support for production use in this release — it may be incomplete, unaudited, or proven only in the lab.

Nothing here is enabled by an upgrade. A controller with no experimental: block — which is every install that predates this mechanism — offers none of them.

Turning one on

Edit the controller's configuration (/etc/simplevirt-command/config.yaml) and restart simplevirt-command:

experimental:
  cluster_services: true

Enabling a flag is an explicit acceptance that the capability is unsupported. The controller logs a warning at startup naming every preview you have enabled.

A flag name this build does not recognise is ignored with a warning, not treated as a fatal typo. Every other key in the config file is strict; this block is deliberately not, so that a configuration written by a newer SimpleVirt still boots an older controller after a rollback.

How the gate works

Three layers, of which only the first is a control:

The API refuses. Every endpoint belonging to a disabled feature answers 403 with {"error": "...", "experimental": "<flag>"}. This is the real gate: a client with a session cookie and curl is bound by it.
The UI hides or labels. Where a feature is off, SimpleVirt-Command does not present its entry point as an ordinary capability. Where it is on, every entry point carries an EXPERIMENTAL badge.
The startup log states it. So a support case never has to guess.

The seven

Flag	Capability	Why it is a preview
`cluster_services`	SimpleVirt Cluster Services (`simplevirt-clusterd`)	Command-independent HA. Held to v1.1.
`file_services`	SimpleVirt File Services	SMB/NFS shares carved from SimpleVirt HCI (CephFS) on a highly-available floating address. Both NFS and SMB are served from the appliance image. The serving path is production-quality but must be lab-proven across a full multi-host cluster before the flag comes off. See File Services and known limitation 12.
`kubernetes`	Kubernetes (k3s) provisioning	Never audited. Flagged as-is; no behaviour was changed.
`unattended_install`	`simplevirtinstall.auto=1` / PXE install	Label only — see below.
`windows_guest_tools`	The Windows half of SimpleVirt Guest Tools	The medium is bundled and signed, but installation is still a manual run at the guest console followed by a reboot. Linux guest tools are supported and are not behind this flag.
`block_datastores`	iSCSI and Fibre Channel datastore types	The pre-release audit found they cannot hold a VM disk, and that merely adding one flips the Create VM wizard into HCI-only mode.
`library_iso_items`	Content library "ISO (install media)" item type	No code in the product can mount a library ISO into a VM, so importing one produces a catalog row and nothing else.

`unattended_install` is label-only

The installer runs from the live ISO, long before any controller configuration exists, so there is nothing for it to read this flag from. Flagging it means saying so: simplevirt-installer prints an EXPERIMENTAL banner on the serial and system console before an unattended install begins, which is the only place a PXE install can be diagnosed from.

It is deliberately not blocked. The release's own automated ISO boot test installs through this path, and a gate would refuse the very run that proves the image boots.

Graduated out of preview

Capabilities leave this set as they mature. When one graduates its flag is removed, its endpoints and UI become available without a flag, and any remaining safety gate stays in force. A configuration that still carries a removed key is harmless — the key is recorded as unknown and warned about, never fatal.

SimpleVirt HCI (hci) — now a supported, always-on storage tier (like NFS).
Stretched cluster (stretched_cluster) — graduated. Its tab and endpoints need no flag. Every fail-closed readiness check is intact, so a cluster that is not a genuine two-site + witness topology reads Not Ready and can never be activated. Full two-datacenter hardware validation is still pending; the honest capability note lives in the Stretched Cluster UI and in SIMPLEVIRT_STRETCHED_CLUSTER.md, not here.
Workload Distributor (workload_distributor) — graduated now that SimpleVirt HCI is a supported, live-migratable tier (the old "inert on the default storage tier" rationale is obsolete). Its tab and endpoints need no flag. It defaults to recommend-only, so out of the box it proposes moves and never performs one on its own; an operator must opt into automatic mode. Every move it makes or recommends passes the same fail-closed migration precheck a manual live-migration does (shared storage, GPU/passthrough, memory headroom, admission policy), and it reports honestly — rather than acting — when a cluster has nothing it can legally balance.

Not in this list

Two things the scope ruling grouped with the previews are vendor tooling, not in-product features, and have no flag because there is nothing to flag: the hot-deploy scripts (scripts/deploy-*.sh) and the auxiliary image builders. Neither has a UI or an endpoint, and neither ships to a client.

For developers

The mechanism is internal/experimental: a typed Flags struct, one Enabled helper, and a tolerant YAML unmarshaler. The controller-side gate is internal/commandserver/handlers_experimental.go — expOnly wraps a handler inside the auth/CSRF/privilege chain, so an unauthenticated caller still only learns "sign in first". GET /api/v1/settings/features is what the SPA reads.

Adding a preview feature means: a constant and a label in internal/experimental, expOnly on its routes, a row in web/command/static/js/features.js, and a row in the table above.