automatically provisioning a bhyve test VM
asomers at freebsd.org
Mon Mar 12 20:57:36 UTC 2018
On Mon, Mar 12, 2018 at 9:43 AM, Mark Johnston <markj at freebsd.org> wrote:
> 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
> 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.
More information about the freebsd-testing