Topics created by Gheppy

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

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

@Gheppy It should be fixed, thanks for your report!

https://github.com/vatesfr/xen-orchestra/commit/b5578eadf7356098ac2fa4af63b75b18d34ba558

0 julien-f committed to vatesfr/xen-orchestra fix(xo-server/sr.{create,set}): name can be empty Fixes https://xcp-ng.org/forum/post/59937 Introduced by 65168c853

@Gheppy Ah! Great news then 🙂

@florent Thanks for the fix.

P.S. @Gheppy was the original reporter. 😉

@Gheppy @julien-f
I have the same problem....
post 6940

Check Dashboard->Health and look at the bottom to see if the Importing VMs are still there.

So far, no solution, other than to rollback to a working version.

@FabioRizzo What exact error do you get?

@Gheppy
I am not an expert on the network part but I can help on the NBD part

We added some info in this PR https://github.com/vatesfr/xen-orchestra/pull/6596, it should be merged in this form or another in master in a few days. It will give the user more info on the NBD usage and the cause (misconfiguration, or network error)

Then if XO ( or the proxy) can't connect to the host through the NBD (for example with a network filtering/ routing), it will fall back to the reliable (but non parallelizable) api call

Finally , the backup done with NBD or the legacy api call will produce exactly the same data so they are compatibles, but using the same target (as in the same directory , same remote and same VMs) for multiple job can lead to complex support tickets with interesting race conditions.
I would advise to only use the same remote/directory only if the backups jobs does not concern the same VMs

fbeauchamp opened this pull request in vatesfr/xen-orchestra closed feat(@xen-orchestra/backups): more information on nbd backups #6596

This is probably something for XO 6 then, let me ask @julien-f in the conversation 🙂

Yay! Thanks both @Gheppy for the report and @errellion for the feedback 🙂

@Gheppy I will ask @marcungeschikts to take a look at this and talk to dev team about it

Hello, we will take a look into that and keep you posted.

Thanks for the guidance, that's all I need.
It's all working now.

Thank you

Fixed, thanks for the report 🙂

https://github.com/vatesfr/xen-orchestra/commit/7830c89e66e178921695aa5e17670717703ef290

0 julien-f committed to vatesfr/xen-orchestra fix(xo-server/Xapi#exportVm): correctly use getRecord Introduced by 6aa5ec6eb

Is there any option to set for timeout value?

I say this because, monitoring the process, everything seems to be going well until the moment when it starts to check the free space.

XCP-NG is 8.2 up to date, the disk on which the VM is it is formated as local ext.
The connection to the backup server is on NFS on the LAN at a speed of 1Gb.
On the iotop it seems that the space check goes with speed 650Gbits +.

Just change HTTP in the Settings/server to connect to your pools with http://<IP> that's it 🙂

yes, I have no problem with commit before.
For now I'm on commit 65e62018e6aeabf64cf9def01ad043dfbdff5c18 and all is ok,

This can happen from time to time on master (despite we do every "broken" code in dedicated branches), sometimes you can have a surprise.

That's why it's important, before anything, to get the latest commit and rebuild, to see if the issue persist. If it's the case, then reporting the problem will be helpful 🙂

Yes, that's what i want to do.
But at the moment it create an snapshot for each cron that I made and I want to have only one snapshot and to be reset to full backup on Saturday.
In essence, I want to have only one snapshot to an VM no matter how many cron I have attached to the replication.
In this case, I want to reset the Continuous Replication chain when the server is least busy, not after a number of replications

This is a known issue that will be fixed next week.

@julien-f is working on it 🙂