P2V windows servers using robocopy

[neil_murphy]

Hi,

I am starting a virtualisation project where some very large data volumes have to be migrated. The plan is to P2V the system partitions first, use robocopy to migrate the data from the physical server to the virtual server over the course of a week (while users continue to access the physical box), and finally to cut-over to the virtual machine.

I wonder if anyone has any suggestions as to how best to handle the active directory/SID issues involved in doing this. I was thinking of the following process:

1. P2V system partitions

2. Change IP and machine name on VM

3. Perform robocopy

4. Remove source server from domain

5. Shutdown source server

6. Remove target VM from domain

7. Re-add target server to domain

I'm not really sure yet if this hangs together. I'd be interested in hearing from anyone who has been through this process.

Neil.

[Lightbulb]

This may not be an optimal P2V situation. It all depends on what the existing servers are doing. If for other reasons the servers cannot be migrated quickly it might be better to leverage Vmware as a means to make an old school migration easier. Create new VMs and configure to perform funtion of existing systems and then migrate data over.

P2V is cool but as you have noticed there are issues when not simply performing one time move of physical system to virtual. Also there are often post P2V headaches vis-via weird driver issues etc. Don't get me wrong converter it is a useful tool and mostly things goes well but you need to consider all your options for providing a seamless transition.

Just a thought.

[vmroyale]

Hello.

This approach will work. If you could answer a few questions it would help.

Are the current large volumes on direct attached storage?

Are we talking about file servers, or what are the primary uses?

How are the permissions set up - are you using domain users and groups or local?

[neil_murphy]

All servers have direct attached storage at present. We'll be moving to an environment with HP MSA2012fc shared storage.

The servers are a mixture of file shares, FTP repositories and application servers.

Share permissions are based on Active Directory users and groups. All servers run Windows 2003.

[vmroyale · Accepted solution]

As opposed to doing the P2V first, why not do it last?

01. Create a new VM with the same number of volumes as your current physical server (one vmdk per vol) and size as required

02. Perform robocopy of the large volumes, making sure to copy the ACLs, to the new VM

03. Schedule downtime

04. Kick all users out, and perform one last incremental copy of the data

05. P2V system partition

06. While waiting, shut down the new VM.

07. Rename or move the vmdk containing the system vol in the new VM. The idea here is to replace the system partition with the P2V version.

08. Copy the resulting vmdk from the P2V over to the new VM (make sure the copied vmdk file name matches the original file name of the vmdk you renamed or moved)

09. Now that the system partition has been replaced with the P2V version, shut down the physical source server

10. Power up the VM

11. Clean up from the P2V and get networking right with the correct IP address

12. Test, test and test some more

You could do the P2V first, sysprep, rename, re-address, etc, but the above listed approach gives you a bit of an easier fallback. In the event something goes wrong or just doesn't work, you simply shut the VM down and power your physical server back up. Then you can rename or move the original system volume back into the VM and be ready to try it all over again.

Good Luck!

[neil_murphy]

Thanks. I like your thinking.:D