Vmware Converter Extremly Slow

[Jorgen_J]

In the past year i have done around 100 P2V migrations. The common factor I have discovered is that for each release of the Vmware Converter tool it gets slower and slower. The last 10-15 migrations with the 2 latest releases have been awful. Last conversion was a server standing on GB Lan and the server was fairly new. we where going to migrate around 30GB and after 1 hour still standing on 2% we aborted. and tried an erlier release. no changes. then we tried to run with symantec ghost 500-600 MB/min.. this i can live with, but running Vmware Converter Enterprise (coldboot cd) we are getting speeds around 10-50kb/s.. is there any one else with the same problem. I think It suxx that we spend alot of money on a Enterprise solution and the Convertion products only gets worse and worse. we have tried everything to rule out an configuration error. the setup was the following.

1 HP C7000 Blade chassie

6 HP BL460c G1 (2xQuadcore, dual fiberchannel mezzine, 6Nics (VLAN conf)

1 EVA4100 SAN

2 Brocade Fiberwitches

Cisco 6500 with 2 GBit blades for the vmware environment for redundant LAN

We have the server that we are going to migrate on the 6500 so there isn't any network problem.

The problem isn't bound to any hardware vendor. we have tried HP, Dell, IBM machines to migrate newer and older.

on the older servers the ghost only gets 500-600 on the newer ghost can run up to 1300MB/min

can anyone explaine this ?????

Regards Jörgen

Linux is like a wigwam. It has no Windows or Gates and it got Apache inside.

[jaganpjames]

have you tried with changing the port speed on the source box, from auto negotiate to 1000Meg full duplex.

[Jorgen_J]

Yes i have. I have tried 1000Mbit - 1000Mbit full duplex, autoneg - autoneg and in both cases i have confirmed that the connection speed have been 1000Mbit Full Duplex. as a test i have tried sending a 1024MB file from the server im going to migrate to an virtual machine. it took around 21 seconds witch is around 380Mbit/s and i think thats good enough, but still migration with Vmware converter cant get any speed. Migrating a server with around 100GB Data shouldn't take 24 hours that's unacceptable when i can migrate the server with Bart PE Ghost Cd in 3 hours. please Vmware employes explain this.

Linux is like a wigwam. It has no Windows or Gates and it got Apache inside.

[ryanbirk]

I am running into the same issue tonight...err cough, now this morning. My team and I are migrating several VM's from various GSX boxes and it is VERY slow. I am running 3.0.2u1 build-62456.

I have 2 GSX boxes running the converter console and have it set to two active connections, with about 6 other VM's in queue.

They normally never take this long (4-6hours/vm. 6GB and 13GB disks/vm.)

I'll be bookmarking this in hopes of a solution.

[powellwi]

I am in the same boat it seems very slow. Converter v3.0.2u1

Source: 13gb sys volume (W2k3 sp2 all patches), 1000baseT copper, 8gb data volume (reduced during configuration from 121gb)

In 3+ hours it has transfered 14gb to target but converter screen says 1%

Interesting

Any info would be helpful, first time I have tried this version of converter.

Thanks

[Maduro]

I'm using v3.0.2 build-59994. I was trying to convert a 6 GB Windows XP VM sitting on a Dell 1950 over to a VMware Server-compatible version. I had tried over-the-network (slow) and even pointing to a different destination partition on the same server (just as slow). I left this last process running overnight only to find that it's only at 36% and still has over 26 hrs. to go...!? However, each percentage drop resulted in about one hour less of End Time, so it looks like it might end up sooner after all.

The above was a little bizarre and the only common elements between the two scenarios were the network and my laptop running the Converter tool. I checked my laptop's Task Manager > Networking activity and realized that it was running at full capacity. I double-checked the Converter's functional architecture at:

http://www.vmware.com/pdf/VMware_Converter_manual302.pdf

page 10, and realized that my laptop was working as a mid-level intermediary or forwarder (at least that's what the diagram suggests and what my laptop's network activity tended to show). I installed the Converter tool on the physical box containing the originating files and converted the VM in about 10 minutes.

So, it looks like the bottleneck was simply using my network in the first place for the conversion, even when the file host and target where the same, and the Converter's intermediary role.

Message was edited by: Maduro

[M_Patryl]

I had the same problem, so I played around with the tool for a bit. I can only speak for the offline (CD boot) version of the tool, but I found the biggest difference was to not directly clone the disks, but to resize them. Even resizing by 1GB makes a world of difference - from the performance graphs, it looks like when you tell Converter that you want to resize, some of the work is offloaded to the Host and there's less data that doesn't actually contain anything sent over the wire.

A few examples (these are all averages of two separate tests, both source and VMware Host were on the same dedicated Gbit Cu switch)...

Converting a machine with two disks (C: 33.89GB total, 7.52GB used and D: 683.51GB total, 282.35GB used) took the following:

4:53:26 to do a direct clone, and 4:05:21 when resizing the disks down by 1GB each (and I kept the hibernation/page file).

That's almost an hour chopped off. If you have less data on the disk, the results are even more dramatic. Converting a machine with two disks (C: 33.89GB total, 5.43GB used and D: 683.51GB total, 25.7GB used) took the following:

4:47:58 to do a direct clone, and 0:24:05 when resizing the disks down by 1GB each (and again, kept the hibernation/page files).

I was kind of gobsmacked to see the difference there, but even when resizing UP, it's still faster than a direct clone.

So... if you have the opportunity and the disks you're migrating from aren't completely full, try resizing - it may help.

Good luck!

[Vodder]

I've have to do this tonight :| from GSX to ESX 3.5. I did a test on Monday, using a VM with a 20GB "growable" drive and a 8GB "flat" drive which would both obviously become fixed size on ESX. Only the 20GB drive had 5GB of actual data. The migration took 15 minutes!

The one I have tonight is a 20GB drive with 13.6GB free and a 72GB drive with just 2.6GB free. I'm not going to resize them as I'm a little worried about data loss or corruption. Have you had / seen any issues with this or is there a minimum amount of free space you need on the drive being resized? I presume if you did resize them on migration they could be expanded again once in ESX?

[M_Patryl]

I haven't personally had any problems with data corruption whilst resizing disks - up or down. There is a minimum disk size on the destination that Converter needs, but I haven't seen it have a requirement for a minimum amount of free space on the source disks. There may be something on it in the docs, but I'm not sure.

As for resizing after migration, I've been playing around with that exact thing. My guest OSes have been Standard and Enterprise 2003 (host is ESX 3.5 w/update 1), and I've seen no problem (so far) with running Diskpart after using the offline Converter to expand the disk to where I want it to be. It's a lot faster doing it that way than telling Converter to resize up. I know I said in my earlier post that resizing up is faster than a direct clone, but it doesn't seem to scale well and beyond a certain point it gets horribly slow again. So if speed is a concern, I think your best bet is to resize down even a little if you can, then use Infrastructure Client to make the disk bigger and run Diskpart afterwards.

I totally understand your concerns about data corruption though (people pay me to be paranoid), but I don't think Converter does anything to the filesystem on the source disks - if the conversion failed horribly, you should still have your original data to fall back on.

Good luck with the work!

[Vodder]

Hi,

Well the conversion went to plan! The one on Wednesday night started at 17:40 and finished by 22:30! I then expected Thursday's to be fast as although it was the same size it had 40GB free on its 2nd partition rather than only 2GB and low and behold it completed 2 hours faster!!!

I've now persauded the business owner to allow me to do the disk resize as our next one has a 199GB partition but only using 2GB of space, he's also agreed that it'll never use that much and to shrink it to 50GB! Which has just gained me the difference on my SAN for the other VM's!! :smileylaugh:

[theanykey]

File-level clones are always slower - especially if the source is heavily fragmented. Also factor in the age of technology used on the source machine.

• Disk-based Block-Level (Disk-based)*

This method of cloning is enabled when you choose to import all disks without selecting/resizing volumes. In this mode the disks are copied to the destination block by block. This method is the least likely to fail due to volume structure. If cloning with one of the other methods fail try getting a disk based clone which can then be used by developers for troubleshooting the bug.

This option is not available when doing Hot Clones (local or remote).

• Volume-based Block-Level (Volume-based)*

This method of cloning is enabled when you choose to import all or a subset of volumes without resizing them. In this method, we examine the source partition to determine what the partition boundaries are on-disk and then copy just the selected partitions on to the target disk on a block-by-block basis. The partition order may not always be preserved in the target VM (especially if there are diagnostic partitions in the source). This means that Post-cloning related issues are more likely to show up here.

Non-windows VMs cloned with volume-based cloning are almost guaranteed to not be able to boot.

• Volume-based File-Level (File-level)*

This method of cloning is enabled when you select one or more volumes for cloning and resize any one of them. Here, converter creates the target disk, partitions and formats it appropriately and copies over data from the source to the target on a file-by-file basis.

Resizing the disk smaller in size will force a file-level clone

With respect to 3.0.3, we can now identify bad disks and unlike early versions, we have a new method of tackling the issue (platformerror fault 23). Generally speaking, we convert in 64k blocks. If there was a bad sector within that block the conversion would fail. We now identify a bad block, go back to the beginning of that block and run the cloning process sector-by-sector for that flagged block. This process will slow down the cloning process considerably but instead of failing, your dying disk will convert.

[tzfan]

Hi, I am very curious the following few things. 1) How long did it take you to complete the conversion? 2) After convert is done, did you experience any problem or issue to power on the resultant VM? 3) what was the size of the VM (or physical machine) before you did the conversion? Thank you.

[Vodder]

Hi tzfan - who you refering your questions to? If it's me the answers are in my last post and no I didn't have any issues or problems with the converted VM. Hope I haven't just cursed my future migrations! :smileyhappy:

[tzfan]

Hi, Thanks for the response. I acutally wanted to know if Jorgen J has issue after the VM convesion is done. Thanks.

[Ravi_T]

I came looking for this same problem here. In a way releived to find out I am not the olnly one cursing in despair, but also disappointed that there seems to be no solution. After wasting about 6 hours, watchin it move from 1 to 26% for a 30 G drive in that amount of time, I have finally given up on it.

VMWare converter is a piece of crap and a joke.VMWare should look into this.

[continuum]

VMWare converter is a piece of crap and a joke.

Nope - thats not true - the problem with Converter is that folks think they can use it to replace Ghost or Acronis or whatever.

Fact is : Converter is unreliable compared with Ghost for example.

So in a usage scenario like yours when you want to import a 30 Gb system I would use ghost for the imaging part of the import and use Converter just to patch the drivers later on.

I would never wait 6 hours for Converter ...

___________________________________

description of vmx-parameters:

VMware-liveCD:

[Ravi_T]

Ok..I take back the 'piece of crap' tag. It is in fact a very good tool, too bad

I discovered it too late. You need to actually install it in the VM itself. Then choose

the source as the Physical server (the VM) and dump it in the same ESX server

as a clone. This works like a piece of art..But the problem still remains in the OS

level as Windows 2003 does not support Partition magic, and DiskPart just did not

work for me. Any suggestion to merge the unpartitioned, extended disk space to the

existing disk? Mine are all basic, not dynamic.

[continuum]

Ravi - there are several howtos in the net that explain howto resize partitions with diskpart

___________________________________

description of vmx-parameters:

VMware-liveCD:

[Ravi_T]

I tried Diskpart many times, and had very unreliable result. It would hang forever or would not be able to merge the partitions.

Anything else that could help in this? its Windows 2003 standard.

[continuum]

Maybe you have a BartPE with Partition-magic ?

___________________________________

description of vmx-parameters:

VMware-liveCD:

[STLcards06]

I know this is an old post that I'm replying to, but I found a program that successfully resizes partitions in NT enviroments (W2K3 Server) with ease. And it's a free download as well. The products is called EASEUS Partition Manager. Anyway... I'm on this thread because I'm having issue trying to convert P2V as well and am looking for an answer... Right now I'm a 4% and it's been 3 hours since I've started the conversion. I sized the partitions down to ( C:\ = 20GB instead of 40GB and D:\ = 40GB instaead of 60GB) 60GB total with only 10GB of total data... This shouldn't take too long, am I doing anything wrong? Any suggestions please!

Thanks!

[athlon_crazy]

That's hell slow dude. I did p2ved (Hot Cloning) few win2k3 machines last week for 12-20gb disk usage and it tooks only max 2 hours with 100 base network.

BTW, 4% at cloning volume process rite?

System Engineer

Zen Systems Sdn Bhd

Malaysia

[victorg]

I suggest using v4.0. The performance is better than 3.0.X. Of course, if you are resizing the volume, the speed is very low, because it's doing a file copy. But if you are importing to ESX 3.5 with Converter 4.0, you can create thin-provisioned disks instead of resizing the volumes.

WikipediaWictionaryChambers (UK)Google imagesGoogle defineThe Free DictionaryJoin exampleWordNetGoogleUrban DictionaryAnswers.comrhymezone.comMerriam-Webster<>0

wvcidfjoguarm

[ericortego]

Vmware converter is a piece of &^$%.

I've tried to do P2V, V2V, Client standalone, client server, and have never once witnessed this excuse for a product work to completion.

The ONLY %^&*$ way to get a V2V copy of windows on a linux vmware server host or workstation is to copy the files and manually rename & edit the files, new-sid etc etc

Message was edited by: RDPetruska Expletives deleted.  Please refrain from such language on these forums.

[benpiper]

Unless you have gigabit all the way through, VMware Converter is going to take many hours if not days to convert.  For whatever reason, VMware Converter seem to use only a small percentage (about 6% from what I've seen) of the available bandwidth to perform the conversion, even if you disable network throttling.