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

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]

@olivierlambert It is a pleasure to help. I highly appreciate your teams work on making XCP-ng better and more secure as well as the support you give.

@stormi Just did a quick test before and after installing the patch you supplied on one of my playlab hosts (XCP-ng 8.2 fully patched).

Before sudoedit -s '\' `perl -e 'print "A" x 65536'` result in

*** Error in `sudoedit': free(): invalid next size (fast): 0x00005633b9d5b130 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x81499)[0x7efdaf3f2499]
/lib64/libc.so.6(__vasprintf_chk+0x144)[0x7efdaf489114]
/lib64/libc.so.6(__asprintf_chk+0x82)[0x7efdaf488fc2]
/lib64/libpam.so.0(+0x4ec1)[0x7efda7ec7ec1]
/lib64/libpam.so.0(+0x5c83)[0x7efda7ec8c83]
/lib64/libpam.so.0(+0x5b62)[0x7efda7ec8b62]
/lib64/libpam.so.0(+0x6235)[0x7efda7ec9235]
/lib64/libpam.so.0(pam_start+0x20b)[0x7efda7ecaa4b]
/usr/libexec/sudo/sudoers.so(+0x8e88)[0x7efda835be88]
/usr/libexec/sudo/sudoers.so(+0x7d61)[0x7efda835ad61]
/usr/libexec/sudo/sudoers.so(+0x9f44)[0x7efda835cf44]
/usr/libexec/sudo/sudoers.so(+0x1d04d)[0x7efda837004d]
/usr/libexec/sudo/sudoers.so(+0x16c84)[0x7efda8369c84]
sudoedit(+0x543f)[0x5633b924e43f]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7efdaf393445]
sudoedit(+0x6d8f)[0x5633b924fd8f]
[...]

With patch applied, result is

usage: sudoedit [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] file ...

Same goes for sudoedit -s / (did not record before / after), so the patch gives the expected results as described in the linked articels. Already see the respective patches on my Debian VMs as well. Thumbs up for swift reaction

@stormi Can not speak for the issue solved, but upgrading my three host playlab from XCP-ng 8.2 fully patched worked as well as create, live / storage migrate, copy, delete, snapshot (with/without ram), backup and restore of Linux and Windows 10 VMs. Nice upstream, downstream and forum work .

@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

@monotoneculprit If you are on a Windows 10 client, you could give Xen Center a try to manage your XCP-ng host while continuing to investigate the issue with XOA. You could even try to build Xen Orchestra from source if the issue persists, since Xen Orchestra is the recommended management tool for XCP-ng.

From what you describe I still think that you have a network / proxy / firewall issue (See this post as an example, not a solution).

@monotoneculprit Took me about 5 minutes on the cli to download and deploy - strange indeed. Do you have a firewall in place that might interfere? TCP port 8888 is required to deploy, but there would be a different error message, so I doubt that it is that.

@monotoneculprit Just tried it a moment ago and XOA imported and started fine (DELL Optiplex 9010, XCP-ng 8.2.0 fully patched). Can you try to SSH into your XCP-ng host and do bash -c "$(curl -s http://xoa.io/deploy)"?

[18:50 xcp01]# bash -c "$(curl -s http://xoa.io/deploy)"

Welcome to the XOA auto-deploy script!

Network settings:
IP address? [dhcp] 10.10.70.90
Netmask? [255.255.255.0]
Gateway? 10.10.70.1
dns? [8.8.8.8] 10.10.70.1
Importing XOA VM...
Booting XOA VM...
Waiting for your XOA to be ready…

Your XOA is ready on https://10.10.70.90/

Default UI credentials: admin@admin.net/admin
Default console credentials: xoa/xoa

VM UUID: 9ff7c79b-30b4-2532-919b-c1f0cdea5a57

[18:54 xcp01]#

@olivierlambert It is a pleasure to help. I highly appreciate your teams work on making XCP-ng better and more secure as well as the support you give.

@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 Had some time at hand and updated my three host playlab (8.2.0 fully patched). No problem with the update so far and creating linux VMs, live migrate, copy, delete, snapshot (with/without ram), backup and restore of linux and a windows 10 VM is working as expected.

Here is a diff of my sshd_config

[22:37 xcp01 ~]# diff -u /etc/ssh/sshd_config.pre /etc/ssh/sshd_config.post
--- /etc/ssh/sshd_config.pre    2021-02-04 19:57:46.121049198 +0100
+++ /etc/ssh/sshd_config.post   2021-02-04 22:37:18.283422751 +0100
@@ -24,7 +24,12 @@
 HostKey /etc/ssh/ssh_host_ecdsa_key
 HostKey /etc/ssh/ssh_host_ed25519_key

-# Ciphers and keying
+# Ciphers, MACs, KEX Algorithms & HostKeyAlgorithms
+Ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
+MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
+KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
+HostKeyAlgorithms ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa
+
 #RekeyLimit default none

 # Logging

and ssh_config file on host xcp01.

[22:37 xcp01 ~]# diff -u /etc/ssh/ssh_config.pre /etc/ssh/ssh_config.post
--- /etc/ssh/ssh_config.pre     2021-02-04 19:58:18.282487154 +0100
+++ /etc/ssh/ssh_config.post    2021-02-04 22:37:09.447028887 +0100
@@ -66,3 +66,8 @@
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS
+
+       Ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com,aes128-cbc,aes192-cbc,aes256-cbc
+       MACs hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
+       KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1
+       HostKeyAlgorithms ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa

Both files have not been modified. Made copies of the files before (pre) and after (post) the update.

@stormi Just did a quick test before and after installing the patch you supplied on one of my playlab hosts (XCP-ng 8.2 fully patched).

Before sudoedit -s '\' `perl -e 'print "A" x 65536'` result in

*** Error in `sudoedit': free(): invalid next size (fast): 0x00005633b9d5b130 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x81499)[0x7efdaf3f2499]
/lib64/libc.so.6(__vasprintf_chk+0x144)[0x7efdaf489114]
/lib64/libc.so.6(__asprintf_chk+0x82)[0x7efdaf488fc2]
/lib64/libpam.so.0(+0x4ec1)[0x7efda7ec7ec1]
/lib64/libpam.so.0(+0x5c83)[0x7efda7ec8c83]
/lib64/libpam.so.0(+0x5b62)[0x7efda7ec8b62]
/lib64/libpam.so.0(+0x6235)[0x7efda7ec9235]
/lib64/libpam.so.0(pam_start+0x20b)[0x7efda7ecaa4b]
/usr/libexec/sudo/sudoers.so(+0x8e88)[0x7efda835be88]
/usr/libexec/sudo/sudoers.so(+0x7d61)[0x7efda835ad61]
/usr/libexec/sudo/sudoers.so(+0x9f44)[0x7efda835cf44]
/usr/libexec/sudo/sudoers.so(+0x1d04d)[0x7efda837004d]
/usr/libexec/sudo/sudoers.so(+0x16c84)[0x7efda8369c84]
sudoedit(+0x543f)[0x5633b924e43f]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7efdaf393445]
sudoedit(+0x6d8f)[0x5633b924fd8f]
[...]

With patch applied, result is

usage: sudoedit [-AknS] [-r role] [-t type] [-C num] [-g group] [-h host] [-p prompt] [-T timeout] [-u user] file ...

Same goes for sudoedit -s / (did not record before / after), so the patch gives the expected results as described in the linked articels. Already see the respective patches on my Debian VMs as well. Thumbs up for swift reaction

@lonnietc You could SSH into the VM from Dom0 or (manually) switch to the console view of the VM in either XCP-ng Center (XC) or Xen Orchestra (XO). Not sure if that answers your question...

@mstollenwerk Your XCP-ng host will try to download the Xen Orchestra appliance (XOA) from the internet and - like @HeMaN said - the XCP-ng host (the server, not your PC) must have a working internet connection to do so. Since it will connect to the download server through port 8888, this port to the internet must be open. Otherwise it can not connect to the download server which in turn might be the reason for your Unix.ECONNREFUSED error message. This message is from the XCP-ng host, not your local Windows PC.

@mstollenwerk Check if you have a (network, not your local windows) firewall in place that blocks tcp port 8888. This seams to be required for quick deploy.