SASディスクからRAIDアレイを正常に作成し（Adaptek raidを使用しました）、lvm-storageとして追加した後、仮想マシンのイメージの1つを転送し始めました。 転送の進行を検討する過程で、サーバーの音のトーンが変化したため、何かの疑いが潜んでいました。 そして、サーバーが独立した再起動に入ったとき、私は少し灰色に変わり始めました...そして、再起動後にどのストレージにもポータブルイメージが見つからず、新しいストレージ自体がステータス「利用不可」で表示されるという事実によって最終的に終了しました。
私の神経と一杯のコーヒーを落ち着かせるために少し歩いた後、私は袖をまくり上げて（そう、Tシャツを着て）、イメージを復元する方法を考え始めました...
もちろん、まずログに登り、SASアレイからストレージを作成中にエラーが発生したことを確認しました。
Error code: SR_BACKEND_FAILURE_47
エラーは、ストレージが利用できないことを意味します。 pvdisplayを使用して物理lvmボリュームをチェックすることにしましたが、SASアレイに作成されたボリュームが表示されませんでした。 pvsもボリュームを見つけられませんでした。
これは、実際にはリポジトリが作成されなかったことを意味します。 より正確には、ストレージオブジェクトはXenServerで作成されましたが、物理ストレージに関連付けられていませんでした。 XenServerがこのように動作し、さらに、このストレージにイメージを転送できるようにした理由は、まだわかりませんでした。
物理的に何も転送されていないため、SASアレイ上のイメージを探すことさえできないことがわかります。 したがって、元のストレージからイメージを復元する必要があります。
LVM論理ボリュームの回復に関するトピックのインターネット検索により、最初の発掘ベクトルが設定されます。
LVMは現在の構成を/ etc / lvm / backup /に保存し、通常の状態では、バイナリ構成の古い構成のアーカイブを/ etc / lvm / archive /に保存します。 XenServerリポジトリのUUIDは、LVM VolumeGroup名に対応しています。 しかし、XenServerではこのアーカイブが無効になっていることがわかりました。
/etc/lvm/lvm.conf
＃メタデータのバックアップとアーカイブの構成。 LVM2では、
＃「バックアップ」とは、メタデータのコピーを作成することを意味します
＃*現在*システム。 「アーカイブ」には古いメタデータ設定が含まれています。
＃バックアップは人間が読めるテキスト形式で保存されます。
バックアップ{
＃現在のメタデータ構成のバックアップを維持する必要がありますか？
＃はいの場合は1を使用します。 いいえの場合は0
＃これをオフにする前に一生懸命考えてください！
バックアップ= 1
＃どこに保管しますか？
＃このディレクトリを定期的にバックアップすることを忘れないでください！
backup_dir = "/ etc / lvm / backup"
＃古いメタデータ設定のアーカイブを維持する必要があります。
＃はいの場合は1を使用します。 いいえの場合は0
＃デフォルトでオン。 これをオフにする前に一生懸命考えてください。
アーカイブ= 0
＃アーカイブされたファイルはどこに行くべきですか？
＃このディレクトリを定期的にバックアップすることを忘れないでください！
archive_dir = "/ etc / lvm / archive"
＃保持するアーカイブファイルの最小数は？
retain_min = 10
＃アーカイブファイルを保持する最小時間は何時ですか？
retain_days = 30
}
＃「バックアップ」とは、メタデータのコピーを作成することを意味します
＃*現在*システム。 「アーカイブ」には古いメタデータ設定が含まれています。
＃バックアップは人間が読めるテキスト形式で保存されます。
バックアップ{
＃現在のメタデータ構成のバックアップを維持する必要がありますか？
＃はいの場合は1を使用します。 いいえの場合は0
＃これをオフにする前に一生懸命考えてください！
バックアップ= 1
＃どこに保管しますか？
＃このディレクトリを定期的にバックアップすることを忘れないでください！
backup_dir = "/ etc / lvm / backup"
＃古いメタデータ設定のアーカイブを維持する必要があります。
＃はいの場合は1を使用します。 いいえの場合は0
＃デフォルトでオン。 これをオフにする前に一生懸命考えてください。
アーカイブ= 0
＃アーカイブされたファイルはどこに行くべきですか？
＃このディレクトリを定期的にバックアップすることを忘れないでください！
archive_dir = "/ etc / lvm / archive"
＃保持するアーカイブファイルの最小数は？
retain_min = 10
＃アーカイブファイルを保持する最小時間は何時ですか？
retain_days = 30
}
さらに検索を行ったところ、lvmはすべてのVolumeGroup構成のアーカイブをこれらの同じVolumeGroupの初期セクターに保存することがわかりました。 私のストレージは別のアレイに配置されているため、このアレイの先頭を見ます：
# hexdump -C /dev/md1 | less
configsに似たものが表示される場合、これらのセクターのダンプを削除して読みやすくすることができます（私の場合、アーカイブは100Mbかかりました）。
# dd if=/dev/md1 of=dump.conf bs=100M count=1
lvmdumpコマンドを使用してダンプを削除することもできます。
ダンプでは、画像が失われた瞬間より前の日付の設定を探しています。
構成
VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191 { id = "TprMi6-z1OR-BGcz-uReP-if22-6122-tfu0zP" seqno = 5 status = ["RESIZEABLE", "READ", "WRITE"] flags = [] extent_size = 8192 # 4 Megabytes max_lv = 0 max_pv = 0 metadata_copies = 0 physical_volumes { pv0 { id = "0gexgQ-urcH-GZd0-iehs-ne0y-6JYz-ZTGbna" device = "/dev/md1" # Hint only status = ["ALLOCATABLE"] flags = [] dev_size = 473571375 # 225.816 Gigabytes pe_start = 20608 pe_count = 57806 # 225.805 Gigabytes } } logical_volumes { MGT { id = "Znwuly-qcgx-AHbd-1qg9-Jjp8-eogk-N5ASme" status = ["READ", "WRITE", "VISIBLE"] flags = [] segment_count = 1 segment1 { start_extent = 0 extent_count = 1 # 4 Megabytes type = "striped" stripe_count = 1 # linear stripes = [ "pv0", 0 ] } } VHD-6bdf21c1-cc52-45d1-ab9e-56bd7aa9bc89 { id = "yLMfFb-9yOk-vf1N-FTmz-5NiL-F5lx-NNmkuN" status = ["READ", "WRITE", "VISIBLE"] flags = [] segment_count = 1 segment1 { start_extent = 0 extent_count = 12827 # 50.1055 Gigabytes type = "striped" stripe_count = 1 # linear stripes = [ "pv0", 1 ] } } } }
この構成から、不足しているイメージに対応するエントリ（/ etc / lvm / backup / <Corresponding VG>の現在の構成にないエントリ、私の場合はVHD-6bdf21c1-cc52-45d1-ab9e-56bd7aa9bc89）のみが必要です。 現在の構成でそれを書き換え、バックアップからVGを復元するLVMコマンドを指定します。
vgcfgrestore -f /etc/lvm/backup/VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191 -v VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191
論理ボリュームが選択されたことを確認します。
# lvdisplay --- Logical volume --- LV Name /dev/VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191/MGT VG Name VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191 LV UUID Znwuly-qcgx-AHbd-1qg9-Jjp8-eogk-N5ASme LV Write Access read/write LV Status available # open 0 LV Size 4.00 MB Current LE 1 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0 --- Logical volume --- LV Name /dev/VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191/VHD-6bdf21c1-cc52-45d1-ab9e-56bd7aa9bc89 VG Name VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191 LV UUID yLMfFb-9yOk-vf1N-FTmz-5NiL-F5lx-NNmkuN LV Write Access read/write LV Status available # open 0 LV Size 50.11 GB Current LE 1 Segments 1 Allocation inherit Read ahead sectors auto - currently set to 256 Block device 253:0
（XenCenterまたはxe sr-scanを介して）リポジトリを検索すると、XenServerはこのレコードを正常に上書きし、最初からやり直す必要があります。 私の理解では、XenServerは、復元された論理ボリュームのUUIDと一致するUUIDを持つVDI（ディスクイメージ）を認識しません。
XenServerは、lvmを使用する場合、ディスクイメージをLogcalボリュームに直接保存します。 より正確には、論理ボリュームはVHDイメージです。 したがって、同じサイズの別の画像の上にコピーすることにより、XenServerに画像を表示させることをお勧めします。
セクションをコピーするには、このVGでセクションをアクティブにします。
# vgchange -ay VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191
これでLVMセクションにアクセスできます。つまり、ddを使用してこのセクションをコピーできます。
# dd if=/dev/VG_XenStorage-a1744b5b-cc65-ac9a-390c-8cfacf2cc191/VHD-6bdf21c1-cc52-45d1-ab9e-56bd7aa9bc89 of=image.vhd bs=100M
コピーされたイメージが仮想マシンに追加された後、およびこのイメージからマシンが開始された後、私の幸福は際限がありませんでした！
しかし、すべてがそれほどバラ色ではありません。 バグのあるコントローラーを引き出すには、サーバーの電源を切る必要がありました。 そして、私がそれをオンにしたとき、画像は再び消えました！ 起動時にXenServerがLVMのイメージのUUIDをデータベースのUUIDと照合し、一致しない場合はイメージが削除されることがわかりました。
LVMを選んでいる間、彼は、あるストレージから別のストレージにイメージを転送すると、そのUUIDも変化し、これに基づいて、ddを介して書き換えられたイメージを別のストレージにコピーするだけでイメージを完全に復活できることを示唆しました。 これにより、データベース内のUUIDと一致させることにより、イメージ内のUUIDが更新されます。 すべての手順を再度繰り返した後、そのために作成された一時ストレージにイメージを転送し、仮想マシンに追加して実行を試みます。 スタートアップはうまくいきます。
サーバーを再起動し、焦りと疲労で握手し、画像のリストを確認すると...画像が配置されました！ 幸いなことに制限はなく、自分自身に満足して、私は日没に引退します...