Category: KVM

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を「ニンハ」って読むんでしょうか．

結局，久しぶりに取り組んでみることにしました．しかし，なかなかたいへんです．

以前buildしたときと比較すると，

1. 必要なライブラリーやツールが増えた
   • まあ，バージョンが進めばありがちなこと
2. glib関係のライブラリーのバージョンが相当進んだ
   • それなのに，sbopkgでは一部のパッケージのupdateが止まっている
   • よりによって，GNOMEがlibtool archive (.la)の使用をやめたので大混乱
3. Python2がobsoleteとなった

などの問題に遭遇しています．.laがなくなったことは，訳解らずにbuildしている人間にとっては大混乱を引き起こしました．SDL2のように，すでに，.laがなくても大丈夫なライブラリーもありますが，libvirtなどは，xxx.laがない，って文句を言って止まります．今回のupdate作業では，glibは最新のものでなく，2.58.xを使用することにしました．

virt-mangerのbuildまでいきましたが，起動すると，”gi”というモジュールがないといって止まります．明日以降取り組むことにします．

追記（2020/10/14）

giの件は，大きな問題ではなく，

pip3 install pygobject

で解決しました．が，それだけの問題ではなかったです．