Note that we have 0 XO or XCP-ng dev based in the US neither

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

perhaps "in the context of a proceeding RPU, do not start halted VMs" ? or "boot only halted VMs that have HA enabled" ? but I can imagine corner cases where this is not wanted. some chicken & egg problem.

That is a frustrating loop to be in, especially with TrueNAS. Usually, when the VM fails to start after a change, it’s because XCP-ng is trying to pass through a PCI device (like an HBA) that isn't being released properly by the host. Have you checked if the "hide" parameters in your grub config are still correct? Sometimes an update can reset those, and the host grabs the controller before the VM can. Another thing to try is toggling the BIOS/UEFI mode in the VM settings - TrueNAS can be picky about that depending on which version you’re running.

Nevermind. I forgot your previous post about: You'll need to modify two files (via SSH): /opt/dell/omc/utilities/tui/bin/ome_disk_config.sh /opt/dell/mcsi/appliance/scripts/appliance_ressource.sh In these files, replace /dev/sd with /dev/xvd. I went and made these changes, and now the Data drive is loading after doing the drive scan. I should mention that doing this BEFORE first logging into the OME web interface and completing the initialization seems to be best (no further errors appear once logged in).

I can confirm that when using Citrix/Xenserver guest utilities version 8.4 (https://github.com/xenserver/xe-guest-utilities/releases/tag/v8.4.0) memory ballooning / DMC is working fine. After live migration the RAM of the linux guest is expanded to dynamic_max again. So this issue was in fact caused by Rust based xen-guest-agent. For now I'll keep using Citrix/Xenserver guest utilities on my Linux guests until the feature is implemented in Vates rust-based guest utilities. Best regards

@TeddyAstie Attached is the output you requested xen-cpuid -p.txt

@TeddyAstie That's more like it. I'm not finding the com2tcp though. I at least have something to search for. Once configured, is this persistent or do I need to create some sort of start up script that runs/loads a config on machine boot? Thanks!!

@abudef Some quotes from the documentation to clarify the situation: https://docs.xcp-ng.org/compute/#-nested-virtualization

Having help from OpenBSD side could be the way to go. Please forward your report to bugs@openbsd.org (with a link to this post too) For the record, I am able to reproduce it too (on XCP-ng 8.3 too, using OpenBSD -current).

@redakula said in Coral TPU PCI Passthrough: Frigate.nvr which is one of the popular uses for the Coral do not recommend it for new installs either. Frigate updated their recommendations because of the Google decision to sunset the device and because there are alternative options available to frigate for image inferencing. The coral is still supported though, and frigate is not the only use case or platform that can benefit from an accelerator. At the end of the day if you've already got the hardware, and it's efficient enough to run, then not using it is a waste or resources that could be allocated to other VMs.

Thank you all for information. I will try to virtualize GPU to Windows VMs.

@markxc could you tell us what endpoint you used ?

To elaborate: it was already in progress, but delayed due to 1. the fact that I underestimated the impact (I thought we'd overwrite the file only when we'd modify it, not every update the package) and 2. lots of other priorities keeping the team busy. But it's clearly the reminder, and the help in better diagnosing it, that allowed to have it re-prioritized and (partly, we've mostly bought time to fix it properly, by simply avoiding to touch the file at all at the moment) fixed so fast.

I made a list of processes with a small bash script that I am attaching here [image: 1769612600385-screenshot-2026-01-28-alle-16.01.53.png]

Thank you! So in this case, if better option for me to join the hosts to existing pool and then shutdown VMs and start it on host with older CPUs. Thank you again!

For documentation purposes, there's a more general step of "Any VM you can shut down, do". Live Migration is great for VMs which need to stay up, but it's not free, and not even cheep. You will get done quicker if you can shut down VMs you don't need, migrate fewer things, and then (re)boot everything at the end.

I just learned something new, thats awesome

@dinhngtu I believe it was changing the guest TSC Mode that seems to have done the trick.

Yay! Santa came early this year!!