@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!

@olivierlambert can memory size difference being showed as different cpu? tried both commands [image: 1737500112335-screenshot-2025-01-22-005049-resized.png] [image: 1737500122455-screenshot-2025-01-22-005412-resized.png]

Updated all my hosts but ended up with a bunch of stuck tasks for API host calls, didn't seem too healthy! It looks like they were stuck, kept seeing a host unhealthy power state repeatedly pop up and disappear. I opted to select all tasks and delete, same with my logs (I monitor externally anyway) which appears to have resolved this for the moment. I no longer see these mdadm logs being generated and everything appears normal.

@olivierlambert Yes we can, however, it's unsettling not knowing the root cause. But seems that restarting the Xen Toolstack may have resolved this issue. I haven't attempted creating a VM yet, so I'll do that when I get in tomorrow.

@olivierlambert Technically, yes, I suppose I could do that. However, that would not mimic what a SysAdmin would have to do, should they run into this trouble in production. Is there no other alternative to get this utility, perhaps as a .deb package that I can manually install on XOA? Lastly, I performed the following testing just now: Created a new VDI on a known working VM and put the VDI on the problematic SR (let's call it NFS-DS1). I then attempted to migrate the newly created VDI to the known good SR (NFS-DS2); it failed with error VM_LACKS_FEATURE. So I crested another VDI, attached to the same VM, but this time I put it on SR NFS-DS2 (the good one) and then attempted to migrate it to SR NFS-DS21; IT WORKED. So I retried migrating it back to NFS-DS2, and it worked as well. Finally, I went back to the original new VDI I started with, and attempted to migrate it from SR NFS-DS21 to NFS-DS2; it worked! SO, it seems the issue remains with the VDIs that seem to have lost their parent. P.S. I haven't noticed the VDIs disappearing from SR NFS-DS1 for over an hour now.

@olivierlambert as i say, now it works. So nvm)

@olivierlambert Thanks for that ill plan for the weekend to do that and see how it goes.