与竞争对手服务器虚拟化平台相比，Microsoft Hyper-V好的一面在于它的相对简单性。它通常稳定而可靠，但存储相关的问题可能而且有时确实会发生。这将导致备份失败，损坏虚拟机，甚至主机系统崩溃。平台的简单性有助于更容易的诊断和修复存储相关的问题，同时了解会产生哪些错误也很重要。
在Hyper-V中，你可能遇到的与存储相关最常见的问题是由于虚拟机损坏导致虚拟机无法启动。在某些情况下，单个的虚拟机组件可能彻底消失。在这些情况下的一些错误信息的示例包括:
"The requested operation cannot be performed on a file with a user-mapped section open (_0x800704CB)."
"VMName" Microsoft Synthetic Ethernet Port (Instance ID{7E0DA81A-A7B4-4DFD-869F-37002C36D816}): Failed to Power On with Error "The specified network resource or device is no longer available" (_0x80070037)."
"The I/O operation has been aborted because of either a thread exit or an application request (_0x800703E3)."
所有这三个错误都是由于不正确的使用防病毒程序导致的。管理员通常在主机操作系统内部署防病毒软件，而没有意识到这类软件对于虚拟服务器的损害。一般说来，在主机操作系统中运行的防病毒软件需要在配置中将虚拟机配置所在目录，以及虚拟磁盘所在目录，以及任何包含虚拟机快照的目录排除在外。 Microsoft同时建议在病毒扫描时略过文件Vmms.exe 和Vmwp.exe。
如果主机服务器运行Windows Server 2008 R2版本，并且作为Hyper-V集群节点，在C盘上的ClusterStorage目录在扫描时也必须排除在外。这个目录直接映射集群共享卷，其中通常都会包含虚拟机文件。
主机服务器蓝屏死机
另外一个Hyper-V存储问题是你可能会在主机服务器上遇到蓝屏死机(BSOD)。有很多原因可能导致BSOD。最常见的就是内存损坏。另外，一些Hyper-V管理员在他们每次试图备份Hyper-V主机时也遇到过BSOD错误。
判断BSOD问题是否与备份过程相关最简单的方法就是检查服务器的日志，看备份的时间与系统崩溃的时间是否吻合。如果你确定系统崩溃是由备份过程导致，那么还有几件事需要检查。
首先，检查你的存储硬件和备份硬件的固件程序，确保其最新。过时的固件程序有时可能导致备份过程严重错误。
其次，如果你的Hyper-V部署使用了集群共享卷，你必须检查以确认你的备份软件是否支持备份集群共享卷。用于Hyper-V的许多备份应用并非集群感知。使用非集群感知的备份应用备份集群共享卷极少导致严重错误，不过还是有可能发生。更常见的后果是导致损坏的备份。
最后，BSOD 错误可能由卷影拷贝服务(VSS)的问题而引起。Hyper-V备份使用VSS以保证虚拟机的内容在备份建立时保持不变，从而确保备份的一致性。实际的备份过程由VSS provider实现。通常，VSS provider由Microsoft提供，并且文件拷贝的过程由本地Windows文件系统处理。不过，当使用特定的存储硬件时，存储厂商可能会提供自己的VSS provider。这些定制过的VSS provider已知可能会导致BSOD错误。如果你怀疑问题可能由VSS provider导致，请与你的存储厂商确认是否使用了最新的VSS provider并且已在操作系统中正确的注册。
存储争用
最常见的Hyper-V存储问题之一是存储争用。无论你的虚拟主机使用专用的存储还是集群共享卷，主机上的所有虚拟机都必须竞争磁盘I/O。如果使用集群共享卷，集群中每个主机上的虚拟机都必须竞争磁盘I/O，因为每一个主机都链接到相同的存储卷。
当存储子系统不能交付足够的磁盘I/O来满足虚拟机的需要时，存储争用就成为问题。这可能是由于磁盘阵列瓶颈或存储网络带宽瓶颈导致。解决此问题的唯一方法是通过性能监测软件来确定瓶颈然后升级硬件。
不过，有时你也可以通过重新组织和安排虚拟机的工作负载来减轻存储争用的症状。例如，众所周知存储可以产生大量的磁盘I/O，如果在多个虚拟机中执行客户机一级的备份，你可以考虑调整备份时间，使得备份不会被同时执行。这样做可以减轻有备份过程所产生的I/O负载。
