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-microvm
Extension 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-microvm
Until 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 -l
If you want a faster overview of booted and current versions, run this instead:
ls -l /var/lib/microvms/*/{current,booted}/share/microvm/system
First, stop the MicroVM:
systemctl stop microvm@$NAME
If you don't use absolute filesystem paths for sockets, volumes, or
shares, all MicroVM state is kept under /var/lib/microvms/$NAME/
.
The [email protected]
systemd service template depends on existence
of this directory.
rm -rf /var/lib/microvms/$NAME