XCP-ng 8.3 updates announcements and testing

[flakpyro]

@dinhngtu We did initially run into this issue a number of years ago and were able to fix it by following this kb article at the time:
https://support.citrix.com/external/article?articleUrl=CTX692813-xenserver-potential-performance-issues-on-imported-windows-vms&language=en_US

Checking s few random migrated windows VMs and it appears these flags are still set as they should be.

[acebmxer]

@gleh

Installed patches on home lab. No initial issues found. Existing Windows 11 vm no issues with it on basic vm functions. Created new Windows 11 vm with 26h2 iso no issues. Also installed guest tools in both vms.

[flakpyro]

Installed on my usual test hosts without any issues so far.

[olivierlambert]

That's a pretty beefy update! It's great to see the live storage migration performance improving by a very nice margin

[olivierlambert]

Tested in my home lab, no issues so far (Intel CPU).

[abudef]

I have to say that the acceleration of the migration is really dramatic, which is particularly useful for occasional ad hoc migrations where another task needs to be performed immediately after the migration is completed.
and thanks!

[bufanda]

Installed on my usual lab pool. No issues so far seen.

[jr-m4]

Installed on 3xDell PowerEdge R350 in HA. And so far, I haven't noticed anything out of the ordinary.

[JeffBerntsen]

Installed and running on my lab system and my twinstor test pair and no problems yet.

[Andrew]

@gleh Up and running on busy pools. Rolling pool reboot worked correctly.

[gduperrey]

Thank you everyone for your tests and your feedback!

The updates are live now: https://xcp-ng.org/blog/2026/10/05/october-2026-updates-1-for-xcp-ng-8-3-lts/

We decided not to release the xen update that was initially included in the testing phase of this update cycle. It introduced changes related to support for Windows VMs with more than 64 vCPUs; a feature that is not yet fully supported and requires further work to be completely implemented.

We therefore chose to postpone it to avoid any regressions or user confusion, aiming to release a properly finalized and documented version in the near future.

This version should have no impact on your test environments, and they can continue to operate as is. Any future xen update should have a higher version number and should install over the current one.

However, if you do not wish to keep this update on your test environments, you can downgrade using the command yum downgrade xen-*.

[bvitnik]

@gleh said:

Disable Viridian in the "Other install media" template by default. As a reminder, Windows VMs must use Windows templates.

What is the rationale for disabling Viridian? Does it have any negative effects for non Windows VMs?

[acebmxer]

@gduperrey

Just tried to install the patches pushed today to home lab. All but 1 vm evactuated from the primary host.

 },
                    "taskRef": "OpaqueRef:f56d3f5e-d41c-c8eb-3c70-4676f74de68c",
                    "message": "task has been destroyed before completion",
                    "name": "Error",
                    "stack": "Error: task has been destroyed before completion\n    at Xapi._removeRecordFromCache (file:///opt/xen-orchestra/packages/xen-api/index.mjs:1462:21)\n    at file:///opt/xen-orchestra/packages/xen-api/index.mjs:1429:18\n    at Set.forEach (<anonymous>)\n    at file:///opt/xen-orchestra/packages/xen-api/index.mjs:1428:20"
                  }

Rolling pool update.txt

VM that wouldnt migrate -

[TeddyAstie]

@bvitnik
Various reasons :

• In some niche cases, it can cause compatibility issues with guests.
• Viridian exposes additionnal attack surface e.g VSA-2025-006 and VSA-2026-031
  and given that this is generally unused for non-Windows guests, there is no good reason to expose it to the guest

For Windows guests, use of the dedicated Windows template is strongly encouraged, as it brings additional viridian flags and other tunings for better compatibility and performance.

[bvitnik]

@TeddyAstie Thanks

[acebmxer]

after multiple failed attempts and rebooted all three host. Host 1 did update and finally got host 2 and host 3 updated both via rolling pool update.

During the evacuation multiple vms failed to migrate / reboot. All showing similar errors in each console for the vms.

[jacob.becker]

@acebmxer
Had some similar Errors on 2 Arista appliances with an older Alma-Linux base (9.5).
After upgrading the image (Alma 9.6 based) the error went away - so it looks like a kernel thing

what kernel run inside your vm ?

[acebmxer]

@jacob.becker

VM were Ubuntu and Fedora distros. Ubuntu is 7.0.0-38-generic. The Fedora vms 7.2.7-200.fc44.x86_64 and 7.2.9-300.fc45.x86_64.

Had no issues with the beta test but those were done not via Rolling pool update.

[jacob.becker]

@acebmxer
Can you suspend the vm ?

If its not possible its most likely a kernel thing inside the vm.
If you can suspend the vm however, it points more to a timing/timeout issue with the migration.

[gduperrey]

We have just released security updates for xen and blktap. Full details are available on the blog: https://xcp-ng.org/blog/2026/10/13/october-2026-security-updates-2-for-xcp-ng-8-3-lts/