@olivierlambert

Hi Oliver thanks for replying, we are using XOA.

Current version: 5.100.2 - XOA build: 20210823

This was only updated today and unfortunately I am not sure what version we was on, however I have tried another backup of a problematic VM today and got the same error.

Hi All,

I came across a similar topic, which you can find here: Old Topic.

I initially replied to it but decided it would be better to start a new thread. We have several pools, and a few VMs in some pools consistently fail during the full backup with the below error.

In the previous discussion, it was mentioned that rebooting the host resolved the issue. However, I recently performed a rolling pool upgrade on one of our pools, so all nodes were rebooted, and I also rebooted the VMs. Does anyone have any suggestions on what might be causing this problem? I'm considering cloning the problematic VMs, but that seems a bit drastic.

Build: 2024-10-30
Version: 8.2
DBV: 0.0.1

Thank you

Neil

result": {
                "name": "BodyTimeoutError",
                "code": "UND_ERR_BODY_TIMEOUT",
                "message": "Body Timeout Error",
                "stack": "BodyTimeoutError: Body Timeout Error\n    at Timeout.onParserTimeout [as callback] (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/undici/lib/dispatcher/client-h1.js:626:28)\n    at Timeout.onTimeout [as _onTimeout] (/usr/local/lib/node_modules/@xen-orchestra/proxy/node_modules/undici/lib/util/timers.js:22:13)\n    at listOnTimeout (node:internal/timers:569:17)\n    at process.processTimers (node:internal/timers:512:7)"
              }
```.

We realize this is an older issue, but we're experiencing something similar. Last week, I performed a rolling pool update, which involved rebooting all nodes and migrating VMs as part of the process.

Interestingly, the issue consistently affects the same VMs each time. These VMs have the necessary tools installed, and I can't pinpoint why only they are impacted.

We're encountering the same error across multiple pools. All pools use the same backup repositories, but out of approximately 100 VMs, only 3-4 are affected.

i know even more happy hours since the last post haha.

I could clone the VM etc but that seems a bit drastic.

@olivierlambert It's exactly the same - this was deliberate at the time. Much easier to troubleshoot if all your hosts are the same spec!

@olivierlambert I'm currently not sure what's causing it to be slower (and by that much). I've ran other backup tests and I am getting similar results.

Even taking into account the time of day I ran the test vs our normal OOHs backups it's quite a difference.

Switches aren't being anywhere near utilised during the backups (10GBE / 40GB Fibre between hops).

XOA and proxy are up to date "Current version: 5.66.2 - XOA build: 20210823"

Hi all,

Im currently testing the use of a XOA Proxy to utilise remote backups. We'd eventually like to use x2 proxies at various sites for backups.

To test our Proxy is currently in a place where it saves a couple of hops compared to XOA and it traverses all the same networking kit as our XOA.

As you can see from the images below, backing up from our main XOA VM is x3 faster than the proxy.

Both XOA and Proxy have 16GB/8GB RAM respectively and 4 CPUs assigned.

Is there anything I can do to speed up the Proxy/ settings that can be changed etc?

Cheers
Andrew