先日、Hyper-VのStorage Migrationが不完全な形で終わってしまい何故か2台の仮想サーバーになってしまう、しかも1台は起動が不可能、もう一台は相当過去の状態に戻ってしまう…というかなりクリティカルな問題が発生しました。テスト用の環境でかなり乱雑に扱われていたのが原因だろうとは思うのですが…。

詳しく説明すると以下のような状況でした。

- もともとのVMは4つのスナップショットが存在していた。
- Storage Migrationに関連したトラブル発生後、VMは2つになってしまった。それぞれVM1とVM2とします。
- VM1には設定上スナップショットが4つ存在することになっていました。
- VM2には設定上スナップショットが存在しないことになっていました。
- VHDXファイルおよびAVHDXファイル群はまとめてVM2が存在してる方のディレクトリに存在していました。
- VM1はもともとのVMの最新のAVHDXファイルがHDDとして設定されていました。ただしそのパスにはもうAVHDXファイルは存在していません。このためVM1は起動不可能でした。
- VM2はもともとのVMの一番大元のVHDファイルがHDDとして設定されていました。起動するとテンプレートから展開直後の状態のようでした。(もともとテンプレートから展開直後にスナップショットを取得していたものと思われる。)

結果的にAVHDXファイル群は存在しているものの、VM1は起動しないし、VM2は過去の状態だし…で事実上すべてのデータが失われている状態でした。

この状態からなんとか最新の状態で仮想マシンを起動しようと頑張ったのですが結構苦労してしまいました。

あまりAVHDXファイルのことを知らなかったのですが、今回調べる中で以下のことを確認しました。

- AVHDXファイルの「親ファイル」の情報は、ファイルのパスとIDをAVHDXファイル自体が保持している。別途XMLファイル等にかかれているわけではない。
- 仮想マシンのディスクのパスとしてAVHDXファイルが指定されると、AVHDXファイルの親、更にその親…という形で「チェーン」をたどって、きちんと一番の親までチェーンをたどりきれればマウント可能となり、起動できる。チェーンが途中で破損していると以下のメッセージが出て起動できない。

- このチェーンの破損の修復はHyper-Vマネージャーで仮想ハードディスクの編集を行うことで可能。親ディスクを指定し直すことや、その際にIDの不一致を無視させることも可能。

 

今回のケースではこの方法でチェーンの破損を修復した上で、最新のAVHDXファイルをマウントすることで最新の状態でVMを起動させることが出来ました。

 

ちなみに、スナップショットの情報はXMLにかかれていてうまくXMLを編集してあげればVM2側でスナップショットまで復旧できるだろうと思ったのですが、単純にVM1のスナップショットの記述をVM2のXMLファイルにコピペするだけではダメでした。復旧優先だったので深追いしていませんが、スナップショット情報の記述方法はもうちょっと研究しないとダメそうです。

また、調べている最中で知りましたが、AVHDXファイルは単純に拡張子をVHDXファイルに変更してしまった上でマウントなどの操作もできてしまうのですね。大味でちょっとびっくりしました。

あまり有効活用する機会に巡りあいたくない知識ですが、どんな場合でもVHDX, AVHDXファイルさえ確保できていればデータの復旧に関しては大丈夫そうな印象を受けました。