本文來自 網易雲社群 。

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  
版權宣告：本文為博主原創文章，轉載請附上博文連結！