Hyper-V Program Manager
Yesterday I gave a presentation on new features in Hyper-V in Windows Server 2012 R2. As part of this presentation I did multiple demonstrations – which involved starting and stopping many virtual machines. While I was preparing and practicing for the presentation I noticed something odd.
Whenever I started a virtual machine it spend a long time (5 to 10 seconds) at 2% on starting.
Now let me take a moment to explain something about starting a virtual machine in Hyper-V. The percentages that we display while starting a virtual machine have a reliable meaning. For example: Starting – 10% is when we try to allocate memory for a virtual machine. If you see a virtual machine spend a long time at 10% when starting – your system is running low on memory and it is taking us a while to gather all the memory for the virtual machine to start. But I do not know what is happening at 2%.
On a hunch – I started looking at the network traffic that was being generated when I started a virtual machine. Using NetStat I could tell that we were sending out some network requests – but I could not figure out where these requests were going to. Next, I logged into my DNS server and enabled DNS debug logging (details on how to do this are here: http://technet.microsoft.com/en-us/library/cc759581(v=ws.10).aspx). The DNS logging soon revealed the problem.
Hyper-V was trying to contact “corppki.ben.demo” whenever I started a virtual machine (ben.demo is the private domain that I am using for the demo). Now, corppki.ben.demo does not exist. I do not know why we are looking for it – but I do know how to get rid of this delay. I logged into my demo server and opened the hosts file (%windir%\System32\Drivers\etc\hosts) and added the following line:
Once I did this – we would no longer try and resolve this name, and my virtual machines began starting much more quickly.
Now I just need to get back to the office and figure out why we are trying to talk to corppki.ben.demo in the first place!
Due to the name - Corp PKI - I suppose it's looking for a certificate revocation list (CRL) for some cert you're using somewhere. So it might me a good idea to let your CA issue certificates without CRL pointer information (not recommended for production, but for demo it should be just fine).
I agree with Altair: I found this post blogs.msdn.com/.../client-certificate-revisited-how-to-troubleshoot-client-certificate-related-issues.aspx which indicates that Microsoft-issued client certificates contain a Certificate Revocation List Distribution Point whose URL is simply http://corppki/crl (no domain specified).
It's a very bad idea to depend on recursive name searches these days: mobile platforms (Android and Windows Phone) won't do them. Specify a fully-qualified domain name.
I'm not sure what part of Hyper-V needs to do a certificate revocation check, though.
Thank you for your information. Microsoft has to work on this issue.