automatically provisioning a bhyve test VM

[Alan Somers]

On Mon, Mar 12, 2018 at 9:43 AM, Mark Johnston <markj at freebsd.org> wrote:

> Hi,
>
> I have some tests for FreeBSD's kernel dump code that I'd like to make
> more robust. They use bhyve to test a variety of combinations of kernel
> dump configurations: e.g., full dump vs. minidump, encryption,
> compression, dump device block size, etc.. Each test triggers a kernel
> panic and dump, and upon reboot opens the dump in kgdb, in the VM, to
> get some confidence that the dump is valid.
>
> I use sysutils/vm-bhyve to simplify some aspects of VM management, and
> that works pretty well. I use some hacks to configure networking for the
> VM, and this is the part that I don't like. The tests run on the host
> and use ssh to run commands in the VM. For this to work, I need to
> hardcode an IP for the guest and for the bridge to which the guest's tap
> interface is connected, which of course only works if those IPs aren't
> already somehow in use by the host. I'd prefer something that makes zero
> assumptions about the host and just provides the bare minimum needed to
> establish a private communication channel to run commands on the guest
> (which includes getting the output and exit status of said commands).
> Ideally this would still involve assigning private IPv4 addresses to
> each side since I'd like to expand my test suite to cover netdump, which
> makes it possible for a panicking kernel to transmit a dump to a remote
> host. Does anyone have any suggestions for a more elegant way to go
> about this? Does anyone else automatically provision and tear down bhyve
> VMs as part of a test suite?
> _______________________________________________
> freebsd-testing at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-testing
> To unsubscribe, send any mail to "freebsd-testing-unsubscribe at freebsd.org"
>

Could you use the virtual serial port instead of a virtual network?  That
would eliminate the assumption about a suitable IP address for the guest.
You could also try using an IPv6-only guest with a link-local address.
Thanks to IPv6's scoping rules, this would be guaranteed not to interfere
with any other interface on the host, so long as you don't bridge it.

-Alan