Xen Orchestra 5.77

Our November release is here. All aboard the penultimate release of the year!

Xen Orchestra 5.77

There is a lot of exciting stuff ✨ I wanted to thanks everyone involved in this 5.77: we managed to deliver a lot constantly, despite having only 30 days between each new version. Congrats to our XO team and the community!

πŸ›°οΈ XO Proxy major improvements

Now you can easily scale your entire XCP-ng/XenServer infrastructure all around the world without a "shared"/extended network, still using just one XOA to control everything, while doing CR via the proxy, and deploying it with a one-liner. More in this article:

XO Proxy: a concrete guide
A introduction on how to create a global XCP-ng infrastructure managed by a central Xen Orchestra. In a secure manner without any 3rd party network tool.

As promised in the article, you can also simply add an existing XO Proxy from your central XOA via this new interface:

And we managed to get XO automatically utilize the proxy for any operation (management, backup, replication…)

🌑️ Warm migration

Another proof that you can create brand new features by orchestrating multiple XCP-ng hosts at the same time. But let's rewind a bit first.

Some context: imagine you have a datacenter where all your VMs are running on Intel Xeon CPUs, and some of those VMs have pretty large disks. Now, you want to migrate those to a new datacenter running on AMD EPYC CPUs. You can't live migrate, and offline migration will take a long time.

The new button is available in your VM view, Advanced tab.

That's why we created the warm migration: reducing your downtime to migrate to only few minutes, while allowing to move your VMs between various hosts, even if they are running different CPU manufacturers, or even from old XenServer hosts to our latest XCP-ng version.

All the details (and more!) in our dedicated article:

Warm migration with XO
Discover how warm migration can help you to handle different and complex migration scenarios.

πŸ“‘ REST API: snapshots

Our REST API now has 2 new endpoints to request: vm-snapshots and vdi-snapshots. This way, you can fetch any info related to your snapshots (VMs or disks).

The list of available collections is under the path /rest/v0. Remember to take a look at the official documentation for more details.

Remember that you can use filters to only fetch what you need! Here is an example to get only the snapshots of one VM:

curl -b authenticationToken=<TOKEN> \
https://xoa.example.com/rest/v0/vm-snapshots?filter=%24snapshot_of:<VM_UUID>

Enjoy! And keep us posted on what you need. We have plans to get more than read only calls, but this requires creating a queue and using tasks, which is something we are working on with Xen Orchestra 6. More to come on that topic next month!

πŸš€ XCP-ng 8.3 Alpha

If you missed it, we are proud to announce we released a first alpha for our next release: XCP-ng 8.3. There are so many things to talk about, that you should really read the dedicated blog post. However, if you need to remember 2 important things: it's not an LTS version, and it's a decent base for a LOT more stuff coming in 2023. The future is exciting!

XCP-ng 8.3 Alpha
XCP-ng 8.3 first alpha release is now available. Download and try it!
πŸ’‘
This alpha is bundled with XO Lite by default! Just go to the URL of your host, and you'll land directly on the login page.

πŸ”­ XO Lite improvements

Expect bigger news in December with more content and directly usable features.

This month however, we did various components that will be integrated soon, while also improving our responsive design for smaller devices:

πŸ“€ Nagios backup reports improved

In our first iteration of our backup report capability on Nagios (ie: sending backup reports to Nagios), only one job status (failure or success) was sent to your monitoring server.

We've been asked to improve our plugin to support individual backup reports for each VM in a backup job. The plugin UI is very similar:

However, you now have the detail for an individual VM reported, with its job name:

But that's not all! We added a template system for your report, so you can add any kind of description for the service and host. For example, we use {vm.name_label} but you can add xo-backup-{vm.name_label} before. It's exactly the same thing for the Job name and description, with {job.name} available by default.

πŸ”‘ Remove TOTP for a user

It happens: sometimes, a user will lose their TOTP recovery password. To prevent a lock-out, you can now disable it for him, only as an administrator obviously:

πŸš„ OVA generation: twice as fast

In our interoperability quest, we always want to allow people to try our platform without any lock-in. That's why we invest time and effort to get a decent standard support for VM formats, so you can export your XCP-ng VMs to VMware, KVM and anything else supporting OVA format.

However, generating an OVA with VMDK disks inside it isn't really trivial. Due to format differences and some missing features on the XCP-ng API side (knowing the size of what we export), we previously had to make the OVA generation in 2 stages.

We found a way to remove this extra stage, at the cost of some padding, increasing a bit the OVA size as a result. But as it's twice as fast, it's a no brainer. With this release, you can now enjoy faster OVA generation!

πŸ’Ύ Backup resiliency improved

As usual in software, it's relatively easy to write something in the "best case", when everything is working around you. Sadly, there's always a problem happening somewhere (it might be DNS, network, hardware or firmware related. Even if it's always often DNS).

Anyway, our work on improving the whole backup experience is never finished. This time, we fixed/improved various parts of the backup (the "block", not the VHD one), mostly to be more resilient when something is going wrong on your backup storage. We worked on 3 different parts:

  • Merge process refactoring: we made it easier to test and maintain
  • Fixing an edge case: sometimes, block folders weren't created.
  • Allowing merge restart: if an issue happened during the rename/deletion phase (at the end of the merge process), we allowed a merge process restart to resume it on the next job iteration.

It's also a quality of life improvement, since issues on the previous run will be auto-corrected automatically!

🐘 We are on Mastodon!

Maybe you've heard about the Twitter drama. Since there's an uncertain future for this non-free and centralized platform, we used this opportunity to deploy our own Mastodon instance. Obviously, inside an XCP-ng VM running in our production, managed and backed up by Xen Orchestra πŸ˜‰

You can find our server at https://social.vates.tech with our various accounts:

And myself (shameless plug): https://social.vates.tech/@olivier

We'll continue to post on Twitter, but likely only sending links toward our "toots" ("tweets" in Mastodon language). We love the decentralized and open source approach offered by this platform!