config.sample

# This is a sample configuration file containing all supported options
# Please do not try and use this 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"
# The only exception to this is that only one disk device is supported
# in templates. If additional disks are required, they will need to be
# added once the guest has been created.
#
# 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.

# guest
# The type of operating system this virtual machine will use.
# Different systems often require specific steps to load the
# virtual machine, or specific bhyve options. The generic option
# does no specific loading and can be used for standard uefi guests.
#
# This is no longer a required option and will default to 'generic'
# if not specified. If set to freebsd, the bhyveload loader is 
# automatically used, and if set to linux, grub-bhyve will be used.
#
# Default: generic
# Valid Options: freebsd,linux,windows,generic
#
guest=""

# loader
# If the guest you are using requires either bhyveload or grub-bhyve,
# specify the loader to use here. If the guest is freebsd or linux,
# this is not required as the correct loader is used by default.
#
# If using guests such as netbsd, you can either set the guest to
# linux, or set to generic and specify the grub loader here
#
# Valid Options: bhyveload,grub
#
loader=""

# loader_timeout
# By default 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
# Tells bhyve that it should load the UEFI firmware. To use UEFI
# this can be any value other than [empty]/off/false/no/0. If
# it contains the string 'csm', the UEFI BIOS compatability (CSM)
# firmware will be used
#
# Default: no
#
uefi=""

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

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

# 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=""

# 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
# Set to any value other than [empty]/no/off/false/0 if you want the guest
# clock to use UTC time.
#
# Default: no
#
utctime=""

# 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=""

# 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
#
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.
#
# Default: file
# Valid Options: file,zvol,sparse-zvol,custom
#
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'
#
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.
#
# 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="50"

# 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
#
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_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=""

# 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"
#
# 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=""

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

# 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=""

# 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=""