bhyve(8)

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

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

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) host NUMA memory allocation policy for an emulated domain. See the -n flag in cpuset(1) 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) 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).

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.

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

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

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) or a similar boot loader before bhyve(4) 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) 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) 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), 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 Developer's Manual, Volume 3.

HISTORY

bhyve first appeared in FreeBSD 10.0.

AUTHORS

Neel Natu ⟨[email protected]⟩ Peter Grehan ⟨[email protected]⟩