Wait for a blog post coming next week

You have my attention

@olivierlambert as someone who only uses zfs for vm storage on all of their xcp-ng hosts, this makes me very happy.

Yea I totally agree, this sounds promising.
We've used Nexentastor and FreeNAS/TrueNAS as backend for our XCP's for many many years and even arrays with spinning rust backed by RAM and SSD cache are pretty fast.

Being able to snapshot the zvol volume regularly is also a huge plus in case of a ransomware-attack and disaster-recovery since those can be sent to another machine.

To me, the best thing with SMAPIv3 is the flexibility (which is a challenge to deal with to appear as seamless regardless the storage you use as a user). But this flexibility could offer fast path and offload to devices.

Eg right now with SMAPIv1, it's ultra flexible but the entire concept is managed by the dom0 (we have to VHD everything, coalesce a chain, garbage collect snapshots etc.).

With SMAPIv3, you can do the same, but also, in some case, delegate to specific hardware. Let's take an example: a Pure Storage Flash array. Those things got an API, so you could have a specific driver talking to the array for doing snapshot and so on. So no more coalesce to deal with on XCP-ng, the storage will do it for you. That's just an example, but it will give a degree of freedom to provide many different capabilities, and some more "native" to a storage tech.

The downside is it's up to us to develop a way to universally works when you want to go from a storage to another, and to export your data too.

It's a bit more subtle than this. SMAPIv3 provides a decoupling between the volume and the data path. It means you can use whatever way to store your volumes (like a regular SMAPIv1 driver for example) BUT also choose the datapath (tapdisk with VHD or raw is the only choice in v1).

With v3, you could use any other datapath, like qemu-dp and other future solution.

Since VHD isn't mandatory to do snapshots and anything (as long you implement a way to do it yourself), it allows you to delegate some operation to the storage itself.

Here is an example with ZFS-ng driver: https://xcp-ng.org/blog/2022/09/23/zfs-ng-an-intro-on-smapiv3/

In short, we use tapdisk in raw mode, and let ZFS handle the snapshots and so on.

The first driver will be available in XCP-ng 8.3, without some features still missing (no migration path from v1 to v3, no storage migration and no backup). We are prioritizing a way to have XO able to backup this first implementation. This way, you could backup a SMAPIv1 based VM disk and restore it on SMAPIv3 ZFS-ng, providing a "cold/warm" migration to it.

Alright!
So a clean installation of 8.3 with SMAPIv3 would probably be the best way to test it once 8.3 is released.
If you were to summarize the 3 biggest differences (May be positive or negative) between SMAPIv1 and v3, what would those be?

Im thinking one would be this migration limitation, but other than that?

With v3, you could use any other datapath, like qemu-dp and other future solution.

Since VHD isn't mandatory to do snapshots and anything (as long you implement a way to do it yourself), it allows you to delegate some operation to the storage itself.

Here is an example with ZFS-ng driver: https://xcp-ng.org/blog/2022/09/23/zfs-ng-an-intro-on-smapiv3/

In short, we use tapdisk in raw mode, and let ZFS handle the snapshots and so on.

The first driver will be available in XCP-ng 8.3, without some features still missing (no migration path from v1 to v3, no storage migration and no backup). We are prioritizing a way to have XO able to backup this first implementation. This way, you could backup a SMAPIv1 based VM disk and restore it on SMAPIv3 ZFS-ng, providing a "cold/warm" migration to it.

Short answer: yes Our goal is to have a local SMAPIv3 SR available in 8.3 on the "short term" to demonstrate what's already doable with it. It will be likely ZFS based behind, allowing to use any VDI size while enjoy ZFS perks (compression).

This sounds great!
So it is really that close to becoming a reality?
Can't wait for it to be released, this will probably be a huge performance increase as well

We are (As many others) looking for alternatives to our VMWare platform, we're already using XCP and feel that it would possibly be a good alternative once XOSTOR is ready.

One thing that we and others (For example I read this in pretty much every thread on reddit) are struggling with is the 2Tb VDI limit. Many on-prem enterprises are running fileservers or large sql servers which requires a big VDI (Which is not ideal, I know).
Is this being resolved in SMAPIv3?

See https://xcp-ng.org/blog/2022/07/27/grant-table-in-xen/ for more details.