Compartmentalizing services in an infrastructure landscape allows us to
conduct maintenance individually and without affecting unrelated
MicroVMs. The microvm command helps with that.
You can specify this MicroVM's source flake with -f. If omitted, the
tool will assume git+file:///etc/nixos. The source flakeref will be
kept in /var/lib/microvms/*/flake for future updating the MicroVM.
microvm -f git+https://... -c my-microvmExtension of the host's systemd units must happen declaratively in the host's NixOS configuration:
microvm.autostart = [
"myvm1"
"myvm2"
"myvm3"
];Updating does not refresh your packages but simply rebuilds the
MicroVM. Use nix flake update to get new package versions.
microvm -u my-microvmUntil ways have been found to safely transfer the profile into the target /nix/store, and subsequently activate it, you must restart the MicroVM for the update to take effect.
Use the -R flag to automatically restart if an update was built.
Listing your MicroVMs is as trivial as ls -1 /var/lib/microvms
For more insight, the following command will read the current system version of all MicroVMs and compare them to what the corresponding flake evaluates. It is therefore quite slow to run, yet very useful for an updatable VM overview.
microvm -lIf you want a faster overview of booted and current versions, run this instead:
ls -l /var/lib/microvms/*/{current,booted}/share/microvm/systemFirst, stop the MicroVM:
systemctl stop microvm@$NAMEIf you don't use absolute filesystem paths for sockets, volumes, or
shares, all MicroVM state is kept under /var/lib/microvms/$NAME/.
The microvm@.serivce systemd service template depends on existence
of this directory.
rm -rf /var/lib/microvms/$NAME