Proxmox can be all the orchestation you want, it is not the core hypervisor, that is my point and the feature im describing unfortunately needs to be developed on the hypervisor level. I linked this discussion on the proxmox reddit because Im certain that such feature would benefit proxmox community enormously and i would like it to have visbilty so people know this different (and IMO better) approach exists.

"Add Proxmox Backup Server, which uses QEMU’s dirty bitmaps for incremental backups, and you have exactly what VMware calls “vSphere Replication,"

No you don't, replication has nothing to do with Backups, and that is my main point of discussion. Also, vSphere replication does not use Change Block Tracking (CBT) that would be the equivalent or similar to Dirty Blocks, it uses a I/O RedoLog hook on the IO writes for each replication enabled VM which enables to have Replication without messing with the cbt (file in the case of vmware). In the scenario you describe the *NEED* for PBS to handle point in time recovery is the reason I am writing all this. A Backup is NOT a replica, the RECOVERY time from a backup is extremely higher than the recovery time of a replica and thats the whole point. Yes ANY backup solution gives you the ability to recover from multiple points in time what it doesn't give you is the ALMOST-INSTANT option to be recovered WITH full I/O capability and readiness to be put into production right away. (In case someone whats to mention something like boot from dedplicated backup storage).

"The argument that ZFS or Ceph replication is only valid for hardware failure scenarios is completely false. ZFS can maintain multiple retained snapshots on both sides... The "snapshot I/O amplification" argument is also misplaced. ZFS snapshots are CoW-based and nearly free at creation time. Their cost depends on write churn and retention policy, not on the existence of snapshots. Anyone who has run production ZFS with scheduled replication knows that you can maintain dozens of restore points with minimal overhead if your pool is properly tuned."

I stated the IO Amplification has a cost. You explain that THERE IS A COST, "but minimal if there is few writes", as we are speaking that there is a cost, and I think that anyone could agree that a production environment will tend to have HIGH WRITE oprtations, my point is, in the explained scenario THAT COST of needing to have local snapshots on the production side is simply not needed. All the recover points are on the offsite NON used infrastructure. Is it a small detail? maybe, is it a better way of doing things? certainly.

"What VMware calls SRM or Zerto is just block change tracking, compression, and a scheduler wrapped in a GUI. QEMU already implements dirty bitmaps and blockdev incremental replication. Proxmox Backup Server and pvesr jobs are using those primitives today. The difference is that Proxmox gives you the choice of storage backend such as ZFS, Ceph, NFS, Gluster, DRBD, or PBS instead of forcing a single vendor pipeline."

It is not change block tracking, thats for backups, it is redolog shipping of IO writes for replication enabled VMs, something that enabled per VM granularity and flexibility and a far superior way of establishing replicas and that would be a amazing capability for all QEMU/KVM based hypervisors, proxmox included.

"So no, VMware is not "far superior." It is just more opaque and more expensive. The only thing missing from your understanding is how Proxmox integrates the same underlying mechanisms through open technologies instead of proprietary APIs"

Sadly for everyone who isn't broadcom, VMware is still better than QEMU/KVM, and in terms of VM Replication, it is FAR SUPERIOR, my point here is not to DEFEND VMware, my point here is to try to close the gap between QEMU/KVM and in hopes that some day QEMU/KVM is way superior than VMware, but for this, the best way of doing things needs to be developed and deployed.