I believe some people did use this, but I had intermittent problems getting it to work reliably.
It has now been re-implemented as a single "migrate" command using ssh.
A guest can now be transferred completely from the source host using a single command.
See the man page for more details
vm migrate -s guest-name new-host
Ideally passwordless key-auth should be used, although not strictly necessary.
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).
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
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.
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.
*Show tmux in console-ports info output
*Look for an available port for recv operation
The recieve command will output the port it is waiting on.
Send should be run as "vm send guestname remotehost:port"
If you have a directory (or network mount) containing iso files, you
can configure vm-bhyve to look there by adding it as
a media datastore. (vm datastore iso my-media /path/to/iso/dir).
Also we now look in the current dir for iso files, and accept full paths.
So far we only have a "console" setting, but there may be more
in the future. This change provides 'vm get' & 'vm set' commands,
that can view or change these config settings.
This is supported when using tmux for the guest console.
The guest is started on a tmux session, but the session is not
detached so you are immediately placed inside the guest. Similar to
foreground mode, but you can leave the guest running and return to host
using the tmux detach keys (Ctrl+b d)
I already do pretty much everything they advise anyway
Grouping functions together by using "prefix::" is quite a nice feature though.
Nothing too clever, just makes use of the fact that a colon appears
to be a valid character in a shell function.
Makes sense to display obvious error if host doesn't support bhyve
Also, apparently only FreeBSD guests work on Intel without unrestricted guest, so
display an error if any other guests are started, and limit to 1 vcpu
Gotta keep up with the competition... :)
Reduce main version number to maj.min
Add a seperate integer build number that is MNNRRR (M = Major, N = Minor, R = Revision)
We may write this int to .config directory in future versions (poss even 1.0-rel) and
use this to perform automated upgrades when there are changes required between versions.
This lists PCI devices and shows the B/S/F string to add
to /boot/loader.conf. It also detects if a device has been
picked up by the ppt driver, at which point it should be available
for bhyve.
The first available option is "-d /path", which allows you to specify
a different directory than $vm_dir from /etc/rc.conf.
E.g: vm -d /path start myvm
We now have snapshot and rollback commands for ZFS. See the man page for
details. Also, there's a new 'debug' configuration option for guests, that
writes the STDOUT & STDERR of the bhyve process to $vm_dir/guest/bhyve.log.
This allows you to see any error output from bhyve itself if a guest fails
when run using the normal 'vm start guest' command.
Add some (admittedly php style) comments to each function to explain what they
do, arguments, and what they output. Useful for anyone who's trying to figure
out how things work and why certain things are done.
There are now separate functions which handle base devices, disks & networking
I've also added a new function which adds ppt devices to the bhyve command.
Any modifications can now be made by altering these functions or adding new ones,
rather than making __vm_run more and more extensive.
I've also cleaned up any remaining tab->space issues
Replace spaces with tabs
Change __nat_init function name to match other functions in the switch library
Completely rewrite guest support, making vm-core logic much cleaner
Guests are now supported via the lib/vm-guest library
Each guest has a function which unifies the install/run logic in once place rather than two.
Loaders now run in the background; Not 100% ideal in some cases but better for most.
This also fixes the small tap0 issue which will now only present itself if you start a guest
with no networking
All guests need more testing with these changes but should be functional.
