横断歩道での一時停止は善意ではなく義務 (Powered by WordPress)
今のプロバイダーにしてから約2年です．これまでも夜間のスピード低下は気になっていましたが，最近は連日かなりひどい状況です．
最初に光ファイバーを引いたときは，10Mbpsだったので，こんなだったかもしれませんが，今は1Gbpsなので，いくら何でもって感じです．
ちなみに混雑時でない朝なんかだと，
こんなもんで，まあまあです．しかし，Nuroにしていた頃は，測定サイトが違いましたが，上下とも800Mbps以上出ましたので，残念ではあります．
あと一年少々で縛りが切れるので，NuroかSo-netのauにします（戻します）．
QEMU本体は特に問題なくbuildできました．
Slackbuilds.orgにある説明によれば，前のバージョンのlibvirtファイルを削除しないといけないとあるので，/usr/lib64や/usr/sbinにある，libvirt関係と思われるファイルをパスの通らないところに移動して，sbopkg -bしましたところ，何のエラーも出ずにbuildできてしまいました．
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で起動したときデーモンが居座らない問題を調べてみます．
libvirtdを起動するオプションに-lがついていて，これを手動で起動するときにつけるとやはりエラーが出ます．-lがなくてもネットに繋がるので，起動スクリプトから-lを外しました．
SlackwareでQEMU/KVMを更新することにした．基本的には，slackbuils.orgにあるものはそのまま利用することにする．
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を試みたら成功した．
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する．
glusterfsのみファイルのfetchに失敗してbuildできない（2020/12/07現在）．その他はsbopkg -bでbuildできる．
Optionalということなので，glusterfsは放置して先に進む．
そんなに難しくないだろうということで，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に進みます．
メインWSとして使用できるかという，実用性の評価は，一旦おしまいにします．
まあ，メインのWSにするというのは，よほど体力知力と時間に余裕がある場合以外はやめといた方がいいと思います．
Raspberry Pi 4本体はサーバーの予備用とし，SSDはしばらく起動できるようにそのままにしますが，必要があれば使い回すことにします．