OpenStack SR-IOV
本文主要介绍SR-IOV及实践openstack的SR-IOV功能的过程。sriov功能介绍
SR-IOV 使一个单一的功能单元（比如，一个以太网端口）能看起来像多个独立的物理设备，即支持SR-IOV 功能的物理设备能被配置为多个功能单元。
SR-IOV 两种功能（function）：
[*]物理功能（Physical Functions，PF）：这是完整的带有 SR-IOV 能力的PCIe 设备。PF 能像普通 PCI 设备那样被发现、管理和配置。
[*]虚拟功能（Virtual Functions，VF）：简单的 PCIe 功能，它只能处理I/O。每个 VF 都是从 PF 中分离出来的。每个物理硬件都有一个 VF 数目的限制。一个 PF，能被虚拟成多个 VF 用于分配给多个虚拟机。
Hypervisor 能将一个或者多个 VF 分配给一个虚机。在某一时刻，一个 VF 只能被分配给一个虚机。一个虚机可以拥有多个 VF。在虚机的操作系统看来，一个 VF 网卡看起来和一个普通网卡没有区别。SR-IOV 驱动是在内核中实现的。 网卡 SR-IOV 的例子：
光纤卡 SR-IOV 的例子：
OpenStack实践SR-IOV
系统运行环境：
系统：Centos 6.6,Intel 82576
openstack版本: Juno
配置计算节点物理主机：
开启 VT-d #BIOS配置
开启IOMMU功能 #在文件中添加 /boot/grub.confintel_iommu=on
创建VF设备 #modprobeigb max_vfs=8 或 echo 8 > /sys/class/net/ethx/device/sriov_numb
配置Openstack(Juno)：
Controller Node:
1.配置sriov mechanism driver
编辑 /etc/neutron/plugins/ml2/ml2_conf.ini
2.配置支持SR-IOV网卡类型
查看系统网卡类型 lspci -nn | grep Eth
编辑 /etc/neutron/plugins/ml2/ml2_conf_sriov.ini
3.修改 neutron-server 脚本 /etc/init.d/neutron-server
4.重启neutron-server 服务.
Compute Node:
1.配置计算节点 PCI Device重启 openstack-nova-compute 服务
编辑 /etc/nova/nova.conf
2.配置计算节点 neutron-sriov-agent
编辑 /etc/neutron/plugins/ml2/ml2_conf_sriov.ini
3.启动neutron-sriov-agent 服务
虚机使用SR-IOV网卡的步骤：
1.创建sriov类型的Port
# neutron port-create ${net-id} --binding:vnic-type direct
2.创建虚机
#nova boot --flavor${flavor_name} --image${image_id} --nic port-id=${port_id} ${vm_name}
实践总结
Openstack(Juno)使用SRIOV特性存在以下局限：
[*]不支持迁移
[*]不支持卡的热插入虚机
[*]不支持虚机的Qos .
[*]不支持安全组
[*]仅支持Vlan
虚机使用sriov类型的网卡时，1.创建sriov类型的Port .2.将sriov类型的Port分配给虚机.
注
1) 暂时不支持迁移，
冷迁移：
https://bugs.launchpad.net/nova/+bug/1400784
https://bugs.launchpad.net/nova/+bug/1512880
热迁移：虚机直接使用物理设备造成不能实时迁移和保存，https://blueprints.launchpad.net/nova/+spec/sriov-live-migration
后续跟进macvtap，Liberty支持macvtap https://blueprints.launchpad.net/nova/+spec/libvirt-macvtap-vif。
2) sriov类型虚拟网卡只能新建时加入目标虚机。在创建虚机时，nova会关联Instance和sriov类型port(保存到数据库)
和配置binding profile信息，interface_attach则会不能配置bind profile导致port绑定失败。
3) 不支持虚机的Qos，最终支持虚机Qos。openstack对Qos有两种支持方式 ：1.基于
Qos-Service ,Agent(OVS,sriov)，该部分功能代码还在master分支. 2. 基于虚机的Quota(Libvirt ,TC).
4) 系统环境(centos6.6 + intel 82576)不支持管理员手动配置vf的状态，计算节点不需要启动neutron-server-agent服务.
5) 创建vnic-type为macvtap类型的sriov的port，计算节点libvirt会产生设置ethx(vf对应的eth) MAC的错误.
6)在创建虚机时可以指定Net，不能指定被创建Port的vnic-type。 建议后期将Port抽象成虚拟网
卡的概念，用户直接管理虚机网卡类型。后续通过扩展，提供方便的sriov类型网卡使用方式。
需要处理的问题：无ovs-agent服务的计算节点(仅支持sriov类型的port)，可能会被选中来vnic-type为normal的虚拟网卡，这样
会导致虚机启动失败，建议计算节点有开启neutron-openvswitch-agent，创建非sriov类型的网卡。
*使用SRIOV Feather 怎么物理网卡的的HA ?
SRIOV直接从物理网卡分配VF，VF的状态与PF的状态保持一直，物理网卡或网卡直连的交换机down都会引起VF不能正常通信，应该怎么处理这个问题呢？
在OVS的场景下bonding多块网卡保证网卡HA。在SRIOV的场景下直接bonding物理网卡，并不能网卡HA的问题，因为VF状态与物理网卡保持一致，VF直接通过物理网卡处理packet。
方案参见：https://communities.intel.com/thread/54061?start=0&tstart=0
Openstack 网卡bonding 参见：https://blueprints.launchpad.net/nova/+spec/libvirt-sriov-nic-bonding
参考文档：
http://www.openstack.cn/?p=2118
http://www.ovirt.org/Feature/SR-IOV
http://www.cnblogs.com/sammyliu/p/4548194.html
http://docs.openstack.org/networking-guide/adv_config_sriov.html
页:
[1]