qemu+kvm的IO路径分析

本文来自 网易云社区 。

openstack之所以选择kvm作为底层虚拟化的主要方案，从我个人的角度分析应该与Redhat背后推动libvirt和kvm这两层组件密不可分。libvirt目前基本上已经等同于machine层虚拟化的glibc，而kvm方案随着linux一起演进加上不断在架构和性能上的优化，已经逐渐成为主流。

由于kvm是基于host linux的虚拟化方案，所以在谈到kvm的io路径时首先来认识一下linux系统的IO路径：

   

从linux系统的IO图可以很清楚的看到，普通用户发起的IO操作其实经过了一系列很复杂的流程，一般由系统调用进入，经过VFS层分流到具体的文件系统层，最后通过block layer才真正抵达硬件驱动层。这种分层抽象的模型一直是软件设计者的追求，通过层次化来解耦复杂的问题。而对于qemu+kvm虚拟化方案来说，这种层次更加明显。

对于整个kvm虚拟化系统来说，qemu只是一个用户态的程序，而在这个用户态的程序之中又跑着一个操作系统镜像，所以整个qemu+kvm对于用户来说其实就是两层的系统IO栈+虚拟化接口。下图是一个使用virtio-blk模式的io栈：

我们知道在基于host linux的kvm虚拟化方案中IO基本上是由qemu模拟实现的，在最初的实现方案中由于每次io都需要vm context的切换，这个成本非常高，所以virtio应运而生了，利用前后端驱动以及io缓冲队列的模式来降低这种消耗。在虚拟化的范畴中，io优化主要还是考虑由于虚拟化层加入所带来的额外路径上的优化，虽然系统IO栈的优化也能提升整个路径上的效率，但毕竟各司其职才能发挥各自的优势，系统栈的优化主要还是留给了搞kernel的人，所以我们看到的QEMU+kvm的io优化大多数是还在集中在虚拟化接口层。包括virtio和后续会具体分析的virtio-blk-dataplane基本都是在这层做文章。

 

原文：qemu+kvm的IO路径分析

本文来自网易云社区，经作者赵建明授权发布。
---------------------  
作者：网易云  
来源：CSDN  
原文：https://blog.csdn.net/wangyiyungw/article/details/81069522  
版权声明：本文为博主原创文章，转载请附上博文链接！