Release

Xen Orchestra 5.91

Olivier Lambert

Jan 31, 2024 • 17 min read

Welcome to our inaugural 2024 release! This update is particularly robust, featuring an array of new additions: it's one of our largest in terms of new features. A special shout-out to our new users transitioning from VMware; your enthusiasm is greatly propelling the entire Vates ecosystem, including XCP-ng and Xen Orchestra.

In case you haven't heard, we've introduced a new 'bundled' pricing structure. For more details on this, please check out the following link:

👨‍🚀 Project & Community

We have a multitude of topics to discuss, yet we've chosen to concentrate on the most significant ones.

Our insights on the VMware exodus

As one of the leading alternative to VMware, we're right at the heart of the action, engaging with numerous companies exploring their options or already actively transitioning. Our recognition in the "Gartner Virtualization Market Guide" for two consecutive years certainly helps, but there's more to the story. And we wanted to share that with you!

Our numbers clearly illustrate the trend:

More than 95% of our new customers are coming from VMware.
We're handling migrations for installations of all sizes, ranging from a few hosts in small businesses to extensive networks in universities and hospitals.
Smaller systems typically migrate more quickly (thank you Captain Obvious!)
For larger setups, we strategically migrate sections that are simpler to transition. This approach helps mitigate risks associated with VMware's pricing changes and gradually reduces dependency. Our platform demonstrates that managing our stack doesn't have to be daunting – a Linux expertise isn't a necessity.

Our role in the market is not just about "winning awards" or being quoted in a Gartner guide; it's about making a real difference with easy-to-use solutions for our customers.

Finally, we've noticed that VMware partners are greatly affected by Broadcom's new policy changes. To address this, we've specifically designed a supportive program tailored for them:

Our community's rapid growth

We're really excited to see our community booming more than ever. Whether it's the number of people visiting our websites, engaging in our forums, or signing up: everything's shooting up! We're talking about a solid 30% to 50% jump in pretty much all areas. It's incredible to see such enthusiasm and growth.

And hey, with so many new faces around, we thought it'd be great to put together something helpful. So, we've crafted a fresh, easy-to-follow guide for getting started with XCP-ng & Xen Orchestra, which we're calling "Vates VMS." It's perfect for anyone who's just joining us and wants to dive right in:

XCP-ng security updates

A nice bug fix (but also a security issue) has been fixed recently. You can read more details here:

Don't forget to keep an eye on the "security" tag to filter our blog post on XCP-ng security releases.

Updated Linux/FreeBSD Rust tools

Here we go again – another month, another cool update for our Rust guest tools. This time, we've gone the extra mile with a statically linked dependency. What does this mean for you? Well, it boils down the entire deployment process to just a single binary. Talk about making things more convenient!

Open Source XenCenter is dead

So, XenCenter as an open-source project is officially a thing of the past. Cloud Software Group, through its XenServer division, has decided to pull the plug on it. And how did they announce it? Just a quiet update in the README file – a classic move. The message was clear: the XenCenter repository is archived, no more updates, no more pull requests:

Please note that as of December 2023 this copy of the XenCenter repository is considered archived. As such it will not reflect the latest state of XenCenter development, and any pull requests will not be reviewed/merged. If you have any feedback regarding XenCenter, please send it to feedback@xenserver.com.

Here's the source for those who want to see it firsthand: https://github.com/xenserver/xenadmin/#xencenter

It's a "subtle" exit from the open-source world for another component. And yes, they can do that, thanks to the BSD-2 license. This just goes to show how crucial open-source software (OSS) licenses are. We take pride in using aGPLv3 for XO – it's a big deal for us.

What's the fallout from this move? Well, Borzel, a key community contributor for XCP-ng Center, which is a fork of XenCenter, has decided to stop contributing. But it's not all bad news. We're now helping him shift his contributions to XO Lite! In a way, this is positive for us all, as it means we're shedding another dependency on the upstream XenServer.

And it seems this might be just the beginning. XenServer's reluctance to collaborate on shared components has been a recurring theme. But here's our take: if collaboration isn't on the cards, we're just going to do things better on our own. 🤷‍♂️

Doubling down on Open Source

While XenServer seems to be retreating (again) from the open-source ethos (seriously, how many times already?), we're going full throttle in the opposite direction. Our mission? To make contributing straightforward and accessible for everyone. It's all about transparency and sharing. For instance, our Figma designs will be completely open to the public in the next weeks. This move is a clear invitation for you to jump in and start developing alongside us.

We've also wrapped up a new architecture that lets us share components between XO 6 and XO Lite (see below in the release details).. With this new setup, we're gearing up to review our external code contributions very soon.

Why is this a big deal? Well, with our community growing by the day, just think of the massive impact this could have on XCP-ng, XO, and XO Lite. It's all about harnessing the collective power of our community to make things even better!

Expanding our support team

Big news on the team front: Dan P, a standout figure and a familiar name on our forums, has officially joined the Vates family. He's stepping into the support team, bringing his wealth of knowledge and experience with him. And yes, he'll definitely keep on being a pillar of support for our community!

💡

Fun fact: Dan P is the second community member to join our ranks. This speaks volumes about the talent in our community and the great opportunities we offer. We're proud to see our active members become key team players!

Now let's dive into this month's release. Brace yourselves, it's a substantial one with lots to cover!

🐦 VMware to Vates (V2V): now 20 times faster

Reflecting on the VMware shift: It's been a year since we launched our V2V tool, designed to streamline your VM migration from VMware to XCP-ng. This tool is a real game-changer – with just a few clicks, your VMs are seamlessly replicated on the other side:

We've achieved a monumental leap in transfer speed for our V2V tool. In our internal tests, we've astonishingly increased the speed of VM transfers from VMware to XCP-ng by nearly 20 times! Take our test case, for example: an Ubuntu VM with a 25GiB size, of which only 4GiB is actively utilized. Check out the dramatic difference in our 'before and after' results:

It's not just one trick that did the job, but a mix of smart changes. Let's start with the 'import' side on XCP-ng. We ditched the old VHD import system and switched to the XVA format, leveraging the super-fast xxHash algorithm. Sure, generating XVA on XCP-ng (exporting) isn't lightning-fast, but when it comes to importing, it's way better than handling a VHD.

Here's another cool thing about using XVA behind the scenes: unlike VHD, you don't need to read the entire VMware disk to create the block allocation table (BAT). This means we can really stream the disk, ensuring a 'thin' replication every single time in just one read. Now, all imports are thin by default!

And there's more. We've also tweaked how we query VMware, opting for more sequential reads when we can. All these changes combined? In our lab, they rocketed a sluggish 10MiB/s transfer speed to a whopping 200MiB/s! Results might vary, but we're expecting this level of improvement for nearly everyone.

If your network is the bottleneck (like if it's less than 1Gbit), you've still got options. Run the XOA VM on top of your VMware cluster. Why? Because between XOA and XCP-ng, we eliminate the zeros. For instance, in our lab, we hit about 330 MiB/s in read speed with XO on the VMware host, maxing out the 1Gbit/s link to send the "removed-zero-disk" to XCP-ng.

Your feedback is always welcome in our dedicated thread.

💾 Backup

In the realm of backups, the advancements we've achieved with our V2V tool and its fast XVA import hold promising potential for future developments. For the present, though, we're excited to announce a significant new feature currently in preview: immutability!

Immutability (preview)

We made a pretty long explanation/intro on it last month, you can take a look if you missed it:

But this month, you can test it in preview mode! Here is how to install and operate it directly in your Backup Repository (BR).

💡

It's pretty easy to install and run it into any Linux box with an NFS share, acting as your Backup Repository (BR). We wanted to have a first "target" that is pretty simple to deal with, but expect a broader compatibility in the future, as our solution gets more flexible. We started to develop a solution in NodeJS to deliver fast, but it won't be an issue to get a simple "drop-in" binary in Rust or Go.

Installation and configuration in your BR

First thing first, you need to connect to your BR server. The pre-requisite is to install NodeJS, and then to install our package globally:

npm install -g @xen-orchestra/immutable-backups

The, you need to configure it. Since it's installed globally, you will need to create a config files at /etc/xo-immutable-remote/config.toml. Inside this file, you will provide where and how do you want to secure your backup files:

#[remotes.remote1]
root = "/mnt/ssd/vhdblock/" # the absolute path of the root of the backup repository
immutabilityDuration = "7d" # mandatory
# optional, default value is false will scan and update the index on start, can be expensive
#rebuildIndexOnStart = true

Let's analyze quickly this example configuration:

root is where your backup files are stored, and where XO will write it during a backup
immutabilityDuration is for how long a file can't be removed (here, 7 days)
rebuildIndexOnStart at true will rescan the backup files to check everything complies, during the program start

Now, you can start our xo-immutable-remote program, that will protect those target files from deletion for a period, as requested in your configuration. You should see any potential misconfiguration in the output. If everything works well, you can then start it as a service, for example with systemd (we'll provide an example service file).

If everything is correctly configured, you could start a backup on this BR from XO, and those files won't be removable remotely.

There is no communication channel with XO to change the configuration, and it's on purpose: even if your XO is compromised, an attacker won't be able to modify those backups!

Your feedback is welcome on our dedicated forum thread!

📡 REST API

Despite an already busy month in terms of features, we also managed to release two exciting new API endpoints.

Pool emergency shutdown

This feature was asked in the context of having a power cut detected by your UPS. You can just make a simple HTTP call to tell your target pool to immediately shutdown correctly all the VMs and hosts, in the right order. Nothing else than a single call!

We added it as a "actions", and as usual, you can list the available actions (here on the pool) via a simple HTTP GET:

curl \
  -X GET \
  -b authenticationToken=KQxQdm2vMiv7j \
  'https://xo.company.lan/rest/v0/pools/<Pool UUID>/actions' \

You should have this answer:

[
"/rest/v0/pools/<Pool UUID>/actions/create_vm",
"/rest/v0/pools/<Pool UUID>/actions/emergency_shutdown",
"/rest/v0/pools/<Pool UUID>/actions/rolling_update"
]

It means you can RPU or Emergency Shutdown your pool. So to call the emergency shutdown, it's just a PUT HTTP request:

curl -k -X POST -b authenticationToken=KQxQdm2vMiv7j 'http://localhost:8080/rest/v0/pools/<Pool UUID>/actions/emergency_shutdown'

VM creation

Our REST API is now able to do VM creation. If it was already possible (since ever) with the JSON-RPC API, you can now also use the REST one.

Let's me show you how the structure is made:

{
  "params": {
    "affinity": {
      "type": "string",
      "optional": true
    },
    "auto_poweron": {
      "type": "boolean",
      "optional": true
    },
    "boot": {
      "type": "boolean",
      "default": false
    },
    "clone": {
      "type": "boolean",
      "default": true
    },
    "install": {
      "type": "object",
      "optional": true,
      "properties": {
        "method": {
          "enum": [
            "cdrom",
            "network"
          ]
        },
        "repository": {
          "type": "string"
        }
      }
    },
    "memory": {
      "type": "integer",
      "optional": true
    },
    "name_description": {
      "type": "string",
      "minLength": 0,
      "optional": true
    },
    "name_label": {
      "type": "string"
    },
    "template": {
      "type": "string"
    }
  },
  "href": "/rest/v0/pools/<Pool UUID>/actions/create_vm"
},

create_vm is called on a Pool. As you can see, many parameters are optional, mostly because already provided by the template.

♻️ Rolling Pool Reboot

There are times when you need to physically reboot your host for various reasons, be it firmware updates, manual updates you've already installed, or an interrupted Rolling Pool Update (RPU) process. To cater to these needs, we've introduced the capability to initiate a rolling pool reboot whenever required.

This new feature works similarly to the RPU, but with a key difference. Instead of downloading and applying updates, it focuses solely on rebooting. The process starts with evacuating the master host (by live migrating VMs away), then rebooting it, and finally repopulating it. After the master host is up and running, the same process is repeated for all non-master hosts in the pool. This ensures a smooth and orderly reboot of your entire pool without disrupting your operations.

🏷️ Colored tags

Building on the success of our last release's "scoped tags," we've taken tagging a step further – especially useful for those managing large infrastructures serving a diverse range of customers (internal or external). We've expanded beyond just scoped tags to introduce the ability to create and edit colored tags:

With our newly designed "Advanced tag creation" UI, you now have the option to assign colors to your tags, regardless of whether they are scoped. This feature enables quick and effortless identification of different elements within your infrastructure, making it more efficient to manage and navigate through your VMs and resources. It's all about enhancing visibility and organization with just a splash of color!

🗒️ VMs note field

To make managing your VMs even smoother, we've introduced a new feature: editable note fields. Think of it as a space for jotting down anything you need to remember about your VM. And guess what? It supports Markdown!

This means you can use it for a variety of purposes:

Creating a TODO list for operations on the VM.
Describing in detail what's inside or the services it's running.
Storing any relevant information you want to keep handy or share with your team.

It's all about making your VM management more efficient and collaborative.

⚖️ Load balancer

After some dedicated work, we've updated the code for our Load Balancer. The most noticeable change? We've set the default for live migrating VMs during load balancing to two VMs simultaneously. This significantly minimizes the impact on running VMs – to the point where it's practically undetectable from a guest's perspective. Yet, it efficiently shuffles things around as needed.

We've made this parameter adjustable, though our testing suggests that two is the sweet spot for most scenarios. And that's not all – we've got a bunch of other enhancements in the pipeline for the Load Balancer. Keep an eye out for more updates!

🔭 XO 6 and XO Lite: foundations

As you know, our team has been engaged in the development of two key web applications "from scratch": XO Lite and XO 6. XO Lite, our new and streamlined version of our XO series, has been under development for about a year now. Its design and architecture have always been intended to serve as the foundational base for our next major project, XO 6. XO 6, envisioned as the successor to XO 5, is being rewritten from scratch, leveraging the groundwork laid by XO Lite.

The latest structure is centered around three main components: XO Lite, XO 6, and the newly introduced XO Web Core.

💡

As a reminder, XO Lite, a simplified yet powerful version of XO, designed to be lightweight and efficient, also serves as the foundational codebase for the development of XO 6. And XO 6 is the next iteration of XO, following XO 5: it's a complete rewrite, incorporating advanced features and functionalities, building upon the core principles and components of XO Lite.

So what's "XO Web Core"? It's a centralized repository hosting shared code elements between XO Lite and XO 6. It ensures code reusability and consistency across both applications. It will be crucial for our code sharing and migration strategy: essential components, utilities, and configurations are being progressively shifted from XO Lite to XO Web Core. This transition facilitates a unified codebase that benefits both XO Lite and XO 6.

Also, we'll use "component modularization": specific components of XO Lite, initially tailored for its environment, are being modularized. This involves relocating the UI layer to XO Web Core for shared access and retaining the implementation specifics within XO Lite and customizing them for XO 6 as needed.

The TreeView example

The TreeView component exemplifies our modularization approach. Originally part of XO Lite, its UI has been transferred to XO Web Core, while the implementation layers are adapted within XO Lite and XO 6. Indeed, XO 6 is providing many extra features, but we keep the same "chassis" for both!

This restructured approach marks an important shift in our web application development strategy. By leveraging the synergy between XO Lite and XO 6, and centralizing shared resources through XO Web Core, we are set to deliver more robust, scalable, and maintainable web applications, ready to meet the evolving demands of our users. It took time to organize all of this, but now we are ready to accept more easily external contributions for both projects!

🆕 Misc

This release is also pretty large on the "Misc" side of things. Most of the improvements are community feedback, especially from our new users that are not used to our stack. For them, we decided to improve many things in the UI so it's harder to make a mistake!

It was already possible to do it via the CLI or via the now defunct XCP-ng Center UI. It's now exposed in XO UI (and JSON-RPC API and CLI, obviously). Just follow the guide, it's pretty simple:

🙋

Should I use SMB/CIFS over NFS? In general, the answer is "no" if you have a decent NFS server. If you are limited inside the Windows world only, then SMB might be your best option though.

A quality of life feature, telling you more about special tags, for example the "no-bak" tag, avoiding to replicate an already replicated VM:

Warning when restarting a slave host

A common mistake if you are not a seasoned XCP-ng admin, is to update your pool and then start to reboot a pool member (slave) first. This is causing issues, because you should always start with the master, regardless the situation.

To ensure people won't make the mistake, we added a warning when we detect this kind of situation:

Warning on host version in pool

In the same idea than the previous feature, we want to avoid getting different host versions when running in a pool. That's OK while doing an upgrade, but you shouldn't keep that state for long: it can cause various issues, especially when live migrate VMs around. That's why you'll be notified now:

Update VM creator

As requested by the community, following the display on the user who created the VM, an admin can now change this (if it's unknown for example). Simple but useful in the context of having many XO user creating VMs often:

XOSTOR

In some cases, at XOSTOR creation, you might want to really wipe the previous content of the target drives. We added this option in the UI with a checkbox to wipe the previous installed filesystems:

Logs Ref & UUID translation

In your Settings/Logs but also in the Audit log feature of Xen Orchestra, you also have messages displaying object UUIDs or Ref. That can be used to debug further, but it's sometimes not convenient to track. That's why we added a new feature that is automatically translating those identifiers into clickable links:

This way, you immediately know which is the object in question, routing you to the object page for example (VM view in the previous screenshot). It's a really nice quality of life improvement!

Rolling Pool Update guidance

Instead of always enable the possibility to click on "RPU" to do a Rolling Pool Update, XO is now able to detect if this operation is possible or not. If the button is disabled, a tooltip will explain why it's not possible:

Again, we wanted to guide more our users with this kind of features.

Self-service current usage even if unlimited

As a member of the self-service, you are always aware on how much resources you are using. But we did not implement the current usage if it was set to "unlimited". Our community requested to still know the amount despite there's no limit, and it is now done!

Auto load all plugins automatically

For our sources users, this will allow you to enjoy 100% of our plugins automatically!

Debian 12 template available from the Hub

Thanks to Cécile, we got a fresh Debian 12 Cloud-init ready template available in your XO Hub.