@Team-XO-Backend Someone can take a look at it? I won't be to much available this week

@ph7 @acebmxer
Hi, regarding your backups which do not appear on the XO5 restore page, I suggest you to open a new topic so that this one remains focused on XO6 dashboards

@ph7 can you try without the ndjson=true? Therefore, in case of an error on the server side, we will see it directly.

@acebmxer yes vm dashboard is another issue. I will check tomorow

@acebmxer you are reading the CSS file, not the dashboard http request. Can you test the branch i posted to check if it fix the pool dashboard also for you?

@ph7 well. Vm dashboard is probably another issue. Please test the /rest/v0/vms/:id/dashboard and put the result here

@ph7 Can you test the mra-fix-dashboard-reactivity branch?

@ph7
Well, thanks, we are going to investigate the issue

@ph7
I'm able to reproduce the issue on my end.

Can you confirm this behavior? (To make sure I'm experiencing the same bug.) If you load your XO6, go to the pool dashboard (infinite loaders), then to the "System" tab, and finally return to the pool dashboard, no more loaders

@ph7

{"hosts":{"status":{"running":1,"disabled":0,"halted":0,"total":1}}}
{"vms":{"status":{"running":4,"halted":5,"paused":0,"total":9,"suspended":0}}}
{"alarms":[]}
{"srs":{"topFiveUsage":[{"name_label":"Q1-ContRep","id":"4f2f7ae2-024a-9ac7-add4-ffe7d569cae7","percent":67.65998746071482,"physical_usage":5991060996096,"size":8854658744320},{"name_label":"Local SR","id":"bb817ba4-3908-b458-423b-1273e8072a96","percent":17.690132076358456,"physical_usage":166183759872,"size":939415031808},{"name_label":"T1-NFS-Ryssen","id":"ebc70898-d9c2-33dc-b22b-a465e39075a2","percent":5.314938671242864,"physical_usage":210834030592,"size":3966819631104}]}}
{"hosts":{"topFiveUsage":{"ram":[{"name_label":"X2","id":"bea8efab-9975-4c84-8815-b83d186fc9db","size":33285996544,"usage":11131478016,"percent":33.441925048828125}]}}}
{"cpuProvisioning":{"total":8,"assigned":13,"percent":162.5}}
{"hosts":{"missingPatches":{"hasAuthorization":true,"missingPatches":[]}}}
{"hosts":{"topFiveUsage":{"cpu":[{"percent":5.715011432766916,"id":"bea8efab-9975-4c84-8815-b83d186fc9db","name_label":"X2"}]}}}
{"vms":{"topFiveUsage":{"ram":[{"id":"86ab334a-92dc-324c-0c42-43aad3ae3bc2","name_label":"Home Assistant","memory":1612685312,"memoryFree":762228736,"percent":52.73543261489071},{"id":"0f5c4931-a468-e75d-fa54-e1f9da0227a1","name_label":"Sync Mate","memory":2147340288,"memoryFree":1205936128,"percent":43.840473969629166},{"id":"b1940325-7c09-7342-5a90-be2185c6d5b9","name_label":"PiHole wifi","memory":1075814400,"memoryFree":712548352,"percent":33.76660955644394},{"id":"aee0c791-515b-685f-1748-af352f3529d2","name_label":"XO-ron Ryssen","memory":3328585728,"memoryFree":2483163136,"percent":25.398852878816403}],"cpu":[{"id":"86ab334a-92dc-324c-0c42-43aad3ae3bc2","name_label":"Home Assistant","percent":2.451170980930325},{"id":"b1940325-7c09-7342-5a90-be2185c6d5b9","name_label":"PiHole wifi","percent":0.8001517504453661},{"id":"aee0c791-515b-685f-1748-af352f3529d2","name_label":"XO-ron Ryssen","percent":0.31519236314731336},{"id":"0f5c4931-a468-e75d-fa54-e1f9da0227a1","name_label":"Sync Mate","percent":0.134500655985903}]}}}

@ph7
Okay. It's base64 encoded, no problem, we can easily decode it. I'll check the result.

@ph7 I am talking about that:

The result is what you can see in the response tab

@ph7 Can you open your browser's console, go to the network tab, find the call to the endpoint rest/v0/pools/:id/dashboard and paste the result here?

@acebmxer so the endpoint seems to respond correctly.

Can you confirm that the pool dashboard UI is still displaying infinite loaders?

Hi, I'm not sure I understand, let's try to resume.

You're both using an up to date master branch and you're both experiencing a problem with a pool dashboard?

What is the output of GET /rest/v0/pools/:id/dashboard?

@acebmxer
The fix has been deployed to the master branch. Have you encountered any other issues?

@acebmxer Thanks. We will do our best to merge the fix tomorow

Hi @acebmxer.
Can you test on the branch mra-fix-vm-dashboard?

ACL v2: Fine-grained access control in Xen Orchestra

With the v2 of the ACL system, Xen Orchestra takes a new step forward in permission management. Where v1 offered basic per-object access control, v2 introduces a full RBAC (Role-Based Access Control) model, with effects, selectors, and an action hierarchy.

What changes

The old approach allowed granting access to an object (a VM, an SR…). Simple, but limited: there was no way to say "this user can shutdown only VM with tag: foo".

Another major limitation of v1: it only covered XAPI objects — VMs, hosts, SRs, networks, so user, groups, backups, schedules, jobs,... was out of scope.

ACL v2: REST API exclusive

ACL v2 is available through the REST API only. The JSON-RPC API (used by XO5) stays on ACL v1, and conversely: ACL v1 is not available on the REST API.

Key concepts

Roles and privileges

A role is a named set of privileges. Each privilege defines:

• a resource type (vm, sr, network, backup-job…)
• an action (read, start, shutdown:clean, delete…)
• an effect: allow or deny
• an optional selector to target specific objects (complex-matcher format)

Actions are hierarchical. Granting shutdown covers both shutdown:clean and shutdown:hard. But granting shutdown:clean does not cover shutdown as a whole. deny always takes precedence over allow.

Built-in roles

Actually, 4 template roles are provided out of the box:

• Read only — full read-only access to the infrastructure
• VMs read only — read-only access to VMs only
• VMs power state manager — manage VM power state (start, stop, reboot, pause…)
• VMs creator — create VMs from templates

These roles are immutable and automatically updated on startup — they cannot be assigned directly. To use them, copy the template into a new role and assign that copy to your users or groups. This ensures the built-in templates always stay up to date without affecting your custom configurations.

Selectors: object-level precision

A selector restricts a privilege to objects matching certain properties. For example:tags:qa
This allows add a privilege only on VMs tagged qa.

What makes this mechanism powerful is its dynamic nature. Selectors are evaluated in real time.
In case the users subscribed to VMs changes, if the qa tag is added to an existing VM, and the user have a read privilege, he will see that VM appear as a new object — the user will receive an add event, not an update. Conversely, if the tag is removed, he will receive a remove event: the VM disappears from his scope.

Events are always from the user's perspective, not XOA's. For XOA, it is a simple tag update. For the ACL user, it is an object entering or leaving their scope.

This enables very practical use cases: a single tag is enough to grant or revoke access to a resource, without touching roles or privileges at all.

Assigning Roles to Users and Groups

A role can be attached to a user or a group. A user's effective roles are the union of their direct roles and those of their groups.

REST API integration

All endpoints are exposed through the REST API:

• GET/POST /acl-roles — list and create roles
• PUT/DELETE /acl-roles/{id}/users/{userId} — attach/detach a role to a user
• PUT/DELETE /acl-roles/{id}/groups/{groupId} — attach/detach a role to a group
• GET/POST /acl-privileges — list and create role's privileges
• POST /acl-roles/{id}/actions/copy — copy a role

Each REST API endpoint declares the required privileges to access it via the swagger UI. If an endpoint declares none, it is admin-only.

A concrete example

Alice is a member of the QA team. She needs to be able to start and stop VMs in her test environment, but must not touch anything in production.

With ACL v2:

1. Create a QA Operator role with following privileges:
   • {resource: 'vm', action: 'read', effect: 'allow', selector: 'tags:qa'}
   • {resource: 'vm', action: 'start', effect: 'allow', selector: 'tags:qa'}
   • {resource: 'vm', action: 'stop', effect: 'allow', selector: 'tags:qa'}
2. Attach this role to Alice (or her group)

That's it. Alice cannot touch production VMs, and any attempt is blocked with an explicit error.

Another concrete example

Bob is allowed to rename VMs, but only while they are running — to prevent renaming VMs that are off and might be part of an automated process.

With ACL v2:

1. Create a Running VM Renamer role with following privilege:
   • {resource: 'vm', action: 'read', effect: 'allow', selector: 'power_state:Running'
   • {resource: 'vm', action: 'update:name_label', effect: 'allow', selector: 'power_state:Running'
2. Attach this role to Bob

Bob can rename and see any running VM.

One last example

Carol can see all VMs in the infrastructure, except those tagged prod.

With ACL v2:

1. Create a Non-Prod VM Reader role with two privileges:
   • {resource: 'vm', action: 'read', effect: 'allow'} no selector, grants read access to all VMs
   • {resource: 'vm', action: 'read', effect: 'deny', selector: 'tags:prod' explicitly denies access to production VMs
2. Attach this role to Carol

Since deny always takes precedence over allow, Carol can browse the full VM list — except production VMs, which are completely invisible to her.

ETA on master: early April
Already testable on mra-acl-v2 branch, but not yet finished
List of possible actions (by resource)

{
  update: {
    name_label:true,
    name_description:true,
    ...
  }
} 

is translated into -> update:name_label, update:name_description, ...

Please note that ACL v2 is currently only accessible via the REST API. Support in the XO6 user interface will be available later.

@acebmxer Yes, thanks.
The error unable to read properties of undefined is clearly unexpected. I will investigate.

You probably have a more detailed error log on the xo server side. Can you paste it here?