Live data from Hacker News

Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks

github.com

21–26 of 26 posts

Re: Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks

#22
post #8

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…

check out https://github.com/lnussbaum/incant

Ah, that's neat as well.

I took a slightly different approach in that I don't want to use YAML as the authoritative source. Many projects abuse it, and end up creating a DSL on top of it with all sorts of hacks to achieve the flexibility of a programming language. Pulumi and Pyinfra already provide user-friendly primitives and idempotent(ish) APIs that work much better than YAML. I simply want to expose some (opinionated) building blocks to make them easy to use, and allow users to customize them and add their own as needed. E.g. I definitely don't want to write any shell scripts inside YAML. :)

BTW, Pulumi already supports YAML[1], which can be used with any provider. But to me it's too verbose and generic, and of course, it lacks the provisioning primitives.

[1]: https://www.pulumi.com/docs/iac/languages-sdks/yaml/

Re: Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks

#23
post #9
post #8

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…

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…

> 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.

That's true. But I didn't want to reinvent what Incus or any hypervisor abstraction does. I simply wanted to add some sugar on top that allows me to easily declare infra using small abstractions, and to tie in the provisioning aspect along the way. I still use Incus directly, and can benefit from their work, as you say. State is also managed by Pulumi, so really, there are 3 places for it to exist. There are some challenges with this, of course, but I think the tradeoff is worth it.

Good luck with your project, I'll be keeping an eye on it. I'll probably make a Show HN post when I release mine. Cheers!

Re: Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks

#25

Earlier quoted context omitted.

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.

You should not use an LLM on Hacker News, period.

> Don't post generated comments or AI-edited comments. HN is for conversation between humans.

https://news.ycombinator.com/newsguidelines.html#generated

Re: Show HN: Holos – QEMU/KVM with a compose-style YAML, GPUs and health checks

#26
post #10
post #9

Earlier 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".

[deleted]
Post reply on HN