Thank you for this constructive argument

Have a nice day.

@markhewitt1978 Hi, thank you for your feedbacks!

We are aware that this limitation bothers a lot of users and we have plan to address that in the next major version of XO.

XO 5 was already a major improvement over its predecessor because it allows viewing and handling a much bigger infra.

XO 6 will go further in this direction by introducing a tree view and the possibility to edit and handle many objects at the same time.

@Danp That may not be directly to script but to the external environment: SMB works much better if cifs-utils is installed on the system, something that is present on our doc but might be missing in some install scripts.

We have no animosity whatsoever regarding these scripts but we prefer our appliances (or even manual installs from our documentation) because we understand much better what's going on and it's easier to replicate and fix the issues

Regarding your idea of including the commit identifier for the source version, that's not a bad idea, a (as simple as possible) implementation in a PR would be welcome

I've added the support of advanced filtering in the API, it does no have first class support in xo-cli yet but it's usable anyway:

xo-cli xo.getAllObjects limit=json:10 filter='type:/^VM$/ snapshots:length:>2'

Should be fixed, sorry for this

Thanks all for your feedback!

Should now be fixed, sorry for this.

Thank you all for your reports, should be fixed

https://github.com/vatesfr/xen-orchestra/commit/3cc9fd2782de353dbd866471a793366748c0c098

0 julien-f committed to vatesfr/xen-orchestra

fix(xo-server/api): log instead of rejecting  non-strict schemas

Fixes https://xcp-ng.org/forum/topic/4439/plugin-transport-email-v0-6-0-broken

@rizaemet-0 Thank you, this is really interesting, it suggest that HTTP encryption in XO is a CPU bottleneck.

It should be alleviated in the future, because in a couple of month, all backup jobs should run in separate process, which will better distribute load on multiple CPUs.

FYI, this feature has been released

I'm thinking about it

@andrew It should be fixed, thank you

@andrew Thanks for your report, I'm on it

@mike XO checks existing backups before doing a delta, you should be fine

@olivierlambert Exactly.

@s-pam we were not able to reproduce so far on our side. Also, most of the XO team (myself included) is on holidays until next week, thus I'm not sure we'll be able to fix it before.

If you are using an official XO appliance, you can rollback to the stable channel and if you are using XO from the sources, you can go back to a previous commit.

@danp Which type of remote are you using for this job? SMB? NFS?

@danp I don't think these are new or related to this issue.

@danp We were not able to reproduce the issue on our side, what's the config of your backup job?

We discussed this issue in a support ticket but for everyone else: it was a bug and a fix was shipped in XO 5.66.1 yesterday

@jedimarcus Yes, we got some reports on this, we're investigating

@danp It's a warning for an indirect dependency (@vuepress/core > url-loader), I don't think we should worry about it.