News about 8.3 Alpha

Devblog Feb 27, 2023

Hello everyone! I wanted to give you some updates on what's new for the XCP-ng Alpha, since we've made the first release. As a reminder:

XCP-ng 8.3 Alpha
XCP-ng 8.3 first alpha release is now available. Download and try it!
💡
Remember: despite it works already pretty well, it's still not production grade! But it's OK to play with it in a lab for example.

🖥️ XenServer is back

Citrix Hypervisor 8 Cloud was abandoned, and Citrix Hypervisor is becoming XenServer again (yeah, I know). The way users will update their hosts is the main change besides the name: no more need to do it from Citrix Cloud. Apart from this, development is going on towards the 8.3 release.

Better collaboration

XCP-ng 8.3 was updated to match XenServer 8.3 development: we are now loosely synchronized with XS 8.3 development. Maybe a few weeks behind, for XAPI at least.

It's not always easy to get the attention of reviewers, explaining why some topics move slower than others. All in all, we keep pushing for it and we hope the situation will improve in the future.

✨ New features

There's new things which landed in the updates in 8.3 since we made the alpha release. Don't forget that you can provide feedback for all of them on the dedicated forum thread.

Basic vTPM support

The first vTPM support landed: you can create a vTPM and assign it to a VM and run Windows 11 VMs. Snapshots, import/export, migration and HA are not supported yet. However, it's moving forward pretty fast, and XenServer team has the lead on this feature.

New guest templates

Even if it's not a huge deal, it's always important to catch up on having templates for more recent OS versions. On that topic, we probably want to be more pro-active than our friends at XenServer, since our community is using far more cutting edge distros. So it's possible you'll get more templates and delivered at a faster pace.

Anyway, the new guest templates are Debian 11, Ubuntu Jammy, RHEL 9 and clones.

💡
It's OK to use a template from a similar distro (or just a version behind) if the template is not publicly available.

Major work on the installer

We managed to make various important improvements on the XCP-ng installer itself. I would say we have around 80% of the work done.

One of our goals was to be able to build ISOs in a fully automated fashion, and trigger also an automated test suite right after it (in the same process). That will be very helpful to help us release nightly -or weekly- ISOs!

LACP bond support during install

This feature was requested since a bit: if you already have an LACP bond configured on your switch, you might want to install XCP-ng directly without removing the bond first on the switch (which was the case before).

In this case too, we have around 80% of the feature finished:

  • XAPI pull request merged upstream: applies the bond configuration at first boot
  • Installer pull request submitted upstream, but didn't receive feedback yet
  • Known limitation: only usable for pool master, as other hosts can't join an existing pool if they already have a bond. This is a topic for possible future developments, not planned at the moment.

Better support of previously used RAID devices

In this case, we identified and worked on correctly handling hosts which are already configured with a software RAID on the main disk from a previous system:

  • Allow you to erase an existing software RAID on the main disk or its partitions, to avoid the installation issues known to those who attempted to install XCP-ng on such disks
  • PR awaiting feedback from XenServer
  • Recent user feedback allowed us to also understand how to also clean up leftover ZFS metadata on partitions, which also cause issues (local SR not created at first boot). It's to be done, but moving forward.

Improved IPv6 support

We started to develop this feature a while ago, see:

XCP-ng DevBlog - IPv6 support
After years of requests for IPv6 support in XenServer, we decided to roll up our sleeves and make it real in XCP-ng. Discover our journey!

However, as any project with an upstream (and another downstream), we had to do a lot of things to get our PRs merged. Even if it's for good reasons, it takes time:

  • Pull requests to XAPI accepted and merged several months ago
  • Two pull requests still remain to be merged upstream. One to xha (HA daemon) and one to the installer.

The xha one was reworked to take feedback into account and is just lacking the final "go". On the installer side, it moved slowly, as feedback happens once every few months (!). But all is not due to the pace of interactions: we still have work to finalize on it.

On our side, we need to handle the case when a host management interface is IPv6 only and an update mirror is IPv4 only.

Other installer changes

I think this list is a good demonstration of the huge amount of work done by the XCP-ng team in the recent months:

  • memtest86+ in the installer was updated to version 6, with EFI support
  • The xen-pciback.hide boot parameter, useful for PCI passthrough, will now be retained when upgrading XCP-ng (merged upstream)
  • Default SR type will now default to ext, and the choice will be presented as radio buttons rather than a checkbox (not contributed upstream as not relevant for XenServer)
  • Removed the "Do you want to install any supplemental packs?" dialog at the end of installation (upstream PR submitted to make it optional so that we can disable it while keeping the same code as upstream)
  • Always display the primary disk selection screen, even if only one disk is fitting. The fact that is was automatically skipped when only one disk meets the prerequisites often caused users to mistake the Local SR creation screen to be the primary disk selection.
  • Improved contrast on the installer's welcome screen in BIOS mode
  • A few minor fixes (merged upstream)

🎯 Other improvements

There's many many areas we've worked on the last months. It also gave us a lot more confidence on participating upstream and also mastering all the components in XCP-ng.

Improved XAPI performance

Some optimizations were made in XAPI's code. This means faster requests in general, and better behavior when you have a lot of VMs. It's also less stress on the Dom0, which is always a good thing to get! All those improvements are on the credit to the great XenServer/XAPI team at Cambridge. Kudos to them!

Security fixes

We also provide all security fixes that are also relevant to XCP-ng 8.2 LTS.

Better hardware support

We decided to ramp up on hardware tests, thanks to XTF (Xen Test Framework), a micro-kernel VM used to run some basic tests after boot. It's very fast to run and able to detect various issues.

We started to spread the word in the community to get more feedback on a huge variety of machines, you can see the thread on our forum here. We are also about to put that in our official documentation. This helps to provide the whole community a simple way to contribute to XCP-ng!

HTTPS everywhere

The XenServer team worked hard on getting HTTPS support for all operations (for example storage migration) so that port 80 can be eventually closed in the end. It's not complete yet, but moving fast in the right direction!

In that category, we can also note there's some work to provide automatically an HTTP to HTTPS redirection on the host webpage. It was merged upstream but then XAPI developers made us change the behavior so now we have to update xapi.conf first. It will be done soon!

Python 3

A joint-operation with XenServer team, killing all the Python 2 code in the platform to replace it with Python 3. A few scripts were ported, and now Python 3 is installed alongside Python 2 in the Dom0, so the entire code base will be ported progressively.

🚧 In progress

There's also things that are almost done, but we wanted to keep you posted on it too.

Open SSH configuration

We wanted to avoid overwriting ssh configurations each time the xcp-ng-release package is updated. In order to ensure the ciphers and algorithms validated by their security team are always applied, XenServer chose to fully overwrite the SSH configuration in /etc/ssh/sshd_config and /etc/ssh/ssh_config each time either the xenserver-release-config RPM (xcp-ng-release-config in XCP-ng) or OpenSSH are updated.

They did this in 8.2 hotfixes but we did not apply this change (the configuration changes remain applied through patches in our packages). In XCP-ng 8.3, however, we synced with them, for now. We still want to let our users customize their SSH configuration as they see fit, so we are looking for alternatives.

The main difficulties are not technical: it's finding someone at XenServer ready to discuss this packaging-related topic (that they may see as an internal matter) and ideally find a common solution. If we don't manage to get any viable interaction, then we'll do it our way, on our own, but we try our best to avoid this kind of situation: this will increase future maintenance burdens.

UEFI Secure Boot

There's also some interesting developments on the UEFI Secure Boot certificates: we proposed a design to XAPI developers, who took it into account to write their own design, different on the technical side, but answering the same user needs in the end!

Though, the development is still in progress: it could have been more open (their new design wasn't published publicly), but the positive part is that the user needs we expressed were taken into account and we are taking part in the code review. If development takes longer than planned, it may be postponed to a Beta 2 release.

Updates management

XAPI provided some updater improvements based on yum support. However, the feature was developed by XenServer developers and was tailored to their own specific needs, without taking XCP-ng into account at all.

So we didn't make our decision yet: contribute to change the current behavior, or go with our own, simpler, XAPI plugin. It might need to be postponed to a later release, after 8.3.

Conclusion

As you can see, we've been very busy 🏃 It's hard to grasp the amount of work to deliver an open source stable, turnkey and working virtualization platform out-of-the-box! That's why I wanted to share the incredible efforts made by the whole XCP-ng team 💪

Tags

Olivier Lambert

Along with Samuel Verschelde

Vates CEO & co-founder, Xen Orchestra and XCP-ng project creator. Enthusiast entrepreneur and Open Source advocate. A very happy Finnish Lapphund owner.