Re: Best way to have a FreeBSD VM for automated testing?


> 
> On Feb 23, 2024, at 12:17 PM, Jo Durchholz <jo@durchholz.org> wrote:
> 
> I'm in repeatable build land, working in Linux and developing a FreeBSD appliance.
> 
> For tests, I need to run a FreeBSD VM, put some Python code and test data into it, run the script, and get the test results back.
> 
> Repeatability means: Everything done with the VM needs to be scriptable (using a GUI for exploring is okay but things have to translate).
> Which in turn means that every setup step for a FreeBSD image comes with a pretty high coding and maintenance cost.
> 
> So my question is:
> What's the FreeBSD image that has the least number of steps to get the base system up and running? I suppose it's the VM-IMAGES section, but is this correct?
> 
> Follow-up question:
> The startup time needs to be as fast as possible. Sub-second would be great ("don't disrupt the developer's thought stream").
> I see the boot process from a vanilla VM-IMAGES image takes multiple seconds; can this be sped up to just a few seconds, or do I need to run the setup and create a VM snapshot at which the VM starts for each test run?

I loved Colin’s presentation on Firecracker and reducing boot times. If fast boot is your primary requirement then for sure pursue that as others have suggested. I wanted to mention two alternatives that might require less lift up front:

1) AWS EC2 + cloud-init. The FreeBSD Project publishes AMIs for every release (again, thanks cperciva). You can launch an EC2 instance from one of those with a few clicks. You can additionally assign an IAM role to the instance to give it permission to write to an S3 bucket and drop a script in the user-data for the instance to run when it boots. The script could download the Python code to be run, run it, and upload the results to S3 all non-interactively.

With a couple hours’ work you could adapt the stock image to add any missing dependencies and disable unneeded drivers and services to speed the boot, then snapshot that and use your custom image for future runs.

You could also easily manage the whole thing with Terraform. Copy/paste the infrastructure as code templates and tweak the variables to get an easily repeatable system.

2) KVM + libvirt on whatever Linux host(s) you have available. The VM-IMAGES released by the Project include qcow volumes. You might need to tweak the image to do your custom script(s) at startup (though the image may also have cloud-init if your environment supports it) but qcow does support snapshots as well and the whole thing should have low boot times.

JN