Moving very large VM from VM Server 2 to ESXi 5u1

[RCISS]

I've moved a few of my smaller servers from VM Server 2 to ESXi5-u1, using the convertor tool.

But I have one server that has Just over 1 TB of used data on a second drive. There are no apps installed on F or G, just shared folders.  (This is a file server).  The conversion tool is saying 3+ days (doing physical machine to VM to minimize downtime).  It's been runnig for about 20 hours now and upto 16% done. However, the ETA has hardly changed.

Win 2003 Server R2-64bit

C: 60gb total with 15.7gb free   -> Growing to 100gb on the new VM

F: 499gb total with 194gb free  -> Keeping same

G: 799gb total with 84.7gb free. -> Growing to 2tb on the new VM

Would I be better off just converting the C drive to the new VM, then copy the vmdk files for the other 2 drives to the new datastore and adding them as existing drives?  Or create them as blank drives and restore them from backup (Acronis backup & Restore)?

I tried a 3gb upload to the datastore via the vsphere client, and calcluated 19.37 MB/sec transfer rate. That should mean the G drive should copy over as a vmdk file in just shy of 10 hours.  Is there any drawback from using a vmdk that was created in vmware server 2 on an ESXi5-u1 system?

Thanks,

James

[RCISS]

I decided to try the coverter from the vmware server by selecting the vmx while the vm is offline.  It's much faster.  looks like it's going to take about 10 hours total.

[logiboy123]

I would be tempted to create a new server (not joined to the domain) and present the required disks to it. Then run a robocopy script against it to copy all data from the source to destination server. Once complete you then run an incremental copy by using a robocopy /mir function. This will only copy the differences between the source and destination. Do this for several days each night after hours and you will quickly find out how much data is added or changed. Then on a weekend you can do a final copy, then rename the old server and mark the shares as read only. Then rename the new server to match the old unless you plan to change the login scripts anyway.

The full syntax for robocopy mirror would be something like;

robocopy \\source\share \\destination\share/zb /mir /sec /r:5 /w:5 /log:c:\temp\robocopy.log

Typically with migrations like this the biggest problem is security defined on the share or files/folders in the structure. If your windows user profiles are located here then I can almost guarantee security will not be setup correctly.

If you have big security issues with the folder structures then it will be far easier to migrate it as is. If you want to make your environment more tidy then this is an opportunity to clean it up but will take more time and requires you to do some testing and more after hours work.

By using the robocopy log option you will see when the process doesn't have permission to copy from a source destination folder, so you can manually edit these files/folders to give yourself enough permissions to copy them to the new server.

Regards,

Paul

[RCISS]

Thanks for your reply Paul.  That's very similar to how I converted this machine from a physical one a couple of years ago.  I used something from Karen's Tools to do the drive syncing instead of robocopy.

I have the offline conversion running right now.. says it'll be done in about 8 hours.  Gonna see how that goes.  If it doesn't workout well, then I'll do as you suggest.  Thanks.