仮想化通信

日本仮想化技術株式会社の公式エンジニアブログ

Ubuntu Server 20.04のLXD環境が壊れてヒヤッとした話

何気なしにLXD環境があるOSをアップデートをして、再起動をしたら、いつまで経ってもLXDが起動しなくなってしまいました。しかしこれはOSC( https://ospn.jp )のWebサーバーなので、呑気なことも言ってられず、なんとかすぐに治す必要があります(何気なしにアップデートするな、それはそう)。結果としては20分ほどで解決はできましたが、今日のヒヤリハットでした……。

現在の環境

LXDホストはUbuntu Server 20.04上にsnapで導入しており、CentOS 7 x 1台、Ubuntu Server 20.04 x 2台の計3VMが動いています。トラックはlatest/stable/ubuntu-20.04を使用していて、事態が発生してから確認したところ、4日前にrefreshされた跡がありました。よって、OSアップデートとは関係なく、4日前には勝手にアップデートされていて、人間がOSを再起動すればいつでも壊れる状態になっていたと言えます。

tracking:   latest/stable/ubuntu-20.04
refresh-date: 4 days ago, at 07:48 JS

エラーを見る

/var/log/syslogを見ると、LXDが再起動を繰り返していましたが、エラーはZFSがどう、みたいな感じのようです。肝が冷えます。良くない。

Apr 23 00:00:11 ospn lxd.daemon[2790891]: time="2024-04-23T00:00:11+09:00" level=error msg="Failed loading storage pool" err="Required tool 'zpool' is missing" pool=sdb
Apr 23 00:00:11 ospn lxd.daemon[2790891]: time="2024-04-23T00:00:11+09:00" level=error msg="Failed to start the daemon" err="Failed applying patch \"storage_move_custom_iso_block_volumes_v2\": Failed loading pool \"sdb\": Required tool 'zpool' is missing"
Apr 23 00:00:12 ospn lxd.daemon[2790891]: Error: Failed applying patch "storage_move_custom_iso_block_volumes_v2": Failed loading pool "sdb": Required tool 'zpool' is missing
Apr 23 00:00:13 ospn lxd.daemon[2790258]: Killed
Apr 23 00:00:13 ospn lxd.daemon[2790258]: => LXD failed to start

LXD 5.21からZFS 2.1が必須なのでHWEカーネルに変更せよ(???)

検索すると、すぐにGithubのIssueが出てきました。

github.com

いわく、LXD 5.21からZFS 2.1が必要になったらしく、Ubuntu Server 18.04と20.04ではHWEカーネルに切り替える必要があるとのこと。確かにリリースノートにもありますが、リリースノートを毎回チェックするのは無理がありますし、勝手に配信されたものが破壊的な変更をしてくるのはどうなんだという気持ちはあります。

discourse.ubuntu.com

とにかく、HWEカーネルに変更すれば起動できるようになると信じてaptコマンドで導入して再起動しました。

# apt install linux-image-generic-hwe-20.04

データベースエラーも

再起動してもLXDは起動せず。エラーを改めて見ると、今度はデータベースにエラーが。これもまた肝が冷えます。良くない。

Apr 23 10:25:12 ospn lxd.daemon[7758]: => Starting LXD
Apr 23 10:25:13 ospn lxd.daemon[7908]: time="2024-04-23T10:25:13+09:00" level=warning msg=" - Couldn't find the CGroup blkio.weight, disk priority will be ignored"
Apr 23 10:25:13 ospn lxd.daemon[7908]: time="2024-04-23T10:25:13+09:00" level=warning msg="Instance type not operational" driver=qemu err="KVM support is missing (no /dev/kvm)" type=virtual-machine
Apr 23 10:25:13 ospn lxd.daemon[7908]: time="2024-04-23T10:25:13+09:00" level=error msg="Failed to start the daemon" err="Failed to start dqlite server: raft_start(): io: closed segment 0000000000352433-0000000000352460 is past last snapshot snapshot-1-352256-1276509404"
Apr 23 10:25:13 ospn lxd.daemon[7908]: Error: Failed to start dqlite server: raft_start(): io: closed segment 0000000000352433-0000000000352460 is past last snapshot snapshot-1-352256-1276509404
Apr 23 10:25:14 ospn lxd.daemon[7758]: Killed
Apr 23 10:25:14 ospn lxd.daemon[7758]: => LXD failed to start

幸い、これもすぐに類似事例が見つかりました。

discuss.linuxcontainers.org

どうやら、(データベースをバックアップの上で)エラーになっている[0000000000352433-0000000000352460]のファイルを消せば良いらしいです。バックアップは略して、mvコマンドで該当のファイルを退避してみました。

~# cd /var/snap/lxd/common/lxd/database/global
/var/snap/lxd/common/lxd/database/global# mv 0000000000352433-0000000000352460 ~

結果、これでLXDが回復して、VMが無事に起動してきました。良かった。

どう対策しよう

4年前のサーバー構築当初からlatest/stable/ubuntu-20.04トラックを使用していましたが、ここまでやんちゃなアップデートが来たのは初めてで、そんなものが来るとも思っていなかったので、少し困惑しました。もう4年前のOSなので仕方ない気もしますが、こう、バージョンの互換性とかは気を使ってほしい気がしました。

社内から、バージョンは固定すべきとのコメントもありましたが、個人的には、バージョン固定にいい思い出がない(安定して動くとそのバージョンから上げなくなり負の遺産になりしがち)のでそれは避けたく悩ましい問題です。可といって今後もこう言うアップデートのされ方をされるとつらいし。悩ましい。

そもそもLXDもフォーク問題が起きているらしい

最近は利益がどうこうを巡るOSSプロダクトのフォークが盛んですが、LXDもいつの間にかそれらの仲間入り?をしていたらしく、これも社内から情報が共有されました。

discuss.linuxcontainers.org

LXDからフォークした方はIncusとなり、Canonicalが主導するLXDと分かれる格好のようです。なんとなく、続けるならIncusのほうが良さそうに見えますが、果たして。

gihyo.jp

式年遷宮の機運

現環境のCentOS7もEOLが6月末に控えているので、いよいよXOOPSとお別れをしてCraft CMSに統合するかと考えていた矢先、LXDの罠を踏みつつLXDの近況を知ってしまった午前でした。あと数日でUbuntu Server 24.04もリリースされるので、CMS改築作業とともに、Ubuntu Server 24.04 + Incusによる新環境構築のタスクが見えてきました。メイン業務の片手間でやりきれるかしらん……?