FreeBSD Manual Pages

home | help

BHYVE(8) System Manager's Manual BHYVE(8)

NAME
bhyve -- run a guest operating system inside a virtual machine

SYNOPSIS
bhyve [-aCDeHhPSuWwxY]
[-c [[cpus=]numcpus][,sockets=n][,cores=n][,threads=n]] [-f
name,[string|file]=data] [-G [w][bind_address:]port]
[-k config_file] [-K layout] [-l lpcdev[,conf]]
[-m memsize[K|k|M|m|G|g|T|t]] [-o var=value] [-p vcpu:hostcpu]
[-r file] [-s slot,emulation[,conf]] [-U uuid] vmname
bhyve -l help
bhyve -s help

DESCRIPTION
bhyve is a hypervisor that runs guest operating systems inside a vir-
tual machine. It can run guests on amd64 and arm64 platforms with
suitable hardware support.

Parameters such as the number of virtual CPUs, amount of guest memory,
and I/O connectivity can be specified with command-line parameters.

bhyve is typically used with a boot ROM that can load the guest operat-
ing system. On arm64 platforms, this is currently required. If not
using a boot ROM, the guest operating system must be loaded with
bhyveload(8) or a similar boot loader before running bhyve, otherwise.
On amd64, the edk2-bhyve package provides a UEFI firmware that can be
used to boot the guest; on arm64 the u-boot-bhyve-arm64 package pro-
vides a U-Boot image that can be used to boot the guest.

bhyve runs until the guest operating system reboots or an unhandled hy-
pervisor exit is detected.

OPTIONS
-a The guest's local APIC is configured in xAPIC mode. This
option only applies to the amd64 platform. xAPIC mode is
the default setting so this option is redundant. It will
be deprecated in a future version.

-C Include guest memory in core files.

-c [[cpus=]numcpus][,sockets=n][,cores=n][,threads=n]
Number of guest virtual CPUs and/or the CPU topology. The
default value for each of numcpus, sockets, cores, and
threads is 1. If numcpus is not specified then it will be
calculated from the other arguments. The topology must be
consistent in that the numcpus must equal the product of
sockets, cores, and threads. If a setting is specified
more than once the last one has precedence.

The maximum number of virtual CPUs defaults to the number
of active physical CPUs in the system available via the
hw.vmm.maxcpu sysctl(8) variable. The limit can be ad-
justed via the hw.vmm.maxcpu loader tunable.

-D Destroy the VM on guest initiated power-off.

-e Force bhyve to exit when a guest issues an access to an I/O
port that is not emulated. This is intended for debug pur-
poses and only applies to the amd64 platform.

-f name,[string|file]=data
Add a fw_cfg file name to the fw_cfg interface. If a
string is specified, the fw_cfg file contains the string as
data. If a file is specified, bhyve reads the file and
adds the file content as fw_cfg data.

-G [w][bind_address:]port
Start a debug server that uses the GDB protocol to export
guest state to a debugger. An IPv4 TCP socket will be
bound to the supplied bind_address and port to listen for
debugger connections. Only a single debugger may be at-
tached to the debug server at a time. If the option begins
with `w', bhyve will pause execution at the first instruc-
tion waiting for a debugger to attach.

-H Yield the virtual CPU thread when a HLT instruction is de-
tected. If this option is not specified, virtual CPUs will
use 100% of a host CPU. This option applies only to the
amd64 platform.

-h Print help message and exit.

-k config_file
Set configuration variables from a simple, key-value config
file. Each line of the config file is expected to consist
of a config variable name, an equals sign (`='), and a
value. No spaces are permitted between the variable name,
equals sign, or value. Blank lines and lines starting with
`#' are ignored. See bhyve_config(5) for more details.

-K layout Specify the keyboard layout. The value that can be speci-
fied sets the file name in /usr/share/bhyve/kbdlayout.
This specification only works when loaded with UEFI mode
for VNC. When using a VNC client that supports QEMU Ex-
tended Key Event Message (e.g. TigerVNC), this option
isn't needed. When using a VNC client that doesn't support
QEMU Extended Key Event Message (e.g. tightVNC), the layout
defaults to the US keyboard unless specified otherwise.

-l help Print a list of supported LPC devices.

-l lpcdev[,conf]
Allow devices behind the LPC PCI-ISA bridge to be config-
ured. The only supported devices are the TTY-class devices
com1, com2, com3, and com4, the TPM module tpm, the boot
ROM device bootrom, the fwcfg type and the debug/test de-
vice pc-testdev.

The possible values for the conf argument are listed in the
-s flag description.

This option applies only to the amd64 platform. On arm64,
the console and boot ROM devices are configured using the
more generic -o option.

-m memsize[K|k|M|m|G|g|T|t]
Set the guest physical memory size. This must be the same
size that was given to bhyveload(8).

The size argument may be suffixed with one of K, M, G or T
(either upper or lower case) to indicate a multiple of
kilobytes, megabytes, gigabytes, or terabytes. If no suf-
fix is given, the value is assumed to be in megabytes. The
default is 256M.

-n id,size,cpus[,domain_policy]
Configure guest NUMA domains. This option applies only to
the amd64 platform.

The -n option allows the guest physical address space to be
partitioned into domains. The layout of each domain is en-
coded in an ACPI table visible to the guest operating sys-
tem. The -n option also allows the specification of a
domainset(9) memory allocation policy for the host memory
backing a given NUMA domain. A guest can have up to 8 NUMA
domains. This feature requires that the guest use a boot
ROM, and in particular cannot be used if the guest was ini-
tialized using bhyveload(8).

Each domain is identified by a numerical id. The domain
memory size is specified using the same format as the -m
flag. The sum of all size parameters overrides the total
VM memory size specified by the -m flag. However, if at
least one domain memory size parameter is missing, the to-
tal VM memory size will be equally distributed across all
emulated domains. The cpuset parameter specifies the set
of CPUs that are part of the domain. The domain_policy pa-
rameter may be optionally used to configure the
domainset(9) host NUMA memory allocation policy for an emu-
lated domain. See the -n flag in cpuset(1) for a list of
valid NUMA memory allocation policies and their formats.

-o var=value
Set the configuration variable var to value. See
bhyve_config(5) for configuration options.

-P Force the guest virtual CPU to exit when a PAUSE instruc-
tion is detected. This option applies only to the amd64
platform.

-p vcpu:hostcpu
Pin guest's virtual CPU vcpu to hostcpu. Host CPUs and
guest virtual CPUs are numbered starting from 0. A -p op-
tion is required for every guest vCPU to be pinned. To map
a 4 vCPU guest to host CPUs 12-15:

-p 0:12 -p 1:13 -p 2:14 -p 3:15

-r file Resume a guest from a snapshot. The guest memory contents
are restored from file, and the guest device and vCPU state
are restored from the file "file.kern".

Note that the current snapshot file format requires that
the configuration of devices in the new VM match the VM
from which the snapshot was taken by specifying the same -s
and -l options. The count of vCPUs and memory configura-
tion are read from the snapshot.

-S Wire guest memory.

-s help Print a list of supported PCI devices.

-s slot,emulation[,conf]
Configure a virtual PCI slot and function.

bhyve provides PCI bus emulation and virtual devices that
can be attached to slots on the bus. There are 32 avail-
able slots, with the option of providing up to 8 functions
per slot.

The slot can be specified in one of the following formats:

• pcislot
• pcislot:function
• bus:pcislot:function

The pcislot value is 0 to 31. The optional function value
is 0 to 7. The optional bus value is 0 to 255. If not
specified, the function value defaults to 0. If not speci-
fied, the bus value defaults to 0.

See "PCI EMULATION" for available options for the emulation
argument.

-U uuid Set the universally unique identifier (UUID) in the guest's
System Management BIOS System Information structure. By
default a UUID is generated from the host's hostname and
vmname.

-u RTC keeps UTC time.

-W Force virtio PCI device emulations to use MSI interrupts
instead of MSI-X interrupts.

-w Ignore accesses to unimplemented Model Specific Registers
(MSRs). This is intended for debug purposes.

-x The guest's local APIC is configured in x2APIC mode. This
option applies only to the amd64 platform.

-Y Disable MPtable generation. This option applies only to
the amd64 platform.

vmname Alphanumeric name of the guest. This should be the same as
that created by bhyveload(8).

PCI EMULATION
bhyve provides emulation for various PCI devices. They are specified
by the -s slot,emulation,conf configuration's emulation argument, which
can be one of the following:

hostbridge A simple host bridge. This is usually configured at
slot 0, and is required by most guest operating sys-
tems.

amd_hostbridge Emulation identical to hostbridge using a PCI vendor ID
of AMD.

passthru PCI pass-through device.

virtio-net Virtio network interface.

virtio-blk Virtio block storage interface.

virtio-scsi Virtio SCSI interface.

virtio-9p Virtio 9p (VirtFS) interface.

virtio-rnd Virtio RNG interface.

virtio-console Virtio console interface, which exposes multiple ports
to the guest in the form of simple char devices for
simple IO between the guest and host userspaces.

virtio-input Virtio input interface.

ahci AHCI controller attached to arbitrary devices.

ahci-cd AHCI controller attached to an ATAPI CD/DVD.

ahci-hd AHCI controller attached to a SATA hard drive.

e1000 Intel e82545 network interface.

uart PCI 16550 serial device.

lpc LPC PCI-ISA bridge with COM1, COM2, COM3, and COM4
16550 serial ports, a boot ROM, and, optionally, a TPM
module, a fwcfg type, and the debug/test device. The
LPC bridge emulation can only be configured on bus 0.

fbuf Raw framebuffer device attached to VNC server.

xhci eXtensible Host Controller Interface (xHCI) USB con-
troller.

nvme NVM Express (NVMe) controller.

hda High Definition Audio Controller.

The optional parameter conf describes the backend for device emula-
tions. If conf is not specified, the device emulation has no backend
and can be considered unconnected.

Network device backends
• tapN[,mac=xx:xx:xx:xx:xx:xx][,mtu=N]

• vmnetN[,mac=xx:xx:xx:xx:xx:xx][,mtu=N]

• netgraph,path=ADDRESS,peerhook=HOOK[,socket=NAME][,hook=HOOK][,mac=xx:xx:xx:xx:xx:xx][,mtu=N]

• slirp,hostfwd=proto:hostaddr:hostport-guestaddr:guestport

If mac is not specified, the MAC address is derived from a fixed OUI,
and the remaining bytes from an MD5 hash of the slot and function num-
bers and the device name.

The MAC address is an ASCII string in ethers(5) format.

With virtio-net devices, the mtu parameter can be specified to inform
the guest about the largest MTU that should be allowed, expressed in
bytes.

With netgraph backend, the path and peerhook parameters must be speci-
fied to set the destination node and corresponding hook. The optional
parameters socket and hook may be used to set the ng_socket(4) node
name and source hook. The ADDRESS, HOOK, and NAME must comply with
netgraph(4) addressing rules.

The slirp backend can be used to provide a NATed network to the guest.
This backend has poor performance but does not require any network con-
figuration on the host system. It depends on the net/libslirp port.
The hostfwd option takes a 5-tuple describing how connections from the
host are to be forwarded to the guest. Multiple rules can be speci-
fied, separated by semicolons. Note that semicolons must be escaped or
quoted to prevent the shell from interpreting them.

Block storage device backends:
• /filename[,block-device-options]

• /dev/xxx[,block-device-options]

The block-device-options are:

nocache Open the file with O_DIRECT.

direct Open the file using O_SYNC.

ro Force the file to be opened read-only.

sectorsize=logical[/physical]
Specify the logical and physical sector sizes of the emu-
lated disk. The physical sector size is optional and is
equal to the logical sector size if not explicitly speci-
fied.

nodelete Disable emulation of guest trim requests via DIOCGDELETE
requests.

bootindex=index
Add the device to the bootorder at index. A fwcfg file is
used to specify the bootorder. The guest firmware may ig-
nore or doesn't support this fwcfg file. In that case,
this feature doesn't work as expected.

SCSI device backends
• /dev/cam/ctl[pp.vp][,scsi-device-options]

The scsi-device-options are:

iid=IID Initiator ID to use when sending requests to specified CTL
port. The default value is 0.

9P device backends
• sharename=/path/to/share[,9p-device-options]

The 9p-device-options are:

ro Expose the share in read-only mode.

TTY device backends
stdio Connect the serial port to the standard input and output of
the bhyve process.

/dev/xxx Use the host TTY device for serial port I/O.

tcp=ip:port
Use the TCP server for serial port I/O. Configuring this
option will start a TCP server that waits for connections.
Only one connection is allowed at any time. Other connec-
tion try to connect to TCP server will be disconnected im-
mediately. Note that this feature allows unprivileged users
to access the guest console, so ensure that access is ap-
propriately restricted.

TPM device backends
• type,path[,tpm-device-options]

Emulate a TPM device. Supported options for type:

passthru Use a physical TPM device. The argument path needs to
point to a valid TPM device path, i.e. /dev/tpm0.

swtpm Connect to a running swtpm instance. The argument path
needs to point to a UNIX domain socket that a swtpm process
is listening on.

The tpm-device-options are:

version=version
Version of the TPM device according to the TCG specifica-
tion. Defaults to 2.0, which is the only version currently
supported.

Boot ROM device backends
• romfile[,varfile]

Map romfile in the guest address space reserved for boot firmware.

If varfile is provided, that file is also mapped in the boot firmware
guest address space, and any modifications the guest makes will be
saved to that file.

Fwcfg types:

fwcfg The fwcfg interface is used to pass information such as the
CPU count or ACPI tables to the guest firmware. Supported
values are `bhyve' and `qemu'. Due to backward compatibil-
ity reasons, `bhyve' is the default option. When `bhyve'
is used, bhyve's fwctl interface is used. It currently re-
ports only the CPU count to the guest firmware. The `qemu'
option uses QEMU's fwcfg interface. This interface is
widely used and allows user-defined information to be
passed to the guest. It is used for passing the CPU count,
ACPI tables, a boot order and many other things to the
guest. Some operating systems such as Fedora CoreOS can be
configured by qemu's fwcfg interface as well.

Pass-through device backends
• pptN[,passthru-device-options]

• bus/slot/function[,passthru-device-options]

• pcibus:slot:function[,passthru-device-options]

Connect to a PCI device on the host either named ppt N or at the selec-
tor described by slot, bus, and function numbers.

The passthru-device-options are:

rom=romfile
Add romfile as option ROM to the PCI device. The ROM will
be loaded by firmware and should be capable of initializing
the device.

Guest memory must be wired using the -S option when a pass-through de-
vice is configured.

The host device must have been reserved at boot-time using the pptdevs
loader variable as described in vmm(4).

Virtio console device backends
• port1=/path/to/port1.sock[,portN=/path/to/port2.sock ...]

A maximum of 16 ports per device can be created. Every port is named
and corresponds to a Unix domain socket created by bhyve. bhyve ac-
cepts at most one connection per port at a time.

Limitations:

• Due to the lack of destructors in bhyve, sockets on the filesystem
must be cleaned up manually after bhyve exits.

• There is no way to use the "console port" feature, nor the console
port resize at present.

• Emergency write is advertised, but no-op at present.

Virtio input device backends:
• /dev/input/eventX

Send input events of /dev/input/eventX to guest by VirtIO Input Inter-
face.

Framebuffer device backends
• [rfb=ip-and-port][,w=width][,h=height][,vga=vgaconf][,wait][,password=password]

Configuration options are defined as follows:

rfb=ip-and-port (or tcp=ip-and-port)
An IP address and a port VNC should listen on. There are
two formats:

• [IPv4:]port
• [IPv6%zone]:port

The default is to listen on localhost IPv4 address and de-
fault VNC port 5900. An IPv6 address must be enclosed in
square brackets and may contain an optional zone identi-
fier.

w=width and h=height
A display resolution, width and height, respectively. If
not specified, a default resolution of 1024x768 pixels will
be used. Minimal supported resolution is 640x480 pixels,
and maximum is 3840x2160 pixels.

vga=vgaconf
Possible values for this option are io (default), on, and
off. PCI graphics cards have a dual personality in that
they are standard PCI devices with BAR addressing, but may
also implicitly decode legacy VGA I/O space (0x3c0-3df) and
memory space (64KB at 0xA0000). The default io option
should be used for guests that attempt to issue BIOS calls
which result in I/O port queries, and fail to boot if I/O
decode is disabled.

The on option should be used along with the CSM BIOS capa-
bility in UEFI to boot traditional BIOS guests that require
the legacy VGA I/O and memory regions to be available.

The off option should be used for the UEFI guests that as-
sume that VGA adapter is present if they detect the I/O
ports. An example of such a guest is OpenBSD in UEFI mode.

Please refer to the bhyve FreeBSD wiki page
(https://wiki.freebsd.org/bhyve) for configuration notes of
particular guests.

wait Instruct bhyve to only boot upon the initiation of a VNC
connection, simplifying the installation of operating sys-
tems that require immediate keyboard input. This can be
removed for post-installation use.

password=password
This type of authentication is known to be cryptographi-
cally weak and is not intended for use on untrusted net-
works. Many implementations will want to use stronger se-
curity, such as running the session over an encrypted chan-
nel provided by IPsec or SSH.

xHCI USB device backends
• tablet

A USB tablet device that provides precise cursor synchronization when
using VNC.

NVMe device backends
• devpath[,maxq=#][,qsz=#][,ioslots=#][,sectsz=#][,ser=#][,eui64=#][,dsm=opt]

Configuration options are defined as follows:

devpath Accepted device paths are: /dev/blockdev or /path/to/image
or ram=size_in_MiB.

maxq Max number of queues.

qsz Max elements in each queue.

ioslots Max number of concurrent I/O requests.

sectsz Sector size (defaults to blockif sector size).

ser Serial number with maximum 20 characters.

eui64 IEEE Extended Unique Identifier (8 byte value).

dsm DataSet Management support. Supported values are: auto,
enable, and disable.

AHCI device backends
• [[hd:|cd:]path][,nmrr=nmrr][,ser=#][,rev=#][,model=#]

Configuration options are defined as follows:

nmrr Nominal Media Rotation Rate, known as RPM. Value 1 will
indicate device as Solid State Disk. Default value is 0,
not report.

ser Serial Number with maximum 20 characters.

rev Revision Number with maximum 8 characters.

model Model Number with maximum 40 characters.

HD Audio device backends
• [play=playback][,rec=recording]

Configuration options are defined as follows:

play Playback device, typically /dev/dsp0.

rec Recording device, typically /dev/dsp0.

CONFIGURATION VARIABLES
bhyve uses an internal tree of configuration variables to describe
global and per-device settings. When bhyve starts, it parses command
line options (including config files) in the order given on the command
line. Each command line option sets one or more configuration vari-
ables. For example, the -s option creates a new tree node for a PCI
device and sets one or more variables under that node including the de-
vice model and device model-specific variables. Variables may be set
multiple times during this parsing stage with the final value overrid-
ing previous values.

Once all of the command line options have been processed, the configu-
ration values are frozen. bhyve then uses the value of configuration
values to initialize device models and global settings.

More details on configuration variables can be found in
bhyve_config(5).

CONFIGURATION FILE CREATION
The -k flag allows one to provide a path to a configuration file hold-
ing all settings, which otherwise would need to be defined by providing
a long list of program arguments to bhyve.

There is a very simple way to translate a complex set of program argu-
ments to an equivalent configuration file in bhyve_config(5) format.

Use -o config.dump=1 to make bhyve dump a configuration file represent-
ing the used flags and arguments to stdout. You can pipe the output
into a file to persist the generated settings.

Make sure to remove the config.dump line from the resulting configura-
tion file before using it to start bhyve.

DEBUG SERVER
The current debug server provides limited support for debuggers.

Registers
Each virtual CPU is exposed to the debugger as a thread.

General purpose registers can be queried for each virtual CPU, but
other registers such as floating-point and system registers cannot be
queried.

Memory
Memory (including memory mapped I/O regions) can be read and written by
the debugger. Memory operations use virtual addresses that are re-
solved to physical addresses via the current virtual CPU's active ad-
dress translation.

Control
The running guest can be interrupted by the debugger at any time (for
example, by pressing Ctrl-C in the debugger).

Single stepping is only supported on Intel CPUs supporting the MTRAP VM
exit.

Breakpoints are supported on Intel CPUs that support single stepping.
Note that continuing from a breakpoint while interrupts are enabled in
the guest may not work as expected due to timer interrupts firing while
single stepping over the breakpoint.

SIGNAL HANDLING
bhyve deals with the following signals:

SIGTERM Trigger ACPI poweroff for a VM

EXIT STATUS
Exit status indicates how the VM was terminated:

0 rebooted
1 powered off
2 halted
3 triple fault (amd64 only)
4 exited due to an error

EXAMPLES
If not using a boot ROM, the guest operating system must have been
loaded with bhyveload(8) or a similar boot loader before bhyve(4) can
be run. Otherwise, the boot loader is not needed.

To run a virtual machine with 1GB of memory, two virtual CPUs, a virtio
block device backed by the /my/image filesystem image, and a serial
port for the console:

bhyve -c 2 -s 0,hostbridge -s 1,lpc -s 2,virtio-blk,/my/image \
-l com1,stdio -H -P -m 1G vm1

To do the same on arm64:

bhyve -c 2 -s 0,hostbridge -s 1,virtio-blk,/my/image -o console=stdio \
-o bootrom=/usr/local/share/u-boot/u-boot-bhyve-arm64/u-boot.bin -m
1G vm1

Run a 24GB single-CPU virtual machine with three network ports, one of
which has a MAC address specified:

bhyve -s 0,hostbridge -s 1,lpc -s 2:0,virtio-net,tap0 \
-s 2:1,virtio-net,tap1 \
-s 2:2,virtio-net,tap2,mac=00:be:fa:76:45:00 \
-s 3,virtio-blk,/my/image -l com1,stdio \
-H -P -m 24G bigvm

Run an 8GB quad-CPU virtual machine with 8 AHCI SATA disks, an AHCI AT-
API CD-ROM, a single virtio network port, an AMD hostbridge, and the
console port connected to an nmdm(4) null-modem device.

bhyve -c 4 \
-s 0,amd_hostbridge -s 1,lpc \
-s 1:0,ahci,hd:/images/disk.1,hd:/images/disk.2,\
hd:/images/disk.3,hd:/images/disk.4,\
hd:/images/disk.5,hd:/images/disk.6,\
hd:/images/disk.7,hd:/images/disk.8,\
cd:/images/install.iso \
-s 3,virtio-net,tap0 \
-l com1,/dev/nmdm0A \
-H -P -m 8G

Run a UEFI virtual machine with a display resolution of 800 by 600 pix-
els that can be accessed via VNC at: 0.0.0.0:5900 or via serial console
over TCP at: 127.0.0.1:1234 (unsafe if you expose serial console with-
out protection).

bhyve -c 2 -m 4G -w -H \
-s 0,hostbridge \
-s 3,ahci-cd,/path/to/uefi-OS-install.iso \
-s 4,ahci-hd,disk.img \
-s 5,virtio-net,tap0 \
-s 29,fbuf,tcp=0.0.0.0:5900,w=800,h=600,wait \
-s 30,xhci,tablet \
-s 31,lpc -l com1,tcp=127.0.0.1:1234 \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
uefivm

Run a UEFI virtual machine with a VNC display that is bound to all IPv6
addresses on port 5900 and a serial I/O port bound to TCP port 1234 of
loopback address (unsafe if you expose serial console without protec-
tion).

bhyve -c 2 -m 4G -w -H \
-s 0,hostbridge \
-s 4,ahci-hd,disk.img \
-s 5,virtio-net,tap0 \
-s 29,fbuf,tcp=[::]:5900,w=800,h=600 \
-s 30,xhci,tablet \
-s 31,lpc -l com1,tcp=[::1]:1234 \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
uefivm

Run a UEFI virtual machine with a VARS file to save EFI variables.
Note that bhyve will write guest modifications to the given VARS file.
Be sure to create a per-guest copy of the template VARS file from /usr.

bhyve -c 2 -m 4g -w -H \
-s 0,hostbridge \
-s 31,lpc -l com1,stdio \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd,BHYVE_UEFI_VARS.fd
uefivm

To create a configuration file configfile for a virtual machine, use -o
config.dump=1:

/usr/sbin/bhyve -c 2 -m 256 -H -P \
-s 0:0,hostbridge -s 1:0,virtio-net,tap0 \
-s 2:0,ahci-hd,./vm0.img \
-s 31,lpc -l com1,stdio \
-o config.dump=1 vm0 > configfile

Then use an editor of your choice to remove the line "config.dump=1"
from the newly generated configfile.

To start bhyve using this configuration file, use flag -k:

/usr/sbin/bhyve -k configfile vm0

Run a UEFI virtual machine with four CPUs and two emulated NUMA do-
mains:

bhyve -c 4 -w -H \
-s 0,hostbridge \
-s 4,ahci-hd,disk.img \
-s 31,lpc -l com1,stdio \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
-n id=0,size=4G,cpus=0-1 \
-n id=1,size=4G,cpus=2-3 \
numavm

Assuming a host machine with two NUMA domains, run a UEFI virtual ma-
chine with four CPUs using a prefer domainset(9) policy to allocate
guest memory from the first host NUMA domain only.

bhyve -c 2 -w -H \
-s 0,hostbridge \
-s 4,ahci-hd,disk.img \
-s 31,lpc -l com1,stdio \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
-n id=0,size=4G,cpus=0-1,domain_policy=prefer:0 \
numavm

SEE ALSO
bhyve(4), netgraph(4), ng_socket(4), nmdm(4), vmm(4), bhyve_config(5),
ethers(5), bhyvectl(8), bhyveload(8), domainset(9)

Intel, 64 and IA-32 Architectures Software Developers Manual, Volume 3.

HISTORY
bhyve first appeared in FreeBSD 10.0.

AUTHORS
Neel Natu <neel@freebsd.org>
Peter Grehan <grehan@freebsd.org>

FreeBSD 15.0 October 28, 2025 BHYVE(8)

Want to link to this manual page? Use this URL:
<https://man.freebsd.org/cgi/man.cgi?query=bhyve&manpath=FreeBSD+15.0-RELEASE+and+Ports>

home | help

Header And Logo

Peripheral Links

Site Navigation

FreeBSD Manual Pages

Header And Logo

Peripheral Links

Search

Site Navigation

FreeBSD Manual Pages