@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!

@JamfoFL

@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

@AlexD2006

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.

@olivierlambert

I will check back tomorrow when I'm back at that lab-pool. Sorry for taking your time thus far. I will provide more and better info tomorrow

@olivierlambert said:

So is it a display issue from XO or a problem for the tools? (not sure to get it).

What's the output of xe CLI?

This is me (jr-m4) from another (private) account.

Update: Details below are incorrect information.

xe Output for another windows 2025 guest, where I'm seeing the same behaviour

[16:25 xcp ~]# xe vm-list uuid=3d3b8ba4-09c1-039d-8d58-ec797e7a05c3 params=networks
networks (MRO)    : 0/ip: 192.168.80.234; 0/ipv4/0: 192.168.80.234; 0/ipv6/0: fe80::4496:9d87:690d:ccc7

I just noticed that one VM I did a revert from snapshot on. Now that VM has that same date as its creation date. This is not really what I was expecting... Although I can somewhat se the logic/reason. It being that one could argue that it was "created" by that reverting to snapshot.. It is not indicative of when the VM itself acctually was created.

Is this intended behaviour and working as expected?

probain said:

Unfortunately, commit https://github.com/vatesfr/xen-orchestra/pull/9727 doesn't fix this issue of the VM-console reloading constantly. With loss of focus as a result. At least not on XO6..

pierre-briffaux opened this pull request in vatesfr/xen-orchestra

closed fix(vm/console): fix VNC reconnection causing focus loss #9727

@dinhngtu

Seems that the 9.1.146 version still reports 9.1.145-77 to XO. It is listed as the correct version in "Installed programs" within the guest (Windows server 2025).

@HeMaN

I too would love this.
They'll probably ask you to submit via the feedback website. But let me know when you've done that, and I'll vote on it as well.

@olivierlambert said in Rust-based guest-tools... How are things going?:

The thing is that it works very well and doesn't need fixes… I know, not usual right? It was so stable that we left it like that waiting for people coming for bugs and nothing happened… We'll cut a 1.0 in the next weeks/months.

I have indeed seen the stability of it myself. But the lack of updates made me worry anyway. But I'm really looking forward to the promotion to 1.0 as well.

Thanks!

I'm just curious

Looking at the commit history for the Rust-based guest-tools, from the Xen-project. https://gitlab.com/xen-project/xen-guest-agent

Shows the last commit being done october 2024.. What is the status of this project? Is it dead, in hibernation, or should the xenserver-tools be used instead?

Thanks

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.