Integrate microvm.nix guests

README.md

@@ -132,6 +132,8 @@ source by.
 | `disko` | `disko` | a standalone disk layout, written as disko reads it and published as the `diskoConfigurations.<name>` that disko's command formats and mounts; a machine that carries its layout, as `disko-install` and disko's image builder expect, is a NixOS configuration that selects caisson's `disko` NixOS module |
 | `caisson-facter` | none | the hardware of a machine, a nixos-facter report checked against the report versions caisson knows and extended with a project's options, with the NixOS configurations that run on it declared inside it; a machine gets the report through nixpkgs' `hardware.facter` |
 | `facter` | none | a `facter.json` as nixos-facter writes it, with the NixOS configurations that run on it declared inside it; a machine gets it as `hardware.facter.reportPath` |
+| `caisson-microvm` | `microvm` | microvm.nix guests that share their hypervisor, CPUs, memory, interfaces and shares, declared inside the NixOS host that runs them, each guest a NixOS configuration declared inside it, with pools of slots that differ in their vsock CID and shares; the host selects caisson's `microvm-host` NixOS module to run them; the microvm integration we recommend for new configurations |
+| `microvm` | `microvm` | a microvm.nix guest written as microvm.nix reads it, a NixOS configuration that sets its `microvm.*` options itself, declared inside the NixOS host that runs it; for porting an existing guest |
 | `treefmt` | `treefmt-nix` | the formatters of a tree, as treefmt-nix modules; the configuration named `default` is published as the `formatter.<system>` that `nix fmt` runs |
 | `nvf` | `nvf` | a Neovim written as nvf modules, published as `nvfConfigurations.<system>.<name>`, in the shape `neovimConfiguration` returns, kept in a separate Nix profile that the machine, home-manager configuration or hjem configuration it is declared inside activates |
 | `nixvim` | `nixvim` | a Neovim written as nixvim modules, published as `nixvimConfigurations.<system>.<name>`, kept in a profile as an nvf configuration is |

docs/development/repository-structure.md

@@ -27,14 +27,15 @@ without nixpkgs can depend on it directly.
 The layer users reach for: the integrations (`structural`,
 `flake-parts`, `nixpkgs`, `nixos`, `nixos-minimal`, `home-manager`,
 `home-manager-minimal`, `darwin`, `hjem`, `caisson-colmena`, `colmena`,
-`caisson-disko`, `disko`, `caisson-facter`, `facter`, `terranix`,
-`system-manager`, `treefmt`, `nvf`, `nixvim`, `topology`, `kubenix`,
-`nixidy`), each
+`caisson-disko`, `disko`, `caisson-facter`, `facter`,
+`caisson-microvm`, `microvm`, `terranix`, `system-manager`, `treefmt`,
+`nvf`, `nixvim`, `topology`, `kubenix`, `nixidy`), each
 a library overlay
 contributing its `lib.caisson` namespace, registering its module
 class where it has a class (`nixos-minimal` and `home-manager-minimal`
 each evaluate a class another integration
-owns and carry constructors only), and taking its ecosystem as an `ecosystemSrc` argument
+owns and carry constructors only, and `microvm` evaluates the `nixos`
+class as configurations of its own type), and taking its ecosystem as an `ecosystemSrc` argument
 resolved from the declarations of the mkLib call that composes it
 (including flake-parts: the integration calls the consumer's flake-parts source
 with the composed library as its `nixpkgs-lib`, and carries the
@@ -52,7 +53,7 @@ inject the same names beside `self`.
 ## The pinned world
 
 The upstream world caisson is tested against (nixpkgs, home-manager,
-colmena, disko, nix-darwin, hjem, terranix, system-manager, and the test
+colmena, disko, nix-darwin, hjem, terranix, system-manager, microvm.nix, and the test
 tooling) is pinned in
 `tests/dependencies/flake.lock`, a lock only the checks and formatter
 partitions read, so caisson's `flake.nix` carries no churning pin. The