@MajorP93 OK I tried disconnecting the pool first but now I'm getting: server.disable {} { "code": 10, "data": { "errors": [ { "instancePath": "", "schemaPath": "#/required", "keyword": "required", "params": { "missingProperty": "id" }, "message": "must have required property 'id'" } ] }, "message": "invalid parameters", "name": "XoError", "stack": "XoError: invalid parameters at Module.invalidParameters (/opt/xo/xo-builds/xen-orchestra-202602261435/packages/xo-common/api-errors.js:26:11) at Xo.call (file:///opt/xo/xo-builds/xen-orchestra-202602261435/packages/xo-server/src/xo-mixins/api.mjs:121:22) at Api.#callApiMethod (file:///opt/xo/xo-builds/xen-orchestra-202602261435/packages/xo-server/src/xo-mixins/api.mjs:409:19)" } I guess I will just power down the host and that will be it, as Olivier recommends.

@pdonias nice !

@nikade said in Every virtual machine I restart doesn't boot.: @DustinB yeah im guessing the VDI isn't attached to the VM for some reason, based on the screenshot. Im also wondering if he ever rebooted the VM's after installing them with PXE Right, it's a likely answer... but even then I would've expected his PXE server to just restart the installation process all over again... assuming that the disk is attached to the VM etc and that PXE boot isn't disabled automatically like it is with an ISO after first boot. haha

@Andrew This was the exact problem I was facing. The affected VMs still had the guest-tools.iso mounted in the virtual drive. Once I ejected the ISO, I was able to clear the errors and the backup jobs resumed normal operation. For anyone else hitting this "stuck delta" or VDI_IN_USE state, here is the exact workflow I followed to resolve it: Shut down the VM (Essential to release all storage locks). Eject the ISO/CD from the VM console or CLI. Delete all snapshots associated with the VM (including any old or "ghost" backup snapshots). Delete the VM's backup folder from the remote SR/Backup target to ensure a clean metadata start. Monitor the Coalesce process (via SMlog) and wait for it to finish flattening the VHD chain. Power the VM back on. Manually trigger a Backup Job. Following these steps, the first run was (as expected) a Full backup, but every subsequent run has been a successful Delta with no "hanging" snapshots left behind.

@florent Thanks, if there is something I need to do to coalesce the vdis to avoid disaster, that would be good to understand. I had been thinking it was just an XO issue that would not affect running vms and their vdis.

@afmart_dei could you share the /var/log/xensource.log of the joining host ? ideally the whole part after the host started (you could look at the file before rebooting and strip all lines before the last line you saw)

Instruction published: https://docs.xen-orchestra.com/sdn_controller#openssl-3--sdn-upgrade-path Any volunteer to test this along upcoming XCP-ng update ?

@florent since your early patch of my XOA (xo-server restart at the disk activity peak) [image: 1772047222068-3e55ee10-ef90-471e-aec6-967a569c8fa1-f3d3bd6c-ef54-4f5c-9202-5aab25319db9.png] noticing vif0 transmitting a bit on the network and different ram activity on a timespan of 2 hours something has changed, is it for the better ? let the night decide