Slowly comprehending [spectrum-os](https://spectrum-os.org) and [microvm.nix](https://github.com/microvm-nix/microvm.nix), by reproducing bits and pieces using [NixOS](https://nixos.org) and [cloud-hypervisor](https://github.com/cloud-hypervisor/cloud-hypervisor).
- Google ChromeOS and [AWS Firecracker](https://firecracker-microvm.github.io):
- rust-vmm, [crosvm](https://crosvm.dev/book), and [sommelier](https://chromium.googlesource.com/chromiumos/platform2/+/master/vm_tools/sommelier);
- [Asahi muvm](https://github.com/AsahiLinux/muvm): microvms using [libkrun](https://github.com/containers/libkrun) and virtio-gpu "native context".
- [AppVM](https://github.com/jollheef/appvm): apparently available in Nixpkgs under `nixos/modules/virtualisation/appvm.nix`. Based on (NixOS,) qemu and libvirt.
- Via [spectrum-discuss](https://spectrum-os.org/lists/archives/spectrum-discuss/CAG4opy8BZn2pXDRBHOjcENFBHJON1LoG7A8GPdP0Wt_3KLaHyw@mail.gmail.com/), [qubes-lite, and `wayland-proxy-virtwl`](https://roscidus.com/blog/blog/2021/03/07/qubes-lite-with-kvm-and-wayland).
- [Astro](https://spaceboyz.net/~astro/):
- Via [microvm.nix](https://github.com/microvm-nix/microvm.nix)
- [Jean-Philippe](https://github.com/jpouellet):
- Via [Nixpkgs](https://github.com/NixOS/Nixpkgs), [Qubes](https://doc.qubes-os.org/en/latest/developer/general/devel-books.html), and [Genode](https://genode.org/about/challenges).
- Via [Qubes](https://doc.qubes-os.org/en/latest/developer/general/devel-books.html) [OS](https://theinvisiblethings.blogspot.com/2012/09/how-is-qubes-os-different-from.html).
- ...
### Timeline
The following are the questions I'd like to eventually answer about how virtualization happened:
- [ ] Was Qubes the first attempt at isolating e.g. peripheral and network devices using virtualization?
- [ ] Was Chromium OS the first and (or) the main driver for paravirtualized devices?
- [ ] ...
### Choices
The following are some of the current "am I holding this right?" questions:
- [ ] Memory: it is said that Linux always needs some swap in order not to be weird;
what is the general scheme for allocating memory and swap to the hypervisor and the guests?
> Most of the day I'm using a laptop with 8GiB of RAM; this necessitates frequent OOMs,
> even when not running VMs.
- [x] It seems that hotplug memory is generaly preferred to ballooning.
- [x] It seems that we want the hotplug "banks" to not be too small,
as to avoid fragmentation.
- [ ] Zswap or zram on the hypervisor? On the guest?
- [ ] How much swap to allocate on the hypervisor? On the guest?
- [ ] Startup time: [lightvm](https://dl.acm.org/doi/10.1145/3132747.3132763) claims boot time of 2.3ms;
can we ever achieve comparable numbers with NixOS and systemd? What is the first bottleneck?
- [ ] Guest-to-guest communication: in order to implement configurations similar to Whonix (e.g. Tor in a separate VM),
guests need to be able to talk to each other directly, without exposing the hypervisor to their traffic.
Generally, I've heard of three solutions to guest-to-guest communication:
When using `microvm.nix` you write, for example, each TAP's `hwaddr` by hand, and then rebuild the "runner script".
When using the "fully-declarative mode" you also engangle the guest's and the hypervisor's life cycles, and double the NixOS evaluation time.
Microvm-nix ships support for a wide selection of different hypervisors, but you may only care about e.g. `cloud-hypervisor`.
An instructive reference implementation and a convenient entry point, `microvm.nix` may not be a direct or complete answer to the question "what does a life cycle of a microvm-deployed service look like".
#### appvm
I only noticed the option in `man configuration.nix` a few days ago,
so I just never tried. Long-term I'd definitely prefer not to use qemu.