Backup throughput slow on HyperV vs VMware

[EdgarRicharte]

Hello,

We originally were VMware infrastructure. We are in the process of converting all our VMware to HyperV. So we currently have both. But I notice that my new backup jobs that are HyperV are so much slower than my VMware. I was getting 120+ MB/s throughput on VMware backup jobs. But with HyperV I'm lucky if I get 40MB/s. Both pointed to the same repo that is the local F drive on the VB&R server. VB&R is still in VMware environment and will probably be the last to be converted over. Does veeam need to be in our HyperV environment or is there a way to allow this to speed up. The backup repo is the local F drive on the VB&R server.

VB&R running latest version 9.5 update 4b
Server OS 2016 fully patched
SCVMM 2019

Has anyone done the same thing? Let me know if I'm missing any info. Any help is appreciated.

[soncscy]

Hi Edgar,

If I had a guess, it's how the data is being fetched; the architecture for a VMware and HyperV backup environment is starkly different since in VMware you can have chosen proxies, while in HyperV you get two options: On hosts directly or Off-Host with direct connection to the SAN environment.

I would imagine on VMware you probably used Hotadd, perhaps, and it was just pretty seamless, and with HyperV you're using On-Host, so you're gated by the Host Performance.

If you really think it's about being between the two environments, then just fire up iperf on one of the hosts and the repository server and run extended testing, but I bet you the network is probably fine.

What does your bottleneck say for the job? It's usually pretty good to tell you were to look

[EdgarRicharte]

11/25/2019 9:39:12 AM :: Busy: Source 58% > Proxy 2% > Network 42% > Target 12%

Majority of them have network in the 40%

We do Hotadd for VMware.

Seems that the incrementals do run a bit faster for HyperV jobs. These are new hosts that we purchased for the hyperV conversions. So maybe wait until veeam is converted over? And see if the performance is still slower?

[soncscy]

Well, just off the cuff, seems like the network is your major issue. I know that source is higher, but all these values are relative; when I see high network values, I look at the network between the source proxy (the Hosts in this case) and the target Repository Server (whatever is writing to the repository)

That iperf test I mentioned is likely going to help here. Run it from the host to whatever is your repository server.

[PetrM]

Hello!

11/25/2019 9:39:12 AM :: Busy: Source 58% > Proxy 2% > Network 42% > Target 12%

Does this statistics correspond to full or to incremental run?
It's always better to examine full run statistics to exclude possible additional random read which might occur during incremental runs and affect data read speed from source.

This statistics says that the slowest processing stage is the retrieving data from source storage.
I'd expect that job speed would remain the same even if you managed to optimize network:
the overall job processing rate can not be higher than the processing rate of the slowest stage ("Source" in our case).

On the other hand, this statistics allows us to assume that the bottleneck would be shifted to "Network" (it becomes the slowest stage) if data read speed
from source storage became significantly higher ("Source" is no longer a bottleneck).

Any chance to check job performance in the off-host mode?

Thanks!

[EdgarRicharte]

Just update. We ended up adding additional NIC's to the hyperV hosts that allowed Veeam to access them locally. We locked it down pretty good. The load remained roughly the same. But the throughput is now about 250+MB/s. Which is on par with VMware. So I think we are good. Thank you guys for the suggestions.