COTS里面涉及到虚拟机的概念，所以网络稍微复杂一点点。

基本概念

目前虚拟机里面常见的网卡控制器有三类：

1. 半虚拟化网卡设备，由Hypervisor统一管理，虚拟机里面采用特定的接口进行调用。
   1. 透传网卡设备，将一个PCIe设备（网卡、USB、光驱…）直接分配给指定的虚拟机独占，一般需要开启IntelVT-D技术
   2. SR-IOV网卡设备，结合上述的两种优势，他先在Hypervisor里面注册成多个网卡，再把这些网卡透传分配给虚拟机。（需要NIC硬件支持）

   :fa-location-arrow: 如果是C7K架构，一般一个Blade上面只创建一个VM，所以跨板（Between-Appls）的交换能够使用C7K自带的L2Switch(6120XG),同时H248消息也是从这个交换板来转发到SCM上。至于数据包是直接从PIM板连出去的吗？ 存疑？
   :fa-location-arrow: 针对我们的数据包，能够使用的物理卡是各个Blade上的GE口和6120XG，一般来说最好的打算就是每个虚拟机PF自己所在Blade的那个GE口（如果只有一个虚拟机Per-Blade）
   :fa-location-arrow:如果是DL380一个Blade上做BGW，那么最好的打算是半虚拟化方式，同时，一个Blade的话就没有L2Switch(6120XG)了，所以必须要有vSwitch来扮演这个角色，那么问题就在于vSwitch会不会成为瓶颈？（因为数据包+控制包都在上面交换的= =！）
   :fa-location-arrow:如果在DL380上插Intel-Niantic-NIC，那么最好的打算是SR-IOV方式来分配vNIC，同时也会需要vSwitch的帮助，DPDK的作用目前来说只用于DATA-PATH的交换过程。

虚拟机

机箱里面的虚拟机相关背景知识：
KVM和QEMU的关系
当一起工作的时候，KVM管理CPU和MEM的访问，QEMU仿真硬件资源（硬盘，声卡，USB，等等）当QEMU单独运行时，QEMU同时模拟CPU和硬件。
准确来说，KVM是Linux kernel的一个模块。可以用命令modprobe去加载KVM模块。加载了模块后，才能进一步通过其他工具创建虚拟机。但仅有KVM模块是 远远不够的，因为用户无法直接控制内核模块去作事情,你还必须有一个运行在用户空间的工具才行。这个用户空间的工具，kvm开发者选择了已经成型的开源虚拟化软件 QEMU。说起来QEMU也是一个虚拟化软件。它的特点是可虚拟不同的CPU。比如说在x86的CPU上可虚拟一个Power的CPU，并可利用 它编译出可运行在Power上的程序。KVM使用了QEMU的一部分，并稍加改造，就成了可控制KVM的用户空间工具了。所以你会看到，官方提供的KVM 下载有两大部分(qemu和kvm)三个文件(KVM模块、QEMU工具以及二者的合集)。也就是说，你可以只升级KVM模块，也可以只升级QEMU工 具。这就是KVM和QEMU 的关系。

QEMU是个独立的虚拟化解决方案，从这个角度它并不依赖KVM。 而KVM是另一套虚拟化解决方案，不过因为这个方案实际上只实现了内核中对处理器(Intel VT, AMD SVM)虚拟化特性的支持，换言之，它缺乏设备虚拟化以及相应的用户空间管理虚拟机的工具，所以它借用了QEMU的代码并加以精简，连同KVM一起构成了另一个独立的虚拟化解决方案，不妨称之为：KVM+QEMU.
关于Virtio:fa-link:的具体介绍。
实际上虚拟化和半虚拟化都是概念性的东西，针对每个资源都可以有相当的自行配置空间，譬如NIC设备，
如果全虚拟化方式，那么这块卡的所有包都要经过全虚拟化层的模拟器来转发给各个虚拟机，
如果不用模拟器，而是能够透过特殊的Hypervisor层API调用网卡，那么这就称为半虚拟化，
如果我想把这块卡让某个虚拟机独占使用，那么可以使用PF方式，
如果网卡硬件支持SR-IOV，那么就可以注册出好几个卡，然后PF给多个虚拟机。

遗留问题：

1. COTS中包交换的网络拓扑： ？
2. DL380中包交换的网络拓扑： ？