I recently developed a PowerShell script that fills a need that I couldn't find with the built-in reporting options for Xen Orchestra backups.

The script is available on GitHub, It works with PowerShell 7 (if using self-signed certs and using the SkipCertificateCheck parameter), otherwise it may work with Windows Powershell 5, I just didn't get a chance to test that yet.

Repository: https://github.com/codekeller/XO-PS-Scripts/tree/5ed1ce9915a41b266af6db54e29236e6f4265143/Xen Orchestra Backup Report

The script connects to your Xen Orchestra server via REST API and generates HTML reports that combine:

Complete backup job inventory - Shows all configured VM backups, metadata backups, and replication jobs

Execution status correlation - Matches job definitions with recent execution history to show what's actually running vs. what's configured

Professional reporting - Clean HTML output with a list of all configured backups jobs and their most recently run status within the last 24 hours (configurable)

Automated delivery - Optional email integration for scheduled reporting

Why I Built This

Managing backup jobs across multiple pools and sites, I found myself constantly logging into XO to check backup status and manually correlating job definitions with execution results. This script automates that entire process and provides the kind of professional reports that management actually wants to see.

Sample Output

The reports include a summary showing success/failure counts, job definitions organized by type with current status, and detailed execution logs with timing information. The HTML is optimized for both email delivery and web viewing.

The README includes detailed documentation and real-world usage examples. I've also included sample reports so you can see exactly what output to expect.

Getting Started

Basic usage is straightforward with additional options available:

.\Get-XenOrchestraBackupReport.ps1 -XenOrchestraUrl "https://xo.company.com" -ApiToken "your-token" -OutputPath "backup-report.html"

Would love feedback from the community

@jkatz

I ran into the same issue when trying to configure a network adapter with cloudbase-init. The documentation says that the MAC address value is optional but in reality it is required.

In my case I want Xen Orchestra to choose a unique MAC during deployment, and I since I am deploying from a template, the NIC name is a known value. The fix that ended up working for me was to modify the networkconfig.py file in cloudbase-init so that the NIC name is required and the MAC address is optional.

I ended up making some additional changes to allow for the network-config v2 format along with the existing v1 support and some additional logic to aid in setting the dns search domains (I can't recall if this was originally supported or not but I had issues getting it to work with the original networkconfig.py file)

This file needs to replace the existing one that is installed in the C:\Program Files\Cloudbase Solutions\Cloudbase-Init\Python\Lib\site-packages\cloudbaseinit\plugins\common\ directory. To replace it you should make sure that the cloudbase-init service is stopped, then replace the file.

Once this file is replaced, delete the pycache folder in the same parent folder as networkconfig.py - this will ensure that python recompiles this file on service start. Start the cloudbase-init service and confirm that you see a new pycache get created.

I'm not a python programmer by trade so others may be able to point out areas for improvement but this ended up working for me and I wanted to share in case it could help others needing to deploy new servers without manually specifying a new MAC address. Below is an example network-config v2 format that works with the updated file.

version: 2
ethernets:
Ethernet 2:
dhcp4: false
addresses:
- 10.20.30.10/24
nameservers:
addresses:
- 10.20.5.12
- 10.20.5.13
- 10.20.5.14
search:
- intranet.domain.org
- domain.org
- public-domain.org
routes:
- to: default
via: 10.20.30.1

Updated networkconfig.py file:
networkconfig.py.txt

@Pilow I was using Powershell 7. If you are using a self-signed certificate on the XOA server then you'll have issues as the -SkipCertificateCheck parameter isn't available for the Invoke-RestMethod command in Powershell 5.