Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks(github.com)
20 pointsby zeroecco3 hours ago6 comments
  • frabonacci29 minutes ago
    it reminds me of https://github.com/dockur/windows with its compose-style YAML over QEMU/KVM. The difference i'm seeing is scope: dockur ships curated OS images (Windows/macOS), while holos looks more like a generic single-host VM runner. Is that a fair read? also curious any plans to support running unattended processes for OS installs?
    • zeroecco2 minutes ago
      True and decent read. Holos is a generic runner underneath, and I'm not trying to compete on the curated-OS-image front; the assumption is you bring a cloud image and cloud-init does the rest. Unattended installs for Linux work today through cloud-init (that's most of what the YAML drives). Windows/macOS would need a different path.. autounattend.xml injection for Windows, custom payload for macOS; I haven't built that. If there's interest, a provisioner: type block that picks the right unattend mechanism based on OS isn't crazy, but it's not on the near-term list.
  • spidermonkey232 hours ago
    I like it! is there a way to use both virt-manager and virsh with this or do we have to pick one. I'd be keen to migrate my VMs to this compose based system if it was a simple import job.
    • zeroecco2 hours ago
      Thanks! Honest answer: nope. Holos talks to QEMU directly and skips libvirt entirely — that's deliberate (no XML, no daemon, state lives in a single directory per project), but I like the idea of being able to import vm's. I will try to find some time to add that feature.
  • tiernano2 hours ago
    Interesting. Wonder could it be modified to work with proxmox?
    • gmuslera2 hours ago
      With Proxmox it could be as well Docker compose for LXC.
  • khimaros24 minutes ago
    another player in this space built on incus: https://github.com/lnussbaum/incant
  • imirican hour ago
    Very cool, thanks for sharing.

    I built something similar recently on top of Incus via Pulumi. I also wanted to avoid libvirt's mountain of XML, and Incus is essentially a lightweight and friendlier interface to QEMU, with some nice QoL features. I'm quite happy with it, though the manifest format is not as fleshed out as what you have here.

    What's nice about Pulumi is that I can use the Incus Terraform provider from a number of languages saner than HCL. I went with Python, since I also wanted to expose a unified approach to provisioning, which Pyinfra handles well. This allows me to keep the manifest simple, while having the flexibility to expose any underlying resource. I think it's a solid approach, though I still want to polish it a bit before making a public release.

    • zeroeccoan hour ago
      Your path makes a ton of sense too! You get typed languages, state management, and the Incus team's work on the QEMU layer. The tradeoff I wasn't willing to make is the daemon + state store: Incus wants to own the VM lifecycle the way libvirtd does, and once you have that you're back to "two sources of truth" if you ever shell out. Holos is deliberately stateless on the host; Everything lives under one directory per project, rm -rf is a valid uninstall (though it will abandon the VMs if running). Different answer to the same frustration. Would genuinely like to see your thing when it's public.
      • d3Xt3r34 minutes ago
        This is exactly what I dislike about incus. But what I do like about incus is how I can easily spin up and configure VMs directly using the CLI, without preparing a config first (I hate yaml).

        So would be nice if holos could replicate that docker/incus CLI functionality, like say "holos run -d --name db ubuntu:noble bash -c blah".

        • zeroecco24 minutes ago
          Docker does have both docker run and docker compose... Holos is compose-only right now. A holos run on top of the same VM machinery isn't a huge lift; mostly it's deciding what the sensible defaults are (image, cloud-init user, port, volume scope); Noted. it's not in 0.1 but I hear the ask.
  • johnny222 hours ago
    sure has been awhile since i thought about vagrant
    • zeroecco2 hours ago
      Fair — the YAML shape is similar. The differences that matter to me: GPU passthrough works without fighting the provider plugin ecosystem, healthchecks gate depends_on instead of you sleeping in a provisioner, and there's no Ruby, no vagrant reload, no box format.