The Beta release of XCP-ng 8.2 is available right now .

Stability status

Our internal tests have not revealed any major bugs.

Note : support for UEFI VMs is currently incomplete and will be completed during the beta phase via an update.

Long Term Support (LTS)

XCP-ng 8.2 will be our first LTS release.

Help us make it rock-solid through your tests!

What changed

Here are the main changes since XCP-ng 8.1.

Based on Citrix Hypervisor 8.2 (https://docs.citrix.com/en-us/citrix-hypervisor/whats-new.html).

Base components:

• Xen 4.13.1 + patches
• Kernel 4.19 + patches

Citrix announces:

• Support for SLES 12 SP5 and Ubuntu 20.04 added
• Support for Windows 7, Windows Server 2008 SP2 and Windows Server 2008 R2 SP1 removed. They may still work, but are not supported officially nor tested anymore by Citrix. Consider upgrading.
• Maximum host RAM raised to 6 TB and maximum number of logical processors per host raised to 448 CPUs.
• Support for installing TLS certificates on hosts (see https://docs.citrix.com/en-us/citrix-hypervisor/hosts-pools.html#install-a-tls-certificate-on-your-server)
• TLS 1.2 protocol enforced for HTTPS traffic, and between XCP-ng components. Support for legacy SSL mode and TLS 1.0/1.1 protocols have been removed.

Other changes:

• Bug fixed for hosts configured with DHCP. xcp-networkd used not to send the hostname along with the DHCP request. We contributed a fix to the xcp-networkd package, that was included in Citrix Hypervisor 8.2 and thus in XCP-ng 8.2 (note: packages with that fix are also available for XCP-ng 8.0 and 8.1 in the xcp-ng-testing repository).
• Backup restore fixed for UEFI hosts. This upstream bug that our community had found and that we reported to Citrix teams has been fixed by them.

Changes specific to XCP-ng:

• Support for Intel IceLake and CometLake CPUs.
• Reimplementation of UEFI VM support : See dedicated section below for details.
• New storage drivers: ZFS, GlusterFS, CephFS... and other changes. See dedicated section below for details.
• The updated Xen brings support for Core Scheduling. We added support for changing the host configuration through the XAPI and contributed it upstream. See dedicated section below.
• Guest tools ISO: Citrix doesn't provide a guest tools ISO anymore in Citrix Hypervisor. They replaced it with downloads from their internet website. We chose to retain the feature and still provide a guest tools ISO that you can mount to your VMs. Many thanks to the XAPI developers who have kept the related source code for us in the XAPI project, rather than delete it.
• OpenFlow support in the SDN controller: support added out of the box for Xen Orchestra to leverage it. The related code is being contributed upstream to the XAPI project.
• We replaced Citrix's gpumon package, not built by us, by a mock build of gpumon sources, without the proprietary nvidia developer kit. See dedicated section below
• Alternate kernel updated to version 4.19.140.
• Additional packages:
  • ZFS updated to 0.8.4.
  • glusterfs 8.1 added to the repositories
  • New additional driver package: r8125-module

Reimplementation of UEFI VM support

The component that handles UEFI variables for VMs, varstored, was redistributable but not open source. So we had to implement our own, named uefistored.

It is not entirely ready yet, that's why XCP-ng 8.2 beta's UEFI VM support is incomplete. Systems like Alpine linux will work, but neither Windows nor Debian will install for now.

This is being worked on and you should see updates very soon.

Since the component was entirely rewritten, we will ask the community to give special attention to UEFI VM tests.

New storage drivers: ZFS, GlusterFS, CephFS... and other changes

We added three new experimental storage drivers: zfs, glusterfs and cephfs.

We also decided to remove the sm-additional-drivers package (that only contained the xfs SR driver) and include all SR drivers by default, including experimental ones. However, we do not install all the dependencies on dom0 by default: xfsprogs, gluster-server, ceph-common, zfs... They need to be installed using yum for you to use the related SR drivers.

zfs

We already provided zfs packages in our repositories, but there was no dedicated SR driver. Users would use the file driver, which has a major drawback: if the zpool is not active, that driver may believe that the SR suddenly became empty, and forget all VDI metadata.

So we developed a dedicated zfs SR driver that checks whether zfs is present before drawing such conclusions.

• Required dependency: zfs
• Documentation: https://xcp-ng.org/docs/storage.html#zfs

glusterfs

Use this driver to connect to an existing Gluster storage as a shared SR.

• Required dependency: glusterfs-server
• Documentation: https://xcp-ng.org/docs/storage.html#glusterfs

cephfs

Use this driver to connect to an existing Ceph storage through the CephFS storage interface.

• Required dependency: ceph-common (not provided in XCP-ng repositories. Check the docs.)
• Documentation: https://xcp-ng.org/docs/storage.html#cephfs

xfs

Use this driver to create and use an XFS SR.

• Required dependency: xfsprogs
• Documentation : to be written. There's nothing special about it, it works exactly like the ext driver, but uses xfs instead of ext4 as a filesystem.

Core Scheduling

The updated Xen in XCP-ng 8.2 brings support for Core Scheduling.

As you probably know, Hyper Threading defeats all mitigations of CPU vulnerabilities related to side-channel attacks. That's why it was required to disable it as part of the mitigations. The reason is that with Hyper Threading enabled you can't protect a VM's vCPUs from attacks originating from other VMs that have workloads scheduled on the same physical core.

With Core Scheduling, you now have another solution: you can choose to leave Hyper Threading enabled and ask the scheduler to always group vCPUs of a given VM together on the same physical core(s). This will remove the vulnerability to a class of attacks from other VMs, but will leave the VM processes vulnerables to attacks from malevolent processes from within itself. To be usedonly with entirely trusted workloads.

How to enable it:

• In a future release of Xen Orchestra, you will be able to enable it with a simple click in the host's advanced settings
• Until then, you can enable it manually by adding sched-gran=core to Xen's command line parameters in grub.cfg and reboot. See Xen's documentation.

gpumon's mock build (tests with nVIDIA GPUs required)

gpumon is an opensource component that can't be built without the appropriate proprietary nvidia toolkit. It is supposed to be only used for nvidia vgpus, which we don't support (proprietary stuff too). We already tried to remove it from XCP-ng in 8.1, however you may remember than we discovered, after the release of XCP-ng 8.1, that the XAPI would not manage to start without it on systems that have nVIDIA GPUs.

This time, we chose another approach: we built a mock version of gpumon (working, but giving fake statistics about the GPUs), so the binary is present on XCP-ng and the XAPI is happy enough with it to start in presence of an nVIDIA GPU.

However, there still is a risk that the XAPI would try to use gpumon later, not only during the startup process, so we need users with nVIDIA GPUs to install XCP-ng 8.2 and test it in various situations.

How to upgrade from previous releases

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

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

Refer to the upgrade howto.

Downloads:

• Standard ISO: http://mirrors.xcp-ng.org/isos/8.2/xcp-ng-8.2.0-beta.iso
• Net-install ISO: http://mirrors.xcp-ng.org/isos/8.2/xcp-ng-8.2.0-beta-netinstall.iso
• SHA256SUMS: http://mirrors.xcp-ng.org/isos/8.2/SHA256SUMS
• Signatures of the sums: http://mirrors.xcp-ng.org/isos/8.2/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 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://xcp-ng.org/docs/mirrors.html#security.

After the installation, stay updated

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 want them): we'll announce every important update to the beta here.

What to test

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

In addition, we ask you to give special attention to:

• UEFI VM support
• The new storage drivers

Report or ask anything as replies to this thread.

Feedback is always useful, both about successes and failures.