I confirm that this is the current behaviour, as @pilow reported here https://xcp-ng.org/forum/post/99446 We might change it in the future to make it better, but it won't be trivial to change.

@Forza you will have to switch to LATEST to profit from end month release STABLE is one version behind LATEST both are production ready.

@Forza Cancelling a backup run is also on our roadmap ,as soon as we have done reworking the tasks to use xo-task on the full chain, and not an hybrid of various iteration of the tasks objects better tracking of the backup run is also on our roadmap , this is also linked to the task changes plus are some issues with the size on the remote before being able to do this In any case, both are on our backlog

@Forza I keep hoping to see an Alpha or Beta of XCP-ng 9 soon, but I think there is still a lot of work to be done on the host side and on the Xen Orchestra 6 side.

\o/

@olivierlambert said in Migrating logs and history between XOA instances?: Hi, VM stats aren't store on XOA but on your pools, and they should be there with the same history as the old one Can you tell exactly what kind of logs are you talking about? Thanks. I had looked on the wrong VM. The stats are indeed retained. Originally I was thinking of audit logs, but I realized they can be exported and imported. So for m point of view it is enough for now. Other logs that are missing is for example backup logs.

@thomas-dkmt we might need to make sure XO docs tell how system updates are handled and proxy config

It might record the max static RAM (IDK)

I would like to suggest to configure a remote syslog server. it centralizes all the log s and give you full control over the retention. It would also avoid situation where a disk full would impact your logging as well XCP-ng or XOA host operations. For your XCP-NG host go to you POOl, select Advanced tab and configure the Remote syslog host section to point to your syslog server. For XOA, you can follow the instruction here : https://docs.xen-orchestra.com/backups#send-xo-logs-to-an-external-syslog-server

@dinhngtu Yes, looks like it. I stopped Netdata and the problem went away. But it is strange it started after the latest set of updates.

@olivierlambert @DustinB @Forza May I suggest that it goes a bit further, unless it already does so. Can the VMs in Xen Orchestra show if it was backed up successfully in the most recent job. As well as when it was last backed up, if you happen to not have the report yet (or read it) you can see at a glance. That way it makes decoding the orange status for the backup job easier, so you know which ones you need to do a backup job run for. Alternatively show which ones failed and were successful, when you get the details for the job (task) in Xen Orchestra following an orange status on Xen Orchestra 6.

Maybe the IO scheduler is not the right one?

Hi Indeed. We will see how we can fix this bug. Thanks

Hi Forza, Have you finished migrating the workloads? If you are still looking for an easy migration solution, you can try Vinchin Backup & Recovery. It will replace the driver during migration intelligently.

@olivierlambert thanks. I'll read through the documentation and maybe contact support about this.

@julien-f said in Feat: Improvements to the VM statistics page:: Yes, I've noted this for XO6 Great. Thanks Now we just need a XO 6.0 release

XO does not pause backups during upgrades/restart, all currently running backups will be interrupted as @olivierlambert said. An interrupted backup is not a big problem by itself, nothing will be broken, and the next run will run properly. Backups are only run at the time they are scheduled, if XO is offline at this time, it will not automatically run them when restarted, it will wait for the next scheduled run.

@manilx 2 more and yes seems to be confusing and just to round it up. Same VM as above Delta (full) backup using NBD without and with "nconnect=6" in the remote setting: [image: 1714397312022-screenshot-2024-04-29-at-14.27.19.png] with nconnect=6 [image: 1714397346566-screenshot-2024-04-29-at-14.28.57.png] nconnect=6 doesn't seem to do a lot.

I re-checked again but the issue is unfortunately not resolved. It does not happen on all VMs and files, so maybe there is something wrong somehow in the VDI?