VMware Cloud Community
Alex_49
Contributor
Contributor
Jump to solution

Slow speed converting physical machine to VM

Hello,

I'm trying to convert one of our physical test machines (Win 2003 + applications) into a virtual machine.

First I followed the recommendation to install newest VM Converter on one machine and start converting from a source machine to another destination machine where VM Server is installed. By firewall restrictions I could not use three machines and I had to install additional to the converter agent on the source machine the VM ware converter and tried to convert the local host to a share on the destination. For convertion I have now only a two machines architecture. I'm not sure if this can work.

At the moment I started the convertion but see one task in progress with 5% but an end time with 22 hours growing up. Looks like something running wrong. On destination machine saw files created with 1 GB of 50 GB expected but still not growing.

The CPU usage an network traffic is very low on both machines. On the destination machine the disk space is big enough.

Is this the reason for the slow/froozen converting my two machine architecture? (I cannot use a converter CD)

Does someone has experience with this problem?

Thank you for every response.

Regards

A.L.

0 Kudos
1 Solution

Accepted Solutions
admin
Immortal
Immortal
Jump to solution

If you use cold cloning, you can clone using disk-based cloning. It will copy the disk as-is and use block-level cloning that can be faster.

Hot cloning uses volume-based cloning. If you change the sizes of the volumes, it resorts to file-based copying.

View solution in original post

0 Kudos
13 Replies
Jasemccarty
Immortal
Immortal
Jump to solution

How much space does the source machine have? And how much free? Are you resizing the disks on the destination VM?

If you resize disks on the destination VM, a file based copy will occur. If you have many small files, this will take longer.

If you don't resize the disks, a block based copy will occur.

The amount of space used on the source machine will contribute to the amount of time either process takes.

Jase McCarty - @jasemccarty
Alex_49
Contributor
Contributor
Jump to solution

Hello Jasemccarty,

thank you for your response.

The source machine has 55 GB used on different partitions. One partition has about 200 GB free.

The destination machine has 280 GB free space on the share I use for the convertion to VM.

I do not resize the disc partitions of the source.

I hope I need not the same free space on destination machine like the source machine offers (complete 320 GB Hard disk space available but 55 GB used).

I see no success after start the convertion. End time for the process is now 32 hours an only 5% in progress. CPU load low and no error messages.

Regards

A.L.

0 Kudos
Jasemccarty
Immortal
Immortal
Jump to solution

I noticed someone the other day had a bunch of "little files" on the source system, and that slowed the process down immensely.

Could that be the case?

Jase McCarty - @jasemccarty
0 Kudos
Alex_49
Contributor
Contributor
Jump to solution

Hello Jasemccarty,

maybe but then the vm converter is unusable because I do not know a serious business application with about 40 GB having only few big files in it.

The OS has a lot of small files I believe, too.

No, I believe this is not the reason. I see no more files growing on the destination machine! Looks like nothing happens only the end time counter is running. I think I have to stop the process. But what is wrong?

Regards

A.L.

0 Kudos
Jasemccarty
Immortal
Immortal
Jump to solution

I agree with you regarding the files issue.

I really meant to say many files, as opposed to little files. If you are doing a resize on the destination disk, and you have hundreds of thousands of files to millions of files (like on a file server), the process will be slower.

I did experience a problem like yours the other day, with a system that had about 40GB being used of 60GB, and it took absolutely forever.

I then did some troubleshooting, and noticed that the source box, and destination server had their nics at AutoNegotiate, and were not pinned to 100MBps Full Duplex.

That might be another thing to look at.

I did a "old fashioned" P2V test a couple months ago, testing the differences between AutoNego, HD, and FD, and when everything was set to FD, there was a sizable increase in speed.

Jase McCarty - @jasemccarty
0 Kudos
Alex_49
Contributor
Contributor
Jump to solution

Hello Jasemccarty,

thank you for your feedback.

I belive not it is a problem by network hardware and configuration. I copied a mass of files between the servers without any problem but thank you for the hint.

I restarted the convertion in the meantime (only converting the OS prtition with 15 GB). After 18% it looks like nothing happens. The files about 7 MB where saved on the destination but nothing grows. There is no file load to destination server.

I checked the log files but it does not help me:

\[2007-02-05 15:57:24.123 'App' 1724 verbose] \[imageProcessingTaskWrapper,749] Got an update from BlockLevelVolumeCloning::task\{13}

\[#4] \[2007-02-05 15:57:24.123 'App' 5004 verbose] \[imageProcessingTaskWrapper,668] (Re)Start waiting for property updates from CloneTask::task\{12}

\[#4] \[2007-02-05 15:57:24.123 'App' 5192 verbose] \[imageProcessingTaskWrapper,437] Waiting for updates from BlockLevelVolumeCloning::task\{13}

\[#4] \[2007-02-05 15:57:24.123 'App' 5192 verbose] \[imageProcessingTaskWrapper,668] (Re)Start waiting for property updates from BlockLevelVolumeCloning::task\{13}

\[2007-02-05 15:57:24.123 'App' 4716 verbose] \[imageProcessingTaskWrapper,749] Got an update from CloneTask::task\{12}

\[#4] \[2007-02-05 15:57:24.123 'App' 5004 verbose] \[imageProcessingTaskWrapper,437] Waiting for updates from CloneTask::task\{12}

\[#4] \[2007-02-05 15:57:24.123 'App' 5004 verbose] \[imageProcessingTaskWrapper,668] (Re)Start waiting for property updates from CloneTask::task\{12}

Regards

A.L.

0 Kudos
Alex_49
Contributor
Contributor
Jump to solution

Hello Jasemccarty,

I have to update my last post. Now the progress shows 25% but no more file loaded to the destination machine.

I will see if it continues over night. End Time is about 2 and a half hour.

If the converter creates on every source partition a kind of converting file it means I have a problem with the free place os sone partitions. If I cannot go around the problem I will try temporary use a laptop as third machine to find out if this speeds up the process.

Does nobody has some experience about how long it takes to convert a physical machine with a running windows?

Regards

A.L.

0 Kudos
thanifan
Enthusiast
Enthusiast
Jump to solution

I've converted 2 systems that had 60GB of data, the first was on a pair of 1000mbps nics, the 2nd on a pair of 100mpbs nics

the 1st took about 90 minutes to convert, the 2nd took about 4 hours to convert

both of these systems were on the same core switch as the target ESX host

as Jase suggested, I would definately check the network settings of both the Windows and the ESX servers, Auto-Negotiate should not be used ever, especially when large transfers are involved! you may also want to check the port settings on the networking equipment in betseen the two source and target for auto-negotiate, it can have an even more damaging effect there

Alex_49
Contributor
Contributor
Jump to solution

Hello thanifan,

thank you for your response. I will check which configuration for the network is used. I saw the nics using 1GBit. Means to me the convertion should only use a couple of hours.

In the meantime the OS partition convertion is finished. It took about 4 hours and the result was a 6GB VM. The source was 15 GB but it looks like the 15 GB containing some big pagefiles which I have excluded for the convertion.

Could maybe a third machine having the Vm converter installed speed up the process?

Will be a cold cloning a better choice because a hot cloning is more risky and could have unknown effects like a slow convertion?

First I will talk with our technical guys today about the network configurations.

Regards

A.L.

0 Kudos
admin
Immortal
Immortal
Jump to solution

If you use cold cloning, you can clone using disk-based cloning. It will copy the disk as-is and use block-level cloning that can be faster.

Hot cloning uses volume-based cloning. If you change the sizes of the volumes, it resorts to file-based copying.

0 Kudos
Alex_49
Contributor
Contributor
Jump to solution

Hello pangchen,

thank you for the hint. So I'm right to choose a hot cloning.

Now, I have reconfigured the nics to 100 Mbit/s Full Duplex without autodetect. Wating for restart and trying again a convertion.

I will post if it has resolved the problem.

Regards

A.L.

0 Kudos
Alex_49
Contributor
Contributor
Jump to solution

Hello,

the status is now progress 5%, running since 1,5 hours. End Time 33 hours remaining!!!and increasing!

CPU usage of both machines 1- 2 %. Network activity extreme low. VM files with 39 Mbytes created on destination machine. Waiting more than one day for converting 55 GB?

Looks like the configuration of nics didn't helped. Is the diplayed remaining times an approximation or will it come real?

Any ideas?

Thanks for every response.

Regards

A.L.

0 Kudos
Alex_49
Contributor
Contributor
Jump to solution

Hello,

took 10 hours to convert the system with 55 GB. We found some more involved network components to be configured. I think it is possible to speed up more the convertion but means to go deeper in all network components. I was surprised that this task is so sensible if network full duplex does not work perfectly.

A cross patch cable and only configure the nics of server seems to me a good idea to go around this problem.

Regards

A.L.

0 Kudos