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 Updated my two host playlab (XCP-ng 8.2.0 fully patched) as per 1 and did a reboot of the hosts.

Created a new Debian 10 VM from scratch, installed the new guest tools and did a reboot of the VM. IP addresses and Management agent are shown as expected. Clean shutdown and reboot is working (from XO from source and from the VM console). Live migration is working as well.

Did the same with a Debian 10 VM restored from backup and it basically works as well. I experienced some "blibs" along the way which I attribute to my impatience (e.g. I was unable to eject the new guest tools disk after a live migration and needed a toolstack restart). Can not reproduce this, so most likely nothing.

Edit #1: Exported a Debian 10 VM with the "old" guest tools installed from another pool and imported it to my playlab pool, installed the new guest tools, did a reboot and it works as expected.

Edit #2: Created a new Ubuntu 20.04 server VM and everything works as well.

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

@ninghe You are creating a pool from different CPUs (Hashwell and Broadwell) and this warning just notifies you that the pool will be limited to the lowest common CPU feature set. You should still be able to create the pool. Running VMs must be rebooted, because they need to be aware of the pools new CPU feature set before they can be live migrated to the host added to the pool. See Pool with different CPU Features Hosts - best solution?! or Cross Pool Migration error when CPU different vendor or the documentation on pool requirements.

@stormi Nice work and the joint effort by the community for tests gets better every time . Keep up the good work . Updated my (semi production) three host homelab and it works - as usual. Now it is time to tear down my playlab for some 10G testing .

@stormi No issue with updating my two host playlab. Just run some simple tests with Debian VMs (create, live migrate with/-out 7.20.0-9 guest tools, start/stop/reboot, snapshot with/-out RAM and revert, online-/offline storage migrate from/to shared and local SR, restore from backup). Restored a Windows 10 VM from backup as well and moved it around a bit. Everything works as expected.

@olivierlambert The cloud hosted routers OVA file can be found on the MikroTik download page. Not related to the OPs topic - I just happen to know this since I was messing around with a CRS306-1G-4G+IN to test 10G in my playlab. A quick try to import either the long-term or stable release did not work by the way.

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