この状況でどのように安全に外れますか？
詳細は次のとおりです。
XenサーバーがブロックデバイスをVMに割り当てました。ただし、これらのデバイスはXenの内部にもインストールされます。
実際、これらのブロックデバイスが44台搭載されています。仮想的には、各物理デバイスは4つのパスで表示され、各パスは別々のマウントポイントにマウントされます。つまり、各デバイスは実際に5回インストールされます。
VMゲストOSは、PowerPath様デバイス（domUに割り当てられたphy：ブロックデバイス）を介してパスをチェックします。
一部のデバイスはext2とreiserfsでフォーマットされています。
ここに関連するファイルシステムの破損の危険性を私に説明する必要はありません。
ファイルシステムをアンマウントするだけで破損が発生する可能性があります。この時点では、ホストから電源装置を取り外すのが最も安全なオプションです。。
すべての仮想マシン（主にOracleデータベース）のアプリケーションはまだ実行中で使用中です。
dom0で高いCPU使用率を調べている間にこれを発見しました。終了できない「検索」プロセスがあります。 cwd -> /media/disk-12 は /dev/sdf1 からマウントされ、/dev/emcpowerr に属します。
誰かが尋ねる前にプロセスを終了できず、CPUとRAMを使い続けるのを初めて見たのは（デッド/ゾンビプロセスとは異なり）、優れたコミットされたI / Oがあったとき（同期が返されたが物理的にディスクにはありません） ）。まだ。より一般的には、これはテープI / Oで発生します。
提案！ ？
PS：これが起こらないようにインストールした後にデバイスを「予約」したいですか？それともLinuxでは不可能ですか？
編集：まず、ハイパーバイザーのKDEが犯人だと確信しています。 KDEがデスクトップアイコンを作成するために記録できるデバイスをインストールしているようです。しかし、他のXenサーバーでは同じことは起こりませんが、他のすべてのサーバーは以前のバージョンのSLESとKDEを実行しています... V4が問題のあるバージョンのようです。 3.4はより良いパフォーマンスを発揮します。
さらに、重要ではない2つの仮想マシンが中断されました。終了した後は、ファイルシステムの破損により再起動できません。マスター/プロダクションVMはまだ稼働しており、そのVMのデータベースも引き続き機能していますが、これは明らかに時限爆弾です。顧客は他のサーバー上の他のVMから環境を再構築しようとしていますが、一部のコンポーネントを構成するのに問題があるのを待っています。
まぁ、今まで「いつもエレガントに閉じるベストプラクティス」を超えて答えがなかったようで、もっと具体的な内容を望んでいたのですが…まぁ今回の事態はもう少し慎重な考えが必要になるかもしれないと思います。終了すると、未処理のIO（特にハイパーバイザーのファイルシステムメタデータ更新）が同期して、潜在的に深刻なファイルシステムの破損が発生する可能性がありますか？
ベストアンサー1
単一のマウントポイントでディスクに書き込むと、破損は発生しません。完全にシャットダウンし（必要に応じてサスペンド状態でバックアップ）、マウントを修理してください。 Dom0で必要なアプリケーション以外のアプリケーションを実行しないでください。 OTOH、パーティションが複数のパスで書き込まれると、悪くなります。コードを抜きます。