我们有许多Server 2012系统，所有这些系统都在Hyper-V 2012服务器上运行。 我们遇到了两个这样的虚拟实例的问题，这两个虚拟实例都被用作文件服务器，偶尔会停止响应向客户端提供文件的请求。 login到服务器后，尝试正常closures失败（没有错误，它只是无法确认closures请求）。
恢复是从Hyper-V控制台对服务器进行重新启动的情况。
这两台服务器并不服务于大量的用户（一个用户不超过6个，另外一个服务于大约20个用户），他们在同一个域中，但是在不同的物理硬件上（以及在不同的站点上）。 他们不同时locking。 他们都使用DFSR通过ADSL连接在它们自己之间（200GB）复制相当大量的数据，这样工作的很好，而且我们已经使用DFSR在我们以前使用的前两代服务器操作系统（Server 2008 R2和Server 2003 – 但这两者都是物理安装）。
今天，当其中一台服务器崩溃时，我注意到事件日志中的一个条目，其类似于以下内容：
Log Name: Application Source: ESENT Date: 27/11/2012 10:25:55 Event ID: 533 Task Category: General Level: Warning Keywords: Classic User: N/A Computer: HAL-FS-01.example.com Description: DFSRs (1500) \\.\E:\System Volume Information\DFSR\database_C8CC_101_CC00_EC0E\ dfsr.db: A request to write to the file "\\.\E:\System Volume Information\ DFSR\database_C8CC_101_CC00_EC0E\fsr.log" at offset 4423680 (0x0000000000438000) for 4096 (0x00001000) bytes has not completed for 36 second(s). This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem. 当服务器再次启动时，我去查找事件日志条目进一步调查，发现事件日志条目不再存在（我假设它在内存中，但在服务器closures之前未能写入磁盘，消息中提到的原因）。 我通过在事件日志中进一步searchfind上述消息。
这两个虚拟服务器的E：卷完全分配，而不是dynamic扩展，并且在其他任何虚拟服务器（包括server 2012，server 2008 R2和Ubuntu 12.04 x64）上都没有其他问题。 主机系统上没有IO，内存或CPU不足的迹象。
我在受影响的虚拟服务器上使用了性能计数器来监视内存使用情况（包括非分页池使用率）以及CPU和networking利用率，并且在问题出现时，这些都不会显示任何麻烦迹象。
我以为我们的configuration并不罕见，所以我想知道是否有其他人看到这个，并设法解决这个问题？
主机规格如下：
运行总共5个虚拟服务器（受影响文件服务器，DC +其他客户端）的hal-vm-01是Dell Poweredge R710,16GB，6 x 300GB SAS 15K RAID 10，Perc H700
hey-vm-01运行2个虚拟服务器（受影响的文件服务器和DC）的系统Dell Poweredge T620,16GB，2个3TB SATA RAID 1，Perc H310
我们有一个运行5个guest虚拟机的虚拟服务器hal-vm-02 ，它不受这个问题的影响，比hal-vm-01 ，但是加载的是相同的（交换，DC，SQL +其他guest虚拟机）。 更多内存正在开发中，以便我们可以在此主机和“hal-vm-01”之间configuration共享任何故障切换。
在受影响的两台虚拟服务器上运行AV软件（MS SCEP），它们被configuration为仅在创build时扫描，而不扫描由dfsrs.exe进程创build的文件。 VM主机上没有运行AV软件。
我们在主机hal-vm-01上使用Windows Server 2012备份来备份所有的虚拟机，这个时间用完了。 另一台受影响的服务器hey-vm-01没有备份，因为它只是我们主要办公室的离线DFSR数据副本。 另一个备份作业在受影响的虚拟guest虚拟机hal-fs-01 ，这也使用Windows Server备份来存储DFS复制共享中存储的数据的快照。 两个备份作业都在办公时间之外。
三个月后…
我们已经有三个月的时间与微软合作开通支持服务，现在已经有很多性能计数器日志，内存转储和事件日志发送给微软了。 他们执行的分析表明，hal-fs-01（有问题的虚拟服务器）的一个虚拟驱动器出现问题。 有问题的虚拟驱动器是服务器的E:\驱动器，它恰好拥有我们所有的DFSR组和共享。 最近，我将E:\驱动器上的所有数据都移到了我添加到服务器上的许多较小的虚拟磁盘上，当然也移动了所有的共享和DFSR组，只剩下E:\驱动器上的Windows部署服务文件。 尽pipe如此，我们仍然看到写入E:\驱动器失败的问题。
上周我已经将WDS文件移动到一个新的虚拟磁盘，并禁用了WDS服务。 我还删除了E:\虚拟磁盘，以防万一磁盘出现exception。 从那时起，我们还没有再次失败，但是现在就知道这是否解决了这个问题还为时尚早，因为我们最长的时间大约在2周左右，截至编辑时间（20/03/2013） ，我们只有一个星期到现在的configuration，如果问题下周再没有出现，我会重新启用WDS，因为我怀疑WDS可能是罪魁祸首。
我会继续更新这个问题（或者如果我设法解决问题，请提供答案）。
移回到Server 2008 R2 …
没有更新与进展的问题，但我们最终回滚到Server 2008 R2，一切工作正常。 我仍然有兴趣听到任何人有这个问题，并设法find解决办法。
好吧，我不知道这是否会有任何帮助，但我与你有共同的因素是，我有我的驱动器连接到PERC H310控制器，我在虚拟环境中运行文件服务器映射其数据驱动器到原始磁盘连接到相同的H310。 通常在高I / O期间的随机时间虚拟机会抱怨它无法访问驱动器，并会崩溃。 我最终将驱动器连接到板载英特尔控制器，从此没有任何问题。 我个人认为低端Perc卡有可能会导致I / O敏感操作问题的怪癖。
你看我错了，我想。 看看这个主机，它听起来像是光盘子系统的主机问题，或者是胡扯或者是明显的重载。