@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