Xen Project covered this as XSA-489.

Interesting Maybe a way to create the vTPM in XO? Adding @julienxovates in the loop

Ah very good, so it was even easier than this. You had the Xen blk driver but instead of using an UUID, the appliance was having a hardcoded sda. Keep us posted

@delacosta456 said: the pool host maximum limit is 3200% right right

@CyaVMware said: Have a simple question for someone. Looking at migrating a client to XCP. Currently they have a data disk that is exactly 2TB in VMware. My question is the limitation anything OVER 2TB, or is it 2TB AND above? I'd prefer not to use the VMware converter tool to shrink the disk to 1.99TB if I don't have to. VHD format has a strict limit of roughly 2TB (around 2040 GB), so if your client’s VM disks are larger than this then you’re going to have trouble with VHD format. However QCOW2 support is almost here (production ready) about to reach RC2 state, once this reaches stable you’ll be able to safely reach a max of around 16TB. That is if your using ext4 based SR, other Filesystems have different limits. If using a networked file sharing protocol service then, the limit of the host server’s filesystem applies. Though QCOW2 VDI has a limit of 16 TiB.

@dinhngtu Thanks for the fast response, as always.

Hello all, XenClean 9.1.148 Prerelease is now available with a fix for error 1605 during execution. This is a XenClean-only prerelease. https://github.com/xcp-ng/win-pv-drivers/releases/tag/v9.1.148

@benapetr said in New project - XenAdminQt - a cross-platform GNU/Linux, macOS, Windows native thick client: you can switch between them nope, that just 2 from multiple nics. Need press add ip address to add other NICs. Now i see how it works.

@olivierlambert In my understanding, Anti affinity tags only looks for the tags that are attached to the VM. For example: Datacenter 1 Host 1 VM1-1 Host 2 VM1-2 Datacenter 2 Host 3 VM2-1 Host 4 VM2-2 VM1-1 and VM1-2 should be able to migrate to Host 1 and Host 2. VM2-1 and VM2-2 should be able to migrate to Host 3 and Host 4. But VM1-1 and VM1-2 should never be able to migrate to Host 3 and Host 4. VM2-1 and VM2-2 should never be able to migrate to Host 1 and Host 2. With the current (Anti) Affinity tags, it will only look to the tags attached to the VM, so in the example it would be possible for VM1-1 to go to Host 4, if VM2-2 would be at Host 3 together with VM2-1. But if we could tag the hosts, it would not be possible for VM1-1 and VM1-2 to be on Host 3 and Host 4

@gregoire said: @olivierlambert I added this feature request in the backlog regarding RPU improvements. Hello, Thanks all ! Totally agree with @poddingue , be able to exclude VM which has: PCI attached devices Local storage ( maybe ? ) Could be a great option !

@Pilow Apologies for the late reply. Thank you for sharing the work around. I have tried it and confirmed that the work around works. I hope they can find a solution for this issue.

@Team-Storage I am also having the same issue. Here is link on my forum post: https://xcp-ng.org/forum/topic/12093/lost-connection-to-iso-repository/9

@yannsionneau Thank you very much. Please let me know if there’s anything I can help with.

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)

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!

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