Good morning, afternoon, evening or night to everybody.

The beta release of XCP-ng 8.0 is available right now .

What's new

• Based on Citrix Hypervisor 8.0 (see https://xen-orchestra.com/blog/xenserver-7-6/).
• New kernel (4.19), updated CentOS packages (7.2 => 7.5)
• Xen 4.11
• New hardware supported thanks to the new kernel. Some older hardware is not supported anymore. It's still expected work in most cases but security cannot be guaranteed for those especially against side-channel attacks on legacy Intel CPUs. See Citrix's Hardware Compatibility List. Note: in 7.6 we've started providing alternate drivers for some hardware. That's something we intend to keep doing, so that we can extend the compatibility list whenever possible. See https://github.com/xcp-ng/xcp/wiki/Kernel-modules-policy.
• ). Note: in 7.6 we've started providing alternate drivers
• Experimental UEFI support for guests (not tested yet: have fun and report!)
• An updated welcome HTML page with the ability to install Xen Orchestra Appliance directly from there (see below). Tell us how it works for you and what you think of it!
• A new implementation of the infamous emu-manager, rewritten in C. Test live migrations extensively!
• Mirrors: you can offer mirrors and yum now pulls from them: https://github.com/xcp-ng/xcp/wiki/Mirrors
• Already includes the latest patches for MDS attacks.
• The net-install installer now checks the signature of the downloaded RPMs against our GPG key, which is becoming more important now that we're delegating downloads to mirrors.
• Status of our experimental packages:
  • ext4 and xfs support for local SR are still considered experimental, although no one reported any issue about it. You still need to install an additional package for it to work: yum install sm-additional-drivers.
  • ZFS packages are now available in the main repositories, can be installed with a simple yum install zfs, and have been updated to version 0.8.1 (as of 2019-06-18) which removes the limitations we had with the previous version in XCP-ng 7.6.
  • No more modified qemu-dp for Ceph support, due to stalled issue in 7.6 (patches need to be updated). However the newer kernel brings better support for Ceph and there's some documentation in the wiki: https://github.com/xcp-ng/xcp/wiki/Ceph-on-XCP-ng-7.5-or-later.
  • Alternate kernel: none available yet for 8.0, but it's likely that we'll provide one later.
• New repository structure. updates_testing, extras and extras_testing disappear and there's now simply: base, updatesandtesting`. Extra packages are now in the same repos as the main packages, for simpler installation and upgrades.
• It's our first release with close to 100% of the packages rebuilt in our build infrastructure, which is Koji: https://koji.xcp-ng.org. Getting to this stage was a long path, so even if it changes nothing for users it's a big step for us. For the curious ones, more about the build process at https://github.com/xcp-ng/xcp/wiki/Development-process-tour.

Documentation

At this stage you should be aware that our main documentation is in our wiki and you should also know that you can all take part in completing it. Since the previous release, it has improved a lot but there's still a lot to improve.

How to upgrade

As usual, there should be two different upgrade methods: classical upgrade via installation ISO or upgrade using yum.

However, the yum-style update is not ready yet. Since this is a major release, Citrix does not support updating using an update ISO, and the consequence for us is that the RPMs have not been carefully crafted for clean update. So it's all on us, and we plan to have this ready for the RC (release candidate).

Before upgrading, remember that it is a pre-release, so the risks are higher than with a final release. But if you can take the risk, please do and tell us how it went and what method you used! However, we've been testing it internally with success and xcp-ng.org already runs on XCP-ng 8.0 (which includes this forum, the main repository and the mirror redirector) !

Although not updated yet, the Upgrade Howto remains mostly valid (except the part about yum-style upgrade, as I said above).

• Standard ISO: http://mirrors.xcp-ng.org/isos/8.0/xcp-ng-8.0.0-beta.iso
• Net-install ISO: http://mirrors.xcp-ng.org/isos/8.0/xcp-ng-8.0.0-netinstall-beta.iso
  • Do not use the pre-filled URL which still points at XCP-ng 7.6. Use this instead: http://mirrors.xcp-ng.org/netinstall/8.0
• SHA256SUMS: http://mirrors.xcp-ng.org/isos/8.0/SHA256SUMS
• Signatures of the sums: http://mirrors.xcp-ng.org/isos/8.0/SHA256SUMS.asc

It's a good habit to check your downloaded ISO against the SHA256 sum and for better security also check the signature of those sums. Although our mirror redirector does try to detect file changes on mirrors, it's shoud always be envisioned that a mirror (or in the worst case our source mirror) gets hacked and managed to provide both fake ISOs and SHA256 sums. But they can't fake the signature.

Stay up to date

Run yum update regularly. We'll fix bugs that are detected regularly until the release candidate. Subscribe to this thread (and make sure to activate mail notifications in the forum parameters if you need them): we'll announce every update to the beta here.

What to test

Everything!

Report or ask anything as replies to this thread.

A community effort to list things to be tested has been started at https://github.com/xcp-ng/xcp/wiki/Test-XCP

Hello to everyone.

The Release Candidate (RC) release of XCP-ng 8.1 is available right now .

This post is a mostly a copy-paste from the beta release announcement, with additions regarding the RC release.

Stability status

Good as far as we call tell from our tests and beta feedback. I would personally use it in production (actually we probably will very soon at Vates). The main unknown is how well the new coalesce algorithm will perform. Now is the time for as large testing as possible before the final release.

What changed

Here's what changes from XCP-ng 8.0. Changes since the 8.1 beta are in bold characters.

Non-exhaustive list:

• Based on Citrix Hypervisor 8.1 (https://docs.citrix.com/en-us/citrix-hypervisor/whats-new.html).
• Same base version of CentOS (7.5)
• Same base version of kernel (4.19, with more patches of course)
  • Latest kernel hotfix from CH 8.1 included in the RC release.
• Xen 4.13
• UEFI support for guests is not experimental anymore
• Support for Secure Boot is NOT INCLUDED because it relies on Proprietary packages. We're raising the issue with the Xen community to see how to provide a FOSS implementation.
• Citrix announces:
  • "Improved performance for VM imports and exports that use the XVA format" thanks to the use of a very efficient hash algorithm
  • "Storage performance improvements"
  • "New Windows I/O drivers with improved performance"
  • (From https://bugs.xenserver.org/browse/XSO-951) The next update (apparently not published yet as of 2020-01-27) of the Windows Drivers through Windows Update should at last be compatible with non-english locales!
• chrony replaces ntp
• Support for PV guests is now deprecated
  • templates for creating PV guests have been removed
  • existing guests will still run
  • it is advised to convert them to HVM guests
  • a compatibility layer should be provided in the future for PV guests that really can't be converted. But really anyone who can convert to HVM, should
  • due to how 32-bit PV guests work, keeping it functioning on newer hardware with newer features comes with an increasing performance cost, and the linux kernel is about to drop support for 32-bit PV guests
• Support for AMD EPYC 7xx2(P) added
• Dynamic Memory Control (DMC) is deprecated and will be removed in the future.
• VSS and quiesced snapshots support is removed, because it never worked correctly and caused more harm than good.
  • For backups, we are working on support for backups that include the guest RAM to replace the need for quiesced snapshots.
  • Note that Windows guest tools version 9 (the default for recent versions of Windows if you install through Windows Update) already removed VSS support, even for older versions of CH / XCP-ng
• For new local storage repositories using the EXT filesystem, it now defaults to ext4.
  • The transition from our experimental ext4 storage driver is not automatic.
  • Instructions for transitioning written in specific section below.
  • sm-additional-drivers package updated to refuse to create new experimental ext4 SRs since ext4 is already the default with the ext driver.
• Status of our specific packages:
  • Experimental support for XFS in local storage repository still available through the sm-additional-drivers package.
  • ZFS still available as an additional package and updated to 0.8.3.
  • Alternate kernel now available, version 4.19.102 (probable update to 4.19.108 before final release). Installing it now automatically adds a new boot entry in grub's configuration, to make testing easier. Default entry remains that of the main kernel.
  • netdata RPMs are now ready
    • @r1 contributed a fix to netdata project to bring support for Xen 4.13
    • @stormi made netdata cache be RAM-only to workaround an upstream bug that could make the disk cache grow forever
• Plans are laid out for simpler installation and maintenance of Windows guest tools. Unfortunately, we haven't found resources yet to implement them so the current state remains that of 8.0. If you're a developer on the Windows platforms, we're hiring! (full time or part time, contracts or hires) - Contact us.
• Installer improvements in 8.1 RC: see section below.
• New leaf coalesce logic of VDIs with dynamic limits: see section below.
• Fixed VM Autostart issues in 8.1 beta when updated from 8.0 through yum (upstream bug https://bugs.xenserver.org/browse/XSO-978)
• Fixed netxtreme drivers (bnx2x module) that crashed with some models
• Updated zstd to 1.4.4. Possibly even better perfs according to upstream. Still no import/export comparative benchmarks to 8.0. Does anyone volunteer?

Installer improvements in 8.1 RC

Our installer now offers two new installation options. In BIOS mode, access them with F2 when offered the choice. In UEFI mode, see the added boot menu entries.

• First new option: boot the installer with a 2G RAM limit instead of the 8G default. This is a workaround for installation issues on hardware with Ryzen CPUs. Though those are Desktop-class CPUs and not supported officially in the HCL, we tried to make it easier to workaround the infamous "installer crashes on Ryzen" issue.
• Second new option: boot the installer with our alternate kernel (kernel-alt). That kernel, built and maintained by @r1 for the team, is based on the main kernel, with all upstream kernel.org patches from the LTS 4.19 branch applied. It should be very stable by construction but it receives less testing. That option is there for cases when the main kernel and drivers have issues, so that you can quickly test if kernel.org patches have fixed it already. It will also install the alternate kernel in addition to the main kernel as a convenience. If kernel-alt fixes issues for you, the most important thing to do is to tell us so that we may fix the main kernel!

Announcement about our former experimental ext4 SR driver

It is now deprecated in 8.1. For a good reason: in XCP-ng 8.1 and above, following upstream changes, the ext driver now formats new SRs as EXT4. Existing SRs are untouched (so remain formatted to EXT3).

There is no easy way to convert an existing SR created with our driver, so those using it will need to move the VDIs out (to another SR or to export them), destroy the SR and create an EXT SR instead. Make sure to do this on XCP-ng 8.1.

The sm-additional-drivers package remains available in XCP-ng 8.1 in order to ease the transition. However I've broken the sr-create command on purpose. Any attempt to create a SR of type ext4 will result in an error with a message that explains that you need to use the ext type instead.

Our experimental driver will be completely removed in a later release, possibly XCP-ng 8.2. Unless someone convinces me to delay the removal for a good reason. I will accept reasons such as "I know I shouldn't have used the experimental driver in production, but I did and need more time to convert my SR while at the same time I really need feature xxx from XCP-ng 8.2", but I really would prefer to drop it in 8.2.

Feedback from people doing the transition is welcome to make sure we document the transition in the best way possible.

New leaf coalesce logic with dynamic limits

I have backported patches from sm's master branch, that implement a new, smarter, logic for leaf coalescing.

Those interested in the patches, see https://github.com/xcp-ng-rpms/sm/commit/ed1a55d727846cf5777c8258e6a8f3b068e8a35b (python code).

Feedback wanted.

Documentation

At this stage you should already be aware that our main documentation is in our wiki and you should also know that you can all take part in completing it. It's improving continuously and still has room for improvement.

How to upgrade from XCP-ng 8.1 beta

Just use yum update or Xen Orchestra as if you were installing updates to a stable release.

How to upgrade from previous releases

Since XCP-ng 8.1.0 is a minor release, both upgrade methods are supported:

• From the installation ISO
• From command line using yum (from XCP-ng 8.0 only!)

Refer to the upgrade howto: https://github.com/xcp-ng/xcp/wiki/Upgrade-Howto

Downloads:

• Standard ISO: http://mirrors.xcp-ng.org/isos/8.1/xcp-ng-8.1.0-RC1.iso
• Net-install ISO: http://mirrors.xcp-ng.org/isos/8.1/xcp-ng-8.1.0-RC1-netinstall.iso
• SHA256SUMS: http://mirrors.xcp-ng.org/isos/8.1/SHA256SUMS
• Signatures of the sums: http://mirrors.xcp-ng.org/isos/8.1/SHA256SUMS.asc

If your browser tells you that the page is redirected in a way that prevents from loading the page correctly, this is a known issue. Long story short, it's caused by a wrong security header sent by the forum software, which impacts all non HTTPS requests to the xcp-ng.org domain. Try in Private Navigation mode or use curl or wget.

It's a good habit to check your downloaded ISO against the SHA256 sum and for better security also check the signature of those sums. Although our mirror redirector does try to detect file changes on mirrors, it's should always be envisioned that a mirror (or in the worst case our source mirror) gets hacked and managed to provide both fake ISOs and SHA256 sums. But they can't fake the signature. See https://github.com/xcp-ng/xcp/wiki/How-to-check-the-authenticity-of-files-downloaded-from-XCP-mirrors.

Stay up to date

Run yum update regularly. We'll fix bugs that are detected regularly until the final release. Subscribe to this thread (and make sure to activate mail notifications in the forum parameters if you need them): we'll announce every important update to the RC here.

What to test

Everything and Anything!

Report or ask anything as replies to this thread.

A community effort to list things to be tested has been started at https://github.com/xcp-ng/xcp/wiki/Test-XCP

Feedback is welcome both about successes and failures.

Hello to everyone.

There's a very important way to prove to the world that your software is good: excellence in documentation. A project without good documentation is not appealing and looks un-professional.

I mentioned it here or there, but never made a proper announcement, so here it is: we are now using the wiki on our github project to store documentation:

https://github.com/xcp-ng/xcp/wiki

Now, as you can see, it's missing a lot of useful information. Every red link leads to a non-existent page that should exist, and I probably forgot to add many of them. Thankfully, our community comprises many experienced users of XS and XCP-ng, so we should be able to fill the gap.

I'm myself totally unable of writing documentation about storage or networking. My field of expertise is packaging, updates, releases, patching, writing some code. So I only write about what I know. But I'm sure you're not thinking that I will write the documentation alone.

So this is the official start of the "let's improve the documentation together" campaign. Any github user has write access to that wiki (it's versioned so we can revert changes from trolls if needed).

Don't ask for permission before adding or modifying something to the documentation. Just do it, and others will review it.

Even the structure of the home page can be modified. I made one to help us start and see where contributions are needed, but it's just a way to help us start.

Who's in? If you were looking for a way to get involved in XCP-ng but did not know how, here's your chance!

It's now live!

https://xcp-ng.org/blog/2022/11/18/xcp-ng-8-3-alpha/

Hello everyone.

I'm Samuel Verschelde. I started working full-time on XCP-ng on the 18th or June, so little more than one week ago. It's a pleasure to join your community and to devote my time to this free software project.

Obviously, my first mission targets the release of XCP-ng 7.5. So I figured I'd write a status update post to let you know what's been done, what is being done and what remains to be done. It's easy to get carried away by technical work and to forget to communicate, and I'll try not to fall in this trap. Since I'm still quite new to XCP-ng, please forgive me in advance any approximation or mistake in what I'll write. Just don't hesitate to point any mistake I might be doing, or any omission.

What needs to be done

So, basically the process of releasing the new version of XCP-ng, at the moment (this will evolve), is as follows:

• Get the installation and source ISOs from XenServer 7.5.
• Rebrand to XCP-ng and remove trademarked material (Citrix name, XenServer name, Citrix logo, splash screen...).
• Modify the licensing system to remove the restrictions for features that depend on free software.
• Remove proprietary software components from Citrix that we aren't allowed to redistribute.
• Fix a few known bugs
• Create an update repository for transitioning from 7.4
• Build the installation ISO
• Test (internally at first, but we'll quickly involve the community)
• Release
• (ideally, because we're a free software project after all) Provide source RPMs.

So were are we at this stage?

Rebrand to XCP-ng and remove trademarked material

Mostly done.

We do this for legal reasons, and Citrix obviously doesn't want its name (or XenServer) to be associated with XCP-ng.
Amusingly, though, they added their name in the description of several packages in 7.5. Some of these additions are clarifications, so that's good to help us detect proprietary software or trademarked material among the free software components.

But some other are suprising, such as what they did to the linux kernel package: they added a Citrix logo image in the package (which otherwise contains free software), and then changed the package license from GPLv2 to Portions GPL, Portions Non-Redistributable (See description). And description of the package now contains:

Citrix, the Citrix logo, Xen, XenServer, and certain other marks appearing
herein are proprietary trademarks of Citrix Systems, Inc., and are
registered in the U.S. and other countries. You may not redistribute this
package, nor display or otherwise use any Citrix trademarks or any marks
that incorporate Citrix trademarks without the express prior written
authorization of Citrix. Nothing herein shall restrict your rights, if
any, in the software contained within this package under an applicable
open source license.

Portions of this package are 2017 Citrix Systems, Inc. For other
copyright and licensing information see the relevant source RPM.

A lot of claims for an added logo.

Since the kernel contained by this package is free software, we made a new package without the added claims and without that added logo, so that we can redistribute it.

Modify the licensing system to remove the restrictions for features that depend on free software

We hoped we could simply reuse our package from 7.4.1 but it seems it's not sufficient. Investigations by @johnelse are in progress. Maybe they changed the protocol, maybe we just need a rebuild against latest xapi.

Remove proprietary software components from Citrix that we aren't allowed to redistribute

Some are easy to remove, such as the ParaVirtualization (PV) tools for Windows, which are proprietary. I've been told that Xen Orchestra has support for installing them easily, so we shouldn't miss them too much.

There's one that's giving @johnelse trouble, though: EMU Manager

This closed-source component is tightly coupled to other free software core components. Since I know little about it, I'll let John explain:

emu-manager is a layer between xenopsd (the host-level domain management daemon) and xenguest (which deals with the creation of xen domains) and vgpu (which does the graphics emulation for vGPU)
It is invoked when VMs are suspended, resumed or migrated

To put things in a few words: there's a close-source component that we can't remove without losing suspend, resume and migrate features. So we have to replace it with a free-software component of our own, and that's a hard work: the interfaces are public but not the internals. And we'll lose the vGPU migration ability in the process.

We expect to finish this in two weeks from now, but that may slip. If you think you can help, contact @johnelse or come discuss on the #xcp-ng-dev IRC channel on freenode (we both are on a European timezone).

Fix a few known bugs

• Broken link to XCP-ng center in the HTML welcome page: fixed for 7.5.
• Missing /etc/shadow and other files in install.img: will be fixed when building the new ISO images.
• Fix xcp-python-libs bug mentioned at https://xcp-ng.org/forum/topic/79/configure-dom0-memory-not-work
• Maybe more? I'm not sure this list is exhaustive.

Create an update repository for transitioning from 7.4

Nearly done.

Build the installation ISO, Test, Release

Depends on the above other tasks.

Community involvement

Now that I'm available almost all the time, it should become easier to include contributers from the community. We don't have the target infrastructure for that yet, but it's already possible to help at various stages. So don't hesitate to discuss it on this forum, to contact me ( stormi-xcp@ylix.fr ) or to come to chat on freenode's #xcp-ng-dev IRC channel.

And if you read all of this, thanks!

FYI, I have just published security updates today PLUS the fixed ixgbe driver as an official update to XCP-ng 8.1 and 8.2.

We made it. This is the end of this huge thread.

A big thank you to everyone involved in debugging the issue.

And this is not a :D.

Context: various recent devices on the consumer market require network drivers which are not present in XCP-ng 8.2.

Based on the work made with @Andrew for XCP-ng 8.3, I've finally found some time to backport the drivers to XCP-ng 8.2.

The following optional driver packages will soon be updated on the default repositories:

• igc-module (backported from kernel 5.10.150): adds support for Intel I225/I226.
• intel-e1000e-alt (updated to 3.8.7): adds support for Intel I219-V.
• r8125-module (updated to 9.010.01) for RealTek r8125. Quoting @Andrew:

  Note: This 8125 driver has SG/TSO, PTP, RSS enabled by default.
  Note: This 8125 driver has (optional) firmware loading enabled. Please manually download the rtl8125 firmware and install in XCP in /usr/lib/firmware/rtl_nic .
  Note: The 8125 Chipset/PCI-E card/driver has been known to cause system problems and crashes (not an XCP problem).

These are Additional packages, which means only best effort support is provided for them.

Update (2023-05-03): packages now moved to the xcp-ng-updates repository, which means they can be installed with a simple yum install name_of_package, without the need for extra parameters.

I'm publishing new updates to the base repository of XCP-ng 8.3:

• Security fixes for AMD
• Debian 12 VM template
• Removal of the old and unused experimental EXT4 SR driver. Don't jump: the main EXT SR driver still uses EXT4. I'm talking of the old experimental driver we added back then when the default EXT driver would use EXT3 only. This experimental driver has been deprecated since XCP-ng 8.1.
• smartmontools updated to version 7 which brings JSON output
• A fix for live migration support in IPv6-only pools

XCP-ng 8.3 beta 1 is released!

Announcement: https://xcp-ng.org/blog/2023/06/22/xcp-ng-8-3-beta-1/

This thread is the place where we can discuss this release and where all testers can provide feedback.

Update: AND now Beta 2 released too. We're keeping the same thread.

Hello here! I hope you are ready, because we'll have a train of update candidates for you to test shortly

@gduperrey said in How to Install XCP-ng Guest Tools on Rocky Linux 10?:

but I don't have a release date yet, even for testing

Actually it's already available as xcp-ng-pv-tools in the xcp-ng-incoming repository. What Gaël means is that we haven't run CI on it yet, so we haven't moved the package to the testing repository yet, which is when we usually invite users to test.

However here I'm able to say that there's no risk in installing it now for testing, with:

yum update xcp-ng-pv-tools --enablerepo=xcp-ng-incoming,xcp-ng-ci,xcp-ng-testing,xcp-ng-candidates

(the testing repos will only be enabled for the time of the command, not permanently)

@flakpyro Thanks for letting us know. I suppose there was a mirror that was not ready yet, or had a transient issue, and unfortunately XOA's rolling pool update feature is not very resilient to that at the moment.

IMPORTANT NOTICE!

After publishing the updates, we discovered a very nasty bug when using the UEFI certificates that we distribute. Long story short, they're too big, and there's only limited space (57K), and combined to a preexisting bug in varstored, this will cause the VM to stop booting after Windows or any other OS attempts to append to the DBX (revocation database).

We pulled the varstored update, but those who updated can be affected.

There are conditions for the issue:

• Existing VMs are not affected, unless you propagated the new certs to them
• New VMs are affected only if you never installed UEFI certs to the pool yourself (through XOA or secureboot-certs install), or cleared them using secureboot-certs clear in order to use our default certificates.

If you have the affected version of varstored (rpm -q varstored yields varstored-1.2.0-3.1.xcpng8.3) :

• on every host, downgrade it with yum downgrade varstored-1.2.0-2.3.xcpng8.3. No reboot or toolstack restart required.
• if you have affected UEFI VMs, that is VMs that meet the conditions above but are not broken yet, don't install updates, turn them off, and fix them by deleting their DBX database: https://docs.xcp-ng.org/guides/guest-UEFI-Secure-Boot/#remove-certificates-from-a-vm. This has to be done when the VM is off. Your OS will add its own DBX afterwards.
• If you already have broken VMs (this warning reaching you too late), revert to a snapshot or backup. Other ways to fix them will require a patched varstored currently in the making.

@acebmxer said in XCP-ng 8.3 updates announcements and testing:

@stormi
How to revert changes if needed to? and/or how to switch back to normal repo?

The command only enables the testing repositories for the time of the update, so no need to disable them afterwards.

Reverting changes can be done with yum downgrade, but it's not always doable. XAPI updates can come with an upgrade of the XAPI database. If you downgrade, then XAPI with detect that the database is too recent and will refuse to start.

So, you can technically downgrade the files, but not the state.

New update candidates for you to test! (adding to the previous batch)

New updates join the previous batch of update candidates. I also take this opportunity to call for more feedback on the previous batch of updates, in particular on the changes mentioned in its "What to test" part. Anyway, installing this batch will also install the previous one.

Main changes:

• qemu: Fix BSODs on VMs having the Windows Server 2025 September update and emulated NVMe controllers
• xcp-ng-pv-tools: FINALLY, we could embed our own, signed, Windows Guest Tools in the guest tools ISO shipped with XCP-ng! See https://xcp-ng.org/blog/2025/10/10/signed-windows-pv-drivers-now-available/
• xcp-ng-xapi-plugins:
  • Reworked sdncontroller plugin to properly support all network types:
    • Standard networks on physical devices
    • Bonded networks
    • VLAN on top of either standard networks or bonds
    • Private networks
  • Support per-VIF rules, as well as network-wide rules (no UI in XO at this time, xo-cli recommended)

Other changes:

Optional packages:

• netdata: Minor change in the systemd unit file to avoid minor log pollution. No functional change.

Test on XCP-ng 8.3

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

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

Versions:

• qemu: qemu-4.2.1-5.2.12.2.xcpng8.3
• xcp-ng-pv-tools: xcp-ng-pv-tools-8.3-13.xcpng8.3
• xcp-ng-xapi-plugins: xcp-ng-xapi-plugins-1.15.0-1.xcpng8.3

Optional packages:

• netdata: netdata-1.47.5-4.2.xcpng8.3

What to test

Normal use and anything else you want to test.

Additional focus can be given to:

• Everything we mentioned in the previous batch
• Make sure Windows+Linux VM installation and booting works on UEFI without PV drivers (that's when the NVMe emulated disks are used)
• XCP-ng's signed Windows Guest tools that are finally available on the guest tools ISO!

Known issues

XAPI's handling of remote logging remains to be fixed before the release.

So: don't attempt to set up remote logging yet. If you set it up previously, then it should continue to work.

Test window before official release of the updates

~5 days.

@olivierlambert LVM also plays a role with such SRs, maybe that's it. Or it's another optimization. XAPI had some too.

@Andrew Nice. What kind of SR?

I'm going to build an updated installer with an updated bnxt_en driver, as more and more servers require it.

@flakpyro said in XCP-ng 8.3 updates announcements and testing:

@stormi Installed on my usual test hosts (Intel Minisforum MS-01, and Supermicro running a Xeon E-2336 CPU). Also installed onto a 2 host AMD epyc pool. Updates went smooth, backups continue to function as before.

3 windows 11 VMs had secure boot enabled. In XOA i clicked "Copy pool's default UEFI certificates to the VM" after the update was complete. The VMs continued to boot without issue after.

If you want to go further with the test, you need to clear your pool's secure boot certificates (the ones you probably had installed in the past from XO to "set up the pool for Guest SB"), so that the new pool defaults become the ones we provided with the update.

Then you can try again propagating the certs to the VMs.

A new batch of non-urgent updates is ready for user tests before a future collective release. Below are the details about these.

Main changes:

• edk2: In the virtual firmware for UEFI VMs (OVMF):
  • Update the embedded OpenSSL to version 3.0.9 + additional fixes. This mainly addresses network boot of UEFI VMs from an HTTPS server.
  • Fix VLAN tag handling, that is fix network boot of UEFI VMs on a tagged VLAN (without handling the VLAN at the pool network level, as this makes it transparent to the VM).
• ethtool: Allow ethtool to enable 50G/100G/200G link modes. The dom0 kernel and the Mellanox network adapters driver have been updated accordingly.
• expat: Update from 2.1.0 to 2.5.0, bringing security fixes related to XML handling.
• guest-templates-json: Add templates for almalinux 10, rocky linux 10, debian 13, oracle linux 10, redhat 10
• intel-microcode:
  • Update to publicly released microcode-20250812
  • Security updates for: INTEL-SA-01249, INTEL-SA-01308, INTEL-SA-01310, INTEL-SA-01311, INTEL-SA-01367
  • Updates for multiple functional issues.
  • Note: this update is provided with XCP-ng as a convenience, but this doesn't constitute a fix of a vulnerability in XCP-ng, nor does it entirely replace the action of upgrading your firmware.
• kernel:
  • Enable 50G/100G/200G ethtool link modes in XCP-ng 8.3 kernel and Mellanox network adapters driver. The userspace tool ethtool has been updated accordingly.
  • Fix race condition regarding namespace identifier attributes in sysfs
  • Fix deadlock on PCI passthrough. This is related to the following Known Issue in XenServer: "When NVIDIA T4 added in pass-through mode to a VM on some specific server hardware, that VM might not power on"
• libtpms: Fix CVE-2025-49133 in libtpms - "Potential out-of-bounds access and abort in libtpms due to inconsistent HMAC signing parameters". A guest process with access to the TPM can cause the guest's TPM server to crash by sending malicious commands. This crash does not affect other VMs or the host.
• lvm2: Performance improvements for LVM-based SRs on systems with a large number of VDIs.
• mellanox-mlnxen: Enable 50G/100G/200G ethtool link modes (goes with kernel patches and ethtool patches). Note: this set of changes was initially made by XenServer, and we haven't had the occasion to test it.
• qlogic-qla2xxx: Update to version 10.02.13.00_k. Bug fixes only.
• sm:
  • Adapt the LargeBlock SR driver following the change of configuration in lvm2 rebase.
  • Robustify LINSTOR volume size retrievals to avoid throwing exceptions when not needed.
  • Improve LINSTOR DB robustness: detect failure with a small delay, use specific DRBD options to fit for drbd-reactor.
  • Limit LINSTOR logs in SMlog.
  • Rewrite of the handling of DRBD/LINSTOR command calls: in particular speed gain concerning scan commands.
  • Robustify LINSTOR DB umount call in case of network outage.
  • Robustify the garbage collector to avoid falsely marking VDIs as hidden, subsequently preventing journal rollbacks.
  • Fix error message reported when a snapshot failed.
  • Robustify LinstorSR creation with thick mode.
• varstored: Provide the latest Secure Boot certificates from Microsoft by default. This is a big change compared to the past situation where you had to prepare pools for Guest Secure Boot by manually running a command or clicking a button in Xen Orchestra. Now, if you haven't install any UEFI certificates to the pool, it will automatically use the latest we provide on the system to set up Secure Boot on new VMs. Existing VMs are untouched. Additionally, this will allow to support Secure Boot with future Windows media that no longer use the expired 2011 certificates. Documentation updates are on their way: https://github.com/xcp-ng/xcp-ng-org/pull/328.
• xapi:
  • Notable fixes
    • Consoles are now started for PVH guests => steps towards supporting PVH virtualization mode.
    • Stop ballooning down memory on localhost migration => VDI migration to another SR no longer fails because of unrelated memory configuration.
    • Allow SHA-512 in host certificates.
    • Better error reporting for other_operation_in_progress => now describing what operation was blocking another one.
    • Avoid trying to suspend a VM which doesn't support it, thus preventing a VM crash.
    • Fix an issue that disabled CBT unnecessarily on VDIs on shared SRs during VM live migration. This will also allow to live migrate such VMs during a rolling pool update.
    • Message.get_all_records_where now properly evaluates the query. This will be leveraged by Xen Orchestra to get some information from XAPI faster (by fetching smaller amounts of items).
    • Fix issues with emergency network reset on IPv6 hosts
  • Notable features
    • Best effort mode for NUMA: This is not enabled by default at the moment, but when enabled this means that xapi will try to use a single NUMA node when creating VMs. It is best effort, meaning that this strategy sometimes fails and instead all nodes are used. Especially when many VMs are started or migrated at the same time. Test instructions are provided in the "What to test" section below.
    • Host evacuation was parallelized further, so that the migrating flow of VMs is maintained, avoiding bottlenecks.
    • Storage migration reworked: Allows migration from and to SMAPIv3 storage backends => a step towards SMAPIv3, but not immediately usable.
    • CLI interface: improved autocompletion (xe).
    • New HA option to avoid rebooting VMs on internal shutdown: https://docs.xcp-ng.org/management/ha/#halting-the-vm
  • A lot of other fixes and internal improvements.
• xen:
  • Enhance support for Intel Granite Rapids systems
  • Fix PCI passthrough on some systems
  • Add additional CPU RRD metrics
• xenserver-status-report: bug fixes + collection of additional debug data.
• xo-lite: update to version 0.15.0. See Xen Orchestra's release announcements for the changelog.

Other changes

• blktap: Add a log line when an operation is not supported.
• gpumon: Rebuilt for updated XAPI.
• libarchive: Fixed libarchive package to refresh the ldconfig cache, whose lack impacted driver disk generation
• samba: remove unneeded dependencies.
• swtpm: Rebuilt for updated libtpms.
• xcp-featured: Rebuilt for updated XAPI.
• xcp-python-libs: Various fixes.
• xha: Various fixes.

Added dependency:

• qcow-stream-tool: will be used by XAPI when support for the QCOW2 disk format is added.

XOSTOR
In addition to the changes in common packages, the following XOSTOR-specific packages received updates:

• kmod-drbd:
  • Update DRBD kernel module (improvements, fixes)
  • Important update to fix memory leaks during DRBD resource synchronization: This bug could be triggered during the addition of a node, or after an LINSTOR evacuation following a HW problem and a recreation of the resources.
• linstor:
  • Updated the LINSTOR controller and satellite packages.
  • In particular, a resizing issue that may block a resource has been fixed.

Test on XCP-ng 8.3

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

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

Versions:

• blktap: 3.55.5-6.1.xcpng8.3
• edk2: 20220801-1.7.10.1.xcpng8.3
• ethtool: 4.19-3.xcpng8.3
• expat: 2.5.0-3.xcpng8.3
• gpumon: 24.1.0-65.1.xcpng8.3
• guest-templates-json: 2.0.14-1.1.xcpng8.3
• intel-microcode: 20250715-1.xcpng8.3
• kernel: 4.19.19-8.0.43.1.xcpng8.3
• libarchive: 3.3.3-1.1.xcpng8.3
• libtpms: 0.9.6-3.xcpng8.3
• lvm2: 2.02.180-18.2.1.xcpng8.3
• mellanox-mlnxen: 5.9_0.5.5.0-3.1.xcpng8.3
• qcow-stream-tool: 25.27.0-2.1.xcpng8.3
• qlogic-qla2xxx: 10.02.13.00_k-1.xcpng8.3
• samba: 4.10.16-25.2.xcpng8.3
• sm: 3.2.12-10.2.xcpng8.3
• swtpm: 0.7.3-9.xcpng8.3
• varstored: 1.2.0-3.1.xcpng8.3
• xapi: 25.27.0-2.1.xcpng8.3
• xcp-featured: 1.1.8-2.xcpng8.3
• xcp-python-libs: 3.0.8-1.1.xcpng8.3
• xen: 4.17.5-20.1.xcpng8.3
• xenserver-status-report: 2.0.15-1.xcpng8.3
• xha: 25.1.0-1.1.xcpng8.3
• xo-lite: 0.15.0-1.xcpng8.3

XOSTOR

• kmod-drbd-9.2.14-1.0.xcpng8.3
• linstor-common-1.29.2-1.el7_9
• linstor-controller-1.29.2-1.el7_9
• linstor-satellite-1.29.2-1.el7_9

What to test

Normal use and anything else you want to test.

Additional focus can be given to:

• Network boot of a UEFI VM from HTTPS server
• Network boot of a UEFI VM on a tagged VLAN (without handling the VLAN at the pool network level, as this makes it transparent to the VM)
• UEFI Secure Boot: new VMs, existing VMs, ... And/or just verify that you understand the updated documentation (work in progress)
• Testing on Intel Granite Rapids systems
• 50G/100G/200G link modes with Mellanox network adapters, using ethtool
• vTPM
• Hardware depending on the qla2xxx driver, that is Qlogic 2500/2600/2700/277x/2800 Series Fibre Channel Adapters
• NUMA's best effort mode, for hosts with more than one NUMA node:
  Turn it on, per host, by running xe host-param-set numa-affinity-policy=best_effort uuid=$HOST_UUID.
  Now new VMs should be able to be allocated to single NUMA nodes. To verify that it works, (re)start a VM that can fit in a single NUMA memory node, run xl debug-keys u on dom0, then check the output by running xl dmesg. The last lines of the output will show on which numa nodes each domain (VM) has memory allocated, you should see that the domain that was restarted, usually the one with the highest domain number; has several nodes below it and that all of them except one have the number 0.

Known issues

XAPI's handling of remote logging changed. XAPI now expects a configuration file in a specific location, and we haven't applied this system change yet. We'll publish the related update candidate to complement the current batch in the next days.

So: don't attempt to set up remote logging yet. If you set it up previously, then it should continue to work.

Test window before official release of the updates

~10 days. But please test as early as possible.