幹壞事是進步最大的原動力
用了幾個月才發現沒聲音，花了點時間找方法測試才解決。
一般人用預設值應該是沒問題，不過我的環境比較特別，剛好不是預設值，我的 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 上開發了，現在這樣好多了...
Hacker News Daily 上看到的工具：「Quickly create and run optimised Windows, macOS and Linux desktop virtual machines.」，對應的討論在「Quickemu: Quickly create and run optimised Win-10,11/macOS/Linux on Linux (github.com/wimpysworld)」這邊可以看到，可以減少自己要設定一堆 QEMU 參數。
雖然專案是支援多系統，但其實 Microsoft Windows 與 Linux 的部份在其他虛擬軟體都很簡單 (像是用 VirtaulBox)，大家馬上會注意到的重點還是 macOS 的部份，如果有自己弄過就會知道這東西有夠難裝的，而且跨版本有不同的安裝方式...
目前 Quickemu 支援四個版本：
Supported macOS releases:
- High Sierra
- Mojave
- Catalina (Recommended)
- Big Sur
然後可以看到幾乎所有目前能支援的功能都有設定上去了，包括 VirtIO 與 USB 的部份。
然後一些經典的問題，像是 Big Sur 的音源問題還是沒解：
Full Duplex audio works on macOS High Sierra, Mojave and Catalina.
- macOS Big Sur has no audio at all.
在 Hacker News 的討論串裡面有提到有很多地方沒有檢查，這會是風險：
While I appreciate the effort, and the code is very readable. I just want to give a friendly warning that these shell scripts just download random stuff from the internet and run this random stuff without checking any integrity/signature.
下面的討論另外看到個冷知識，關於蘋果故意走 HTTP 下載 recovery image 是因為 HTTPS 太複雜，在 UEFI firmware 裡面實做容易產生被攻擊的點，所以決定自己透過其他機制確認正確性：
Apple Internet recoveryOS images are served over plain http, on purpose. The macrecovery.py script used by Quickemu uses http¹, though the server supports https.
https://support.apple.com/guide/security/recoveryos-and-diagnostics-environments-sec2512a0c09/web
> When the internet recovery and diagnostic modes were added to Mac computers in 2011, it was decided that it would be better to use the simpler HTTP transport, and handle content authentication using the chunklist mechanism, rather than implement the more complicated HTTPS functionality in the UEFI firmware, and thus increase the firmwareʼs attack surface.
[edit] Added macrecovery.py info
另外為了避免直接在 shell script 裡面出現「神秘字串」，可以看到特別的寫法 XDDD
Took a little while to find the magic words in there: https://github.com/wimpysworld/quickemu/blob/af26f41440d63a069045660fad860c797011310a/quickemu#L351
可以想到一些用途，像是在機房裡面跑 CI 的 worker，但要注意這個搞法不符合蘋果的 EULA，現在不抓不代表以後也不會有事，請自己謹慎評估...
然後往 ARM-based 架構後應該門檻就更高了，現在還有 Intel-based 的環境可以用加減用...
也是因為最近 Docker Desktop 改變授權的關係 (參考先前寫的「Docker Desktop 要開始對商用收費了，以及 Open Source 版本的設法」這篇)，有不少人在講怎麼用 Podman 替代 Docker，不過要注意這邊的替代不是 drop-in replacement，而是功能上的替代。轉移的過程還是得花一些時間處理...
在 Mac 上面的範例大多都是用 Homebrew，我在 MacPorts 上也有看到套件：「podman」，看起來好像得多裝 qemu，但即使把 qemu 裝起來，也還是不會動... 後續因為沒有需求，加上先前已經把 Docker CLI 的版本弄好了，暫時就沒再多研究要怎麼跑起來。
另外有人寫了「Migrating from Docker to Podman」這篇，在「GUI Replacement」的部份還介紹了對應的 GUI 方案，也可以參考看看。
跟以前的養套殺類似，都會推動一些 open source 替代方案的成熟度，以這次的情況看起來這些能量有很大一部份都會進到 Podman 裡面，對於個人用戶也可以再放幾個月看看是不是要跳槽過去。
在「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.
主要還是有趣吧...
看到「dockerpi」這個專案，讓你可以在 x86-64 上模擬 Raspberry Pi 環境跑 Raspbian。
然後整包是先透過 Docker 產出一個獨立環境，然後裡面跑 QEMU 模擬 ARM 的環境，接下來再跑 Raspbian：
A full ARM environment is created by using Docker to bootstrap a QEMU virtual machine. The Docker QEMU process virtualises a machine with a single core ARM11 CPU and 256MB RAM, just like the Raspberry Pi. The official Raspbian image is mounted and booted along with a modified QEMU compatible kernel.
這馬上讓人想到 Inception 啊 XDDD
Anyway，這個方法對於想玩玩的人可以省不少功夫，是個有趣的專案就是了...
在 OSNews 上看到「Announcing Ubuntu Core, with snappy transactional updates」，原文出自 Ubuntu 老大 Mark Shuttleworth 的文章「Announcing Ubuntu Core, with snappy transactional updates!」。
依照官方說明：
Ubuntu Core is a minimal server image with the same libraries as today’s Ubuntu, but applications are provided through a simpler mechanism.
希望提供比較穩定的套件環境，並且讓 app 之間不受干擾執行。系統裡分成 release、framework、app 三種角色，release 就是 Ubuntu Core，而 framework 可以是 Docker，最後的 app 就是自己的應用程式，而 snappy 就是管理這三個的軟體。
Snappy Ubuntu Core 是個 readonly image (裡面大多數的地方都不能寫，只有部份目錄以及用 tmpfs 掛起來的部份可以寫入)。
除了可以在雲端平台上面測試外，還可以用 QEMU 掛起來跑，不過實際測試的時候發現 precise (12.04) 的 QEMU 因為是 1.0 版所以不能跑，要 trusty (14.04) 附的版本才夠新 (2.0 版，需要 1.1+)。
找到 trusty 的機器跑的時候因為是遠端的機器，要多加上 -nographic -curses 的參數：
sudo kvm -m 512 -nographic -curses -redir :8090::80 -redir :8022::22 ubuntu-core-alpha-01.img
然後就可以依照官方文件裡提到的方法連進去了：
ssh -p 8022 ubuntu@localhost
然後就可以照著官方的文件操作一次，我自己沒遇到什麼問題。
看起來是 Ubuntu 自己在推動的一套標準，不知道市場接受度如何 :p
