在本文中，我们将一同来评测全新Hyper-V 3.0中的功能：虚拟光纤通道。

　　背景知识

　　虚拟光纤通路(简称VFC)使得Hyper-V客户机能够访问安装于Hyper-V服务器端的物理存储主机总线适配器(简称HBA)。通常情况下，Hyper-V客户机本身都会配备存储适配器。但在这项新功能的帮助下，所有具备相应O/S级别的Hyper-V 3.0客户机都能访问HBA，并直接与光纤通路存储设备相连接。

　　VFC功能的实现依托于NPIV或者N_Port ID虚拟化技术。这是一种光纤通道标准，允许单一HBA在SAN环境下充当复数节点。一般来说单一HBA与SAN连接后即提供相应的惟一物理ID，即全球商品名称或简称为WWPN，这涉及到光纤的物理连通性。与此同时，连接服务器或存储设备将提供惟一的节点名称ID或者WWNN(即全球节点名称)。每个适配器都拥有独一无二的WWNN，这与大多数主机托管下的HBA相似，也能作为像存储阵列这类整体设备的独立代表节点。

　　NPIV允许单独物理适配器为光纤提供多个节点名称，并以这种方式对物理设备进行高效“虚拟化”。每一个新节点同样必须拥有虚拟WWPN，因为只有这样才能符合光纤通道标准的要求。

　　使用NPIV对HBA加以虚拟化的好处在于，Hyper-V环境下的每一台客户机都能够分配到自己的专有WWNN，并以此为基础直接与SAN相连接。就直观角度来看，我们可能无法马上感受到虚拟服务器基础设施是如何对物理层加以抽象化处理的，但通过这种方式对存储设备进行分区仍然能带来诸多显著改善：

　　? 单独客户机经过分区之后安全性得到大幅度提升(虽然仍然需要通过管理程序)；

　　? 能够支持磁带驱动器，这样软件备份就能直接被写入设备当中；

　　? 存储所必需的故障转移、快照及其它基于SCSI的常见功能都能得到直接支持，特别是在那些非标准化SCSI指令环境之下，这一特性就显得尤为宝贵。

　　实际使用

　　VFC的配置工作在Hyper-V管理器中完成，使用的是新的Virtual SAN Manager(虚拟SAN管理器)选项，详见上图。只有HBA以及支持NPIV的固件才能正确为VFC所使用。换句话来说，只有像Emulex HBA这类传输能力在4Gb/秒以上的新HBA方能符合要求。显然SAN光纤也必须同样支持NPIV。一个HBA只能归属于一个虚拟SAN，然而一个虚拟SAN中却可以包含多个HBA。在虚拟SAN创建完成之后，我们就可以利用Add Hardware(添加硬件)选项中的Settings(设定)子集将虚拟HBA分配给客户机。光纤通路ID理论上可以使用任何16位长度的16进制数字，不过官方并不建议用户使用那些已经预留的数值。微软公司在默认情况下设定了一些标准值，我们在点击“Create Addresses”(创建地址)按钮时这些值会自动生成以供使用。不过到现在我也没搞清楚为什么光纤通路似乎只有两组地址可见并直接可用。

　　在客户机启动完成之后，即使我们没有安装客户机O/S，光纤登录进程也会自动开始。如上图所示，额外的节点指明了源Hyper-V服务器(在本实例为中PH03)，但却无法正确显示客户机名称，而只是标注为“Hyper-V VM Port”(Hyper-V虚拟机端口)。希望这一点在今后的更新中能有所改善，毕竟看不见虚拟机名称的话管理工作实在很难进行。

　　要想在Hyper-V客户机上使用VFC需要满足两大条件：

　　第一，使用指定的O/S——Windows Server 2008、Windows 2008 R2或者Windows 2012都可以;

　　第二，安装Windows Server 2012中附带的集成服务更新。也就是说虚拟光纤通路适配器无法被模拟为本机设备，因此我们不能使用以Linux为代表的其它操作系统。上图显示的是我为主机设置的模拟HBA控制器以及磁带驱动器。

　　最近我发现很多博文都在对Windows Server 2012的磁带驱动器支持能力展开讨论。这里我要澄清一下，磁带驱动器绝对是能够正常工作的，但目前微软官方还没有在任何说明文档中正式表示他们提供相关支持。

　　性能表现

　　我选择了一款磁带驱动器，这正是展示Windows Server 2012处理性能的绝佳方式。在将Backup Exec 2012部署到我的Windows 2008 R2客户机并向LTO2驱动器进行写入操作时，我发现测试成绩达到12MB/秒，这比我在vSphere 5.0上进行模拟设备测试时的成绩要好一些。虽然这与驱动器本身的最大传输能力(40MB/秒)还有一定差距，但在小型业务环境中已经足够用了。要想得出更有说服力的结论，我们还需要进行大量测试工作，毕竟在Hyper-V服务器上的数据迁移管理工作量并不太大。

　　架构师观点

　　虚拟光纤通路的出现为本地SAN设备带来了有力的技术支持。不过这项新功能在实际使用方面仍然存在各种限制，其中最令人难以接受的就是必须使用最新的硬件以及微软系统平台。到目前为止我还没有看到任何真正成功的VFC实践经验，例如将多个HBA与单一虚拟SAN相匹配或者将其构建为故障转移体系，因此具体实施方案还需要用户耐心等待。

　　VFC的主要改进方向有两点：首次，驱动器应该能够支持其它平台，尤其是Linux环境;其次，如果供应商能够利用虚拟设备进行代码编写，那么虚拟SAN装置(简称VSA)应该能够比目前的iSCSI更好地与光纤通路进行协作。

　　最后再说一句，微软在这些全新存储功能的细节说明方面做得并不好。直到现在我们也无法在高端博客之外找到任何实际使用经验，这对于用户而言显然不够贴心。希望这一点能够尽早得到改观，让微软潜心打造的新功能真正为广大消费者服务。