@nasheayahu Hi, you could passthrough the controller hosting these disks if its independant of the disks hosting the XCP itself I guess...

but not really recommended ? perhaps someone has another solution

@LoTus111 nice, but could be better
you're missing the additionnal step in the TIPS section here :
https://docs.xen-orchestra.com/xo5/troubleshooting#memory

upgrading XOA to 8Gb is not enough, you have to tell xo services to be able to use this additionnal RAM.

@johnnezero this could be a plugin in XOA !

@julienXOvates sounds promising !!

@gashorus in last veeam webinar they announced for veeam v13.1 (currently 13.0.1) to be out of beta on XCP-NG plugin...
date : june 2026.

@colomb said:

it could appear when a host is selected in the tree view?

or as a tooltip when the cursor fly-over the name of th VM / host

@pierrebrunet @poddingue

the size is really 2.17Tb, but showing last incremental size on the key
I'll wait for the patch, this is really a visual bug, backup is working okay.

hello there, still XOA 6.3.3 here.

since the last big XObackup & CR reworking, we have an annoying bug

This VM is 2.17Tb

how can be the KEY is 9.1Gb ?
In fact the KEY size is good, but when retention of 10 points is obtained, the merging of last incremental in the first KEY point of the chain erase the size.

So in our restore view, data sizes are all wrong, based on the sum of this key + 9 inc

@florent could you do something about that ?

@poddingue there is a notion of appliance too (group of VMs)
https://docs.xcp-ng.org/appendix/cli_reference/#appliance-commands

where you can start/stop a group of VMs, never tried it, doesn't seem to have a boot order in the vAPP neither

if you have other SRs, migrating VDIs/VMs is known to correct the "visual issue"

the bug just populates a metadata of the VDI making XOA Web UI believe it's a snapshot, and it is not...

a dev told us in another thread they are on it, but it will be a two phase remediation I believe, correcting the bug so that it doesn't reproduce and a way to script out this metadata on impacted VDIs

this is only guesses

@AlexD2006 you are right, this is dangerous.
I also have them old & dusty base copies from the seventies

do not shoot them.

@AlexD2006 see here, we're in the same boat
https://xcp-ng.org/forum/topic/11715/vdi-not-showing-in-xo-5-from-source.

@AlexD2006 this is a current bug, not solved yet

you could try that on one VM : snapshot it, revert to snapshot (VDIs will re appear in the disk tab of the VM), then delete snapshot.
rince & repeat for each VM...

problem of disappearing VDIs could come again.

There is no harm to the VMs, in XO6 you should see the VDIs are there (like in XCPNG Center).
xo-cli calls also work normal.

@AlexD2006 could you check directly in the disks tab of the SR if all VDIs have a snapshot icon on them ?

@vlamincktr XO PROXY from source is pretty reliable at no cost

either use @acebmxer script or @ronivay
here is a quick tuto on an ubuntu VM
https://omnibox.huducloud.com/shared_article/QJ9y1bRSPj9VTbWp6NKaV7yn/installation-xoa-a-partir-des-sources-github-ronivay

first part is XO CE, second part is XO PROXY CE

beware as you delegate some jobs to XO PROXY, to ever upgrade XO PROXY when you upgrade XOA, so that they have the same backup mechanisms/code

one way to double backup performance would be to put a XO PROXY on the host where XOA is not.
you could then dedicate some jobs/vms through this XO PROXY, running at the same time as backups running through XOA.

the hosts would still be in one Pool, but flow of backups would egress simultaneously from XOA and XO PROXY from the two hosts.

@vlamincktr said:

Hosts are managed via XOA.

and so is the backup.

while backups are running, monitor your bandwidths, you will see that backup flow through XOA.
So having the two hosts in their own pool will get you no gain in term of backup performance I guess...
You have the advantage of facilitated network configuration with the two hosts in the same pool as network is pushed from pool config. I could see that as a downside when separating the two hosts.

@McHenry I think depends if the copy is a fast clone, depending of full chain length with 13 points behind, or a full copy of its own that will be independant

@delacosta456 said:

the pool host maximum limit is 3200% right

right

@delacosta456 do not take into account the pool CPU USAGE...

for example I have a pool with one host, here is the POOL CPU USAGE :

yeah right ... 600%

the host :

BUT, if you switch on the STACKED VALUES

you get the POOL CPU USAGE value...

it adds up all core usage, so... not a very good view...

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