@olivierlambert Nice!

Looking forward to this too. Can't wait to test on my 8.3 cluster.

Understandable, I forgot that this is built ontop of LINTSTOR and not on DRBD directly. I belive then this post by LINBIT is more appropiate. Stacked Block Storage in LINBIT SDS (aka LINSTOR) This stack which is outlined seems interesting as it means we could for exampel use ZFS as volume manager and create a mirror-1 zpool for fast access, and raid-z2 or zfs draid for the slow access. Utilizing LINSTOR and DRBD for distributing this across the cluster. And utilizing bcache to unify these two zpools for using the fast/slow tier. I understand that right now the storage controller api of xcp-ng and xo is not setup to utilize such a setup. but could I potentially setup a ext4 or zfs filesystem ontop of this stack and use the already existing storage controller infrastructure, or would I be losing out on either performance and/or features by doing so.

@David I think the complexity is to be able to offer a simple interface / API way for users to configure multiple storages. Maybe through smapi v3. In any case we currently only support one storage pool, the sm driver would have to be reworked to support several. It also probably requires visibility from XOA's point of view. Lots of points to discuss. I will create a card on our internal Kanban. Regarding multiple XOSTOR SRs, we must: Add a way to move the controller volume on a specific storage pool. Ensure the controller it is still accessible for remaining SRs despite the destruction of an SR. Use a lock mechanism to protect the LINSTOR env.

Quick update. I ran this command for each drive on each host... wipefs --all --force /dev/sdX Then tried building the XOSTOR again. This time I got this an error in the XOSTOR page that some random UUID already had XOSTOR on it, but it built the XOSTOR? I have no idea how, or what happened, but it did. So I have my XOSTOR back.

At some point, our coming commercial model will be "bundles", where we won't sell Xen Orchestra "alone" anymore (ie we'll group both XCP-ng and XO into a single simple offer).. XOSTOR will be an option for a bundle. For a home lab use, you will be able to use it without paying anything (and without support obviously) by just installing it yourself manually via the CLI No CLI feature restriction, and it's fine as long as you don't break the moral contract