Sylve

Sylve is a lightweight, open-source management platform for FreeBSD that provides a Proxmox-like experience. It integrates several core FreeBSD technologies into a single web interface:

• Bhyve Virtual Machine Management: Manage virtual machines using the Bhyve hypervisor.
• FreeBSD Jail Management: Manage FreeBSD Jails.
• ZFS-first storage architecture: Native integration with ZFS.
• Clustering & Networking: Built-in clustering support and integrated networking tooling.
• Zelta integration: Support for backups via Zelta.

Sylve is an open-source control panel for FreeBSD virtualization and storage that unifies Bhyve, FreeBSD Jails, and ZFS into a single web UI.

Key capabilities include:

• Bhyve management: Full lifecycle control (create, start, stop, snapshot) and configuration (CPU, memory, PCI passthrough, VNC, serial access).
• Jails: Managed with VM-like workflows, including networking, datastores, limits, and console/shell access.
• ZFS-first storage: Management of pools, datasets, disks, and datastores with direct mapping to VMs and Jails.
• Networking: Configuration of physical interfaces, virtual switches, and DHCP scopes, with support for Samba and libvirt integrations.

Overview

zelta is a tool for performing safe, recursive ZFS operations such as replication, backup verification, dataset recovery, and policy-based automation. It supports both local and remote execution via ssh(1).

Remote Endpoints

Remote dataset endpoints follow scp(1) conventions. You do not need to install zelta on remote systems; only standard ZFS utilities and SSH access are required.

• Local format: pool/dataset@snapshot
• Remote format: user@example.com:pool/dataset@snapshot

Basic Command Syntax

zelta SUBCOMMAND [OPTIONS] [ARGUMENTS]

Sylve is organized into four primary domains: storage, networking, virtualization, and orchestration.

• Storage: Driven by ZFS, providing S.M.A.R.T. visibility, pool monitoring, and snapshot operations.
• Networking: Pairs physical NICs with user-defined virtual switches that can be published to guests.
• Virtualization: Bhyve and Jail management share the same datastore and virtual-switch primitives to ensure aligned workflows.
• Orchestration: All flows are managed through a Go backend and a REST API. The API surface is defined in docs/swagger/swagger.yaml, which can be used to generate clients or build custom integrations.

Sylve implements a 'fail closed' policy for replication. If a node cannot read its local replication policy state or cannot determine its own local node identity, it enters an emergency fencing state to prevent data corruption.

During emergency fencing, Sylve performs the following:

1. Stops every Sylve-managed VM and jail on the node (including workloads without a replication policy).
2. Fences canonical guest datasets to prevent writes while ownership is unknown.
3. Retains the last durable ownership observations to allow for restoration of dataset properties once the control plane is recovered.

Note: This fencing is intentionally broad because an unreadable policy database cannot verify which specific guests are protected.

Zelta uses specific casing to denote variable scope and type. Adhering to these conventions is critical for maintaining code readability and understanding the lifecycle of data.

Sylve manages storage by providing full control over ZFS, allowing users to perform disk operations, manage datasets, and handle snapshots.

Storage is organized into Datastores, which are created over ZFS datasets. These datastores act as the underlying storage layer for Virtual Machines (VMs), Jails, and ISO images. You can attach or detach these datastores to specific workloads to provide them with persistent storage.

Snapshot Visibility Latency

To optimize performance on systems with large numbers of snapshots, Sylve uses heavy backend caching. A full pool rescan is only triggered by ZFS events.

• Note: If you create a snapshot via the CLI or another UI, it may take seconds or even minutes to appear in the Sylve table.
• Action: Use the refresh button on the top right of the snapshots table to force a frontend refresh.

Periodic Snapshot Naming

Periodic snapshots created by the Sylve scheduler follow a specific naming pattern: [dataset-path]@[prefix]-[YYYY-MM-DD-HH-mm]

Example: zroot/samba@samba-minutely-2026-03-09-15-00

• zroot/samba: The dataset path.
• samba-minutely: The user-defined prefix.
• 2026-03-09-15-00: The timestamp appended by the scheduler.

Sylve nodes use groups to organize users. By default, a group named sylve_g is automatically created when you initialize a Sylve node; this group serves as the default container for all users created on that node.

You can create additional groups to implement more granular access control or organizational structures.

Sylve's networking model uses a combination of physical interfaces and virtual switches to provide connectivity to workloads.

• Physical Interfaces: Manage the actual network hardware (list, create, delete).
• Virtual Switches: Create and manage software-defined switches to connect VMs and Jails together.
• Workload Integration: You can attach or detach network interfaces and virtual switches to both VMs and Jails to define their network topology.

Zelta is designed to prevent data loss through several core principles:

1. Read-Only Defaults: Backups are created as read-only by default to prevent accidental modification.
2. No Destructive Overwrites: Instead of forcing an overwrite when data diverges, Zelta uses zelta rotate to clone and preserve both versions.
3. Zero Footprint: Zelta operates via SSH from a management host. No agents or daemons are required on the source or target endpoints.
4. Safe Mountpoints: Child dataset mountpoints are automatically reset to prevent dangerous overlapping mounts during recovery operations.
5. ZFS Dependency: Zelta relies on ZFS features (snapshots, sends, receives) to provide its functionality.

Network Objects are abstractions used to represent Hosts, Networks, MAC addresses, or DUIDs within the Sylve application. Instead of using raw, complex configuration values (like IP addresses or MACs) throughout your setup, you define a named Network Object once.

Benefits:

• Readability: Use simple names (e.g., LAN Gateway) instead of raw values.
• Maintainability: If a configuration value changes, you only update it in one place (the object definition) rather than performing a find-and-replace across your entire configuration.
• Abstraction: Decouples the logical name of a network component from its physical or numerical value.