Xen Orchestra 5.62
Xen Orchestra 5.62 is available on the latest release branch! This release is mainly focus on improving performances and Quality of Life in Xen Orchestra.
Xen Orchestra 5.62 is available on the latest release branch! This release is mainly focused on improving performance and Quality of Life in Xen Orchestra.
Allow users to create networks with ACLs
Until now, creating networks within a pool was a privilege of super admins in Xen Orchestra.
We have changed this rule to the following: a user who has admin rights on a pool will now be able to create networks on this pool.
IP addresses: handle old tools
In some situations, when multiple IP addresses were configured on a single VM, the old Xen tools were not able to handle them properly.
We improved our compatibility with older versions to make it possible to manage multiple IPs on a single VM, even with older Xen tools.
Display warning on EoL XCP-ng/Citrix Hypervisor versions
We will now display a warning when your XCP-ng or XenServer version is reaching End of Life.
It appears to us that displaying a warning for this information right in XOA is important to improve the security, stability and the support you expect.
Use default migration network in backups
Since Xen Orchestra 5.55 you have the ability to select a default network in Xen Orchestra.
To configure your network, you need to go into the advanced section of the pool.
This network will now also be used by backup jobs in Xen Orchestra (during the export process).
If you have infrastructure with a dedicated network that communicates with your storage, this will allow you to define this nework as the default and Xen Orchestra will automatically use it.
Note: You need to define a default migration network for each pool.
Beta - VHD merge worker
If you are interested in this feature, please open a support ticket to request access. Note that you should not request this feature to use in a production environment for now.
As we explained last release, we intend to move the merge part of a backup job into a separate and independent process. This action will be performed for each remote. One worker will merge all the jobs one after the other.