Neutron 把网络连接抽象成 Network、Subnet、Port、Router 和 Security Group。日常操作中最容易混淆的是：网络只是二层范围，子网负责地址规划，端口才代表虚拟网卡的连接点。SR-IOV 又引入 PF、VF、物理网络映射和特殊 VNIC 类型，需要更严格的前置检查。
## 1. Network、Subnet 与 Port
- Network：二层广播域或逻辑网络，可由 VXLAN、Geneve、VLAN、flat 等类型承载。
- Subnet：IP 地址段、网关、DNS 和地址池配置。
- Port：设备接入网络的连接点，保存 MAC、固定 IP、安全组、绑定主机和 VNIC 类型。
- Router：连接不同子网或提供外部网络访问。
- Floating IP：将外部可达地址映射到端口固定 IP。
查看资源：
```bash
openstack network list
openstack subnet list
openstack port list
openstack router list
openstack floating ip list
```
## 2. 创建普通租户网络
```bash
openstack network create app-net
openstack subnet create \
--network app-net \
--subnet-range 192.0.2.0/24 \
--allocation-pool start=192.0.2.100,end=192.0.2.200 \
--gateway 192.0.2.1 \
--dns-nameserver 1.1.1.1 \
app-subnet
```
创建前确认 CIDR 不与现有租户、管理网络、存储网络和外部网络冲突。若关闭 DHCP，实例内部地址必须通过其他受控方式配置。
## 3. Provider VLAN 网络
管理员可把 Neutron 网络映射到物理网络和 VLAN：
```bash
openstack network create \
--provider-network-type vlan \
--provider-physical-network physnet1 \
--provider-segment 120 \
provider-vlan120
```
随后创建子网。physnet1 必须在相关网络节点或计算节点的机制驱动中正确映射，交换机 Trunk 也要允许对应 VLAN。VLAN ID 冲突、接口未加入桥、物理映射错误都会导致端口看似 ACTIVE 但业务不通。
## 4. 固定 IP 端口
```bash
openstack port create \
--network app-net \
--fixed-ip subnet=app-subnet,ip-address=192.0.2.120 \
app-port
openstack port show app-port
openstack server add port VM_NAME app-port
```
指定地址前应确认它属于子网分配范围、没有被其他端口占用，并符合 DHCP 与地址管理策略。不要只在虚拟机内部手工改 IP，而忽略 Neutron 端口记录。
## 5. SR-IOV 的原理
SR-IOV 让一个物理网卡 PF 创建多个 VF，VF 可以直接分配给虚拟机。数据绕过传统虚拟交换层，通常能获得更低时延和接近线速的性能，但也减少了虚拟交换层可提供的可观测性和部分安全能力。
启用 SR-IOV 通常需要：
1. BIOS、IOMMU 和网卡支持已开启。
2. 计算节点创建足够 VF。
3. Nova 配置 PCI device spec 或 resource provider。
4. Neutron ML2 启用 SR-IOV mechanism driver。
5. 每个相关计算节点运行 sriov-nic-agent。
6. physnet 与物理接口/VF 映射正确。
7. 调度、NUMA 和 Huge Page 约束得到满足。
## 6. 创建 SR-IOV 端口和实例
```bash
openstack port create \
--network provider-vlan120 \
--vnic-type direct \
--fixed-ip subnet=provider-subnet \
sriov-port-01
openstack server create \
--flavor sriov-flavor \
--image IMAGE_NAME \
--port sriov-port-01 \
sriov-vm
```
如果实例需要普通管理口和 SR-IOV 业务口，可以显式传入多个端口。管理口通常使用 normal 类型，业务口使用 direct；端口顺序是否影响 guest 网卡命名取决于镜像和初始化方式，不应只依赖 eth0/eth1 的偶然顺序。
## 7. normal 端口能否改成 direct？
某些环境允许对未绑定端口执行：
```bash
openstack port set --vnic-type direct PORT_ID
openstack port show PORT_ID -c binding:vnic_type -f value
```
但这不是所有驱动和状态下都安全或受支持。对已绑定实例的 normal 端口，推荐流程是：
1. 确认目标网络支持 SR-IOV，计算节点有可用 VF。
2. 创建新的 direct 端口。
3. 在维护窗口停止或隔离业务。
4. 按当前 OpenStack 版本支持的流程附加新端口。
5. 在 guest 内配置并验证路由、MTU、MAC 和业务流量。
6. 确认稳定后再移除旧端口。
直接修改一个已绑定端口的 binding 属性可能导致重新绑定失败、实例网络中断或资源分配不一致。生产变更前应验证驱动、Nova/Neutron 版本和迁移限制。
## 8. SR-IOV 的限制与风险
- direct 端口在迁移时可能出现短暂中断，具体取决于版本、驱动和 guest 内的故障切换设计。
- SR-IOV agent 不提供传统虚拟交换防火墙能力；安全组支持取决于硬件 offload、驱动和部署方式。
- VF 数量有限，需要纳入 Placement 资源和容量规划。
- MAC、VLAN、spoof checking、trusted VF 和 QoS 支持受网卡与驱动影响。
- 多 NUMA 节点服务器需注意 VF、CPU pinning 和内存拓扑对齐。
## 9. 排查端口绑定
```bash
openstack port show PORT_ID -f yaml
openstack network agent list
openstack server show VM_NAME
openstack hypervisor show COMPUTE_HOST
```
重点检查：
- binding:vnic_type 是否正确。
- binding:host_id 是否为目标计算节点。
- 端口状态和 binding profile 是否异常。
- sriov-nic-agent 是否 Alive。
- 计算节点 VF 是否存在、驱动是否正确。
- physnet、VLAN、交换机 Trunk 与 MTU 是否一致。
- Nova scheduler 是否因为 PCI/NUMA 条件返回 NoValidHost。
Guest 内还要检查 PCI 设备、接口、MAC、IP、路由和抓包结果。端口 ACTIVE 只是控制面状态，不代表端到端流量一定正常。
## 参考资料
- https://docs.openstack.org/neutron/latest/admin/config-sriov
- https://docs.openstack.org/python-openstackclient/latest/cli/command-objects/port.html