私はいくつかのLVM論理ボリュームを持つサーバー(Ubuntu 18.04)を持っています。定期的な再起動後、そのうちの1つが戻らない。いくつかの調査の後、これは私がいるところです:
物理ディスクはiSCSIデバイスであり、カーネルから/ dev/sdcとして認識されます(エラーはなく、正しいサイズ)
lvmdiskscan -vは/ dev/sdc上のPVを表示します
> lvmdiskscan -v ... /dev/sdc [72.76 TiB] LVM物理ボリューム
... /dev/sdc:UUID = "fvUXXf-pVOF-EPnn-c8eg-tZ5S-iMVW-wsSFDy" TYPE = "LVM2_member"
このエントリには、システム上の他のLVが持っているPARTUUIDエントリがありません。これは手掛かりですか?私はこの情報を私をさらに助ける何かと全く結びつけることができませんでした。
pvscanが/ dev/sdcを報告しない
pvdisplayがこのPVを認識していないようです
> pvdisplay /dev/sdc 物理ボリューム「/ dev/sdc」が見つかりませんでした
私を正しい方向に向けることができる人はいますか?
Pvck -tの出力を追加するように編集
pvck -t /dev/sdc テストモード:メタデータは更新されず、ボリュームは(非)アクティブ化されません。 /dev/sdc、セクター1にラベルが見つかりました、type = LVM2 001 テキストメタデータ領域が見つかりました:オフセット= 4096、サイズ= 1044480
また、このLVはもともとUbuntu 14.04で作成されており、Ubuntu 18.04では完全に問題なく動作していることを知るのにも役立ちます。
以下のlvmdiskscanからの追加の出力。この出力は、システム上の他のVGで得られるものと変わりません。 LVは最初は孤立しているように見え、次にVGに関連付けられ、使用可能になります。しかし、r3vgの場合、これは起こりません。
lvm [7852]:デバイス/ dev/sdcからラベルを読み取ります lvm [7852]:オープンされた/ dev/sdc RO O_DIRECT lvm [7852]:/ dev/sdc:ブロックサイズは4096バイトです lvm [7852]:/ dev/sdc:物理ブロックサイズは512バイトです lvm [7852]:/ dev/sdc: lvm2ラベルがセクター1で検出されました lvm [7852]:lvmcache/dev/sdc:VGの#orphans_lvm2(#orphans_lvm2)に0 mda(s)が追加されました。 lvm [7852]:/ dev/sdc:PVヘッダー拡張バージョン2が見つかりました lvm [7852]:/ dev/sdc:r3vg(Rpn2x9KOivnVd3m6gM9Rf2p3SYkRFm00) lvm [ 7852]:lvmcacheにVGID "r3vg"の情報がなく、VGID Rpn2x9KOivnVd3m6gM9Rf2p3SYkRFm00。 lvm [7852]:lvmcacheにvgname "r3vg"。 lvm [7852]:lvmcache/devの情報がないsdc:1 mdaのVG r3vgになりました。 lvm [7852]:lvmcache/dev/sdc:VG r3vg:VGIDをRpn2x9KOivnVd3m6gM9Rf2p3SYkRFm00。 lvm [7852]:lvmcache/devに設定します/ sdc:VG r3vg:作成ホストをleitrimに設定します。 lvm [7852]: lvmcache/dev/sdc:VG r3vg:サイズ1015のメタデータチェックサム0x54affad5を保存しました。 lvm [7852]:クローズ/dev/sdc lvm [7852]:/ dev/sdc:キャッシュサイズを使用156250918912セクター lvm [7852]:/ dev/sdc [72.76 TiB] LVM物理ボリューム lvm [7852]:7ディスク lvm [7852]:3パーティション lvm [7852]:1つのLVM物理ボリューム全体ディスク lvm [7852]:2つのLVM物理ボリューム lvm [7852]:グローバル/ notify_dbusを1 に設定lvm [ 7852]:完了:lvmdiskscan -dddddd
TelcoMによるコメントを読み、さらにログとマニュアルページを掘り下げた後、自分の質問に答えることができます。
何らかの理由で、PV/dev/sdcが属するVGに関する情報が再起動中に失われ、戻ってこなかった。
私は解決策を完全には理解していません(おそらく、詳細を追加できる人がいます)が、次のように機能しました。最初
> vgscan --cache メタデータタイプlvm2を使用してボリュームグループ「r3vg」が見つかりました
私のVG構成を見つけます。今PVは再び知られています
> pvs /dev/sdc r3vg lvm2 a-- 72.76t 26.39t
LVもまた既知ですが、非アクティブです
> lvscan 非アクティブ '/ dev/r3vg/p0' [46.37 TiB]継承
そして最後に
> lvchange -ay r3vg/p0
それを戻す。
再起動時にVG構成が選択されないのはなぜかわかりません。誰かが何か提案があれば、コメントにそれらを追加してください。
Sudo vgscan
およびSudo vgchange -ay
を実行すると、LVはマウント可能になりますか?これらのコマンドでエラーが発生する場合は、おそらく別の問題があり、おそらくそれらのエラーメッセージを元の投稿に追加する必要があります。
しかし、これらのコマンドの後でLVがマウントできるようになった場合は、次を読んでください...
/dev/mapper/vgNAME-lvNAME
のLVM論理ボリュームパス名(例:/etc/fstab
)だけでは、ネットワークとiSCSIがアクティブ化されるまで、この特定のファイルシステムをマウントできないという手がかりはシステムに与えられません。
その手がかりがなければ、システムはファイルシステムがローカルディスク上にあると想定し、ネットワークがアクティブ化される前のできるだけ早い段階でマウントしようとしますが、iSCSI LUNで明らかに失敗します。だから、どうにかしてその手がかりを提供する必要があります。
1つの方法は、_netdev
をそのファイルシステムのマウントオプションに/etc/fstab
で追加することです。 このUbuntuヘルプページ から、Ubuntuでサポートされているようです。これにより、実際にvgscan
または同様の新しいLVM PV(およびその他の役立つもの)の検出が、_netdev
でマークされたファイルシステムのマウントを試みる直前にトリガーされる場合もあります。
別の方法は、systemd固有のマウントオプションx-systemd.requires=<iSCSI initiator unit name>
を使用することです。 iSCSIイニシエーターが正常にアクティブ化されるまで、そのファイルシステムのマウントの試行を延期することにより、同じことを実現できます。
ISCSIイニシエーターがアクティブになると、構成されたすべてのLUNが自動的に使用可能になり、それらが使用可能になると、LVMはそれらのすべてのVGを自動アクティブ化する必要があります。したがって、マウントの試行が延期されると、それで十分です。
PARTUUIDの欠如は、ディスク/ LUNにGPTパーティションテーブルがないことの手がかりです。 /dev/sdc
はTYPE="LVM2_member"
としてリストされているため、実際にはパーティションテーブルはまったくありません。理論的には、これはLinuxに問題を引き起こさないはずですが、私はiSCSIストレージを備えたUbuntu 18.04システムを個人的にテストしたことがないため、確実に特定することはできません。
パーティションテーブルのないディスク/ LUNの問題は、他のオペレーティングシステムがLinux LVMヘッダーをディスクが使用中であることを認識せず、最小限のプロンプトで喜んで上書きすることです。 iSCSIストレージ管理者が誤って/dev/sdc
に対応するストレージLUNを別のシステムに提示した場合、これが発生した可能性があります。
不足しているVGに対応する/etc/lvm/backup
ディレクトリでLVM構成バックアップファイルを見つけ、それを読んで、不足しているPVの予想されるUUIDを見つける必要があります。 blkid
が報告する内容と一致する場合は、ストレージ管理者に依頼して、上記のような間違いがないか、最近の作業を再確認してください。 PVが他のシステムによって上書きされていることが判明した場合、LUN上の残りのデータは多かれ少なかれ破損している可能性が高く、新しいものを取得したら、バックアップから復元するのが最善です...iSCSI管理者からの保証された競合のないLUN。
/dev/sdc
の実際のUUIDが予想と異なる場合は、誰かが誤ってpvcreate -f /dev/sdc
を実行した可能性があります。それだけの場合は、比較的簡単に修正できます。 (注:man vgcfgrestore
の章を確認物理ボリュームの交換更新された手順-LVMツールは私のものより新しい場合があります。)最初にUUIDを復元します。
pvcreate --restorefile /etc/lvm/backup/<your VG backup file> --uuid <the old UUID of /dev/sdc from the backup file> /dev/sdc
次に、VG構成を復元します。
vgcfgrestore --file /etc/lvm/backup/<your VG backup file> <name of the missing VG>
この後、VGをアクティブ化できるはずです。他に損傷がなければ、その後ファイルシステムをマウントします。