Date: Sat, 24 Feb 2024 14:47:52 -0700 From: John Nielsen <lists@jnielsen.net> To: Jo Durchholz <jo@durchholz.org> Cc: freebsd-virtualization@freebsd.org Subject: Re: Best way to have a FreeBSD VM for automated testing? Message-ID: <C5794819-BFE0-4D85-AA5A-00D5988C8B9C@jnielsen.net>
next in thread | raw e-mail | index | archive | help
=EF=BB=BF
>=20
> On Feb 23, 2024, at 12:17=E2=80=AFPM, Jo Durchholz <jo@durchholz.org> wrot=
e:
>=20
> I'm in repeatable build land, working in Linux and developing a FreeBSD ap=
pliance.
>=20
> For tests, I need to run a FreeBSD VM, put some Python code and test data i=
nto it, run the script, and get the test results back.
>=20
> Repeatability means: Everything done with the VM needs to be scriptable (u=
sing 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.
>=20
> So my question is:
> What's the FreeBSD image that has the least number of steps to get the bas=
e system up and running? I suppose it's the VM-IMAGES section, but is this c=
orrect?
>=20
> Follow-up question:
> The startup time needs to be as fast as possible. Sub-second would be grea=
t ("don't disrupt the developer's thought stream").
> I see the boot process from a vanilla VM-IMAGES image takes multiple secon=
ds; 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=E2=80=99s presentation on Firecracker and reducing boot times.=
If fast boot is your primary requirement then for sure pursue that as other=
s have suggested. I wanted to mention two alternatives that might require le=
ss lift up front:
1) AWS EC2 + cloud-init. The FreeBSD Project publishes AMIs for every releas=
e (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 t=
o 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 Py=
thon code to be run, run it, and upload the results to S3 all non-interactiv=
ely.
With a couple hours=E2=80=99 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 i=
nfrastructure as code templates and tweak the variables to get an easily rep=
eatable 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 i=
mage to do your custom script(s) at startup (though the image may also have c=
loud-init if your environment supports it) but qcow does support snapshots a=
s well and the whole thing should have low boot times.
JN
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C5794819-BFE0-4D85-AA5A-00D5988C8B9C>