Category: KVM

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を外しました．

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に進みます．

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

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

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

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

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

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

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

DOSのエミュレーターに関しては連戦連敗状態です．ちゃんとやる気になっていないというのが最大の理由かもしれません．適当に考えずに，パッケージをインストールして，先駆者たちのWeb情報を斜め読みして試して，だめだと諦めてパッケージをuninstall．

QEMUに関してはかなり長いこと使ってきているですが， AMD64 (x86_64)マシンにて，x86の32bitないし，64bitの仮想マシンを動かす（エミュレーションはしてない）というほぼワンパターンで使ってます．ですから，自力でインストールして長期間使っている割には経験値が積み上がってないです😥

WindowsでDOSboxを動かして経験を積む，Linux x86_64マシンで，QEMUの経験を積むっていうのを少し時間をかけてやってみます．

だんねん残念ながら，あきらめて，backupから，元に戻しました．

最大のネックは，GNOMEが，buildの環境をlibtoolからmeson (ninja)に変更したことです（当社調べ）．たとえばglibだと2.59.xと2.60.xの間でその変更があります．マイナーバージョンが1つ上がってこんなに変えて良いのかとわめきたくなります．GTK+3にも同様に境界があり，最新のソフトは，meson対応のGTK+やglibを要求し，逆に旧式のソフトは，libtool時代の.la拡張子のlibtool archiveを要求します．

で，記憶違いかも知れませんが，qemuは，依然としてlibtool archiveを要求するのに対し，virt-managerはmeson対応のGTK+を要求します．

まあ，ちゃんとメモを残したわけではないですが，そんな感じだったと思います．もうしばらく待って，世の中のdistroが，meson & ninja対応のGNOMEパッケージを使用するようなり，そういうのにupgradeしてから挑戦し直します．

それにつけても，ninjaって名前はなんとかなりませんかね．ネット検索しても「忍者」の情報ばかりかかります．スペイン語圏の人たちはninjaを「ニンハ」って読むんでしょうか．