XCP-ng 8.3 updates announcements and testing
-
While updating my host i see 30 updates...
========================================================================================================================================= Package Arch Version Repository Size ========================================================================================================================================= Updating: forkexecd x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 2.5 M gpumon x86_64 24.1.0-84.1.xcpng8.3 xcp-ng-testing 1.6 M intel-microcode noarch 20260416-1.xcpng8.3 xcp-ng-testing 14 M kernel x86_64 4.19.19-8.0.46.3.xcpng8.3 xcp-ng-testing 29 M message-switch x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 4.6 M qcow-stream-tool x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 1.4 M rrdd-plugins x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 9.8 M sm-cli x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 4.8 M squeezed x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 1.9 M varstored-guard x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 4.9 M vhd-tool x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 4.9 M wsproxy x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 1.1 M xapi-core x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 30 M xapi-nbd x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 3.1 M xapi-rrd2csv x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 3.0 M xapi-storage-script x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 2.5 M xapi-tests x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 5.0 M xapi-xe x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 1.5 M xcp-featured x86_64 1.2.1-1.xcpng8.3 xcp-ng-testing 1.5 M xcp-networkd x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 4.8 M xcp-rrdd x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 3.6 M xen-dom0-libs x86_64 4.17.6-8.1.xcpng8.3 xcp-ng-testing 703 k xen-dom0-tools x86_64 4.17.6-8.1.xcpng8.3 xcp-ng-testing 2.0 M xen-hypervisor x86_64 4.17.6-8.1.xcpng8.3 xcp-ng-testing 2.4 M xen-libs x86_64 4.17.6-8.1.xcpng8.3 xcp-ng-testing 65 k xen-tools x86_64 4.17.6-8.1.xcpng8.3 xcp-ng-testing 46 k xenopsd x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 1.4 M xenopsd-cli x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 2.0 M xenopsd-xc x86_64 26.1.4-3.1.xcpng8.3 xcp-ng-testing 5.3 M xo-lite noarch 0.21.0-1.xcpng8.3 xcp-ng-testing 2.6 M Transaction Summary ========================================================================================================================================= Upgrade 30 Packages Total download size: 152 M -
I'm seeing 30 updates as well but they're installed and seem to be working fine on my test systems.
-
I'm seeing 30 updates as well but they're installed and seem to be working fine on my test systems.
I think I only listed sources packages (which contains several binaries sub-packages having the same versions), so that's expected
BTW thank you for reactivity on testing
-
Indeed we only list source packages.
xapi's source RPM alone creates a lot of RPMs each time, for example. In this case, all those with version 26.1.4-3.1.xcpng8.3. -
@rzr
Seems to be OK
ran a few backups and installed a new VM
XO-lite was already on 0.21.0 (13f98) after the update 2 weeks ago.. Don't know if it's the same. -
Installed on my usual batch of test hosts, so far so good.
-
XO-lite was already on 0.21.0 (13f98) after the update 2 weeks ago.. Don't know if it's the same.
yes it's same landed in testing before and not yet moved to updates, btw this version does not bring much change as it's a rebuild with dep update, see there is no full changelog :
https://github.com/vatesfr/xen-orchestra/releases/tag/xo-lite-v0.21.0
-
@rzr Updated and running on most systems now. Rolling pool reboot worked correctly (need to disable backups first). VMs and CR running normally.
After a large S3 backup session (that succeeded), GC on the master got stuck in a loop and failed (lock issue). A reboot of the pool master was required to resolve the problem then GC coalesced the VHDs without additional action. Other pools did not have the same problem. I have not seen that issue before, but everything seems fine now so I can't blame the update.
-
Why did you need to disable backups before applying this?
-
@Greg_E It's not a patch/update issue, it's the rolling pool reboot. If a VM is being backed up and XO wants to migrate the VM and can't, then the host evacuate stops and the reboot does not happen.
-
@Andrew Hello,
I'm also getting error on some VMs while trying to export a disk and also trying to even start some VMs from NFS (that were fine before).
Is it still a problem? It might have multiple causes. If it's still an issue, could you share the logs:
/var/log/{SMlog,xensource.log,daemon.log}. It contains information that could help us investigate.The VDI not detached cleanly means that the VDI still has a reference to the host it was running on before.
It's might be caused by the xenopsd error earlier or maybe it's the cause.If you are sure no tapdisk are using the VDI, you can look at
tap-ctl listoutput on each host.
You can clean this reference with the script in/opt/xensource/sm/resetvdis.py single <VDI UUID>. -
Thanks, my updates and my RPU are normally at different times. I also don't backup multiple times per day like I probably should.
-
I get this in dmesg after the latest updates :
[ 54.673443] python3[3691]: segfault at 200000 ip 00007f16eb8eca9f sp 00007ffd b84e9ff0 error 4 in libpython3.6m.so.1.0[7f16eb804000+28d000] [ 54.673450] Code: 01 00 00 8d 5f ff 48 8d 2d de 3a 3c 00 c1 eb 03 44 8d 24 1b 4e 8b 44 e5 00 49 8b 70 10 49 39 f0 74 5f 49 8b 40 08 41 83 00 01 <48> 8b 38 48 85 ff 49 89 78 08 74 0d 48 83 c4 10 5b 5d 41 5c c3 0f [ 84.587661] xapi[3697]: segfault at 7f28cacaea40 ip 00007f28c6df0ec2 sp 00007 f289a5b8af0 error 6 in libjemalloc.so.2[7f28c6d85000+85000] [ 84.587669] Code: 48 2b 73 08 44 8b 4d 84 ba 01 00 00 00 49 83 c2 01 49 0f af f1 4c 8d 0d ac 72 42 00 48 89 f1 48 c1 ee 26 48 c1 e9 20 48 d3 e2 <48> 31 54 f3 40 48 8b 8d 58 ff ff ff 48 8b 33 48 8d be 00 00 00 10Hi, if possible can you share us more information to troubleshoot, like a xen-bugtool --yestoall output ?
https://docs.xcp-ng.org/troubleshooting/log-files/If you can also do the usual hardware check (eg: memtest) that would help, because my intuition is that it is not related to this precise update but we like to be sure.
-
@rzr Hi. It appeared only once, after a host reboot. If it shows again, I'll let you know.
-
-
We pushed the updates to the
xcp-ng-updatesrepository: https://xcp-ng.org/blog/2026/05/21/may-2026-updates-3-for-xcp-ng-8-3-lts/Changed since the initial announcement,
xenwas updated with the proper vulnerability fix and an update tosmwas added to fix an issue on LVM-based SRs with CBT enabled.Thanks everyone for your feedback!
-
We pushed the updates to the
xcp-ng-updatesrepository: https://xcp-ng.org/blog/2026/05/21/may-2026-updates-3-for-xcp-ng-8-3-lts/Changed since the initial announcement,
xenwas updated with the proper vulnerability fix and an update tosmwas added to fix an issue on LVM-based SRs with CBT enabled.Thanks everyone for your feedback!
update main pool. so far so good. updates went well and vms are running.
-
Did my production this morning... Not a smooth upgrade this time.
The master took so long that the process timed out, I can't tell too much more because I was doing other work and was doing this remotely.
I handled the next host manually, and that took so much time I gathered my hearing protection and went over to the rack. It was stuck in a reboot phase but hadn't shut down for about 20 minutes. Held my finger on the power button. booted back up with a couple reboots in the process and it finally was ready.
Moved the VMs off the third host, manually triggered the update, and sat and watched looking at the VGA output to see what was happening. The reboot phase saw the XCP-ng animation progress all the way to an empty bar, but sat there another 5-10 minutes until I again held my finger on the power button to shut it off. Power up and after a bit of time it was ready again. All in all, updating three hosts took me around 2 hours today.
Here's the one condition that I think could contribute to this issue:
I have two NAS normally connected, an ISO and NFS connection on each. One of the servers is powered down for construction, but I did not disconnect it from the hosts. Could this severed connection be the reason why my updates took so long, something around not being able to purge or drain the state before the reboot?
I've disconnected those SR from the hosts, and I'll probably do a rolling pool reboot later today or next week and see if things go better.
And all that said, my XO sources is not happy with this update. XO6 isn't grabbing the data so dashboards are blank or take a long time with spinning wheels gathering the data. XO5 is immediate. One of my XO sources updated this morning, the other was yesterday so they should be pretty close to current.
-
I have two NAS normally connected, an ISO and NFS connection on each. One of the servers is powered down for construction, but I did not disconnect it from the hosts. Could this severed connection be the reason why my updates took so long, something around not being able to purge or drain the state before the reboot?
Don't look further, that's exactly the issue. Reboot would have occur in the end after 30 minutes (timeout) and all other operations will be extremely slow.
You must disconnect a SR for maintenance, otherwise you enter in a world of pain.
-
I have issue with rolling pool update with 1 of my 3 pools at work. It was the last pool to be updated. Host 1 updated no issues. vms stopped migrated off host 2 to complete updates.
Support ticket opened -
Ticket#7758427. Found 1 vm with cpu stuck at 100% and unresponsive. Force rebooted vm and proceed updates on host2.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login