Network problems on a Hyper-V guest

One of the particularly nice things about using Hyper-V is its robustness. The fact that the hypervisor runs seamlessly within a Windows installation means that there’s a certain reassurance in knowing that if the host is running happily on your hardware platform of choice, that the rather excellent guest abstraction means that you’re unlikely to encounter any compatibility issues.

Or so I thought, until I encountered a particularly tricksy problem last week.  I was setting up a new Server 2008 R2 domain controller as a VM running on top of a Server 2008 R2 Enterprise Core server running Hyper-V.  Yes, I know that running a DC as a virtual system can be fraught, but after reading this 2008 piece by Virtual PC Guy Ben Armstrong I’m happy that’s a viable way forward (while taking every possible precaution, of course).

All was running well with the install until I found that the newly-installed system couldn’t check for windows updates online, even though I’d instructed the firewall to grant full access to this particular box.  The error number given was 0x80072EE2, which according to Microsoft is a connectivity issue.  Bizarre, given that the machine had full access out and wasn’t being restricted by IE Trusted Sites or anything like that.

After a bit of digging I found a blog post which discussed the same issue.  The author wrote that he had been able to fix the issue by adding the following registry entry to the Hyper-V guest:

HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
Value(DWORD): DisableTaskOffload = 1

I tried the fix and on reboot Windows Update was working.  Great, but why was that actually necessary?  I run quite a few Hyper-V machines across a range of hardware platforms and this was the first time I’d had to implement this fix.  Anyway, I carried on regardless, joined the machine to the domain and installed and configured ADDS.  On reboot the machine gave a spectacular BSOD and got stuck in a reboot loop.  No recovery options available, so I had to strip the newly-created DC out of AD and start again.

After a bit more investigation (which in retrospect should have happened first, but what can I say…it was a Friday), I discovered that the particular registry fix, according to INSIDEtheREGISTRY.com, performs the following function:

This value instructs the TCP/IP stack to disable offloading of tasks to the network adapter for troubleshooting and testing purposes.

Valid entries are 0, 1 (false, true), where the default is 0 (false)

That’s fine when the system is talking out through a physical NIC but in the Hyper-V environment it isn’t.  The NIC was configured as an external network hidden from the host, but the VM was attached to it via Hyper-V’s Virtual Machine Bus.  After a bit more digging around I came across this entryin the TechNet forums.  Seems that this isn’t a new issue – just because a Hyper-V host can install, configure and successfully use a physical network adaptor, this doesn’t mean that it’s fully compatible and that you won’t run into issues.  The NIC in my case was a PCI Realtek Gigabit network card – not exactly enterprise-class but good enough for my immediate needs (or so I thought).

Basically the card was the source of all my issues and the likely cause of the domain controller falling over so badly.  Lesson learned, I stripped out the card and replaced it with a more reliable PCI-E Intel NIC….no issues whatsoever.

So if you get strange networking issues in your Hyper-V virtual machines, after running through the usual configuration checks go straight to the underlying hardware and make sure that it’s good, rather than trying to fix that particular problem.  In the sandboxed world of a Hyper-V guest you really shouldn’t be seeing these sorts of issues, so when they crop up they are quite probably just a visual symptom of a deeper malaise.