@bnerickson said: Thanks for the reminder, for some reason it was not seen before (all applogies). I'm unsure where to report this, Here or in related open projects directly (assuming you know where to look at) but let me guide you. but syslog reports the following warning when a VM starts: (UDEV-WORKER) cpu0: Process '/bin/sh -c '[ -e /dev/xen/xenbus ] && [ -e /sys/devices/system/cpu/cpu0/online ] && echo 1 > /sys/devices/system/cpu/cpu0/online'' failed with exit code 1. Good catch, it's a bad habit to use AND (&&) in conditionals. Hardcore programmers prefer to use OR (||) in scripts, this practice prevents failed exit and make debugging easier (with set -xe). (...) > ACTION=="add", SUBSYSTEM=="cpu", RUN+="/bin/sh -c 'if [ -e /dev/xen/xenbus ] && [ -e /sys$devpath/online ]; then echo 1 > /sys$devpath/online; fi'" That would work, What about this "simpler" form ? [ ! -e /dev/xen/xenbus ] || [ ! -e /sys$devpath/online ] || echo 1 > /sys$devpath/online Could be harder to read, but I get used to. If you want you can contribute the fix directly to upstream since the file is public at: https://github.com/xenserver/xe-guest-utilities/blob/master/mk/xen-vcpu-hotplug.rules About the exec bit, here is the line that should be changed: https://github.com/xcp-ng-rpms/xcp-ng-pv-tools/commit/3d134fbd0f3ac9e2f3cfa914e38b33529635d458#r183816712 @bnerickson, If you need any mentoring for OSS contributions, I would be more than a happy to help. Since it's a lowest priority you can take all the time you need, and If too busy, no problem we can do it for you and then backport the change to XCP-ng. 1 stormi committed to xcp-ng-rpms/xcp-ng-pv-tools Build the tools from the sources - Build 32 bit and 64 bit xe-guest-utilities - Build TGZ, RPM and DEB packages for xe-guest-utilities - Put the result into the ISO and the ISO into the xcp-ng-pv-tools RPM (as before). It's a bit hacky, but as the binaries are statically linked, this peculiar build process should work.

yes we'll enhance this behavior in a coming release ! thanks

@MathieuRA I noticed you merged https://github.com/vatesfr/xen-orchestra/pull/9787 I just tried it. And it does seem to fix my original issue! Thank you! I am always impressed by you guys. Making testing and reporting upstream (to you guys) a good experience! Elise-FZI opened this pull request in vatesfr/xen-orchestra closed fix(xo6): remove dev routes from prod #9787

Thanks, Florent, for the explanation.

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!