Synopsis #
bhyve is the FreeBSD base-system hypervisor. vm-bhyve adds guest configuration, datastores, virtual switches, console handling, and rc.d integration. Current stewardship is under the FreeBSD organization at github.com/freebsd/vm-bhyve; obsolete repositories should not be used as implementation authority.
This guide stops after host initialization and network design. Guest installation deserves testing against a specific image and firmware combination before tested_on metadata can be claimed.
Confirm the host can run bhyve #
On amd64, bhyve requires Intel EPT or AMD RVI/NPT. On aarch64, support has additional limitations. Review the boot messages:
$ grep -E 'VT-x|EPT|POPCNT|SVM' /var/run/dmesg.boot
# kldload vmm
$ kldstat -n vmm
Intel hosts should report EPT; unrestricted guest support is relevant for Linux guests and FreeBSD guests with more than one vCPU. Confirm firmware virtualization settings when the expected capability is absent.
Decide storage and recovery #
vm-bhyve can use a directory or ZFS dataset. A dedicated dataset makes capacity, snapshots, and replication visible:
# zfs create tank/vm
$ zfs list tank/vm
A snapshot of a running guest disk is not automatically application-consistent. Define guest shutdown, filesystem freeze, or application quiescing before treating a host snapshot as a backup. Replicate the dataset according to Snapshot and replicate a ZFS dataset , with guest-consistency controls added.
Install and initialize the maintained manager #
Install the FreeBSD package and persist the datastore:
# pkg install vm-bhyve
# sysrc vm_enable=YES
# sysrc vm_dir='zfs:tank/vm'
# vm init
Copy the packaged sample templates into the initialized datastore. Resolve the dataset mount point first rather than copying to a guessed path:
$ zfs get -H -o value mountpoint tank/vm
# cp /usr/local/share/examples/vm-bhyve/* /MOUNTPOINT/.templates/
Replace /MOUNTPOINT with the returned mount point. Review a template before creating a guest; CPU, memory, disk, loader, and network values are policy.
Choose the virtual network before attaching it #
vm-bhyve virtual switches can bridge guests to a physical network or support other topologies. Bridging a physical interface can move the host address to a bridge and interrupt remote access. Make such changes from a console or with a tested recovery path.
Inventory the existing host first:
$ ifconfig -a
$ netstat -rn
# pfctl -sr
# vm switch list
Only after selecting an interface and understanding its host address configuration should a public switch be created and attached:
# vm switch create public
# vm switch add public em0
# vm switch list
em0 is an example, not a default. On a remote production host, follow Change PF safely on a remote host
and the FreeBSD Handbook bridge warning before changing the live path.
Verify the control plane #
Confirm initialization without starting a guest:
# service vm status
# vm list
# vm switch list
$ zfs list -r tank/vm
Keep vm-bhyve configuration, templates, downloaded-image provenance, guest backups, and network design under the same change-control boundary. Autostart should be added only after an individual guest shuts down cleanly and recovers after a host reboot.