それらは異なるものであることがわかりますが、その理由は本当にわかりません。 「エミュレータはゲーム用、仮想マシンはオペレーティングシステム用」と言う人もいます。ビデオゲームコンソール(AMIGA(?))以外のプラットフォーム用のエミュレータがあるため、この回答には同意しません
助けてくれませんか?
仮想マシンは、存在する範囲にかかわらず、CPUの自己仮想化を利用して、実際のハードウェアへの仮想化インターフェースを提供します。エミュレーターは、CPUがコードを直接実行し、一部の操作を仮想コンテナーを制御するハイパーバイザーにリダイレクトできることに依存せずにハードウェアをエミュレートします。
特定のx86の例が役立ちます。 Bochs は、互換性のある物理プロセッサで実行されている場合でも、ソフトウェアでプロセッサ全体をエミュレートするエミュレータです。 qem もエミュレータですが、カーネル側のkqemu
パッケージを使用すると、エミュレートされたマシンが物理ハードウェアと一致したときに仮想化機能が制限されますが、実際には使用できません完全なx86自己仮想化の利点。したがって、ハイパーバイザーは限られていました。 kvm は仮想マシンのハイパーバイザーです。
ハイパーバイザーは、保護されたアクセスを「エミュレート」すると言えます。ただし、プロセッサをエミュレートするわけではなく、mediates保護されたアクセスと言う方が正しいでしょう。
保護されたアクセスとは、ページテーブルのセットアップやI/Oポートの読み取り/書き込みなどを意味します。前者の場合、ハイパーバイザーはページテーブル操作を検証し(通常はハイパーバイザー自身のメモリに一致するように変更し)、保護された命令自体を実行します。 I/O操作は、エミュレートされたCPUではなく、エミュレートされたデバイスハードウェアにマップされます。
そして、物事を複雑にするために、 Wine は、エミュレータよりも(より高いABIレベルではあるが)ハイパーバイザー/仮想マシンでもあります(つまり、「ワインはエミュレータではありません」)。
仮想マシンの目的は、隔離された環境を作成することです。
エミュレータの目的は、一部のハードウェアの動作を正確に再現することです。
どちらもホストマシンのハードウェアからある程度の独立性を目指していますが、仮想マシンはゲストを動作させるのに十分なハードウェアをシミュレートする傾向があり、エミュレーション/仮想化の効率を重視しています。最終的に、仮想マシンは実際に存在するハードウェアのように動作せず、VM固有のドライバーが必要になる場合がありますが、ゲストドライバーのセットは多数の仮想環境で一貫しています。
一方、エミュレーターは、シミュレートされる実際のハードウェアの癖やバグなど、すべての動作を正確に再現しようとします。必要なゲストドライバーは、シミュレートされる環境と完全に一致します。
仮想マシンの実装には、仮想化、準仮想化、エミュレーションテクノロジー、またはいくつかの組み合わせを使用できます。一般に、エミュレーターは仮想化を使用できません。仮想化を使用すると、抽象化がややリーキーになるためです。
デルは、エミュレータと仮想マシンの違いを正確に説明しました。
エミュレーションまたは仮想化:違いは何ですか?
エミュレーションと仮想化には多くの類似点がありますが、それらには明確な運用上の違いがあります。新しいアーキテクチャ内の古いオペレーティングシステムにアクセスする場合は、エミュレーションが優先ルートになります。逆に、仮想化システムは、基盤となるハードウェアとは無関係に機能します。よく混同されるこれらの用語を分離し、それぞれがビジネスIT運用にとって意味するものを説明します。
違いは何ですか?
要するに、エミュレーションでは、あるシステムを別のシステムに模倣させる必要があります。たとえば、ソフトウェアがシステムBではなくシステムAで実行される場合、システムBはシステムAの動作を「エミュレート」します。ソフトウェアはシステムAのエミュレーションで実行されます。
この同じ例では、仮想化はシステムAを取得して2つのサーバーBとCに分割します。これらの「仮想」サーバーは両方とも独立したソフトウェアコンテナーであり、ソフトウェアベースのリソース(CPU、RAM、ストレージ、ネットワーク)に独自にアクセスできます–個別に再起動できます。これらは実際のハードウェアとまったく同じように動作し、アプリケーションまたは別のコンピューターは違いを認識できません。
これらのテクノロジーにはそれぞれ独自の用途、利点、欠点があります。
エミュレーション
エミュレーションの例では、ソフトウェアがハードウェアを埋めて、ハードウェアのように動作する環境を作成します。これは、サイクルをエミュレーションプロセスに割り当てることにより、プロセッサに負担をかけます。代わりに、計算の実行に使用されるサイクルです。したがって、CPUマッスルの大部分がこの環境の作成に費やされます。
興味深いことに、エミュレートされた環境で仮想サーバーを実行できます。それでは、エミュレーションがリソースの浪費であるなら、なぜそれを考慮するのでしょうか?
エミュレーションは、次のシナリオで効果的に利用できます。
•他のハードウェア向けのオペレーティングシステムの実行(PC上のMacソフトウェア、コンピューター上のコンソールベースのゲームなど)
•別のオペレーティングシステム用のソフトウェアを実行する(PCでMac固有のソフトウェアを実行する、またはその逆)
•同等のハードウェアが廃止された後のレガシーソフトウェアの実行
エミュレーションは、複数のシステム用のソフトウェアを設計するときにも役立ちます。コーディングは単一のマシンで実行でき、アプリケーションは複数のオペレーティングシステムのエミュレーションで実行でき、すべてが独自のウィンドウで同時に実行されます。
仮想化
この仮想化の例では、物理的な場所やレイアウトに関係なく、効率的かつ機能的な方法でコンピューティングリソースを利用していると安全に言えます。十分なRAMと十分なストレージを備えた高速マシンは、それぞれがリソースのプールを備えた複数のサーバーに分割できます。通常、単一サーバーとしてデプロイされたその単一マシンは、電子メールサーバー:以前は十分に活用されていなかったコンピューティングリソースを最大限に活用できるようになり、コストを大幅に削減できます。
エミュレートされた環境ではハードウェアと対話するためにソフトウェアブリッジが必要ですが、仮想化ではハードウェアに直接アクセスします。ただし、全体的に高速なオプションであるにもかかわらず、仮想化は、基盤となるハードウェアで既に実行可能なソフトウェアの実行に限定されています。仮想化の最も明確な利点は次のとおりです。
•既存のx86 CPUアーキテクチャとの幅広い互換性
•すべてのハードウェアおよびソフトウェアから物理デバイスとして表示される機能
•各インスタンスに含まれる
エミュレーションと仮想化の間で、ビジネスはほとんどの仮想システム機能を実行できます。どちらのサービスも同じように聞こえますが、すべてはソフトウェアの使用方法を中心に展開します。ソフトウェアを邪魔にならないようにするには、仮想化によりゲストコードをCPUで直接実行できます。逆に、エミュレータはゲストコード自体を実行し、他のタスクのためにCPUを節約します。