Ubuntu ARM64のVM動く

もう,「だったらなんだよ」って聞こえてきそうですが,Raspberry Pi 5 Model B (RPi5)のKVM/QEMU環境で,Ubuntu ARM64の仮想マシンがめでたく動きました.

CPUは3個割り当てました.UbuntuのサイトにはARM64のDesktop版のインストールイメージが見つからないので,とりあえずServer用イメージから余計なデーモンを追加しないでインストールを行いCUI環境で立ち上がるようにして,

apt install ubuntu-desktop

をして再起動したらGUI環境になりました.最初のうちは起動のたびになんかがクラッシュしたとダイアログが出ましたが,全部Noで答えて使っているうちに,クラッシュの報告もなくなり,安定してきたようです.なぜだか分かりませんが😥

“Settings” 内の “About Ubuntu” は次のように表示されます.

Processorが空欄です😥 問題なく動くので問題ないです.

このあとfcitx5-mozcをインストールして日本語入力もできるようになりました.

ちなみに,stress -c 3 で割り当てたCPU3個に負荷をかけたとき,ホストのCPUは3個がフルになって稼働しています.

左が仮想マシンのgkrellmで表示したCPUの稼働率で,上から3つ目の枠までがフルになっています.右のホストのgkrellmでは切り替わりながら4つのCPUのうち3個がフルになっている様子がわかります.

x86_64のエミュレーションでもこうなってくれればDebian x86_64(AMD64)が4倍速くなるはずです.

さて,Ubuntuの仮想マシンが使い物になるかどうかっていう総合評価ですが,Raspberry Pi 4 Model B (RPi4)やRPi5でホストOSとしてUbuntuを動かしたことがないので正確には言えませんが,今回インストールしたUbuntu ARM64の仮想マシンの体感速度と以前から試しているDebian ARM64の仮想マシンと実機の比較からして,Ubuntu ARM64もRPi4のホストOSとして動かすよりRPi5の仮想マシンのほうが速いのではないかと推定されます.安定性はまだ分かりませんが,スピード的には「使えなくない」レベルと思います.

よほどUbuntuが好きな人には,ネット情報を探してUbuntuをRPi4/5のホストOSとしてインストールするのがベターと思います.

まあ仮想マシン遊び(箱庭)が好きな人の作ってはいずれ消す箱庭の一つとするには良い景色と思います.

3個ではたしてsymmetricといえるのだろうか😥

RPi5でVM遊び (2) qemu-system-x86がマルチにならない

忍耐の限界を超える,と言いながら,その後も時々怖いもの見たさでDebian x86_64の仮想マシンをRaspberry Pi 5 Model B (RPi5)で動かしています.

先程気がついたのですが,仮想マシン側でCPUを上限の4個に設定し,実際仮想マシンでは4つのthreadをフルに使っていますが,ホストマシンではqemu-system-x86のCPU占有率は100%前後で,1つのコアしか使っていないようです.

このスクリーンショットは,仮想マシンのデスクトップの右端とその下のホストのデスクトップのデスクトップの右端で,どちらのデスクトップにもgkrellmがありCPUの動作状況などを表示しています.

左側の仮想マシンではたしかに割り与えられたCPU4個をほとんどフルに使用していますが(上4つのグラフ),ホスト側では1個のCPUがフルに使われているだけの状況(同じく上4つのグラフがCPU1〜4ですが,このスクリーンショットでは上から2番めだけがフルに稼働しています.使用されるCPUは時々で変わります)です

もちろんネイティブのARM64の仮想マシンの場合は,仮想マシン側のCPU稼働率がそのままホスト側に反映します.

x86のエミュレーションでもホストの4個のCPUが使われれば,今のおそすぎる状況から4倍速くなることが期待できます.

しかし,ざっとネット検索したところでは解決策どころか,この状況を問題と取り上げている記事も見つかりません.

topで見ても同じです.

zram (5) resumeの問題

zramの設定について,自己完結のために記事を書きましたが,自己完結していないので補記です.

Debianのクリーンインストールをデフォルトで行うと,ルートパーティションの後ろにswapパーティションが作られてしまいます.

/etc/fstabからswapの行を削除しても次に起動するとswapパーティションが使われています.fdiskでswapパーティションを削除するという強硬策に出ると,さすがにディスクのパーティションを使用したswapはしませんが,起動がやたら遅くなります.

これは随分前から何度も経験している “RESUME” の問題です.initramsfs内の起動設定でRESUME用にswapパーティションを必要とするため,マウントしたいけどできずタイムアウトまで無駄に時間を浪費する,ということです.

仮想マシンに独自にRESUME機能をもたせても意味がありませんから(仮想マシンとしてresumeできる),ここを無効にするのですが,distroにより流儀が違うようです.

Manjaroに関しては,当blog内に記事がありました

Debianに関しては,/etc/initramsfs-tools/conf.d/resumeの一行だけあるRESUMEの行をコメントアウトすればよいです

3年前の記事です.何年か周期で同じことを繰り返しています😥
当然/etc/initramsfs-tools/conf.d/resumeを削除しても良いですが,残しておけば後で何かの手がかりになるかもしれません.

RPi5でVM遊び

Raspberry Pi 5 Model B (RPi5)は速いです.そうだこれだけ速いならVM遊びをしよう,ということで最初は無謀にもx86_64の仮想マシンを動かしてみることにしました.

別のx86_64マシンで動いているDebian x86_64 (AMD64)の仮想ディスクイメージをコピーしてきてチョチョイのちょいとおまじないをしたら動きました.

Raspberry Pi 5 Model B上で動くx86_64 Debian (QEMU-KVM使用)

しかし,遅い.遅いにもほどがあるというほど遅く,何かちょっと設定するだけでも忍耐の限界を超えるので人間の方にまだダメージが少ないうちにやめときました.

AppleのM1のMacではx86のソフトがx86の実機より速く動くという話を覚えていたので,少し期待しましたが,無理な話でした.

まだマシだろうということで,ARM64のソフトを動かしてみることにしました.最近いじりなれていて楽なのでDebianにしました.ほとんどDebianと同じであるRaspberry Pi OSをホストとして動くDebian ARM64です.net-instのcdromイメージを使って更からインストールです

スピード的には十分使える速度で,たぶんRaspberry Pi 4 Model B (RPi4)の実機より速いと思います.しかし,そのままほっといて食事から戻ってみると,死んでいたようなことが何度かあり,安定性には難があるようです.

Raspberry Pi 5 Model BのRaspberry Pi OSのもとで動くDebian ARM64.どちらもデスクトップはKDE Plasma Desktop.
作っては消す箱庭遊び.
一回失敗して,もう一回更に戻してインストールし直しました.まさに箱庭遊びです.

RTSPの視聴が不調 (2) マクドもffplay

関東ではマックといいますが,フランスではマクドというらしいです.

VLC macOS版の3.0.20 (Intel 64bit版)も,うちのカメラのRTSPを表示してくれなくなりました.ずっとこのバージョンのままのような気もするので,カメラ側の仕様が変更になってコンパチビリティーが失われたのかもしれません(少し前にカメラのfirmwareのupdateがありました).

Raspberry Pi OS版のVLCも含めて症状は同じで,カメラに接続したその時の画像が静止したままです.システムもVLCも生きていて,

killall vlc

で止められます.

それでマクドミニの方でもffplayを試してみようかと思ったら,当然ですがX用しかなく,まずXQuartzをupdateしてからMacPortsでFFMPEGをインストールしました.

その結果大きな問題なく動きました.

正常に動いた場合のVLCと比較して,Raspberry Pi OS版と同様に小さいブロックノイズが時々出ます.また時間遅れがかなりあります

VLCでは出ません.
遅れが蓄積していくかは検証してません.