QEMU/KVM 作業メモ1

SlackwareでQEMU/KVMを更新することにした.基本的には,slackbuils.orgにあるものはそのまま利用することにする.

Mesa 12

QEMU本体buildの準備だが,virglrendererを使用するには,Mesa 12が必要とある.Slackware64 14.2ではMesaは11なので,Slackware64-currentからソースを持ってきてbuildしようとしたが,含まれているソースはMesa 20で,あまりにも新しすぎてbuild不能.

そこで,Slackware64 14.2のSlackbuildスクリプトに,ソースだけmasa-11.2.2からmesa-12.0.6に差し替えてbuildを試みたら成功した

SDL2

Slackware64 14.2に標準でついてくるSDL 1.2はdeplicatedなので,SDL2をインストールせよということだが,幸いSlackbuilds.orgにあるので,

sbopkg -i SDL2
sbopkg -i SDL2_gfx
sbopkg -i SDL2_image
sbopkg -i SDL2_mixer
sbopkg -i SDL2_net
sbopkg -i SDL2_ttf

で特に問題なく完了.

その他

Optionalと書かれているパッケージをsbopkgでインストール,もしくはbuildしてからupgradepkgする.

  • sphinx
  • libiscsi
  • libcacard
  • spice (upgrade. 先にspice-protocolをupgradeする)
  • usbredir (upgrade)
  • virglrenderer
  • device-tree-compiler (install済み)
  • libnfs
  • snappy
  • glusterfs
  • vde2

glusterfsのみファイルのfetchに失敗してbuildできない(2020/12/07現在).その他はsbopkg -bでbuildできる.

Optionalということなので,glusterfsは放置して先に進む.

Follow-up

そんなに難しくないだろうということで,glusterfsのbuildをしました.まず,liburcuが必要になりますが,これは,sbopkg -iでインストールできます.

結論的には,Slackbuilds.orgのスクリプトが対象としている,glusterfs 4.1.0というのが,古すぎのため,本家でarchive送りとなっていて,ダウンロードできないようです.そこで,展開したbuildスクリプトのディレクトリーに適当なところから見つけてきた,glusterfs-4.1.0.tar.gzをおいて,glusterfs.Slackbuildを走らせたらbuildできました.

ただし,4.1.0はoutdatedということになるので,QEMUが許してくれるかはわかりません.

いよいよ,  QEMU本体のbuildに進みます.

Mesaを12に上げたことによる副作用として,KDEのOpenGLを必要とするいくつかのデスクトップ効果が動かなくなります(MesaはOpenGLとコンパチで,OpenGLの代わりにインストールされている).たぶん,KDEをbuildし直さないといけないのだと思いますが,それはやめときます😓

Raspberry Piで暮らせるか (10・終) 一旦おしまい

メインWSとして使用できるかという,実用性の評価は,一旦おしまいにします.

まあ,メインのWSにするというのは,よほど体力知力と時間に余裕がある場合以外はやめといた方がいいと思います.

Raspberry Pi 4本体はサーバーの予備用とし,SSDはしばらく起動できるようにそのままにしますが,必要があれば使い回すことにします.

KVMが使い物にならん

弱りました.結局,KVM周りをupdate/upgradeしないと,どうにも仮想マシンが動かないようです.

そのupdate/upgradeの試みは一度頓挫してます😓

Debianの仮想マシンをしばらく動かしていると,反応がだんだん悪くなり,無応答になります.システムモニターであるgkrellmも状態を更新しなくなります.

そうなる前にコンソールからtopコマンドでプロセスを監視すると,scsi_eh_なんとかいうプロセスが,ある程度のcpu cycleを安定して使用しています😓

ホスト側から見ると,qemuなんとかいうプロセスが動いているに過ぎません.だから,SCSIのエラーが起きているにしても仮想マシンの中で完結しているのかなと思いましたが,ホストを再起動するとホスト自体がSSDのハンドリングに失敗するので,システムワイドなエラーのようです.

KVM/QEMUはSlackbuildsにあるので,自力buildした分に上書きインストールしてしまう,というのが一番確実な可能性が高い方法と思います.この場合のリスクは,KVM/QEMUのメインテナーが途中で飽きて投げ出すことです.

かといって,自力update/upgradeは失敗しているしなぁ😓

SCSI Error Handler.
一旦電源リセットしないと,ホストが起動しません.