Any reason for painfully slow transfer rates with VMWare Converter?

[fq13]

By now I have been through several P2V and one V2V conversion using the VMWare converter 5.0, 5.1 and now 5.5 and all have suffered from very slow transfer rates. On 5.0 and 5.1 I have disabled SSL Encryption and while doing a local P2V from the physical machine or a P2V from a remote machine (all on a Gigabit LAN network) I have seen slow transfer rates of maybe 5 MB/s.

And now doing a V2V using 5.5, I am moving a VM from internal storage onto a SAN, I am seeing average of 2MB/sec transfer rates. This is with SSL enabled. And I am converting a 1.6TB VMDK (windows 2008) that has only 480GB used. For this particular V2V, I had to resize the volume and make it a thin from thick, so I realize a slower file level copy is taking place instead of a block level or volume level. But are these transfer rates "normal"?

Thanks for any and all feedback in advance.

[POCEH]

Do the following test: start conversion with block level and then share what the speed is.

As workaround you can transfer at block-level and then resize the disk from OS.

HTH

[fq13]

Thanks for your response. One issue is that on the destination storage I didn't have 1.6TB available, so I had to resize the volume. Though for a 100MB system volume it copied at block level, that finished in 8 seconds according to the Converter log. For future reference though, how would I transfer resize the disk from OS in a way that it would it also decrease the size of the thick provisioned VMDK?

Also, my understanding is that when changing the size of a volume, the Converter will have to do a file-level copy. Please do correct me if I am wrong. I am really interested in seeing if there a way to speed this up.

Thanks!

[POCEH]

If you start your task with 'thin' disk, you'll not be stopped to start conversion - wait to see the transfer rate for few percent and then cancel the task.

You are correct about Converter view of disk resize, but if you optimize your disk, then you can decrease partition type from OS (use DiskManager to shrink the volume size). Then you should use some of vmware-toolsXX to shrink the size of VMDK. With such big disk I'll say that transfer speed is lowered because files are read one-by-one and written one-by-one, that's because there is a warning about this type of transfer.

[Aiden1]

Hi

Welcome to the communities.

Did you checked by disabling SSL ?

http://pubs.vmware.com/orchestrator-plugins/topic/com.vmware.using.soap.plugin.doc_10/GUID-3AF0A20C-...

Confidence is preparation. Everything else is beyond your control

[fq13]

@ POCEH: Thanks. I had read on many posts here that using the Converter would be the recommended method for resizing an existing VMDK file. Unfortunately I couldn't find any official VMWare documentation on what methods are recommended for shrinking a VMDK. Now the V2V process actually completed after 2.5 days and the server is running good so far! When you say there is a warning about this type of transfer, what do you mean? It's not recommended?

@Aiden1, thanks. I had SSL disabled a P2V conversions I did and it did help maybe 10% but it wasn't much. I saw a 45min be cut down by 10 mins or so. On a V2V I just did, I left the SSL enabled since the format of the worker agent xml looked different than in 5.1 so I didn't want to risk breaking anything.

[A13xxx]

Had similar problems on my travels too, did you check the resources / processes running on the machine when converting? Is it maxing out or not doing much?

Are you standalone or Server/Client?

Have you tried to move the VM to the SAN and then do a V2V on the SAN

[POCEH]

If you sure that your thin disk will not grow dramatically you can leave it with original size 1TB+ and don't worry because disk will use current size of 500GB..

If you want to fix disk's size you should SSH to ESX and see vmkfstools tool for this, or just google it