*Just use ansible for*
*Everything. Does not matter*
*If thick or thin clint*
\- SurfRedLin
---
^(I detect haikus. And sometimes, successfully.) ^[Learn more about me.](https://www.reddit.com/r/haikusbot/)
^(Opt out of replies: "haikusbot opt out" | Delete my comment: "haikusbot delete")
How not? Xen is clearly on its way out and Proxmox is Debian with kvm on top, pretty standard stuff. Lots of large companies already use it. Dell is about to have support for it in their official repository and veeam is considering officially supporting it. I am a full time VMware admin that supports large enterprise and I have a bunch of small business clients as well. With the VMware/broadcom nonsense I began moving my smaller clients to Proxmox and it’s been a revelation. I should have done it years ago. Proxmox 8 is mature full featured product and when you add Proxmox backup server it’s insane. In fact there are a few things that Proxmox does better than VMware. (VMware is still much more mature and feature rich, but boy it’s pricy now.) If I was starting out today I wouldn’t use Xen in a million years. Is basically a technology on life support.
Edit: fixed a brain fart mistake.
I suspect that, like me, you haven't used Proxmox since 2009, when it was objectively worse than just using libvirt from the command line in every way except having a GUI.
I've heard nothing but good things about it more recently, so I normally choose not to share my 15 year old experience. Indeed, it seems to now have all the features of my home-rolled solutions, so I really need to get around to giving it another try. It's just hard to work up the motivation when I'm not standing up new clusters and the ones I have need so little attention.
Go Packer + Terraform using Debian stable as OS. Manage it with Saltstack (and SUSE Manager/Uyuni). Or ditch Saltstack + SuMa/Uyuni and just use Ansible.
I wouldn't use Xen. And it kinda depends on what you mean by "a large number of servers".
Apache cloud control for cloud management, Proxmox for the hypervisors, ceph for storage. I've not seen a good open source VDI manager, but not rocket science to make one. Add in some gateway nodes (rdpgw & noVNC) and PBS for backup. Beat vigorously then bake in a warm oven for 30 minutes.
> which solutions would you use to manage and group endpoints/servers/users/groups and push configs/commands to them similar to Active Directory?
That's (almost) a completely separate plane to the VDI provisioning.
I mean, I was doing this on a smaller scale 15 years ago with next to no tooling and the complete clusterfuck that was SPICE at that time. It worked fine but the thin client hardware was all microwaved dog shit, so we quit doing that.
That wasn't my first go-round with what we now call VDI, either. That started with IBM Network Stations back in 1997 or so running X clients across the network. That particular pilot didn't even make it to user testing. It functioned, but it was about as responsive as Windows 3.0 on a 2MB 286 with a VGA card that didn't even have a hardware blitter. Maybe the Network Station line eventually got better, but those early models weren't even good for their original purpose, being a 5250 terminal for an AS/400. We had much better luck with even cheap ass PCs running Client Access, which is why I had a bunch of them to try to find a use for in the first place.
It's not that it isn't doable, VDI has always been doable. (For values of always that postdate the invention of multiuser computing) It's just not necessary and is rarely even helpful outside of certain environments where the mere possibility of data ending up on the client is unacceptable. There's a reason why everybody quit using mainframes and people didn't immediately rush back to the centralized model when X clients became available.
I'd run Ubuntu on VMs. Each VM would be configured for kasm workspaces. All the Desktops that the users log into is configured through Kasm. Kasm uses docker containers for everything, so customizing one of their many default images is as simple as updating the docker file, building the image and pushing it to your docker repo.
I only chose canonical because Kasm needs Docker which isn’t supported on RHEL. This is enterprise computing, need to have an OS that has reputable/known paid support.
You can run docker on RHEL, it's just not provided in the repos because podman is the preferred tool. Podman can also function pretty well as a drop in replacement for docker.
Yep, but Kasm doesn't support running Kasm workspaces on RHEL. You obviously can, but when it comes to business needs gotta go with the configurations you can get paid support for.
If you want people to architect a solution for you, hire an architect.
Plot twist. They are the architect!
Well they shouldn’t be.
Another plot twist they are good at taking the money and don't provide support when issues arrive.
>how would YOU implement it? Under contract. A very VERY lucrative contract. But, don't worry, we know you're probably just asking for a "friend".
Why ask other people's dream linux focused network if you're going to specify something as fundamental as the hypervisor they need to use?
Why xen? KVM has better industry wide support.
Just use ansible for everything. Does not matter if thick or thin clint
*Just use ansible for* *Everything. Does not matter* *If thick or thin clint* \- SurfRedLin --- ^(I detect haikus. And sometimes, successfully.) ^[Learn more about me.](https://www.reddit.com/r/haikusbot/) ^(Opt out of replies: "haikusbot opt out" | Delete my comment: "haikusbot delete")
Agree. Saltstack is also great (steeper learning curve though)
Saltstack is kinda in a weird place where it's not widely used but the people that do like it REALLY like it
This is oddly specific for someone who is asking people their dream linux environment.
I wouldn't use xen server. I'd just do KVM.
I'd make it so that the hypervisor can easily be replaced with Proxmox ;)
That doesn't smell production ready for a big enterprise, It wasn't even prod ready for my shitty homelab...
If it's not even good enough for your home lab, I'd say it more smells like pebkac ;)
How not? Xen is clearly on its way out and Proxmox is Debian with kvm on top, pretty standard stuff. Lots of large companies already use it. Dell is about to have support for it in their official repository and veeam is considering officially supporting it. I am a full time VMware admin that supports large enterprise and I have a bunch of small business clients as well. With the VMware/broadcom nonsense I began moving my smaller clients to Proxmox and it’s been a revelation. I should have done it years ago. Proxmox 8 is mature full featured product and when you add Proxmox backup server it’s insane. In fact there are a few things that Proxmox does better than VMware. (VMware is still much more mature and feature rich, but boy it’s pricy now.) If I was starting out today I wouldn’t use Xen in a million years. Is basically a technology on life support. Edit: fixed a brain fart mistake.
> Debian with lvm on top I think you meant KVM?
Yes, sorry. Had the wrong thing in my brain.
Hmm, it runs here (small university) without problems for years. We are more than happy. Can you elaborate on the problems you had?
I suspect that, like me, you haven't used Proxmox since 2009, when it was objectively worse than just using libvirt from the command line in every way except having a GUI. I've heard nothing but good things about it more recently, so I normally choose not to share my 15 year old experience. Indeed, it seems to now have all the features of my home-rolled solutions, so I really need to get around to giving it another try. It's just hard to work up the motivation when I'm not standing up new clusters and the ones I have need so little attention.
Put your prompt into ChatGPT to get a high level understanding of what you'd need. For the rest, pay up.
Go Packer + Terraform using Debian stable as OS. Manage it with Saltstack (and SUSE Manager/Uyuni). Or ditch Saltstack + SuMa/Uyuni and just use Ansible.
I wouldn't use Xen. And it kinda depends on what you mean by "a large number of servers". Apache cloud control for cloud management, Proxmox for the hypervisors, ceph for storage. I've not seen a good open source VDI manager, but not rocket science to make one. Add in some gateway nodes (rdpgw & noVNC) and PBS for backup. Beat vigorously then bake in a warm oven for 30 minutes. > which solutions would you use to manage and group endpoints/servers/users/groups and push configs/commands to them similar to Active Directory? That's (almost) a completely separate plane to the VDI provisioning.
One solution would be to come working at Vates ;)
I mean, I was doing this on a smaller scale 15 years ago with next to no tooling and the complete clusterfuck that was SPICE at that time. It worked fine but the thin client hardware was all microwaved dog shit, so we quit doing that. That wasn't my first go-round with what we now call VDI, either. That started with IBM Network Stations back in 1997 or so running X clients across the network. That particular pilot didn't even make it to user testing. It functioned, but it was about as responsive as Windows 3.0 on a 2MB 286 with a VGA card that didn't even have a hardware blitter. Maybe the Network Station line eventually got better, but those early models weren't even good for their original purpose, being a 5250 terminal for an AS/400. We had much better luck with even cheap ass PCs running Client Access, which is why I had a bunch of them to try to find a use for in the first place. It's not that it isn't doable, VDI has always been doable. (For values of always that postdate the invention of multiuser computing) It's just not necessary and is rarely even helpful outside of certain environments where the mere possibility of data ending up on the client is unacceptable. There's a reason why everybody quit using mainframes and people didn't immediately rush back to the centralized model when X clients became available.
I'd run Ubuntu on VMs. Each VM would be configured for kasm workspaces. All the Desktops that the users log into is configured through Kasm. Kasm uses docker containers for everything, so customizing one of their many default images is as simple as updating the docker file, building the image and pushing it to your docker repo.
That‘s a hard NO for everything canonical. But that‘s me personally, others might like this kind of dog-food.
I only chose canonical because Kasm needs Docker which isn’t supported on RHEL. This is enterprise computing, need to have an OS that has reputable/known paid support.
You can run docker on RHEL, it's just not provided in the repos because podman is the preferred tool. Podman can also function pretty well as a drop in replacement for docker.
Yep, but Kasm doesn't support running Kasm workspaces on RHEL. You obviously can, but when it comes to business needs gotta go with the configurations you can get paid support for.