ITインフラストラクチャと開発VMを同じ物理マシンに混在させるのは悪い考えですか？
システム設計者として、コアインフラストラクチャ（dns/dhcp/directory/web/wiki/repos/file shareなど）を担当するVMと、同じ物理マシンでの開発とテストに使用されるVMを配置しますか？
私の見解：
For
- ハードウェアの使用率の向上-ほとんどのIT VMの負荷は比較的低い
- さまざまなプロジェクトからのより良いハードウェア/ w $により多くを費やす能力
- 全体的な支出が少ない
に対して
- ITと開発はおそらくとにかく異なる（別々の）予算を持っています
- 暴走した開発VMはコアITサービスに悪影響を与える可能性があります
一般的に私はこれをしないと言うでしょう。開発は、作業の性質（無限ループ、不適切に最適化されたSQLステートメント、その他すべての楽しいもの）が原因で中断する可能性があり、中断する可能性がある領域と見なしています。
私は実際、開発環境を運用/ネットワーク部門のテスト環境のように扱っています。ただし、開発環境で5 9の稼働時間が必要な場合は、うまくいかない可能性があります。
それらを同じホストに配置する必要がある場合は、割り当てられたリソースを実際に厳しく制限して、上記の問題のいずれかが発生した場合に他のサービスを停止できないようにします。
また、それらを別のホストに配置することのもう1つの追加の利点は、必要なすべてのソフトウェアを使用していくつかのテンプレートを設計し、それらを展開してソフトウェアをインストールする許可を開発者に与えることができることです。このようにして、新しいサーバーを起動したり、ソフトウェアをインストールしたりする必要がある場合でも、誰も気にする必要はありません。
もう1つ注意すべき点は、ディスクへの書き込みまたはディスクからの読み取りの暴走プロセスによって引き起こされるディスクの競合です。
あなたの「反対」のポイントと話すには：
確かに、それらは大企業では別々の予算である可能性がありますが、一部の中小企業はより限られたリソースを持っている可能性があります-特に支出の大幅な削減があります。
VMware [〜＃〜] drs [〜＃〜] または Resource Pools のようなオプションを使用すると、VMが暴走するリスクを簡単に最小限に抑えることができます。
小さなお店では、そうします。
おそらく、開発VMが別個の物理アダプターとVLANを備えた別個のvm-net上にあるように設定し、開発VMを特定のCPUにロックして、コアサービスに影響を与える可能性を減らすようにしますVMひどい。
また、状況が悪化した場合は、いつでもVMを別のサーバーに移動できます。
特にテスト用に別の環境が必要になる可能性があるシナリオを1つ考えることができます。
仮想環境の実行と管理に使用しているハイパーバイザーまたは仮想ツールの新しいバージョンをテストするとします。実稼働環境ではこれを実行したくないでしょう。
常に本番環境と開発/ QA環境を分離する必要があります
以前は問題なくこれを実行しました。
Hyper-Vを使用していて、開発者が独自のVMのセットを管理できるようにしたい場合は、 承認マネージャー を確認する必要があります。これにより、特定のVMとそれらのVMの特定の操作のみにアクセスできるようになります。