thisago's blog

Persistent DVM makes no sense

I was previously planning to setup a fine-grained persistence in DVM, but after some research, I understood that it's not a good idea.

I still didn't migrated my Chezmoi setup to a Guix system, but I feel that QubesOS as-is won't bring me the best flow for managing a system with Guix.

On the Qubes side, the TemplateVMs provide a simple and effective inheritance system for reducing overhead. But on the Guix side, it's IaC.

Instead a generic TemplateVM with just Guix and Nix, I am considering the following options:

Continue using Guix in foreign distro, but instead setupping it separately for each AppVM, do it in TemplateVM

Pros:

  • Close to intended QubesOS flow.
  • Reduce configuration duplication.
  • Single Source of Truth, guix pull and package updates spread across VMs.
  • Lowest overhead to create/renew AppVMs.

Cons:

  • Extra manual tweaking on the TemplateVM on every edit. A little more frequent with a Guix system setup.
  • guix shell called from AppVM won't persist the packages. This is bad for a Guix/Nix flow, but expected when using a regular system package manager in AppVM (dnf, apt, …).
  • Guix Home might not work as intended. TemplateVM is not meant to manage AppVM home after it gets created.

Neutral:

  • Will require proxy for Git and Guix in the Template. Currently I'm doing it wrong, by connecting the whole VM in the network.
  • Full IaC will require SaltStack. Not a issue because this is inevitable in QubesOS.
Setup a Guix OS from scratch via Guix

Pros:

  • Ideal Guix flow.
  • Fully configured as IaC.
  • Nice to dive into Guix, reaching a more competent level.

Cons:

  • Loses a killer feature of QubesOS: TemplateVMs.
  • Reduces the ease of re-generating a VM because the setup time. Less painful if with a local Guix substitute server.
  • More friction to adapt. Time is short and workspace setup shouldn't eat all the time intended to be using for achieving the goals.
Leave Guix and stick with original QubesOS flow (system package manager in TemplateVM)

Pros:

  • Easier and faster.
  • Less storage needed.

Cons:

  • Less reproducibility.
  • Loses Guix features as sharing packages between systems and built images.
  • Leads to the problem of having multiple package managers, one for each subsystem. Mirrors is harder to maintain.
Continue without changes, keeping all Guix setup in AppVM private storage

Pros:

  • No friction and extra time needed. That's how I do now.
  • guix shell calls in AppVM persists.

Cons:

  • Needed storage for AppVM increases considerably.
  • TemplateVMs gets almost unused.
  • Medium overhead when creating new AppVMs. The packages should be installed (or when having Guix system, it should be applied).

Netural:

  • Also requires proxy for Git and Guix in TemplateVM

Maybe I am missing some points: