@olivierlambert thanks! Logrotate seems easy enough to understand and adjust if needed. It's the audit and XOA logs that I need help understanding.

@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

@WayneSherman Thanks for this.

@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?

This post specifically: https://xcp-ng.org/forum/post/57441 The person had issues to speak in English but wanted to tell this configuration worked. You can use the xen_wdt backend to rely on a Xen operation to force restart the VM. I have no idea how it works on Windows.

a case for this: have a lot old, disabled vms with some archive data\projects. Probably they will never be used again, but who knows. So i create 1 full backup, but when yet one vm go to archive, i need to run that task for all vms.

@Hightmar Excellent to see, yeah this worked well for me on the 2060 and have been using it on Jellyfin for a while now without any crashes or other odd behavior.

No sure this will be compatible with the level of memory isolation provided in Xen (vs the more "open bar" model in KVM). Worth taking a look though, thanks for the link.

No, it's useless on Linux.

Thanks! I tried the ESC option but could never get it to work. I thing the UEFI is set to 0s waiting time for boot options, which makes it tricky to time it.

@Forza No, it's not possible to add multiple hosts of the same pool to XO.

Indeed, that makes sense now

@mersper Thank you. I will re-think the setup. Having 256 threads in one VM isn't perhaps possible. I have scheduled a meeting with the software manufacturer to talk about network rendering etc. It might be better to have serveral VMs with pinned CPUs and run render jobs. I'll update on the progress