XCP-ng 8.3 updates announcements and testing
-
My master host hung on reboot, after about 10 minutes I forced the power off, and then back on. Host is HP T740 Thinclient with AMD v1756b processor, 64GB of DDR4 SODIMM, Intel dual x520 PCIe card, and an Intel i226-v in the a+e slot, plus the onboard Realtek NIC, BIOS at 1.20 which I think is still current for this model. All three hosts are identical with possible exception of x520 card revisions, host 3 might have an older revision (donations accepted for x710 based cards
)Otherwise everything went as planned, all three are updated and all three needed to have the toolstack restarted to see the stats. I only have 2 small Linux VMs on this system right now, and both of them started fine.
There were no stats in XO-Lite either, I was doing the second and third hosts from XO-Lite to see if XO was getting mad. The second and third rebooted without issue and something I'll look into with the next update, the delay on master could have been the VMs trying to auto start where I remembered to turn that off for the other two hosts.
-
Installed on my Test pool with 2 HP EliteDesk 800 G3 mini. Except the no stats in XenOrchestra. Did some VM migragration between hosts, reboot testes (only Linux VMs though) and so far no issues.
-
Could you please attach
/var/log/{xensource.log,daemon.log,xcp-rrdd-plugins.log}from the time after the reboot and before the toolstack restart?Also: does this reproduce if you reboot again - would you still have no metrics until toolstack restart? Because if not, this is entering paranormal territory
UPD: I've just updated xapi from 24.39 to 25.6 myself - stats are working after the reboot and I can see them in XenOrchestra, no additional toolstack restart required.
-
@andriy.sultanov said in XCP-ng 8.3 updates announcements and testing:
does this reproduce if you reboot again
Yes, this does. Logs have been provided via pm.
-
@andriy.sultanov
Same issue after another reboot. The stats on host just flatline. No CPU usage or anything.
See screenshot
I attached log files
daemon.log.txt xcp-rrdd-plugins.log.txt xensource.log.txt -
@bufanda Thanks!
Hmm, can't see anything suspicious either in your logs or @abudef'sSince you said it reproduces if you reboot the host again, I'd really appreciate if you could send the result of
rrd2csvrunning for 30 seconds or so on a system that doesn't have the stats working - so before any toolstack restarts. -
@andriy.sultanov
I ran it for a minute. -
If still needed, I can probably get you the rrd2csv next week, I need to unrack my system and move it to a new mobile rack. A large expense that I'm not happy to have to do, but now needed going forward (it's a work thing, where I prototype workflows for my production system)
-
@Greg_E Thanks, but that will not be necessary - I think I've figured out where the problem lies now. Good luck with the move
-
The move is more about spending yet more personal money for something that is primarily used for learning what I need to know for work (a rack, UPS, and some odds and ends at $800). Or half of it is, half of it is a VMware system and that's to let me learn what I need to leave this job and find one that pays more. And then move that work to something easier to use that costs less. Still amazed at how many places just took the price increase and are still not making plans to move to something else, even if they are cutting core counts in half to save half of that new money. But I'm also seeing that the general trend in IT around where I live is to get into a Silo, and never ever take on another task to fill a need. This way you never want to move laterally to other products, just keep doing the same things the same ways until management gets tired of hearing "we can't do that" and fires everyone to replace them with an MSP (or other contractor).
So for the off topic rant, feeling salty again today.
-
New security update candidates for you to test!
We're still working on the updates that you started testing (and a few more), but right now there's an emergency: a security update.
Yet more vulnerabilities in Intel hardware, addressed in two complementary ways: patching Xen and updating Intel microcode.
Test on XCP-ng 8.3
From an up-to-date host, or a host on which previous update candidates had been installed. Both fit.
yum clean metadata --enablerepo=xcp-ng-candidates yum update --enablerepo=xcp-ng-candidates rebootThe usual update rules apply: pool coordinator first, etc.
Versions
intel-microcode: 20250501-1.xcpng8.3xen: 4.17.5-13.1.xcpng8.3
What to test
Normal use and anything else you want to test. The closer to your actual use of XCP-ng, the better.
Test window before official release of the updates
~24h. That's an urgent one.
-
@stormi
Stats still not good
Only rebooted
After
Restart tool stack
-
@ph7 This update only covers the security issue described above. Fix for the stats issue will roll out later.
-
@stormi installed on the same test machines i have the other batch of updates installed on. No issues after a reboot.
-
@andriy.sultanov
Sorry, if I only could read...
Anyhow, My updated host running on intel seems to work just fine. -
My lab is down for a few days, so no testing for me. And it is AMD so maybe not useful. I probably won't be back running until Friday.
-
@Greg_E Thanks for letting me know. It is useful to make sure that it's still working on any kind of hardware, but your lab won't participate this time
-
Installed the patches on my lab pool and both hosts are up and running and no issues so far.
-
Latest urgent updates installed on 3-node Intel pool. Everything is working as before including the pre-production code "no stats" issue, but that still resolves following xe-toolstack-restart command. Since it is currently Microsoft patch Tuesday here, the latest Windows 11-24H2 2025-05 cumulative update was installed to VM along with various Linux VM updates and live VM host migrations. All working well including latest af03c Xen Orchestra from source (XOS).
-
@stormi Upgraded my test 8.3 hosts, several Intel and AMD Zen 3. So far, so good.
