For now I have upgraded all hosts to use --enablerepo=xcp-ng-linstor-testing to get kmod-drbd.x86_64 0:9.2.18-2.0.xcpng8.3 That way it is there to be picked up if the host crashes again. https://github.com/xcp-ng-rpms/drbd/blob/master/SPECS/kmod-drbd.spec https://koji.xcp-ng.org/buildinfo?buildID=5747 [12:15 ovbh-pprod-xen04 ~]# yum upgrade --enablerepo=xcp-ng-linstor-testing Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile Excluding mirror: updates.xcp-ng.org * xcp-ng-base: mirrors.xcp-ng.org Excluding mirror: updates.xcp-ng.org * xcp-ng-updates: mirrors.xcp-ng.org grafana/signature | 810 B 00:00:00 grafana/signature | 3.0 kB 00:00:00 !!! xcp-ng-linstor-testing/signature | 473 B 00:00:00 xcp-ng-linstor-testing/signature | 3.0 kB 00:00:00 !!! zabbix | 3.0 kB 00:00:00 zabbix-non-supported | 2.9 kB 00:00:00 (1/3): grafana/primary_db | 879 kB 00:00:00 (2/3): xcp-ng-linstor-testing/primary_db | 2.4 kB 00:00:00 (3/3): zabbix/x86_64/primary_db | 114 kB 00:00:00 Resolving Dependencies --> Running transaction check ---> Package kmod-drbd.x86_64 0:9.2.16-1.0.xcpng8.3 will be updated ---> Package kmod-drbd.x86_64 0:9.2.18-2.0.xcpng8.3 will be an update ---> Package zabbix-agent.x86_64 0:7.0.27-release1.el7 will be updated ---> Package zabbix-agent.x86_64 0:7.0.28-release1.el7 will be an update --> Finished Dependency Resolution Dependencies Resolved ============================================================================================================================================================================================================================================================== Package Arch Version Repository Size ============================================================================================================================================================================================================================================================== Updating: kmod-drbd x86_64 9.2.18-2.0.xcpng8.3 xcp-ng-linstor-testing 2.8 M zabbix-agent x86_64 7.0.28-release1.el7 zabbix 660 k Transaction Summary ============================================================================================================================================================================================================================================================== Upgrade 2 Packages Total download size: 3.4 M Is this ok [y/d/N]: y Downloading packages: Delta RPMs disabled because /usr/bin/applydeltarpm not installed. (1/2): zabbix-agent-7.0.28-release1.el7.x86_64.rpm | 660 kB 00:00:00 (2/2): kmod-drbd-9.2.18-2.0.xcpng8.3.x86_64.rpm | 2.8 MB 00:00:01 -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- Total 2.8 MB/s | 3.4 MB 00:00:01 Running transaction check Running transaction test Transaction test succeeded Running transaction Updating : kmod-drbd-9.2.18-2.0.xcpng8.3.x86_64 1/4 Updating : zabbix-agent-7.0.28-release1.el7.x86_64 2/4 Cleanup : kmod-drbd-9.2.16-1.0.xcpng8.3.x86_64 3/4 Cleanup : zabbix-agent-7.0.27-release1.el7.x86_64 4/4 Verifying : zabbix-agent-7.0.28-release1.el7.x86_64 1/4 Verifying : kmod-drbd-9.2.18-2.0.xcpng8.3.x86_64 2/4 Verifying : kmod-drbd-9.2.16-1.0.xcpng8.3.x86_64 3/4 Verifying : zabbix-agent-7.0.27-release1.el7.x86_64 4/4 Updated: kmod-drbd.x86_64 0:9.2.18-2.0.xcpng8.3 zabbix-agent.x86_64 0:7.0.28-release1.el7 Complete!

Got this issue since 2026-07-12.

@TeddyAstie From what I've tried...It won't work at all in Linux. It kind of works in Windows, and while I do see some load on the GPU when running something, there's as much if not more load on the CPU. It's not what I expected at least. I've never really gamed on PC, and definitely never Linux. My only uses for GPU's have been in media composition which was always on dedicated systems and Nvidia GPUs. More recently I've been doing some AI tasks, again with passed-through NVidia GPUs. Side tangent... I ran into another workload last night where the app wanted OpenGL...But OpenGL doesn't work with the "normal" VGA adapter in XCP-ng, and I don't have a GPU on that particular pool to try a pass-through. That lead me to VirGL, but it doesn't look like that's gone anywhere.

@poddingue Oh yes (dumb me). Very good, we'll see if they respond (as now there's two @ refferences). Happy Day

@Bastien-Nollet Perfect, thanks Bastien! Thanks for looking into this, I really appreciate how responsive everyone at Vates is on this forum.

Hello, Any answers to these questions? This morning, the backup didn't run correctly (the first delta backup after yesterday's full backup). For your information, this is a delta job that has been running perfectly for months. I simply added the CR. For your information, we have not changed the status of the CR VM; it has not changed. Here are the errors [image: 1784790547581-xcpng.png]

Perfect, thanks for your feedback!

@poddingue yeah I saw it now but I was more like mentioning that many people also have the same problem. Hope it gets resolved soon

Thanks a lot @msupport ! @all-ki could you add this to our IPMI doc to be published ?

@pierrebrunet said: Hi, just to be sure, are you saying it is working ok apart one task 8 days ago? Yes, after I adjusted the time it's working

@john.c See this post - https://xcp-ng.org/forum/post/105564

Thanks for the feedback @norpan , worth it! Ping @florent

@pedro_udifar Hi, You can try again with minPartSize=100000000 indeed. But I would advise you to contact B2 directly. They should have a clearer error to show instead of a 500. Thanks for your patience and your help

Hello @kazual82, Lot of question here, I'll try to answer my best: Is there a known XCP-ng 8.3, blktap, or Xen issue matching this frontend/backend state mismatch? No, I never saw this kind of issue but I appreciate all your investigation. Can tapdisk or the Xen backend lose a completion while both sides remain in state Connected? It'd surprise me because my opinion is tapdisk is sending to much completion notifications. My guess is a race condition somewhere that loose the notification. Is xen_blkfront.max_ring_page_order=3 considered safe and recommended with this backend? Yes, it's safe but there is no recommendation on that because any max_ring_page_order should work. Could increasing the ring size reduce the probability of this failure, or would it only mask it temporarily? I guess it reduce the probability. Is the fact that persistent grants and indirect descriptors are not negotiated relevant? No, it's expected, tapdisk doesn't support those features. Are there additional tapdisk, xenstore, event-channel, or ring diagnostics that we should enable before the next incident? I don't see what we can do. If it appends again I'm curious to investigate. Install blktap-debuginfo and devtoolset-11-gdb to attach the debugger on tapdisk and see the state of the blkif ring, that could be an info if the requests are still in the ring. If you can open a support tunnel, I will investigate. Are there candidate packages or patches that would be useful to test on one canary host? The next update, yet to be release, will add a bunch of fixes for QCOW2 support in tapdisk and sm. I recommend this update. Could the use of a multi-terabyte QCOW2 VDI on an LVM SR be relevant to this failure mode? I fear this is a QCOW2 issue only linked to the recent release of the feature but no real clue here. The fact that tap-ctl stats answer is the proof that there is no deadlock on the tapdisk side, that's a small reason of satisfaction.

Created two pull requests for the issues: https://github.com/xenserver/xe-guest-utilities/pull/180 https://github.com/xcp-ng-rpms/xcp-ng-pv-tools/pull/14 @rzr , for the latter, I don't have any experience with xcp-ng's testing suite, so I'll need guidance assuming testing is warranted.