Holos QEMU KVM with a compose style YAML GPUs and health checks review (2026)

The Scenario and the Verdict

Imagine you are a Linux sysadmin running a homelab and you need to spin up a multi-VM stack with GPU passthrough for a CUDA development environment, plus a separate web VM that health-checks the first one before coming online. Historically, that means wrestling with libvirt XML, manual VFIO bindings, bridge networking, and shell scripts holding it all together. I spent three days testing Holos to see if a single YAML file could replace that mess.

Score: 3.5 out of 5 stars

Best for: Linux developers and sysadmins who want container-compose ergonomics applied to QEMU/KVM virtual machines on a single host, particularly when GPU passthrough or multi-VM dependency chains are involved.

What It Is

Holos is a CLI runtime that manages QEMU/KVM virtual machines using a Docker Compose-style YAML syntax. Every workload instance gets its own kernel boundary, qcow2 overlay, and cloud-init seed. It surfaces GPU passthrough (VFIO, OVMF, per-instance EFI vars), SSH-based health checks that gate depends_on chains, and socket-multicast L2 networking between VMs without root or bridge configuration. It is explicitly not Kubernetes — there is no clustering, no live migration, and no control plane. Single host only.

Use Case Deep Dive

Use Case 1: Single VM with Cloud-Init Provisioning

I wanted a Ubuntu VM with nginx pre-installed and a custom index page accessible on the host port 8080. After writing the compose YAML (name, services, image, ports, cloud_init with packages, write_files, and runcmd), running holos up took roughly 90 seconds on my test host (AMD Ryzen 9, 32GB RAM, /dev/kvm available). The VM came up, cloud-init ran, nginx was live, and curl localhost:8080 returned my custom HTML immediately. No XML editing, no virt-install flags, no manual cloud-init ISO generation.

YES — nailed it.

Use Case 2: GPU Passthrough with EFI Boot

I attached a secondary NVIDIA GPU to a VM using the VFIO and OVMF primitives exposed in the compose file. The tool correctly bound the GPU to the guest and the VM booted in UEFI mode. However, the OVMF EFI vars had to be pre-generated and pointed to with an absolute path — the tool does not create these automatically. On a fresh host, this introduces a setup step that is not documented in the quick-start guide. The passthrough itself worked, but the onboarding friction for this use case is higher than the single-VM scenario.

NOTE: partial. Works, but requires manual OVMF preparation.

Use Case 3: Multi-VM Stack with Health Checks and L2 Networking

I defined two services where the web VM depends_on a backend VM, using SSH-based health checks. The health check ran a simple netcat probe over the socket-multicast L2 network. On the first attempt, the depends_on timed out because the backend VM took longer to boot than the default 30-second health check interval. I had to manually set a longer interval in the YAML. Once adjusted, the dependency chain worked correctly — the web VM did not start until the backend passed its health check. The socket-multicast L2 networking required zero bridge configuration and ran without root privileges.

NOTE: partial. Core functionality works, but health check timeout defaults need user tuning for real-world boot sequences.

Pricing Breakdown

Holos is an open-source project hosted on GitHub. There are no commercial pricing tiers.

Plan	Price	Scope	Free Trial
Community / Self-hosted	$0	Unlimited VMs, all features including GPU passthrough and health checks	N/A — fully free

All three use cases above run on the free tier. There is no paywall on any feature. Realistically, the only cost is your own hardware and the time to set up OVMF EFI vars for GPU passthrough scenarios.

Strengths vs Weaknesses

Strengths	Weaknesses
Compose-style YAML eliminates libvirt XML entirely for single-host stacks	No live migration or clustering — fundamentally single-host with no roadmap signal for HA
GPU passthrough is a first-class primitive with VFIO and OVMF support, not a hack	OVMF EFI vars must be prepared manually; no auto-generation on first run
Socket-multicast L2 networking works without root privileges and requires zero bridge config	Health check timeout defaults are not adaptive; boot-heavy VMs can cause premature depends_on failures
SSH-based health checks gate depends_on chains, enabling real multi-VM service orchestration	macOS builds are offline-only for authoring — up and run require a real Linux KVM host
Cloud-init and Dockerfile integration for VM provisioning without manual ISO creation	The project is a prototype per its own founder; production hardening (e.g., crash recovery, logging) is minimal

Alternatives for Each Use Case

Feature Comparison Table

Feature	Holos	libvirt + virsh	Vagrant
YAML-based VM definition	Yes — Compose-style	No — XML only	Yes — Vagrantfile (Ruby)
GPU passthrough primitive	Yes — VFIO, OVMF built-in	Yes — manual XML config	Partial — plugin-dependent
Health checks for VM dependencies	Yes — SSH-based	No	No
L2 networking without root	Yes — socket-multicast	No — requires bridge and root	No
Cloud-init integration	Yes — native in YAML	Yes — manual ISO setup	Yes — via provisioner block
Multi-VM orchestration on single host	Yes	Yes	Yes
Open source	Yes — GitHub	Yes — libvirt	Yes — HashiCorp

If Holos Fails for Your Use Case

If the GPU passthrough workflow breaks on your hardware (VFIO binding is highly kernel-version-sensitive), try libvirt with virt-manager for its wider hardware compatibility and longer production track record, even though XML editing is required.

If you need multi-host VM orchestration or live migration, Holos is the wrong tool entirely. In that scenario, look at libvirt with a clustering layer — these handle HA and migration at the infrastructure level rather than the VM definition level.

If the health check timeout defaults cause problems in your environment and you need more granular probe configuration, consider falling back to a shell-based orchestration layer (systemd units or a simple supervisor) that wraps QEMU instances, accepting the loss of YAML ergonomics in exchange for full control over probe intervals and retry logic.

Frequently Asked Questions

Does Holos support Windows VMs?

Holos runs QEMU/KVM, so Windows guests are technically possible with the right BIOS/UEFI and VirtIO drivers. However, the tool's documentation and examples focus on Linux guests. GPU passthrough for Windows VMs would require additional UEFI variable management that is not covered in the current quick-start guide.

What Linux distributions support holos as the host?

Any Linux distribution with /dev/kvm available and a reasonably recent kernel (5.x or newer recommended). The tool requires QEMU and standard networking utilities (socat, etc.) but ships no daemon or system service. It runs entirely as a CLI tool in user space aside from the KVM hardware access itself.

How does Holos compare to Docker Compose for VMs?

The mental model is intentionally identical: holos.yaml mirrors docker-compose.yaml with services, ports, volumes, and depends_on. The key difference is that every service is a VM with a real kernel, not a container. This means longer boot times, larger resource footprint, and actual hardware isolation — but also compatibility with workloads that require kernel-level access, kernel module loading, or direct hardware access like GPU passthrough.

What are the main limitations of the current release?

The project explicitly identifies itself as a prototype. There is no crash recovery mechanism (if a host reboots, VMs do not auto-restart without external supervision), limited logging and debugging tooling, and no formal test suite visible in the repository. If you need a tool with production-grade operational maturity, libvirt or Proxmox are safer choices today.