> 
> On Feb 23, 2024, at 12:17 PM, Jo Durchholz <[email protected]> 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




Reply via email to