@florent
monolithic flat sounds like a disk which cannot be created directly by vSphere (ESXi effectively). This is the type of a disk which comes from VMware Workstation or am I wrong? That's why you've mention about v2v tool or converting to vhd?

There is one more thing we've noticed.

While CPU are 100% flat, when we trigger migration to different XCP-ng host the task stops at 90% and goes "failure".

Here's the code.

{
  "id": "0m9005wjh",
  "properties": {
    "method": "vm.migrate",
    "params": {
      "vm": "c30f10de-4dfa-e7dd-84dd-3104ed7e1c23",
      "migrationNetwork": "6dc5b9a9-36dc-ab29-4ad6-80ecbd53b906",
      "targetHost": "24eacfb2-da63-4e27-aa02-6e5cb774026b"
    },
    "name": "API call: vm.migrate",
    "userId": "612f2ca4-dddf-4d18-96c4-1ce8c57a6383",
    "type": "api.call"
  },
  "start": 1743602926589,
  "status": "failure",
  "updatedAt": 1743602977282,
  "end": 1743602977282,
  "result": {
    "code": "INTERNAL_ERROR",
    "params": [
      "Xenops_interface.Xenopsd_error(S(Failed_to_acknowledge_suspend_request))"
    ],
    "task": {
      "uuid": "2f0c5622-52a1-f621-bbec-b2cdf1ab07c9",
      "name_label": "Async.VM.migrate_send",
      "name_description": "",
      "allowed_operations": [],
      "current_operations": {},
      "created": "20250402T14:08:46Z",
      "finished": "20250402T14:09:37Z",
      "status": "failure",
      "resident_on": "OpaqueRef:d11c5a86-fa0b-7788-3f80-0cb300322d88",
      "progress": 1,
      "type": "<none/>",
      "result": "",
      "error_info": [
        "INTERNAL_ERROR",
        "Xenops_interface.Xenopsd_error(S(Failed_to_acknowledge_suspend_request))"
      ],
      "other_config": {},
      "subtask_of": "OpaqueRef:NULL",
      "subtasks": [],
      "backtrace": "(((process xenopsd-xc)(filename ocaml/xenopsd/xc/xenops_server_xen.ml)(line 2561))((process xenopsd-xc)(filename ocaml/xenopsd/xc/domain.ml)(line 1706))((process xenopsd-xc)(filename ocaml/xenopsd/xc/emu_manager.ml)(line 239))((process xenopsd-xc)(filename ocaml/xenopsd/xc/emu_manager.ml)(line 244))((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/xenopsd/xc/domain.ml)(line 1840))((process xenopsd-xc)(filename result.ml)(line 23))((process xenopsd-xc)(filename ocaml/xenopsd/xc/domain.ml)(line 1833))((process xenopsd-xc)(filename ocaml/xenopsd/xc/xenops_server_xen.ml)(line 2554))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_server.ml)(line 1830))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_server.ml)(line 1838))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_server.ml)(line 2380))((process xenopsd-xc)(filename list.ml)(line 121))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_server.ml)(line 2373))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_server.ml)(line 2746))((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 403))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_server.ml)(line 2759))((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 403))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_server.ml)(line 2657))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_server.ml)(line 1830))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_server.ml)(line 1838))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_server.ml)(line 3185))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_server.ml)(line 3195))((process xenopsd-xc)(filename ocaml/xenopsd/lib/xenops_server.ml)(line 3215))((process xenopsd-xc)(filename ocaml/xapi-idl/lib/task_server.ml)(line 194))((process xapi)(filename ocaml/xapi/xapi_xenops.ml)(line 3387))((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 3555))((process xapi)(filename ocaml/xapi/xapi_vm_migrate.ml)(line 264))((process xapi)(filename ocaml/xapi/xapi_vm_migrate.ml)(line 270))((process xapi)(filename ocaml/xapi/xapi_vm_migrate.ml)(line 295))((process xapi)(filename ocaml/xapi/xapi_vm_migrate.ml)(line 1551))((process xapi)(filename ocaml/libs/xapi-stdext/lib/xapi-stdext-pervasives/pervasiveext.ml)(line 24))((process xapi)(filename ocaml/xapi/xapi_vm_migrate.ml)(line 1714))((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 143))((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 2591))((process xapi)(filename ocaml/xapi/rbac.ml)(line 191))((process xapi)(filename ocaml/xapi/rbac.ml)(line 200))((process xapi)(filename ocaml/xapi/server_helpers.ml)(line 75)))"
    },
    "message": "INTERNAL_ERROR(Xenops_interface.Xenopsd_error(S(Failed_to_acknowledge_suspend_request)))",
    "name": "XapiError",
    "stack": "XapiError: INTERNAL_ERROR(Xenops_interface.Xenopsd_error(S(Failed_to_acknowledge_suspend_request)))\n    at Function.wrap (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/_XapiError.mjs:16:12)\n    at default (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/_getTaskResult.mjs:13:29)\n    at Xapi._addRecordToCache (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:1072:24)\n    at file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:1106:14\n    at Array.forEach (<anonymous>)\n    at Xapi._processEvents (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:1096:12)\n    at Xapi._watchEvents (file:///usr/local/lib/node_modules/xo-server/node_modules/xen-api/index.mjs:1269:14)"
  }
}

Maybe Devs will get something out of it : - /

@XCP-ng-JustGreat
Check mentioned by @planedrop disabling network adapter from devmgmt.msc before removing it from XOA. It works in our case as a workaround but of course the problem is still there.

Apologize again for touching an old topic but we are just testing all things we need from XCP-ng while migrating OFF VMware and it looks like this error still occurs even with Citrix XenTools installed.

Version we have inside VMs is 9.4.0-146.

Here is the result of removing network adapter.

Not every time I delete network adapter the issue occur.

We've tried on different VMs with Windows 2019 and the problem exists.

Yes, yes, of course.

So when I try to import .vmdk disk nothing actually happens.

I've left the whole thing for few hours but nothing changed.

Tried at the beginning with big disk but also after that tried with small one.

There is a "loading gear" and it's only spinning around (marked on below screenshot).

No error, I've tried multiple times.

Not sure if that helps but in general .vmdk disks comes with a bit different shapes.

There can be a -flat one (zeroed or lazy), the one which is thin. As additional there may be a difference between disk exported to template directly from VMware vCenter and the .vmdk disk created via VMware Workstation. Disk can be created with different SCSI controller like LSI or VMware Paravirual. -flat.vmdk can be opened with 7zip but there is no way to do the same trick with thin .vmdk. - Does any from above matters from XOA point of view?

Q: Is there any specific requirement for that .vmdk disk to be imported to XOA?

I've also tried to export a VM from VMware vCenter into OVF, convert it to OVA and import it to XOA - and that worked fine. Connected .vmdk disk from that imported VM to a VM created in XOA and at the beginning the disk was NOT spotted. It was NOT visible in the system but after few tries I was able to initiate it and works perfectly fine now.

So the problem is with importing just a .vmdk file.

Hi, I just tried to do a similar thing and it seems that the issue is still there.

@piotrlotr1
I'm changing my mind regarding point 2.

From XOA webGUI there is a way to distinguish between "master bond" and "pool-wide networks" created based on "master bond".

On pool level, when checking "Network" tab the master bond is marked with "Bonded" icon next to it.

It is NOT so obvious from "host" level as there is no "Bonded" icon next to the "master bond".

Sorry for poking the bear.

Just want to point out (in a positive way as much as possible), that I cannot find an issue related to this one on a Github and as we are trying to migrate our env onto XCP-ng I cannot find inside XOA webGUI the way to check which network interfaces (effectively PIFs eth0 or eth1 in our case) are inside a bond we've created.

There is a way to check that from "xe" command line (the commands are within this thread, few posts above, thank you @VoipDude).

Having this information provided in XOA webGUI would be something nice and useful (for example to confirm that eveyrthing is configured as it should be). Digging this up with "xe" commands took me some time and finding those right commands on the internet with explanation isn't the easiest thing.

As additional what I've spotted it is also hard to distinguish between "master bond" and "pool-wide networks" which are created based on "master bond". (I don't think it's possible from XOA webGUI to get that information).

To me it looks like the only way to distinguish it for now is this:

xe pif-list params=all

Above will give us list of all PIFs with all params. We need to look for an entry where "bond-master-of" is NOT empty AND at the same time if "device" is the one we are looking for AND that the "network-name-label" is the one we are looking for : - )

bond-master-of ( RO): **a0753427-b3f1-52bc-1c0e-2b6481e8701e**

Next step is:

 xe bond-param-list uuid=**a0753427-b3f1-52bc-1c0e-2b6481e8701e**

Above will give us UUIDs of interfaces (inside the "master bond") but again we will have to use "xe pif-list" to find what "network-name-labels" hides under UUIDs to get info if those are PIFs eth0 and eth1.

Hi,

Looks like we've got a similar problem on our newly deployed XOA (5.103.1).

There are approx. 500 tasks and some of them are "refreshing/changing places in the list".

Also, next to the "Tasks" button on the left inventory menu we can see "1" from time to time (screenshot: 03.PNG).

Haven't yet tried to clear it but would first understand why this is happening and maybe it can be perma fixed?

01

02

03