@acebmxer Hello, no. Let me describe my setup. Esxi + vcenter + veeam. Vcenter wakes up veaam at 9am. Veeam sends wol packet to the synology nas at 9.15. At 9.30 the backup starts and ends more or less at 10.00 Due to inactivity synology stops the hard disks, then after some time it shut itself off. Veeam just see the repo as unavailable. At 12.00 veeam auto shuts down. Migrating to xcpng + xo, veeam is retired. At first i added the remote to XO, believing it's like veeam. If the backend goes down it simply shows unavailable. Then i discovered is not at all like that when i found an inaccessible XO. After some chatgpt-ing i found out this "bug". I thought that the script would be sufficient, but it's not. Waiting for ping to fail and then disable the remote (cron every 5mins) still ends up in ps -T -p 738 -o pid,tid,stat,wchan:32,comm PID TID STAT WCHAN COMMAND 738 738 Ssl do_epoll_wait MainThread 738 753 Ssl do_epoll_wait DelayedTaskSche 738 754 Ssl futex_wait_queue V8Worker 738 755 Ssl futex_wait_queue V8Worker 738 756 Ssl futex_wait_queue V8Worker 738 757 Ssl futex_wait_queue V8Worker 738 758 Ssl futex_wait_queue SignalInspector 738 863 Dsl rpc_wait_bit_killable libuv-worker 738 864 Dsl rpc_wait_bit_killable libuv-worker 738 865 Dsl rpc_wait_bit_killable libuv-worker 738 866 Dsl rpc_wait_bit_killable libuv-worker And it's even worse because not only XO becomes unavailable, but even if i disable manually (or via script) the remote as soon as the backup ends, with the synology still ON, the linux os does not unmount the nfs. Today the remote was disabled before the nas shutdown and correctly XO kept working. But if at this point i want to restart the XO vm i must do this before shutdown umount -l /run/xo-server/mounts/9fc232df-4d0c-4a15-93b5-c0585c1dd9c9 otherwise it stays like this for at least 15 minutes, then finally reboots [image: image.jpeg] The ideal behaviour would be that XO does all by itself, but since we can't have it all, the closest thing i have in mind is Script that sends WOL to the nas, when it pings than enables the remote Script that monitors the backup acrivity. when the last job is done, it must disable the remote and also umount the linux os nfs mount. Then the nas could shut down automatically without issue. Since i'm not a dev i need to take my time with chatgpt and see i what i can do. Having said that, my concern is not about my homelab, it's about production. In my environment i can and want to simulate all kinds of malfuncions. In the previous message i said i still need to try to shut down the main nfs SR for vms and see how the host behaves. But if i decide to deploy XEN at my company, i cant have 1 remote unavailability cause the whole XO (or XOA in that case) fall apart. Hope it helps!!

error via reverse proxy. Uncaught Error: Body is not a JSON, original message is : <html> <title>500 Internal Server Error</title> <style>html{color-scheme:light dark;}</style> </head> <body> <center><h1>500 Internal Server Error</h1></center> <hr><center>Angie</center> </body> </html> pr index.js:2564 me index.js:4029 i index.js:4029 promise callback*me index.js:4029 i index.js:4029 promise callback*me index.js:4029 i index.js:4029 promise callback*me index.js:4029 i index.js:4029 be index.js:4029 be index.js:4029 dr index.js:2531 importDisks index.js:2575 Lodash 2 importDisks index.js:2574 e index.js:113 P index.js:22 i index.js:22 R index.js:22 R index.js:22 import index.js:121 t factory.js:307 o factory.js:331 e action-button.js:93 m action-button.js:10 i action-button.js:10 _execute action-button.js:10 _execute action-button.js:10 _execute action-button.js:10 v action-button.js:140 componentDidMount action-button.js:147 React 14 componentWillUnmount factory.js:125 f factory.js:31 _dispatch factory.js:158 t factory.js:322 promise callback*t factory.js:313 o factory.js:331 value index.js:206 promise callback*value index.js:174 React 5

This is a question for @dinhngtu

@IgorGlock What do you mean by "okay"? Backing up the VM with Commvault or...?

Thanks for the versions. If I read the changelogs right, sm-3.2.12-25.2 is one build after the 25.1 that @dthenot mentioned and still carries its QCOW2 patches, and the release note for blktap-3.55.5-12.3 says it fixed a tapdisk crash during backups (https://xcp-ng.org/forum/post/109336). So unless I missed one, you already have every fix I know about. I think this might be a different bug. I can't tell from here why tap-ctl close times out on those snapshot disks, so that one is for @Team-Storage. I'd guess the SMlog from both hosts around one failed run is the first thing they'll ask for.

Your reading of the code matches what I see on master, as far as I can tell. The object.enabled === true check in _getHosts() seems to have come in with PR #10209, released in XO 6.7.1 in August, to stop the balancer migrating VMs onto disabled hosts. If I follow the code right, a host that XO shuts down goes through disableHost first, so the power-on step in performance-plan.js no longer sees it. That looks like a side effect of the fix to me. The docs still say the performance plan powers halted hosts back on (https://docs.xen-orchestra.com/manage-your-infrastructure/load_balancing#plan-modes), so I think one of the two is wrong. I haven't reproduced it and there may be a reason to filter halted hosts that I can't see from the code, so @Team-XO-Backend is better placed to say if your powerState === 'Halted' exception is the right fix.