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).

@stormi Did not even know the problem existed . Anyway, added a new (second) DNS server (9.9.9.9) to the DNS server list via xsconsole and rebooted the host (XCP-ng 8.2.0 fully patched).

Before update: DNS 9.9.9.9 did not persist, only the previous settings are shown
After update: DNS 9.9.9.9 did persist the reboot and is listed together with the previous settings

Deleting DNS 9.9.9.9 worked as well, so the xsconsole update worked for me.

@stormi Updated my two host playlab (8.2.0 fully patched, the third host currently serves as a Covid-19 homeoffice workstation) with no error. Rebooted and ran the usual tests (create, live migrate, copy and delete a linux and a windows 10 VM as well as create / revert snapshot (with/without ram) ). Fooled myself with a VM_LACKS_FEATURE error on the windows 10 VM until I realized that I forgot to install the Guest tools - I need more sleep. Will try a restore after tonights backup.

Edit: restore from backup worked as well

@stormi Again more a regression test for the basic things. Tested Debian and Ubuntu VMs (create, live migrate with/-out guest tools (now at 7.20.0-9), start/stop/reboot, snapshot with/-out RAM and revert, storage migrate from/to shared and local SR). Imported Centos and Ubuntu VMs and restored a Windows 10 and a Debian VM from backup. No issues so far. Nice work.

@stormi Did the update on my two host playlab, which worked well. Do not use secureboot/UEFI or QNAP, so this is more a regression test for the usual stuff. I tested Debian, Centos and Ubuntu VMs (create, live migrate with/-out guest tools (now at 7.20.0-8), start/stop/reboot, snapshot with/-out RAM and revert, storage migrate from/to shared and local SR) and restored a Windows 10 and a Debian VM from backup. As for now, everthing is working. I will see how backup runs tonight.

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
Cannot test the bugfixes on my system but did an ISO update of my two host playlab (DELL Optiplex 9010, XCP-ng 8.2.0 fully pathed) with the updated installation images for XCP-ng 8.2. The update process went well, but this are pretty plain and identical systems with XCP01 being master and XCP02 being slave. The only thing different between the hosts was that I had to confirm the NIC setup steps on the slave XCP02 but not on the master XCP01 (which was updated and rebooted first)?
Apart from the update process, creating, starting, stopping and deleting (Linux) VMs does work as usual as well as taking snapshots and doing VM and storage migration. Will do a fresh install with the updated installation images the other day if time permits.

@stormi A lazy sunday morning, some coffee, a notebook and time for testing. Updated my two host playlab (DELL Optiplex 9010, 8.2 fully patched) and tested Debian VMs and Windows 10 VMs (create, live migrate with/-out guest tools, start/stop/reboot, snapshot with/-out RAM and revert, online-/offline storage migrate from/to shared and local SR). Restored a Windows 10 and a Debian VM from backup. All good so far for this regression test.

@benjireis Had some time for testing and installed the update on my two host playlab (DELL Optiplex 9010, XCP-ng 8.2.0 fully pathed). This are identical hosts with an onboard NIC (Intel 82579LM, eth0) and a dual port NIC (Intel 82571EB/82571GB, eth1 and eth2). Both are connected to a Synology as shared storage.

• Starting with the master, both hosts updated and rebooted without an issue.
• Live migration of Debian, Ubuntu, Centos and Windows 10 VMs works (with and without guest tools installed).
• Host evacuation over eth0 (Management network) without the new network-uuid parameter works as before.
• Host evacuation over eth1 (Storage network) with the new parametrer works at full gigabit speed.

Still working on 10G in my playlab, so i only have 1G available, but host evacuation over a non- management network works with the new network-uuid parameter.

@stormi Successfully updated my two host playlab (8.2.0 full patched, but with the new guest tools ISO). Rebooted both hosts and ran my usual test program (create, live migrate (without (only Debian) and with guest-tools installed (Debian 10 and Windows 10) avoiding the VM_LACKS_FEATURE error on Windows 10 - more sleep this time ), copy and delete as well as create / revert to snapshot (with/without ram) and (live/halted=shutdown) storage migration remote to local SR and back). Also restored a Debian 10 VM from a pre-update backup with no problem. Looks good . Will see how backup runs tonight, but I am confident that this will work as well.

Edit #1: typos

Edit #2: Thanks to Xen Orchestra, out-of-band management even for Optiplex 9010s, a notebook and a very nice evening on the balcony, I extended my tests to Ubuntu 20 LTS. And you might guess it - works as well

Edit #3: Deleted a subsequent post on an asyncMap is not defined error because it is not related to the security update.

@stormi A lazy sunday morning, some coffee, a notebook and time for testing. Updated my two host playlab (DELL Optiplex 9010, 8.2 fully patched) and tested Debian VMs and Windows 10 VMs (create, live migrate with/-out guest tools, start/stop/reboot, snapshot with/-out RAM and revert, online-/offline storage migrate from/to shared and local SR). Restored a Windows 10 and a Debian VM from backup. All good so far for this regression test.

@olivierlambert No, everything looked quite normal. Is there anything I should pay special attention to?

I extended my test today by creating a softraid boot device with two identical SSDs for a XCP-ng clean install. The installer guided me through the install and softraid creation process without any hiccups or complains. Did a XOA quick deploy after that for my now single host pool (since I used the other host's boot SSD for the RAID), connected to the NFS SRs (ISO and data) and did some shutdown / reboots of the host. Even disconnected one SSD of the softraid while the host/RAID was online (not recommended, but hey - it is a playlab) but XCP-ng and some running Linux VMs just kept going. Adding the disconnected SSD back into the RAID from cli was unspectacular (State is clean again). The only thing that somehow surprised me is that there was no information or warning on the degraded RAID status in XOA (or I missed it). How would I know (from XOA) that the boot device RAID is degraded?

@stormi
Did a complete wipe of my two host playlab today and a fresh install with the updated installation image. Still cannot help with the bug fixes, but installation went as usual and there is nothing special I can report. Did a XOA quick deploy, created my pool of two host, connected NFS SRs (ISO and data), imported some VMs (ova files) and moved them around a bit. Create a new Debian 10 XO from 3rd party script VM from scratch and in addition restored Windows and Linux VMs from backup. Looks good. Let me know if I can test anything special with my setup.

@stormi
Cannot test the bugfixes on my system but did an ISO update of my two host playlab (DELL Optiplex 9010, XCP-ng 8.2.0 fully pathed) with the updated installation images for XCP-ng 8.2. The update process went well, but this are pretty plain and identical systems with XCP01 being master and XCP02 being slave. The only thing different between the hosts was that I had to confirm the NIC setup steps on the slave XCP02 but not on the master XCP01 (which was updated and rebooted first)?
Apart from the update process, creating, starting, stopping and deleting (Linux) VMs does work as usual as well as taking snapshots and doing VM and storage migration. Will do a fresh install with the updated installation images the other day if time permits.

@cyrus104 That makes sence. Depending on the IPMI/BMC, you could add an ipmitool -I lanplus -H [Host IP] -U admin -P [admin password] power on for each XCP-ng host into the TrueNAS Init/Shutdown Scripts settings, if your hosts support ipmitool.

@cyrus104 You could change the grub boot delay on your XCP-ng host, so that your host waits longer. Let's say your SR is savely available after 60s, you could set the boot delay to 70s.

@marc-pezin After reading the blog post, one question / remark immediately comes up. To use XO Lite, the host must have a working internet connection to load the React JS app from your servers? Or is it just the computer that loads the app?

Silly me - the graphic says it all: it' only the computer.

@marc-pezin Nice to see XO Lite (and XO 6) becoming reality . When and how will XO Lite be available for testing?

@stormi what is the best strategy to revert a host with testing updates installed back to the standard, non-testing status? Just wondering, if there is a more simple approach than doing a clean install / revert to backup.

@stormi Again more a regression test for the basic things. Tested Debian and Ubuntu VMs (create, live migrate with/-out guest tools (now at 7.20.0-9), start/stop/reboot, snapshot with/-out RAM and revert, storage migrate from/to shared and local SR). Imported Centos and Ubuntu VMs and restored a Windows 10 and a Debian VM from backup. No issues so far. Nice work.