我们有一个运行许多虚拟机的 Windows Server 2012 故障转移群集。群集的存储由 Windows Storage Server 2012 实例提供，并通过 iSCSI 映射到节点。此外，我使用 DPM 2012 SP1 来保护群集虚拟机 - 这些备份存储在与运行群集的服务器不同的服务器上。快照提供程序配置是根据以下说明和指导设置的： http://blogs.technet.com/b/filecab/archive/2012/10/08/iscsi-target-storage-vds-vss-provider.aspx
我们在 Server 2008 R2 上进行了同样的设置，但最近进行了升级，以利用 Microsoft 声称的硬件快照提供程序和性能改进。自从为群集虚拟机配置保护组以来，该组显示所有成员都处于理想状态，并且群集事件日志中没有错误。
但是，查看存储服务器上的 iSCSI 设备时，许多虚拟磁盘都显示有路径，例如“\?\GLOBALROOT\Device\HarddiskVolumeShadowCopy{95EEC618-9594-11E3-93F9-00259067F05B}\csv.vhd”。每个虚拟磁盘都与一台服务器的备份相对应，并且每个设备在设备管理器中都有一个条目。备份运行后，这些不应该作为人工制品保留下来，但出于某种原因，它们保留了下来。
运行“vssadmin list shadows”时，也会列出许多阴影。
系统日志中没有显示任何重要内容，但每当运行新备份时，就会将另一个磁盘添加到 iSCSI 磁盘列表中，并将另一个条目添加到 vss 影子列表中。
这个问题已发布到 Technet 论坛，但他们无法提供帮助。Microsoft 支持也无济于事。
有人知道为什么快照会出现在 iSCSI 虚拟磁盘中，或者如何防止这种情况发生吗？
答案1
首先，在采用该建议之前，我会先让 Microsoft 支持技术人员运行此解决方案！
我们的集群也存在类似的问题，并已向 Microsoft 报告。在我们的案例中，卷出现在集群的每个节点上的注册表项下：
\HKLM\SYSTEM\CurrentControlSet\Enum\STORAGE\VolumeSnapshot\HarddiskVolumeSnapshot###
我们有大约 400-500 个来自 vss 提供商的幽灵条目，但这些条目没有自行清理。他们的建议是使用 DevNodeClean.x64.exe 删除幽灵设备，这招很管用。
在存储节点上运行 DevNodeClean.x64.exe /l（列表扩展）时，我能够看到 DriverKey（在存储节点上）与注册表项（在群集节点上）内的 Driver 字符串值匹配。
我认为您可以从 DPM 服务器中删除幽灵条目，就像我们从集群节点中删除一样。
至于他们为什么还留下来，我们也没有从微软得到任何答复......
PS-据我所知，DevNodeClean.x64.exe 仅可从 Microsoft 支持技术人员处获得。