automatically provisioning a bhyve test VM

[Alan Somers]

On Mon, Mar 12, 2018 at 3:33 PM, Mark Johnston <markj at freebsd.org> wrote:

> 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@
> 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?
>

Um, you could try expect?


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

That's what mDNS is for.  Or, since there won't be any unexpected
neighbors, you could simply assign link-local addresses statically.  Nobody
ever said that a link local address _must_ be automatically generated.

-Alan