You could at least send the backup reports (requires backup-reports and transport-email plugin on XOA) to a Microsoft Teams channel of your choice (Channel - More options - Get email adress).

Upgraded a three host homelab from XCP-ng 8.1 fully patched to XCP-ng 8.2 beta.
Things done/tested successfully:

• Upgrade process (via ISO)
• Copy/Move of VMs (even cross pool)
• Create/Change VMs (Linux, Windows (but not UEFI))
• Add/remove server to XO from source
• Create/Change networks
• Fresh install process (via ISO)
• Basic storage benchmark on dom0 and Debian VM using fio
• Add, Remove, Re-add NFS shares (ISO and storage)

This weekend I try to do some backup/restore (if time permits).
Nice work XCP-ng rocks

[edit: some more tests]

@stormi thank you as well for regulary pushing out security updates and bugfixes . Makes me feel comfortable to have a solid virtualization environment (even with a non-commercial homelab) .

Upgraded a three host homelab:

• ISO upgrade from XCP-ng 8.1 fully patched to XCP-ng 8.2.0 RC
• ISO upgrade from XCP-ng 8.2.0 beta fully patched to XCP-ng 8.2.0 RC
• ISO fresh install of XCP-ng 8.2.0 RC

My quick-and-dirty setup of Let's Encrypt on one of the hosts survived the ISO upgrade - nice

Did a yum update on all hosts and tested:

• Add/remove hosts to XO from source
• Join/remove hosts to a pool.
• Copy/Move of VMs (within and across pools)
• Move VDI between local/shared SR
• Create/Change VMs (Linux, Windows (but not UEFI))
• Add, Remove, Re-add NFS shares (ISO and storage)

Using CA issued certificates on Xen Orchestra from source (xo) improves security and browser compatibility. Creating Let's Encrypt (LE) certificates for Xen Orchestra is simple using pfsense with the acme plugin. It is a two-step process controlled by the acme plugin on pfsense:

1. request/renew LE certificates
2. copy certificates to xo and restart the xo-server

The acme plugin offers several methods for step 1. I am using the Webroot FTP method because I do not want to expose services to the internet and my domain provider (Strato AG) does not offer DNS and/or API based LE support.
Step 2 is the same for all methods in this example. With key-based authentication a ssh user (e.g. acme) will copy LE certificates from pfsense to xo and restart the xo-server

For this post I skip step 1 since it highly depends on your situation, but if acme has been setup correctly you end up with domain specific LE certificates in the /conf/acme/ folder on pfsense. xo.myplaylab.net is my Xen Orchestra from source VM and xo.myplaylab.net.key and xo.myplaylab.net.crt are the LE certificates from step 1.
Step 2 needs some preparation before the acme plugin can automate this step.

Prepare Xen Orchestra from source to receive certificates from pfsense

• create user acme on xo.myplaylab.net
• make acme member of sudo
• limit acme sudo rights to restart xo-server only
• create certificate folder on xo (e.g. /etc/acme/ssl)
• change folder owner to acme
• optional: make xo-servers non-privileged user member of acme if not run as 'root'.

Prepare pfsense to send certificates to xo via ssh

• setup key-based ssh connection on pfsense to ssh into xo
• copy ssh-keys to xo for user acme@xo.myplaylab.net using ssh-copy-id
• ssh into xo with user acme@xo.myplaylab.net and complete process
• check that you can scp the certificates from pfsense to the certification folder on xo
• check that you can ssh into xo from pfsense and restart the xo-server
• these manual tasks will later be executed by the acme plugin.

Prepare Xen Orchestra to use the LE certificates

• make sure that the certificates have been copied to /etc/acme/ssl
• edit /opt/xen-orchestra/packages/xo-server/.xo-server.toml (maybe not the right file )
• uncomment [[http.listen]] and port = 443 in the Basic HTTPS section
• uncomment and change cert to cert = '/etc/acme/ssl/xo.myplaylab.net.crt'
• uncomment and change key to key = '/etc/acme/ssl/xo.myplaylab.net.key'
• uncomment redirectToHttps = true
• restart xo-server and check the status

The final step is to add the shell commands to the xo.myplaylab.net acme configuration. Edit the configuration on pfsense and add the shell commands to the action list.

• scp /conf/acme/xo.myplaylab.net.crt /conf/acme/xo.myplaylab.net.key acme@xo.myplaylab.net:/etc/acme/ssl/
• ssh acme@xo.myplaylab.net "sudo /bin/systemctl restart xo-server"

Did a complete rewrite to be more clear on the interaction between pfsense and xo.

@olivierlambert Thanks - that is what I like about this forum and XCP-ng: learn and share

@stormi updated my three host playlab (8.2.0 fully patched) with no problem. Kicked around some VMs (starting, stopping, live migration, delete, restore from backup, snapshot) but no serious testing. Everything worked fine.

Just a quick follow-up on my last post on restoring backups from a 8.1 to a 8.2.0RC pool.

Successfully tested restoring Linux VMs (Debian 9/10) and Windows 10 VMs (but no UEFI) from 8.1 to 8.2. Tried newly created ("plain") VMs and production VMs (but not all). So apart from that one odd VM, backup and restore works on my homelab / playlab .

@kernelcrunch Deploying the Xen Orchestra Appliance (XOA) on one of the hosts will give you a UI to perform all required actions to create and manage a pool. It is really easy to install and use (and the recommanded UI for XCP-ng).

@stormi did yum update on my three host homelab. So far everything is running as usual, but I did no real test others then starting/stopping/restoring some VMs and moving them around.

@jokurinopoloski are your USB NICs running on VLANs? If so, you could check /var/log/kern.log for xenbr2: dropped over-mtu packet: 1502 > 1500 [...] messages. Maybe not related, but I had a problem with connecting to a NFS SR. While ping and SSH worked, connecting XO from source to the NFS SR failed. After changing the USB NICs MTU from 1500 to 1502, it did work.

@haribo112 You could use USB NICs for additional PIFs if needed to seperate network and backup traffic. This comes at a price, but nevertheless works

@stormi thank you as well for regulary pushing out security updates and bugfixes . Makes me feel comfortable to have a solid virtualization environment (even with a non-commercial homelab) .

@harajukakei As Olivier suggested, it is most likely a network related issue that prevents you from creating the resource set. Pools, SRs and Networks must "match" to make the hosts available in the resource set.

@stormi updated my three host playlab (8.2.0 fully patched) with no problem. Kicked around some VMs (starting, stopping, live migration, delete, restore from backup, snapshot) but no serious testing. Everything worked fine.

Just a quick follow-up on my last post on restoring backups from a 8.1 to a 8.2.0RC pool.

Successfully tested restoring Linux VMs (Debian 9/10) and Windows 10 VMs (but no UEFI) from 8.1 to 8.2. Tried newly created ("plain") VMs and production VMs (but not all). So apart from that one odd VM, backup and restore works on my homelab / playlab .

I am a bit out of my knowledge zone here, so please excuse me if I post something unrelated or obvious.

EDIT - it looks like only this VM has a problem when restored from the 8.1 pool to the 8.2.0RC pool (good pick ). Did some more restores and those restored fine .

Restored the plain backup of a Debian 10 9 VM (based on the Debian 9 Template) from my homelab (DELL R210 II, Xeon E3-1270 V2, 32GB RAM, 8.1 fully patched) to my playlab (DELL Optiplex 9010, i5-3550, 16GB RAM, 8.2.0RC fully patched). My homelab and playlab have different (Synology) NFS SRs connected. I am using XO from source (xo-server 5.70.0, xo-web 5.74.0) to manage my homelab and playlab pool.

Restore was sucessfull and the VM does spin up after about 2min, but with some issues during boot:

[    0.764806] vbd vbd-5696: 19 xenbus_dev_probe on device/vbd/5696

followed by

Gave up waiting for suspended/resume device

and

[***   ] A start job is running for dev-disk-by\x2duuid-7b8f0998[uuid like string].device (8s / 1 min 30s)

and finally (after 1min 30s)

[ TIME ] Timed out for dev-disk-by\x2duuid-7b8f0998[some uuid, see above]
[DEPEND] Dependency failed for /dev/disk/by-uuid/[some uuid, see above]
[DEPEND] Dependency failed for SWAP.

The VM finally starts and is fully working but does the above after every reboot. fdisk -l shows the expected drive/partition/swap. Most likely related to the somewhat different host?

Thank you Olivier , did not see that. Changing the control domain memory is nothing one does frequently and it is perfectly ok to use the CLI. Maybe adding this to the documentation could be helpfull. Already in the documentation - how did I miss that ?

@kernelcrunch Deploying the Xen Orchestra Appliance (XOA) on one of the hosts will give you a UI to perform all required actions to create and manage a pool. It is really easy to install and use (and the recommanded UI for XCP-ng).

What is the correct way to change a hosts control demoin memory using XOA or Xen Orchestra from source (XenCenter is not an option since I am on 8.2.0RC)? I searched the documentation and the forum, but even my google-fu did not help.

/opt/xensource/libexec/xen-cmdline --set-xen dom0_mem=<nn>M,max:<nn>M on the command line works of course