How to estimate ETA for conversion

[MichaelLeone]

I have 2 file servers to convert. 1 is Win 2008 R2, one is Win 2012 R2. I've been asked to estimate the amount of time it will take to convert, and i have no way how to do that. I have the sizes of the machines to convert (1 is 500G, the other is a bit over 600G).

How would I make such an estimate? The standalone converted is block-based, right? Has nothing to do with the number or size of files on the servers, only the total size of the disks.

Each server would have 2x1G Ethernet NICs, teamed.

Anyone have any pointers on how to make such an estimate? 4 hours?

Converter v6.2, destination ESXi 5.5 U3b. ESXi has 2x10G NICs for VM traffic.

[RickVerstegen · Accepted solution]

Make sure you have a baseline of about how many GB can be converted per hour. A good way to test this is to convert a good candidate system of about 100 GB and use that as a multiplier for your environment. There are a lot of factors you need to consider, such as network speed and traffic, esxi host performance, storage performance (on both ends), and total size of the data on disk. This allows for a good estimate on any downtime that needs to be coordinated if this applies to the selected workload.

There is an incremental synchronization which will be useful in your case - the down time is minimized because initial sync will transfer 'base' data and incremental sync(s) will transfer only differences.

Rick

[Lalegre]

As RickVerstegen​ says there are many factors to consider that are mentioned in his reply.

I also recommended to disable encryption on Converter Standalone this will REALLY improve your consumed time. Follow the next post: https://www.vladan.fr/how-to-disable-ssl-encryption-in-vmware-vcenter-converter-standalone-to-speed-...

[continuum]

Last year I had to do a series of about 10 similar P2V operations - same opeating systems and similar sizes.
Your rough guess of 4 hours is quite inside the range that I was able to acchieve.
Are you aware of the fact that every successful P2V import requires 2 completely independant tasks ?
Typically you will spend about 99% of the time for the transport part of the job.
The "configure machine" part normally requires just 5 minutes.
To give a reliable ETA-value you need to give a good guess on the time each part of the job requires.
You must also evaluate the successrate of each part of the job.
For Wiindows 2008 and 2012 you can assume a very high successrate for the configure machine part combined with a required time that is neglectable.
In other words: in your case any recent Converter should require about 5 minutes for the configure part with a 95% or better successrate.
If you decide to use VMware Converters hot clone approach to do the transport you can not assume to acchieve a successrate close to 95 %.
I would rather estimate the success rate for the transport part of the job in a range between 75 % and 90 %.
You have to decide wether that is good enough for you.

If I have to schedule a P2V operation and need to achieve a very high reliabilty and predictabilty I do not use Converter for the transport at all.
Instead I use ddrescue over sshfs. This transport procedure is the most reliable one:
It can fail several times along the way as it allows to be restarted from last state and can even handle errors in the source material. You can not ask for anything better IMHO.

Finally I have another approach for very demanding clients. I avoid this one if possible as this requires a significantly larger amount of manual work.
This approach uses Converter for the "configure machine" part of the job.
It uses iSCSI for the transport and most significantly: it inverts the sequence of the tasks:
In this scenario I do the "configure machine" part before I do the actual transport.
This requires several additional steps but enables you to guarantee ETA evaluations in the range of 30 minutes independant of the actual amount of data you need to transport.
An ETA of 30 minutes means:
30 minutes after you started the process you can switch production from physical machine to VM.
In the first few  hours after switch-over the VM will be slow.
Once all the data is transferred a final downtime of 5 minutes is required.

I wonder if my summary actually helps you - well you asked "how to estimate ETA for conversion ?"
Probably you want to go with standard Converter functionality and dont see any need to learn the procedures I mentioned.
If you decide to use Converter standard procedures here is one tip that can highly improve your successrate / reliabilty:
Try to find a time before you actually start the Conversion and run a checkdisk of the source systems in the background.
If checkdisk finds anything relevant to the P2V conversion this approach gives you a chance to react before the customer is standing behind you - breathing into your neck and looking at his watch ...
If you are interested in details for any of the procedures I mentioned here - feel free to call me via skype.
Ulli

[MichaelLeone]

"Probably you want to go with standard Converter functionality and dont see any need to learn the procedures I mentioned."

It's not that I don't see the need, I don't have the time. Learning new procedures on OSes you don't use every day requires much practice, in order to deal with any unexpected outcomes.

I honestly don't know if I have any test systems to use to establish a baseline. The one or two I can think of have single disks well under 100G, much less anything comparable to the sizes in question.

I guess I will find out. I'll tell them 4 hours. I do remember once, years ago, it took 4 attempts to P2V a system - it would get 90%+ of the way, then error out. I vaguely recall we had to eventually tell it to resize the target disk, even by 1G. I don't remember, it was years ago, I'd have to go digging through old notes.

[MichaelLeone]

" incremental synchronization". How does one do that with the Converter? First I've heard of that.

[RickVerstegen]

See these links for more information. The first link is quite old but still applies.

https://www.viktorious.nl/2012/04/06/about-the-improved-synchronize-option-in-converter-standalone-5...

Synchronize the Destination Machine with Changes Made to the Source Machine

[MichaelLeone]

So I did the convert over the weekend. I had hoped to be able to use teamed NICs, for better bandwidth, but our networking staff was not up to the challenge. Anyway, I ran the convert with a single 1G NIC on the physical box, and set the convert to resize the resulting hard drive down (didn't need all that now-empty space). So downsize from 1TB physical to 525G virtual drive.

Took 5 hours.

Another hour or so to install VMware Tools, set the new IP, uninstall all the old HP software that is no longer required since it's a VM.

And it's all working fine.

But based on those times, I'm not running the converter again until I have to. Ideally, I will create a new VM, migrate data and settings to it, then - when it's ready - rename the old, rename and re-IP the new.

Thanks everybody

[RickVerstegen]

Great to hear the conversion went fine.

Kindly close the thread if that issue is resolved.