@User-cxs Ping @xen-orchestra for additional help regarding this trace.

Concerning LINSTOR, you don't have to manually configure it using yum/systemctl. The controller must never be started like this, please stop it with:

systemctl disable --now linstor-controller

For you info it's started automatically by another service and to mount the DB volume list of the SR. Otherwise, this information is not shared across all hosts.

@User-cxs "unknown error from the peer" => It can be a problem with licenses, or another thing caused by XOA, you should have more info in XO server logs. Otherwise check the logs indicated by Antoine on the XCP-ng side.

@iamsumeshks So I guess you have two resources in your LINSTOR and they are using your 10Gb network.

@iamsumeshks You can confirm that using netstat -nlapute | grep :7.

Explanation: The DRBD ports are in the range 7000:8000. With this command, you should see the IPs of your PrefNic interface and not the default one, if everything is configured correctly.

@snk33 In fact we have limitations with CBT and XOSTOR. And this won't be resolved until we get back into SMAPIv3.

Not being able to use CBT on XOSTOR is a big issue for backup/replication.

Using it is more likely to cause problems than improve your situation. What bothers you about not using CBT here?

@ovicz Can you share the /var/log/SMlog file from the master? It's quite strange considering that this driver is small and hasn't been modified.

@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.

@henri9813 said in XOSTOR hyperconvergence preview:

of course, i checked, my SR was not full

The visual representation of used space is for informational purposes only; it's an approximation that takes into account replication, disks in use, etc. For more information: https://docs.xcp-ng.org/xostor/#how-a-linstor-sr-capacity-is-calculated

We plan to display a complete view of each physical disk space on each host someday to provide a more detailed overview. In any case, if you use "lvs"/"vgs" on each machine, you should indeed see the actual disk space used.

@henri9813 Can you share your logs (/var/log/SMlog + xensource.log) somewhere? I wonder if this error is triggered by a sm attach call.

@henri9813 Hi! Just to confirm, can you share the exception in the SMlog file of the master host? We are aware of an exception in the same style, and it is a side effect of another exception caused in the _snapshot function of LinstorSR. We have already planned to correct it in a new version of the sm, it's been a while that it's there but not critical. Thanks!

@manilx No, nothing more to do, once installed this package remains present as long as you do not upgrade to a new major version of XCP-ng. But no issues regarding updates.

@Razor_648 Do you have any exceptions in your /var/log/SMlog files?

@dwhitehead42 You can install the plug-late-sr RPM from our repo.
Then follow this documentation: https://github.com/xcp-ng-rpms/plug-late-sr/tree/master/SOURCES

@peter_webbird We've already had feedback on CBT and LINSTOR/DRBD, we don't necessarily recommend enabling it. We have a blocking dev card regarding a bug with LVM lvchange command that may fail on CBT volumes used by a XOSTOR SR. We also have other issues related to migration with CBT.

@nodje said in Create a VM with an existing iSCSI disk:

Is there anyway to achieve an iSCSI mount without automatic LVM VG creation?

You can try with the "RawISCSISR" driver but it's not really tested on our side, I can't confirm that it will work. It doesn't support creation of VDIs but you can use it to access existing LUNs on a target.

@Dark199 In practice you should have more info via dmesg or kern.log. I have never seen this error until now, since it impacts VMs, I am afraid it is something quite serious. Are your disks ok? Do you have enough RAM on the Dom-0?

@dslauter You can test the new RPMs using the testing repository, FYI: sm-3.2.3-1.14.xcpng8.3 and http-nbd-transfer-1.5.0-1.xcpng8.3.

@dslauter Just for your information, I will update the http-nbd-transfer + sm in a few weeks. I fixed many issues regarding HA activation in 8.3 due to bad migration of specific python code from version 2 to version 3.

@fatek We have to release important fixes before the end of the year concerning problems with the HA which I corrected + other changes on the smapi side. I recently discussed that we should release a stable XOSTOR 8.3 version early next year in order to move forward with important projects regarding smapi v3. But I can't be categorical on a date. We lack user feedback.

@dslauter Are you using XCP-ng 8.3? If this is the case I think there is a porting problem concerning python 3...