File upload through Gateway very slow

File upload through Gateway very slow

avatar

Hi,

We use Devolutions Gateway between all our components including access to vCenter. When we need to upload an ova or iso to vCenter the upload process is very, very slow. Uploading a few gb takes several hours. When we connect without gateway it's much, much faster.

Is this a known issue and is there something we can do to speed this up?

All Comments (7)

avatar

Hello

In the past we've had at least two reports of the same problem and, interestingly, all of them relate directly to VMWare (vSphare and / or esxi).

When we've looked into it previously we were not able to recreate the issue; but clearly something is going on here when talking to VMWare.

I will ask that we reopen our internal investigation into that; but it would certainly be helpful if you could describe your environment in a little more detail:

  • Relevant versions of the Devolutions stack you are using (Gateway, Devolutions Server, RDM, etc)
  • Relevant versions of the VMWare components you are using
  • Any particular network details (a description of the environment); particularly if there are intervening network hardware or software tools involved (like other proxies, firewalls, VPNs)
  • Do you notice the same issue with other sites or services, or it seems isolated to VMWare? Or perhaps, this is the only place the problems comes up if you are not doing very large file uploads with other services.


Please, let me know if something isn't clear or you have further questions

Kind regards,

Richard Markievicz

avatar

Hi Richard,

At the moment we only notice it when sending "lare" files to vcenter, so I think we can relate it to this specific case.

We use the following versions:

Remote Desktop Manager 2025.2.25.0
Devolutions Server 2025.2.8.0
Devolutions Gateway 2025.2.3

vCenter 8.0.3

If there is anything we can test or help to get this problem solved, please let me know.

avatar

Hello

Can you let me know where exactly in vCenter you're doing the uploads? Is it to a datastore, or somewhere else?

Thanks and kind regards,

Richard Markievicz

avatar

Hi Richard,

The upload happens most of the time when you select Deploy OVF template.

avatar

Hello

Broadly when I made a sanity test on my side, I didn't notice much of a different uploading a large file via the web to MS Azure. Going via Gateway is a little slower; which is normal (instead of browser -> ESXi; we're going Browser > SOCKS Proxy > jetsocat.exe > JMUX -> Devolutions Gateway > ESXi); but in the two existing tickets we had the customer reported a 50x slowdown in this scenario (and your results sound similar).

I wonder if this is something specific to OVF deployment, and I'll re-open the investigation ticket on our side to try and evaluate that. Unfortunately the dev and QA teams do not have access to the OVF tools in our vCenter so this is something that requires a bit of coordination internally. Although, I would be surprised if this is specific to OVF because as far as I can tell, when it pushes the actual blobs it's just using HTTP POST; no custom VMWare / Broadcom magic.

From your side, is there a lot of variability when using (for example) Cloudflare Speediest over the Gateway versus without it? It's also using HTTP POST to test the upload as far as I can tell. I'd like to narrow this down as something VMWare / OVF specific.

Thanks and kind regards,

Richard Markievicz

avatar

I did the Cloudflare speedtest with and without gateway. Both gave the same result so it seems it's related to vcenter in combination with the gateway.

avatar

Hello

I think it's specifically related to OVF deployment. If you just upload an arbitrary file to a data store on vCenter, is it slower? Our tests show that it is, but not significantly so (and expected due to the extra layers of indirection).

VMWare / Broadcom's documentation for the standalone OVF tool has a "highlight": "Uses new optimized upload and download API (optimized for vSphere 4.0 and newer)" which suggest to me they are doing something special in this case, which might have characteristics that don't work well (currently) with Devolutions Gateway.

I'm asking our QA team to re-open the investigation here and focus specifically on image deployment to see if we can reproduce and understand the traffic. I don't expect this to happen quickly because it requires significant involvement from our IT team.

In the meantime, I have a suggestion which might help or at least provide an additional data point. You could try using the standalone OVF Tool for image deployment. The documentation says that it allow you to specific a proxy. For the proxy you could create a Devolutions Gateway Tunnel session type in RDM and launch it, then point OVF Tool at the tunnel local address. It would be interesting to know if this works better or the result is broadly the same.

Thanks and kind regards,

Richard Markievicz