@MajorP93 said: What you are describing must be a storage live migration then (XenMotion). That should work across pools, yes. I stand corrected because I did not factor in this variant in my initial answer. Yes, that's it - sorry - I should have been more explicit, even if 'lumbers along' wasn't a hint //EDIT: also there is no such thing as non-pool hosts. Even a single host setup has it's own pool. Pedantic, but true I technically meant 'not hosts in the source pool' I guess.

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

@pierrebrunet Hi! I'll send you xo logs of the errors. In the meantime, I've deleted "Long-term retention of backups" settings and I no longer get duplicated VMs on the DR pool. [image: 1784562046612-cb037ec5-7ad7-4c3f-8a76-1b5be06574f7-image.jpeg] So it seems that this setting is also being used for replication and I cannot use it. Don't have the space for it on my storage, with thick snapshots on lvmoiscsi.

That timeline is the clearest version of this yet. xen04 going down the same way as xen05 makes the race look real to me rather than coincidental, unless I am reading the ordering wrong. The fault lands inside drbd_bm_count_bits, so in the DRBD module itself, which makes me think this is an upstream LINBIT question as much as an XCP-ng one. I do not know enough about how that module gets packaged here to say who owns the fix though. Might be worth another mention to @Team-Storage so someone can open your bundles with your post #10 next to them. On the padding idea I am out of my depth: no idea whether LINSTOR can be told to pre-round a volume at creation, but asking LINBIT directly seems worth a try since it would sidestep drbd_bm_resize entirely.

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

@acebmxer I can confirm that, we'll fix it, thanks

@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

Perfect, thanks for your feedback!

@poddingue Thank you for all the details and advise. I will reach out to them to see if it is anywhere on the project horizon. Thanks much, and have a great day!

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

@pierrebrunet Hello! I've checked B2 logs and found some errors like you had foreseen. I had a look and this kind of 500 INTERNAL ERROR several times on other jobs that seem ok. How many retries does XO attempt to send the part when this happens? I'll do another run that includes only a few large VMs. BTW, is there a way to interrupt the job withou restarting XO ? REST.PUT.PART Weekly/xo-vm-backups/60b4d2a7-3f91-f0f9-b0a0-f834df3ff9ee/20260705T070618Z.xva "PUT /zzzzzkly/xo-vm-backups/60b4d2a7-3f91-f0f9-b0a0-f834df3ff9ee/20260705T070618Z.xva?partNumber=3954&uploadId=4_ze092693d1b65962e9fe6051b_f25969add7e42e384_d20260713_m140016_c003_v0312040_t0013_u01783951216751&x-id=UploadPart HTTP/1.1" 500 INTERNAL_ERROR 145 - 3762 3762 "-" "aws-sdk-js/3.1065.0 ua/2.1 os/linux#5.15.0-185-generic lang/js md/nodejs#24.18.0 api/s3#3.1065.0 m/N,a,c,E,e xen-orchestra-fs-4.9.2" - - - TLS_AES_256_GCM_SHA384 AuthHeader s3.eu-central-003.backblazeb2.com TLSv1.3 - -

Just FYI, we had some issues with some Debian VMs for instance, with old kernel where the VM would suddenly take 100% CPU and would we completely frozen and unresponsive. It was in fact Debian enabling the suspend, the guest would suspend and trigger a bug in xen PV driver in the guest kernel which would never be able to wake up anymore. Newer kernel don't have this issue and are able to wake up. I'm quoting Debian here but it might very well happen on other distro

@simonp , thank you very much and all of your team ! ! ! Keep up the outstanding work. Regards, Marc

Hi @acebmxer, thanks for reporting, we identified this bug internally already, we're going to fix it once root cause is found.

Hi Everyone, If I may advertise what I did you have a dedicated thread about my project, this is an easy to setup XCP-ng and XO from the source solution. Sorry sharing the link to the topic as is couldn't find better way to do that : XCP-ng HL — an ISO for home labs, deploy any XOA image from XO Lite directly Essentially you deploy XCP-ng ISO and then in XO Lite deploy XOA section you can deploy your prebuilt or XOA VM directly. Hope that helps Home labers to get in to XCP-ng easily. Same here this is still work in progress, also I'm personally already using this version in my lab. Any feedback is welcome ! With regards.

Ping @Team-Storage

Hi @dvdwx, RBAC is available only at the REST API level, not through the XO6 UI. UI compatibility with RBAC is currently under development. For the topology, this is something that has been here for a long time, so I may be wrong since I don't have the full history. However, if I look at the code, creating the topology selector requires knowing how many CPUs are available in the pool. Since a self-service user doesn't have visibility into the pool, they can't access this kind of information.

@john.c Unfortunately, I cannot answer your question in the affirmative. I only use XCP-ng with TrueNAS. @Team-Storage have y'all had a chance to take a look at the bug report I filed? This issue is quite serious.