@Jonathon I think @mathieu-l asked it you rebooted after installing drbd 9.2.18 from test repository. Your message sounds like you rebooted after installing 9.2.16 but not after applying the 9.2.18 update from test repository.

Thanks for the reports and the detailed analysis. I'll make sure that the XOA team is notified.

Unfortunately, I need to have a CR job that works because we have a constraint this weekend. However, I'm available to provide you with logs if necessary. I could let you know if changing the status of the replicated VM (from suspended to forced shutdown) has an impact on the backup chain. (with normal snapshot).

@ataxyanetwork , just checking in on this. No rush at all. Thanks!

i think im seeing the same with fake cpu spikes. I started a second pool yesterday to patch and left it on over night. typically i just shut it down once done so the servers dont get too far behind patching. Under the pool stats im seeing spikes but under hosts nothing. It doesnt really bother me, but figure i add to the thread that im also seeing it. [image: 1784817154694-c75fecec-d618-4f05-a931-edea6bc6ecce-image-resized.jpeg] [image: 1784817189696-1b9ea5aa-d349-4ff8-af89-30a970d36fbb-image-resized.jpeg] [image: 1784817219194-0f579999-cd96-4216-a0d4-d637ea5febf1-image-resized.jpeg]

@anthoineb Thank you. We have now installed the required packages on all three hypervisors hosting the OpenSearch data VMs: blktap-3.55.5-6.7.xcpng8.3.x86_64 blktap-debuginfo-3.55.5-6.7.xcpng8.3.x86_64 devtoolset-11-gdb The debuginfo package was not exposed by our internal yum mirror metadata, but we found the exact matching RPM in the official XCP-ng 8.3 stable-updates repository. No services or hypervisors were restarted during the installation. Could you please provide the recommended gdb commands for attaching to the affected tapdisk process and inspecting the blkif ring? In particular, it would be helpful to know which structures, fields and threads should be captured. We plan to test the attach procedure manually on a healthy tapdisk first. After that, we can add a short pre-reboot diagnostic pause to our recovery controller so that the GDB data can be collected during the next occurrence before the VM is rebooted.

Two PRs out of the lowest priority bug ever, that made my morning.

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

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

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

@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

@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

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.

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

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

Perfect, thanks for your feedback!