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

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