# opnsense-edge: one OPNsense edge VM (D-100's per-site independent OPNsense
# edge with a simulated ISP uplink; D-103: OpenTofu owns creating it).
#
# NOT the cloud-init pattern (modules/cloudinit-vm) -- confirmed unreliable
# on OPNsense/FreeBSD this session (see opentofu/README.md's "OPNsense
# deployment research" section, fully sourced). This module instead uses
# OPNsense's own Configuration Importer: a plain ISO9660 volume containing
# /conf/config.xml, attached as a secondary cdrom disk -- mechanically
# IDENTICAL to cloudinit-vm's seed-volume shape (a libvirt_volume with
# create.content.url, attached as device="cdrom"), just a different payload
# and no libvirt_cloudinit_disk resource (that resource is NoCloud-specific;
# wrong format here). Both the base image and the config ISO are prepared
# OUTSIDE OpenTofu by scripts/opnsense-prep-image.sh and
# scripts/opnsense-build-config-iso.sh respectively -- see each variable's
# description for why.
#
# UNVERIFIED, flagged plainly (see opentofu/README.md for the full account,
# including a 2026-07-09 audit pass that corrected the LAN/WAN claim below):
# (a) whether the Configuration Importer's ISO9660 support actually behaves
# as described once booted for real -- the research is well-sourced but not
# independently tested this session (no real OPNsense boot, no
# genisoimage/xorriso available).
# (b) `devices.interfaces` list ORDER and OPNsense's LAN/WAN ROLE are TWO
# SEPARATE THINGS, not one -- corrected during the audit pass (the original
# version of this comment conflated them). List order plausibly determines
# which `vtnetN` device number FreeBSD assigns each NIC (libvirt's own docs:
# PCI addresses auto-assigned in XML order "usually match" for a simple
# topology like this one -- reasonably well-supported, not a hard guarantee).
# But OPNsense's LAN/WAN designation is a SEPARATE, explicit mapping made
# inside config.xml itself (or the interactive/API assignment step) from
# device name to role -- "vtnet0 = WAN" is a convention some guides choose,
# not a FreeBSD/OPNsense-enforced rule. So: `var.lan_network_name` at index 0
# only expresses INTENT for which network should end up as LAN; the real
# config.xml (still undesigned, see variables.tf) MUST independently
# confirm, on a real boot, which vtnetN corresponds to which network, and
# map <wan>/<lan> to the CORRECT device name accordingly -- do not assume
# "first in this list" automatically becomes OPNsense's LAN role.
#
# No PXE boot-order attribute is used here (unlike modules/node-vm): this VM
# boots from its own pre-installed disk, not over the network, so the
# UNVERIFIED `boot`-order shape noted in node-vm/main.tf does not need
# touching for this module at all.
resource "libvirt_volume" "disk" {
name = "${var.vm_name}-disk.qcow2"
pool = var.pool_name
# Direct per-VM COPY of the prepared nano image, NOT a backing/overlay.
# OPNsense nano is designed to be booted + auto-expanded IN PLACE; booting it
# through a read-only COW backing (with an overlay capacity larger than the
# base) made boot2 fault while loading /boot/loader (first-boot finding
# 2026-07-12 -- q35->i440fx did not help, the disk shape did). Matches the
# documented `virt-install --import <nano.qcow2>` workflow. The nano is already
# grown to its target size by scripts/opnsense-prep-image.sh, so var.disk_size_bytes
# is no longer used here.
create = {
content = {
url = var.base_volume_path
}
}
target = {
format = {
type = "qcow2"
}
}
}
resource "libvirt_volume" "config_seed" {
name = "${var.vm_name}-config.iso"
pool = var.pool_name
create = {
content = {
url = var.config_iso_path
}
}
}
resource "libvirt_domain" "vm" {
name = var.vm_name
memory = var.memory_mib
vcpu = var.vcpu
type = "kvm"
running = true
# host-passthrough, but DISABLE the AMD `svm` (nested-virt) feature in the
# guest. ROOT CAUSE of the first-boot triple-fault (2026-07-12): on an AMD host
# (this one is Opteron_G3), passing `svm` to a FreeBSD/OPNsense guest makes its
# loader triple-fault -- a well-documented KVM bug. Equivalent to the forum's
# `-cpu host,-svm` fix. (qemu64 default also lacks features, so host-passthrough
# is still right; we just drop svm.)
cpu = {
mode = "host-passthrough"
features = [
{
name = "svm"
policy = "disable"
}
]
}
os = {
type = "hvm"
type_arch = "x86_64"
# i440fx (pc), NOT q35: FreeBSD/OPNsense's legacy BTX `/boot/loader` triple-
# faults on q35 in qemu -- the boot dies right after boot2 echoes
# /boot.config (confirmed via the serial log, first-boot finding 2026-07-12).
type_machine = "pc"
}
devices = {
disks = [
{
source = {
volume = {
pool = libvirt_volume.disk.pool
volume = libvirt_volume.disk.name
}
}
target = {
dev = "vda"
bus = "virtio"
}
driver = {
type = "qcow2"
}
},
{
device = "cdrom"
source = {
volume = {
pool = libvirt_volume.config_seed.pool
volume = libvirt_volume.config_seed.name
}
}
target = {
dev = "sda"
bus = "sata"
}
}
]
# index 0 = the network intended for LAN, index 1 = the network intended
# for WAN -- this ORDER plausibly controls which vtnetN device number
# each gets (see the file header's corrected note), but does NOT by
# itself make OPNsense treat either as LAN/WAN -- that role assignment
# is config.xml's job. Confirm actual vtnetN<->network mapping on a real
# boot before writing config.xml's <wan>/<lan> interface names.
interfaces = [
{
model = {
type = "virtio"
}
source = {
network = {
network = var.lan_network_name
}
}
},
{
model = {
type = "virtio"
}
source = {
network = {
network = var.wan_network_name
}
}
}
]
# OPNsense nano images are SERIAL-console only. This file-backed serial gives
# the guest a serial device (its comconsole loader needs one) AND captures the
# boot output to a file, so the first boot can be read without an interactive
# console (first-boot finding 2026-07-12: with no console the domain
# triple-faulted).
serials = [
{
source = { file = { path = "/var/lib/libvirt/vr1/staging/${var.vm_name}-serial.log" } }
target = { port = "0" }
}
]
}
}
