There have been many complaints about transfer rate degradation in Converter 5.0.
Converter uses NFC (a proprietary VMware protocol) for cloning to managed destination. Security has been enhanced in Converter 5.0 by encrypting the data transfer. Unfortunately this has caused a more severe performance degradation than expected.
Switching off SSL encryption is a way to work around this issue. Here is how it is done:
I.e. it should look like:
I started a conversion - noticed that it was very very slow.
I then aborted the task - changed the xml and directly after that the problem occured.
Nothing else was done in the mean time
I have changed this XML and restarted the service and still had an average of 14MB/s transfer rate.
I have a source VM totalling 3TB's ( 2x 1.5TB RDMs) that needs to be V2V's over into our new environment which is using NFS datastores.
Source system has FC LUNs (4GB fiber), VMnetwork = 2x 1GiGe and destination has IP based storage (2x 1GiGe) and VMnetwork = 4x 1 GiGe. I have the converter installed on our Virtual Center server on the destination cluster..
I did a test conversion on a VM with a 40GB VMDK and a 400GB VMDK and it took 23 minutes. The 400GB VMDK was empty in regards to data. With this in mind, the weekend outage is not going to be enough time to do the conversion at the current transfer rate so I am trying to see if I can the conversion process throughput closer to 100MB.
If it is V2V and you don't change hardware version, you could bypass Converter. E.g. use scp to copy the files directly between datastores and then attach the VMs. Not sure how fast this will be but I would expected to be faster than converter.
Source EMC AX4-5i and Target EMC AX4-5i
Servers Dell R710 72 GM of memery and 4 Quad Cores.
Sorry, it's a V2V on same host same storage and vConvertor running on same host as well. It's ESXi5 latest version. Source VM running
on AX4-5i LUN and Target Datastore running on same SAN Storage AX4-5i.
Because I got an error while I was migrating it with Storage vMotion. Now half of the LUN resides in this datastore and the second half resides of the original datastore That's why V2V and changing the datastores is the solution.
BUT, V2V is horrible slow don't know why.
Sent via BlackBerry® from Batelco
So I have a pesky server that I need to P2V.
It is a file server with a 63GB C:, 2 x 400GB volumes and an 800GB volume.
The box is HP Proliant ML370 G5 going into and HP EVA4100 running Windows Server 2003 x86. All the networks are 1Gb or better.
I am redcuing the CPUs from 8 to 2 and the NICs from 6 to 1, but other than that all of the settings are default.
I've tried setting the SSL to false but I am still getting "Transfer Rate: 4.79 MB/s" ... maybe as high as 5.22 MB/s.
When we tried this in another office we uninstalled the Conveter 5 and installed Converter 4 and took the job from days to hours. Here we get the same either way.
There are many things that can affect performance, e.g. network connectivity, disk speed, incuding disk fragmentation, heavy usage of the source, etc. The settings of the destination like number of CPUs do not affect performance. If you have had the same results with converter 4.0, it is certainly not the SSL issue either. I would try first to check the stuff described above.