この状況から安全に抜け出すにはどうすればよいですか？
詳細は以下の通りです：
xenサーバーには、VMに割り当てられたブロックデバイスがあります。ただし、これらのデバイスはXen内にもマウントされています。
実際、これらのブロックデバイスのうち44個がこのように取り付けられています。さらに悪いことに、各物理デバイスは4つのパス上に表示され、それぞれが別々のマウントポイントにマウントされます。つまり、デバイスは実際にはそれぞれ5回マウントされます。
VMゲストOSは、PowerPath疑似デバイス（phy：ブロックデバイスとしてdomUに割り当てられている）を介してパスを認識します
一部のデバイスは、ext2およびreiserfsとしてフォーマットされています。
ここに含まれるファイルシステムの破損のリスクについて説明する必要はありません。
ファイルシステムをアンマウントするだけでも破損する可能性があるのではないかと思います。この時点で、ホストから電源を切るのが最も安全なオプションだと思います 。
すべてのVMのアプリケーション（ほとんどの場合、Oracleデータベース）はまだ実行中であり、使用されていることに注意してください。
dom0で高いCPU使用率を調査したときに、これを発見しました。 / dev/emcpowerrに属する/dev/sdf1からマウントされたcwd->/media / disk-12を使用した、殺せない「検索」プロセスがあります
誰かが尋ねる前に、私がプロセスを殺してCPUとRAMを使い続けることができないのを見たのは（廃止/ゾンビプロセスとは異なり）、未解決のコミットされたI / Oがあるときです。たとえば、同期は返されますが、物理的にはまだディスク上にありません。より一般的には、これはテープI/Oで発生します。
提案！？
P.S.このようなことを防ぐために、一度マウントするとデバイスが「予約」されることを期待していましたか？それともLinuxでは不可能ですか？
編集：まず、ハイパーバイザー内のKDEが原因であると確信しています。 KDEは、デスクトップアイコンを作成するためにログに記録できるデバイスをマウントしているようです。ただし、他のXenサーバーでも同じことは発生していませんが、他のすべてのサーバーははるかに古いバージョンのSLESとKDEを実行しています…V4は問題のあるサーバーのようで、3.4の方が動作が優れています。
さらに、2つの重要ではないVMがハングしました。それらをシャットダウンした後、ファイルシステムの破損のために再度起動することはありませんでした。メイン/本番VMはまだ実行中であり、その上のデータベースはまだ機能していますが、明らかにこれは時限爆弾です。お客様は、別のサーバー上の別のVMで環境を再構築しようとしていますが、一部のコンポーネントの構成で問題が発生しているため、待機しています…
いずれにせよ、これまでのところ「ベストプラクティスは常に優雅にシャットダウンされる」以上の答えはないと感じており、もっと具体的なことをしたいと思っています…いずれにせよ、この状況はもっと慎重に考える必要があると思います。シャットダウンすると、未処理のIO、特にハイパーバイザーからのファイルシステムメタデータの更新が同期され、ファイルシステムが大幅に破損する可能性がありますか？
関連：選択したサブクエリから複数の列を取得しますか？承認された回答：
ディスクが単一のマウントポイントから書き込まれている場合、害はありません。クリーンシャットダウンを実行し（必要に応じて一時停止状態からバックアップします）、マウントを修正します。 Dom0で必要なアプリ以外は実行しないでください。 OTOHの場合、パーティションが複数のパスから書き込まれている場合、それは悪いことであり、秒単位で悪化します。プラグを引きます。