4 ms·
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–w
by tlamponi 1y ago
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 :-)
- pphysch 1y ago> 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. This would be appealing in a world where Kubernetes doesn't exist as a mature option. Don't the vast majority of Proxmox users use it for small VM labs, without all the bells and whistles?
- phil21 1y ago> 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.
- tlamponi 1y ago> 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.
- pphysch 1y agoKubernetes 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.
- tlamponi 1y agoKill? 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.
- deleted 1y ago[deleted]
- qualeed 1y agoYou 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".
- pphysch 1y agoDo 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.
- deleted 1y ago[deleted]
- qualeed 1y agoThat'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.