🕌
Azure仮想マシン(Ubuntu)が起動しなくなったので作り直した

2024/10/04に公開
 はじめに普段Azure上では仮想マシン(Ubuntu)上にDockerサービスを入れて、コンテナ上で個人的なサービスを動かしています。
なぜContainer AppsやContainer InstancesなどのAzure PaaSを使わないのかというと、普段からLinuxに触れる機会を常に維持するのが目的です。(お仕事だったら無論PaaSをフル活用します！)
先日カーネルアップデートや設定変更を繰り返していたらrootボリュームがマウントできなくなり、OSが起動しなくなったのでその対応をしました。

 この記事でわかること、わからないことOSが起動するように修復する方法はこの記事ではわかりません(そんなにLinuxカーネルには詳しくない)
新規仮想マシンを再作成後、故障した仮想マシンのOSディスクをマウントする手順がわかります
データディスクのスナップショットを取り、新規仮想マシンにマウントするためのマネージドディスクの作り方がわかります

 起動しなくなった仮想マシンAzureポータル上では仮想マシンの状態は起動中ですが、いつまで経ってもsshによるログインが出来なくなりました。
「何もしていないのに起動しなくなりました！」って報告する人もいないので自分でなんとかするしかない。


画像では「penpen」となっていますが元の仮想マシン名は「tama」です
「ヘルプ」「シリアルコンソール」でOS起動中の状態を表示してみると、/dev/rootデバイスが開けず、カーネルパニックを起こしています。正に地獄。


画像では「penpen」となっていますが元の仮想マシン名は「tama」です
この仮想マシンはいわゆるGen2で、EFIのセキュアブートを使っています。あまり巷にも情報がまだないため、自力で復旧できる気が全然しない。
秒で諦めてこの仮想マシンは捨てることにします。

 仮想マシンの削除起動しなくなった仮想マシン(Azureリソース的な意味)は不要なので削除します。
仮想マシンに紐づいているディスク、パブリックIPなどは後から再利用するので一緒に削除せずに残します。NICはいらないので仮想マシンと一緒に削除しました。


画像では「penpen」となっていますが元の仮想マシン名は「tama」です
仮想マシン削除後にもOS、データディスクのAzureリソースが残っていることを確認します。

 新しい仮想マシンを作成既存の仮想ネットワーク内に新規仮想マシンを同じUbuntuを利用して作成します(私はCanonical Ubuntu Server 22.04 LTSを愛用)。
Azureポータルから作成時にはデータディスクのマウントは行いません。OSディスクだけ作成します。
前に使っていたパブリックIPを指定することで外部からの接続設定(DNSレコードとか)を省略できますね。
私の場合、もともとの仮想マシンがIPv4, IPv6のデュアルスタック構成だったのでNICのipconfigにIPv6の設定を追加したりしましたが、通常は必要ないでしょう。
当たり前ですが、仮想マシン作成後に普通にsshログインできました。

 古いOSディスクから必要なファイルをサルベージアプリ、サービス類はaptで再度導入すればよいと思いますが、/var, /etc配下にあった復元させたいファイルをコピーしましょう。
Azureポータルから新しい仮想マシンの「設定」「ディスク」から元のOSディスクを「既存のディスクのアタッチ」で接続します。
この操作は仮想マシンが起動中(sshログイン中)に実行して構いません。
sshコンソール上からdmesgコマンド結果を確認します。
sudo dmesg | tail
追加された古いOSディスクはsdcとして認識したことがわかりました。
fdiskで論理デバイス名を確認します。
sudo fdisk -l /dev/sdc
Linux filesystemとしてパーティションが切られているのは/dev/sdc1だということがわかりました。
永続的なマウントは必要ないので手動で一時的に/dev/sdc1をマウントします。
sudo mkdir /mnt/root
sudo mount /dev/sdc1 /mnt/root
もともとの / ディレクトリが /mnt/root でアクセスできるようになりました。
後は必要なファイルを /mnt/root/etc や /mnt/root/var などからコピーしましょう。
私の場合は元々Wireguardを使って自宅と閉域接続していた関係から、/etc/wireguard/wg0.confがとても必要で、それ以外のデータファイルは全てBtrfsな追加ディスクに保存していたのであまり復元が必要なファイルはありませんでした。
https://zenn.dev/yotan/articles/8082cfe1060860
画面キャプチャを忘れてしまいましたが、必要なファイルのコピーが完了したらumountして、Azureポータルから追加ディスクをデタッチしておきましょう。
sudo umount /mnt/root

 データディスクの複製とマウント元のデータディスク(冒頭の例でいうとdisk-tama-data01)をそのまま新しい仮想マシンの追加ディスクとしてアタッチしても良いのですが、万が一操作ミスで何かあったら怖いのでディスクをコピーして、コピー先のディスクを今後マウントして使います。
Azureマネージドディスクは1手順でコピーは行えず、以下の操作が必要です。
(旧)マネージドディスクのスナップショットを取得
スナップショットから(新)マネージドディスクを作成
マネージドディスクのアタッチ・マウント

 マネージドディスクのスナップショットを取得元のマネージドディスクのディスクの状態が「Unattached」になっているので今時点で誰も使っていない(アクセスされていない)状態ですね。
「＋スナップショットの作成」をクリックしましょう。
一時的な利用目的のスナップショットなので名前は適当に。スナップショットの種類は「フル」にすることで今後マネージドディスクだけ削除してもこちらのスナップショットは残るので一応設定。
特に可溶性も速度も必要ないのでストレージの種類は「Standard HDD(ローカル冗長ストレージ)」(いわゆるStandard_LRS)にしています。

 スナップショットからマネージドディスクを作成作成されたスナップショットから「＋ディスクの作成」をクリックします。
ディスク名には新しい仮想マシンの名前を模した名称をつけました。
作成された新ディスクは無論Unattached状態。

 マネージドディスクのアタッチ・マウント先に古いOSディスクをアタッチしたのと同様の手順で作成された新ディスクをAzureポータルから接続します。
私の場合、データディスクはBtrfsであったので、dmesgの結果を見ると勝手に認識してBtrfsのモジュールがロードされました。
btrfs的なファイルシステム情報を確認すると、ちゃんともともとの設定が保持されていました。
sudo btrfs filesystem show
永続的にマウントするため、/etc/fstabにエントリ追加。
こちらの例はBtrfsでサブボリュームも含めたマウント設定です。
通常はfstabの既存の行を参考にするか、適当にググってエントリを追加しましょう。

 追加作業こちらはそれぞれの環境依存なのでなんとも言えませんが、私はDocker, Wireguardのパッケージを追加インストールして、データディスク(/data)配下に元々あったDocker composeをupしまくるだけで復元完了でした。

 後始末新しく作成した仮想マシンで問題なく利用できると判断したら、最後に古いマネージドディスクや、一時作成したスナップショットなどは削除してよいと思います。

 おわりにそういった事態にならないように、本当であればAzure Backupを使って日次バックアップ程度は取っておけば良かったと今更後悔しています。
新しい環境では、ちゃんとバックアップ取っていますよ。
Gen2のEFIセキュアブートの場合でも、2024/7末に一般公開されていますので安心してバックアップできます(それも1日に複数回)。
Azure Site Recovery support for Azure trusted launch virtual machines
以上、誰かのお役に立てば幸いです。