KVM / libvirt

Idealistically, the introduction declared a “No Sworkstations” rule (No Server-Workstations). Pragmatically, you can bend this rule a bit, by hosting some development servers inside of virtual machines (VM). Hosting VMs on your workstation is convenient for having a portable lab environment. By using virtual machines for all services, we get to maintain our core distinction between the roles of workstation and server.

This paradigm is considerably more adhoc than a proper hypervisor operating system like Proxmox. For pure server installs, Proxmox should be preferred. But if you want to have a mixed-mode native workstation, with extra server VMs, in the same portable platform, this setup works really well.

Using this config, your workstation will stay relatively pure, because these VMs are isolated from your normal account. They are automatically started on boot, running under a dedicated VM user account (libvirt-admin). You can treat these VMs just like any other remote Linux host. From your normal workstation account, you can access the VM’s root shell, over (local) SSH connection, and you can remotely install Docker on these target VMs.

These instructions will cover installing libvirt, and creating a barebones Debian or Fedora VM (but any cloud-init image should work), inside of a private host-only network (No public ports are open by default, but outgoing internet access is allowed). This is mainly for local development/testing purposes only, but near the end of this chapter, you’ll get to decide if you’d like to bend this rule too, and open the VMs up to public (LAN) routes for production-lite roles.