administrators group | XCP-ng and XO forum

poddingue

Thanks, that helps. Some VMs fail to the Synology but pass to S3, and some the other way round.
So I think the backups on Ark are probably fine (they pass health checks, as you said at the start) and it has more to do with what each target already holds, but I could be wrong.
I'd also flag the several delta jobs with different retentions all feeding Ark, I just don't know the mirror code well enough to say whether that matters.

@Team-XO-Backend, posts 6 and 10 have the log and the pattern if someone gets to this one.

poddingue

@mdm thanks for checking Reconnect. If I'm reading the code right, both actions have the same mistake, so one fix should cover both. You already wrote the steps out in your first post, so if you're up for it, an issue on https://github.com/vatesfr/xen-orchestra/issues would put it where the frontend team tracks their work. Their bug form asks for the XO version (or commit if you're on sources) plus your Node and XCP-ng versions, which I don't know for your setup.

poddingue

If you have the time, an issue on https://github.com/vatesfr/xen-orchestra/issues with your build date and that ps -T output would make the case better than I can.

poddingue

Thanks for the screenshot, Christof. I haven't reproduced it myself yet, but I think I can see why it only hits that one field.
In XO Lite's VM creation form, the rows of the disk table seem to be keyed on the disk name itself (line 12 of NewVmSrTable.vue on current master), so each character you type would make Vue treat the row as new and rebuild it, focus included.
If I'm reading it right, someone reported the same thing for XO 6 in March (https://xcp-ng.org/forum/post/103160), and the XO 6 form now keys those rows on a separate field, so the fix might be small.
Might be worth a mention to @Team-XO-Frontend.

olivierlambert

Thanks for the feedback!

poddingue

This looks like the same thing @acebmxer ran into in July (https://xcp-ng.org/forum/topic/12339), and your libuv reading matches what the XO devs wrote in https://github.com/vatesfr/xen-orchestra/pull/10587.

As I read their write-up, with a hard mount every background operation on the dead remote (listing backups, retries) holds one of xo-server's file-access threads until the NAS comes back, and once they're all taken the web UI can't be served either.

Olivier's advice back then (https://xcp-ng.org/forum/post/106632) was to disable the remote while the NAS is still up and only then power it off, and acebmxer scripted that on the Synology so the remote gets disabled at shutdown and enabled again at startup through the XO API.

If XO is already stuck, XO 6.10.0 added xo-server-db disable-remote <id>, which you run while xo-server is stopped so the remote isn't mounted again on the next start; your November 1 build should have it if I read the dates right, but I haven't tried it myself.

About UV_THREADPOOL_SIZE I'm only guessing, but since a hung NFS call never gives its thread back I'd expect a bigger pool to just take longer to fill, and the PR says they tried capping the threads one remote can use and dropped the idea for now. @Team-XO-Backend will know better than me whether more is planned.

poddingue

Thanks for the information, @ph7 .
That's a typo, for sure.

administrators

Posts

Member List