Xen Orchestra 5.56

Backup code major upgrade

A few months ago, we started working on an overhaul of our backup code. Xen Orchestra 5.56 marks the first phase of deployment of this new backup code and its accompanying new features.

If you want to learn more about our backup improvements project, you can take a look on our dedicated devblog.

New main backup code

The backup code we wrote for the XO proxies is the most advanced backup code we have in Xen Orchestra.
We developed it from scratch with our experience on previous code base, improving almost all of it. Making it both more flexible and more robust.

In Xen Orchestra 5.56, this code became the main backup code, in all Xen Orchestra components, main appliance as well as proxies. We are expecting it to bring many improvements in the performances of backup jobs.
It's a faster but also more resilient when it comes to failures or corruption and overall much more reliable.

This is the biggest and initial step in our major backup code upgrade process. And this will help to build very cool features!

Coming soon: backup workers in xo-server

A direct consequence of this new code: in our next release, each backup jobs will be executed in a different worker. It means those new threads will bring more scalability and performance when there's multiple jobs running at the same time.

But it will also keep the main event loop free for any other backup process happening in the background. In other words, XO UI will be more responsive regardless the amount of jobs running behind!

Among the benefits of such method:

• It will make XO more responsive
• A single process crashing will not stop everything
• Backup performance will be less CPU limited - a single process runs in a single CPU, but multiple processes means you can add vCPUs to get faster backups

So stay tuned for our March release!

Schedule a forced full backup in delta job

In order to avoid particularly long VHD chains in delta backup jobs, it is recommended to make a full backup on a regular basis.

It is now possible to schedule a full backup when creating a delta backup job (and not just tell every xx backup).

Custom disk snapshot

Before this, we relied on VM.snapshot call in host API to make snapshot of the VM. However, this method isn't capable of bypassing some disks. It means even if [NOBAK] in the disk name prevented to transfer it, it was still snapshoted anyway.

Now, we can do snapshot at the disk level directly with VDI.snapshot and avoid specifically [NOBAK] drives.

However, this option is now working only for halted VM, because of XAPI limitations. We'll push upstream to upgrade the VM.snapshot method to pass extra args, asking for some VDI to be NOT snapshoted.

Display more information on tasks progress

In the current task view, you will now have an estimate of the elapsed time and the time remaining before the task is completed:

It's a pretty crude estimation, but still interesting to get a rough idea.

Remove disconnected objects

When xo-server is losing connection with the pool master, we didn't flush the objects. That's why, sometimes, you would think those VMs/hosts etc. were still there despite they are not.

Now, the behavior is different: when we lose contact with the pool master, all related objects are directly flushed (we clear the object cache). No more confusion or "ghost" task/VM and so on!

The ideal way could be to "grey" them at some point (at least for a bit), but we wanted to get rid of this first.