BHYVELOAD(8)

✨ bhyveload(8) — load a FreeBSD guest inside a bhyve virtual machine ✨

okay bestie, welcome to the bhyveload(8) page from the System Manager’s Manual. This is the load-a-FreeBSD-guest-inside-a-bhyve(4)-virtual-machine situation, and yes, it’s giving main character energy. 💖

---

🌸 NAME 🌸

bhyveload — load a FreeBSD guest inside a bhyve(4) virtual machine. No cap, that’s the whole vibe of this icon. 💅

---

⭐ SYNOPSIS ⭐

bhyveload [-C] [-S] [-c cons-dev] [-d disk-path] [-e name=value]
          [-h host-path] [-l os-loader] [-m memsize[K|k|M|m|G|g|T|t]]
          vmname

---

🦋 DESCRIPTION 🦋

So bhyveload is used to load a FreeBSD guest inside a bhyve(4) virtual machine. That’s the assignment. 🫶

bhyveload is based on loader(8) and will present an interface identical to the FreeBSD loader on the user’s terminal. This behavior can be changed by specifying a different OS loader.

The virtual machine is identified as vmname and will be created if it does not already exist. Iconic, honestly.

---

🎀 OPTIONS 🎀

The following options are available, bestie — collect them all: ✨

• -c cons-dev — cons-dev is a tty(4) device to use for bhyveload terminal I/O.

The text string "stdio" is also accepted and selects the use of unbuffered standard I/O. This is the default value. Lowkey the default bestie.

• -d disk-path — The disk-path is the pathname of the guest’s boot disk image.
• -e name=value — Set the FreeBSD loader environment variable name to value.

The option may be used more than once to set more than one environment variable. Environment variable stacking? We love to see it.

• -h host-path — The host-path is the directory at the top of the guest’s boot filesystem.
• -l os-loader — Specify a different OS loader. By default bhyveload will use /boot/userboot.so, which presents a standard FreeBSD loader.
• -m memsize[K|k|M|m|G|g|T|t] — memsize is the amount of memory allocated to the guest.

The memsize 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 respectively.

memsize defaults to 256M. ✨

• -C — Include guest memory in the core file when bhyveload dumps core. This is intended for debugging an OS loader as it allows inspection of the guest memory.
• -S — Wire guest memory.

---

🌈 EXAMPLES 🌈

To create a virtual machine named freebsd-vm that boots off the ISO image /freebsd/release.iso and has 1GB memory allocated to it:

bhyveload -m 1G -d /freebsd/release.iso freebsd-vm

To create a virtual machine named test-vm with 256MB of memory allocated, the guest root filesystem under the host directory /user/images/test and terminal I/O sent to the nmdm(4) device /dev/nmdm1B:

bhyveload -m 256MB -h /usr/images/test -c /dev/nmdm1B test-vm

---

🧚 SEE ALSO 🧚

Go peek at bhyve(4), nmdm(4), vmm(4), bhyve(8), and loader(8) — all the lore is there. 💜

---

👑 HISTORY 👑

bhyveload first appeared in FreeBSD 10.0, and was developed at NetApp Inc. Periodt. 🎀

---

💖 AUTHORS 💖

bhyveload was developed by Neel Natu <neel@FreeBSD.org> at NetApp Inc with a lot of help from Doug Rabson <dfr@FreeBSD.org>. Collab royalty, fr fr. 💅

---

💀 BUGS 💀

bhyveload can only load FreeBSD as a guest. That’s the limit, bestie — no cap.

---

🔥 SECURITY CONSIDERATIONS 🔥

Note that in some configurations, bhyveload will execute guest loader scripts in the context of the host machine. Note, however, that bhyveload will enter a capsicum(4) sandbox before it loads the os-loader or executes any loader scripts. On the host filesystem, the sandbox will only have access to the path specified by the -h flag, the contents of the /boot directory if -l was not specified, and the chosen console device. 🫶

Note that the guest loader scripts are already subject to some limitations that are not relaxed simply because we are running in userland. For instance, any I/O on the loader’s “host” device that can be done in loader scripts is limited to the interface that bhyveload provides, which itself will restrict paths that can be touched to those within a specified -h directory, if any. Access to files within /boot inside the sandbox would require arbitrary code execution in userboot, and userboot is usually provided by the host machine rather than anything that is a part of the guest image. All access to the -h directory as well as /boot is strictly read-only in the sandbox. 💖

---

🎀 That’s the whole page, bestie — brought to you by the Debian flavor of BHYVELOAD(8), dated January 12, 2024. Stay slaying in your bhyve VM! 💖