The container and app server support in Virtualmin Pro (including Docker or Podman support) is working pretty well and in private testing now. It’s still getting a lot of UI polishing and bug fixing and it still needs documentation, so it’s not ready for public consumption yet, but it should be available for customer beta testing in a couple/few weeks.
And, yes, LXC is also being removed from the default Cloudmin installation. We’re cutting down to just KVM or Xen (with KVM recommended) on Linux as supported virtualization types in the installer, for a variety of reasons.
One reason is that we’re just overwhelmed. Cloudmin doesn’t make enough money to begin to support its development, certainly not enough to hire another developer to help out (or enough to justify one of us quitting our other jobs to work full-time on it), so we have to reduce the surface area dramatically.
But, also, container-based full system virtualization is kind of a dead end. KVM is now the de facto standard for that kind of virtualization and with advancements in memory sharing the advantage of containers has mostly evaporated (it used to be that KVM needed a lot more memory than something like LXC, and could be more resource hungry, but that’s not as true any more). And, KVM gets tremendously more funding than LXC/LXD has gotten, so it’s just a remarkably more mature platform. The market and the development resources have decided that containers are for running apps and KVM is for running full system virtual machines.
So, container support (Podman preferred, but Docker is also fully supported, but the default install will use Podman) is coming to Virtualmin very soon and leaving Cloudmin, at least in the default installers. Container support will remain in the Cloudmin package for some time (depending on how many customers are using it), so it’ll still be possible to keep using it and keep getting updates and bug fixes for existing deployments, but it’ll stop being part of a default installation when you run the install script.
LXC and Zones will probably remain in the package longer than Docker, since Docker has never really been useful in the ways Cloudmin uses it and I doubt there are any production users depending on it that wouldn’t be better served by Virtualmin support for it.
The side effect is we can actually focus on making the primary/recommended virtualization type (KVM) really nice to use. That’s not really the case right now. There’s so many options and so many weird interactions between virtualization types, and this is a complicated area with a lot of low-level kernel interaction, that it can be really hard to make Cloudmin work really nicely without more expertise than I think we should expect users to have. I started working on a new installer for Cloudmin ages ago, but there were so many scripts and so many targets and so many interactions that it was overwhelming. Reducing the focus of Cloudmin makes it possible to make it good given the resources we currently have.