The "vm" script is responsible for executing shell script
functions found in other vm-bhyve scripts. It does this by
sourcing other vm-bhyve shell scripts, which automatically
execute code that handles the user's input.
One of the first actions "vm" takes is to check if the relative
file "./lib/vm-core" exists. If this file exists, it sets
the parent directory for sourcing scripts to "./lib",
resulting in all shell scripts being sourced from a path
relative to the user's current working directory.
This is unsafe because sourcing from a relative file path
may result in execution of untrusted code.
For example, imagine the user cloned a git repository that
contains malicious code stored at "<git-dir>/lib/". If the
user were to "cd" to this imaginary cloned repository and
execute the "vm" script, they would inadvertently source and
execute code from that directory.
This commit removes this behavior. The "vm" script now
sources scripts exclusively from "/usr/local/lib/vm-bhyve/".
This makes it much easier to switch between versions or modify functionality
just by switching the library files. Very useful for development and also means
the version displayed by "vm version" is linked to the lib files being used, which
is far more appropriate than just the version of the vm executable you have in PATH.
To reduce code we originally parsed some options globally, such as "vm -f start ...".
However this was confusing and inconsistent, especially in relation to other commands
such as zfs(8).
Dataset is only of use if running on ZFS, but in that case it is very
useful if the script wants to create snapshots/etc, and the path can
be retrieved from pwd/cwd if needed.
It's actually far easier and less error-prone to create a standard or manual
switch, then configure whichever NAT service the user wants to use manually.
It's now possible to run commands such as "vm l" or "vm conf <guest>"
Also named console ports allows us to not bother trying to find the next nmdm number
Think adding this to `vm list` adds too much complexity when the zfs commands
do a much better job. Having this in info output as commented is a nice idea though.
Use the -f option to force commands such as reset/destroy/poweroff.
Unfortunately this same option is used for foreground mode when running a vm,
but -f ties up with the force option for many other commands.
Create new "generalise" function specifically to remove any fixed configuration
from a guest. This can then be used in any situation where a guest may be copied.
Tested with clone and both uuid & mac are removed. (Note this just removes settings, based
on the fact that these will be generated on next boot)
New options to 'vm switch create' to allow an ip and/or mtu to
be assigned to standard/vxlan switches. Also standard,vxlan &
custom switches can be set as private so no guest interfaces can
communicate.
We already had 3 types of switch (although you could only test vale manually),
with fairly ugly code to handle the differences. Now that a fourth has been added,
split each type into their own 'module'. This adds test vxlan support which can
create arbitrary virtual L2 networks by tunneling traffic over UDP L3.
I don't want to fully rely on these checks as it could stop us from running
on a system that actually supports bhyve. If the system doesn't support bhyve,
and doesn't have dmesg.boot, then bhyve will just fail to run.
