Ok i redeployed as a separate xo... I was able to get one of the two vms i had trouble with initially. The one that is not connecting is a Fedora vm running docker.

This test i used same ssh key for all three vms and user name.

After some digging around and with AI help i got the Fedora Docker vm connected...

There is a possibility i might not had sshkey installed on the vm. I should have looked before re-applying it.

SELinux: Fedora blocked sshd from reaching Docker's socket, which XO needs in order to talk to Docker. It denied two things, writing to /var/run/docker.sock and connecting to the Docker daemon. The two rules we added with audit2allow allow both. Ubuntu doesn't enforce SELinux, which is why the other two VMs worked with the same user and key.

@nathanael-h said:

@acebmxer Thanks for your very quick feedback, even more with screenshot for the VM where the connection to the docker socket did not worked, are you sure the public ssh key corresponding to the private ssh key filled in the form is correctly deployed in the VM, to the corresponding ssh user? Do you have any logs from xo-server?

Yes i double checked the ssh key. As for the logs is there a particular log you would like to look at?

@nathanael-h

thanks for the build... I have tested and i was able to connect one vms docker to it. Other vms fail. The do prompt for the finger print but fails to connect...

Update - changes are live in the dev branch now.

So figured out the update / switching branches for the proxy by connecting the proxy to my xoa free account. That triggered the available update to next version. From there I found the command that needs to be ran on the proxy to switch back and forth...

Latest branch

stable branch

Backup job ran sucessful.

2026-10-09T17_48_25.447Z - backup NG.txt

After the proxy has been deployed...

The proxy has been registered with your Xen Orchestra instance.
You can manage it from the Xen Orchestra web interface.

Next: register the proxy's updater and move it to the 'latest' channel.

1. On the pool master (IP), set a password for the proxy's 'xoa' user
   (choose your own) and reboot the proxy VM:
   xe vm-param-set uuid=UUID xenstore-data:vm-data/system-account-xoa-password='<your password>'
xe vm-reboot uuid=UUID
2. SSH to the proxy as 'xoa' (IP) and run:
   sudo xoa-updater register - This registers it with your vates account.
   sudo xoa-updater configure-channel xo-proxy-appliance-latest - set to latest or stable
sudo xoa-updater upgrade - This can be ran via the UI or this command. Both need to be done twice to do the upgrade and/or downgrade.
   register needs a free xen-orchestra.com account; see the README.

And host connected via proxy.

Update - changes are live in the dev branch now.

So figured out the update / switching branches for the proxy by connecting the proxy to my xoa free account. That triggered the available update to next version. From there I found the command that needs to be ran on the proxy to switch back and forth...

Latest branch

stable branch

Backup job ran sucessful.

2026-10-09T17_48_25.447Z - backup NG.txt

After the proxy has been deployed...

The proxy has been registered with your Xen Orchestra instance.
You can manage it from the Xen Orchestra web interface.

Next: register the proxy's updater and move it to the 'latest' channel.

1. On the pool master (IP), set a password for the proxy's 'xoa' user
   (choose your own) and reboot the proxy VM:
   xe vm-param-set uuid=UUID xenstore-data:vm-data/system-account-xoa-password='<your password>'
xe vm-reboot uuid=UUID
2. SSH to the proxy as 'xoa' (IP) and run:
   sudo xoa-updater register - This registers it with your vates account.
   sudo xoa-updater configure-channel xo-proxy-appliance-latest - set to latest or stable
sudo xoa-updater upgrade - This can be ran via the UI or this command. Both need to be done twice to do the upgrade and/or downgrade.
   register needs a free xen-orchestra.com account; see the README.

And host connected via proxy.

@bogdantomasciuc

Got so possible good news... I got the proxy to update to the latest version and was able to do a backup job with it. Still need to test connecting a host via proxy.

@bogdantomasciuc

Correction to my side note: the license check can still block backups through a proxy. A proxy deployed by --proxy on a free xen-orchestra.com account updates to 0.31.10 and fails backups with no valid proxy license. The fix that stops gating backups on the license first ships in proxy 0.32.0+. The README now covers registering the proxy and this limit (dev branch).

I took this screenshot before the error whent away.

After update.

Backup Remote connected via proxy.

I did not test with host connected via proxy yet. Just not sure why the proxy will not update to 0.33.1.

Also added support for auth token when xo account is using MFA.

@bogdantomasciuc

Thanks for trying it! This one comes from upstream Xen Orchestra, not the installer. A change in XO's connection library (around 2026-09-09) left servers set to connect through an HTTPS proxy that supports HTTP/2, such as XO Proxy, stuck in Connecting. Vates fixed it in #10507 and released it in XO 6.9.1 (2026-10-05). That's also why the other project broke the same way.

Running --update should pull the fix, since the installer builds from master by default. If servers behind the proxy still won't connect after updating, please open an issue with what the Servers page shows and I'll dig in.

Side - note the disable license check is no longer needed as that appears not to be gated by the license check.

I have pushed these changes to the Dev branch. You should be able to switch to the dev branch and run the update ...

git fetch origin
git switch dev
./install-xen-orchestra.sh

@jacob.becker

VM were Ubuntu and Fedora distros. Ubuntu is 7.0.0-38-generic. The Fedora vms 7.2.7-200.fc44.x86_64 and 7.2.9-300.fc45.x86_64.

Had no issues with the beta test but those were done not via Rolling pool update.

after multiple failed attempts and rebooted all three host. Host 1 did update and finally got host 2 and host 3 updated both via rolling pool update.

During the evacuation multiple vms failed to migrate / reboot. All showing similar errors in each console for the vms.

@gduperrey

Just tried to install the patches pushed today to home lab. All but 1 vm evactuated from the primary host.

 },
                    "taskRef": "OpaqueRef:f56d3f5e-d41c-c8eb-3c70-4676f74de68c",
                    "message": "task has been destroyed before completion",
                    "name": "Error",
                    "stack": "Error: task has been destroyed before completion\n    at Xapi._removeRecordFromCache (file:///opt/xen-orchestra/packages/xen-api/index.mjs:1462:21)\n    at file:///opt/xen-orchestra/packages/xen-api/index.mjs:1429:18\n    at Set.forEach (<anonymous>)\n    at file:///opt/xen-orchestra/packages/xen-api/index.mjs:1428:20"
                  }

Rolling pool update.txt

VM that wouldnt migrate -

Latest commit fixed the synchronized snapshots showing up as a vm...
Commit 8c2f3

@Divo

You would want to adjust your script to disable the smb share or put it in maintenance mode prior to shutting down.

I ran into an issues for when I was shutting down a Remote just to save power - https://xcp-ng.org/forum/topic/12339/xo-unresponsive-when-remote-storage-is-offline.?_=1791151494204

It still didnt help with the unresponsivenes. This was with a Backup Remote not a SR but enabled maintenance mode before shutdown and disable when back online.

@john.c

I appreciate your thoughts on ipv6. Not trying to hijack @zorro post.

For us we do not use ipv6 internally. Our organization needs are small and simple. I do not expose XOA or either the proxies to the internet directly. They can access the internet but not the reverse without vpn access.

If there is internal communication with the proxies and XOA and that might be a different thing. But again I didnt have this problem untill i tried to move the the proxy to different network to correct a backup issue. Vates tech noticed the error reporting in XOA was possibly do to ipv6 and/or ipv4 issues.

I was just commenting incase there was change in the code that may be linked in any way. In my case i could every well not have any ipv6 issues and could just be down to an issue with the proxie do to other previous issues (NAS releate) that have been resolved.

@john.c

We currently dont use ipv6 internally. No network changes were made at this location other then moving the proxy to the correct network for nbd connections. With that move some how made the ipv6 issue appear. So it was just easy to disable ipv6 in the proxy. I guess if we ever switch to ipv6 (no plans too) then i guess i will have to look back into it.

@poddingue

I had issue with a remote xo proxy.. showed error in xoa untill i disabled ipv6. But only with one of two remote proxies. This was in a support ticket.

@gleh

Installed patches on home lab. No initial issues found. Existing Windows 11 vm no issues with it on basic vm functions. Created new Windows 11 vm with 26h2 iso no issues. Also installed guest tools in both vms.

Just taking screenshots for others... @mathieura is looking into the issue...

after update this how the proxies show. Along with the log posted in first post.

@poddingue

Looks like it clears after 30 days... but not the XO Config Cloud backup... This is from XOA..

Just filtered for backup... Oldest is from 7-19-26 oldest backup job 8-31-26.

@MathieuRA said:

@acebmxer If you can open a support ticket with a tunnel, it would be nice. I am not able to reproduce in my lab nether on our QA lab

PMed tunnel info.