@OhSoNoob I've used XOSTOR on top of MDRAID and it seemed to work well for me during my testing. I ran tests of it on top of MD RAID 1, 5, and 10 (MDRAID's "RAID 10" which isn't really RAID 10) and had good luck with it. The XOSTOR is really adding a second layer of redundancy at that point, similar to MDRAID 5+1 builds so is almost overkill. Almost. Where I see the most benefit from XOSTOR on MDRAID would be on top of RAID 10 or RAID 0 arrays. Depending on the speed of your drives, you might get some benefit from the increased read speed (and read/write speed for RAID 0). In addition, RAID 10 would give you some additional redundancy so that losing a drive wouldn't mean the loss of that node for XOSTOR's purposes, possibly making recovery easier. The ability for some redundancy might also be useful for a stretched cluster or some other situation where your network links between XOSTOR nodes isn't as fast as it should be; The ability to recover at the RAID level might be much faster than recovering or rebuilding an entire node over a slow link. @ronan-a, I'm not sure if you remember, but the very first test of XOSTOR I ran, shortly after it was introduced,, were on top of RAID 10 arrays. I kept that test cluster alive and running until equipment failure (failed motherboards, nothing related to XOSTOR or MDRAID) forced me to scrap it. I had similar teething pains to others while XOSTOR was being developed and debugged during the test phase, but nothing related to running on top of MDRAID as far as I could tell.

Not only but that's where it's more visible.

Hi, Because you can enter a scenario where some XOSTOR packages might require a restart without the rest. We have planned to detect that and make the RPU algorithm a bit different in the order of operations

@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