我每隔两周就会发生一次奇怪的间歇性连接问题。
首先我的configuration：我正在运行具有两个物理主机（node01和node02）的HyperV故障转移群集。 主机都运行带有SP1的Windows Server 2008 R2 HyperV服务器（免费的）。 在这些主机上，我运行了两台运行Windows Server 2008 R2 Web版SP1的虚拟机。 我的存储服务器是通过iSCSI连接的Windows Storage Server 2008。 两台主机以及存储服务器都运行从英特尔网站直接下载的最新networking驱动程序。
这就是问题：99.99％的时间，一切正常。 大约每两到三周，虚拟机将同时失去networking连接，无论是传入和传出。 发生这种情况时，
这发生了大约5次，症状与上述相同。 我怀疑networking驱动程序或networking硬件问题，但由于我已经运行最新的驱动程序，我不知道该怎么做。
这是一个真正的头脑…任何想法？
更新
我在这里发现了一个非常相似的情况： Virutal Machine在Hyper V群集上丢失了networking连接
2011年7月29日更新
安装修补程序和更新networking驱动程序后，我仍然遇到同样的问题。 针对要求提供硬件详细信息的评论，服务器是英特尔SR1670HV，它是1U机箱，包含两个独立的S5500HV主板。 通信是通过主板的Intel 82574L集成网卡。 networking驱动程序是版本16.2.49.0。
我们曾经有过这样的问题。 我不记得确切的细节，但最终的解决scheme必须处理dynamic分配给虚拟networking适配器的冲突的mac地址。 把它们固定在他们没有dynamic帮助了很多。 您通常不想这样做，因为它可以使虚拟机更难以移动到不同的主机，但是在这种情况下它帮助了我们。
另一部分是broadcom制造的物理networking，我们也有一个configuration错误，在那里，以前的pipe理员不正确地尝试使用broadcom实用程序来将主机上的两个nics连接在一起以提高带宽/吞吐量。 我们删除了这个设置，并configuration了其中的一个，所以它在主机上根本没有IP，但是仍然可以用来传递给虚拟客户端。 然后，我们将每个虚拟机设置为只使用一个nic或另一个，根据历史stream量来平衡负载。 当然，如果一个适配器或连接断开，就意味着没有故障转移，而且我们也没有很好地跟踪stream量是否随着时间的推移而保持平衡，但是从那以后它一直保持稳定。
我知道这是一个古老的问题，但是我遇到了同样的问题，浪费了太多的时间来解决问题，我想我会分享为我工作的解决scheme。 我在这里find了解决我的问题的方法：
http://invendows.wordpress.com/2008/03/06/network-issue-with-hyper-v/
在我的情况下，解决scheme是禁用虚拟机上的TCP卸载。 我会引用链接中的相关部分：
为了禁用TCP Offloading，我必须在连接到Broadcom 8507 Nextreme II NIC的每个虚拟机中创build并设置一个新的registry值。
我使用以下registry更改来禁用TCP卸载：
关键：HKLM \ SYSTEM \ CurrentControlSet \ Services \ Tcpip \ Parameters
值（DWORD）：DisableTaskOffload = 1
通过这种方法在每台虚拟机上禁用TCP卸载后，所有问题都已经结束，我可以将多个虚拟机连接到Broadcom 5708 Nextreme II NIC的一个NIC端口。
我的服务器有Broadcom NetExtreme网卡，所以在我看来这个问题的原因是与驱动程序有关，但设置DisableTaskOffload = 1完全解决了我的问题。 希望这个信息可以节省别人几个小时的search时间！
我在一个更简单的Hyper-V环境中遇到了类似的情况，并在Microsoft上阅读了这篇文章。 似乎适合您的情况，如果Web服务器大量使用。
http://support.microsoft.com/kb/974909 – 运行Hyper-V虚拟机的networking连接在基于Windows Server 2008 R2的计算机上繁忙的传出networking通信下丢失
我们遇到了同样的问题，但在我们的情况下，每24-48小时。 我会仔细检查你的防病毒/防火墙产品是否支持Hyper-V Server 2008，如果不是的话，请尝试使用其他防病毒/防火墙产品作为testing，以查看问题是否消失。
在稍后调用Microsoft和几个转储/日志file upload之后，他们确定趋势科技防毒墙networking版是我们案件中的罪魁祸首。 我们使用的是一个在Hyper-V上没有明确支持的版本，一旦我们升级到最新版本，问题就消失了。
这原来是一个硬件问题 – 我把问题隔离到了一台Netgear GSM7224v2网pipe交换机上，用D-Link DGS-1024D取而代之，一切工作都很顺利。
作为一个“吸取的教训”，在这种情况下，我可能花费了99％的诊断工作来排除故障软件设置的硬件问题。 我甚至还支付了259美元的微软支持（并且花了很多时间和他们打电话），以帮助我通过软件设置来解决问题。 我想这个故事的寓意是怀疑你的硬件和你的软件一样多。
在VM guest虚拟机的networking适配器属性上，是否禁用了Jumbo Packets和Large Send Offload？ 根据我对这些设置的经验，我肯定会尝试一下。
https://support.microsoft.com/en-us/kb/2986895
这是Broadcom 1千兆字节networking适配器的已知问题。