config.sample

# This is a sample configuration file containing all supported options
# Please do not try and use this file itself for a guest
# For any option that contains a number in the name, such as "network0_type",
# you can add additional devices of that type by creating a new set of
# variables using the next number in sequence, e.g "network1_type"
#
# Please make sure all option names are specified in lowercase and
# at the beginning of the line. If there is any whitespace before
# the option name, the line will be ignored.
# The '#' character signifies the start of a comment, even within
# double-quotes, and so cannot be used inside any values.

# loader
# Specify the loader to use for the guest. This can either be
# one of the original bhyve loaders (bhyveload/grub), or
# you can specify to use uefi firmware to load the guest
#
# Valid Options: bhyveload,grub,uefi,uefi-csm
#
loader=""

# bhyveload_loader
# If using bhyveload, this option can be used to specify the path
# to the loader inside the guest to use
#
# the default is /boot/userboot.so
#
bhyveload_loader=""

# bhyveload_args
# If using bhyveload, this option can be used to pass command line
# arguments to the loader
#
bhyveload_args="-e machdep.hyperthreading_allowed=0"

# loader_timeout
# By default bhyveload & grub-bhyve will wait 3 seconds before booting the default
# option. This setting allows you to either reduce the timeout to
# make boot faster, or increase it so that it's easier to access
# the grub console before it starts booting
#
loader_timeout="3"

# uefi_vars
# set to a true value to support persistent UEFI vars
# this relies on a version of uefi-firmware that comes with the BHYVE_UEFI_VARS.fd template,
# and support in bhyve
#
uefi_vars="no"

# cpu (required)
# specify the number of cpu cores to give to the guest
#
cpu="1"

# cpu_sockets
# manually configure the number of sockets that bhyve should
# expose to the guest.
# note that sockets*cores*threads should equal the above cpu count
#
cpu_sockets="1"

# cpu_cores
# the number of cores to create per physical processor
#
cpu_cores="1"

# cpu_threads
# the number of cpu threads per core
#
cpu_threads="1"

# memory (required)
# specify the amount of ram to give to the guest. This can be
# followed by M or G.
#
memory="512M"

# wired_memory
# All requested memory should be wired to the guest
#
wired_memory="no"

# hostbridge
# Allows you to specify the type of hostbridge to use for the
# guest hardware. This can usually be left as default. The
# additional options are 'amd', for a hostbridge that advertises
# itself as AMD hardware and 'none' for no hostbridge. Note
# that there is no requirement to use the 'amd' hostbridge if
# you host has an AMD processor
#
# Default: standard
# Valid Options: standard,amd,none
#
hostbridge=""

# ignore_bad_msr
# Instruct bhyve to ignore accesses to model specific registers
# that are not implemented in the current CPU.
# This appears to be required for AMD processors when using
# some guest operating systems. Note that this is enabled
# by default when running a UEFI guest
#
ignore_bad_msr="no"

# bhyve_options
# any additional bhyve command line options
#
bhyve_options="-p 1:1"

# comports
# This allows you to define the com ports which should be available.
# By default only com1 is connected, and can be accessed using the
# 'vm console' command. If more than one com port is specified, you
# can choose the port to connect to by running 'vm console guest com1|com2'.
# When using the 'vm console' command, if no com port is specified,
# you are connected to the first port listed in this string.
#
# Default: com1
# Valid Options: com1,com2,com1 com2,com2 com1
#
comports=""

# utctime
# bhyve normally sets the guests RTC to the host's localtime. The utctime
# option causes bhyve to try and configure the guests RTC to UTC.
#
# As of vm-bhyve 1.2, this setting defaults to yes, giving the guest a
# UTC realtime clock. I consider this more consistent, and is actually
# expected by some guests. The guest should show correct time as long as
# its timezone is configured correctly. Note that the following command
# is useful to verify the time of a guest's "hardware" RTC:
# bhyvectl --vm={guestname} --get-rtc-time
#
# To revert to the default bhyve behaviour, explicitly set this to off/no/false/0
#
# Additionally it is generally advised to run a time sync daemon, such as ntpd
# in the guest, as each OS will have its own clock that will inevitably drift.
#
# Default: yes
#
utctime="no"

# debug
# Set to a value other than [empty]/no/off/false/0 to run vm-bhyve in debug mode.
# In this mode, all output from the bhyve process is written to
# $vm_dir/{guest}/bhyve.log. This is useful if the guest is crashing or
# exiting abnormally as the log will contain any output from bhyve.
#
# Default: no
#
debug=""

# uuid
# This is set automatically by vm-bhyve when creating a new guest. Normally
# bhyve assigns a UUID at runtime based on host and guest name. This
# option allows you to specify a fixed UUID that will always be used. Remove
# this or leave blank to return to the normal bhyve behaviour.
#
uuid=""

# ahci_device_limit
# By default all ahci devices (ahci-hd/ahci-cd) are configured on independent
# slots with their own controller. In FreeBSD 12 it's possible to put up
# to 32 devices on each controller. This setting allows you to configure
# the number of devices vm-bhyve will allocate on each controller.
#
# Valid Options: 2-32
# Default: 1
#
ahci_device_limit="8"

# disk0_type (required)
# This specifies the emulation type for disk0. Please note that each disk requires
# at least a type and name.
#
# Valid Options: virtio-blk,ahci-hd,ahci-cd,nvme
#
disk0_type="virtio-blk"

# disk0_dev
# The type of device used as the backing store for this disk. The default is 'file',
# which means a sparse file is used. This file is stored in the guest's directory.
# For the zvol options, the zvol must be directly under the guest dataset.
# There is also a 'custom' option, in which case the disk name should be the full path
# to the file or device you want to use.
# For 'iscsi', the disk name must be set to a unique target and lun combination
# when matched against iscsictl -L output.
#
# Default: file
# Valid Options: file,zvol,sparse-zvol,custom,iscsi
#
disk0_dev=""

# disk0_name (required)
# The name of the file or zvol for this disk. If the device type is 'custom', it should
# be the full path to whichever device or file you want to use
#
# This value is translated to a path as follows, based on disk0_dev
#
# DEVICE TYPE        DISK NAME      BHYVE PATH USED
# file              'disk0.img' -> '$vm_dir/$name/disk0.img'
# zvol|sparse-zvol  'disk0'     -> '/dev/zvol/pool/dataset/path/guest/disk0'
# custom            '/dev/da10' -> '/dev/da10'
# iscsi             'tgt[/lun]' -> '/dev/daNN' (lun defaults to 0 if omitted)
#
disk0_name="disk0.img"

# disk0_opts
# A comma separated list of additional options for the specified disk.
# The available options are listed below. See the bhyve(8) man page for
# more details
#
# Valid Options: direct,nocache,ro,sectorsize=logical[/physical]
#
disk0_opts=""

# disk0_size
# When a new guest is created, vm will create a 20G disk image by
# default. This option can be used to specify a different size
# for this disk. Make sure to include a human readable suffix
# compatible with 'zfs create' (G for gigabytes, T terabytes,
# etc)
#
# The size of the first disk (disk0) can also be overridden
# using the -s option to 'vm create'.
#
# NOTE: This option is only supported in template files. This
# setting serves no purpose in real guests and would become
# misleading if a disk were resized manually. When provisioning
# a new guest, all 'diskX_size' options are stripped from
# its configuration file.
#
disk0_size="50G"

# network0_type
# This specifies the emulation type to use for the first network interface.
# Networking is not required, although this field is mandatory if you do want
# to add an interface
#
# Valid Options: virtio-net,e1000
#
network0_type="virtio-net"

# network0_switch
# The name of the virtual switch to connect this interface to. When starting the
# guest, if this switch cannot be found, or no switch is specified, the interface
# is still created but will not be connected to anything.
#
# All default templates use a switch called 'public', although it's perfectly
# reasonable to use other switch names that make sense in your environment
#
network0_switch="public"

# network0_device
# If you do not want vm-bhyve to create a new interface, but use an existing
# one, enter the interface name here. This allows you to preconfigure the network
# device in a custom configuration, then instruct vm-bhyve to use that rather
# than create all interfaces dynamically at run time.
#
network0_device=""

# network0_name
# if specified, the interface will be given this name
#
network0_name="web1"

# network0_mac
# This allows you to specify a fixed mac address for this interface inside the guest.
# When a guest is run, vm-bhyve will automatically assign a mac address for each
# interface if one is not specified. This mac address is then written to the
# configuration file using this option. If we didn't do this guests might get
# a different mac if the tap device changes (very possible in vm-bhyve as all
# tap devices are dynamic by default). Guests like Windows treat an interface
# with a different mac as a new interface, with a new set of default settings.
#
network0_mac=""

# network0_span
# Set to any value other than [empty]/off/false/no/0 to create the specified
# port as a SPAN port rather than as an ordinary bridge member.
#
# NOTE: Does not work with VALE switches yet.
#
network0_span="no"

# passthru0
# Add a pass-through PCI device to the virtual machine. This allows the guest
# to access a hardware device no differently than if it was running on bare
# metal. The value of this option is the B/S/F of the appropriate device.
# e.g "3/0/0"
#
# The slot to use in bhyve can be specified as below. This example will
# force the host device 6/0/0 to use slot 2:0 in the guest
#
# passthru0="6/0/0=2:0"
#
# Please note that in order to stop the bhyve host from attaching to the device,
# there are some steps required to reserve the device in /boot/loader.conf.
#
# The 'vm passthru' command provides a convinient way of seeing the BSF of each
# device in your system, and whether any have been reserved ready for use
# in bhyve
#
# More details can be found in the FreeBSD bhyve wiki pages
#
passthru0=""

# start_slot
# The slot to start creating devices at inside the guest. Note that
# we create disk devices first, and some UEFI guests require disks to
# be in slots 3-6. The default is 4, with 3 being left available for
# an installation ISO
#
start_slot="4"

# install_slot
# The slot to use for an installation ISO. By default this is 3,
# which is the first available slot with the original UEFI firmware.
# Using this makes sure the ISO is the first device, and leaves
# 4-6 available for hd devices. Being able to change this may
# be useful for non-UEFI guests, especially if a passthru device
# requires this slot.
#
install_slot="3"

# virt_random
# Set to any value other than [empty]/off/false/no/0 to create
# a virtio-rnd device for the guest
#
virt_random=""

# graphics
# Set to a value other than [empty]/off/false/no/0 to enable
# the bhyve frame buffer device. This creates a graphics console
# in the guest, which is accessible using vnc
#
# By default this is set at 800x600, and we find an available vnc
# port starting at 5900. The port can be seen in vm list|info output.
#
graphics="yes"

# graphics_port
# Use this option to specify a fixed network port that the vnc service
# should listen on. If specifying port numbers manually, please make
# sure all guests have a unique port.
#
graphics_port="5999"

# graphics_listen
# By default, the vnc service will listen on 0.0.0.0, so you can connect by
# using any IP address assigned to the bhyve host. Use this option if you
# want to specify a specific IP address that the service should bind to
#
# Default: 0.0.0.0
#
graphics_listen="10.0.0.1"

# graphics_res
# This allows you to specify a resolution for the graphical console.
# Pleas note only the below options are supported
#
# Default: 800x600
# Valid Options: 1920x1200,1920x1080,1600x1200,1600x900,1280x1024,1280x720,1024x768,800x600,640x480
#
graphics_res="800x600"

# graphics_wait
# Set to yes in order to make guest boot wait for the VNC console
# to be opened. This can help when installing operating systems
# that require immediate keyboard input (such as a timed 'enter setup'
# screen). The default setting of auto will add the wait option
# if the guest is run in install mode. Note that in auto mode
# the wait option will only be present on the first boot. If you
# need the guest to wait on every boot during install, the yes
# option should be used.
#
# Valid Options: no,yes,auto
#
graphics_wait="auto"

# graphics_vga
# valid options for this are on/off/io. io is the default
# please see the bhyve man page for details on this option
#
graphics_vga="io"

# xhci_mouse
# When graphics are enabled, a PS2 mouse is created by default. This
# doesn't track very well, and can be replaced with an XHCI mouse
# by setting this option to yes. Please note only some guests support
# this mouse
#
xhci_mouse="yes"

# virt_console0
# create up to 16 virtual console devices
#
# the value can be yes|on|1 to create a numbered port. FreeBSD < 12
# only supports virtio consoles configured in this way
#
# For guests with named console support (FreeBSD 12+, Linux?), the
# value can be the name of the port to create. The name "org.freenas.byhve-agent"
# can be useful as it ties in with tools written to make use of the
# FreeNAS bhyve-agent interface.
#
virt_console0="org.freenas.byhve-agent"

# grub_install0
# use this to specify grub commands that should be run inside the
# guest when installing.
#
# If more than one command is needed, you can specify this option
# multiple times, incrementing the number on the end each time
#
grub_install0="..."
grub_install1="..."

# grub_run0
# use this to specify grub commands to run when starting the guest
# normally
#
grub_run0="linux ..."
grub_run1="initrd ..."

# grub_run_partition
# by default 'hd0,1' is specified as the root when running grub-bhyve.
# to force 'hd0,X' instead, set this to 'X'.
# in most cases the default of partition 1 is correct, although
# this settings allows you to force grub-bhyve to look on a different
# partition if required.
#
grub_run_partition="msdos1"

# grub_run_dir
# by default grub-bhyve will look in /boot/grub for the guests
# grub config file. use this to specify an alterate path
#
# Default: /boot/grub (set by grub-bhyve)
#
grub_run_dir="/grub"

# grub_run_file
# by default grub-bhyve will look for a file called grub.cfg containing
# the guests grub configuration. use this to specify an alternate filename
#
# Default: grub.cfg (set by grub-bhyve)
#
grub_run_file="grub.conf"

# zfs_dataset_opts
# A list of ZFS properties to set on any new dataset created for this
# guest. Multiple properties can be specified, separated by a space.
# As a dataset is created while provisioning a new guest, this option
# makes most sense when specified inside a template.
#
# Please note that spaces are currently not supported in the field values
#
zfs_dataset_opts=""

# zfs_zvol_opts
# A list of ZFS properties to set on any new ZVOL created for this guest.
# As with dataset_opts, this should to be set inside the guest template
# if you need the properties to apply to the guest as it is created.
# Some options such as volblocksize cannot be changed once the guest
# disk has been created.
#
zfs_zvol_opts=""

# prestart
# specify a script to run when the guest starts
# if just a name rather than full path is provided, we look in the guest directory
# the script must be executable and is run in the following way -
#
# {scriptname} <guest-name> [zfs-dataset?]
#
# we also change directory to <guest-path> before running the script
# note that if taking guest snapshots, the -f option must be used as although
# the guest is technically stopped when this script runs, vm-bhyve still has it
# locked
#
prestart="myscript.pl"

# priority
# set a priority (nice value) for a guest
# valid range is -20 (highest) to 20 (only run when system idle), with
# 0 being the default system priority
#
priority="10"

# limit_pcpu
# use rctl to limit guest to the specified cpu percentage
#
limit_pcpu=""

# limit_rbps, limit_wbps, limit_riops, limit_wiops
# Configure additional rctl limits available on 11+
# These limit read/write throughput and iops
#
limit_rbps=""
limit_wbps=""
limit_riops=""
limit_wiops=""