@florent said in Snapshots are no longer being pruned? Commit 58f02:
@probain thanks for signaling this, we just merged a fix, that fix it on our labs
can you test it on your side ?
https://github.com/vatesfr/xen-orchestra/pull/9202
I can confirm that it solves the issue in my primary lab. Tomorrow I will be able to re-validate at my second lab as well.
Thank you for such a quick fix!
I've mentioned it on the forums once or twice. And after @wezke explicitly asked for it. I decided to take the time to finally go ahead and publish an Ansible-role for installing XO from source.
Benefits from using any of the many installation-scripts:
Scripts are often quite big. Making them hard to validate and scrutinize for security reasons.
Ansible (imho) is easier to read and see what it does.
If you are orchestrating your environment through Ansible already, this should drop in semi-nicely
This follows the official steps from the Xen-Orchestra docs, except for ONE main thing. This does not run the xo-server as root. In the hopes that it should raise security just a tiny bit more.
Note and Disclaimer!
Do your own validation of the source. Do NOT take my word for how this works. And use it at your own risk.
Now, with all disclaimers out of the way. Feel free to use as you'd like. I hope the community takes kindly to this.
https://github.com/cloudrootab/ansible_role_xoce
PS: This is ported from my private role. But should work. See the disclaimer above!
PPS: This is a re-post from a now deleted forum-post, where I mistakenly placed the topic in XCP-NG/Installation.
@olivierlambert said in 
️ XO 6: dedicated thread for all your feedback!:
So I quickly experimented different "identities"/themes.
Here is "Nord" in dark mode:
Please add this. This was gorgeous!
@florent said in Backblaze as Remote error Unsupported header 'x-amz-checksum-mode' received for this API call.:
,
requestChecksumCalculation: "WHEN_REQUIRED",
responseChecksumValidation: "WHEN_REQUIRED"
I (previously as @jr-m4) just tried the patch you suggested. And I can confirm that this does indeed make the backup complete successfully!
Great work finding a solution that quicklly!
@Danp responded to similar/same issue here:
https://xcp-ng.org/forum/post/89858
@R2rho
Faulty gear always sucks. But who would've guessed that two separate systems would produce the same problems. That is highly unlikely, but never impossible.
Good luck with the RMA
For completeness sake. Confirming that the fix also works in my second lab as well.
I can now reliably recreate the behavior between the commits mentioned above.
As I expected, the problems with finding a "known good" was due to user error
Thanks for your input.
So I believe I've managed to find which commit breaks my snapshot-pruning.
If I use the commit: 8a390057b648205b7ae2c6ccc2a0bc78dc624e08 - Then the pruning works.
However, if I go to the next one: 05c6f87a1212e81c51e63f6a585b9e97a3c1bfb2- Pruning breaks and snapshots are no longer being deleted as retention says they should.
I can consistently and reliably re-create the different scenarios in my first lab. This doesn't explain why I'm seing inconsistent results in my other lab. But that might be user error, that I have to double check tomorrow!
Perhaps you could try to see if you see the same behaviour between the commits?
It might be that my known good, isn't that good at all.
I can replicate the problem in my second lab as well. But it is being affected even with commits older than a101e.
I'm still trying to find and provide better/useful information.
Also..
Thank you for taking a look at it and solving it so quickly, @florent
It is a quite nice interaction when reporting bugs that they are looked at and triaged. Not saying everything needs to be a priority 1. But I do appreciate being close to the process. And if I can help make things better by reporting bugs, in a hopefully constructive way. Then I'll continue to contribute my way.
@florent said in Setting "Protect from accidental deletion" breaks with backups and healtchecks:
the fix is merged into master
I can confirm that the problem has now been solved. And will mark the raised github-issue as closed as well.
@Greg_E
or just uncheck the "protection"-flag. But that get tedious very quickly. And I only had to do it on 6 VMs.
@greg_e & @florent
I have gone back through the commits, and I believe it is 0a042d2f54a74ecc11a377809272337cb5c880d9 that introduces the bugg.
https://github.com/vatesfr/xen-orchestra/commit/0a042d2f54a74ecc11a377809272337cb5c880d9
My last known good and working commit is the one just prior to it, a831ac7b213eb6fc7f05fbd466407d5cf379cfe9.
Tried with the latest commit (as the time of writing). 91c5d98489b5981917ca0aabc28ac37acd448396. But this didn't fix it, unfortunately.
Filed a issue/bugg-report on github for this
https://github.com/vatesfr/xen-orchestra/issues/9472
@pilow
A lot of updates can, and do, happen in a month or two 
I didn't have this before yesterday, which is when I updated. And I update from source regularly. So the regression has happened since the last few (<1w) days.
I'll step backwards and see which commit introduced the bug.
Manually unchecking makes the problem go away..
And I can also delete manually (after unchecking the HC-vms)
Having the flag "Protect from accidental deletion" has since yesterday left me with plenty of restored VMs. In the backup logs, it indicates that this happens during the healthcheck.
This has happened on 3 out of 6 VMs
Update: The other 3 VMs were opt-out from Healthchecks. So that is why this didn't affect them.
commit: dd5f0cdaa9993fae25469bd1cb1d01d4f2123f44
transfer
Start: 2026-02-04 12:16
End: 2026-02-04 12:16
Duration: a few seconds
Size: 2.01 GiB
Speed: 81.14 MiB/s
health check
transfer
Start: 2026-02-04 12:16
End: 2026-02-04 12:35
Duration: 19 minutes
vmstart
Start: 2026-02-04 12:35
End: 2026-02-04 12:35
Start: 2026-02-04 12:16
End: 2026-02-04 12:35
Error: forbidden operation: destroy is blocked: protected from accidental deletion
Start: 2026-02-04 12:15
End: 2026-02-04 12:35
Duration: 20 minutes
Error: forbidden operation: destroy is blocked: protected from accidental deletion
Clean VM directory
cleanVm: incorrect backup size in metadata
merge
Start: 2026-02-04 12:40
End: 2026-02-04 12:41
Duration: a minute
Start: 2026-02-04 12:40
End: 2026-02-04 12:41
Snapshot
Start: 2026-02-04 12:41
End: 2026-02-04 12:41
said in ️ XO 6: dedicated thread for all your feedback!:
Windows guests Console - Reloads every 5-10s.
When trying to use the console for both my Windows 11 and Server 2025. The console reloads every 5-10s. This makes it borderline unusable. Since it resets the viewport/window scroll placement as well. Also the console seems to loose focus when this happens as well. Leading to have to click the console-section to get it in focus, to receive I am not seeing this behaviour in XO5 at all.
.
.
.
.
Unfortunately this is still present in commit 0a0ae5dc7ea6608612d105f6338ffe72d8bd9ed1 as well..
Update: I recorded the behaviour, for better clarification:
https://www.youtube.com/watch?v=PXpBFgSl31U
I've updated and added a node.js-installation to the role. Targeting the LTS-24 version.
I hope you find it to your liking.
Windows guests Console - Reloads every 5-10s.
When trying to use the console for both my Windows 11 and Server 2025. The console reloads every 5-10s. This makes it borderline unusable. Since it resets the viewport/window scroll placement as well. Also the console seems to loose focus when this happens as well. Leading to have to click the console-section to get it in focus, to receive I am not seeing this behaviour in XO5 at all.
I do not see the same behaviour on Linux (Ubuntu 24.04) guests. But they are cli-only. No X/Wayland
Commit: b89c26459cfd301bb92adf0a98a0b2dbab57e487
node: 24.12.0
Management agent 9.1.100-59 on both VMs
Windows 11 has GPU passthrough & bios
Windows Server 2025 - no GPU passthrough , uses uefi