@AtaxyaNetwork no error but also no xe-linux-distribution service installed or available...

The sr.scan-driven SMlog growth angle that gumbo2k surfaced is a real lead; there's some context in the storage-related log files reference, but the docs don't go as far as "here's how to throttle it safely on a pool where the underlying disks should spin down." Soft ping to @Team-Storage and @Team-Hypervisor-Kernel: could one of you weigh in on whether other-config:auto-scan=false on the SR is the supported way to reduce scan pressure, or if there's a better lever? I don't want to send anyone down a path that breaks an SR. Apologies if this has already been answered somewhere I haven't seen.

Quick update now that Vates has published their official advisory. First, kudos to the Vates security team for the thorough and timely response. VSA-2026-014 is well-documented and covers the full picture, including a third CVE I had not covered in my earlier posts. VSA-2026-014 confirms what I outlined above: XCP-ng is affected by CVE-2026-43284 (XFRM-ESP) and is NOT affected by CVE-2026-43500 (no RxRPC support). The CVE I had missed: CVE-2026-46300 ("Fragnesia") also affects XCP-ng via the XFRM ESP-in-TCP subsystem. The same esp4/esp6 blacklist mitigation applies, with the same caveat @semarie raised: it will break encrypted private networks on XCP-ng. Now that the VSA and official mitigation guidance are public, I'm releasing the diagnostic script I built. It's Python 3.6, no external dependencies, safe to run on production dom0. It tests whether an unprivileged process can engage the esp4 engine via the XFRM interface inside a user namespace — without touching any exploit code. Since both CVE-2026-43284 and CVE-2026-46300 (Fragnesia) require esp4 or esp6 to be reachable from an unprivileged namespace, and share the same mitigation, a positive result confirms exposure to both. Blacklist esp4/esp6, then run the script again — ACCESS DENIED means both CVEs are mitigated. One important note before running it: please read the code before executing it on any of your systems. This is good practice with any script from the internet, regardless of the source. The code is intentionally short and straightforward so you can review it quickly and satisfy yourself that it does exactly what it says. VSA-2026-014: https://docs.vates.tech/security/advisories/2026/vates-sa-2026-014/ Diagnostic tool: https://github.com/grabesec/XCP_ng_CVE-2026-43284_tester A kernel patch from Vates is in progress. Apply as soon as it lands.

@yomeyo I had this also, but problem disappeared itself. https://github.com/xcp-ng/xcp/issues/793 [image: a3dcbb0b-fe7a-4389-addc-247190039a18] IgorGlock created this issue in xcp-ng/xcp open XN-xenguestagent-rs skips IPv4 at Windows boot #793

@poddingue Thanks for your input. Yes I'm aware that basically everything on the VM is incorporated into the snapshot. Including settings and metadata. This is acctually why I was surprised that the creation date wasn't preserved as part of that metadata. And as you say, if one uses that metric to track VM history. Then it can, and will, throw you off. I'll gladly submit this as a feature request. But my gut feeling is that it is more akin to a bug than missing feature per se. Thanks!

@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

Hi, I just wanted to comment that the provided packages work for all my server. Thank you!

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

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

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

@jerry1333 said: There is nothing else on that host and this is only host in pool but it's using 30% of cpu all the time? it's not using 30% of CPU, you see a graph of cumulated (switch is on) core consumption of your 32 cores. never switch this on. it adds up like that : 32x1%=32%, wrongfully letting you think you are at 30%ish CPU usage.

For my reference later. wget http://downloads.hpe.com/pub/softlib2/software1/pubsw-linux/p1257348637/v76502/hpacucli-9.20-9.0.x86_64.rpm yum install -y --nogpgcheck hpacucli-9.20-9.0.x86_64.rpm hpacucli controller slot=0 physicaldrive all show

@fnf games If it hangs right after detecting the disk, it could be a bootloader or filesystem inconsistency from the snapshot state. Can you try booting the VM with a recovery ISO to check disk integrity or rebuild the bootloader?

To add a bit more detail on the upgrade path: strictly speaking, you do not need to apply outstanding 8.2 patches before upgrading. When you upgrade to 8.3, you are replacing the entire base system with the 8.3 release which already incorporates everything from the 8.2 patch stream. Any 8.2 patches you hadn't yet applied will simply be superseded. That said, applying them first is still a reasonable approach if you want a clean upgrade history and a fully-patched 8.2 baseline before jumping to 8.3. A few things worth checking before you start on a production pool: Check VM compatibility. Run a quick review of your VMs for any that might have specific OS or toolstack dependencies tied to 8.2. Most guests upgrade cleanly but it is worth knowing your environment. Use rolling pool upgrade if you have more than one host. XCP-ng supports rolling upgrades: you migrate VMs off each host, upgrade it, rejoin the pool, then proceed to the next. This maintains VM availability throughout the process. The XO interface handles this workflow if you have XOA. Back up before the jump. Export critical VM configurations or snapshots beforehand. If you use Xen Orchestra for backups, trigger a manual full backup job before starting. The upgrade itself via yum is straightforward: add the 8.3 repo, yum update, reboot. The toolstack and XAPI will handle pool registration after the host comes back up. After upgrading all hosts, run the post-upgrade checks from the docs (pool metadata sync, storage rescans) and verify HA is healthy if you use it.

Not sure the issue, but rebooted the host and everything is fine again. I definitely had rebooted the host twice though after applying the patches and physically unplugged and moved the host.

@olivierlambert Can you provide insights? Is nested virtualization as in running Hyper-V inside a XCP-ng VM expected to work?

Thank you all for your answers—now it's clear.

https://xcp-ng.org/forum/topic/11951/just-fyi-current-update-seams-to-break-nut-dependancies

Thank you for the input everyone. I've tested XenAdminQt and it sees iso library, thank you for advice! Reason for using XCP-ng center is ease of use/simplicity during quick testing deployments in comparison to XO.

Commenting for my future self and others as I just came across this issue too and it's not overly well documented and comments on the forums are often missing a a full story for how to debug and get this working...... When using Ubuntu 24.04, the usual apt method of installing XE Guest Utilities via the command; apt-install xe-guest-utilities Works, but doesn't. It successfully brings through the Memory information through to XO/XOA/XCP-ng Server, but not the IP Address, which is a tad strange. When checking the version of xe-guest-utilities that is contained within the APT Repository that comes configured out of the box with Ubuntu 24.04 using the following command; apt info xe-guest-utilities You can see the response is that it is running version "7.20.2-0" (as at the time of writing, which is before running an apt update command. Even when after running an update command; sudo apt update Then checking what packages are available to be updated using the following command; apt list --upgradable xe-guest-utilities wasn't available for an update past this point unfortunately. So to uninstall xe-guest-utilities installed via APT, simply run the following command; sudo apt remove xe-guest-utilities Then install via XO/XOA/XCP-ng Guest-Tools.iso Mount + Command Line by following these steps. Firstly, Select the guest-utilities.iso from the Disk within the XO/XOA/XCP-ng Platform for the VM. Then SSH into the box/console view and run the following commands; sudo mount /dev/cdrom /mnt sudo bash /mnt/Linux/install.sh sudo umount /dev/cdrom What you will notice when you run the second command is that gets installed here is "xe-guest-utilities_7.30.0.12_amd64.deb" - So is further ahead. Then you'll need to use the following commands to start the service on boot and also start the service. systemctl enable xe-linux-distribution.service systemctl start xe-linux-distribution.service And that now results in the IP Address of the virtual machine flowing through to XO/XOA/XCP-ng, which ever you are using.