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.

0 stormi committed to xcp-ng-rpms/sm

New leaf coalesce logic with dynamic limits

Patches backported from master

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!

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!

This thread is now read-only. Testing feedback now happens on the thread dedicated to the 8.1 RC release.

Hello to everyone.

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

What changed

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)
• 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 so you still need the sm-additional-drivers package if you have such a local storage repository.
  • We will try to provide an automated conversion from the ext4 experimental driver to the ext driver for the RC (release candidate) release of XCP-ng. If we can't, we'll document the transition.
• Status of our specific packages:
  • 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.2. We may update to 0.8.3 for the RC release of XCP-ng.
  • Alternate kernel: none available yet for 8.1, work in progress
  • netdata RPMs are not ready yet: waiting for Xen 4.13 support added by @r1, needs testing: https://github.com/netdata/netdata/issues/7803

2020-02-20 update

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.

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.

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

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

• From the installation ISO
• From command line using yum

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-beta.iso
• Net-install ISO: http://mirrors.xcp-ng.org/isos/8.1/xcp-ng-8.1.0-beta-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 know 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.

stormi created this issue in netdata/netdata

closed xenstat plugin doesn't build against Xen 4.13 #7803

It's here, finally.

I will not re-detail everything that this release brings, because everything is available here:

• 8.0.0 Release Candidate announcement
• 8.0.0 Official Release announcement

A huge thank you to all of you who have been involved in testing and more.

For you, testers, some information that is not on the blog:

• If you installed XCP-ng 8.0.0 prefinal ISOs from the RC thread, then you actually already have XCP-ng 8.0.0 final! Nothing to do.
• If you installed XCP-ng 8.0.0 beta or RC, just update your hosts like you would do for any regular update and you'll have the same system as if you had installed from the final ISO. Just avoid doing it from the shell console that is started from xsconsole (see why in the updates howto).

Coming. Very. Soon.

Hello to everyone.

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.

First update for XCP-ng 8.1:

• xcp-ng-deps for pulling the gpumon package. That issue has kept us busy this week when people started reporting installed or upgraded systems that would be unreachable from XO and XCP-ng Center after a reboot. Turns out that XAPI needs gpumon, a package that can only be built using a proprietary (from what I remember. One would need to check the license) nVIDIA developement toolkit. I had removed it from XCP-ng 8.1 because I was convinced that it was only necessary with the vgpu feature with nVIDIA, and we don't have the vgpu package in XCP-ng because it is closed-source. XAPI's start process stalls without an error message if there's an nVIDIA GPU. Installing gpumon fixes it.
  • after the update: if you were affected by the issue (you would know), you may need to do an emergency network restart and possibly reconnect the SRs. There may be other consequences for the hosts, such as missing removable media from VMs and possibly others. If you have a way to come back to a backup and reinstall with the fixed ISO (released 2020-04-06), this may be the safest path.
  • see also https://github.com/xcp-ng/xcp/wiki/XCP-ng-8.1-Known-Issues#host-unreachable-after-upgrade-or-fresh-installation-on-hosts-having-an-nvidia-gpu
• xcp-ng-release* for reducing chrony-wait's timeout from 600s to 120s. So if your host can't connect the ntp server that was configured at installation, you'll only have to wait for 2 minutes, not 10. But your hosts really should be able to connect a ntp server. Accurate time is required to avoid timing and synchronisation issues.

No reboot required if your host is already behaving correctly. If you have a discrete nVIDIA GPU and the host had no issue, then 1. I'm surprised, 2. I advise to reboot.

New installation ISOs including those two updates will be released shortly. 2020-04-06 update: they have been released, named xcp-ng-8.1.0-2.iso and xcp-ng-8.1.0-2-netinstall.iso.

As ususal, see https://github.com/xcp-ng/xcp/wiki/Updates-Howto

Hello to everyone.

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

For those who already read the beta announcement, this is mostly the same post, updated for the RC.

What's new

• Based on Citrix Hypervisor 8.0 (see https://docs.citrix.com/en-us/citrix-hypervisor.html).
• 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 to 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.
• Experimental UEFI support for guests
• Quick deploy of the Xen Orchestra Appliance directly from the host's welcome HTML page. Tell us how it works for you and what you think of it!
• A new implementation of the infamous emu-manager, rewritten in C. Very good results until now. Test live migrations extensively!
• Mirrors: you can offer mirrors and yum now pulls from them, depending on your geographical location: https://github.com/xcp-ng/xcp/wiki/Mirrors
• Includes the latest patches for MDS attacks mitigation.
• 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. Reported to work very well! By the way, Xen Orchestra now has support for adding ZFS storage repositories.
  • 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.
• Simplified RPM repository structure. updates_testing, extras and extras_testing repositories disappear and there's now simply: base, updates and testing. Additional optional 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 own build infrastructure, which is based on 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.

Main additions since the beta release:

• New bash prompt and XSConsole colors
• cryptsetup, htop, iftop and yum-utils are now installed by default in dom0
• The XAPI now automatically opens the VxLAN default port when a SDN controller is started. This is useful for the new pool-wide private networks feature from Xen Orchestra.
• xcp-emu-manager bug fixes
• new XAPI plugins for use by Xen Orchestra:
  • ZFS pool detection for ZFS SR creation from XO
  • HyperThreading detection
• Updated linux guest tools: fixed CoreOS support and backported SLES 15 SP1 support from upstream.
• The net-install ISO now points at the appropriate online repository for installing XCP-ng 8.0.0.

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. Since the previous release, it has improved a lot but there's still a lot to improve.

How to upgrade

Since XCP-ng 8.0.0 is a major release, there will be no support for upgrading using yum only.

The reasons for that:

• New kernel. The installer runs on the same kernel as XCP-ng 8.0, so booting the installer ISO is a way to make sure your hardware is still recognized by the new kernel.
• The yum-style upgrade does not offer backing-up your system at this stage, so it's too risky for a major upgrade.

If you can't boot your host on an ISO image, you can still use the remote upgrade alternate method.

We initially planned to support it, but changed our mind due to the risks and the amount of extra work this involves. We still plan to support yum-style upgrades from 8.0 to 8.1.

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 (very small at this stage), please do so and give us feedback! However, we've been testing it internally with success and xcp-ng.org already runs on XCP-ng 8.0 since the beta release (which includes this forum, the main repository and the mirror redirector) !

The Upgrade Howto remains mostly valid.

• Standard ISO: http://mirrors.xcp-ng.org/isos/8.0/xcp-ng-8.0.0-RC1.iso
• Net-install ISO: http://mirrors.xcp-ng.org/isos/8.0/xcp-ng-8.0.0-RC1-netinstall.iso
• 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. See https://github.com/xcp-ng/xcp/wiki/How-to-check-the-authenticity-of-files-downloaded-from-XCP-mirrors.

Update from XCP-ng 8.0.0 beta

Just run yum update and reboot, on pool master first.

Warning: do not run that command from a shell started from XSConsole. The reason for that: when the xsconsole package itself is updated, it restarts XSConsole and thus kills the current shell session, including the currently running yum command (unless you started it in the screen session). This leaves the rpm database in an unclean state.

You can check the cleanliness of yum's database with yum check.

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

XOA quick deploy

Just head towards the IP address of your pool master in a recent browser and try it.

Hi! The update that you were waiting for arrived: https://xcp-ng.org/forum/post/32335

Please test that your UEFI VMs run correctly.

The new implementation of UEFI support for VMs just landed through the last update to the beta.

yum update will install uefistored-0.2.1-1.xcpng8.2.x86_64, then a simple xe-toolstack-restart will take it into account.

Dedicated thread for tests, feedback, debug and discussion: https://xcp-ng.org/forum/post/32335

The new implementation of UEFI support for VMs just landed through the last update to XCP-ng 8.2 beta.

With this update, our new implementation should bring UEFI support that is equivalent to what we had in XCP-ng 8.1. A future update should bring SecureBoot support.

yum update will install uefistored-0.2.1-1.xcpng8.2.x86_64, then a simple xe-toolstack-restart will take it into account.

@beshleman, the main developer of this component, wants your feedback now and is available to help debugging any issue. Both success- and failure- stories are interesting.

Here are a few test ideas:

• Create and install a new UEFI Windows VM (with various versions of windows)
• Create and install a new UEFI Linux VM (various distros)
• Export a UEFI VM from XCP-ng 8.0 or 8.1 and import it on XCP-ng 8.2, then check it works
• Live migrate a UEFI VM from XCP-ng 8.1 to 8.2, and check it still works after a reboot
• (Live migrate a UEFI VM from XCP-ng 8.0 to 8.2 : expected to fail or crash the VM)
• Pause/Suspend/Resume/Live migrate UEFI VMs
• Perform a 2-host (or more) pool upgrade from XCP-ng 8.1 to 8.2 with UEFI VMs on, check that they all survive the upgrade process (no crash) and check that they can be shutdown and started again.
• Any other idea from a tester's twisted mind
• @beshleman may add more test suggestions

Maybe a simple toolstack restart will solve it. There's also the option of trying xe vm-reset-powerstate on the VM.

I'd force-shutdown it on the old pool, check that everything is fine on the new pool, check that I have backups of the VM and then delete it from the old pool if all is right.

First I'd check if a VM with the same UUID exists in the new pool, with its VDIs. Use command line for that as XO will get confused if the same VM exists in both pools (which can happen when cross-pool migration encounters an issue at the end of the migration, especially when migrated from an old XSpool). Disconnecting the old pool temporarily from XO may also be sufficient to allow XO to see it on the new pool (if it's actually duplicated).

By the way, be aware that a single virtual disk is usually represented by several VHD files : base copy, intermediate snaphots... I think you need them all. The database describes all the relationships but it's not that easy to extract the information when it's your first time.

I guess @pnunn doesn't have access to xe either since the host has crashed.

All the information about your VMs and VDIs is written in XAPI's database, an XML file located at /var/lib/xcp/state.db.

If you can't access the hard drive but have a backup of the metadata (recommended to do regularly for any XCP-ng host. XO can do that), it's the same file contents.

I just pushed xcp-ng-pv-tools-8.2.0-1.xcpng8.2.noarch.rpm to the 8.2 base repository. Beta testers can install it with a simple yum update. No reboot required. Please check that :

• guest tools attached to existing VMs are detached during the update
• the new guest tools ISO is available for attaching to VMs after the update
• the updated README.txt looks fine (updated links to the docs, and added a FreeBSD section)
• tools can be installed to linux and FreeBSD VMs

And I expect that XCP-ng 8.2.0 will be perfectly stable well before we release it officially. The main missing piece is fixes to UEFI VM support.