我们有一个运行大量虚拟机的Windows Server 2012故障转移群集。 群集的存储由Windows Storage Server 2012实例提供，并通过iSCSI映射到节点。 另外，我使用DPM 2012 SP1来保护群集虚拟机 – 这些备份存储在与运行群集的服务器不同的服务器上。 快照提供程序configuration是根据http://blogs.technet.com/b/filecab/archive/2012/10/08/iscsi-target-storage-vds-vss-provider.aspx上的说明和指导进行设置的。
我们对Server 2008 R2进行了相同的设置，但是最近升级为利用Microsoft提供的硬件快照提供程序和性能改进。 由于为群集虚拟机configuration了保护组，因此组显示所有成员都处于理想状态，并且在群集事件日志中没有错误。
但是，在查看存储服务器上的iSCSI设备时，许多虚拟磁盘都显示为path，如“\？\ GLOBALROOT \ Device \ HarddiskVolumeShadowCopy {95EEC618-9594-11E3-93F9-00259067F05B} \ csv.vhd”。 每个虚拟磁盘都与一台服务器的备份对应，每台设备也都有一个设备pipe理器的条目。 在备份结束后，这些不应该作为文物留下，但由于某种原因，它们是。
运行“vssadmin列表阴影”时，也会列出许多阴影。
系统日志中没有显示出任何重要的信息，但每当运行新的备份时，都会将另一个磁盘添加到iSCSI磁盘列表中，并将另一个条目添加到vss阴影列表中。
这个问题被张贴到technet论坛，他们无法帮助。 微软的支持也没有帮助。
有没有人知道为什么快照显示为iSCSI虚拟磁盘，或者如何防止这种情况？
首先是事情。 在使用此build议之前，我将由Microsoft支持技术人员运行此解决scheme！
我们和我们的集群有一个非常类似的问题，并引起了微软的注意。 在我们的情况下，卷在密钥下的registry中出现在我们集群的每个节点上：
\ HKLM \系统\ CurrentControlSet \枚举\ STORAGE \ VolumeSnapshot \ HarddiskVolumeSnapshot ###
我们有大约400-500个来自vss提供者的ghost入口没有自行清理。 他们的build议是用DevNodeClean.x64.exe删除鬼装置，并做了伎俩。
在存储节点上运行DevNodeClean.x64.exe / l（列表扩展名）时，我能够看到DriverKey（在存储节点上）与registry项（群集节点）内的Driverstring值匹配。
我假设你可以像从集群节点那样从DPM服务器中删除虚影条目。
至于为什么他们坚持，我们没有从微软得到任何答案…
PS – DevNodeClean.x64.exe只能从Microsoft支持技术人员提供，据我所知。