@bleader said in update via yum or via xoa?: yes you're basically doing an RPU manually. But it is indeed odd that the process is stuck at 0%, it should be fairly fast to do the install patches, no errors in the logs? i've another install all patches and install all. Now i'll use rpm update and see if speed is the same or not

Hello, can you please try the buffered-task-events branch and let me know if that solves the issue?

Thanks for your feedback!

@robyt Can you post a screenshot of where you see NBD? I don't see it anywhere in mine but I'm not sure if I'm looking at the right place. I think you need to get things working first and then start trying to push the envelop. I would set it to 1 and see what your speeds look like. Then you can slowly increase the number of connections until you stop seeing speed increases and/or you see http connection timeouts. I'll admit that I haven't been paying attention to the whole thread, but I'm not sure what more testing you feel you need in order to determine that the problem is your NAS. What is the goal you're attempting to achieve that you're concerned that different hardware wouldn't solve? I'm not sure what your configuration is (if you've posted it already, my apologies), but posting your XCP-ng host(s) details, XO specs, QNAP specs, and what other duties, if any, the QNAP is performing, that would be helpful. They make some powerful models, but most of them don't have that much oomph and can really only do one, maybe two things at once. And this goes doubly so if you're using very large VM disks instead of network storage. In my case I'm backing up to a fairly beefy TrueNAS running a 11z3 setup on a 10G network. My VMs are all configured with smallish disks and pull the majority of their data from the same NAS. My biggest bottleneck is that my XCP-ng hosts only have 2.5G NICs which is why I'm considering moving XO to something with 10G in order to support the fully bandwidth.

@olivierlambert said in In delta backup force the full backup task in a specific day: Block mode with NBD enabled? That sounds too slow, especially for a first backup (which will be full and won't require any merge) [image: 1706278573918-0e57de89-11e1-4a42-a34c-162d4151f754-immagine.png] is locked to 37%... ho i can stop the backup job without damage old backups?

@robyt It depends on (1) licensing, if any, as some licenses go by cores vs. sockets, and (2) NUMA/VNUMA depending on how critical the performance is depending on how the VCPUs get allocated between sockets or on a single socket. Best way IMO is to try all and test with benchmarks. See, for example, this article and the previous two articles, as well as articles by Frank Denneman and others: https://blogs.mycugc.org/2019/04/30/a-tale-of-two-servers-part-3-the-influence-of-numa-cpus-and-sockets-cores-persocket-plus-other-vm-settings-on-apps-and-gpu-performance/

@robyt nice catch We use compression when selecting block based backup (by default brotli), that brings a 20-50% storage reduction depending on the data PR is here https://github.com/vatesfr/xen-orchestra/pull/6865 and will be merged before may release fbeauchamp opened this pull request in vatesfr/xen-orchestra closed fix(xo-web): VHD directory tooltip #6865

Depends on the load, mostly when doing backups, if you backup 20+ VMs, 4vCPUs is better.

@robyt There are no logs at this time (unless executed as part of a backup), only a notification at the end of the execution. We are currently working on a global task/log system that will be used throughout XO (Restore Health Check is obviously on our todo list)

That would be nice if you open a support ticket with a support tunnel so we can take a look remotely

If you use XOA, I would strongly suggest to open a support ticket. This way, we can investigate properly on your XOA and see what's going on.