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