Web, command line and API
One program, no database
The state of a VM is its ZFS dataset and its config.json. There is nothing else to keep in sync. If the management program stops or restarts, VMs keep running, and it rebuilds its view from the file system.
The web interface
- Overview, VMs, storage, network, logs and system pages, in English, Chinese and Japanese.
- Serial console (xterm.js) and graphical console (noVNC) in the browser; several people can watch a serial console while one types.
- New VMs are made with a wizard that starts from a template for the system: Windows, Linux, router systems, older Windows on BIOS.
- ISO images can be uploaded, or downloaded by the host from a URL.
- Changes to a running VM: name, autostart and RDP password apply at once; the rest waits for the next restart of the VM, as in Proxmox.
- The storage page creates the pool; the network page finds which VLANs and subnets are on each port.
API, tokens and audit
The API is HTTPS and JSON, described by OpenAPI. Tokens are scoped:
- operations × which VMs (all, a list, or by tag) × source addresses × expiry;
- a VM outside a token's scope answers as if it did not exist;
- a token can only create tokens narrower than itself;
- deleting is its own permission and needs the VM's name as confirmation.
Every write request is recorded in the audit log, including refused ones: time, token, source address, action, object and result. On the host itself, the command line talks to a local socket and needs no token.
Not done yet
- Managing several hosts from one place is planned, not built.
- Tokens limited to some VMs or tags are made on the command line; the web page offers admin, read-only and operator presets.
- The event stream in the API is not done.