@Tackyone said:

@MajorP93 said:

@Tackyone said:
live migrates between non-pooled [...]

Hi,

AFAIK this is not possible. Live migration does only work within the same pool. So you can not live migrate VMs to another pool / host that is not part of the pool.

But we do that all the time? - i.e. Two non-pool hosts, live migrate between them (these happen to have the same CPU / family etc.)

Okay I assumed that you use shared storage.

From the XenServer 8.4 "Migrate VMs" docs:
"Storage can only be shared between hosts in the same pool. As a result, VMs can only be migrated to hosts in the same pool."

So for classic live migrations that do not transfer the virtual disk you have to be on the same pool.

What you are describing must be a storage live migration then (XenMotion). That should work across pools, yes. I stand corrected because I did not factor in this variant in my initial answer.

//EDIT: also there is no such thing as non-pool hosts. Even a single host setup has it's own pool.

@Tackyone said:
live migrates between non-pooled [...]

Hi,

AFAIK this is not possible. Live migration does only work within the same pool. So you can not live migrate VMs to another pool / host that is not part of the pool.

Regarding mixing and matching different CPUs within the same pool: do note that you can not mix AMD/Intel together. Different CPU models of the same brand within a pool will work though. And it behaves just like you said: XCP-ng hosts will agree on the least common denominator regarding CPU features and use that across the pool in order to ensure that (live) migrations will work.

@acebmxer @pkgw Do / did you guys have any VMs set to "best-effort" under VM's HA-settings?

I encountered the exact same issue (HOST_NOT_ENOUGH_FREE_MEMORY) and was able to completely solve it by changing all VMs from "best effort" to "restart".

Best regards

@ph7 As a suggestion: it would improve readibility if you paste your logs on Vates official pastebin tool: https://paste.vates.tech/ and share the links here instead of posting the logs in multiple messages.

Due to the fact that this is the second XO release in a row that broke backups I do wonder: are all backup job types being tested via automated unit tests? Are those tests being run multiple times in order to catch issues that do not occur during every single test run? There must be a reason for QA not catching these kind of issues…

Actually after latest XO update I also started to see "body timeout error". Interestingly on my metadata backup job.

@the_jest According to my own tests not rebooting after patching XCP-ng hosts can cause several issues. Thats why Xen Orchestra GUI notes to reboot after updating. Documentation has further explanation for this and explains whole update procedure.

Hello!
Just an idea but maybe the PCI link speed you are seeing is related to some sort of energy saving feature?
Background: I have a Nvidia GPU in my PC and when there is no load the PCIe speed is lowered from PCIe 4.0 to 1.1 due to energy saving feature.

So yeah, I think @teddyastie 's idea is a good approach here. Try how your setup behaves during a workload.

@marcoi I found out what to enter for "vendor" by running "dmidecode -s system-product-name" on one of my XCP-ng hosts:

[15:45 xcpng01 ~]# dmidecode -s system-product-name
Super Server

//EDIT: in your case it looks like you should enter "To Be Filled By O.E.M." for vendor. Not "To Be Filled By O.E.M. (To Be Filled By O.E.M.)"

For my fellow Supermicro enjoyers: I was able to get the plugin to show some information.
Even if there are some parts missing it is better than nothing in my opinion.

Go to settings --> plugins --> ipmi-sensors --> "+" --> Add --> Fill information and add the vendor string as well as the Sensor Reg Ex.

Hope this helps.

Best regards

@All-Ki Thanks for your work on that plugin!

This is the ipmitool sdr list output on one of my Supermicro based XCP-ng hosts, how can I derive the correct plugin settings (regex) from that?

[13:36 xcpng01 ~]# ipmitool sdr list
CPU Temp         | 59 degrees C      | ok
System Temp      | 30 degrees C      | ok
Peripheral Temp  | 29 degrees C      | ok
M2NVMeSSD Temp1  | no reading        | ns
VRMCpu Temp      | 31 degrees C      | ok
VRMSoc Temp      | 43 degrees C      | ok
VRMABCD Temp     | 34 degrees C      | ok
VRMEFGH Temp     | 36 degrees C      | ok
DIMMA1 Temp      | 36 degrees C      | ok
DIMMB1 Temp      | 35 degrees C      | ok
DIMMC1 Temp      | 34 degrees C      | ok
DIMMD1 Temp      | 33 degrees C      | ok
DIMME1 Temp      | 38 degrees C      | ok
DIMMF1 Temp      | 37 degrees C      | ok
DIMMG1 Temp      | 36 degrees C      | ok
DIMMH1 Temp      | 34 degrees C      | ok
FAN1             | no reading        | ns
FAN2             | 4200 RPM          | ok
FAN3             | no reading        | ns
FAN4             | no reading        | ns
FAN5             | no reading        | ns
FANA             | 3600 RPM          | ok
FANB             | 3600 RPM          | ok
12V              | 12,05 Volts       | ok
5VCC             | 5,02 Volts        | ok
3.3VCC           | 3,33 Volts        | ok
VBAT             | 0x04              | ok
VDDCR            | 1,11 Volts        | ok
VMEMABCD         | 1,23 Volts        | ok
VMEMEFGH         | 1,22 Volts        | ok
VDD_5_DUAL       | 5,16 Volts        | ok
VDD_33_DUAL      | 3,28 Volts        | ok
SOCRUN           | 0,87 Volts        | ok
SOCDUAL          | 0,89 Volts        | ok
Chassis Intru    | 0x00              | ok
PS1 Status       | 0x01              | ok
PS2 Status       | 0x01              | ok

Thanks and best regards

@rzr Installed those security update candidates in my XCP-ng test environment.
So far no issues whatsoever. Basic operations all work. VMs running etc.

@TeddyAstie said:

param-name=platform nomigrate=true

Hi @teddyastie , thanks for working on this.

As per policy I am not allowed to test these parameters in production which is why I had to create a small test setup for being able to try your settings.

I deployed a Debian 13 VM via Cloud-Init on a XCP-ng test host using the official Debian 13 cloud image.

After deploying the VM I had the issue of slow boot.

After shutting the VM down, applying the settings that you just sent and starting it again I can say that you are on the right track!

In my case the boot time is completely normal now and on par with Debian 13 VMs that use BIOS instead of UEFI (for booting).

As this is a workaround and disables live migration this is not an option for production environments but good to have a workaround available anyways for sure!

Do you think it is possible to fix this on hypervisor level while still having live migration etc. enabled or do we have to wait for an upstream fix within Linux kernel tree?

@olivierlambert Awesome work on tracking down the issue!
Very nice, detailed, technical writeup.

@TeddyAstie These spinlock events that cause slow boot also happen on my Debian VMs. Also AMD Epyc CPU in my case.

I noticed that this only happens for UEFI enabled VMs. VMs booting in BIOS mode do not have this issue.

Hi,

I installed the update candidates within my test environment.

Updates installed fine, after reboot all looks good so far.

No apparent issues can be seen.

@pierrebrunet Thanks for fixing this critical issue!

Do you have any plans regarding internal automated tests that would ensure that critical issues like these (deletion / corruption of backups etc.) do not get shipped?

Best regards

@olivierlambert said:

Yes we use them in production since more than a year without any issue.

Only with a caveat: they only work in environments where DMC (Dynamic Memory Control) feature of XCP-ng is not being used.

Reason: Rust-based Xen guest agent currently has no ballooning driver implemented which is present in Citrix Xen guest agent as confirmed by XCP-ng developer here: https://xcp-ng.org/forum/topic/11955/memory-ballooning-dmc-broken-since-xcp-ng-8.3-january-2026-patches/13?_=1779445511424

@poddingue Hello, while I -as a user- appreciate that you coordinate these bug reports I do wonder: is the GitHub issues section of Xen Orchestra really the preferred way of reporting issues?
This is also a valuable information for me personally.
In the past I felt like issues at the XO github repository often did not get the level of attention by the developers compared to reporting the issues here on the forums.
I wrote some XO github issues in the past as well and noticed that some never got any response and/or update.
Reporting these things here on the forums mostly felt more "productive".
Looking forward to getting some insights in this regard.
Thanks and best regards

@manilx No I did not. I replied to this thread in general not to your post. When looking at the answers to your specific post where you reported the RPU issue I can only see 1 reply which was written by Stormi (asking for logs).

Going forward: you can identify replies to your posts by either looking at posts that quoted your message or tagged your username using the @ character.