Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Virtualization & Containers

This page covers running containerized workloads and full virtual machines on InterGenOS. The two stacks ship with different footprints — the container engines are mirror-only packages you install on demand, while the virtualization stack is included on the image — but the same rule governs both: nothing container- or VM-related runs until you deliberately enable it. That posture is deliberate: security is not first. It is only. The goal is a machine you understand, can modify, and can trust, so a root-privileged daemon never starts on your behalf.

InterGenOS is built from source. The container engines, the virtualization stack, and their runtimes are compiled and signed alongside the rest of the system, verified by pkm before installation against the live package index. See Repository Trust and the Package Manager for how that verification works.

Containers

InterGenOS provides two OCI container engines today: Podman and Docker. Both are open-source (Apache-2.0), and both manage standard OCI images and containers.

Podman

Podman is the daemonless OCI engine. It runs containers without a long-lived background service and supports rootless operation, which fits the system’s least-privilege posture. The Podman package pulls in the supporting runtime stack automatically as dependencies:

  • crun — low-level OCI runtime
  • conmon — container monitor for conmon-managed processes
  • netavark and aardvark-dns — container networking and name resolution
  • fuse-overlayfs — userspace overlay storage driver for rootless containers
  • catatonit — minimal init for container PID 1
  • containers-common — shared configuration for container tools
  • passt — userspace networking

Install it with pkm:

sudo pkm install podman

Once installed, Podman is invoked directly. Because it is daemonless, there is no service to enable before you can run a container.

Docker

Docker ships as a separate, opt-in package. It bundles the Docker engine (dockerd and docker-proxy), the docker CLI, and an init for container PID 1. Docker depends on containerd (its runtime peer) and runc (the low-level OCI runtime), both built and pinned alongside it.

Docker is mirror-only: it is not part of the default desktop image, so it never lands on a system without explicit operator action. Install it with pkm:

sudo pkm install docker

Unlike Podman, Docker uses a root-privileged daemon. To honor the secure-default posture, docker.service and docker.socket ship disabled. The daemon does not start until you opt in:

sudo systemctl enable --now docker.socket

Until you run that, the Docker daemon is not listening and not running. This is a belt-and-suspenders default on top of the mirror-only inclusion: even after install, you make a deliberate choice to start a privileged daemon.

Choosing between Podman and Docker

If you want a daemonless, rootless-capable engine that keeps privilege low by default, use Podman. If your existing tooling or CI expects the Docker daemon and socket, install Docker and enable it explicitly. Both consume and produce standard OCI images, so workflows are portable between them.

Virtual machines

InterGenOS ships a complete KVM-based virtualization stack on the image: it is present in the live ISO and lands with the Extras package group at install, with every daemon disabled — no virtualization process starts until you enable it. Every piece is built from source and verified like the rest of the system:

  • QEMU — the machine emulator and virtualizer (KVM-accelerated on hardware that supports it).
  • libvirt — the virtualization management daemon and API, with its GLib and Python bindings.
  • virt-manager and virt-viewer — the graphical VM manager and the guest console.
  • OVMF (from EDK2) — UEFI firmware for guests, including a Secure-Boot-capable image.
  • swtpm — a software TPM 2.0 for guests, so a VM can do measured boot and TPM2-sealed disk encryption.
  • virtiofsd — the virtio-fs daemon for sharing a host directory into a guest.
  • SeaBIOS — legacy BIOS firmware for guests that need it.

On a system installed without the Extras group, add the stack any time with pkm (virt-manager pulls in QEMU, libvirt, and the firmware pieces as dependencies):

sudo pkm install virt-manager

Because OVMF and swtpm are included, an InterGenOS host can give its guests enforced Secure Boot and an emulated TPM 2.0 — the combination needed to run another InterGenOS instance (or any Secure-Boot OS) with its full trust chain intact. This is the same class of stack InterGenOS is itself assembled in: the OS both hosts VMs and builds itself.

libvirtd and its sockets ship disabled by default — a privileged management daemon is armed only when you choose to. Start it deliberately when you are ready to host VMs:

sudo systemctl enable --now libvirtd.socket

To install InterGenOS as a guest under QEMU/KVM (with OVMF + swtpm for the full boot chain), see Installing in a Virtual Machine. GNOME Boxes is not packaged; virt-manager is the shipped graphical manager.

Defaults and posture

  • Nothing runs uninvited. No container engine is present in the desktop image; the virtualization stack is present but fully inert. You enable exactly what your workload needs.
  • No privileged daemon by default. Podman is daemonless; Docker’s daemon and socket, and libvirt’s daemon and sockets, ship disabled and require an explicit systemctl enable --now.
  • Verified before install. pkm checks signatures against the trusted package index before any container package is placed on disk.
  • No telemetry. The container stack carries no usage reporting off your machine.

Further reading