@olivierlambert Well that was easy. Much appreciated!

@isdpcman-0 Which version are you running (XOA > Updates)? You can check the logs by connecting to the VM via SSH and then running the command journalctl -u xo-server -f -n 50.

Please open a support ticket, obviously for a large infrastructure that would be logical to be sure it's not behaving like that or to make sure XO disable things in the correct order before trying to evacuate a host

@olivierlambert do you know who on XOA side can have a look?

working now after NIC driver update. Thanks

The issue is in the VM indeed, it's not on XCP-ng nor XO. The VM doesn't cooperate because there's a problem inside it. Sadly, there's little we can do except to check if you don't use dynamic memory. Outside that, the OS is likely the issue.

And of course there is the netdata plugin that can be enabled, https://xcp-ng.org/forum/topic/2288/netdata-package-is-now-available-in-xcp-ng Which will give you more performance metrics and health status.

@dvshmkr I think its a temporary glitch; I had the same issue but restarting toolstack solved it

This works fine, indeed. Thanks!

@dsmteam Yes I totally agree, a user who logs out from XO, might also have the choice to logout from all SSO'ed applications. That would be for the feature request list

@olivierlambert @paco Thanks! Will work on it

@olivierlambert gotcha.

@stevezemlicka Thanks . . . I do want to be able to use vnc to connect to the VM from my laptop and have the graphical desktop there. But through XOA/ XOlite I just want a user shell. I suppose that I should just not use the console at all in this case.

I rebuilt XO to build 7579b with no change. I performed an export and import of the VM and the imported VM functioned normally and displayed the disk in the UI appropriately.

Update: I was able to move the VM to a different host that is also xcp-ng 8.2. When I tried moving the VM back to where it came from now I'm getting: NO_HOSTS_AVAILABLE() vm.migrate { "mapVdisSrs": { "f4d88025-9e26-44a1-8028-4d5d9c11c994 ": "18850841-5eb8-6b28-73ba-cae1c40af157" }, "mapVifsNetworks": { "b56126a8-85ab-80de-9db8-4864ec5618e5 ": "99b40169-8dab-6e9d-db96-23277b405b4a " }, "migrationNetwork": "99b40169-8dab-6e9d-db96-23277b405b4a ", "sr": "18850841-5eb8-6b28-73ba-cae1c40af157", "targetHost": "69c0c257-a547-4d49-8270-b49eafe35c2c", "vm": "78938c32-eb52-491f-1fbf-3ad5d2e374f0" } { "code": "NO_HOSTS_AVAILABLE", "params": [], "task": { "uuid": "4eb56a28-ffa7-cee6-31e1-87209af8de75 ", "name_label": "Async.VM.migrate_send", "name_description": "", "allowed_operations": [], "current_operations": {}, "created": "20250131T20:51:54Z", "finished": "20250131T20:51:54Z", "status": "failure", "resident_on": "OpaqueRef:72cbec6b-d489-49ca-a8a8-e623e3c5f4e4", "progress": 1, "type": "<none/>", "result": "", "error_info": [ "NO_HOSTS_AVAILABLE" ], "other_config": {}, "subtask_of": "OpaqueRef:NULL", "subtasks": [], "backtrace": "(((process xapi)(filename ocaml/xapi/xapi_vm_placement.ml)(line 104))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 1199))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 35))((process xapi)(filename ocaml/xapi/helpers.ml)(line 1356))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 1191))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 2279))((process xapi)(filename lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/xapi/rbac.ml)(line 205))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 95)))" }, "message": "NO_HOSTS_AVAILABLE()", "name": "XapiError", "stack": "XapiError: NO_HOSTS_AVAILABLE() at Function.wrap (file:///opt/xo/xo-builds/xen-orchestra-202501311655/packages/xen-api/_XapiError.mjs:16:12) at default (file:///opt/xo/xo-builds/xen-orchestra-202501311655/packages/xen-api/_getTaskResult.mjs:13:29) at Xapi._addRecordToCache (file:///opt/xo/xo-builds/xen-orchestra-202501311655/packages/xen-api/index.mjs:1068:24) at file:///opt/xo/xo-builds/xen-orchestra-202501311655/packages/xen-api/index.mjs:1102:14 at Array.forEach (<anonymous>) at Xapi._processEvents (file:///opt/xo/xo-builds/xen-orchestra-202501311655/packages/xen-api/index.mjs:1092:12) at Xapi._watchEvents (file:///opt/xo/xo-builds/xen-orchestra-202501311655/packages/xen-api/index.mjs:1265:14)" } I rebooted XO and tried moving the VM to the xcp-ng 8.3 machine again. It looks like the task started but now it's hung at "Connection to VM console (on xcp-m83) 0%" and I can't "Cancel" or "Destroy" the task

@DustinB Hmm, hadn't thought of that one. I'll try it and see.

@olivierlambert said in VM Failing to Reboot: Quick check: is hardening is done via any MS virtualization technology? If yes, it could be a nested virt problem maybe (just throwing ideas) Certainly could be. @dinhngtu said in VM Failing to Reboot: @kagbasi-ngc Could you apply the hardening controls now and see if the VM still works? Yeah, I'll try doing that today to see what happens. We generally get an already hardened ISO from our upstream Security Team, so as to minimize the deployment time. However, I can manually harden myself - although, since it may not be the exact same process as followed by the upstream team, there's a chance I will not be testing apples-to-apples.

@Danp Thank you! That's simple enough. I thought XO couldn't live migrate itself without running into an issue. Thanks again! SW

@Davidj-0 Thank you, this solved my issue.

@Danp That is it! @olivierlambert said in Automatically balance VMs between Hosts within a single pool: https://docs.xen-orchestra.com/load_balancing Thanks!