So the scheduled backup at 1pm this afternoon ran with no issue. As stated previously the Coalesces are adding now now show 2 for vm. edit - Apr 21 11:22:55 xo-ce xo-server[15617]: }, Apr 21 11:22:55 xo-ce xo-server[15617]: summary: { duration: '6m', cpuUsage: '4%', memoryUsage: '29.01 MiB' } Apr 21 11:22:55 xo-ce xo-server[15617]: } Apr 21 13:00:00 xo-ce xo-server[16924]: 2026-04-21T17:00:00.320Z xo:backups:worker INFO starting backup Apr 21 13:00:00 xo-ce sudo[16938]: xo-service : PWD=/opt/xen-orchestra/packages/xo-server ; USER=root ; COMMAND=/usr/bin/mount -o -t nf> Apr 21 13:00:00 xo-ce sudo[16938]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=996) Apr 21 13:00:00 xo-ce sudo[16938]: pam_unix(sudo:session): session closed for user root Apr 21 13:00:06 xo-ce xo-server[16924]: 2026-04-21T17:00:06.941Z xo:backups:MixinBackupWriter INFO deleting unused VHD { Apr 21 13:00:06 xo-ce xo-server[16924]: path: '/xo-vm-backups/138538a8-ef52-4d0a-4433-5ebb31d7e152/vdis/9f7daac4-80a1-41f9-8af0-99b6fe> Apr 21 13:00:06 xo-ce xo-server[16924]: } Apr 21 13:00:19 xo-ce xo-server[16924]: 2026-04-21T17:00:19.536Z xo:backups:MixinBackupWriter INFO deleting unused VHD { Apr 21 13:00:19 xo-ce xo-server[16924]: path: '/xo-vm-backups/6d733582-0728-b67c-084b-56abe6047bfc/vdis/9f7daac4-80a1-41f9-8af0-99b6fe> Apr 21 13:00:19 xo-ce xo-server[16924]: } Apr 21 13:01:23 xo-ce xo-server[16924]: 2026-04-21T17:01:23.971Z xo:backups:worker INFO backup has ended Apr 21 13:01:23 xo-ce sudo[16971]: xo-service : PWD=/opt/xen-orchestra/packages/xo-server ; USER=root ; COMMAND=/usr/bin/umount /run/xo-> Apr 21 13:01:23 xo-ce sudo[16971]: pam_unix(sudo:session): session opened for user root(uid=0) by (uid=996) Apr 21 13:01:23 xo-ce sudo[16971]: pam_unix(sudo:session): session closed for user root Apr 21 13:01:24 xo-ce xo-server[16924]: 2026-04-21T17:01:24.029Z xo:backups:worker INFO process will exit { Apr 21 13:01:24 xo-ce xo-server[16924]: duration: 83708608, Apr 21 13:01:24 xo-ce xo-server[16924]: exitCode: 0, Apr 21 13:01:24 xo-ce xo-server[16924]: resourceUsage: { Apr 21 13:01:24 xo-ce xo-server[16924]: userCPUTime: 31147905, Apr 21 13:01:24 xo-ce xo-server[16924]: systemCPUTime: 14319055, Apr 21 13:01:24 xo-ce xo-server[16924]: maxRSS: 65888, Apr 21 13:01:24 xo-ce xo-server[16924]: sharedMemorySize: 0, Apr 21 13:01:24 xo-ce xo-server[16924]: unsharedDataSize: 0, Apr 21 13:01:24 xo-ce xo-server[16924]: unsharedStackSize: 0, Apr 21 13:01:24 xo-ce xo-server[16924]: minorPageFault: 367979, Apr 21 13:01:24 xo-ce xo-server[16924]: majorPageFault: 1, Apr 21 13:01:24 xo-ce xo-server[16924]: swappedOut: 0, Apr 21 13:01:24 xo-ce xo-server[16924]: fsRead: 5648, Apr 21 13:01:24 xo-ce xo-server[16924]: fsWrite: 16101272, Apr 21 13:01:24 xo-ce xo-server[16924]: ipcSent: 0, Apr 21 13:01:24 xo-ce xo-server[16924]: ipcReceived: 0, Apr 21 13:01:24 xo-ce xo-server[16924]: signalsCount: 0, Apr 21 13:01:24 xo-ce xo-server[16924]: voluntaryContextSwitches: 65983, Apr 21 13:01:24 xo-ce xo-server[16924]: involuntaryContextSwitches: 7745 Apr 21 13:01:24 xo-ce xo-server[16924]: }, Apr 21 13:01:24 xo-ce xo-server[16924]: summary: { duration: '1m', cpuUsage: '54%', memoryUsage: '64.34 MiB' } Apr 21 13:01:24 xo-ce xo-server[16924]: } lines 617-656/656 (END)

@ashinobi in your specific ISO SR problem, you could try this wilsonqanda 9 Jan 2026, 22:41 @Pilow now that you mention that everything is seen as snapshot i remember all my ISO are seen as snapshots too... so most iso cannot be mounted until i drag them in a folder then put them back in same folder so XO could reprocess all the iso correctly. This might be a related issue to all the snapshots for the VMs.

Adding: is there a possibility to see the vm-export progress in the XCP-ng Center in a next update? Actually we only can see the vm-import progress. Thanks!

@olivierlambert I added this feature request in the backlog regarding RPU improvements.

@yannsionneau said: Can you retry with an up-to-date xcp-ng 8.3 please? FYI on recent XCP-ng 8.3 versions the pci-passthrough will enable the ROM expansion bar. The guest VM will have access to it, so no need to pass it via qemu anymore. See my comment on GitHub: https://github.com/xcp-ng/xcp/issues/786#issuecomment-4281846490 Regards, Yann I tried, yes. I confirmed as well on github that the patch does what it suppose to do - it exposes ROM BAR, but that alone is not sufficient to get our cards working. More in my other topic.. I believe it will still fix a lot of issues, and it could potentially fix amd gpu passthrough for some card, but not Phoenix, Raphael and this generation of Ryzen iGPUs (not sure specifically about Barcelo).. But it is a good progress anyway as I wouldn't be able to fix this ever on my own, so I am really glad it is done. Now I will probably get back to the topic and try to patch whatever else is needit and give it to people in a form of rpm package for the time being.. we will see, it is all about time

@MajorP93 said: @florent Thanks! I did not have time (yet) to look into the heap export due to weekend being in between. I will update to current master and provide you with the heap export in the following days. Best regards no problem , the sooner we'll have these exports, the sooner we will be able to indentify what is leaking in your usage, since we already plugged the leaks we reproduced in our labs

@gleveque Hello Can you retry with an up-to-date XCP-ng 8.3 host? PCI expansion ROM are now enabled when doing pass-through. The guest VM can now access the ROM bar. Regards, Yann

@olivierlambert +1 For creating vApps GUI in XO Reason: I recently had this configuration: VM1 - Delay 90 Seconds VM2 - Delay 100 Seconds VM3 - Delay 0 Seconds The VM3 instead of starting first, always starts last without fail. One difference I noticed is that VM3 is UEFI vs VM1 & 2 being in BIOS mode. I read elsewhere in the forum that vApps is the only reliable way to have an order. Maybe if we can somehow ensure that delay works, vApps will become less significant ?

@Pilow I did check this and it definitely completes within the hour. I am testing a lesser value for CR retention to see if this resolves it.

@gregbinsd let us know. If you do use my script. It pulls nodejs from NodeSource so it may not install the latest 24.15.0 tls. If you specific 24.15.0 it will install that version. If you need to change node version with my script use the rebuild option.

@abudef I don't know. I forwarded the question.

@ataxyanetwork I managed to install XOA (Current version: 6.2.2 - XOA build: 20251219) and did some more testing. I am experiencing the same issue when trying to restore from an existing backup. When I create a new backup job, I can perform a filelevel restore without any problems. However, when I rerun the job, I am no longer able to restore from the most recent backup. It only works with the initial backup. Can you also reproduce this ?

@Bytevenidos That's an interesting way of doing this, I'll have to remember it. I think the Fuel Ignition tool has a vhd output, it also produces both ignition and combustion parts for you. Worked pretty good on one test machine, but I need to go deeper into some of the other choices you can type in.

Hello @MathieuRA , @florent Moving the discussion to this thread as it seems to be tackling the same issue: https://xcp-ng.org/forum/topic/11892/xoa-memory-usage/28?_=1776334896974 I reported my findings so far over there Best regards

Thank you so much for your feedback, @Vagrantin !

@denis.grilli The problem is not the performance of the scan ... the problem is, that this storage device only consists of block devices (disks) that should go into standby mode when not used ... but I think I've found a code line that checks if other-config for an SR contains auto-scan: false... I think ...

@yannsionneau Thanks for the update! We are eagerly awaiting your findings! Thanks for looking into it.

@Pilow Thanks for the heads-up, you should be able to add back concurrency as it was before and get similar performance to before the refactoring.