Proxmox Virtual Environment 9.0 with Debian 13 released
proxmox.com
proxmox.com
I don't have much experience with them, so can't tell if it's really on the same level.
One advantage Ceph has over VMware is that you don't need specially approved hardware to run it. Just use any old disks/SSDs/controllers. No special extra expensive vSAN hardware.
But I cannot give you a full comparison, because I don't know all of VMware that well.
Use any of these with the built in HA manager in proxmox
Can it be used to format a single shared block device that is accessed by multiple hosts like VMFS does? My understanding is this isn't possible.
You can set up a radosgw outside of the proxmox and use objects.
But ceph is fundamentally a distributed object store, shared LUNs with block level multi-writer is fundamentally a tightly coupled solution.
If you have a legacy need that has OCFS or a quorum drive, the underlying tools proxmox is an abstraction can sometimes be used as these types of systems tend to be pets.
But if you were just using multi-writer because it was there, there are alternatives that are typically more robust under the shared nothing model like Ceph uses.
But it is all tradeoffs and horses for courses.
There is Ceph and then there is CephFS, "a POSIX-compliant file system built on top of Ceph’s distributed object store, RADOS":
When migrating a VM from one host to another it would require cloning the LVM volume, rather than just importing the group on the other node and starting the VM up.
I have existing VMware gusts that I'd like to migrate over in bulk. This would be easy enough to do by converting the VMDK files, but using LVM means creating an LVM group for each VM and importing the contents of the VMDK into the LV.
With such a setup, PVE will create LVs on the same VG for each disk image. So no handling of multiple VGs or LUNs is necessary.
The multipathing PVE wiki page lines out the whole process: https://pve.proxmox.com/wiki/Multipath
If your requirements are flexible Proxmox does have one nice alternative though - local ZFS + scheduled replication. This feature performs ZFS snapshots + ZFS send every few minutes, giving you snapshots on your other nodes. This snapshot can be used for manual HA, auto HA, and even for fast live migration. Not great for databases, but a decent alternative for homelab and small business.
[1] https://forum.proxmox.com/threads/default-settings-of-contai...
[2] https://linuxcontainers.org/incus/docs/main/howto/instances_...
Most of the operations and configurations that exist in Proxmox are not present in the providers, like SDN, firewall and the various storage options. The reason is that the API is all over the place and really badly documented.
Note that I still quite like the product. I have a 2- (soon to be 3-) node cluster at home and at this moment I have no plans to migrate away from it.
I looked into Incus but it's also far from mature, with an API and general data structure being full of inconsistencies, and again the documentation is not quite there.
I really wish proxmox had nicer container support.
If a proxmox container config could specify a dockerfile as an option, I think proxmox would be 1000% more useful (and successful)
Instead with LXC and their config files, I feel like i have to put on a sysadmin hat to get a container going. Seems like picking up an adding machine to do my taxes.
(also, lxc does have a way to specify a container, but it is not used)
Instead I have written scripts to automate some of this, which helps,
There is also cloud-init, but I found it sort of unfriendly and never went anywhere with it.
Apparently with OIDC (with group claims), Proxmox can map group membership from OIDC tokens and autocreate or map groups dynamically at user login
Love Proxmox, it's done everything I needed of it.
I don't use it to anywhere near it's potential, but I can vouch for the robustness of its backup process. I've had to restore more than handful of VMs for various reasons, and they've all been rock-solid upon restoration. I would like to use its high-availability features, but haven't needed them and don't really have the time to tinker so much these days.
Can someone tell me wether proxmox upgrades are usually smooth sailing, or should I prepare for this being an endeavour?
That said, I just made it out alright in my home lab without too much hullabaloo.
I should do the same update this weekend. .
At work we started with 6.x a few years ago, upgraded to 7.x a bit after releases, then same with 8.x without issue.
We'll wait a reasonable while before upgrading to 9.x but I don't expect any issue.
Note : same with integrated ceph update, did Reef to Squeed a few weeks ago, no issue.
FWIW, we got staff members that are also directly involved with Debian which makes things a bit easier.
I wouldn't expect much changes, if any a all, between today (Aug 5th) and the expected release date (Aug 9th).
Frankly, not waiting half a week is bright orange flag to me.
Finally, we provide bug and security updates for the previous stable release for over a year, so no user has any rush to upgrade now, they can safely choose any time between now and until August 2026.
As you said, Debian 13 officially lands on August 9, so it’s close—but in my (admittedly limited) experience, the testing branch still feels pretty rough. I ran into way more dependency chaos—and a bunch of missing or deprecated packages—than I expected.
If you’re relying on container images that have already moved to Trixie, heads up: it’s not quite seamless yet. Might be safer to stick with Bookworm a bit longer, or at least test thoroughly before making the jump.
kernel.org don't even list version 6.14 anymore. do they backport security patches on there own?
(Ignore this if it’s irrelevant and I’m missing the point, which is always a distinct possibility)
> Many Linux distributions provide their own "longterm maintenance" kernels that may or may not be based on those maintained by kernel developers. These kernel releases are not hosted at kernel.org and kernel developers can provide no support for them.
> It is easy to tell if you are running a distribution kernel. Unless you downloaded, compiled and installed your own version of kernel from kernel.org, you are running a distribution kernel. To find out the version of your kernel, run uname -r:
Has that always been the case? I have a faint memory of trying once and not being able to with Proxmox 7.x
But, things like proxmox-boot-tool may not work.
Which I think is really cool since it means their stuff is "truly open-source" :)
We did it for 7.x [1] and it worked fine (since upgraded things in-place to 8.x).
[1] https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_11...
It seems to me people who try things like this might also be ok with spaces in filenames, or replacing bash with csh...
It should work, but you might want to cross your fingers.
First time hearing about Yew (yew.rs). First time hearing about it. Is it like writing frontend code in Rust and compiled to WASM ? Is anyone using it (other than Proxmox folks, of course).
Exactly, it's actually quite lightweight and stable plus mostly finished, so don't let the slower upstream releases discourage you from ever trying it more extensively.
We build a widget library with our products as main target around Yew and native web technologies, you can check out:
https://github.com/proxmox/proxmox-yew-widget-toolkit
And the example repo:
https://github.com/proxmox/proxmox-yew-widget-toolkit-exampl...
For code and a little bit more info. We definitively need to clean a few documentation and resource things up, but we tried to make it so that it can be reused by others without tying them to our API types or the like.
FWIW, the in-development Proxmox Datacenter Manager also uses our Rust / Yew based UI, it's basically our first 100% rust project (well, minus the Linux / Debian foundation naturally, but it's getting there ;-)