While UI/UX is–as probably everywhere–a huge topic, we actually have spent most engineering power in the whole management stack. And of that managing QEMU/KVM–while surely significant–is by far not the biggest part of our also 100% free and open source code bases. I'd invite you to try our full feature set, from clustering, to SDN to integrated Ceph management, to containers, backups including third party and our own backup server, and many more, all accessible through a REST API with full permission management and modern access control.

And we naturally try to contribute to every project we use however possible, be it in the form of patches, QA, detailed bug reports, ... and especially for QEMU et al. we're pretty content with our impact, at least compared to resources of other companies leveraging it, I think.

If all it'd take is being "just" a simple UI wrapper, it would make lots of things way easier for us :-)

> This would be appealing in a world where Kubernetes doesn't exist as a mature option.

The feature set of Kubernetes and Proxmox VE do not really overlap completely IMO, or would need much more hands-on approach and specialized in-house staff to set up and maintain, why go for that if you can do everything one need with much less headache.

As the former needs much more dedicated management and maintenance resources and is often pulling in more complexity than most need, but there one needs also to differentiate from those developing and releasing their own applications and being fine with what e.g. kubernetes offers, quite possibly even wanting that, compared to those e.g. providing infrastructure for internal use or just favoring more monolithic applications, often boils down to taste and what one is comfortable with. Our enterprise customers are very diverse, from small shops with two or three node clusters to host the office infra to five digit hosts and 6 digits VMs spread out. We even know a few setups using Proxmox VE as basis for their Kubernetes cluster.

Finally, PVE is quite a bit older than Kubernetes, we still exist and see a lot of adoption (already before the Broadcom deal, albeit there was an uptick since then), so even without some technical comparison of features or use cases or the like it seems clear that Kubernetes isn't an alternative for all, just like Proxmox VE certainly isn't one.

> Don't the vast majority of Proxmox users use it for small VM labs, without all the bells and whistles?

One should not confuse being very popular in the home lab scene due to being very approachable, simple to set up, and most importantly 100% FLOSS, not just open core or the like, with it being the main or target audience, but we're really happy with the synergies it provides.

And actually I'd not frame it as bad thing that Proxmox VE is used that way, we do not want to be a club that is hard to access, neither cost wise nor hindering scaling smaller VM labs to bigger setups, and certainly not from a complexity barrier.

Kubernetes also has off-the-shelf distros that are more apples-to-apples with Proxmox VE.

Let's not pretend that Proxmox or any of these are silver bullets that kill the (inherent) complexity demon. Anything touching SDN or clustered storage, in any ecosystem, will need dedicated in-house experts that know networking, storage, Linux and how Proxmox (or Kubernetes) approaches those domains.

Unless you are just using Proxmox for small VM labs, in which case it ought to be compared with libvirt and standalone QEMU.

Kill? no, definitively not. But 1) not adding a lot of extra and 2) applying the Pareto principle here are a huge difference. I.e. making the essential parts approachable enough to get one started while not being blocked too much by upfront (steep) learning curve, while not blocking one later by limiting one to just the predefined path.

> Anything touching SDN or clustered storage, in any ecosystem, will need dedicated in-house experts that know networking, storage, Linux and how Proxmox (or Kubernetes) approaches those domains.

There are widely different level of expertise needed though, and the setups that often are managed by admins with not in-depth expertise in clustering or SDN can still get things done with Proxmox VE, and if they are out of idea we got our enterprise support and naturally also the very active and friendly community forum to help.

> Unless you are just using Proxmox for small VM labs, in which case it ought to be compared with libvirt and standalone QEMU.

Yeah, I really do not get that point, you basically invalidate 95% of Proxmox VE's feature set because it might not be fully leveraged by a specific user group and because there are some different solutions that also allow one to do similar things. That would also invalidate Kubernetes, it's not completely unpopular in small labs either after all.

To be honest, to me, it feels a bit to me like a justification attempt for the initial post in this chain here that brushed off Proxmox VE as just some small UI/UX wrapper around QEMU/KVM and all the Real Work™ being done by others, possibly because you never actually used it, but I might read it the wrong way, and I'm certainly not offended in any way, just find it a bit odd.

My OP is more about promoting understanding of underlying VM technologies. Proxmox adds value, but also complexity of its own abstractions. QEMU and libvirt don't have salespeople trolling the internet to promote their use, so there is less awareness of what these core technologies are capable of.

Note that I'm neither a "sales people", nor is the one that made the original post, as that is Olaf from the Perl foundation, who reached out to me after I made a contribution to one of his Perl projects, if you must know. Tbh. I didn't even know that he would post this on some channels like here or reddit before getting pinged by a colleague that we were mentioned on the front page of HN. And for a fact, I actually know (and enjoy!) several people from the QEMU and libvirt developer community actively posting on other sites comment sections, or is that now a bad thing too?

And FWIW, I tried several times to point out that QEMU itself is only a small part of what we provide–even if not, just providing a good API abstraction around that is significant work, especially if it should allow two decades (and counting!) of stable upgrade paths and _without_ libvirt. And we nowhere hide the underlying technologies, we're proudly building upon–and trying to give back–to all projects we use, be it Debian, QEMU/KVM, LXC (which we co-maintain), Linux kernel, FRR, rust, or–like here–Perl...

But as you're rather dismissive and now even start to call people trolling I hardly see any need to take your writings as serious discussion, they do not seem to be done in good faith, and IMO doing it this way certainly won't help to promote FLOSS, that should be possible without being dismissive to others work.

Have you used proxmox? It makes stuff easy, that was really complicated before proxmox entered the stage.

You started with saying it was "essentially a UX wrapper", it was explained that there is a lot more to it, so you immediately shift into (paraphrased) "well there's other options and most people don't use the other features anyways".

Would have been cool of you to just say "oh neat, I didn't realize that you did all that too".

Do you really think people are using Proxmox MCP servers to administer mission-critical distributed computing systems that leverage SDN and clustered storage, rather than small VM labs? Because that was not my assumption.

That's very much not the point I was making, at all.

There could be tons! Or not many. It's completely irrelevant to my comment.

> Don't the vast majority of Proxmox users use it for small VM labs, without all the bells and whistles?

In my little world this largely was true until Broadcom bought VMware and proceeded to blow it up.

I know of a handful of rather “large” (100s of physical servers at least) VMware based products that are as quickly as possible migrating to proxmox.

Given how universal this is for my little slice of IT, I imagine this is quite pervasive for the “mid tier” VMware organization.

While you could do that, proxmox offers lot of value with its UI which I need to default to time to time. With just an API key I generate from proxmox I have a wide range of capability that I can hook up an MCP server to.

The funny thing is with Cursor I can just generate a new capability, like the clone and template actions were created after asking Sonnet 4.

Calling Proxmox a wrapper for KVM is hilarious, you're ignoring that Proxmox does all the work to make a functional cluster of VM servers including stuff like shared storage and live migrations and networking. If you only use Proxmox on a single server with local storage then I could see how you would say this but having a fleet of VMs on a cluster of servers where you can take down physical hosts to patch transparently is the "hard problem."

It's an annoying thing common to a lot of technologists. They (we?) see a product which solves a problem, then imagine some hacky way to set up existing tools to half-way solve a similar problem in an easy but incomplete way, then make fun of the product for existing when the hacky solution exists. The Hacker News comment on Docker's announcement post comes to mind, where a person makes fun of the concept when you could "just" run rsync in a cron job.

I think you might mean Dropbox, but your point still stands.

For context, here's that classic thread: https://news.ycombinator.com/item?id=8863 :)

Haha, yeah I meant Dropbox. Derp

Proxmox has a UI and a bunch of APIs so I don't need to rebuild them myself, and maintains everything quite well (all major upgrades I've done have been pretty seamless). Proxmox is definitely an easy path, and you still have root access for drawing outside the lines.

This is true for the act of launching VMs, but it’s pretty reductive towards the entire suite of important features that Proxmox provides like clustering, high availability, integration with various storage backends, backups, and more that qemu doesn’t.

I mean, that's actually not being fair... It's like saying Windows is just a UX wrapper around a microkernel. There is quite a bit of functionality provided by that wrapper.

it's not. their SDN built on frr and vxlan is itself a complex piece that has been missing from the free space (integrated as a package).