Converter 3.0.1 V2V poor performance

[Garfied]

After some successful and fast P2V convertion we try a V2V convertion. The goal is to replicate an existing VM and extend the disks size (C: 8 to 18GB, 😧 22 to 32 Gb). The source VM is on a LUN and the destination selected is another LUN. At the moment the import is running and after 20 hour is still at 54%.

On the Host network traffic is low and so the disk activity. Am i missing something? Our farm is running on Dell 6850 with Qlogic HBA.

Thanks!

[BFD]

Hi Garfied,

I've had some joy with V2V conversions. I've had 2 concurrent conversions of machines (8GB C:\ only) running from the same source ESX 2.5.4 server to the same target VI3 server with one set to go up to 12 GB and one down to 5 GB and they completed in 26 minutes and 44 minutes respectively. This is using Qlogic cards in IBM servers - a very old source and a very modern target.

However, I now run in to slow performance using the same source VM on the same source server, using the same target and the same machine running the same version of VMConverter (3.0.1 enterprise edition build 44840). Yesterday a conversion of the same 8GB vmdk from a 50GB datastore with nothing else in it to a VI3 server in a cluster attached to a 200 GB VMFS 3 datastore with 160 GB free space took just over 10 hours.

I'm wondering what I am missing now too!

Based on the initial conversion speeds, I was hoping to use converter rather than Dmotion to move most VMs into VI3 as it retains my source VM (easy backout plan) and we want to change the network names for VI3. If I am down at under a gig an hour then converting any file or database servers is somewhat impractical!

Does anyone have any suggestions for Garfied and I?

Thanks!

[w00ten]

You guys seem to have it good, you just have extremely poor performance. Not only do I have that, mine fails consistently at the end of the conversion. our images use 15GB disks with about 3-4 gigs actually used and I am looking between 10 and 20 hours to do a conversion. Usually about hour 18 or 19, it just says it failed with an unknown error. P2V is a bit better. It's failing at 2% after about 1-1.5 hours. Nice to know I'm not the only one.

[Garfied]

Update:

the job was completed with success. Looking at the log (vmlog-client) i found this recurrent block:

2007-10-03 17:15:46.030 'App' 4068 verbose Successfully connected to VmiImportTask::task 2007-10-03 17:15:46.046 'App' 4068 verbose Start managed object method for task VmiImportTask::task

2007-10-03 17:15:46.046 'App' 4068 verbose Waiting for updates from VmiImportTask::task 2007-10-03 17:15:46.046 'App' 4068 verbose (Re)Start waiting for property updates from VmiImportTask::task

2007-10-03 17:15:46.046 'App' 5820 verbose Got an update from VmiImportTask::task

2007-10-03 17:15:46.062 'P2V' 4068 verbose Raising event 4 for job 6

8-10 minutes cycles for 24h (on a total of 25h).

Could anyone give me some info about this log?

Thanks!

Edit I try to paste the plain text from log file but i could not completely correct the text formating problem.

[tlwilson]

I have the same problem! We had successfully P2V prior to upgrading to 3.0.1 but since then the P2V process has become extremely slow. I just did a V2V yesterday to increase the disk size of the VM. It took about 15 hrs. Initially I tried the V2V from one ESX 3.0.2 to another ESX 3.0.2 using Virtual Center as the source from another PC.. It was crawling. I canceled and restarted using Converter installed on the VC server and used the same ESX 3.0.2 as the source and destination, but going to different LUN's. We have many servers to consolidate, hope we can find a resolution soon.

Any advice?

[Garfied]

Update:

I talked to a SE in Vmware Italy and the only answer i got is "open a SR".

i'm compiling the form right now...

[w00ten]

Don't bother. I've done it and their response is that they don't give any guaruntee on performance for converter and it can take a long time. Completely unacceptable under the circumstances, but that appears to be their stance. The fact that it consistently fails with the super slow performance apparently means our network is slow... but I'm on the same segment as the ESX server(its a 10 second walk from my desk) and there is only 2 switches between this PC and the servers/storage, and the transfer is being done on a saturday when I'm the only one on the LAN in the entire building and can transfer files to the storage through windows in 10 minutes. Sounds ridiculous, but that's the answer I got.

[Garfied]

The averange traffic load generated by the process is under the mbit... and the segment is less than 30% loaded.

In some of documentation I read that resizing disk change the copy mode used by converter. The problem seems be that this copy mode is sloooowwwww. The same server that cold converted with disk resize is slow is really fast if hot coverted without disk resize.

[pasoboble]

Hi, what about the disk to disk process versus the file to file convertion (in time)? I mean, you can resize your vmdk file after the convertion (vmkfstools -X etc...). Try to stop all active and running process like antivirux and so on. Thanks for updates

[Garfied]

vmkfstools permit to extend disk size but not to shrink. I'm working on P2V consolidation and SAN disk storage could not be wasted. Time difference between Hot convertion without disk resize: 45 minutes, Cold convertion with disk resize: 72 hours +