@olivierlambert, yes, thank you. I will open that ticket.

Is there a plan at least for the future to implement those groups from AD FS claims? Having such feature is something desirable and looks like the hardest bit is already done.

@florent In that case, every time we login for the first time via OIDC to XOA, admin will have to manually add newly created user to specific group?

There is no way to map AD FS group hidden in claim to XOA local group via some config file to automate this?

@olivierlambert, you guys have that documentend for XCP-ng somewhere?

Hi,

auth-oidc plugin seems to be working fine, and we are able to login with OIDC via AD FS to our XOA.

We've also configured claim rule for target group with target user in AD FS.

Is there a documentation of how to auto assign that target user into correct XOA group (which will have target permissions applied)?

There is some info on the internet of how to do it but it's for XO not XOA I'm afraid.

@DustinB They were named as in column "Pool" at the very beginning - before adding them to pool.

Again, the question is why after detaching, the "Label" column shows three exactly the same names? I can rename them, but that's not the point.

I'm asking if the same "Labels" can be somehow explained...

It looks like after detaching slave host from the pool it inherits master name as a label - that doesn't look correct.

@DustinB No, no... look at the "Label" column.

The question is - why after detaching hosts from pool, they all have "Label" the same as pool master?

@olivierlambert
That worked, thank you.

Next thing is that every time I hit "Detach" on any host, it jumps into "Settings -> Servers" with the same name as the host which currently is an master.

So right now I have on my "Servers" list below situation.

All three hosts have the same "Label".

When I add them back to the pool everything goes back to normal.

I'm able to rename those without any issue but is it some kind of a bug or expected feature?

@olivierlambert
Well, that worked.

But... after bringing back the old master (without reinstallation or anything) XOA sees it as master HOWEVER xe pool-list sees as a master different host.

Hello!

So it looks like after bringing master down, HA election of new one takes place however XOA is not aware of it.

Is there a way to point XOA to new master?

To check which host is the new master I've logged via SSH to one of the slaves and did below.

[05:40 phx01xcp03 ~]# xe pool-list
uuid ( RO)                : 03e8733b-fbd0-61c9-3850-353bfd9e3149
          name-label ( RW): Pool_01
    name-description ( RW):
              master ( RO): a65dcfcb-8a60-4aa8-a467-2351140f80d4
          default-SR ( RW): <not in database>

Which shows UUID of newly elected master.

[05:52 phx01xcp03 ~]# xe host-list uuid=a65dcfcb-8a60-4aa8-a467-2351140f80d4
uuid ( RO)                : a65dcfcb-8a60-4aa8-a467-2351140f80d4
          name-label ( RW): hidden_label
    name-description ( RW): Default install

Not sure why default-SR has "<not in database>" status.

@planedrop
It just says "Drop (...) VMDK (...) files here to import disks." so I thought I could simply drop it there and job done : - )

But in general for example importing VM in OVA format works fine.

@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