At a certain point, I don't know when because we are talking about a home lab here.
I could attach the USB HDD same as a virtual HDD and I could put exclusions on it

@olivierlambert
Thank you, this solve the problem

And I confirm this, the problem has disappeared.
Thank you

ok, thank you

This is precisely why we did that feature in Xen API 🙂 Enjoy!

In essence, you can write any script you like in your VM that would be executed, test whatever you want in the database, and if it's OK, write a special key in the XenStore. XO will detect it and consider the backup health check done and working 🙂

Hopefully, we'll make things more obvious in terms of "danger zone" in XO 6 UI 🙂

Question for you @florent

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.