Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

How can I calculate / estimate the time length of p2v migration with vmware vsphere 4?

share|improve this question
add comment

2 Answers

As Chopper3 says the time it takes depends on too many variables that are specific to a given environment to be able to say how long they will take with any significant level of accuracy.

However provided the environment is running on a healthy Gigabit LAN, there are no other significant loads on the network, SAN or Server's being migrated from (e.g. large backups) and the Virtual Infrastructure is not overloaded you should be able to migrate machines at rates between 30 and 80Megabytes per second.

Some other variables are important - if you are using a P2V utility that is using a file level copy protocol then the number of files in the system to be migrated can become significant but we need to be talking about many hundreds of thousands of files per volume for it be noticeable. File systems with millions of small files can take a very long time. If the source system only has a 100Megabit connection then transfer rates drop by a factor of 10 (obviously). If your source or destination storage systems top out at speeds below the above transfer rates then that too will slow you down.

In general I generally allow for a 30Megabyte/sec transfer rate and then add on about 20-30 minutes for the various preparation\reconfiguration stages in order to get an initial ballpark number. Then I add on the time it will take to test the migrated system, that will vary enormously depending on the applications\services on the server. Once I've carried out a couple of migrations I adjust the plan and always make it clear before I start that the timings will depend on the performance we encounter.

One other thing that may be a good idea is to have an accurate estimate of how long it takes to backout of the migration. This is usually relatively quick (just turn the old server back on and have it boot for the most part) but if you have a strict migration window you need to know when your drop dead time is for kicking over to the backout plan.

share|improve this answer
add comment

You can either guess or extrapolate existing information i.e. have you done one before on this particular ESX host/cluster, over the same network and storage systems, at the same time of day etc. It's the only way to get remotely close, anything else would be, well the first option.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.