如前所述，网络虚拟化是只有内核虚拟化功能开发者才关注的技术。 但是，随着云计算模式和云本机概念的普及，云上业务的部署方式转向虚拟机和容器，两者都依赖网络虚拟化技术提供高性能的网络功能，因此虚拟网络将成为云环境云上的虚拟机和容器对网络虚拟化技术的易用性、功能和性能提出了更高的要求。
对于云环境中的网络基础设施开发者来说，网络虚拟化已经成为一项必须掌握的技术。 但是，在学习网络虚拟化技术时，笔者找不到能完全介绍网络虚拟化技术类型、原理和实现的信息源，特别是中文资料。 为此，笔者拟将学习网络虚拟化技术过程中收集到的信息进行总结，形成一系列介绍各种网络虚拟化技术的文章，供后续学习和工作参考。 各种技术从笔者最关心的问题出发，介绍相关知识，试图回答这些问题。
本文的第一篇文章介绍了最典型的网络虚拟化技术——QEMU虚拟网卡。
问题使用QEMU虚拟网卡时，来宾系统如何使用网卡和网络？ 您是否知道虚拟化设备的存在？ 是否需要使用与在物理计算机上运行时不同的配置？ 需要更改内核吗？ 在来宾系统中如何识别和加载网卡？ QEMU是如何支持此功能的？ 如何在guest系统上通过网卡发送和接收消息QEMU如何支持此功能？ guest系统发送和接收的消息在QEMU和host系统中是如何流动的？ guest与host、guest与外部网络的交互在什么阶段实现？ QEMU虚拟网卡支持虚拟机的网络功能有哪些优势和劣势？ QEMU QEMU是在LINUX平台上广泛使用的虚拟机管理器(VMM )，可模拟各种硬件体系结构和设备，并支持各种操作系统的模拟其中，QEMU支持特定NIC设备(例如e1000 )的完全虚拟化，允许来宾操作系统和内核在不进行任何修改的情况下使用原始NIC驱动程序完成网络操作。
QEMU-KVM体系结构图(来自wiki.qemu.org ) )。
有关qmu模拟IO设备的原理，请参见卸载qmu设备和高级别开发虚拟化'慢级别。 一般而言，QEMU在通过命令翻译或基于KVM和CPU的硬件虚拟化对设备进行guest操作时，即在执行访问设备的地址空间或寄存器的命令时，中断guest的执行流程
QEMU虚拟网卡用作网络IO设备，在QEMU中的模拟实现与其他IO设备相同。 通过QEMU模拟，在来宾系统中使用虚拟网卡的方式和感受与在物理机上使用的方式完全相同，无需更改内核驱动程序或配置。
guest系统对网卡的识别和加载的模拟与其他设备的模拟相同，网卡的识别来自QEMU对PCI/PCIE总线设备的模拟，网卡的加载、加载
qmu实现了多种经典网卡设备的模拟，包括e1000、rtl8139和i82559c。 网卡设备和驱动程序的逻辑相似，下面以e1000的网络消息收发为例，分析一下guest中网络rx/tx操作的实现逻辑步骤。 主流的x86体系结构CPU支持CPU硬件虚拟化，如英特尔的VT-x和AMD的AMD-V，因此，这里只介绍QEMU-KVM方案。
TX :
guest内核将tx消息的内容写入skbguest内核，然后descriptor ringguest内核将tx消息信息(例如数据的dma地址、长度等)写入网卡的tx队列寄存器， 处理tx消息并通知网卡启动VM Exit，KVM处理VM Exit事件以发现KVM是IO操作，然后返回用户状态的QEMU进程(QEMU进程从IOctl返回) QEMU向IOctl返回根据描述符内容将消息传输到QEMU以更新虚拟网卡的状态和DMA内存QEMU，然后从KVM接口再次恢复guest运行(VM Entry ) RX。
QEMU接收到rx消息的QEMU将rx消息的内容写入guest指定的DMA地址空间QEMU，将rx消息信息写入描述符环形QEMU，并更新rx队列寄存器(虚拟) QEMU 更新描述符ring和寄存器，现在又陷入QEMU是一个简单的流程，guest处理消息的逻辑与物理机相同，Linux系统上的网络分组处理流_dillanzhou的块注入原理可参考高水平整合虚拟化'慢水平。
通过上述流程，来自guest的消息通过QEMU转发到主机内核或网络，从主机或网络发送到guest的消息也通过QEMU转发到guest虚拟网卡。
在QEMU虚拟网络之前，我们介绍了QEMU如何模拟guest网卡的行为，但存在一个问题，即消息如何在QEMU到主机内核/网卡之间流动。 说起来，guest需要通信的对象就不是QEMU本身。 此功能的一部分称为虚拟网络后端。
qmu支持的网络后端模式实施主要有两种： slirp(user )和TAP。
SLIRP模式是在用户状态下实现的后端。 在此模式下，QEMU在用户状态下分析gues
t收发的网络报文，并向其他guest和host转发。同时SLIRP还支持NAT地址转换。这就要求在SLIRP模式下实现一套TCP/IP协议栈。SLIRP的实现笔者没有看过，也没有找到详细介绍其原理的文章。据找到的个别资料介绍，SLIRP在和host或外部网络通信时，并不是通过raw socket转发报文的形式实现的，而是通过将guest报文的行为翻译成普通socket操作来实现的，例如guest发送了一个SYN包，SLIRP就调用一个到目标地址的connect syscall。这个实现听起来有些不可思议，但SLIRP本身来自于很古老的协议模拟软件，因此也是可以理解的。但这种实现功能必然有限，如果guest发送一些不太标准的报文或SLIRP协议栈不能理解或处理的报文，那么网络功能必然不能正常运行。TAP模式就比较好理解了。这种模式下QEMU为每个guest创建一个tap设备，直接向这个tap设备收发报文。tap设备可以连接到一个bridge上实现更复杂的路由功能。
其实guest报文到了QEMU用户态逻辑之后，后端的实现方式可以有很多种，例如OVS或OVS-DPDK。这部分的功能与虚拟化其实已经没有太多的关系，更多是网络报文处理转发能力的实现。后续将不再重点讨论这部分技术。
小结本文分析了QEMU的经典网络虚拟化实现：物理网卡虚拟，以及QEMU的经典后端实现方式：SLIRP和TAP。通过本文的分析，应该已经可以回答文章开头提出的4个问题：
1. 使用QEMU虚拟网卡时，guest系统中是如何使用网卡和网络的？是否感知虚拟化设备的存在，是否需要和运行在物理机上时使用不同的配置？是否需要修改内核？
答案是不需要，guest完全不用感知或修改网络使用方式。
2. 在guest系统中如何感知和加载网卡？QEMU是如何实现来支持这种功能的？
通过拦截和模拟实现guest的PCI和网卡设备访问操作，让guest获得和在物理机上相同的操作结果。
3. 在guest系统中如何通过网卡收发报文？QEMU是如何实现来支持这种功能的？
同样通过拦截和模拟实现guest的网卡操作，并将外部发给guest的报文也通过模拟的方式交给虚拟机处理并注入中断。
4. guest系统收发的报文，在QEMU和host系统中是如何流转的？通过哪些环节实现guest和host、guest和外部网络间的交互？
通过SLIRP或TAP模式将报文转发到host或外部网络。
5. 用QEMU虚拟网卡方式支持虚拟机网络功能有哪些优点和不足？
QEMU虚拟网卡方式实现网络功能的优点是对guest系统透明，不需要guest系统做任何修改，使用物理网卡驱动就能操作虚拟网卡完成网络通信。
这种实现方式的主要缺点有两个。一是需要用软件去模拟各种真实物理硬件网卡的功能，由于硬件网卡功能复杂而缺乏标准，因此QEMU模拟网卡的代码也复杂多变，而且可能存在软件模拟的网卡行为和硬件不一致，导致guest系统中的网络行为和host上出现差异。
另一个更明显的缺点是性能。根据前面的分析，每次读写网卡寄存器或IO地址时都会导致guest应用到QEMU进程的来回切换，而一次网络读写操作可能会产生多次网卡IO操作，这就导致使用QEMU虚拟网卡时虚拟机的网络性能受限于上下文和guest/host切换的速度，必然远低于物理机的性能水平。