幹壞事是進步最大的原動力
用了幾個月才發現沒聲音，花了點時間找方法測試才解決。
一般人用預設值應該是沒問題，不過我的環境比較特別，剛好不是預設值，我的 PulseAudio 輸出到 DA&T C-13 時是設定成 96kHz/24bit，而一般 Windows 預設輸出時是 44.1kHz/16bit，兩邊對不起來就沒聲音了。
找了一些文章，後來是在「Virtual machine audio setup – or how to get pulse audio working」這篇裡面講到用 virsh 直接改 XML 設定檔的方式讓 qemu 輸出到 PulseAudio 裡面轉，也就是文章裡面 Option 2 的部分。
這樣 guest OS 裡面還是跑 44.1/16，但外面輸出的時候就固定是 96/24 了。
比較奇怪的是如果 guest 裡面跑 96/16 的話聲音會破破的，不過我只是要有聲音 (不然也不會用了好幾個月才發現)，品質的問題倒是還好...
為了可以使用 KVM，把桌機 Ubuntu (Xubuntu) 上的 VM 都從 VirtualBox 換到 virt-manager 了...
不得不說 VirtualBox 包的很好，很多事情就不用自己繞半天... 在 virt-manager 上面有蠻多東西得自己設定繞開，把 2024 年會遇到的問題整理下來。
首先是權限的部分，裝完 virt-manager 後馬上打開會遇到 virt-manager 說連不到 libvirtd 的問題：「virt-manager can't connect to libvirt」，而最簡單的解法就是重開機，原因是安裝過程中在 /etc/group 增加了 libvirt 的權限，現有的 session 因為權限不夠無法連上 libvirtd。
接下來就是操作介面上的順暢度問題了，預設「Automatically detect from the installation media / source」是勾起來的，但你丟 Windows 的 ISO 進去不一定會偵測到是 Windows 的 ISO，需要把勾勾拿掉，然後自己輸入 win 後才會出現可以選的選項，而不是直接選單選擇... 這邊的 UX 在第一次用的時候還蠻卡的。
另外裡面設定也是有問題的，選擇 Windows XP 會發現網路的設定居然還是用 e1000，導致 Windows XP 抓不到網路卡，需要另外再改成 rtl8139 (不過速度只有 100Mbps)。
最後在 Network selection 的部分，NAT 算是最常用的，不過如果要自己架設 lab 的話 (像是我弄了三台 Ubuntu VM 測各種服務)，直覺會設定成 Bridge device，但這邊的 Bridge device 是需要先自己設定好 bridge interface 後再讓 virt-manager 設定掛進去。
所以比較「簡單」的方式 (當時以為比較簡單) 是選擇 Macvtap，然後選擇要用的介面，這樣設定後主機的確可以透過指定的介面連到 Internet 上，但就像設定 Macvtap 時出現的警告，guest 與 host 本機之間是無法溝通的：「In most configuration, macvtap does not work for host to guest network communication.」。
解決的方法還是自己搞 bridge interface，這邊由於 Ubuntu 現在網路都是透過 Netplan 在管理，我是透過「[Wishlist] Support macvlan/macvtap interfaces」這邊提供的 workaround 來解決。
以前是直接在 enps0f0 上面設定 IP address，現在是在 networkd 跑起來就先建立 macvlan0，然後在上面設定 IP address。然後 virt-manager 就可以用 macvtap 到 macvlan0 了，實際測試 guest 與 host 之間也通了...
折騰了一會算是搬過來了，這樣總算是可以在桌機上面跑 android emulator 了，先前硬關掉 KVM 跑了兩次，速度實在是受不了，就跑去 Mac 上開發了，現在這樣好多了...
因為我電腦有兩張網卡，兩條線分別接到自己拉的 HiNet 以及社區網路 (不過出去也是 HiNet，這是另外一回事了)。
我桌機的預設 routing 是走自己拉的 HiNet，但我希望 VM 是走社區網路，所以用 bridge mode 設定到網卡上，用 DHCP 取得分享器給的 private IP。
之前一直都沒注意到，前幾天用 Line 傳照片的時候很慢 (之前就有發生了，一直忘記去追問題)，花了點時間追問題的時候發現是 VM 裡面的 Windows 10 上傳很慢，這點可以從 Speedtest 的測試結果看到：
先講最後的結論，在交叉測了很多組合後，我發現遇到的問題是把網卡裡的 Large Send Offload (IPv4) (也就是 LSO) 從 Enabled 改成 Disabled：
回到當時抓問題的情況，當時先用筆電與 host 測試都沒看到問題，所以看起來應該是 VM 裡面的狀況，但不確定是什麼情況，畢竟不是斷掉...
由於下載速度正常，只有上傳速度卡住，一開始想到的是跟 MTU 相關的問題，所以找了指令降到 1400 後測試，還是一樣...
後來先把 VM 的網路改成 NAT，再測試上傳速度就正常了...
接著想要換個網路卡類型看看，結果卡在找不到 driver。
本來已經想拿 tcpdump 出來追了，但想說先去看看 Windows 10 網卡設定裡面的設定，結果看到 LSO... 就先關看看 (算是以前在 FreeBSD 以及 Linux 下的經驗？)。
然後一關就正常了，交叉再開關兩次確認這個參數有影響，就肯定這個 workaround 應該是有效了...
另外在自己找完問題後，在「Virtualbox 7.0.12 slow upload speed in any Guest OS」這邊看到了類似的問題以及同樣的 workaround。
LSO 過了十幾年還是...
Archive Team 是一個致力於保存數位資料的組織，而 ArchiveTeam Warrior 則是他們提供的軟體，可以讓你很方便直接跑 worker 加入他們的 cluster，幫忙抓資料並且保存到 Internet Archive 上。
他們提供三種方法跑 ArchiveTeam Warrior，第一種是 VM 的方式，文件裡面有介紹怎麼用 VirtualBox 或是 VMware Player 跑起來。
第二種與第三種都是 container 類的方式，Docker 與 Podman 都能跑起來。
跑起來後可以連進 http://127.0.0.1:8001/，然後選擇想要加入的項目，或是接受指令選擇目前團隊主打的項目。
在「Projects」這頁可以看到目前主力是備份 Enjin 上的資料。
丟了兩台 VPS 的機器上去用 Docker 跑，CPU 使用率看起來很低，但網路流量看起來會因為所在的地點而差蠻多的，一台大約是 300KB/sec 到 400KB/sec，換算後大約是 1TB/mo，另外一台則只有 1/10 的量。
在 Hacker News 上看到 Netflix 的人丟出來的投影片，試著了解 Netflix 的 Open Connect Appliances 裡與 FreeBSD 相關的最佳化技巧對於效能的影響：「The “other” FreeBSD optimizations used by Netflix to serve video at 800Gb/s from a single server」。
看起來這邊的分析是先基於 400Gbps 的版本，可以跑到 375Gbps (53% CPU)，接著在上面拔掉各種最佳化的設定，看看會掉多少流量。這邊可以參考先前在「Netflix 在單機服務 400Gbps 的影音流量」提到的資料。
投影片上的第一章是 sendfile 與 kTLS 相關的最佳化，這邊可以看出來都是重要的項目，隨便關掉一個就會掉很多 capacity：
第二章是 virtual memory，UMA VM Page Cache 這邊看起來最明顯，SF_NOCACHE 也是個重要的項目：
另外第二章特別提到了一個之前沒有用到的 optimization，是把 arm64 上面的 4KB Pages 變成 16KB Pages，這帶動了些許的效能提昇，並且降低了 CPU 使用率：
345Gb/s @ 80% CPU -> 368Gb/s @ 66% CPU
第三章是 network stack，看起來 TSO 帶來的效益也是很高：
最後面則是有提到從 400Gbps 到 800Gbps 還多做了那些事情，最後是達到 731Gbps。
用的機器是 Dell PowerEdge R7525，這是一台 2U 的機器啊...
在 LWN 看到 VirtualBox 7.0.0 出了：「VirtualBox 7.0.0 released」，其中 Changelog 可以在「Changelog-7.0」這邊翻到。
Ubuntu 下的更新還算方便，先把 VM 都關掉，移除 virtualbox-6.1 後再裝 virtualbox-7.0，然後把 VM 開起來看看有沒有什麼問題。
在 Changelog 裡面看到這個，這些 3D support 不知道有支援到什麼程度：
Devices: Implemented new 3D support based on DirectX 11 (and DXVK on non Windows hosts)
我把 Enable 3D Acceleration 的選項打開後變成只能跑 1600x1200，本來 1920x1200 不能跑，所以只好又關掉...
另外是支援了 virtual TPM 可以掛進去：
Devices: Added virtual TPM 1.2 and 2.0 devices
然後以前 USB 裝置的支援是 proprietary software，現在放到 open source 版本裡面了：
Devices: The EHCI and XHCI USB controller devices are now part of the open source base package
目前用起來沒什麼大問題，繼續觀察看看。
查了一下現在的 vm.swappiness，發現跟以前又有一些差異。在「Documentation for /proc/sys/vm/」這邊可以看到說明。
很久以前應該是 0 到 100，現在變成 0 到 200 了，其中設定成 100 會在比重公式裡讓 memory 與 swap 的計算上有相同的比重：
This control is used to define the rough relative IO cost of swapping and filesystem paging, as a value between 0 and 200. At 100, the VM assumes equal IO cost and will thus apply memory pressure to the page cache and swap-backed pages equally; lower values signify more expensive swap IO, higher values indicates cheaper.
另外是設定 0 時的方式，在不夠用的時候還是會去用：
At 0, the kernel will not initiate swap until the amount of free and file-backed pages is less than the high watermark in a zone.
目前看起來之前建議設成 1 的方式應該是還 OK...
剛剛看到 Travis CI 宣佈支援 Arm64 的編譯與測試環境了：「Announcing General Availability of Graviton2 CPU Support!」。
架構上是利用 AWS 推出的機器來做，其中支援的 OS image 目前看起來是以 Ubuntu 為主，其中 16.04 (xenial) 與 18.04 (bionic) 只有 LXD container 的環境，而 20.04 (focal) 則除了 LXD container 環境外，也有完整的 VM 環境可以跑：
Following Arm64 distributions of Ubuntu are available for you as LXD containers:
Xenial (16.04)
Bionic (18.04)
Focal (20.04)Following Arm64 distribution of Ubuntu is available for you as a full VM option:
Focal (20.04)
看起來底層是用 Ubuntu 20.04 為主力，然後提供 container 跑其他版本。
在「OS/2 on Virtualbox guide」這邊看到在 VirtualBox 上裝 OS/2 的指引，引用的文章在「OS/2 on Virtualbox Guide」這邊。
讓人懷古的東西...
另外文章的作者有提到，有試著在實體機器與其他的 VM 環境裝 (這邊提到了 QEMU)，不過結果不太行：
Note: On real hardware, or on other VM platforms, I have found OS/2 to be extremely fragile. When I installed it on my real P1 and P3 Dell machines, I had to reboot multiple times during the setup and driver install processes due to hangs, and I had a ton of issues with random errors on boot.
I also tried all this on QEMU 4.2.0 and had very similar problems, and I had developed some very negative opinions about OS/2's reliability before I switched to Virtualbox and found that it was actually quite solid and the installs went very smoothly.
主要還是有趣吧...
前幾天在公司弄 GitLab 與 GitLab CI，前者光跑起來都還沒動他就先吃 1.5GB 左右的記憶體，動兩下就 2.5GB 了。後者的 CI 隨著使用的情況而改變，不過最少丟個 1GB 差不多...
公司用的機器當然是還好，先簡單弄一台 t3a.medium (4GB) 跑 GitLab 主體，然後另外一台 t3a.small (2GB) 跑 CI 的 Runner，真的有需要的時候可以再往上拉...
不過自己也要弄的時候就會考慮到成本問題，畢竟也只有自己一個人用，如果在 Vultr 上面租類似的機器就要 USD$30/month，其他的 KVM VPS 也都差不多價錢。
而 OpenVZ 的 VPS 主機一向都比 KVM 的 VPS 便宜不少，但有不少限制。其中一個限制就是沒辦法跑 Docker，這樣就沒辦法把 GitLab CI 的 Runner 跑上去了 (有其他模式可以跑，但我這邊偏好用 Docker)。
查了一下資料 (因為記得 OpenVZ 有計畫要支援 Docker)，發現 OpenVZ 7 已經支援 Docker 了，而且在官方文件上面也都已經有說明了：「10.3. Setting Up Docker in Virtuozzo Containers」、「Docker inside CT vz7」。
然後順著找一下，發現市場上也已經有 OpenVZ 7 的 VPS，而且會宣傳支援 Docker，試著租一個月也確認可以跑，這樣代表之後又有更多選項啦...