2

I have a question about my test lab. It's more to understand the concept more than apply this into production:

I have an ESXi with few VMs linux/windows configured and I'd like to use VMWare converter to create backups.

To speedup the process I decided to create a Windows VM on the same ESXi host where I've installed Windows 7 and VMWare Converter.

The Host has a gigabit card but it's currently connected to a 100Mb FD port. Windows 7 sees a 1gb card connected.

When I do the backup using VMWare converter I specify the host IP as source and destination, so I thought the copy could be faster then use my laptop across the network.

Well, to cut a long sotry short: I get dreadful performance (4Mb/sec). I'm a buit confused on this because despite the fact that the host is running 100Mb communication between VMs and hosts shouldn't (correct me if I'm wrong) have any limitation instead.

I did tweak windows 7 to optimise network performane but I got just a little improvement. i still need 4 hours to back up a 50Gb (thin) VM.

Additionally I wanted to ask: Would jumbo frame help in this? I know that jumbo frame have to be supported end to end, and the network switch where the host is currently connected doesn't support this, but I was wondering:

1) Does ESXi host support jumbo frames at all?

2) Can I enable it somehow?

3) If I do so, I guess bulk transfert between VMs and host would improve, but would this affect the communication going through the real switch as this doesn't do jumbo?

Thanks for reading

2 Answers 2

1

Jumbo frames may make some difference but your throughput problems indicate a much more severe issue. You can enable Jumbo frames in ESXi but it requires the use of the vCLI command line tools - you can find specific instructions in this VMware ESXi config document.

There are some possible causes.

You might have your data going in and out of the ESXi host - in that case Converter would be copying the data from within the VM in the ESXi host back to the Management Interface via your physical network. Given that it's a 100Megabit uplink I'd still expect you to get a couple of Megabytes/sec rather than the 4Megabit/sec you report.

Your ESX host NICs might not actually be negotiating the 100Mbps/Full duplex settings correctly with the switch - make sure both the switch and the pNIC settings on your ESXi host are set correctly.

Converter isn't terribly efficient in terms of throughput but if you are using block based disk copying (rather than file level) it is OK (transfer rate will be >50% of the link bandwidth's maximum - say 4 Meg/sec on a 100Mbps network, 40Meg/sec on GigE). If your copy is using file level copying then things will be a lot slower.

All of this activity is putting a fair amount of additional load on the disk subsystem your VM's are stored on. If you are running all of this off fairly slow storage (say a handful of SATA drives in RAID 5) then it's possible that the disk is thrashing but for a healthy storage setup this sort of thing shouldn't be a stress.

I think the problem is with your virtual networking though - assuming that it is you should consider the following:

If your ESXi Management Port is on the same virtual switch as your VM's production network port group then the traffic should loop back internally within the Virtual Switch. If that's not happening then I'd start checking whether VLAN's are configured on the ports\port groups or check whether your ip-addressing is causing the traffic to think it has to exit the switch before coming back in (e.g. if you have the Management port on a different subnet to the VM Network and are relying on an external router to allow them to communicate). If you suspect that your network isn't doing the above correctly then you can put the Source and target VM's on the same subnet as the management port and connect them to a VM Port Group on the same vSwitch as the Management port then you should get traffic between the various systems (the source, the converter VM and the ESX host) to remain within the confines of the vSwitch. Move the VM port groups rather than messing with the Management port - if you make a mistake with that you'll have to go back to the ESXi's physical console to fix things and it's best to avoid taking any risks with that.

Also shut down as much as you can before you start just in case something like a Backup process is hogging all the Management port network bandwidth etc.

0

Switching off SSL encryption is a way to work around this issue. Here is how it is done:

Open the converter-worker.xml configuration file. It is located in

"%ALLUSERSPROFILE%\VMware\VMware vCenter Converter Standalone"

folder for Windows Vista or newer or in

"%ALLUSERSPROFILE%\Application Data\VMware\VMware vCenter Converter Standalone"

for older Windows versions.

Set the key Config/nfc/useSsl to false and save the configuration file.
Restart "VMware vCenter Converter Standalone Worker" service.

I.e. it should look like:

...
<nfc>
   <readTimeoutMs>120000</readTimeoutMs>
   <useSsl>false</useSsl>
...

"Restart "VMware vCenter Converter Standalone Worker" service."

You must log in to answer this question.