@yannsionneau That's great to hear, I can't wait to see what it'll look like.

@anthoineb We captured another occurrence, this time on os-ott-data-3-2, running on hypervisor 172.30.50.191. The guest-side state was: 31 requests in flight all 32 blkfront tags busy I/O PSI full around 97% 6 tasks in D state no completed xvdb I/O progress The VM was still running and its local OpenSearch HTTP endpoint was responsive, but the node had already disappeared from OpenSearch cluster membership. On the hypervisor: tapdisk was responsive to tap-ctl reqs_outstanding: 0 tap request counters: 0/0 all xenbus request counters were balanced no tapdisk errors were reported We attached GDB to the affected tapdisk before reboot. The main thread was sleeping in scheduler_wait_for_events(), and the captured blktap/shared-ring state was: req_prod = 0 req_cons = 0 rsp_prod = 0 rsp_prod_pvt = 0 n_reqs = 32 n_reqs_free = 32 The complete shared ring was empty. Therefore, at capture time, there were no requests waiting in the tapdisk ring, while the guest still believed that 31 requests were in flight and all frontend tags were occupied. GDB detached normally. After the diagnostic window, the VM was rebooted and successfully rejoined the cluster. At the time of the failure, this VM was still running with xen_blkfront.max_ring_page_order=0 and 32 tags. After reboot, the persistent setting became active: xen_blkfront.max_ring_page_order=3 nr_tags=256 Could this evidence indicate that requests or completion notifications are being lost between blkfront and the backend before they become visible in the tapdisk shared ring? We can provide the complete GDB backtraces and ring dump if useful.

@olivierlambert Working again. Thanks!

@Jonathon Indeed I missed that part in your message, my bad. If the hosts still crash even after the 9.2.18 module has been loaded (update + reboot), please keep us informed. Thanks!

I did indeed make both changes at the same time. The status of the backup this morning is completely normal (even on ADDS VMs). I think that the forced shutdown in order to correct the status error caused a problem during the next delta. Why only on ADDS VMs? I can’t explain it. I had no errors on these VMs at that time. (Especially since I have another full backup job that doesn’t cause any problems).

I have been in the Network Enterprise business for 28 years. I live in Virginia which is heavily populated with Data Centers and adding more all the time. However, we have quite a few customers especially municipalities which are saying NO to having anything hosted with cloud computing due to security and endless rising cost. We have been deploying xcp-ng in quite a few installations, on customer premise. I think VATES will find there is a whole other market in these areas they can reach. That being said, Thanks to VATES and all who have worked on solutions for this! It truly benefits everyone!

I got this running and when I set up a catalog and baseline the report tells me that it has nothing in the catalog. Is that because it doesn't understand XCP-ng or because my hardware is old enough that it has dropped out of the catalog? I have two PE R630 and one PE R730. I tried both the full default Dell catalog as well as the one that limits to BIOS and firmware updates.

@olivierlambert I have a full Realtek 8125/8126/8127 update to replace the existing r8125 driver, as required to support newer chips. The new 8125 driver drops the 8126 support but you just install the 8126 if needed (requires newer 8125 driver to avoid module conflicts).

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]

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

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