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.

Just notice XOA 6.9 was released. After updating to 6.9 both remote proxies fail to connect

Error - incorrect state

2026-09-30T18_30_12.814Z - XO.txt

I have switched from Latest to Stable and downgrade to 6.8.2 and proxies reconnected.

In the past i have updated XOA first then Proxies... Is that correct or should proxies be updated first?

If this is a real issue let me know and i will open support ticket and tunnel.

@lem2405

No problem. Let me know if you still encounter any issues.

@lem2405

Sorry for any confusion. Hope this clears it up.

The credentials in xo-config.cfg are only for logging into Xen Orchestra (the pre-update task check and VM snapshot). There is no setting for a sudo password, and the script won't run as root, so sudo will still ask.

To run it from cron, the account running the script needs passwordless sudo. Run this as that user:

echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/xo-cron
sudo chmod 440 /etc/sudoers.d/xo-cron
sudo visudo -c

Then add --non-interactive so it doesn't stop to ask anything:

0 3 * * * cd /path/to/install_xen_orchestra && ./install-xen-orchestra.sh --update --non-interactive

Keep in mind this gives that account full sudo with no password. Use at your own risk.

I've pushed this to the dev branch, including a new Scheduled Updates (cron) section in the README. To try it before it reaches main, switch your copy to dev:

cd /path/to/install_xen_orchestra
git fetch origin
git checkout dev

To go back later, run git checkout main.

Scheduled Updates (cron)

--update can run unattended from cron. Two things are needed:

1. Passwordless sudo for the account that runs the script. The script
   refuses to run as root and calls sudo throughout, and there is no config
   setting for a sudo password. Run this as that account:

   echo "$USER ALL=(ALL) NOPASSWD:ALL" | sudo tee /etc/sudoers.d/xo-cron
   sudo chmod 440 /etc/sudoers.d/xo-cron
   sudo visudo -c
   

   This gives the account full sudo with no password.

2. --non-interactive, so the update never stops to ask anything:

   0 3 * * * cd /path/to/install_xen_orchestra && ./install-xen-orchestra.sh --update --non-interactive >> "$HOME/xo-update.log" 2>&1
   

Set XO_API_TOKEN (or the user/password pair) in xo-config.cfg.
Without it, a non-interactive run skips the
running task check instead of
prompting for credentials.

@poddingue

Yes it just make it look odd as it shows itself as a vm being backed up only by the count of vms. Maybe if didnt add to the number it would be fine. Or if there was a description about it in the log or something so when someone is looking in to i like i was dont go looking of for a ghost vm being backed up.

So i notice when this is enabled it adds to the total number of vms backed up.

Example if my backup job is set to backup 7 vms. the job log will show total 8 vms but only list the actual 7 vms.

Is it supposed to show as an additional vm being backed up?

2026-09-29T17_00_00.008Z - backup NG.txt

@JorisK

This does seem to work for Delta backup and health check enabled. Did not run a full backup.

@danp

testing now... i did not have it enabled on my deltas but did have it enabled on full.. Running delta now with enabled. will report back.

Edit - still running but i think thats the issue health check is part of the calculation..

I am seeing similar but only 1 vm backup is different.

XO - commit a1dba
719.71 GB vs 415.96 GiB (Full backup)

Just recieved another update from veeam...

Regarding the general earlier errors:
Warning : Failed to use CBT: [Task e75c4247-2ee1-7b51-088c-b970ace60f3d (Async.VDI.list_changed_blocks) failed: . SR_BACKEND_FAILURE_460. . Failed to calculate changed blocks for given VDIs. [opterr=Source and target VDI are unrelated]

Our QA team did hear back from Vates support, who says its tied to a recent bug they've found with blktap calls: https://github.com/xapi-project/blktap/pull/444

Our QA engineer hasn't heard back yet on ETA when it will be pushed out in a general release yet though