---
name: "bhyve"
section: "8"
platform: "freebsd"
package: "base"
version: "16.0-CURRENT-20261027-61c70dc16a79"
release: "FreeBSD 16.0-CURRENT (2026-10-27)"
platforms: ["freebsd"]
url: "https://new.carta.tech/bhyve"
---

# bhyve(8)

run a guest operating system inside a virtual machine

## NAME

**bhyve** – run a guest operating system inside a virtual machine

## SYNOPSIS

**bhyve** \[**-aCDeHhMNPSuWwxY**\]\[ **-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** *vcpuN*\[-*vcpuM*\]**:***hostcpuN*\[-*hostcpuM*\]\] \[**-r** *file*\] \[**-s**  *slot***,***emulation*\[**,***conf*\]\] \[**-U** *uuid*\] *vmname*

**bhyve** **-l** **help**

**bhyve** **-o** **help**

**bhyve** **-s** **help**

## DESCRIPTION

**bhyve** is a hypervisor that runs guest operating systems inside a virtual 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 operating system. On arm64 platforms, this is currently required. If not using a boot ROM, the guest operating system must be loaded with [bhyveload(8)](/bhyveload/8.md) 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 provides a U-Boot image that can be used to boot the guest.

**bhyve** runs until the guest operating system reboots (if ‘monitor’ mode is not enabled) or halts, or an unhandled hypervisor exit is detected.

Generally **bhyve** must be run by the super-user, but users belonging to the *vmm* group can create and run virtual machines as well. See [vmm(4)](/vmm/4.md). When run by an unprivileged user, **bhyve** must have access to any required resources such as disk images or network devices. PCI passthrough cannot be used by unprivileged users.

## 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)](/sysctl/8.md) variable. The limit can be adjusted 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 purposes 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 attached to the debug server at a time. If the option begins with **w**, **bhyve** will pause execution at the first instruction waiting for a debugger to attach.

- **-H**

  Yield the virtual CPU thread when a HLT instruction is detected. 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)](/bhyve_config/5.md) for more details.

- **-K** *layout*

  Specify the keyboard layout. The value that can be specified 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 Extended 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 configured. 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 device **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)](/bhyveload/8.md).

  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 suffix is given, the value is assumed to be in megabytes. The default is 256M.

- **-M**

  Run the VM in ‘monitor’ mode. In this mode, a guest reboot does not cause the bhyve process to exit. Instead, bhyve will restart the VM. Once the bhyve process exits or is killed, the VM will be destroyed automatically.

- **-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 encoded in an ACPI table visible to the guest operating system. The **-n** option also allows the specification of a [domainset(9)](/domainset/9.md) 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 initialized using [bhyveload(8)](/bhyveload/8.md).

  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 total 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* parameter may be optionally used to configure the [domainset(9)](/domainset/9.md) host NUMA memory allocation policy for an emulated domain. See the *-n* flag in [cpuset(1)](/cpuset/1.md) for a list of valid NUMA memory allocation policies and their formats.

- **-N**

  Prevent monitor mode from automatically rebooting the virtual machine. This option has no effect unless the *monitor.enabled* configuration option is enabled or **-M** was specified.

- **-o** **help**

  Print a list of supported configuration variables.

- **-o** *var***=***value*

  Set the configuration variable *var* to *value*. See [bhyve\_config(5)](/bhyve_config/5.md) for configuration options.

- **-P**

  Force the guest virtual CPU to exit when a PAUSE instruction is detected. This option applies only to the amd64 platform.

- **-p** *vcpuN*\[-*vcpuM*\]**:***hostcpuN*\[-*hostcpuM*\]

  Pin the guest's virtual CPUs starting from *vcpuN* to *vcpuM* to the host CPUs starting from *hostcpuN* to *hostcpuM*. Host CPUs and guest virtual CPUs are numbered starting from 0. The *vcpuM* and *hostcpuM* arguments may be omitted.

- **-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 configuration 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 available 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 specified, 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)](/bhyveload/8.md).

## 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 systems.

- **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 fw\_cfg 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 controller.

- **nvme**

  NVM Express (NVMe) controller.

- **hda**

  High Definition Audio Controller.

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

### Network device backends

- **tap***N* \[**,mac=***xx:xx:xx:xx:xx:xx*\] \[**,mtu=***N*\]

- **vmnet***N* \[**,mac=***xx:xx:xx:xx:xx:xx*\] \[**,mtu=***N*\]

- **ngd***N*

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

- **slirp** \[**,open**\] \[**,hostfwd=***proto*:*hostaddr*:*hostport**-**guestaddr*:*guestport*\] \[**,mac=***xx:xx:xx:xx:xx:xx*\] \[**,mtu=***N*\]

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 numbers and the device name. If specified, it must be a unicast MAC address.

The MAC address is an ASCII string in [ethers(5)](/ethers/5.md) format.

A **ngd** device can be used to connect a guest to a [netgraph(4)](/netgraph/4.md) through a [ng\_device(4)](/ng_device/4.md) node. This can be used to run bhyve in a [VNET(9)](/VNET/9.md) jail, and give it access to the host's netgraph, that cannot be reached directly, by exposing the ng\_device through [devfs(8)](/devfs/8.md).

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 specified to set the destination node and corresponding hook. The optional parameters **socket** and **hook** may be used to set the [ng\_socket(4)](/ng_socket/4.md) node name and source hook. The *ADDRESS*, *HOOK*, and *NAME* must comply with [netgraph(4)](/netgraph/4.md) addressing rules.

The **slirp** backend can be used to provide a NATed network to the guest. This backend has limited performance but does not require any network configuration on the host system and can be used by unprivileged users. It depends on the *net/libslirp* port. If the **open** keyword is set, the guest will be able to make outbound network connections, and **bhyve** will transparently handle the necessary address translation. The **hostfwd** option takes a 5-tuple describing how connections from the host are to be forwarded to the guest. Multiple rules can be specified, separated by semicolons. Note that semicolons must be escaped or quoted to prevent the shell from interpreting them. The backend will provide DHCP and DNS service to the guest.

### 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 emulated disk. The physical sector size is optional and is equal to the logical sector size if not explicitly specified.

- **nodelete**

  Disable emulation of guest trim requests via DIOCGDELETE requests.

- bootindex=*index*

  Add the device to the boot order at *index*. A fw\_cfg file is used to specify the boot order. The guest firmware may ignore or doesn't support this fw\_cfg file. In that case, this feature doesn't work as expected.

### SCSI device backends

- \[**target**=\[ID:\]*path*\] \[**,***scsi-device-options*\] \[**,***backend-specific-options*\]

Multiple *target* parameters may be specified, each configuring a different *path* as a distinct SCSI target. If the *target* *ID* is not explicitly configured for a *target*, the *target* will be assigned the next sequential *ID* following the highest *target* *ID* used at that point, or 0 if it is the first target configured. All *target* *ID*s must be unique per instance. The meaning of the *path* argument is specific to each backend:

| | | |
| --- | --- | --- |
| **Backend** | **Path** | **Description** |
| ctl | */dev/cam/ctl*\[*pp*.*vp*\] |  |

The *scsi-device-options* are:

- **backend=***backend*

  The virtio-scsi backend to use. The backend name is case-insensitive. There is currently only one backend "ctl", which is also the default backend.

- bootindex=*index*

  Add the device to the boot order at *index*. A fw\_cfg file is used to specify the boot order. The guest firmware may ignore or not support this fw\_cfg file. In that case, this feature doesn't work as expected.

- ctl\_ringsz=*ringsz*

  The ring size to use for the control queue.

- evt\_ringsz=*ringsz*

  The ring size to use for the event queue.

- req\_ringsz=*ringsz*

  The ring size to use for each I/O request queue.

- num\_queues=*num*

  The number of I/O request queues to use.

- seg\_max=*num*

  The maximum number of segments allowed in a single command.

- thr\_per\_q=*num*

  The number of parallel request processing threads per I/O request queue.

The *backend-specific-options* for the **CTL** backend are:

- **iid=***IID*

  Initiator ID to use when sending requests to **CTL**. 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. The TCP server will immediately close new connections while an existing connection is active. Note that this feature allows unprivileged users to access the guest console, so ensure that access is appropriately 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 **swtpm** utility can be installed from the *sysutils/swtpm* port.

The *tpm-device-options* are:

- **version=***version*

  Version of the TPM device according to the TCG specification. Defaults to **2.0**, which is the only version currently supported.

When using a TPM with UEFI firmware, the boot ROM should be configured with a writable *varfile*.

### 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.

fw\_cfg types:

- *fwcfg*

  The fw\_cfg 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 compatibility reasons, ‘bhyve’ is the default option. When ‘bhyve’ is used, bhyve's fwctl interface is used. It currently reports only the CPU count to the guest firmware. The ‘qemu’ option uses QEMU's fw\_cfg 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 fw\_cfg interface as well.

### Pass-through device backends

- **ppt***N*\[,*passthru-device-options*\]

- *bus***/***slot***/***function* \[,*passthru-device-options*\]

- **pci***bus*:*slot*:*function* \[,*passthru-device-options*\]

Connect to a PCI device on the host either named ppt*N* or at the selector 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.

- bootindex=*index*

  Add the device to the boot order at *index*. A fw\_cfg file is used to specify the boot order. The guest firmware may ignore or doesn't support this fw\_cfg file. In that case, this feature doesn't work as expected.

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

The host device must have been reserved at boot time using the *pptdevs* loader variable as described in [vmm(4)](/vmm/4.md).

### Virtio console device backends

- **port1=***/path/to/port1.sock*\[**,port***N***=***/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** accepts 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 Interface.

### Framebuffer device backends

- \[**rfb=***address*\] \[**,w=***width*\] \[**,h=***height*\] \[**,vga=***vgaconf*\] \[**,wait**\] \[**,password=***password*\]

Configuration options are defined as follows:

- **rfb=***address* (or **tcp=***address*)

  A UNIX domain socket or IP address and a port VNC should listen on. There are three possible formats:

  - \[*IPv4***:**\] *port*

  - **\[***IPv6%zone***\]****:***port*

  - **unix:***my/unix.sock*

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

- **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 (64 KiB 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 capability 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 assume 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 systems that require immediate keyboard input. This can be removed for post-installation use.

- **password=***password*

  This type of authentication is known to be cryptographically weak and is not intended for use on untrusted networks. Many implementations will want to use stronger security, such as running the session over an encrypted channel 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. A value of 1 indicates that the device is a solid state drive, i.e., non-rotational. Default value is 0.

- **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 variables. 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 device model and device model-specific variables. Variables may be set multiple times during this parsing stage with the final value overriding previous values.

Once all of the command line options have been processed, the configuration 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)](/bhyve_config/5.md).

## CONFIGURATION FILE CREATION

The **-k** flag allows one to provide a path to a configuration file holding 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 arguments to an equivalent configuration file in [bhyve\_config(5)](/bhyve_config/5.md) format.

Use **-o** *config.dump=1* to make **bhyve** dump a configuration file representing 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 configuration 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 resolved to physical addresses via the current virtual CPU's active address 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

- 5

  suspended

## EXAMPLES

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

To run a virtual machine with 1 GiB 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 24 GiB 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 8 GiB quad-CPU virtual machine with 8 AHCI SATA disks, an AHCI ATAPI CD-ROM, a single virtio network port, an AMD hostbridge, and the console port connected to an [nmdm(4)](/nmdm/4.md) 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 pixels 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 without 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 protection).

```
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 domains:

```
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 machine with four CPUs using a *prefer* [domainset(9)](/domainset/9.md) 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
```

To run a virtual machine with a single vCPU pinned to host CPU 12:

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

To run a virtual machine with 4 vCPUs pinned to host CPUs 12-15:

```
bhyve -c 4 -s 0,hostbridge -s 1,lpc -s 2,virtio-blk,/my/image \
  -l com1,stdio -H -P -m 1G -p 0-3:12-15 vm1
```

Run a UEFI virtual machine with a TPM device connected to a running **swtpm** instance listening on */var/run/swtpm/tpm*. The *tpmvm\_VARS.fd* file must be a per-guest copy of the firmware VARS template, as described in the UEFI example above:

```
bhyve -c 2 -m 4g -w -H \
  -s 0,hostbridge \
  -s 31,lpc -l com1,stdio \
  -l tpm,swtpm,/var/run/swtpm/tpm \
  -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI_CODE.fd,tpmvm_VARS.fd \
   tpmvm
```

## SEE ALSO

[bhyve(4)](/bhyve/4.md), [netgraph(4)](/netgraph/4.md), [ng\_socket(4)](/ng_socket/4.md), [nmdm(4)](/nmdm/4.md), [vmm(4)](/vmm/4.md), [bhyve\_config(5)](/bhyve_config/5.md), [ethers(5)](/ethers/5.md), [bhyvectl(8)](/bhyvectl/8.md), [bhyveload(8)](/bhyveload/8.md), [domainset(9)](/domainset/9.md)

Intel, *64 and IA-32 Architectures Software Developer's Manual*, Volume 3.

## HISTORY

**bhyve** first appeared in FreeBSD 10.0.

## AUTHORS

Neel Natu ⟨*neel@FreeBSD.org*⟩ Peter Grehan ⟨*grehan@FreeBSD.org*⟩