So when i try to run the installer for just he plugin on a fresh windows server it prompt that b&r 13.1 needs to be installed. On fresh install of 13.1 the plugin is include. My guess if someone is upgraded from previous version the plug would not get installed by default? When i run the plug installer with B&R 13.1 fresh install it prompts to uninstall the plugin.

@jeremie1977 Merci ! Je teste ça de mon coté et je fais un feedback vite !

Great, thanks for the feedback!

A remote is not the same thing as a SR. For a remote, it's simple: disconnect it (click on "Enabled" so it's disabled then), do whatever you need on the NFS server, re-enable.

@olivierlambert Happy to hear that they are providing results to be looked at. If there is anything else I can provide, please don't hesitate to ask. And I'll do my very best to be helpfull

Actually, isn't XAPI 24.19.2 what is shipped with the original XCP-ng 8.3 release? If so, then you could just do this -- Reinstall XCP-ng on the new host Restore the pool metadata Patch the host

Thanks for coming back with the actual cause instead of leaving it hanging. To me, a permissions reset on /etc/rc.d/rc.local would explain it completely, and it fails in the worst way, since nothing complains at boot and the VMs just never start. It also looks worth documenting, because our own troubleshooting page tells people to append a clocksource workaround to /etc/rc.local without mentioning the executable bit either, so anyone following that could end up with a workaround that quietly does nothing. I haven't tested whether the 8.2 to 8.3 upgrade resets that bit every time or just happened to in your case, so that half stays your finding, not mine. I'm curious what you turn up on the colon versus equals behaviour.

Congrats on getting this out so fast after 6.7, and thanks for the writeup, genuinely interesting approach. The declarative angle instead of wrapper code per endpoint makes sense to me, especially given how often the REST surface grows. One thing I keep wondering about: you framed the auth/audit/fail-closed checks as sitting in front of the gateway. What happens when the model actually asks for something destructive, a VDI delete, a host disable, that kind of thing? Does the gateway block it outright, or does a human need to sign off somewhere in there? I'm asking because that's close to the exact boundary question our own Insights piece touched on this month. I'm community manager here, not a developer, so I'd rather ask than guess at how the security model actually behaves. Want to understand it properly before I say more. Passing this along internally too. No promises on timing, but it's the kind of thing worth a closer look.

Excellent! It's really cool to see how XO Backup and Replication can help you to migrate easily

@florent [image: 1785422247634-backup-metadados3.jpg]

@oliv77 said: Hi, XOA version: xo-server 5.193.1 xo-web-premium 5.191.0 We've noticed on our production XOA server that when we put an XCPNG host in a pool into maintenance mode, we reboot it and then it reconnects to its pool but is no longer in maintenance mode. Is it possible to configure the XCPNG hosts so that they automatically return to maintenance mode after a reboot? Regards, Oliv77 Hi @oliv77, XO 6.7 - latest - adds this option in REST API and next month we should have the available action (Disable host and evacuate VM) in XO6 !

I think this is fixed in 6.7: when a delta backup falls back to a full, the task now shows the actual reason instead of just contradicting itself the way you and Andrew both saw (PR #10148). Worth checking after you upgrade.

Both things reported here look fixed in 6.7: the retry succeeding but the job still showing as failed (PR #10129), and the EEXIST: file already exists error, which happened when a job got recreated after a crash (PR #10139). Curious if upgrading clears it for you all too.

The progress bar issue you and Florent were chasing looks fixed in 6.7 (PR #10133). Worth upgrading and seeing if it moves now instead of sitting still. Separately, since this thread is specifically about QCOW2 backups: 6.7 also fixes an offset bug that could leave incremental backups mostly empty after the first block when NBD isn't enabled. Worth a look at the release notes if that's your setup too.