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 prepares storage, networking, and the manager. Install and verify a guest separately before enabling autostart.
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
A private guest network #
For guests that should share a network with this host without attaching its uplink, create an addressed switch:
# vm switch create -a 192.0.2.1/24 private
# vm switch list
Replace the documentation prefix with an unused private subnet. Select private as the guest’s template switch and configure its address in that subnet. This command does not supply DHCP, NAT, or Internet routing; add those only when required.
A bridge to an existing network #
Only after selecting an interface and understanding its host address configuration should a public switch be created and attached instead:
# 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
With no guests running, service vm status can report vm is not running. The switch list, datastore, and vm list establish whether initialization succeeded; vm-bhyve is not a continuously running daemon.
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.