@olivierlambert Sounds good, I'll do more testing too. If there is anything you all in specific want me to test let me know!

@olivierlambert @florent
Looks like XO is not running the Destroy (old) VM on the destination SR.

@olivierlambert
Hi,
thanks for info.

Roman

@florent

Attempting to confirm what's expected vs what's observed....

If retention is the number of backups kept, regardless of the date, then if I had a retention of 2, and ran 5 consecutive backups, only the last two backups should remain on the remote?

@florent Thank you for the update

@mlustosa apologies for the slow response on that issue. I'm hoping to around to addressing that within the next week or so and thanks for posting the workaround on the related issue.

@tcorp8310 for information you can use the xe template-export template-uuid= filename= command to export a template into a file.

@florent Updated XO source to latest master and it's all green again.

Commit 3f316fcaea11775fc1393737cc6e09d8138da62d fixed the issue for me.

Thanks!

@robyt nice catch

We use compression when selecting block based backup (by default brotli), that brings a 20-50% storage reduction depending on the data
PR is here https://github.com/vatesfr/xen-orchestra/pull/6865 and will be merged before may release

fbeauchamp opened this pull request in vatesfr/xen-orchestra open feat(xo-web): vhd directory tooltip #6865

It seems that the task failed 5 minutes a go, with the error >> HTTP connection has timed out <<, I restarted the task and now everything is displayed.

Thank you

XO works well with a reverse proxy, so I would ask Authelia community I think. I don't see any reason it shouldn't work 🤔

@AtaxyaNetwork
Thank you so much.

@Andrew I'm on the same commit. To be clear, it's a warning not an error --

[4/5] Linking dependencies... warning " > eslint-config-standard@17.0.0" has incorrect peer dependency "eslint-plugin-n@^15.0.0". warning Workspaces can only be enabled in private projects.

@fred974 Gotcha, yeah this is their built in speed test which IMO isn't that accurate since it uses a very small amount of data to determine speeds, I've seen wild fluctations in it.

There isn't a huge diff: stable is just release-1. "release" is "latest". So for example, our next XO release (5.83) will be in latest while your current latest code will land in stable. So if next week (June the 1st) you decide to get back on stable, you will be in 5.82 (the current latest of today).

Nice catch @Danp 👍

Have you tried attaching the disk to a separate VM and then editing the SSH keys from there?

@Mcvills ah, cool. Well at least that fix is there in case anyone else stumbles upon what I was hitting.