无论哪家解决方案，若想启用一些加速功能，势必需要硬件的支持，这就导致在一些项目前期的调研或者POC环境里不太容易实现，毕竟有些要求是十分昂贵和苛刻的，比如RDMA。相对于一些需要资金投入的技术来说，SRIOV无疑是比较亲民且易于实现的，今天就选它来一探究竟。本篇将全部采用微软 Hyper-V 环境进行说明。
SRIOV，即单根虚拟化。Intel 在早期为了支持虚拟化环境，在 CPU 和 PCI 总线上提供了三层虚拟化技术，它们分别是：
通过以上架构的描述就可以看出，启用 SRIOV 之后，物理 NIC 将通过 VF 与虚拟机（VF driver）进行数据交互，反之亦然。那么这样一来即可跳过中间的虚拟化堆栈（即 VMM 层），以达到近乎于纯物理环境的性能；这一点也是 SRIOV 最大的价值所在，他有别于以往虚拟机通过仿真设备和虚拟化层进行流量传递的情况，那么究竟SRIOV与传统环境相比能提升多少，我来做个实验：
宿主机OS：windows server 2012R2
虚拟机OS：windows server 2012R2
服务器型号：DELL R720
网卡：intel x520 series
######################################################################################
首先在服务器 BIOS 设置中将 SRIOV 功能开启
[attach]4179[/attach]
物理机确认开启了 SRIOV 功能之后，接下来在操作系统层面操作，首先 Hyper-V 若要使用SRIOV，有两处需要修改，一个是虚拟交换机，如下图确认在创建虚拟交换机时开启了SRIOV（单根虚拟化），需要注意的是虚拟交换机一旦创建后，SRIOV 功能无法在修改，也就是说你要是忘了开启那对不起，麻烦您删了重来。
[attach]4180[/attach]
虚拟交换机启用SRIOV之后，就要在我测试的虚拟机上操作了，在虚拟机的vNIC（虚拟网卡）上开启SRIOV，如下图所示，这里是可以随时开关的
[attach]4181[/attach]
确认了上面的操作之后，通过 powershell可 以进一步确认系统是否识别了我的设置，在当前宿主机执行（get-vmhost）.iovsupport 或 iovsupportreasons 来查看返回结果，有关 powershell 中对象的属性可以通过管道符“|gm”来查看
另外如下图所示，通过 get-netadaptersriov 来查看当前主机上支持 sriov 的物理网卡有哪些，并且从返回结果来看，我的 x520-2 网卡最多支持 62 的 vf。
顺带提一句Peripheral Component Interconnect Special Interest Group(外围部件互连专业组)，简称PCISIG，这个组织定义了每个设备最多可支持的 vf 数量为256个。
[attach]4182[/attach]
在正确且成功开启了sriov功能之后，我启动这台测试虚拟机SRIOV_2012，可以看到hyper-v下方显示当前 SRIOV 是活动状态，但奇怪的是我发现有两个IP。。怎么回事呢？
[attach]4183[/attach]
进入到虚拟机系统里来看设备管理器，发现多了一块网卡，叫做“Intel(R）82599虚拟功能”，其实我这块Intel x520 series网卡是基于Intel 82599控制芯片的，后面的虚拟功能翻译过来就是virtual function，也就是虚出来的一个VF，它以一块虚拟网卡的形式呈现在虚机操作系统里了，因此我刚才看到了两个IP地址。
[attach]4184[/attach]
这里可能有个小bug，就是我需要重新配一次IP，这样这台虚拟机才不会出现两个IP地址，如下图目前这个正常的测试IP显示的是（复制）
[attach]4185[/attach]
重新输一遍之后就恢复正常了，也就是说原先的IP地址没有直接映射到我的VF上面，下图显示当前IP已经恢复正常了，只有一个6.6.6.0 的 IP 。
[attach]4186[/attach]
同样通过powershell命令“get-netadaptersriovvf”可以看到当前生成的VF信息。
[attach]4187[/attach]
######################################################################################
下面开始一个拷贝测试，通过网络传输一个iso文件，在启用SRIOV的情况下，传输速度大约460MB/S
[attach]4188[/attach]
在传输文件同时，我使用工具（burnintest）对虚拟机CPU进行加压，以尽量模拟实际情况，观察结果如下图，通过性能监视器看到CPU使用率最小值不到2%，最大值11%多，相差约9.5% 。
[attach]4189[/attach]
接着关掉这个虚拟机的SRIOV功能
[url=]表情[/url]
[attach]4190[/attach]
可以看到VF没有了，如下图
[attach]4191[/attach]
通过powershell确认VF的确离我们远去了~
[attach]4192[/attach]
同样再通过网络拷贝一次文件，依旧是iso文件（这里不用考虑缓存因素，我在每次拷贝之前都会进行一些复制操作以便尽量充满缓存），传输速率大概在410MB/S左右
[attach]4193[/attach]
同样传输期间对虚拟机CPU进行加压，观察性能监视器结果，CPU负载最小值不到2%，最大值接近17%，相差约15%
[attach]4194[/attach]
综合上述情况来看，对比SRIOV功能开启与关闭，拷贝同样iso文件以及相同的CPU加压方式，结果如下：
| 开启SRIOV | 关闭SRIOV | 差值 | |
| CPU使用率 | 9.5% | 15% | 5.5% |
| 传输速率 | 460MB/S | 410MB/S | 50MB/S |
########################################################################################
通过上面的测试可以看出在SRIOV开启或关闭的不同情况下，对比还是有一定效果的，我的测试环境还是不够严谨的，因为在实际生产环境中还要考虑诸多因素，例如磁盘的IO，虚拟机的CPU配置等等情况，但是即便比较粗陋，这个数据还是具有一定参考价值的，将近6%左右的CPU负载以及相差50MB/S的速率我想对于任何一个有大批量并发请求的虚拟化平台用户来讲都是相当可观的，所以说 SRIOV 对于当前私有云用户来讲还是很有价值的。
说起SRIOV，其实还有一个“兄弟”不得不提，它就是VMQ（virtual machine queue），我的个人理解是 SRIOV 更适合于出流量，它优化了数据在虚拟机与物理机之间交互的路径，简化了这个过程，使得性能近乎于纯物理环境，但是对于入流量来讲，大部分处理工作还是交由CPU来做，外部流量进来之后，系统需要确认哪些数据发送给哪些虚拟机，这些路由和分发工作在大访问量的场景下是十分费力的，VMQ 功能恰恰解决了这个问题，同样是需要物理网卡支持，将入流量提前进行路由并列队，系统直接分配给需要接收的虚拟机，提高了性能，但是VMQ基于“先到先得”的机制，建议仅对那些有大批量访问请求的虚拟机使用，以免那些只有很少入流量的机器影响了关键业务。
关于虚拟化的硬件加速功能还有很多，如果以后有条件了会一并奉上与大家分享。
出处 http://maomaostyle.blog.51cto.com/2220531/1439651
| 欢迎光临 曲径通幽论坛 (http://www.groad.net/bbs/) | Powered by Discuz! X3.2 |