ちょっとアプリケーションだなんだを仮想マシンベースで動かしたい場合のために、Linux KVM環境を動かしています。
このLinux KVMはDebianベースで長いこと動かしていたのですが、サーバーをHP G7世代のサーバーから新しいものに切り替えた際に、Ubuntu Serverベースに切り替えることになりました。
UbuntuはDebianベースであるのもあって､Linux KVM環境の移行はそこまで難しくはありませんでした。
移行から数ヶ月経ったある日と言うか昨日､大問題が発生しました。
いつものようにサーバーメンテナンスでソフトウェアアップデートと再起動を実施しました。
Linux KVMは色々動いているのもあって､メンテナンスは手動で行っています。
ソフトウェアアップデートが終わったので再起動を行い､仮想マシンを起動して復旧しようとしたところ､次のような無情なメッセージが表示されるのでした。
「Error Starting domain: Cannot access storage file… No such file or directory」
この環境は､ストレージをOS用とVM用で分けています。
そのようにしたのは元々はストレージの容量がまだ小さかったときの名残ですが､そのようにしておくとサーバーの更新の際に移行が楽な点やシステムのストレージ食いつぶしで…みたいな事も防げるので､いまだにそんな運用をしています。システム側はSSDにして､VM置き場はHDDにしてみたいなことができますしね。
OSは起動したのに何で？と思って､VMのストレージのディレクトリーである/opt/vmsディレクトリーを確認しました。
無いですね。qcow2ファイルも含めて必要なファイルが何もかも。
$ cd /opt/vms $ ls EFI
その瞬間､10年くらい前の記憶（トラウマ）がよみがえりました。
10年前と同じ原因で消失？
実はこの手の問題が起きたのは10年くらい運用していて今回で2回目なんですよね。
その2回とも､UbuntuでLinux KVM環境を動かしていたときに起こっているのです。あの時もアップデートして再起動したらこんな状態になった記憶があります。
1回目の時はログくらいは見たものの原因究明まではせず､イラッとしてUbuntuからDebianに切り替えたのでした。それから長いことDebianのメジャーバージョンをアップデートしながら運用していました。
じゃあなんで今､そのUbuntuを使っているんだと言われそうですが､あるときサーバーを切り替える前のG7世代のサーバーでDebianのアップデートをしたら､Linux kernelの起動のところでフリーズする問題に悩まされたのがきっかけだったりします。日付を見ると2024年9月30日のことです。どうやらこの問題と同じような原因っぽいです。新しいOSを動かすにはサーバーが古すぎるんじゃいと言う話っぽいです。ここら辺は物理マシンでOSを動かすときあるあるでしょうか。仮想マシンベースに使い慣れると忘れてしまう話ですね。
何度か「新しい世代のマシンへの切り替えを！」と言われていたものの､それから何年もそのまま運用していたのですが､さすがに厳しくなってきたのもあり､サーバー移行とOSの切り替えを同時に実施することになりました。
サーバーの設定とOSのセットアップはお願いして､Linux KVMのxmlファイルとqcow2ファイルをストレージから取り出して再設定しました。ストレージを分けておいて本当に良かった。
ところで今回DebianではなくてUbuntuにしたかというと、社内のサーバーは現在基本的にはMAASでだいたい管理されていて､MAASでUbuntuをデプロイするのは楽だったからと言う理由があります。
社内標準のOSとしてUbuntuを使い始めているというのも理由だったりします（アプリケーションの都合で､一部ほかのディストリビューションもありますが）。
社内には自分で構築したUbuntu LTSバージョンのローカルdebミラーがあり､運用上楽だったからというのも理由だったりします。少なくとも自分が動かすUbuntuベースの検証環境は､そのミラーからパッケージを取得するような設定にしています。
今回の主な原因
今回のと言うか前回もおそらく同じ原因でこの問題が起きたと思われますが､ストレージをシステム用と仮想マシンのファイル置き場の2つに分けていました。
システム用はOSのセットアップ時に自動設定されているので問題はありませんが､仮想マシンのファイル置き場用のストレージはOSのセットアップ後に接続したため､未設定の状態でした。
未設定とはいえ､マウントして/etc/fstabに書いて終わりなんですが､/etc/fstabの書き方が原因だったようです。
もともとの設定は次のような書き方でした。/dev/sdX形式で指定するという従来の書き方です。
/dev/disk/by-id/dm-uuid-LVM-HAfXpAdVHFDKi3ReMWufIT0MzWmcPzNuxTcUHxfv2ZzF9QGNSqSUyDLNINiDy5vK / ext4 defaults 0 1 # /boot was on /dev/sda2 during curtin installation /dev/disk/by-uuid/bb105ba3-5366-4276-86f1-1e1d85b01930 /boot ext4 defaults 0 1 # /boot/efi was on /dev/sda1 during curtin installation /dev/disk/by-uuid/1563-CE1F /boot/efi vfat defaults 0 1 /swap.img none swap sw 0 0 /dev/sdb1 /opt/vms ext4 data=ordered 0 0
この書き方は現在は推奨されないようで､時に違うディスクにマウントされたりマウントに失敗する事があるようです。
ただ運が良かったのか同じような運用をしていてもRHELやRHELクローン､Fedora､Debianといったような私がよく使うほかのディストリでは経験したことがありませんでした。
運が良かっただけ､偶然だったようです。
と言うわけで､Claudeにどう設定したら良いか聞いてみました。
まずこれを確認しろとのことでした。
# すべてのブロックデバイスを表示 lsblk # すべてのディスクを確認 ls -la /dev/sd* # dmesgでディスク認識のログを確認 dmesg | grep -i "sd[a-z]"
lsblkの実行結果を渡すと､次のように導いてくれました。
ディスクの順序が入れ替わっています： 現在： /dev/sdb = システムディスク、/dev/sda = VMデータディスク（マウントされていない） 以前： /dev/sda = システムディスク、/dev/sdb = VMデータディスク VMデータは/dev/sda1にあるはずです！
典型的な/dev/sdaと/dev/sdbが入れ替わってしまった事例だったもようです。
確認しましょう： # /dev/sda1をマウント sudo umount /opt/vms # 現在の間違ったマウントを解除 sudo mount /dev/sda1 /opt/vms ls -la /opt/vms
これを実行して､/opt/vmsディレクトリー配下に必要なファイルが復元されました。
つまり本来は/dev/sdb1として認識されていて欲しいデバイスが､いまは /dev/sda1として認識されているということです。これはまずい。一方で/bootがいるパーティションはby-uuidの形式で記述されているのでOS自身は問題なく起動してきたという話だったようです。
/dev/sdb1を再起動後もマウントされるように､UUIDでデバイスを指定する方法で記述することにしました。
現在は/dev/sda1として認識されているので､/dev/sda1のUUIDを確認します。
# /dev/sda1のUUIDを確認 sudo blkid /dev/sda1 # fstabを編集 sudo nano /etc/fstab UUID=/opt/vms ext4 defaults 0 2
今回は次のように設定しました。オプションは元の設定に合わせました。これ以降､問題は起きていません。
#/dev/sdb1 /opt/vms ext4 data=ordered 0 0 UUID=5f97c90d-3929-4e91-989a-b25878dd6b4f /opt/vms ext4 data=ordered 0 0
先にリンク情報を示したように､RHELの少なくとも5以降のバージョンでも起きうる問題で､RHELではlabels/WWID/UUID ベースの名前を推奨しているようです。ナレッジにたくさん書かれていました。
いくつかの選択肢の中でUUID形式が一番私には分かりやすかったので､UUID形式で書くことにしました。
また､社内にはいくつかRHELで動いている私が構築したPG-Strom環境があるので､同じ対応をしておきました。今は問題なくても､いつ何があるか分からないですからね。
