Here are a couple of tips to get the restore working relatively quick:
- Use the Legacy NIC in Hyper-V if the restore files are on a network share.
- Use only 1 virtual CPU to run the restore.
- Use the Integration Services drivers as part of a Hardware Independent Restore for the guest OSs:
- Extract the contents of the VMGuest.iso to an architecture specific folder.
- msiexec /a Windows5.x-HyperVIntegrationServices-x86.msi /qb targetdir=c:\temp\x86
- msiexec /a Windows5.x-HyperVIntegrationServices-x64.msi /qb targetdir=c:\temp\x64
- Use a utility like CDBurnerXP to place the extracted content into an ISO file.
- Mount that ISO file when it comes time to run the restore in SP.
- Install _every_ driver that is in the \Hyper-V Integration Services folder for the required architecture.
The WinRE used by ShadowProtect will not pick up the Hyper-V NIC by default. So, run the restore with the Hyper-V legacy NIC in place. Once the restore is complete, shut down the VM and switch out the Legacy NIC for the Hyper-V native NIC.
This is what a restore looks like with 2 virtual CPUs for throughput:
This is what a restore looks like with only 1 virtual CPU:
So, somehow having anymore than 1 virtual CPU enabled causes a real problem with not only the restoration process, but navigating around the ShadowProtect recovery GUI too. Things are a lot more responsive with just 1 vCPU.
Using the above procedure will yield the following on a Windows 7 P2V:
The 100MB system partition that Windows 7 creates during its install routine is not needed to restore the OS as a Hyper-V guest. We needed to use the Hardware Independent Restore process to get beyond a BSOD 0x0000007E.
Microsoft Small Business Specialists
Co-Author: SBS 2008 Blueprint Book