それで、実際には、仮想化のオーバーヘッドは何であり、いつ心配すべきですか？
マシンを仮想化しない場合を理解するための良い経験則を探しています。
たとえば、ほぼ100％の使用率で完全にCPUにバインドされたプロセスは、仮想化することはおそらくお勧めできませんが、ほとんどの場合、「実質的な量」（たとえば40または50％）？
別の例：1000台のマシンを仮想化した場合、使用率がわずかまたは中程度であっても、コアを4つしか持たないホスト上ですべてを実行するのはおそらく悪いことです。
ホストのリソースと比較した場合、マシンのワークロードまたはゲストマシンの数に基づいて仮想化に関するヒントを要約できますか？
私は通常、VirtualBoxまたはVMWareを使用してWindowsホストで仮想化しますが、これはかなり一般的な質問だと思います。
ディスクサブシステム。これは通常、最も共有できないリソースです。もちろんメモリですが、それは明らかです。
ディスクサブシステムの制限は、両方の方法で機能します。システムが多くのディスクI/Oを使用する場合、他のゲストの速度が低下します。このゲストが本番環境にある場合、適切にはWebクエリへの高速応答が必要です。これは非常にイライラする可能性があり、仮想ハードウェアをレンタルしない大きな理由にもなります。専用ディスクを使用すると、この問題を最小限に抑えることができます。
ゲストで512 MBのメモリのみを使用すると、すべてのディスクキャッシュがホストに配置されます。そして、それはゲストの間で均等に分割されていません。
CPU IOについては心配しないでください。このように、仮想化は非常に効率的であり、多くの場合、同じシステム上で実行される複数のプロセスのみとして関連しています。 CPUで100％実行しているマルチxeonシステムはめったにありません。
編集：タイプミス
VMに配置しないもの：
仮想化できない特定のハードウェアを使用するもの：通常はグラフィックス、かなりの数のハードウェアセキュリティモジュール、カスタマイズされたドライバー（特殊な目的のネットワークドライバーなど）を持つもの。
ライセンスに問題があるシステム。一部のソフトウェアは、VMに割り当てた数に関係なく、物理CPUまたはコアごとに課金されます。 32コアサーバー上のVMで実行されているシングルコアのソフトウェアのライセンスを取得している場合、監査の対象になります。
VMに入れないようにしたいもの：
すでに市販のハードウェアですべてのリソースを使用しようと努力しているソフトウェア。 hadoopのような「ビッグデータ」の取り組みの一部として機能するマシンは、通常、ベアメタルで実行するように設計されています。
リソースを利用するために微調整されるもの。実際にデータベースのチューニングを開始すると、リソースをめぐって争うVMは、実際に作業に悪影響を及ぼすでしょう。
すでに大きなボトルネックがあるもの。それ自体はすでにうまく機能していないため、他のユーザーとはうまく機能しない可能性があります。
VMを配置するのに非常に優れている点がいくつかあります。
アイドル状態でかなりの時間を費やすもの。メールやDNSのようなユーティリティホストは、専用サーバーを保証するのに十分な負荷を現代のハードウェアに生成するのが困難です。
単独ではうまく（または簡単に）拡張できないアプリケーション。レガシーコードはこのカテゴリにかなり頻繁に分類されます。アプリがサーバーを占有するように拡張しない場合は、小さな仮想サーバーをたくさん使用します。
小さなプロジェクトから始まり、成長するプロジェクト/アプリケーション。 VMにリソースを追加すること（および新しい、より大きなハードウェアに移動すること）は、ベアメタルで開始するよりもはるかに簡単です。
また、単一のホストに膨大な数のVMを配置することについて誇張しているかどうかはわかりませんが、VM：HWの比率を大きくしようとする場合は、ESX、Xen、KVM代わりに、WindowsでVMwareやvirtualboxを使用するよりもはるかにうまくいきます。
仮想化のパフォーマンスには2つのポイントがあります。
- 共有ボトルネック
- エミュレーション
共有のボトルネックで、他に誰が同じアイアンを持っていますか？仮想化環境に同じ場所にいる場合は、ホスティングパートナーに正直に依存しています。
生のパフォーマンス（特に対話性）が尋ねる主な問題は、仮想化システムのどの部分がエミュレートされるかだと思います。これはセットアップによって異なります。ディスクとネットワークが典型的な候補です。経験則として、エミュレーションはアクションを実行するパフォーマンスの「コスト」を2倍にするため、ハードウェアの待ち時間は2倍にカウントされ、スループット数は半分になります。
最終的に、高パフォーマンスの負荷は仮想化しないでください。仮想化のパフォーマンスの過負荷は重要です。ここで私のテストの結果を参照してください：
http://www.altechnative.net/2012/08/04/virtual-performance-part-1-vmware/
OTOH、常にほとんどアイドル状態になっている多数のマシンを統合することを検討している場合、仮想化が先の道です。
AnttiRからの良い答え。
さらに、タイムクリティカルなシステム。私は、Hyper-Vダイム腐敗（vmがゆっくりと遅れ、vmのすべての最新のOSがそれを実行し、頻繁に再同期される）が、開発中のいくつかのタイムクリティカルなアプリケーションでニースに影響を与えていないことを理解しています。さらに、そこでは「たくさんの」CPUを使用し、本番環境でのそのアプリケーション専用の12コアマシンを入手する予定です。