holos Brings Docker‑Compose Style Workflows to KVM/QEMU Virtual Machines

holos is a new open‑source tool that lets you define multi‑VM stacks with a single YAML file, similar to docker‑compose. It runs on Linux hosts with /dev/kvm and creates each workload as a separate QEMU virtual machine, giving every instance its own kernel, qcow2 overlay and cloud‑init seed.

The simplest way to try holos is to run a disposable VM without writing a compose file. Running holos run alpine pulls the Alpine cloud image, boots a VM with one vCPU and 512 MiB of RAM, and prints the exact holos exec and holos down commands you need to interact with it or tear it down.

For a more reusable setup you can write a holos.yaml file. A minimal example defines a service called web that uses the Ubuntu Noble image, forwards host port 8080 to port 80 inside the guest, installs nginx via cloud‑init packages and writes a simple HTML file. After saving the file, holos up starts the VM, curl localhost:8080 returns the message, and holos down cleans up the resources.

holos also supports the familiar compose features such as depends_on, healthchecks, named volumes and replica scaling. A service can declare a healthcheck that runs over SSH; dependent services wait until the check passes before starting. Named volumes are stored as qcow2 files under the project’s state directory and are symlinked into each instance, surviving holos down so data persists across teardowns.

For workloads that need direct hardware access, holos can passthrough PCI devices, including GPUs. When a device is listed under the devices field, the tool automatically enables UEFI (OVMF) and sets kernel-irqchip=on for better NVIDIA compatibility, while each VM gets its own copy of the OVMF_VARS store. Arbitrary QEMU flags can be added via extra_args, letting you tune display or virtio‑gpu settings without holos validating them.

If you already run VMs under libvirt, the holos import command reads domain XML and emits an equivalent holos.yaml. Fields such as vCPU, memory, machine type, CPU model and PCI hostdev are mapped directly; any unsupported elements are reported as warnings so you can adjust them before launching with holos.

Pre‑built binaries for Linux and macOS are attached to every GitHub release; macOS builds allow offline commands like validate or import, while actual VM execution requires a Linux host with KVM. To make a project survive a host reboot, holos install --enable emits a user‑level systemd unit; adding --system creates a host‑wide unit that starts before any user logs in.

holos deliberately avoids solving problems that belong to orchestration platforms. It does not provide multi‑host clustering, live migration, service meshes, overlay networks or a scheduler; the goal is to make KVM usable for single‑host stacks without importing the operational complexity of Kubernetes.

By mirroring the docker‑compose workflow holos lowers the barrier to running isolated VMs for development, testing or edge services. Users get the safety of a separate kernel boundary for each workload while retaining the simplicity of a single YAML file and familiar CLI commands.

You can find the source code and releases at the project’s GitHub page: zeroecco/holos.