XCP-ng 8.3 updates announcements and testing
-
Hmmm I have been reading quite often in the last months that people have issues with RPU.
I tried RPU during every single update within the last year and for me it only failed when one (or multiple) VMs have not been live migrateable.
That is not really the "fault" of the RPU process but rather related to the VMs.
Finding out the cause has been a bit finicky though. (reading through log file)
Maybe the biggest improvement to RPU would be some form of better error reporting?
That would make it more clear to people what actually caused the issues rather than thinking "RPU is broken".
-
Yes, here that's an error that could be translated like this: some (7?) VMs cannot boot on the other available hosts, because they are using a resource local to the host they are running on right now. So they can't be evacuated.
-
"xenopsd internal error: Hotplug.Hotplug_error(\"Failed to read /xapi/450015b0-e878-5067-e8b6-000000000001/private/vif/1/trunks\")"This is related to new code in the upgrade. the trunks attribute is used for VLAN filtering (new feature).
it seems that the running code is the new one (it is knowning about trunks) but the VM doesn't have the trunks attribute.
I would be interested to have a clean picture of the situation:
- on which host this VM is resident on
- version of the master
- version of the host where the VM is resident
-
@semarie In my case the pool i tested these updates on was a 2 host pool, i patched each host using yum and then kicked off a rolling pool reboot. So the VMs would have been resident on the pool master since it is the first rebooted when running a rolling pool reboot. I was unable to manually migrate the VMs resident on this host as well, attempting to do so would show the same error.
In my case though restarting the tool stack on both hosts allowed migrations to complete and a rolling pool reboot to run successfully.
-
@acebmxer This error does not appear to be linked to the update, but rather to a repo that has not yet had time to synchronize or is in the process of doing so at the time of your update.
-
@flakpyro it seems to me the proper upgrade path is:
- put the master in maintenance mode (
xe host-disable host=$MASTER) - evacuate the master (
xe host-evacuate host=$MASTER) - yum update the master
- reboot the master (
xe host-reboot host=$MASTER) - once done, do the same of the others hosts
the VM would have been updated with the new
trunksattribute when migrating to some updated host (in your case, when migrating to the master). - put the master in maintenance mode (
-
@semarie If that's the case then the update will likely go smoothly once its released to the stable repos and users use Xen Orchestra to run a rolling pool update which follows that workflow. Since this was a test pool and using the test repos i ran the update via yum without evacuating the host first.
-
@flakpyro yes. thanks for your test and to reporting the problem anyway. it is helping us to see what kind of problems users could have.
-
Thank you everyone for your tests and your feedback!
The updates are live now: https://xcp-ng.org/blog/2026/08/18/august-2026-updates-1-for-xcp-ng-8-3-lts/
-
@gduperrey Rolling pool update worked with released production patches.
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