Why do my Client Hyper-V connections keep dying?

I have Client Hyper-V on Win8, hosting a few VMs like ubuntu, a clean windows build-machine, etc. My VMs are connected to an external virtual-switch (shared with the management OS), and that works fine... for a while - they can see the world. However, after an indeterminate time, when I resume the guest VM it won't have internet access. It simply can't see out. Shutting down the guest completely and restarting it doesn't help.

Currently, the only way I can "cure" this is to suspend the guests, go into Virtual Switch Manager, remove my virtual-switches, re-add the same virtual-switches, and reactivate the guest OS. Then it immediately works. This even works if the guest was just paused (not fully shut down).

Is this a common fault? What can I do to prevent this?

Update: after experimentation, it seems I only need to delete / re-add the external virtual-switch. Until then, the guest OS thinks it is disconnected.

Marc Gravell

Posted 2012-11-12T09:48:34.177

Reputation: 1 419

when I resume the guest VM it won't have internet access. means if you don't pause the VM then your internet access continue without any interruption? – avirk – 2012-11-15T18:19:48.753

@avirk it may also relate to suspend/resume at the host - lots of variables. But to answer your question - it doesn't seem to happen when using the guest continuously... But I rarely need to use the guest continuously :) – Marc Gravell – 2012-11-15T18:30:58.607

I wonder if this is due to the fact that Hyper-V Client is a ported version of the Hyper-V server, and thus expected to operate with client constantly running most of the time. – James Mertz – 2012-11-15T19:04:12.403

Answers

The issue here was (as harrymc rightly noted) dodgy drivers and/or hardware, in this case an on-board Marvell network adapter. It was not possible to follow the "use an older driver" approach (it simply doesn't install, and I'm not sure that is a great practice anyway), so I instead threw in an Intel CT network adapter (or a GT would probably be fine, if you lack a spare PCI Express slot).

With the on-board, this scenario would happen when suspending the host: it simply doesn't resume correctly as far as Hyper-V is concerned. With the dedicated NIC - it just works. If you are going to the trouble of replacing the NIC, you might as well get a well supported model / brand, hence why I went for the Intel.

Marc Gravell

Posted 2012-11-12T09:48:34.177

Reputation: 1 419

This might be a driver issue.

For example, in the thread Hyper-V Virtual Switch (Windows 8) the solution was to downgrade to Windows 7 drivers, rather than using the ones that windows 8 installed.

harrymc

Posted 2012-11-12T09:48:34.177

Reputation: 306 093

any idea whether it is talking about the host or the guest? – Marc Gravell – 2012-11-15T12:30:47.017

Windows 8 is supposedly the host. – harrymc – 2012-11-15T13:13:59.973

in my case I also have win8 guests - you can see how it may become confusing ;p – Marc Gravell – 2012-11-15T13:16:25.113

As the problem also arrives with linux, the host must be the common factor. Best to continue testing with linux clients at first if possible. – harrymc – 2012-11-15T13:34:22.187

For info, I've added a separate answer with more info, but you definitely deserve the bounty for leading me down the right road - cheers. – Marc Gravell – 2012-11-22T11:16:56.583