KVM - 虛機內核配置

時間：2023-06-26 02:18:02 | 來源：網(wǎng)站運營

時間：2023-06-26 02:18:02 來源：網(wǎng)站運營

KVM - 虛機內核配置：

緣起

筆者最近分別購買了一臺騰訊云和百度云的機器，都是一年期的，配置和價格分別如下：

	騰訊云	百度云
配置	2 核，2G 內存，40G 硬盤	2 核，4G 內存，80G 硬盤
價格	50 元	78 元

似乎性價比都差不多，但是，用 "lscpu" 命令一看就會發(fā)現(xiàn)，騰訊云機器的 "Thread(s) per core" 這一項為 1，而百度云為 2，這意味著后者是開啟了 hyper-threading 的，性能一般只相當于 1.1-1.2 個 CPU（大家注意以后避免踩坑），而騰訊的是真兩核（要不然怎么叫良心云呢）。

另外從控制臺上，雖然是輕量應用版本，但是騰訊云也支持 snapshot 功能，而百度云好像沒有。不能打快照的話，都不敢在上面做過多的試驗性操作。

有時想想，這么低的價格，怕是連電費都不夠，還別說為了保持產(chǎn)品的競爭力，隔幾年就需要對昂貴的 CPU 進行升級換代，這可是一筆不小的開銷。

云服務器普遍存在“超賣”的情況，畢竟不可能售出的所有虛機都同時使用（銀行也是無法同時滿足每一個儲戶的取現(xiàn)需求）。會不會是像航空公司一樣，多賣出去的一個座位，只是幾十元的「邊際成本」（比如這兩年的“隨心飛”產(chǎn)品）。當使用一年之后，由于數(shù)據(jù)遷移的不便，加上習慣和黏性，賭你還會接著續(xù)費使用？

采用虛擬機模式構建的云服務，算是一種共享經(jīng)濟了，但根據(jù)目前了解到的一些信息，在公司級項目的層面，由于各種各樣的原因，目前購買云主機的成本并不見得比自建機房低。

不過“云”還有一個好處，就是隨時隨地的訪問，周末寫文章常常需要一個 Linux 的訪問環(huán)境，買臺云服務器的話，可以省去背電腦回家的麻煩。

在到手的這 2 臺機器上，筆者都基于 5.17.0 內核，使用 menuconfig 默認配置進行了編譯，結果生成的鏡像占用空間較多。由于磁盤空間受限，筆者就想著能不能精簡下配置，把不必要的模塊都去掉。前提一是能在采用 KVM 的虛機上運行，二是虛機里能跑 docker。

動手

筆者最開始使用的是 defconfig，為了加快后續(xù)編譯，make 時加上了 ccache（參考這篇文章）。替換內核是高危操作，所以保險的做法是在 make install 之前打個快照，并且用 "grubby --set-default" 將老內核作為默認啟動項（因為啟動失敗后，網(wǎng)頁版的 VNC 界面很可能無法切換內核）。

支持 KVM

之后，切到新內核的啟動卡在了 "System hang after output: Reached target Basic System"，這可能是 initramfs 里的磁盤驅動缺失導致。

因為目前 KVM 普遍采用 VIRTIO 作為虛機的驅動，所以得在配置里包含相關部分，主要是 BLK, SCSI, PCI 和 NET，以 block 為例，配置路徑如下：

Device Drivers ---> Block devices --> Virtio block driver

此外，作為 guest 虛機，還需加上 "KVM_GUEST" 的配置：

Processor type and features ---> Linux guest support

注意，"Virtualization --> Kernel-based Virtual Machine (KVM) support" 這個并不需要，因為它是用來支持虛機運行的，是給宿主機內核用的。

煞費周章后，新內核終于可以正常啟動了。其實后來才知道，Linux 針對 KVM 虛機提供了一個現(xiàn)成的配置，在擁有一個基礎的 ".config" 文件后，直接 "make kvm_guest.config" 即可（"kvm_guest" 這個 config 文件并不是內核編譯所需的完整配置文件，它只有幾十行，所以中間其實自動進行了一個和基礎配置文件 merge 的過程）。

支持 docker

啟動后試著輸入 "docker ps" 命令，dockerd 守護進程都沒起來：

Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?那為啥沒 run 呢，是沒有設置開機自啟么？用 "systemctl is-enabled docker"，結果顯示為 "enabled"，再用 "systemctl status docker"：

只有最后一部分日志，看不出來具體原因，完整的還得用 "journalctl -u docker"，然后從里面找到端倪：

msg="failed to mount overlay: no such device" storage-driver=overlay"lsmod |grep overlay" 的輸出為空，說明確實沒有這個驅動，得增加 CONFIG_OVERLAY_FS。但重新編譯后，docker 還是沒能起來：

再把 cgroup 里面缺失的 controller 都補上，比如 CONFIG_CGROUP_DEVICE。現(xiàn)在有經(jīng)驗了，docker 的三要素嘛，還差一個 namespace，也一起給補了：

嗯，dockerd 總算是可以運行了，但是容器的網(wǎng)絡不通，還是沒法正常使用：

docker 網(wǎng)絡這塊的關系頗為復雜，傳統(tǒng)上是 iptables，由于兩臺機器都采用和 RHEL-8 兼容的用戶態(tài)，所以還涉及 nftables：

折騰一番后，所幸找到了一個查找容器運行依賴項的工具（具體用法見這篇文章）。對著檢查出的結果， 補齊 "Generally Necessary" 里面 "missing" 的部分（比如 CONFIG_VETH），最后總算勉強跑起來了。

小結

由于在此期間需要多次重編內核，ccache 的加速作用功不可沒。在配置差異的比較中，源碼 "scripts" 目錄下的 diffconfig 工具也是必不可少。整個探（折）索（騰）的過程，除了工具的使用，對 KVM 和 docker 底層依托的組件，也有了更深的印象。

除了騰出有限的存儲空間，更少的配置也意味著更短的編譯時間（咱這只有 1 到 2 個 CPU 的小驢，編譯內核可是非常耗時的），以及更快速的啟動（可以用 "systemd-analyze" 來分析啟動時間的構成）。




參考：

iptables: The two variants and their relationship with nftables | Red Hat Developer




原創(chuàng)文章，轉載請注明出處。