Xen Orchestra 5.20

Our monthly release is here, with a bunch of new features and bug fixes. Time to update and discover what's new!

XCP-ng updates

Xen Orchestra is now able to update your XCP-ng hosts directly from the UI! This is a major improvement in XCP-ng usability, without sacrificing our promise to move closer to the upstream: we still rely on yum like any other CentOS, but we can now also do that from XO!

Read our blog post to learn how it works.

UI improvements

Better usage reports

Usage reports now filter useless objects and more clearly display the evolution of each resource (host CPU, RAM, etc.)

List useless VM snapshots

When you remove a backup job, the snapshots associated aren't removed. To avoid a long hunt of those useless snapshots, we are now able to detect them automatically in the "Health view", so you can remove them in one click!

HA advanced options

You can now configure the XCP-ng/XenServer HA behavior for each VM: "restart", "restart if possible" and "disable". For more details, please read the documentation on HA.

Show control domain in VDI list

We now display the Control Domain if a VDI is attached to it. This is helpful to understand what's happening on your storage.

Set a remote syslog host

You can now set a remote syslog host directly from the UI:

This feature is really useful when you want to centralize all your hosts logs somewhere, for various reasons:

• compliance
• security
• log analyze/parsing
• and more!

Backup

Backup concurrency

A new option is available: you can decide to have a max concurrency of a backup process per VM. For example, you could decide to have maximum of 10 VMs backup in parallel. By default, there is no limit ("0" in the text field) BUT we still enforce maximum values. Please read our blog post regarding backup concurrency in Xen Orchestra.

Improved backup logs

A lot more details in the backup logs! Now, each step is individually visible with its duration, current status etc.

Now, you can know in real time which steps failed (snapshot, transfer, merge) and how long which one succeeded.

Improved backup reports

Same story for backup reports, it's far more detailed:

Retry a single failed VM backup

In a job log view, if a VM failed to be backup, you can retry it now. Very handy when it was for a specific reason, like protecting the VDI chain or one failure within hundreds of succeeded VMs: no need to restart the whole job!