Just to close the loop on this: XO 6.4 (released on April 29) includes a specific fix for VNC reconnection, which may have been causing keyboard focus loss and, in turn, modifier keys to get stuck (PR #9727). At least, that’s my understanding; I could be completely wrong, so please take it with a grain of salt. If you’re on XO 6 and still seeing the issue, upgrading to 6.4 may help.

Good news, or at least, that's my understanding. This was a known bug and it's fixed in XO 6.4 (released April 29, PR #9681). Upgrading should make those alerts disappear for good. Thanks for the video, it made the report unambiguous.

Very nice job @acebmxer Well done

I have completed the latest patches that came out and yet i still face this same issue.. anyone have a solution for this?? id "0moke6b1h-u49q39cfnql" properties method "vm.migrate" params vm "038b1fb8-e86c-9169-2ebc-c18b4e9c53f7" migrationNetwork "9a74000a-8481-1b36-2dd1-a58cd6747623" targetHost "82cf5c29-db31-4cc3-b057-db8f85324232" name "API call: vm.migrate" userId "02d261f6-840b-4148-9eb5-d181432af7d2" type "api.call" start 1777487518565 status "failure" updatedAt 1777487530207 warnings 0 data pif "c13bcf0c-ef0c-27bd-592a-58ef4eedf18d" message "PIF is not attached" end 1777487530207 result code "INTERNAL_ERROR" params 0 'xenopsd internal error: Xmlrpc.Parse_error("open_tag(html)", "open_tag(methodResponse)", _)' task uuid "bd7f8d2a-6d91-3d6a-0da2-e4c1c3758346" name_label "Async.VM.pool_migrate" name_description "" allowed_operations [] current_operations {} created "20260429T18:31:58Z" finished "20260429T18:32:09Z" status "failure" resident_on "OpaqueRef:6dadebb7-39c8-4bb7-a559-909a80824227" progress 1 type "<none/>" result "" error_info 0 "INTERNAL_ERROR" 1 'xenopsd internal error: Xmlrpc.Parse_error("open_tag(html)", "open_tag(methodResponse)", _)' other_config {} subtask_of "OpaqueRef:NULL" subtasks [] backtrace "(((process xenopsd-xc)(filename src/lib/xmlrpc.ml)(line 182))((process xenopsd-xc)(filename ocaml/xapi-idl/lib/xcp_client.ml)(line 138))((process xenopsd-xc)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xenopsd-xc)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 39))((process xenopsd-xc)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xenopsd-xc)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 39))((process xenopsd-xc)(filename ocaml/libs/stunnel/stunnel.ml)(line 412))((process xenopsd-xc)(filename src/lib/idl.ml)(line 550))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_server.ml)(line 2816))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_task.ml)(line 103))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_task.ml)(line 111))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_server.ml)(line 3408))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_server.ml)(line 3418))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_server.ml)(line 3439))((process xenopsd-xc)(filename ocaml/xapi-idl/lib/task_server.ml)(line 192))((process xapi)(filename ocaml/xapi/xapi_xenops.ml)(line 3479))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 39))((process xapi)(filename ocaml/xapi/xapi_xenops.ml)(line 3650))((process xapi)(filename ocaml/xapi/xapi_vm_migrate.ml)(line 262))((process xapi)(filename ocaml/xapi/xapi_vm_migrate.ml)(line 268))((process xapi)(filename ocaml/xapi/xapi_vm_migrate.ml)(line 293))((process xapi)(filename ocaml/xapi/xapi_vm_migrate.ml)(line 434))((process xapi)(filename ocaml/xapi/xapi_xenops.ml)(line 3488))((process xapi)(filename ocaml/xapi/xapi_vm_migrate.ml)(line 458))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 39))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 141))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 39))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 39))((process xapi)(filename ocaml/xapi/message_forwarding.ml)(line 2515))((process xapi)(filename ocaml/xapi/rbac.ml)(line 228))((process xapi)(filename ocaml/xapi/rbac.ml)(line 238))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 78)))" message 'INTERNAL_ERROR(xenopsd internal error: Xmlrpc.Parse_error("open_tag(html)", "open_tag(methodResponse)", _))' name "XapiError" stack 'XapiError: INTERNAL_ERROR(xenopsd internal error: Xmlrpc.Parse_error("open_tag(html)", "open_tag(methodResponse)", _))\n at XapiError.wrap (file:///opt/xo/xo-builds/xen-orchestra-202604291609/packages/xen-api/_XapiError.mjs:16:12)\n at default (file:///opt/xo/xo-builds/xen-orchestra-202604291609/packages/xen-api/_getTaskResult.mjs:13:29)\n at Xapi._addRecordToCache (file:///opt/xo/xo-builds/xen-orchestra-202604291609/packages/xen-api/index.mjs:1078:24)\n at file:///opt/xo/xo-builds/xen-orchestra-202604291609/packages/xen-api/index.mjs:1112:14\n at Array.forEach (<anonymous>)\n at Xapi._processEvents (file:///opt/xo/xo-builds/xen-orchestra-202604291609/packages/xen-api/index.mjs:1102:12)\n at Xapi._watchEvents (file:///opt/xo/xo-builds/xen-orchestra-202604291609/packages/xen-api/index.mjs:1275:14)' i had to manually migrate VM's using the xe command to do the patching and even now to move hosts back. So the loadbalancing or anything is not working

Hello all, XenClean 9.1.148 Prerelease is now available with a fix for error 1605 during execution. This is a XenClean-only prerelease. https://github.com/xcp-ng/win-pv-drivers/releases/tag/v9.1.148

@gleveque Hello Can you retry with an up-to-date XCP-ng 8.3 host? PCI expansion ROM are now enabled when doing pass-through. The guest VM can now access the ROM bar. Regards, Yann

@olivierlambert +1 For creating vApps GUI in XO Reason: I recently had this configuration: VM1 - Delay 90 Seconds VM2 - Delay 100 Seconds VM3 - Delay 0 Seconds The VM3 instead of starting first, always starts last without fail. One difference I noticed is that VM3 is UEFI vs VM1 & 2 being in BIOS mode. I read elsewhere in the forum that vApps is the only reliable way to have an order. Maybe if we can somehow ensure that delay works, vApps will become less significant ?

new mail received from Laurent Nguyen today Bonjour, Face à la hausse des tarifs VMware, nous vous invitons à remplir un questionnaire pour mieux comprendre vos attentes et améliorer nos services. https://www.surveymonkey.com/r/288HCLL Merci d’avance pour votre temps. Et si n’est pas encore fait, n’oubliez pas de vous inscrire au Veeam Technical Cloud Club qui aura lieu le Jeudi 16 Avril 2026 : https://go.veeam.com/webinar-technical-cloud-club-france Go give some love to XCP-NG + VEEAM collaboration in the survey !

@omatsei said: @omatsei I figured out the problem. There appears to be a bug in XO that requires you to check "Check Certificate" and/or "Start TLS", save the configuration, then uncheck them, then save again. Then it should work. The bug is that they're unchecked by default, but apparently they're enabled in the background. Thanks for that, I was stump on this one trying to reconfigure a new instance. This is defintely the case even with the latest auth-ldap (v0.10.11) plugin.

If you're looking for a quick way to verify those files without running a full restoration test every single time, you can usually run a checksum comparison (MD5 or SHA256) against the original data. For a more 'point and click' approach to double-check specific files or verify hashes quickly, I've used https://thetoolapp.com/utilities/file-integrity-checker/ before. It’s pretty handy for a quick integrity check if you aren't in the mood to mess around with the command line for every single backup set.

For my reference later. wget http://downloads.hpe.com/pub/softlib2/software1/pubsw-linux/p1257348637/v76502/hpacucli-9.20-9.0.x86_64.rpm yum install -y --nogpgcheck hpacucli-9.20-9.0.x86_64.rpm hpacucli controller slot=0 physicaldrive all show

Hi @Pilow, Thanks for the report. We are aware that there are many problems with the FLR. We would like to fix them but they are not easy to fix, and we can't give an estimation date for a fix. I've linked this topic to our investigation ticket. For the moment, when FLR fails, we recommend to manually restore your files by following this documentation: https://github.com/vatesfr/xen-orchestra/blob/master/%40vates/fuse-vhd/README.md#restore-a-file-from-a-vhd-using-fuse-vhd-cli

@geometry game 2 This usually happens when dependencies are out of sync after pulling updates. Did you try removing node_modules and the lock file and then running yarn install again before starting XO?

@simonp - Can you reshare the dashboards. The link says json is not available for any of these dashboards,