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

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

Hey everyone!

The patch is finally here

Sorry for the delay

How to test?

1. Select the latest channel on your XO appliance
2. Upgrade to Xen Orchestra 5.43.2
3. Go to the Proxies page and either Deploy a proxy or upgrade the appliance of your existing ones

What's here?

• Full Backup
• Disaster Recovery

Known limitations/issues

Scheduled for Step 2 at the end of the month.

• Network configuration for the proxy appliance
• Delta Backup
• Continuous Replication
• Detailed logs, they are currently empty
• Restoring backups
  Work-around: create a normal remote (not linked to the proxy) connected to the same storage and import via the XO appliance

Thank you for your feedbacks

@k_hamilton The issue is that XO tries to store some config in ${HOME}/.config/xo-server and the setting user=username does not set the home to the specified user.

You can work-around this by explicitly setting the $HOME var when starting xo-server.

@joearnon It means that there is already another job working on this VM at the same time.

@zevgeny Detached backups are backup files present on remotes but not related to any existing backup jobs or schedules.

Restoring the XO config in the new install should properly recreate the backup jobs and avoid this issue.

@bazzacad The replicated VM has its start operation blocked which means that it cannot automatically power-on.

But, if you force started this replicated VM via XO, it removed the blockage and now the VM will automatically power-on.

That should not be the case as the replicated VMs have their start operation blocked

What version of XCP-ng are running on this secondary host?

@Danp Yes, this is normal, it's because after the merge, the size of the oldest backup has changed.

We could fix that but it's not a priority and won't change anything except getting rid of the warning.

We'll see how many reports we get regarding this

@cfm56 The error was probably due to https://github.com/vatesfr/xen-orchestra/issues/5836

This did not impact the import of the config though, anyway it should be fixed now

trader418 created this issue in vatesfr/xen-orchestra

closed Config restore error #5836

@cfm56 Any info on the page Settings/Logs?

Or maybe on the output of xo-server?

@cfm56 If the file is not encrypted, just leave the field empty

@danp No, those are generated files.

Unfortunately they are not cleaned-up automatically but hopefully this won't happen too often