1. 核心结论 (Conclusion)
libvirt 的原生 XML 配置仅支持“带宽（BPS）”限制，不支持“包速率（PPS）”限制。 在 libvirt 的设计定义中，网络 QoS 被严格限制在流量体积维度（throughput），而没有扩展到报文数量维度（packets）。
2. 技术逻辑分析 (First Principles Analysis)
我们可以从 libvirt 的实现机制深入分析为什么 PPS 会缺失：
A. 语义模型的局限 (XML Schema)
libvirt 的 <bandwidth> 标签在设计之初就是为了模拟物理链路的吞吐量。
- 其定义的单位是
KiB/s（千字节每秒）。 - 在
libvirt的源码抽象层（virNetDevBandwidth），它没有预留任何字段来存储“报文数量”这一度量衡。
B. 底层工具链的映射 (tc mapping)
libvirt 主要是 tc 的“命令行生成器”。
- BPS 映射：对应
tc class add ... htb rate或tc filter ... police rate。 - PPS 映射：虽然 Linux 内核的
act_police模块支持pkts限制，但 libvirt 的 C 语言代码库中并没有逻辑去构造包含pkts关键字的tc指令。
C. 资源开销的不对称性
在传统的虚拟化视图中：
-
带宽（BPS） 消耗的是网络链路资源。
-
PPS 消耗的是宿主机的 CPU 资源（中断处理、协议栈上下文切换）。
libvirt 历史上倾向于将 CPU 资源控制交给
cgroups（如cpu_shares），而不是在网络协议栈层级通过网络参数来间接限制 CPU 消耗。
3. 横向对比：网络 vs 磁盘
有趣的是，libvirt 在处理 磁盘 I/O 时，逻辑完全不同：
| 资源类型 | 支持 BPS 限制？ | 支持 PPS/IOPS 限制？ |
|---|---|---|
| 网络 (Network) | 支持 (inbound/outbound) | 不支持 |
| 磁盘 (Storage) | 支持 (read_bytes_sec) | 支持 (read_iops_sec) |
原因分析：磁盘的 IOPS 限制是直接通过 QEMU 的 Block Layer 实现的，QEMU 对每一笔 I/O 都有完整的控制权。而网络 QoS 是在宿主机内核 tc 层实现的，libvirt 对内核功能的抽象粒度较粗，导致了这种能力上的差异。
4. 进阶视角 (For Kube-OVN/Cilium Maintainer)
作为深度参与容器网络的维护者，你可能更关注如何填补这个空白。如果必须在 libvirt 环境下实现 PPS 限制，目前只有以下“非官方”路径：
- Hook 脚本：利用 libvirt 的
qemu-hook机制，在虚拟机启动阶段，通过外部脚本直接调用tc命令在tap设备上追加pkts限制。 - OVS OpenFlow：如果是基于 OVS，可以下发带有
meter的流表，限制特定端口的 PPS。 - eBPF TC Hook：在
tap设备的clsacthook 点挂载一个简单的 eBPF 计数器和丢包器。这比tc police更高效，且不会引入全局锁。
5. 总结
在 libvirt 的世界里，网络被抽象为一根“管子”，它只管管子有多粗（BPS），不管管子里流过的是大石头还是细沙（PPS）。如果你需要防御小包攻击或精细化流量调度，libvirt 并不是一个理想的控制点，通常需要下沉到 CNI 或宿主机网络基础设施层去解决。
