Nice, thanks for the feeder entry and the explanation, @CAPS!

Thanks!

@gduperrey pointed you here, so paste the two screenshots and the description into this thread too, otherwise whoever picks it up lands on a bare link.

In your tasks screenshot the Rolling pool update row on PRD is dated 2026-08-10, 27 minutes, progress bar never filled, which looks more like an older failed run than the one you'd just finished.
Was that the entry you deleted, or was there a second one from today as well?

I don't know how XO decides when a failed task leaves that list, so I could easily be reading your screenshot wrong.

Might be worth a mention to Team-XO-Backend once the details are here, and your XOA version would help them too.

Thanks for chasing this with them, and for offering to post back after the call.

Your Alma 10 read looks right (the 9.0 demonstrator is Xen 4.19 with a dom0 loosely based on AlmaLinux 10 and a 6.12 kernel), but @yann said in July they're out of prototyping and rebuilding the foundations component by component, so I wouldn't treat that kernel as the one their driver ends up targeting.
On the packaging side, the kernel module policy page is the nearest thing I've found to an answer for what you'd need to pull together: https://docs.xcp-ng.org/project/development-process/kernel-module-policy

For VROC, my understanding is that it sits on VMD, though I could have that backwards. VMD stalled boot on the demonstrator kernel back in January until yann said he'd include a patch for it, so that stretch of the thread is worth a read before your call: https://xcp-ng.org/forum/topic/11698

I don't know enough about driver packaging to say what Vates would actually need from GRAID, so it might be worth pulling in @Team-Hypervisor-Kernel, since drivers are their scope.
If the call gives you a list of what they need from our side, that's probably the most useful thing to bring back here.

The same assumption was already fixed once on the dashboard side: https://github.com/vatesfr/xen-orchestra/pull/9997 counts sequence schedules in the backup computation, merged back in June.
So the home filter looks like that same fix never made it across, which is a better argument than "it would be nice".

On your second point, XO 6 may already have part of it: there's a Backed up VMs tab that lists from what's actually on the remotes rather than from the job config, which is the "like the restore page does" bit you were after, and https://github.com/vatesfr/xen-orchestra/pull/10277 is an open fix for a caching bug in it.

I haven't used that tab myself, and since it's built around VMs that do have backups, I don't know if it gives you the negative view you want. If it doesn't, https://feedback.vates.tech is where that gets counted.

It was too tempting not to test, so I went and tested the other half.
On an 8.3 host I set the preferred resolution to 800x600 in the OVMF menu on a UEFI Debian VM, turned that VM into a template, and cloned it.
The clone came up at 800x600.
A control clone of the same original, with nothing set, came up at 1024x768.
So your workaround holds, the resolution really does ride along into VMs built from the template.

For anyone who wants to poke at it, the setting is a UEFI variable called PlatformConfig under GUID 7235c51c-0c80-4cab-87ac-3b084a6304b1. It only appears in NVRAM once you commit it in the menu, and it stores width and height as plain little-endian integers, which is why it travels with the VM record.

One thing I didn't expect: the OVMF help text says the mode list is filtered against video RAM size, but the VM I used had the default 4 MB and still offered everything up to 1280x1024.
So you may not need to raise videoram for the common ones.

Fair warning though, I measured the console at the firmware stage rather than after the distro's own driver takes over, so a guest that sets its own mode later could still override it.
At least, that's my understanding.

I think I may have found why, though someone on the XO side should check me on this.

The filter builds its list from backup jobs that have at least one enabled schedule of their own, right?
A sequence works the other way round: it gets its own timer and runs the member schedules from there.

So once those member schedules are switched off, their jobs drop out of the filter and every VM they cover reads as not backed up.
If that's right, it's a wrong answer rather than a missing feature, which matters because it changes who needs to look at it.

I got there by reading the code with bad glasses, not by reproducing it on a real install, so treat that last step as my wild guess.

Might be worth a mention to @Team-XO-Backend.
Your dashboard idea could well be the better home for it anyway.

To me, the template idea does hold up, at least the part I could check.

On an 8.3 host I cloned a UEFI VM, then turned that clone into a template and cloned it again.
The NVRAM field came back byte-identical both times, so whatever sits in a VM's UEFI variables really does travel into VMs built from it.

What I didn't test is the preferred-resolution setting itself, so I can't promise the resolution survives and applies, only that the place it lives in does.
So it's half an answer.

The "would Vates do this" part isn't mine to answer, and https://feedback.vates.tech is where that gets counted rather than a forum thread.

Worth saying there that https://docs.xcp-ng.org/vms/#manage-screen-resolution only covers the guest-OS side, so the firmware route you wrote up isn't documented anywhere official.

You can say so by clicking at the bottom of the page on :

Was this page helpful?
Yes/No

Or even click on:

Edit this page

Thanks a lot for this feedback, @pedro!

On the XO Lite one, there's an issue open that sounds like what you're describing, https://github.com/vatesfr/xen-orchestra/issues/9801, filed off @Greg_E's report in this thread.
It says UEFI VMs created through XO Lite don't boot since the LTS release, with Debian 13 and Windows Server 2022 both failing, while VMs built under 8.2 with UEFI still work.

Your timing may not line up, since you're saying last year and that issue is scoped to since the LTS release, so I'd rather ask than assume.
If it does look like yours, a comment on it would carry more than anything I can add, because it hasn't had one since May and I don't think anyone has picked it up.

Thanks for the numbers.
So the whole chain drags: 4 to 5 minutes to list the ~90 LUNs, another 1 to 3 to validate one, and the create on top of that.

From the XO side I can't tell where that time goes, XO itself, the host's storage layer, or the array answering slowly, and the one measurement that would split it is the host-side probe I mentioned: time xe sr-probe type=lvmoiscsi device-config:target=<ip>, then the same call with device-config:targetIQN=<iqn> added.

If the CLI takes just as long, XO is mostly off the hook. A 90-LUN multipath target doesn't sound exotic to me, so probes taking minutes feel worth a proper look, though I honestly don't know what's normal at that scale.

@Team-Storage, the numbers above are concrete now, in case it's worth a look on your side.

That's great news, thanks, @christopher-petzel !

No problem about the delay, of course.
I put on better glasses, and guess what? There is a Container management section in the XO docs after all, in docs/xo5/manage_infrastructure.md.

It doesn't describe the old xscontainer route though. It says you can run Docker inside a VM, then links out to Docker's own docs and the Kubernetes recipe, so there's no procedure sitting there to walk anyone into a wall, and no sign of the feature either.

On the features matrix I can't check it the way I checked the rest, because the page builds itself in the browser and fetching it gives me nothing, so treat that one as unchecked rather than confirmed.

The Feeder entry still isn't there, I looked again today, so that part stands.

Thanks, keep us posted!

I don't know the probe path well enough to say where the time goes, so this is mostly questions back at you.

Is it the IQN probe or the LUN probe that drags, and are we talking seconds or minutes?

Our docs describe it as two steps, xe sr-probe type=lvmoiscsi device-config:target=<ip> to list the IQNs, then the same call plus device-config:targetIQN=<iqn> for the LUNs behind one ( https://docs.xcp-ng.org/storage/manage-srs#discover-what-the-storage-offers-probe ).

Timing those by hand on the host would at least split XO's share from XAPI talking to your array.
It'd also help to know the target type, roughly how many IQNs and LUNs it exposes, and whether multipath is on, because my guess (and it's really a wild one) is that a wide target is where an enumeration gets expensive.

Might be worth a mention to @Team-Storage, who'd know what the probe does underneath.

I measured this on a two-NIC 8.3 host.
As far as I understand, there's no way to do it from XO: the call that edits a network doesn't take a bond mode, every bondMode in the codebase sits on a create path, and the REST API on a running XOA offers create_bonded_network plus get and delete on a network, with nothing that edits one.
The CLI route looks cheap though. xe bond-set-mode on a live bond cost zero dropped packets in both directions I tried, pinging every 200ms across the change, and the command returned in about 1.4 seconds.

Two caveats, and the second is about your case specifically: creating and destroying the bond did interrupt the host (roughly 8 and 16 seconds), and I only went active-backup to balance-slb and back, never touching lacp, because my switch port isn't configured as a LAG and I'd have dropped the box.
So I can't tell you your lacp to active-backup move is free, only that mode changes in general didn't cost me anything.

Worth putting on https://feedback.vates.tech either way so the votes have somewhere to gather.

I went digging and three threads turned up people who already have this hardware.
@yeopil21 in https://xcp-ng.org/forum/topic/11799 had an LPe37102-D on a Dell R770 that never showed up at all, @jinju0504 in https://xcp-ng.org/forum/topic/11946 ended up on the -alt package on an R670, and @lukas in https://xcp-ng.org/forum/topic/8847 was running an LPe31002-M6-D with NVMe-oF back on 8.3 beta2.

That last one is the older generation, so I'd guess it's the side where you most want to hear nothing regressed.

Tagging them in case the cards are still on their benches.

Thanks for the feedback so far, folks!

I'm late to this, but I've been building lately a JetBrains plugin against the REST API and ACL v2 turned out to decide its whole design, so here's some feedback.
Everything below is just one appliance, one pool (my small homelab), on a plan 4 trial, with an admin control call taken in the same breath as every scoped one.

What I experienced is that selectors narrow reads (tags: and id: both, 1 VM against an admin control of 11), they're re-evaluated per request rather than fixed when the privilege is created, deny composes the way your Carol example says (allow-all plus deny on a tag gave 9, which is 11 minus the 2 tagged), and they scope the power verbs too, not just reads.

The event stream is, to me, scoped as well, which was the thing I most wanted to check, because a scoped read next to an unscoped feed would have been a nasty trap. It's not.
With two streams open at once, a change to an out-of-scope VM produced an update on the admin stream and nothing at all on the scoped one, so it's genuinely filtered rather than merely quiet.
And the bit I'd underline: the same single change is update to the admin and add or remove to the scoped user. The verb is computed per subscriber, not per object. Across that run the admin only ever saw update, and I originally wrote that an admin never sees add or remove at all. That was wrong and I've since measured it: an admin does get add and remove when an object is genuinely created or deleted. So the rule is that a scope change reads as update and an existence change as add or remove, which supports your design better than what I first wrote did.
"From the user's perspective, not XOA's" turns out to be literal rather than a figure of speech, and that's a nicer piece of design than the sentence let me imagine.

Now the three things that I didn't see in the post above.

vm-snapshot is a separate privilege resource and vm doesn't imply it. Maybe that's obvious, but it was not obvious to me.
With all six VM privileges granted, GET /vm-snapshots came back empty while admin saw 6, including a snapshot the scoped user had just taken. Anything with a restore or revert screen gets an empty list and no error.

Inherited snapshot tags look like a snapshot-time copy rather than a link. Tag a VM and it's in scope immediately, but its existing snapshots keep tags: [] and stay invisible. So someone onboarded into a tag scope after their snapshots exist sees the VM and not its history.

Subscribing delivers no initial dump. Both streams sat on init and keepalives until something changed, so it's a delta feed and a client has to fetch the collection over REST and maintain it from events. Worth a line, since the natural assumption (at least to me, don't make that the rule for everyone) is the other one.

While I'm here: two smaller ones. Privilege action names aren't REST action names: shutdown:clean grants clean_shutdown, revert-snapshot grants revert_snapshot, and a mistyped action quietly gives you a privilege that grants nothing.
And the event: init frame's field is id, not connectionId (why did I think it was connectionId, no idea, I thought it was "natural"), which cost me a while of thinking the stream was dead when I was posting to /events//subscriptions.
Yes, I know, I should have read the documentation instead of experimenting in the dark, sending made-up field names in the wild.

One last thing: selector is optional, so a privilege created without one reads back as {id, resource, action, effect, roleId} with no hint the field exists.
I granted allow read on vm, saw all 11 VMs, read the object back, and (falsely) concluded the REST API had no object dimension at all.
It's all in the previous post and it's in the swagger, and of course, in the official documentation. Once again, I'm an innocent victim because I didn't RTFM.
I just never saw a privilege that had one. If a privilege echoed selector: null, or if the first example anyone met were a scoped one, I don't think I would have spent much time on that. Once again, my bad, didn't RTFM.

This was a small, targeted test, at best. I didn't have the intent to test what was brought up in this very thread, I just happened to tinkle with the REST API and ACL V2 for my PoC, so lots of things got untested.
Please, don't take it from me as settled: only tags: and id: selector forms, nothing on a second pool or a real multi-user deployment, and I have not checked what happens to a live subscription when the privilege itself changes rather than the VM's tags.

If you read me until there, you're brave, or have too much time on your hands.