automatically provisioning a bhyve test VM

[Mark Johnston]

On Mon, Mar 12, 2018 at 02:57:32PM -0600, Alan Somers wrote:
> 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.

Is there an easy way to programmatically run commands over that serial
port from the host?

> 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.

I'd thought a bit about this, but there's also a discoverability problem
in that I'd need a way for the host to figure out the guest's link-local
address without talking to the guest. The serial port might let me work
around this though.