@olivierlambert Hi! i use XO free in this moment. CR jobs is only available with support o free test. I try warm migration connecting Xen7 and XCP83. This part work well, i see both pools/hosts connected. When try migrate VM from Xen7 to XCP, XO show this small error: INTERNAL_ERROR(Xmlrpc_client.Connection_reset) This is a XenServer/XCP-ng error but whe check is a more log error: vm.migrate { "vm": "dfaca34a-a27d-e6bc-d3b0-72cc9a8cd17b", "mapVifsNetworks": { "9863e51e-9edf-4072-65cb-5965779d2cbe": "944cf7f0-9eb5-e6bf-023e-f09eebd6310c" }, "migrationNetwork": "944cf7f0-9eb5-e6bf-023e-f09eebd6310c", "sr": "27259ba3-dff8-49b9-9898-77049ac1f296", "targetHost": "cb7b3482-51d1-4fc8-9bfa-a0105e48e0c2" } { "code": "INTERNAL_ERROR", "params": [ "Xmlrpc_client.Connection_reset" ], "task": { "uuid": "4e35f77a-11a5-1a46-d035-946fbbadba74", "name_label": "Async.VM.assert_can_migrate", "name_description": "", "allowed_operations": [], "current_operations": {}, "created": "20260728T19:15:25Z", "finished": "20260728T19:15:25Z", "status": "failure", "resident_on": "OpaqueRef:1b81fd5a-40ef-04f8-527c-72596400c091", "progress": 1, "type": "<none/>", "result": "", "error_info": [ "INTERNAL_ERROR", "Xmlrpc_client.Connection_reset" ], "other_config": {}, "subtask_of": "OpaqueRef:NULL", "subtasks": [], "backtrace": "(((process"xapi @ xenserver14")(filename http-svr/xmlrpc_client.ml)(line 306))((process"xapi @ xenserver14")(filename lib/pervasiveext.ml)(line 22))((process"xapi @ xenserver14")(filename lib/pervasiveext.ml)(line 26))((process"xapi @ xenserver14")(filename lib/pervasiveext.ml)(line 22))((process"xapi @ xenserver14")(filename rbac.ml)(line 236))((process"xapi @ xenserver14")(filename server_helpers.ml)(line 82)))" }, "message": "INTERNAL_ERROR(Xmlrpc_client.Connection_reset)", "name": "XapiError", "stack": "XapiError: INTERNAL_ERROR(Xmlrpc_client.Connection_reset) at Function.wrap (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/_XapiError.mjs:16:12) at default (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/_getTaskResult.mjs:13:29) at Xapi._addRecordToCache (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:1078:24) at file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:1112:14 at Array.forEach (<anonymous>) at Xapi._processEvents (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:1102:12) at Xapi._watchEvents (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:1275:14)" }

Hello @anthoineb, Thank you. I have attached the requested evidence as separate text files because the forum does not accept ZIP archives: two complete GDB/tap-ctl captures taken during the same incident, before reboot; the corresponding daemon.log excerpt from the hypervisor; the corresponding SMlog excerpt from the hypervisor; a README containing the timeline and identifiers; SHA-256 checksums. Both host-log excerpts cover 2026-07-25 04:35:00-05:10:00 MSK (UTC+03:00). The first GDB capture started at 04:45:44, the independent repeat capture started at 04:48:03, and the forced VM reboot was requested at 04:58:33. Both captures show the same state: the tapdisk main thread was in scheduler_wait_for_events(); n_reqs=32 and n_reqs_free=32; req_prod=req_cons=rsp_prod=rsp_prod_pvt=0; tap-ctl reported reqs_outstanding=0; the guest still reported 31 requests in flight and all 32 blkfront tags busy. The host logs contain no tapdisk error before the reboot. At 04:58:34-04:58:36 they show the expected sring disconnect, tapdisk close/detach and clean shutdown after the forced reboot request. The new QCOW2 tapdisk was opened at 04:59:57 and its sring connected at 05:00:27. Please let me know if you need another structure printed from GDB or a wider host-log interval. Our recovery controller can preserve the same pre-reboot diagnostic window during the next occurrence. SHA256SUMS.txt README.txt osott-193-SMlog-20260725-0435-0510.txt osott-193-daemon-20260725-0435-0510.txt 20260725-044732-gdb-172.30.52.193.txt 20260725-044544-gdb-172.30.52.193.txt

@acebmxer thanks for this - good detective work! Just a note - your code block seems to imply that Restart xo-server: sudo systemctl restart xo-server. needs to be added to the config.toml file --- am I correct that only the first 2 lines of your code block are correct? The "Restart xo-server" was part of your instructions, and then the "sudo systemctl restart xo-server.service" was meant to be the next code block?

New crash, this time xen02. The time is different because I updated the velero backup schedules to not all be in the middle of the night. Also still happened with the openvas schedule removed, which makes sense. Xen02 now has 9.2.18 loaded. Will restart other hosts now. I also uploaded logs if those are desired. [image: 1785260423760-8087b412-eff0-4f2e-9d98-8c87a94e7aad-image-resized.jpeg]

Good news that it sorted itself out. Both changes went in at once and the next run came back clean on the ADDS VMs too, so I don't think there's anything left to pin down here, and I'd rather say that than invent an explanation after the fact. Your question about the snapshot modes was the useful thing to come out of this thread. I went looking, they genuinely aren't documented anywhere, and that's written up on our side now If the fall back to a full ever comes back on the ADDS VMs specifically, that would deserve its own thread with the SMlog output @tjkreidl asked for, since nobody got to look at that part.