Cloud images
FreeSense releases can publish official UFS and ZFS variants in two architecture-scoped cloud-disk formats beside the amd64 ISO or ARM64 installer IMG:
- QCOW2 + xz for Proxmox, OpenStack, QEMU/KVM, and compatible importers.
- Raw GPT + xz for bhyve and platforms that import raw disks.
Select amd64 for supported x86-64 deployments. The arm64 images are experimental,
UEFI-only, and intended for QEMU virt or standards-compliant ARM64 UEFI machines with virtio
devices. They contain no board firmware, U-Boot, or DTBs.
The recommended UFS image is a sparse 16 GiB disk. The ZFS image is a sparse 32 GiB disk and adds
boot environments for upgrade rollback. Both boot with BIOS or UEFI, grow when the virtual disk is
enlarged, and include qemu-guest-agent. Verify the filesystem- and format-specific SHA-256 value
shown on the download page before decompressing the image.
Support follows the release channel, not the disk format: Stable 1.0.x artifacts are supported for production, while Development 1.1 artifacts are experimental and unsupported. The guided download picker shows only combinations that are actually published.
Choose UFS or ZFS
Section titled “Choose UFS or ZFS”Choose UFS for the smallest, simplest, and most broadly compatible cloud appliance. Choose ZFS when boot environments are worth the additional memory and disk headroom. The ZFS cloud image uses one non-redundant virtual disk; ZFS does not make that disk redundant. Use provider snapshots or backups, allocate at least 4 GiB of RAM, keep the virtual disk at 32 GiB or larger, and use provider-level disk encryption when required.
The ZFS pool is named FreeSense, starts at FreeSense/ROOT/default, and keeps configuration and
the package database with each boot environment. A rollback therefore restores a coherent system
state. Cloud instance identity remains idempotent and is reapplied if a rollback predates initial
provisioning.
Network and management safety
Section titled “Network and management safety”Use two virtual NICs whenever possible. The adapter makes the metadata default-route interface
WAN and the next interface LAN unless the freesense: extension assigns explicit roles. With two
or more NICs, SSH and WebUI management remain on LAN; FreeSense never adds an automatic WAN rule.
The image’s known default password is locked. SSH uses the existing admin account and rejects
password authentication.
NoCloud example
Section titled “NoCloud example”Create meta-data:
instance-id: edge-001local-hostname: edge-001.example.netCreate user-data:
#cloud-configtimezone: Europe/Copenhagenssh_authorized_keys: - ssh-ed25519 AAAA... operator@examplefreesense: management_cidrs: - 203.0.113.10/32 interfaces: - match: "52:54:00:12:34:56" role: wan - match: "52:54:00:12:34:57" role: lanCreate network-config:
version: 2ethernets: uplink: match: macaddress: "52:54:00:12:34:56" dhcp4: true dhcp6: true inside: match: macaddress: "52:54:00:12:34:57" addresses: [10.20.0.1/24, "2001:db8:20::1/64"] nameservers: addresses: [1.1.1.1, "2606:4700:4700::1111"]Then create and attach the seed:
cloud-localds --network-config=network-config cidata.iso user-data meta-dataNoCloud, ConfigDrive, and OpenStack datasources are supported. Hostname/FQDN, timezone, DHCP4,
DHCP6/SLAAC, static IPv4/IPv6, gateways, MTU, DNS, SSH keys, roles, and management CIDRs are
translated into native config.xml; cloud-init does not maintain a competing rc.conf network.
Import examples
Section titled “Import examples”Proxmox (replace ufs with zfs to import the ZFS variant):
unxz FreeSense-*-amd64-ufs.qcow2.xzqm importdisk 120 FreeSense-*-amd64-ufs.qcow2 local-lvmQEMU/KVM (replace ufs with zfs when desired):
qemu-system-x86_64 -enable-kvm -m 4096 \ -drive file=FreeSense-*-amd64-ufs.qcow2,if=virtio \ -drive file=cidata.iso,if=virtio,readonly=on \ -nic user,model=virtio -nic tap,model=virtiobhyve (replace ufs with zfs when desired):
unxz FreeSense-*-amd64-ufs.raw.xzbhyve -c 2 -m 4G -H -w -s 3,virtio-blk,FreeSense-*-amd64-ufs.raw freesenseFor OpenStack, upload the QCOW2 as a qcow2 image and supply network data through the instance’s
ConfigDrive or metadata service.
Reprovisioning
Section titled “Reprovisioning”Provisioning is atomic and keyed by cloud instance ID. Rebooting the same instance does not duplicate interfaces, users, or firewall rules. Cloning with a new instance ID performs a new initialization and regenerates host identity and SSH host keys.