XCP-ng 8.3 updates announcements and testing

[manilx]

@stormi didn't see that (my old eyes)... guessed so anyway

[acebmxer]

@gduperrey

When applying updates at work. I started with first pool and choose the rolling pool updates and ran into issue after fist host came back up the second host didnt enter maintenance mode and the operation appeared to have just stopped. I then manually put host 2 in maintenance mode and applied updates. Once updates finished it restated the tool stack and took the host out of maintenance mode. I put it back into maintenance mode and rebooted the host. Once it came backup no migration occurred as expected to bring vms back to host2.

Moved on to pools 2 and 3 and just did everything manually. Each time load balance appears to be broken now just like home lab.

I have rebooted XOA deleted load balance config. rebuilt using different name and still no load balance.

Once manually migrated vms back over to second host in all three pools all seems ok.

[gduperrey]

@acebmxer Hello,

What you're describing sounds more like an RPU issue with Xen-Orchestra than a problem related to XCP-ng updates. But I could be wrong

However, since these updates affect Xen, a reboot was clearly indicated in our procedure. So a simple restart of the toolstack isn't enough. You did the right thing by rebooting afterward.

Are you using XO Appliance or from source?

If it's XO Appliance, you can open a ticket to ask for help analyzing the situation and see if anything in the logs or configuration explains this behavior.

If it's from source, for the same issue, I would suggest you start a separate thread on the forum so other users can help you with the analysis

In any case, it's great if your pool is working in the end

[acebmxer]

@gduperrey

Thank you for the reply. Work uses XOA.

Edit - Support ticket created - Ticket#7755004

[gduperrey]

@acebmxer I invite you to open a ticket through the support ticketing system.

I do not connect remotely myself and I am also unable to provide support for Xen-Orchestra.

[gduperrey]

New security update candidate for you to test!

A new security vulnerability has been detected and fixed for xen.

This was introduced by an upstream commit, and detected before the Xen Project did any new release. Therefore this does not impact any upstream release, and there is no Xen Security Advisory this time. But that change was backported into XCP-ng xen package, therefore XCP-ng is impacted.

---

Security updates

• xen: Fix a security issue where insufficient memory sanitization during guest creation can lead to information leakage from previous guests and potential privilege escalation

Test on XCP-ng 8.3

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.

Versions:

• xen: 4.17.6-5.2.xcpng8.3

What to test

Normal use and anything else you want to test.

Test window before official release of the updates

~2 days

[flakpyro]

@gduperrey Installed on my usual round test hosts. No issues to report so far! With such a small change i wasn't expecting anything to go wrong!

[ph7]

@gduperrey
All good so far

[Andrew]

@gduperrey Up and working on several Intel pools.

[JeffBerntsen]

@gduperrey Seems to be working well on my test systems.

[Greg_E]

How many of these are critical? I haven't even had time to apply the last round of patches to either lab or production.

[gduperrey]

Thank you everyone for your tests and your feedback!

The updates are live now: https://xcp-ng.org/blog/2026/03/26/march-2026-security-updates-2-for-xcp-ng-8-3-lts/

[acebmxer]

@gduperrey
Installed on home lab via rolling pool update and both host updated no issues and vms migrated back to 2nd host as expected this time. fingers crossed work servers have the same luck.

I do have open support ticket from last round of updates for work servers. Waiting for response before installing patches.

[rzr]

New feature, security and maintenance update candidates for you to test!

This release batch contains a major storage feature,
read the RC2 announcement for QCOW2 image format support for 2TiB+ images.

The whole platform has been hardened with a major OpenSSH update.

The updated Windows Guest Tools bring support for the XSTDVGA driver, allowing display resizing.

We also publish other non-urgent updates which we had in the pipe for the next update release.

What changed

Storage

QCOW2 image format support is the major feature of this release batch,
check related announcement in forum.

• sm: 3.2.12-17.2
  • Add support for the QCOW2 image format
• blktap: 3.55.5-6.4
  • Add support of new QCOW2 disk type

Maintenance updates

Virtualization & System

• xen: 4.17.6-6.1
  • Sync with XenServer's xen-4.17.6-6.xs8
    * Fix boot failure on some UEFI systems. WIP
• kernel: 4.19.19-8.0.46.1
  • Fix regarding use of the correct MAC address in the rndis_host driver
  • Backport fix regarding a potential bug in the ext4 driver (CVE-2020-14314)
  • Backports fixes in SUNRPC (related to NFS). This prevents host crashes under some circumstances.

Control plane

• xapi: 26.1.3-1.6
  • Several fixes to QCOW2 enablement for importing and exporting, like reducing memory usage on disk import
• xcp-ng-xapi-plugins: 1.16.0-1
  • sdncontroller.py: add support for new optional cookie argument to add-rule and del-rule functions
• xcp-ng-pv-tools: 8.3-16
  • Update to XCP-ng Windows PV Tools 9.1.146.0
  • Include the XSTDVGA driver and improvements to the guest agent/installer

UI

• xo-lite: Update to 0.20.0-1
  • [VM/New] Added secureBoot support (PR #9423)
  • [Dashboard] Fix reactivity of dashboard (PR #9378)
  • [VM] Fixed duplicated ip addresses in the network tab Forum#101359 (PR #9547)
  • [Stats] Return null instead of 0 when no stats available (PR #9634)
  • [Treeview/Pool/Host] Add button to download bugtools (PR #9419)

Network

• gnutls: 3.3.29-10.2
  • Fix dane removal (no more replacing dane with devel package)
• openssh: Update to 9.8p1-1.2.2
  • Deprecate old OpenSSH clients (7.2 and lower) that use weak SHA1 with ssh-rsa:
    • For now, a warning will ask to use an up to date client, on next update weak configurations will be rejected.
• net-snmp: 5.9.3-8.2
  • Fix SNMP regression (daemon configuration was lost in earlier version)
• xcp-ng-deps: 8.3-14
  • Install traceroute to troubleshoot connectivity problems

Additional packages

Best effort support is provided for additional packages provided by the XCP-ng project.

• lldpd: version 1.0.4-1.1 provided for convenience in our repositories, as the EPEL version is not compatible anymore with the latest XCP-ng 8.3 updates. However, please prefer the pre-installed lldapd whenever possible.
• nut: version 2.8.0-2.1 provided for convenience in our repositories, as the EPEL version is not compatible anymore with the latest XCP-ng updates.
  • User feedback is welcome

Drivers updates

More information about drivers and current versions is maintained on the drivers wiki page.

• emulex-lpfc-alt: 14.4.393.31-1.1
  • This is an alternative driver which handles newer Emulex lpfc devices.
• sfc-module-alt: 5.3.18.1012-1
  • Initial alternate driver for Solarflare SFN5XXX|6XXX|7XXX|8XXX|X2, version 5.3.18.1012

Versions:

• blktap: 3.55.5-6.3.xcpng8.3 -> 3.55.5-6.4.xcpng8.3
• gnutls: 3.3.29-10.1.xcpng8.3 -> 3.3.29-10.2.xcpng8.3
• kernel: 4.19.19-8.0.44.1.xcpng8.3 -> 4.19.19-8.0.46.1.xcpng8.3
• net-snmp: 1:5.9.3-8.1.xcpng8.3 -> 1:5.9.3-8.2.xcpng8.3
• openssh: 7.4p1-23.3.3.xcpng8.3 -> 9.8p1-1.2.2.xcpng8.3
• sm: 3.2.12-17.1.xcpng8.3 -> 3.2.12-17.2.xcpng8.3
• traceroute: 3:2.1.5-2.xcpng8.3
• xapi: 26.1.3-1.3.xcpng8.3 -> 26.1.3-1.6.xcpng8.3
• xcp-ng-deps: 8.3-13 -> 8.3-14
• xcp-ng-pv-tools: 8.3-15.xcpng8.3 -> 8.3-16.xcpng8.3
• xcp-ng-xapi-plugins: 1.15.0-1.xcpng8.3 -> 1.16.0-1.xcpng8.3
• xen: 4.17.6-5.2.xcpng8.3 -> 4.17.6-6.1.xcpng8.3
• xo-lite: 0.19.0-1.xcpng8.3 -> 0.20.0-1.xcpng8.3

Optional packages:

• lldpd: 1.0.4-1.1
• nut: 2.8.0-2.1

Test on XCP-ng 8.3

If you are using XOSTOR, please refer to our documentation for the update method.

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.

Known issues

• On blktap update a non blocking error is reported,the fix is ongoing and will be delivered soon

What to test

The most important change is related to storage: adding QCOW2 support also affects the codebase managing VHD disks. What matters here is, above all, to detect any regression on VHD support (we tested it deeply, but on this matter there's no such thing as too much testing). Of course, you are also welcome to test the QCOW2 image format support.

See the dedicated thread for more information.

Other significant changes requiring attention:
* SSH connectivity
* SNMP, if you use it

And, as usual, normal use and anything else you want to test.

Test window before official release of the updates

~2 weeks

[dthenot]

@rzr Host updated

[Andrew]

@rzr Installed on test machines with some warnings:

  Updating   : blktap-3.55.5-6.4.xcpng8.3.x86_64                           9/87
cat: /usr/lib/udev/rules.d/65-md-incremental.rules: No such file or directory
warning: %triggerin(blktap-3.55.5-6.4.xcpng8.3.x86_64) scriptlet failed, exit status 1
Non-fatal <unknown> scriptlet failure in rpm package blktap-3.55.5-6.4.xcpng8.3. x86_64

  Updating   : sm-fairlock-3.2.12-17.2.xcpng8.3.x86_64                    32/87
Warning: fairlock@devicemapper.service changed on disk. Run 'systemctl daemon-reload' to reload units.

[flakpyro]

Installed on a handful of test machines. Not as many as usual as im being very cautious with this one for now. Everything rebooted and VMs started ok after. Using VHD for everything currently.

[rzr]

@Andrew said:

@rzr Installed on test machines with some warnings:

  Updating   : blktap-3.55.5-6.4.xcpng8.3.x86_64                           9/87
cat: /usr/lib/udev/rules.d/65-md-incremental.rules: No such file or directory
warning: %triggerin(blktap-3.55.5-6.4.xcpng8.3.x86_64) scriptlet failed, exit status 1
Non-fatal <unknown> scriptlet failure in rpm package blktap-3.55.5-6.4.xcpng8.3. x86_64

Yes this was reported as "Known issues"

On blktap update a non blocking error is reported,the fix is ongoing and will be delivered soon

  Updating   : sm-fairlock-3.2.12-17.2.xcpng8.3.x86_64                    32/87
Warning: fairlock@devicemapper.service changed on disk. Run 'systemctl daemon-reload' to reload units.

I observed this too, maybe this should be documented too, a reboot will work too.

[Andrew]

@rzr Always a reboot after big updates, as instructed/required.