Date: Mon, 12 Mar 2018 17:33:19 -0400 From: Mark Johnston <markj@freebsd.org> To: Alan Somers <asomers@freebsd.org> Cc: "freebsd-testing@freebsd.org" <freebsd-testing@freebsd.org> Subject: Re: automatically provisioning a bhyve test VM Message-ID: <20180312213319.GB97195@raichu> In-Reply-To: <CAOtMX2g_WB%2BKtnXuDbnJpSAEsN1ZHoKUGr7CQvm-X=hxohLqbA@mail.gmail.com> References: <20180312154346.GA97195@raichu> <CAOtMX2g_WB%2BKtnXuDbnJpSAEsN1ZHoKUGr7CQvm-X=hxohLqbA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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? > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180312213319.GB97195>