P2V Migration running very slowly

[storagebender]

We are trying to use Converter to migrate a physical W2K3 systems, running SQL 2000 on a Dell Proliant DL 580 to a new virtual machine but it is running very slowing.  It seems to get stuck at 1% but when it goes to 2% the time to completion goes up to 2+ days.  The migration rate never gets above 1Mb/s.

[a_p_]

Welcome to the Community,

can you please elaborate on your environment/setup.

What are the hardware specs of the source and target server (Network, RAID, storage, ...)?

André

[storagebender]

The environment has the following:

1.  Source server:

- HP Proliant DL380

- W2K3

- SQL 2000

2.  Switch

- Dell 2824 Switch

3.  Destination server - vSphere 4.1 Host

- HP DL360 G6 

We attempted to use Converter via the plugin to vSphere Client but the migration ran at a rate of < 1Mb/s.

[pauljawood]

Hi,

I would suggested that you make sure that all the service's on the server are stopped before you try the migration. This can be done through the convertor software or on the actual OS before migration.

The other option is to have the server turned off and complete a cold clone of the server.

[ankitnarchal]

They Key aspects that you need to consider while converting any Physical machine to Virtual is the Bandwidth available for the converter to convert the VM, what storage it is reading the blocks and copying the same to the destination storage.

The procedure for the conversion is that it would take the Snapshot of the Disk it so that whatever transactions will be going to happen at that time would go to snapshot and then it will do the block copy to the destination VM.

There will not be any delta synch, by that i mean the destination VM wold not be containing the data which was transacted to the original server during the conversion process because VMware converter does not have capability of doing the final sych.

If you want to avail that capability then yo can go for Platespin Migrate which is a Paid application but its better then VMware converter.

Now comes the performance part of the conversion, please make sure that when you have started the conversion process either the app services are down or you are doing it after office hours as if you would do the same during the production hours, the bandwidth available for the conversion would be less,  there would loads of I/O happening at the source and target storage which would inturn reduce the rate of conversion.

You can actualy monitor the process of conversion and see  at what rate it is copying the blocks and writing on to the destiantion. This block read and copy depends on the what disk you have at the source  machine and what is the RPM of the same, what RAID it is set up with, what controller you have those disk running with.

[storagebender]

Thanks for the responses.  We advised the Network/Sys. Admin of what both of the responses have suggested - cold-clone or turn off all services, but the Admin insisted that he could not take the app's or services down.  I guess at this point, he has to invest in another tool, such as PlateSpin or convince his upper mangement that he need downtime.

Thanks for your suggestions and confirmation.

[a_p_]

1. Source Server

What's the NIC speed on the source server? Is it 100 MBit/s (e.g. for the G2 model) or is it already 1 GBit/s? If it is 100 MBit/s make sure the NIC speed is set to fixed 100 MBit/s Full Duplex on the server as well as the switch.

As the other's mentioned, stop unneeded services prior to start the conversion. At least the SQL Server should be stopped!

2. Target Server

I assume you have the VMFS datastore on local storage. Some of the G6 models come with the P410i RAID controller without cache. To run ESXi effectively, you need at least 512MB BBWC (battery-buffered) cache!

André

[storagebender]

Thanks for the continued suggestions.

Yes, we made attempts to make the network speed 1000Mb/s Full on each network component - source, switch and destination, but the customer had issues with managing his switch.  We were also running another instance using the same server types and the same network via cold-clone.  This method worked, but it took about 5 hours to P2V a 60GB physical machine.  Looks like the network is a culprit here along with the services that couldnt be stopped.

[ankitnarchal]

This seems that there is some other network overhead which cold be causing this issue because if you have 1gb/s line for the conversion then according to the calculations you are getting around 4mb/s as the conversion speed. Over here, i would be assuming that you have dedicated Bandwidth of 1GB/s for conversion and there is 10% overheaed.

You need to make sure that how much time does it take to do read and write from the source to the destination.

Does this converted VM reside on shared SAN storage or some other? we need to check the read/write throughput.

You can test that by copying 1gb file from Physical server to that storage location where that converted VM will reside and check how mch throughput you are getting.

The % progress for P2V is attached below. These are the phases it goes through with the corresponding %:

0 – 2%

• Initiate and authenticate task over port 443

• Create .vmdk file (reserve required space)

•

A failure will clean up any files left behind.

2 – 97%

• Take snapshot of source disk

• Begin cloning over port 902

•

A failure will clean up any files left behind.

97 – 100%

• Reshaping of virtual hardware (number of RAM and NICs assigned)

• Downgrade from multi-CPU to uni-CPU for NT4 sources going to ESX

• Reconfiguration steps (drivers)

• Sysprep (if customization was selected)

• Installation of vmware tools (if selected)

[ankitnarchal]

Inaddition to my previous post, you need to isolate that what phase of conversion is taking long and accordingly we can rectify the issue.

[storagebender]

I have posted the log files of this weekend's events.