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 !

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

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

No worries, it happens! Glad you found the problem

@DustinB doesn't it use the exact same mechanism? I have to find out.

@semarie This pool is still on 8.2.1, we are trying to add this host in order upgrade with little to no downtime.

@bleader thanks for the tip. You see my knowledge in redhat based systems is almost non existant. Think I'm almost 99% debian and 1% ubuntu (and that not by choice) So I will take care of redeploying the script as soon as I upgrade, should be easily noticeable since monitoring will loose access and yell at me.

@nikade said in Every virtual machine I restart doesn't boot.: @DustinB yeah im guessing the VDI isn't attached to the VM for some reason, based on the screenshot. Im also wondering if he ever rebooted the VM's after installing them with PXE Right, it's a likely answer... but even then I would've expected his PXE server to just restart the installation process all over again... assuming that the disk is attached to the VM etc and that PXE boot isn't disabled automatically like it is with an ISO after first boot. haha