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基本都是在这层做文章。
本文来自网易实践者社区,经作者赵建明授权发布。