XCP-ng 8.3 updates announcements and testing

[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/

[lmolina]

New maintenance update candidates for XCP-ng 8.3 LTS

This batch of updates contains mostly fixes, tools version update, and some improvements.

What changed

Virtualization & System

• xen:
  • This release is a synchronization with XenServer release 4.17.7-4. XSAs 517, 518, and 520 patches that were included in XCP-ng previous releases are now part of this XS release.
  • This release also fixes a possible microcode hang on Granite Rapids systems.

Control Plane

• xapi:

  • Fix the VDI.snapshot_of corruption (see the corresponding troubleshooting page). Note that the old corrupted snapshot_of references still need to be fixed up by the snapshot-fixer.py helper script.
  • Fix issues for PCI passthrough of some devices (AMD and Intel GPUs, Kioxia SSDs) by disabling HVM PIRQ
  • PCI passthrough: HVM PIRQ now disabled by default. Some devices passed through to VMs (AMD and Intel GPUs, Kioxia SSDs) could have problems caused by the "HVM PIRQ" feature (see the troubleshooting section). This update disables it by default on HVM VMs. The new default applies the next time a VM starts or reboots. If you set platform:hvm-pirq on a VM yourself, that value is kept.
  • Improve performance of xapi-nbd (used by XenOrchestra backups)
  • Fix XenOrchestra backups of VDIs on shared SRs failing when a pool has offline hosts
  • Prevent SR issues from blocking XAPI startup
  • Report a clear error during HA when host evacuation is blocked by unprotected VMs

• xcp-ng-xapi-plugins:

  • lsblk.py : Add a new output in lsblk device-id-paths that is a list of paths on the host using stable identifier.
  • service.py: Restrict which services the plugin is allowed to stop/start

Storage

• blktap: Several tapdisk improvements:

  • Qcow2 support introduced multithread and therefore locking. One of the blkif's critical session protected by a lock was larger than necessary. By restricting locking at the blkif level, write operations on Qcow2-format VDIs can see great performance improvement if there is sufficient I/O depth.
  • Fix a potential crash on NBD server handshake connection. This was observed under artificial conditions and should not happen in real scenarios.
  • Storage team continue to modernize the tapdisk codebase to allow more improvements in the future. No functional change expected here but preparatory work on next features.

• sm:

  • Repair plugin method healthCheck of linstor-manager that was broken due to internal refactoring.
  • Repair regression caused by previous release where LINSTOR HA cannot be activated.
  • Reset on boot feature is now usable on ZFSSR driver using on-boot param with persist or reset values.

For XOSTOR users:

• xcp-ng-linstor: Fix rolling pool updates with large pools using XOSTOR

UI

• xo-lite:
  • [Host] Add possibility to reboot a host (PR #10250)
  • [Web-Core/TabItem] Update the component to remove uppercase for better readability (PR #10338)
  • [Host] Add possibility to force reboot a host (PR #10311)
  • [Icons] Update FontAwesome, clean unused libraries (PR #10365)
  • [Host] Add possibility to shut down and start a host (PR #10314)
  • Use MenuItem's accent prop to color menu actions instead of custom CSS classes (PR #10348)
  • [Host] Add possibility to forget a host (PR #10315)
  • [Pool/Network] Add the possibility to delete host internal networks (PR #10332)

Drivers and Firmware

• amd-microcode: Update to 2026-09-23 drop as redistributed by XenServer. Updated CPUs

  • BRH-C1 00b00f21: 2025-10-17, rev 0b002162 -> 2026-08-10, rev 0b00217b
  • BRHD-B0 00b10f10: 2025-10-17, rev 0b101059 -> 2026-08-10, rev 0b101068

• intel-microcode:

  • Update to the 2026-09-25 drop. This is IPU 2026.3 with fixed Meteor Lake microcode.
  • fix of a bugus microcode for Sierra Forest (E-Core) CPUs.
  • microcode update for Granite Rapids to address a security vulnerability for which a mitigation had already been released in previous updates (https://xcp-ng.org/blog/2026/10/13/october-2026-security-updates-2-for-xcp-ng-8-3-lts/).
  • Removed MTL/06-aa-04/c0 due to functional issues observed when loading the MCU in some platforms.
  • Updates for functional issues.
  • Security updates for: INTEL-SA-01379, INTEL-SA-01404, INTEL-SA-01423, INTEL-SA-01428, INTEL-SA-01435, INTEL-SA-01441, INTEL-SA-01442, INTEL-SA-01443, INTEL-SA-01420

Others

• sudo: Update to version 1.9.17
  • 3 security fixes of vulnerabilities in sudo which could allow a privilege escalation in certain condition.
  • 1 security fix of a vulnerability allowing a user with temporary authorization to extend their authorization by 24 hours.

Versions

• amd-microcode: 20260519-1.1.xcpng8.3 -> 20260923-1.1.xcpng8.3
• blktap: 3.55.5-11.3.xcpng8.3 -> 3.55.5-12.2.xcpng8.3
• gpumon: 24.1.0-98.1.xcpng8.3 -> 24.1.0-99.1.xcpng8.3
• intel-microcode: 20260416-2.xcpng8.3 -> 20260925-1.xcpng8.3
• sm: 3.2.12-25.1.xcpng8.3 -> 3.2.12-25.2.xcpng8.3
• sudo: 1.9.15-5.1.xcpng8.3 -> 1.9.17-10.p2.1.xcpng8.3
• xapi: 26.1.19-1.2.xcpng8.3 -> 26.1.21-1.1.xcpng8.3
• xcp-featured: 1.2.1-5.xcpng8.3 -> 1.2.1-6.xcpng8.3
• xcp-ng-xapi-plugins: 1.17.0-1.xcpng8.3 -> 1.18.0-1.xcpng8.3
• xen: 4.17.7-2.5.xcpng8.3 -> 4.17.7-4.1.xcpng8.3
• xo-lite: 0.25.0-1.xcpng8.3 -> 0.26.0-1.xcpng8.3

XOSTOR users: specific update procedure

Some XOSTOR packages are provided in separate repository, and should be installed along xcp-ng regular packages, using the following commands:

yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates,xcp-ng-linstor-testing
yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates,xcp-ng-linstor-testing
reboot

The following XOSTOR-specific package received an update:

• xcp-ng-linstor: 1.2-6.xcpng8.3 -> 1.2-7.xcpng8.3

Test on XCP-ng 8.3

Warning: XOSTOR users should skip this part and follow the instructions of the previous section.

yum clean metadata --enablerepo=xcp-ng-testing,xcp-ng-candidates
yum update --enablerepo=xcp-ng-testing,xcp-ng-candidates
reboot

The usual update rules apply: pool coordinator first, etc.

What to test

Normal use and anything else you want to test, as usual. We mostly want to make sure nothing regressed. These checks would help us most:

1. Reboot your VMs, starting with Linux VMs that use PCI passthrough (GPU, NVMe, NIC). The new HVM PIRQ default applies to every VM at its next boot. If you set platform:hvm-pirq on a VM yourself, that value is kept. Devices that worked before must still work, with similar performance and CPU usage. If one doesn't, check whether platform:hvm-pirq=true brings it back, and tell us.
2. Run your usual Xen Orchestra backups (incremental with NBD, full) and a restore. Every NBD backup now goes through new code (tapdisk's NBD server, parallel requests), so they must complete, and shouldn't get slower.
3. Watch the disk performance of your busiest VMs, on VHD and QCOW2 SRs. The locking change in tapdisk applies to every VM disk, not only QCOW2.
4. After running the snapshot_fixer.py script if necessary, take, revert to and delete snapshots, including on VMs with several disks, and check that the VMs and their disks are as expected afterwards. The fix changes how xapi handles VDIs during reverts and SR scans.

Test window before official release of the updates

~5 days

We would like to thank users who shared feedback since our last call for testing:
@flakpyro, @acebmxer, @abudef, @bufanda, @jr-m4, @JeffBerntsen, @Andrew