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?
Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks
11–20 of 26 posts
Re: Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks
#12another player in this space built on incus: https://github.com/lnussbaum/incant
Re: Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks
#13Earlier quoted context omitted.
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…
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".
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.
Re: Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks
#14Very 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…
check out https://github.com/lnussbaum/incant
Re: Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks
#15it 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?
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.
Re: Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks
#16sure has been awhile since i thought about vagrant
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.
Honestly, if you just sold it as vagrant but with all the weird stuff fixed and actually made to play nice with the rest of the stack that I'd actually want to use, that would be a pretty compelling package to me
Re: Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks
#17My biggest issue with QEMU is trying to keep up with seemingly arbitrary changes to the command-line options format over time, and keeping up scripts that can launch an image across different versions for testing.
Originally if you wanted e.g. a SoundBlaster16 device you could use -device sb16. Then it changed to -soundhw sb16. And now it's -audio driver=none,model=sb16; this has been happening with several different classes of options over the years and I haven't found any good documentation of all the differences in one place. If anyone knows, I'd appreciate it.
Re: Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks
#18sure has been awhile since i thought about vagrant
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.
Stop generating comments, please.
Re: Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks
#19Earlier quoted context omitted.
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.
Stop generating comments, please.
I did use an LLM to workshop my comms; I tend to go on and on so I put my my comments through a LLM to clean up my replies. the opinions and the project are mine, but the polish isn't. I'll knock it off for the rest of this thread.
Re: Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks
#20Earlier quoted context omitted.
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…
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".
[dead]