東ザナラーンの「キャンプ・ドライボーン」で見た光景だなぁ・・・
・・・という訳で、LinuxホストのWindows10パソコンを修復していました。原因はLinuxの定期アップデートをDNFで行ったことによる不具合。Windows updateとは異なって、Linuxの更新は少し厄介なことが多いので良いイメージはしない。しかし行わなければセキュリティ上の問題も。ということで、立ち上がらなくなったWindows10ゲストの修復に乗り出すことに・・・（開始時間は１４日の１５時ぐらい）
★ 仮想マシンの開始中にエラーが発生しました！
仮想マシンの開始中にエラーが発生しました: 内部エラー: qemu unexpectedly closed the monitor: 2020-04-14T08:52:55.844144Z qemu-kvm:（中略）failed to setup container for group 1: No available IOMMU models
CentOS8の定期アップデート直後システムを再起動し、Windows10ゲストを仮想化クライアントから起動とすると、エラーが出てしまいます。
一瞬、頭が真っ白になったのですが、翌々見ると『IOMMUモジュールを正しく読み込んでいない』というエラーのようです。念のため、動作確認を行えるコマンドがあるので、こちらで調べると・・・
# virt-host-validate
QEMU: 確認中 for hardware virtualization : 成功
QEMU: 確認中 if device /dev/kvm exists : 成功
QEMU: 確認中 if device /dev/kvm is accessible : 成功
QEMU: 確認中 if device /dev/vhost-net exists : 成功
QEMU: 確認中 if device /dev/net/tun exists : 成功
QEMU: 確認中 for cgroup ‘cpu’ controller support : 成功
QEMU: 確認中 for cgroup ‘cpuacct’ controller support : 成功
QEMU: 確認中 for cgroup ‘cpuset’ controller support : 成功
QEMU: 確認中 for cgroup ‘memory’ controller support : 成功
QEMU: 確認中 for cgroup ‘devices’ controller support : 成功
QEMU: 確認中 for cgroup ‘blkio’ controller support : 成功
QEMU: 確認中 for device assignment IOMMU support : 成功
QEMU: 確認中 if IOMMU is enabled by kernel : 成功
・・・という具合にシステム上の問題は認められませんでした。『vfio_pci』も正しく認識されていました。色々と調べて格闘した結果、以下の手順で復旧が叶いました。
① allow_unsafe_interruptsオプションの指定
#vim /etc/modprobe.d/vfio_iommu_type1.conf ←新規作成
options vfio_iommu_type1 allow_unsafe_interrupts=1 ←内容を追記して保存
② KVM-QEMUで必要な各種モジュールの読み込み
# vim /etc/modules-load.d/modules-list.conf ← 新規作成
vfio
vfio_iommu_type1
vfio_virqfd
kvm
kvm_intel
↑ 以上を記述して保存。（注：vfio_pciは別ファイルで記述、適用済み）
再起動を行い『lsmod | grep vfio』等で読み込まれているかを確認。以上でゲストのWin10を立ち上げることが叶いました。ここまで要した時間が１２時間・・・一つ一つ障害を調べたので時間がまた。ただ、今回はPCIパススルーが一時的にできず、PCIデバイスを削除するとコンソール上でWin10が起動したので、恐らくPCIパススルー絡みだろうと、そこを重点的に調べていたところですが、モジュールが認識されていなかったとは・・・。
原因が分かればLinuxも使いやすいのですが・・・。元々大容量メモリ積んだゲーミングＰＣをＨＤＤ大量増備のデータサーバーとして運用しつつ、LinuxでFF14を！というスローガンで進めた夢の詰まったクルル鯖。まだリソースに余裕があるので、別ＯＳの仮想化で練習をしてみようかな・・・
ちなみに今回のdnf絡みのトラブルで、いい方法を見つけたので・・・。dnf -y update(又はupgrade)を再度行うことができず、upgradeコマンドを使えるのは次回のアップデートまで待たねばならないのですが、万が一エラー発生で途中で停止してしまった場合の『再試行』方法がみつかったので、記しておこうと思う。
『 dnf list installed > /root/dnf.list 』でリストアップファイルを作成し『 dnf -y reinstall `awk ‘{print $1;}’ /root/dnf.list | sed -e ‘s/\.x86_64.*$//i’ -e ‘s/\.noarch.*$//i’` 』を実行するだけ。するとアップデートしたプロセスを含むプログラムを強制的に再インストール（＝再アップデート）させることができます。あとは再起動して新パッチ適用させるだけ。万が一この方法で途中停止する場合は、引っかかったプロセス（プログラム）を『dnf remove (プロセス名)』で削除して、コマンドを再実行すれば再アップデートができる。かなり横暴な方法ではあるが、system updeteで失敗した場合に覚えておこう。
最近はおこもり需要なのか、ＦＦ１４のクエストかなり進みました。ＦＦ１４自体はだいぶ前からアカウントを復旧させてプレイをしていましたが、イシュガルドにすら到達できていない亀ペースの低接続状態でしたが、４月から課金を再開させて、良いＦＣにも巡り合えて毎日過ごしています。本来の『LinuxでFF14をプレイしたい！』という需要にこたえる形で、メインクエストを進めています。新生エオルゼアのラストは皆離れ離れになってしまい追われるようにイシュガルドへ・・・というシーンは悲しくて泣いてしまった。でも、イシュガルドへ行けたことは大きな意味があるので、このどうしようもないリアルを少し忘れてメインクエストを継続しようと思います。調べたら新生を含め、まだ未攻略のＩＤや討滅戦があったり、グランドカンパニーの階級上げも進んでいなかったりと、色々課題があるので。プロデューサーさんも確か新型コロナのことで言及はしていたけど、今だからこそ非日常の体験ができるという部分・・・正直リアルマダオ状態にとっては複雑な状況であるけど・・・そこは・・・ね？
１世帯あたり３０万円の現金給付が実現すれば、そして実際に受け取ればすぐに転居という道も開けるのですが、非課税世帯の所得が基準って、ほぼほぼ皆に支給しませんって言っているようなもの。失業してしまったという人は該当しないのではという不安も。それは住民税の課税対象は『前年度（つまり令和元年度）』の所得に基づくため、退職した年度というのは含まれないのです。失業直後は健康保険料も含めそれなりに支払いが増えます。そこに非課税世帯目安ですと言われては・・・
昨日になって、国民の声が届いたのか、条件付き現金給付を１人１０万円という話を与党のだれかが言っていた気がするけど、ほんと、この国の新型コロナ政策は・・・もう・・・という感じ。こればかりはどうしようもないねぇ。
イベント主催者関係の支援として、直接の休業補償はできないとしつつ、代わりに参加者（消費者）がチケットの払い戻しに応じなければ、その額の一定額を寄付したものとして税控除する案は、個人的に活用したいなーと思った。イベントチケットを払い戻ししなければその額を税控除できれば、その分来年度の住民税や国保税を安くすることができる。イベントやライブ遠征が多い人で大量にキャンセルとなったならその額も大きいはずなのでうれしいと思っている。一方で主催者側はそのままチケット代金をもらえるため、WINWINの関係になれるという。本当にそのような制度設計なのかはわかりませんが、その通りの制度なら活用の余地はありそう。でも、そう簡単にはいかなそうだなぁ。政治の問題もあるので、これ以上は触れないでおく。いずれにしても、この先幸せがあることを願い、今日もエオルゼアを旅していく。