@ronan-a Unfortunately, I am in the process of reinstalling XCP-ng on the nodes to start from scratch. Just thought I have tried too many things and somewhere forgot to undo the ‘wrong’ configs. So can’t run the command now. Although I had run this command before when I posted all the screenshots. The output had 2 entries (from my memory): 1. StltCon <mgmt_ip> 3366 Plain 2. <storage_nw_ip> 3366 Plain I will repost with the required data when I get everything configured again. Thanks.

@fatek XOSTOR isn't currently compatible with the 8.3 beta, so you need to use XCP 8.2.1 if you want to use XOSTOR now.

I had a similar error. I gave up & have decided to wait for the official 8.3 xcp-ng release that should/will support XOSTOR 1.0 https://xcp-ng.org/forum/post/77160

@BHellman said in Let's Test the HA: Disclaimer: I work for LINBIT, makers of DRBD and LINSTOR the tech behind XOSTOR. We can do highly available iscsi targets, we even have guides on our website that take you step by step to do it. These would be outside of XCP-NG, but would serve the same purpose. If there is any interest from Vates to integrate DRBD/HA into XCP-NG, we're always open to discussions. Sounds interesting for pretty much everyone comming from VMware vSAN running SQL Server in a failover-cluster if im allowed to jump the gun

So, yes, I had to create the interface again. Live migration on a 100gig network is looking pretty sweet!

Ticket has been updated. Thanks to Support. XOSTOR cluster has been successfully created.

@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