QEMU/KVM 作業メモ2

QEMU

QEMU本体は特に問題なくbuildできました．

libvirt

Slackbuilds.orgにある説明によれば，前のバージョンのlibvirtファイルを削除しないといけないとあるので，/usr/lib64や/usr/sbinにある，libvirt関係と思われるファイルをパスの通らないところに移動して，sbopkg -bしましたところ，何のエラーも出ずにbuildできてしまいました．

libvirt-glib

libvirt-glibがないと，既存のvirt-mangerがQEMUに接続できないようなので，sbopkg -iしときました．また，ついでにlibvirt-pythonもsbopkg -iしました．

起動テスト

ここで，システムをリブートした後，

/etc/rc.d/rc.libvirt start

を実行してみたところ，libvirtdの起動時にエラーが出てデーモンが常駐しません．エラーメッセージに，–daemonなしで起動してエラーを確認せよ的なメッセージが出るのでそのようにしてみましたが，その場合エラーが出ずに，libvirtdが常駐してくれます．

この状態で，virt-mangerを起動したら問題なく動いてくれますので，debianのクライアントを起動して，しばらく様子を見ています．

まだ，10分位しか動かしていませんが，scsi_eh_なんとかのプロセスは今の所現れていません．なんとか本質的な問題は，解決した模様です．

あとは，rc.libvirtで起動したときデーモンが居座らない問題を調べてみます．

rc.libvirt

libvirtdを起動するオプションに-lがついていて，これを手動で起動するときにつけるとやはりエラーが出ます．-lがなくてもネットに繋がるので，起動スクリプトから-lを外しました．

糠喜びでした．

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.
一旦電源リセットしないと，ホストが起動しません．