Poor transfer rate using Converter 5.0 Standalone compared to 4.3

[rapier55]

I recently started using the newly released Converter 5.0.0 .  I had successfully done over 30 P2V's of Windows 2003 systems using version 4.3.  Immediately, I noticed two problems:

1) The average transfer rate dropped from about 100 MB/s to between 0.8 and 2 MB/s.

2) The process consistently failed following completion of C: drive cloning and starting on the 😧 drive.

I tried this on 5 different physical servers going to 5 different VMware ESXi 4.1 host servers and the result was always the same.  I assumed it was a Network or Firewall problem and sent the Network team on a "wild goose chase" for 2 days.  After they were convinced that the physical machine being P2V'd was simply not sending sufficient packets, I went back and re-installed version 4.3 and restarted the P2V transfer.  This time I received an average transfer rate of 100 MB/s (50x faster) and the entire process completed successfully.

Has anyone else seen a similar problem?  Any possible explanations?

[Troy_Clavell]

I would expect it to be a bit slower if you are aligning partitions, but not that much slower.  If using Converter 5.0, when you get to "Destination Location", can you Edit the "data to copy" and ensure the Advanced option is showing and uncheck the "create optimized partition layout". Ideally you want to align your partitions, if they are not aligned, but for the sake of testing, maybe this is your issue.

[patanassov]

Have a look at this post for how to speed up conversion in 5.0: http://communities.vmware.com/message/1836705#1836705

HTH

Plamen

[ivivanov]

Disk alignment has nothing to do with it. This option is only used while partitioning the target VM disks. After that actual data transfer is going through the same channel, only the target location of the bits inside the VMDK is slightly shifted in order to align data. A more reasonable test looks disabling the SSL encryption over the NFC data channels as suggested by Plamen.

[rapier55]

The only setting I found that seemed related to your suggestion was the following section in the "converter-client.xml" file in the root of the install location.  I changed the <useSsl> entry from "true" to "false", restarted the services and retried.  No difference in transfer rate.  Still about 1/50th normal when using version 4.3.

<ConverterServerConnectionTCP>

   <host>localhost</host>

   <port>443</port>

   <useSsl>false</useSsl>

   <serverPath>/converter/sdk</serverPath>

   <namespace>converter</namespace>

</ConverterServerConnectionTCP>

<ConverterServerConnectionPipe>

   <pipeName>vmware-converter-server-soap</pipeName>

   <useSsl>false</useSsl>

   <serverPath>/converter/sdk</serverPath>

   <namespace>converter</namespace>

   <serviceName>vmware-converter-server</serviceName>

</ConverterServerConnectionPipe>

[ivivanov · Accepted solution]

The file you need to change is converter-worker.xml. It should be located under "%ALLUSERSPROFILE%\Application Data\VMware\VMware vCenter Converter Standalone" folder. You should find the useSsl value under nfc subkey in Config key. If not present, you can add this value like this:

<Config>

   ...

  <nfc>

    <useSsl>false</useSsl>

    ...

  </nfc>

   ...

</Config>

Save the configuration file and restart the VMware vCenter Converter Standalone Worker service.

[rapier55]

Thanks ivivanov,

After changing the correct file and restarting the service, both problems are now resolved. It is performing as well or better than the 4.3 version.

I would highly recommend that VMware make this an option in the GUI whether or not to encrypt the data.  I lost an entire weekend dealing with this issue as well as my network team.

[ivivanov]

Sorry to hear that. We are trying to focus more on security and using SSL on data channels was an attempt to make a step in this direction. Unfortunately it looks there are issues with SSL encryption which we are investigating, however having a 50 (!) times decrease in transfer rate is too much - we have not seen anything that bad. I don't think this option will make it to GUI because of trying to create more secure products. That's why the default value was chosen to turn on the encryption. The only reason to have this option in the config file was to have a way to fix things somehow if anything goes really bad, which seems to be your case. We will keep investigating why such performance degradation is happening instead of the expected 10-20%. Thank you for your feedback.

Regards,

Ivan

[Troy_Clavell]

thanks for the information ivivanov, good to know!

[MMRNOLA]

Hate to dig this up from the grave but I also have an issue with this

Source:

VM

ESX 4

Windows 2008 R2

450GB (2 VMDKs)

FC LUN (4GB)

Destination:

ESXi 5

NetApp NFS

Datastore network = 2x 1 GiGe

VMNetwork = 4x 1 GiGe

Standalone Converter 5 installed on Windows 2008 R2. Server resides on VM located on destination cluster. The server happens to also be the virtual center server if that makes a difference. Conversion is done with source VM powered down.

All ports are 1000/Full

Transfer rate is 14MB/s average

I changed the Converter-worker.xml file that is located here:

C:\ProgramData\VMware\VMware vCenter Converter Standalone

Retarted "VMware vCenter Converter Standalone Worker" service.

Attached is a snippet of the code that was changed.

Any ideas?

[DJRyanJ]

I have a similar setup to MMRNOLA, with the exception that I am coming from an ESX 4.1 infrastructure (either via the vCenter server or not) and my converter machine is a new Server 2008 R2 VM on the NEW vSphere 5 farm.

I'm getting slightly poorer (and in some cases, only 2MB/s max) performance than the 14 MB/s MMRNOLA is getting, but it's still quite poor.

As I have some time sensitive conversions, can anyone provide any further insight, as I have done everything suggested here and had not much luck?

Thanks.

Ryan

[ivivanov]

If you are getting no improvement after editing the converter-worker.xml file and restarting the Worker service, then most likely you are not suffering from the SSL performance issue, but it is something else.

[DJRyanJ]

Thanks; I do see an improvement, just not much of one.

I'm in the process of opening a case with support now to see if we can find a better solution.

[dmanconivifx]

DJRYANJ - Did you ever get a responce from support?

I am thinking of going down the veeam replicator route, and doing the alignment as a secondary exercise due to the speed issues. I ahve made the necessary xml file changes with little benefit, yet using Veeam gives me a substantial increase (55MB/s instead of max 6MB/s) in speed when converting the same systems.

Curious to know if you had any reply from them

Thanks

David

[dockeradz]

I made the above change, turning off ssl support in  the converter-worker.xml file, and my transfer rate when from about 2MB/s to about 15MB/s.  So definetely turn ssl off.

[GRiveros]

Setting UseSSL FALSE make my P2V task from 2 Hr. to 22 Minutes. Thanks all.

[vTagion]

I wrote a blog post yesterday about how to disable SSL automatically. I do enough P2V's that I got tired of doing it all manually. You can find the steps at my blog: http://www.vtagion.com/automatically-disable-ssl-vmware-converter/

Hopefully this will help some of you out. Let me know if this does.

***Note*** you must have write access to the converter-worker.xml file for this to work.

[kopper27]

really nice script BTW this needs to be change even wit the latest converter version?

[vTagion]

Yes,

  The Converter 5.0.1 has the <usessl>true</usessl> as default in the config file.

[UnderCoverGuy]

I know this is an old thread but Converter 5.0.1 b875114 still has the same issue.  By default, SSL is enabled on the Converter in the "converter-worker.xml" file.  When I turned off SSL and restarted the VMware converter worker service, my rate went from 140KB/sec to 45MB/sec.  I wish that VMware would fix this issue (it wasn't like this in previous versions, i.e., 3.5, 4.x).  Even for secure transfers needing SSL, 140KB/sec is unacceptable.

Thanks for the help!!!