Freigeben über

Why is the virtual machine spending so much time at “2%” when starting?

  • Artikel

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: https://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%System32Driversetchosts) and added the following line:

127.0.0.1           corppki.ben.demo

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!

Cheers,
Ben

Comments

  • Anonymous
    June 25, 2013
    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).

  • Anonymous
    July 02, 2013
    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.

  • Anonymous
    March 18, 2014
    Thank you for your information. Microsoft has to work on this issue.