@irtaza9 it scans all the VDI's on the SR to see if something has changed, if there's a need for coalesce and so on. I dont think it will be a big issue if you increase the auto-scan-interval value to lets say 5 minutes (300 seconds), but do remember, that everything regarding the VDI's on the SR will take up to 5 minutes to update, as well as triggering coalesce after removing snapshots.

That worked; thank you!!!

@TestForEcho No ETA for now. Even before supporting QCOW2 on LINSTOR, we have several points to robustify (HA performance, potential race conditions, etc.). Regarding other important points: Supporting volumes larger than 2TB has significant impacts on synchronization, RAM usage, coalesce, etc. We need to find a way to cope with these changes. The coalesce algorithm should be changed to no longer depend on the write speed to the SR in order to prevent potential coalesce interruptions; this is even more crucial for LINSTOR. The coalesce behavior is not exactly the same for QCOW2, and we believe that currently this could negatively impact the API impl in the case of LINSTOR. In short: QCOW2 has led to changes that require a long-term investment in several topics before even considering supporting this format on XOSTOR.

You can manually install XOSTOR yes.

@bdenv-r are you trying XOSTOR on 8.2 or 8.3 ? had many problem of performance and tap-drive locking my VDIs on 8.2 xostor would like to know if 8.3 xostor still have issues

@olivierlambert Thanks !

Hello, @DustinB The https://vates.tech/xostor/ says: The maximum size of any single Virtual Disk Image (VDI) will always be limited by the smallest disk in your cluster. But in this case, maybe it can be stored in the "2TB disks" ? Maybe others can answer, i didn't test it.

Hello, I tried on a new pool. a little different scenario since i don't create xostor for now, on my previous example, i tried to add a node as replacement of an existing one.. I just run the install script only on node 1. When i try make node2 join the pool, i reproduce the incompatible sm error i got previously. The things which is "bizarre", is i don't have the license issue i got on Xen-orchestra. ( maybe it was finally not related ? ) Here is the complete logs. pool.mergeInto { "sources": [ "17510fe0-db23-9414-f3df-2941bd34f8dc" ], "target": "cc91fcdc-c7a8-a44c-65b3-a76dced49252", "force": true } { "code": "POOL_JOINING_SM_FEATURES_INCOMPATIBLE", "params": [ "OpaqueRef:090b8da1-9654-066c-84f9-7ab15cb101fd", "" ], "call": { "duration": 1061, "method": "pool.join_force", "params": [ "* session id *", "<MASTER_IP>", "root", "* obfuscated *" ] }, "message": "POOL_JOINING_SM_FEATURES_INCOMPATIBLE(OpaqueRef:090b8da1-9654-066c-84f9-7ab15cb101fd, )", "name": "XapiError", "stack": "XapiError: POOL_JOINING_SM_FEATURES_INCOMPATIBLE(OpaqueRef:090b8da1-9654-066c-84f9-7ab15cb101fd, ) at Function.wrap (file:///etc/xen-orchestra/packages/xen-api/_XapiError.mjs:16:12) at file:///etc/xen-orchestra/packages/xen-api/transports/json-rpc.mjs:38:21 at runNextTicks (node:internal/process/task_queues:60:5) at processImmediate (node:internal/timers:454:9) at process.callbackTrampoline (node:internal/async_hooks:130:17)" }```

Hello @ronan-a I will reproduce the case, i will re-destroy one hypervisor and retrigger the case. Thank you @ronan-a et @olivierlambert If you need me to tests some special case don't hesit, we have a pool dedicated for this

@olivierlambert No, For once, i followed the installation step carefully ^^'

Excellent news, thanks!

@cmd Hello, It's described here in the documentation https://docs.xcp-ng.org/xostor/#map-linstor-resource-names-to-xapi-vdi-uuids It might be possible to add a parameter in the sm-config of the VDI to ease this link, I'll put a card in our backlog to see if it's doable.

@nathanael-h Thanks for the feedback.

@olivierlambert I did open a ticket but thought I would post here as well to see if anyone had insights. Thanks.

Have you read the doc first? https://docs.xcp-ng.org/xostor/ This gives a nice overview on how it works

@ronan-a [...] 64 bytes from 172.27.18.161: icmp_seq=21668 ttl=64 time=0.805 ms 64 bytes from 172.27.18.161: icmp_seq=21669 ttl=64 time=0.737 ms 64 bytes from 172.27.18.161: icmp_seq=21670 ttl=64 time=0.750 ms 64 bytes from 172.27.18.161: icmp_seq=21671 ttl=64 time=0.780 ms 64 bytes from 172.27.18.161: icmp_seq=21672 ttl=64 time=0.774 ms 64 bytes from 172.27.18.161: icmp_seq=21673 ttl=64 time=0.737 ms 64 bytes from 172.27.18.161: icmp_seq=21674 ttl=64 time=0.773 ms 64 bytes from 172.27.18.161: icmp_seq=21675 ttl=64 time=0.835 ms 64 bytes from 172.27.18.161: icmp_seq=21676 ttl=64 time=0.755 ms 1004711/1004716 packets, 0% loss, min/avg/ewma/max = 0.712/1.033/0.775/195.781 ms I am attaching simple ping stats for last 11 days. I don't think we can blame the network

Hi, XOSTOR on XCP-ng 8.2.1 has been supported since it was released approx 9 months ago. XOSTOR on XCP-ng 8.3 is still in the beta phase, so not officially supported. Regards, Dan