Scott Worley [Fri, 5 Jun 2026 18:29:27 +0000 (11:29 -0700)]
Put squashfs-label patch overlays in a separate file
The util-linux patch in particular causes a lot of rebuilds / cache
misses (linux kernel, llvm and hence clang, rustc, & ghc, etc.) in the
guest.
If the host is also building large stuff like the kernel locally for
other reasons, this can result in two sets of large, local builds. :(
Users sensitive to this may wish to harmonize the host and guest config
to get back down to one set of large local builds. So we make the
squashfs-label patches easy to also apply to the host, for those that
wish to do so.
Scott Worley [Thu, 22 Jun 2023 22:10:39 +0000 (15:10 -0700)]
New runTest interface fixes useNixStoreImage test
The new runTest interface lets us turn off includeTestScriptReferences,
which lets the useNixStoreImage test pass.
Unfortunately, I then discovered another problem with useNixStoreImage:
It builds a new store image every time the VM starts up! This is
undesirable for two reasons:
1. It significantly delays VM start-up. For network-service-providing
VMs, this is downtime. Longer startup time likely won't trouble
high-availability services with fancy load balancers, health
checks, and rolling restarts, but for unsophisticated use cases
that currently just accept some small amount of downtime during VM
restarts for software updates, using useNixStoreImage means much
longer periods of interrupted service.
2. This wastes disk I/O, building the same image over and over.
This useNixStoreImage design choice was made in order to keep the
guest's Nix store image out of the host's Nix store. This is especially
important for the public Hydra that populates the public binary cache
that's currently hosted on centralized pay-per-byte commercial storage
services -- it doesn't make sense to pay to store and host the Nix store
itself and also many little copies of overlapping pieces of it.
So here in nixos-qemu-vm-isolation, we're happy to pay the cost of
storing the guests' Nix store images in the host's Nix store, because we
really value the faster start-up, and because we don't have the problem
of large storage service bills and no budget to pay them with. :)
Scott Worley [Mon, 20 Dec 2021 02:53:02 +0000 (18:53 -0800)]
21.11: Follow the pathsInNixDB → additionalPaths rename
This rename is unfortunate. We depend here upon this actually being *all
the paths in the Nix DB*. It still *is* all the paths in the Nix DB —
nothing has changed about its implementation — but now it's named after
one use case (adding some additional paths) rather than what it *is*
(all the paths), which makes this usage here read as if it couldn't
possibly work. :(