arm64 Raspberry Pi 400/Raspberry Pi OS/KVMで仮想化

arm64 Raspberry Pi 400/Raspberry Pi OS/KVMで仮想化

　先日、Debian bullseye/Wine 7.0でKindle本を読んでから、QEMUならと思いつつ、結果、Raspberry Pi 400/Box86/Box64/WineでWindowsアプリを起動してみました。

　QEMUといえば、数年前にシステムエミュレーション機能による仮想化ソフト・仮想マシンとして以前、Windows erからBSD* er/PC-UNIX er/Linux erになるべく、VMWare、VirtualBox、Virtual PCと共にあらゆるBSD*/PC-UNIX/Linuxディストロの試用後、それぞれ、Windows 95/98SE/Vista/7/8.1/10なども入れてみたことがあり、QEMUでMS-DOS起動とWindows 95/98SE/XPインストールもやってみたことがありました。

　Armな環境で仮想化ソフトウェアって言ってもVirtualBoxやVMwareもESXiはともかく、VMware Workstation Playerは対応してないですし、そうなるとQEMUでしょと。

　また、当初、Windowsはi386/x86_64を想定していたわけですが、Windows 11にはArm 64版もあるとか、久々にMicrosoft Insider Programにログインしてみたら確かにありました。

　ただ、Insider ProgramのArm 64用Windows 11はHyper-Vの仮想マシンVHDXのみっぽい、でも、そこは、さすがのQEMU、対応しているのでまぁいいかとダウンロード。

　というわけでarm64なRaspberry Pi 400/Raspberry Pi OS上のQEMUで仮想マシン作ってWindowsを起動してみるのも暇つぶしとしては面白いよねと思ってやってみた...。

　という話にする予定だったのですが、考えてみれば、仮想マシンづいてたあの頃は、32ビットPCしかなかったのですが、そう言えば、5年くらい前に買ったノートパソコンdynabook B45/Bは64bit CPUでIntel VT-xだかVT-dに対応してて、しばらくしてamd64なDebianをインストールしててハイパーバイザー仮想化とか言われるKVM/Kernel-based Virtual Machineが使える...。

　他方、64bitのRaspberry Pi 400や4BもラズパイのCPUはIntelでもAMDでもなく、ARMなわけでハードウェア的に仮想化支援技術があるのかは定かではないものの、Raspberry Pi OSも64bitを入れてあり、やはり、KVMも使えることが判明。

　その上、幸いにもARM CPU のQEMUによるエミュレーションの高速化によれば、ホストもゲストもARM 64のケースでもKVMによる圧倒的な高速化を体験できるとあるではないですか。

　というわけで遅まきながら、KVM/QEMUでやってみたら、Intel VTもあるamd64なDebianなら、あっさり、x86_64なWindowsのインストーラが起動したのですが、そこは、arm64/aarch64なRaspberry Pi 400でやってこそでしょ。

　と思いきや、arm64/aarch64なラズパイ上でWindows、一発でうまくいかず、かと言って情報は限られる中(ホストがarm64という点に拘らなければ、情報は多そう。)、KVM周りが難解で1日では理解が追いつかず、ゲストとしてArmなWindowsは、やむなく未完(と思ったら、x86_64はいけました。)、これも一筋縄ではいかなかったものの、ArmなDebianにしてみた話。

　KVMについて、まだ理解が足りないので概要に留めます。

• ゲストDebian arm64/aarch64編/概要
• ゲストWindows x86_64/インストール・VirtIO 概要[追加:2022/09/19]
• ゲストWindows x86_64/MSEdge仮想マシン 概要[追加:2022/09/19]
• 備考

ゲストDebian arm64/aarch64編/概要

　いろいろ参照してパッケージも、あれこれ、いろいろ入れてしまったものの、KVMがデフォルトで利用できるRaspberry Pi 400/4Bだと、実は、Raspberry Pi 4B(Ubuntu 20.04)にKVMを導入する。が、最もスマートじゃないかと。

　これでKVMで仮想マシンを管理するにあたり、CLIのvirshも、GUIのvirt-manager(仮想マシンマネージャー)、そして表舞台でも裏方でも活躍するqemu-system-aarch64も使えるので。

　bridge-utilsは、VNCやSPICEを使う(なら更にvirt-viewerもあると便利っぽい)とか、ホストとsshやscpするとかホスト含め外からアクセスするなら必要ですが、そうでなければ、なくても良さそうなくらい。

　というのもNATが使えて仮想マシン上でリポジトリからパッケージをインストールしたり、ネット閲覧とかはできるので。

　とは言え、同一ネットワーク上にいるのは、何かと便利だしということでKVMでゲストOSをブリッジ接続するの通りにしたらできました。

　ただ、時間の経過で表示や仕様も変わったのかもしれませんが、自身の場合、virt-managerの[マシンの詳細]のNIC画面の項目は[共有デバイス名を指定]ではなく[Bridge device...]でしたし、設定完了後、brctl showした結果にvnet0やvirbr0-nicなんて表示はありませんでしたけど。

　あと、virt-manager(Virtual Machine Manager/仮想マシンマネージャー)を権限を求められることなく開くため含め、グループlibvirtとlibvirt-qemuにホストのUSERを追加。

　尚、やってみるとvirshとvirt-managerで仮想マシンファイル(domain)を置いておくstorage poolがデフォルトでは異なるということなのか、そうだとしてもvirsh define /etc/libvirt/qemu/DOMAIN.xmlしてもvarsh list --allに表示されないケースがあるので注意。

　とは言え、一度、いろいろ入れたパッケージ類をpurgeしてやり直しても変わらず。

　実は、先のブリッジ接続も、これをやってないからvirsh listに反映されないのか？と思ってブリッジしてみたわけですが、変わらず、反映されません...。

　検索してもvirsh defineする、再度やるとできるみたいなできる話はあれど、それでも反映されない話については、英語圏でも日本語圏でもヒットしない...、一体どうしたら...。

　あ！あったこれだ第19章 Virtual Machine Manager を使用したゲストの管理 (virt-manager) by Red Hat。

　sudo virsh list --allしたらありました...。

　「特に指定がない限り」ってどこで指定できるの！？

　と思ったら、グループlibvirtとlibvirt-qemuにUSERを追加する前に仮想マシンを作ってしまった為、仮想マシンの所有者がrootとなりましたが、グループに追加後は、所有グループ・所有者ともにlibvirt-qemuとなりました...。

　とは言え、仮想マシンファイルの所有グループと所有者をlibvirt-qemuにしたところでUSERからは見えないので、rootとしてsudoを付けてvirshコマンドを実行することに変わりないですけどね...。

　となるとrootでの管理が正解？

　さておき、ARMなDebian(例えば、debian-11.5.0-arm64-netinst.iso)をダウンロード。

　そしてGUIなら仮想マシンマネージャ、CLIならvirt-installでKVMの仮想マシンにインストール。

　virt-installの--disk sizeの単位はGB、--memoryの単位はMB。

　arm64なRaspberry Pi 400/KVM仮想マシンにarm64 Debian bullseyeをインストール中の図。

　冒頭リンク先のarm64なRaspberry Pi 400上にbox86/box64にwineでWindowsアプリを入れた際、いろいろやってたら、デスクトップがデフォルトからちょっと崩れたLXDEになってしまい、復旧する際、変更した関係でデスクトップがCinnamonになってますが。

　デスクトップアイコンの内、7ZipとMicrosoft Paintは、Wineでインストールしたもの。

　というかCinnamonでもサクサク動くRaspberry Pi 400、感慨深い...。

　インストールが終わったら、KVM仮想マシンのDebianを起動できます(というか、インストール直後は、そのまま起動するかどうか確認があります)。

　うまくいってないと起動した時にUEFI Interactive Shell EDK Ⅱとか言うわけのわからない画面が表示されて面食らいます。

　exitしてみても、結局、ここにもどってきてしまい、堂々巡り...どうやったら、終了できるのか...。

　なにかの拍子にFD0:とかいうのも出てきてUEFI SHELLでコロン含めてタイプ＋EnterでGRUBのようにlsとかで中身も見えたりするのですが、ここから起動できるのかどうなのかもわからない...。

　終了の仕方もわからないので仕方なく、端末の[x]で端末を強制的に閉じました。

　うまくいくとGRUB画面が表示されてDebianを起動できます。

　というか、最初、CLIしか表示できませんでしたが、とりあえず、Debianログイン画面。

　仮想マシンへのログインがホスト上のターミナル(≒端末)でって、ちょっとおもしろいかもと思ってみたり、みなかったり。

　一方、GUIの仮想マシンマネージャーvirt-managerはこんな感じ。

　virt-managerで仮想マシンを作成する場合は、画面左上端の輝きを放った？モニタアイコンを、もしくは[ファイル(F)] => [新しい仮想マシン(N)]をクリックします。

　これら何れかをクリックして表示されるパネル上には、下三角に[アーキテクチャーオプション]とあり、クリックしないと表示されないわけですが、デフォルトで表示してあっても良さそうなのにという気はします。

　途中、ISOファイルを指定することもでき、その場合は、仮想マシン起動後、GRUB画面からインストールを開始、インストール済みならGRUB画面から起動します。

　任意の仮想マシンを選択して[開く]と添えられたモニタアイコンをクリックすると起動中ならその画面、停止中なら「ゲストが起動していません」と表示された後述の『QEMU/KVM 上のドメイン(仮想マシン)名』というタイトルのパネルが表示されます。

　こちらは、仮想マシンマネージャの[表示(V)] => [接続の詳細(V)]で表示されるパネル。

　これに限らず、libvirtの設定ファイルは、XML形式でXMLタブを開くと中身を閲覧でき、デフォルトでは読み取り専用ですが、[編集(E)] => [設定(P)]から[全般(G)]タブの[Enable XML editing]にチェックを入れておくと、その場で書き込み編集できるようにもできます。

　今回は1つ(1台？)しかありませんが、仮想マシンマネージャの左ペインの一覧にある仮想マシンを選択、[編集(E)] => [仮想マシンの詳細(V)]で左上端から2つめの裸電球らしきアイコンが点灯？した状態になりつつ、左右2ペインの『QEMU/KVM 上の仮想マシン(ドメイン)名』パネルが表示されます。

　ここで画面上左端のモニタアイコンをクリックするとvirt-manager初期画面の時と同様、当該仮想マシンが起動中ならその画面、停止中なら「ゲストが起動していません」と表示されます。

　話を戻すと左ペインがハードウェアの種類、右ペインが左ペインで選択したハードウェアの設定画面です。

　左ペイン下にある[ハードウェアの追加(D)]ボタンを押下すると同じく2ペインの『新しい仮想ハードウェアを追加』パネルが表示されます。

　ここで選択・設定し、[完了(F)]ボタンを押下すると当該仮想マシンに当該仮想ハードウェアが追加されます。

　CLI画面しか表示できなかったゲスト側ですが、仮想マシンマネージャの[ハードウェアの追加(D)]で今回は[VirtIO]を設定した[ビデオ]を追加したら？GUIのログイン画面が表示されるようになりました...。

　が、マウスとキーボードが効かない...。

　そこで同じように[入力]で[USBマウス]、キーボードは、[USBキーボード]か[VirtIOキーボード]を追加したところ機能するようになりました...。

　もしかすると予めvirt-install時にも設定できた、全て設定できるvirt-managerなら、virt-install時に不足があっても補完できるということなのかもしれません。

　そしてログイン...すると無事、デフォルトで上部にステータスバーのあるデスクトップMATEが表示されました。

　ホスト側(Raspberry Pi 400/Raspberry Pi OS/Cinnamon)とゲスト側(Debian/MATE)、それぞれ端末上にuname -aの結果を出力してみました。

　Raspberry Pi 400(arm64/aarch64)のデスクトップにあるBox86を介してWineで入れたMicrosoft Paintや7ZipとKVM/QEMU仮想マシンのDebianが何事もなかったかのように整然としていますが...実は、入り乱れた？複雑怪奇な？滑稽な？興味深い？並び。

　こういうことも、さらっとやってのけるRaspberry Pi 400や4Bって、やはり、すごいですよね。

　さておき、KVM、仮想マシンがSSD上にあることも影響しているにしてもVirtualBoxやVMware Workstation Playerより圧倒的に速い。

　しかもCLI(virsh)だけでも仮想マシンの起動・シャットダウンができるので手軽、そればかりでなく、virt-manager同等以上の管理・操作ができるわけですから素晴らしい。

　自身は、どちらかというと、これまでVirtualBox推しでしたが、DockerやそのベースともなっているというLXCなどコンテナはともかく、KVMがサポートされたマシンで仮想マシンを扱うならKVMが筆頭候補ですね(って使いこなすにはもっと覚えないといけませんが...)。

ゲストWindows x86_64/インストール・VirtIO 概要

　今のところ、ARM対応Windows 11の仮想マシンをqemu-system-aarch64でも、i386やx86_64のWindows 10をqemu-system-i386/x86_64でも、Windowsの旗マーク止まりだったり、ブルースクリーン止まりだったりなんですが、どうしてでしょう？と思ってたら、いけました(後述)。

　こんな感じのEFI画面で何やら見つからないらしきメッセージ出しつつ...

　Windowsロゴマークで止まったり、

　時にロゴマークの下で白いリング状のものが、くるくる回って行けるかなっ！

　と思ったら、Windowsのブルースクリーンだったり。

　あったなー、こんなの。

　おっと、QemuでDebian上に仮想Windowsを構築した手順のメモ - 7meのおかげで、いけました。

　ただ、そこはarm64上でx86_64とホストCPUまでエミュレートしているだけあって、この画面が出るまで5分ほどかかりました。

　さっきやってみたばかりのDebian amd64/KVM上にWindows 10 x86_64は、この画面の表示に限らず、インストールも、インストール後の操作性も、特に違和感もなく、そこそこ速かったので尚更。

　ホストアーキテクチャが異なるからか？でも、以前、それでもできたような？-enable kvmや-cpu hostを付けるとエラーになるんですよね。

　これが使える上で、ARM64版Windowsでないと厳しいかなということでインストールは見送りました。

　コマンドはこんな感じ。

　結果、インストールしないのであれば、まだいくつか省けそうですね。

ゲストWindows x86_64/MSEdge仮想マシン 概要

　仮想マシン Microsoft Edge Developerで任意にHyper-V用のMSEdge on Win10(x64) Stable 1809をダウンロード。

これを

qemu-img convert -O qcow2 MSEdge\ -\ Win10.vhdx msedge_win10_x86_64.qcow2

のようにしてできたmsedge_win10_x86_64.qcow2を仮想マシンマネージャで仮想マシンを作成、アーキテクチャーを[aarch64]、[既存のディスクイメージをインポート(E)]してCPU 3/RAM 2560MBで実行してみたところ、少なくとも8分以上経ったところで落ちました。

　その際、ホストのConkyの表示上もデスクトップ上には仮想マシンマネージャ以外、何も起動していない状態、かつ、ホストのConkyによれば、最初の旗のロゴのところで4GBあるRAM消費率が、98%あたりになっていて、しまいにはConky表示やらマウスすら動かなくなった、その時点でqemu-system-x86のRAM使用率が76.05%でした。

　ディスクがSATAでVirtIOじゃないからかなとVirtIOディスクを追加、SATAディスクを削除して実行してみましたが、5分ほど経過した時点でブラックスクリーンになったところで、そのまま落ちたようでフリーズ。

　一方、msedge_win10_x86_64.qcow2をscpし、ノートPC(x86_64)/Debian bullseye amd64で試してみたところ、ログイン後の操作性は、少しもっさり感はあるものの、そこそこ違和感なく実用的に起動できました(ちなみにCPUx2/RAM2048MBでvirt-manager以外デスクトップにない状態でホスト上のConkyでのRAM消費率は84%)。

　ラズパイでも先のディスクとネットにVirtIOを使用してインストールしたWindows x86_64では、5分ほどかかってインストーラまでですが、起動はできた、CPUの負荷はそれほどでもないことなどからするとaarch64でx86_64をエミュレートする分、微妙に仮想マシン用のRAMが不足したのかもしれず、Raspberry Pi 4B RAM8GBならいけたのかもしれません。

　何れにせよ、arm64なラズパイ400でCPUをエミュレートし、かつ、Windowsというのは厳しそうですね(Windows 8.1以前はいけるかも？)。

備考

　当初、リポジトリからインストールしたqemu-system-*が、whichしてもなぜか、出てこず、よって実行もできず...となり、git clone https://gitlab.com/qemu-project/qemu.gitしてmakeまでで~/や./で使っていたのですが、いろいろやっている内に、そんな必要もなく、正常にqemu-system-*コマンドを使えるようになりました...。

　ノートPCのamd64なDebianでは、そんなことなかったのに、一体なんだったんでしょう...。

　あ、DebianやRaspberry Pi OSでは？qemu-system-aarch64は、qemu-system-armに、qemu-system-i386やqemu-system-x86_64は、qemu-system-x86に統合されているようです。

　qemu-system-aarch64、またqemu-system-i386やqemu-system-x86_64を指定した場合、実際にインストールされるのは、qemu-system-armやqemu-system-x86である一方、コマンドとしては、qemu-system-arm、また、qemu-system-x86_64はあるものの、qemu-system-x86はなく、それをしたいならqemu-system-i386を使うということのようです。

　というわけで当初、Windowsをゲストにしようとした際にqemu-system-x86を実行しようとしてバイナリがないと思った可能性大...。

　それにしてもKVM、arm64同士で-enable kvmやVirtIOを使う、設定をチューニングするにしても、この速さでWindowsが起動するなら、Wineの出番は尚更減るかも。

関連リンク