2

qemu-kvm プロセスとして提示される KVM VM。場合によっては、VM のクローンを作成したい場合、fork を使用しないのはなぜですか? 私が見ているように、少なくとも2つの利点があります。

  1. サブ VM はコピー オン ライトでメモリを共有し、メモリ消費を削減します。
  2. コピー オン ライトを使用してオンザフライで VM を複製する

もちろん、解決すべき問題がいくつかあります。

  1. メイン VM イメージ ファイルを共有するディスク コピー オン ライトを設計します。
  2. サブ VM IO をリダイレクトします。
4

1 に答える 1

1

カーネルレベルの仮想化なしで VM を実行している (つまり、QEMU エミュレーションを使用している) 場合、参照している重複した I/O に関するすべての問題を除けば、これはおそらくうまくいくでしょう。VM を「-snapshot」モードで実行することで、ディスクの問題を回避できる可能性があります。同様に、VM がヘッドレス (ビデオ エミュレーションなし) の場合は問題ありません。残っている唯一の問題は、ネットワークの重複です。

これが実際の KVM VM で動作することを期待している場合は、運が悪いと思います。

たとえそれができたとしても、あなたが想像する利点が得られるかどうかはわかりません。2 つの VM (またはその他のアプリケーション) を個別に起動すると、それらの VM は、開いているファイルに対して既に共有メモリを持っています (明らかに、実際には読み取り専用ファイルしか共有できませんでした)。これには、読み取り専用ディスク マウント、KVM/QEMU 実行可能ファイルとライブラリ自体、および必要なものがすべて含まれます。スキームで得られる唯一の追加の共有はデータテーブルであり、フォークの前に使用されているものだけであり、そのデータへの更新はコピーオンライトを引き起こすため、その共有は比較的短命です。(実際には、これはキャッシュされたJIT生成の実行可能コードが大量にある外国のアーキテクチャのQEMUでの勝利かもしれませんが、あなたが言及していたものではないと思います。)

于 2012-09-10T08:56:44.980 に答える