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.
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?
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.
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.
Thanks. I like your thinking.:D