下面是小凰凰的簡介，看下吧！
💗人生態度：珍惜時間，渴望學習，熱愛音樂，把握命運，享受生活
💗學習技能：網絡 -> 雲計算運維 -> python全棧( 當前正在學習中)
💗您的點贊、收藏、關注是對博主創作的最大鼓勵，在此謝過！
有相關技能問題可以寫在下方評論區，我們一起學習，一起進步。
後期會不斷更新python全棧學習筆記，秉着質量博文爲原則，寫好每一篇博文。
文章目錄
一、kvm認識
上次我們已經將kvm安裝成功了。我們在fusion虛擬機上執行下面命令：
發現kvm虛擬機在fusion上表現出來的是一個進程！kill這個進程就相當於關閉了kvm虛擬機！因爲它是進程，當時間片到（時間片輪轉+多級反饋隊列），進程調度起作用，那麼kvm在運行過程中就可能一會兒調度在這個cpu，一會兒又在那個cpu，這樣kvm性能大大降低。這是一個優化的點，後面會說！
注意：virsh是libvirtd下的一個管理kvm的工具。在kvm運行中，如果把libvirtd停了，不會影響kvm的運行。但是無法用virsh命令管理kvm了！在kvm啓動前，把libvirtd停了，kvm便運行不了。因爲上述進程圖片中，我們能看到kvm有很多參數，有部分參數是libvirtd加的，如果開啓kvm之前停了libvirtd，kvm將無法啓動！
二、kvm管理
libvirt對kvm虛擬機進行管理其實是基於一個xml文件：
這個xml文件是python代碼自動生成的。修改這個xml，就可以修改對應kvm虛擬機的配置！但是這個不能直接進行vim編輯。需要通過virsh命令對其進行修改
1、cpu的熱添加、熱刪除
centos7版本之後，我們可以通過修改xml文件中的cpu個數，實現cpu的熱添加、熱刪除。但是需要你的kvm虛擬機所在的宿主機（即我這裏的fusion虛擬機）也是centos7的，不然無法熱添加、熱刪除。然後很多人就會有下面這個疑問了：
'爲什麼我的阿里雲主機不能熱添加、熱刪除cpu呢？還需要重啓之後才能添加上！'
答（兩點原因）：
1. 其實你的阿里雲主機就是一個kvm虛擬機，之所以不支持熱添加、熱刪除是因爲你虛擬機所在的宿主機不一定是centos7的，即使是centos7，這個宿主機上肯定還有其他好多kvm虛擬機的，你能保證所有人都買的是centos7系統的雲主機嗎？因此與其部分人支持，部分人不支持，不如直接都不支持！
2. 假設你的雲主機被調度到阿里雲中的一個cpu、內存等快溢出的服務器，如果你再熱添加cpu，豈不是就把服務器給整崩了！因此你需要關機，然後添加cpu，然後再開機，這樣阿里雲會根據你當前的服務器配置調度到一個合理的雲服務器上。
# cpu熱添加、熱刪除實現
virsh edit Centos7.4 # 編輯Centos7.4kvm虛擬機的xml文件
<vcpu placement='static'>1</vcpu> # 找到這一項，這是靜態cpu，不支持熱添加、刪除
將其改成：
<vcpu placement='auto' current='1'>4</vcpu> # auto表示自動添加刪除，current表示目前cpu爲一個，中間的4表示最大可添加到4個！
virsh setvcpus Centos7.4 2 --live # 給Centos7.4虛擬機設置2個cpu，這裏的--live是熱添加的意思，給活着的虛擬機添加cpu嘛
注意：雲計算的一個重要的認知，無論你硬件資源怎麼添加，都不能超過當前宿主機的硬件資源擁有數。也即是：我fusion虛擬機不能超過我物理機的cpu個數，我kvm虛擬機不能超過我給fusion虛擬機分配的cpu個數！我物理機cpu個數爲4，fusion虛擬機分配的是2個。因此這裏我的kvm虛擬機最多分配兩個cpu，再多分配就會報錯！
注意：virsh edit Centos7.4編輯虛擬機xml文件，裏面所做的任何操作，都必須重啓kvm虛擬機才能生效。
2、內存熱添加、熱刪除
kvm有一個內存氣球的機制，負責內存的熱添加及刪除。
virsh edit Centos7.4 # 編輯Centos7.4kvm虛擬機的xml文件
<memory unit='KiB'>1048576</memory> # 最大內存
<currentMemory unit='KiB'>1048576</currentMemory> # 當前內存大小，但是不會隨下面設置內存的變動而變動！它是不變的，相當於就是一個初始內存大小。
virsh qemu-monitor-command Centos7.4 --hmp --cmd info balloon # 查看當前內存
virsh qemu-monitor-command Centos7.4 --hmp --cmd balloon 512 # 設置內存大小,注意這個你隨便設置多大都不會報錯，但是這樣設置並不會生效，只會給你當前xml文件中定義限制的最大內存。
注意：virsh edit Centos7.4編輯虛擬機xml文件，裏面所做的任何操作，都必須重啓kvm虛擬機才能生效。
3、網絡模式
之前我們說過：–network default默認採用的橋接模式就是基於nat的橋接模式，即默認採用libvirt生成的virbr0網卡，kvm虛擬機和fusion虛擬機並不在一個網段裏。
上圖就是default默認網絡的kvm虛擬機生成的ip，由此可見的確採用了libvirt產生的virbr0網橋，採用nat模式，nat模式網絡開銷較大，不推薦。我們應該讓kvm虛擬機和fusion虛擬機在一個網段！這樣內網通信，省去了地址轉換的開銷！
# 因爲Centos7.4這個虛擬機已經是橋接了，因此我又建了一個--network default的虛擬機，名爲centos7
1. 修改centos7kvm虛擬機的xml文件
virsh edit centos7 # 編輯centos7kvm虛擬機的xml文件
<interface type='network'>
<source network='default'/>
將上面那兩句改成下面這樣：
<interface type='bridge'>
<source bridge='br0'/> # 注意橋接網卡統一叫br0.
2. 給fusion虛擬機臨時創建橋接網卡br0
brctl addbr br0 # 建立一個邏輯網段，名稱爲br0,可以把這個邏輯網段看作一個vlan
brctl addif br0 ens33 # 讓ens33成爲br0和外界交互的端口
ifconfig ens33 0.0.0.0 # 網橋的每個物理網卡作爲一個端口，運行於混雜模式，而且是在鏈路層工作，所以就不需要IP了。
ifconfig br0 172.16.193.200 # 然後把ens33的ip給br0配置上。
3. 這樣添加了橋接網卡的fusion虛擬機，你會發現ping不同外網！這是因爲沒有了網關。
route add default gw 172.16.193.2
# 爲什麼？因爲原來的網關是在ens33的ifcfg-ens33配置文件裏放着的，現在你把ens33給廢了，網關也就沒了。
# 雖然fusion虛擬機上不到外網，但是kvm虛擬機竟然自己配了172.16.193.2爲網關，可以上外網！
'kvm虛擬機能上外網這是爲什麼？'kvm虛擬機的網卡eth0的配置文件中是dhcp的，因此可以自己發現網關
4. 重啓kvm虛擬機，使xml文件的配置生效！
virsh shutdown centos7
virsh start centos7
成功使kvm與fusion虛擬機在一個網段！
建議看下docker的橋接模式的詳解和kvm虛擬機是一樣的：https://blog.csdn.net/weixin_44571270/article/details/104444960
三、kvm性能優化
1、cpu優化
（1）上下文切換速度優化（intel-VT技術）
注意：有人會問上下文切換咋又和cpu扯上關係了。上下文切換即是cpu處理各個進程的切換，達到併發的效果，使多個程序能看起來並行！上下文切換即爲cpu對進程的調度！
Intel的CPU將特權級別分爲4個級別：RING0,RING1,RING2,RING3。Windows只使用其中的兩個級別RING0和RING3（ring0代表內核態，ring3代表用戶態），RING0只給操作系統用，RING3誰都能用。
注意：生產環境中，一般我們都直接在宿主機上做kvm虛擬機，不會有fusion虛擬機的存在，因此這裏不考慮fusion虛擬機！
# 首先我們有兩個機器：
kvm虛擬機
ring 3
ring 0
宿主機
ring 3
ring 0
kvm需要一個文件，首先從'kvm ring3'轉換成'kvm ring0',由於kvm是一個進程'運行在宿主機的ring3上',因此還需要宿主機 ring3 轉換到 宿主機 ring0，然後再找操作系統要數據。
# 需要兩次用戶態到內核態切換
注意:'從用戶態轉換到內核態也是一種上下文切換，因此切換速度就影響着虛擬機的性能！'
因此我們需要優化上下文切換的速度！
這個intel VT-x就是爲我們加快上下文切換速度的一個技術！
（2）緩存命中優化（綁定cpu）
cpu三級緩存圖解：
一級緩存是靜態緩存，其分爲L1d數據緩存，L1i命令緩存。L2和L3是高速動態緩存。我們kvm運行是可以被調度在其他cpu上的，假如原來我kvm在cpu1上運行，kvm的緩存也在cpu1上，下次被調度到其他cpu，那麼找緩存就在cpu2上找，那麼就cache miss了！就會訪問主存，主存如果再沒有就訪問硬盤。這樣cache miss開銷就很大了吧！
# 解決方案
將kvm綁定在一個cpu上，或一個cpu的一個核上！每次運行都在一個指定的cpu上運行，這樣就提高了cache命中率！
# 注意：綁定cpu這樣雖然提高了性能，但也喪失了靈活性，如果那個cpu已經滿負荷運轉，就會造成kvm虛擬機宕機。
# 實現kvm的cpu綁定
taskset -cp 1 25718 # 25718是kvm的進程，將進程綁定在cpu上，以提高性能！
上面的1是1號cpu，'有點類似nginx的work進程綁定cpu，提高性能！'
nginx的work進程綁定cpu:
2、內存優化
（1）空間優化（intel EPT技術）
注意：生產環境中，一般我們都直接在宿主機上做kvm虛擬機，不會有fusion虛擬機的存在，因此這裏不考慮fusion虛擬機！
# 學過操作系統都知道，通過頁表將虛擬內存地址映射到物理內存地址，這裏還涉及到虛存技術（覆蓋技術、交換技術、虛存技術）
kvm虛擬機
虛擬內存
物理內存
宿主機
虛擬內存
物理內存
# 因此我們的虛擬機訪問物理內存，需要將kvm的虛存映射到kvm 物理內存，kvm物理內存其實是在宿主機的虛擬內存中，因此還需要將宿主機的虛擬內存映射到宿主機的物理內存中。
# 需要兩次內存映射
# 因此我們需要加快這個內存映射
# 解決方案（瞭解即可）
1. '影子頁表' 直接將虛擬機的虛擬內存映射到宿主機的物理內存。
2. 但是事實證明影子頁表性能還是不夠好，於是就出現了'intel的EPT技術！'
因此我們安裝kvm虛擬機需要打開這個按鈕，打開了這個按鈕就對kvm的cpu、內存空間進行了優化。
（2）內存尋址（大頁內存）
首先講個例子：bock塊大小問題。硬盤最小的存儲單位是扇區，最小的存取單位是block塊！block塊過大，會造成內存空間的浪費，因爲如果一個block塊存不滿，剩下的空間也就不會再用了。block塊過小，那麼查找就會很慢！
我們的kvm虛擬機在宿主機眼中就是一個進程，整個宿主機時需要一部分內存空間去運行的，大概要一兩個G左右。注意我們創建虛擬機的時候指定的--ram，那是給kvm虛擬機分配的內存，而不是運行kvm虛擬機所要的內存！內存分頁機制都知道吧，一頁大概是4kb，我們兩個G的內存空間，如果採用4kb來分頁，就類似於block塊過小的情況，造成內存尋址會很慢。
# 解決方案
大頁內存
cat /sys/kernel/mm/transparent_hugepage/enabled # 大頁內存默認開啓的
查看大頁內存的大小：cat /proc/meminfo：
（3）ksmd內存合併
ksmd會在後臺不斷的掃描內存地址，如果發現某一內存地址重複，就會釋放它！
3、IO優化
（1）virtio（瞭解）
virtio 是一種 I/O 半虛擬化解決方案，是一套通用 I/O 設備虛擬化的程序，是對半虛擬化 Hypervisor 中的一組通用 I/O 設備的抽象。提供了一套上層應用與各 Hypervisor 虛擬化設備（KVM，Xen，VMware等）之間的通信框架和編程接口，減少跨平臺所帶來的兼容性問題，大大提高驅動程序開發效率。
kvm默認就有virtio！
（2）IO調度算法（瞭解）
linux2.6的內核有四種調度算法：Noop、CFQ（默認）、As、Deadline
linux3.10的內核有三種調度算法：Noop、CFQ、Deadline（默認）
dmesg | grep -i scheduler
Noop：先來先服務，先來的先進行IO操作！一般用於SSD硬盤，因爲SSD本來就很快了，加個調度算法反而變慢了，因此直接先來先IO。
CFQ（完全公平分配算法）：在觸發IO請求的所有進程中確保磁盤IO帶寬的公平分配
Deadline （最後期限算法）：讀請求和寫請求分別根據最後期限進行排序處理，防止請求被餓死。
（3）kvm的IO寫優化
上面這個圖上層是guest客戶部分（kvm虛擬機部分），下面是宿主機部分。
kvm用戶使用應用程序，把數據先存到內存（page cache）—> 虛擬磁盤（根據虛擬磁盤鏡像自動生成的）—>虛擬磁盤的鏡像（就是我們那個qemu-img創建的raw格式那個）—>宿主機的內存—>宿主機的磁盤緩存—>宿主機的磁盤
有人可能納悶，磁盤也有緩存？
磁盤存取速度很慢，因此需要加個緩存！但是這個緩存斷電數據會丟失！因此一般採用自帶電的raid卡，它也有緩存
我們發現這樣一級級的往下寫，太慢，而且容易丟失數據，因此kvm提供了三種機制：
- writeback機制：直接寫到宿主機的內存中去
- None機制：直接寫到硬盤的cache
- writethrough機制：直接寫到硬盤中去
writeback和None機制斷電都有可能造成數據丟失，因此 writethrough機制最安全，但速度也是最慢的。kvm默認採用writethrough，具體用哪個就看你的具體生產環境了！