@acebmxer Hello, thanks for sharing this here! Me and my team have been waiting for this release! I signed up for the Veeam newsletter hoping I would get notified once Veeam 13.1 (an XCP-ng plugin) gets released but they seem to be a bit slow. So I found out about this release due to your post. Will start testing!

Great, thanks for the feedback!

@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

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.

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

@poddingue Thank you for the feedback! As I am typing this, I believe I've found the issue for autostart issues. My rc.local: [09:15 REDACTED]# cat etc/rc.local #!/bin/bash # THIS FILE IS ADDED FOR COMPATIBILITY PURPOSES # # It is highly advisable to create own systemd services or udev rules # to run scripts during boot instead of using this file. # # In contrast to previous versions due to parallel execution during boot # this script will NOT be run after all other services. # # Please note that you must run 'chmod +x /etc/rc.d/rc.local' to ensure # that this script will be executed during boot. touch /var/lock/subsys/local sleep 300 /usr/bin/xe appliance-start uuid=00edfd41-1b01-f401-43cb-68201c6415c6 From the commented out section above we can clearly see that correct permissions need to be set on /etc/rc.d/rc.local, while my permissions got back to default values after upgrade, see below: [09:16 REDACTED rc.d]# ls -al /etc/rc.d/rc.local -rw-r--r-- 1 root root 556 Jul 29 16:17 /etc/rc.d/rc.local I've mounted backup partition and they were properly set on 8.2. I will make required changes and re-test in the upcoming days, not today. In regards to "other-config:" CLI commands - colon-vs-equals, I will try do dive into this a little deeper and come back with more info.

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

@acebmxer Thank you for your quick feedback.

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.

Hello, You can find all the demo dashboards at the following address: https://github.com/steeve-san/OpenMetrics_XCP_Grafana Regard,

This issue should be fixed in the latest release (to be out today).