@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.
@Danp
Happy to hear that you too were able to reproduce the phenomenon.
Thank you for taking the time to look.
The backup jobs are Delta Backups. And other than the Health Checks-theory, I don't really have a theory of why the same job would report 28GB transfered in XO5, but 172GB in XO6.
The comment about the side panel, is more an emphasis that it is very difficult to read and extract the relevant information from. Whereas in XO5 that information was presented far easier. Both from a readability standpoint, but also accessibility. Where I have a very hard time with being able to focus on elements in XO6... But that is another topic for another day. I'm eagerly hoping for it to mature more. And it is slowly getting better.
Ah, yes. Sorry for not supplying that bit of crucial information.
XO from source: a1dba
I should also say that I believe the transfer size is from Delta Backups. And also, I find XO5 to be better descriptive of how large the amount of backup-data was sent to the remote. Whilst XO6 includes the amount of data from Health Checks sent as well. If this is the case, then the amount if Health Check data, isn't relevant imho. Or should be placed in brackets or similar.
I'm noticing that the transfer sizes for backups are different between XO5 & XO6. And this is by an order of magnitude in difference. Why is that?
If I could decipher the pop-out side-panel, then maybe I could figure it out. But I honestly can't even look at it. 
No explicit assigned migration or backup network set.
Backups generate errors somewhat randomly. As one VM won't get the "error" one time. But on the next backup run it will. And the third time it might not. This even happens on VMs that are turned off, and therefore shouldn't have any changed bytes between backups.
I've since reduced the number of NBD connections to 4. However, I'm actually still seing this happen. I thought it was resolved. But going back to confirm, proved I assumed wrong.
I have therefore uploaded a new bugtools archive from the host server on the link @poddingue sent me earlier.
I hope they can prove helpfull. If you'd like me to do anything else, then I'll happily help out.
Cheers!
@olivierlambert
Happy to hear that they are providing results to be looked at.
If there is anything else I can provide, please don't hesitate to ask. And I'll do my very best to be helpfull
5 nbd connections went fine.
8 is not.
Thanks for looking into it further as well.. If there is a hard cap on the amount of NBD connections, then that is very interesting. Because the closest I've ever been able to find regarding this setting, was the general answer of "Try and see what works for you". So if ther is indeed a hard cap, then I would propose that this is limited inside the GUI itself. e.g. if the cap is 8, then don't let the integer exceed 8.
I'm doing increasing increments of the number of connections now. So far I've done 1,2,10. And 10 does seem to be breaking again, but only on some.
Thanks as well for the link. I'm collecting the logs through xen-bugtool --yestoall now. I do wish that something like this is implemented in GUI someday. And I even made a FR feedback on it. Since I really do want to provide good information for the devs. But collecting manually isn't the most convinient way unfortunately.
Logs should be up shortly
