この状況でどのように安全に外れますか？
詳細は次のとおりです。
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、パーティションが複数のパスで書き込まれると、悪くなります。コードを抜きます。
答え2
特別な理由はありませんが、私の直感によると、これはおそらく最善のアプローチです。
- アプリケーションを閉じます。
- ネットワーク経由で仮想マシンのすべてのデータをバックアップ場所にコピーします。
- VM内でファイルシステムをアンマウントします。
- 仮想マシンを終了します。 （このホストでは仮想マシンが1つだけ実行されます。）
- domUが自動的に起動するように設定されていないことを確認してください。
- ハイパーバイザーが「終了」操作を実行したり、未解決のI / Oなどを同期したりするのを防ぐために、ホストから電源を切ります。
- 仮想マシンを起動し、ハイパーバイザー自体が停電から生き残ることを願っています。
- 失敗した場合は、環境を再構築してください。 （仮想マシンの起動ディスクはファイルベースですが、データマウントポイントはブロックデバイスとして割り当てられた外部ディスクにあります。）
- ハイパーバイザーがdomUに属するファイルシステムをマウントしていることを確認してください。 domUを起動する前に、これらのファイルシステムをアンマウントしてください。）
- KDE自動インストールをオフにします。
- VMを起動し、完全なFSチェックを強制します。
11の代替案：fsck全体を実行せずにVMを起動し、ファイルシステムをマウントします。
その理由は、XenハイパーバイザーがdomUファイルシステムの破損を引き起こすために絶対に必要なものよりも多くの機会を持つことを望まないためです。
答え3
私はXenの専門家ではなく、この分野の経験はありません。しかし、私があなたの立場であれば、次のようにします。まず、データ（おそらくすべて）が失われる可能性があることを知っています。次に、スナップショットを作成してからVMを一時停止して、安全な別の場所に復元しようとしています。環境。
私はあなたに無駄な希望を与えたくありませんが、あなたが何でも回復できるなら幸運だと思います。
警告する：次の提案に従って失敗することがあります。みんなデータ。リスクを負う価値があるかどうかはあなた次第です。
幸いなことに、アプリケーションが使用するデータは揮発性メモリにあるため、アプリケーションを実行し続けることができます。この状況を活用し（各アプリケーションが可能かどうかを評価して）、リアルタイムデータをネットワーク共有にエクスポートする必要があります（アプリケーションがその機能を提供する場合）。ディスクにデータがある場合、エクスポートされたこの関数は、ステートメントのようにfind「ロック」されているか、ディスクの変更/破損したデータが原因でクラッシュ（アプリケーションやOSのクラッシュを引き起こす可能性があります）が発生する可能性があります。
その後、次の記事の説明に従ってライブスナップショットを撮ることができます。Xenでスナップショットを作成する。コマンドのように中断される可能性がありますが、バイト単位のスナップショットを撮りたいです。findしかし、それほど大きな期待は掛かりません。
前のコマンドを実行する前に、Citrixが提供するこのマニュアルをお読みください。Xenのスナップショットの理解（PDF）。
頑張ってください。