ここのstackoverflow.comと別の参照のマークされた回答によると、私はそれを理解しています：
ハイパーバイザー仮想化 = ハードウェアが仮想化をサポートするように設計されている OS およびハードウェア仮想化の下
ハイパーバイザー以外の仮想化 = OS 上 (アプリケーション ソフトウェアなど)、つまり純粋なソフトウェア仮想化
しかし、ハイパーバイザーにはタイプ 1 とタイプ 2 の分類もあり、タイプ 2 は純粋にソフトウェア仮想化であるように私には思えます...つまり、これは非ハイパーバイザー仮想化がタイプ 2 ハイパーバイザーと同等であることを意味するのでしょうか、それとも微妙な違いがあるのでしょうか??
それとも、これらの用語はすべて大まかに定義されているのでしょうか??
前もって感謝します。
Type2 は純粋にソフトウェアの仮想化であるように私には思えます
「タイプ 1 とタイプ 2」および「ハードウェアとソフトウェア」の仮想化を混同しないでください。実際には、ハードウェアとソフトウェアの間には中間の領域があります。完全なハードウェア (HVM)、「部分的な」ハードウェア (PVM)、および純粋なソフトウェア (SW) があります。
6つの組み合わせすべてを展開して明確にします。
タイプ 1 + フル ハードウェア (HVM) - これにより、Xen HVM などのハイパーバイザーが変更されていないゲスト OS を起動できます。これは、ゲスト OS がハードウェアに送信しようとしている「電信メッセージ」をハイパーバイザーがデコードする必要があるため、実際には低速です。(つまり、ディスクドライブへの書き込みには、場所 0xblahblah にバイトを繰り返し格納することが含まれます。)
タイプ 1 + 準仮想化 (PVM) - これは、ゲスト OS を少し変更して、ディスク I/O などの一部のタスクでハイパーバイザーを直接呼び出す場合です。これは、ゲストが「ここに、このページのバイトを書き込んでください」と言うだけで、各バイトで (仮想化された) I/O を実行する必要がないため、より高速です。特別なドライバーをインストールすると、PVM を実行していることがわかります。もちろん、OS に既に仮想ドライバーが組み込まれている場合もあります。たとえば、最新の Linux カーネルは、Xen、KVM、UML などで実行されていることを検出すると、起動時に自動的に PVM モードに切り替わります。
タイプ 1 + 純粋なソフトウェア (SW) - これが存在するかどうかはわかりませんが、構築するのはそれほど難しくありません。ソフトウェア エミュレーションは遅いため、実際の OS を起動して Type 2 を実行するオーバーヘッドは大した問題ではありません。
タイプ 2 + フル ハードウェア (HVM) - VirtualBox または KVM で変更されていない Windows を起動できます。すべてのゲストを再起動してもバックグラウンドで MP3 を再生できる場合はタイプ 2 です :)
タイプ 2 + 準仮想化 (PVM) - これは、ゲスト ドライバーをインストールするか、VirtualBox/KVM で最新の Linux カーネルを起動するたびに発生します。
Type 2 + Pure Software (SW) - Bochs と Qemu の初期バージョン。（最近のバージョンには、実際にはハードウェア支援モードもあります。）通常はそれなしでは実行できないソフトウェアを実行できるため、それらが「純粋なソフトウェア」であることがわかります。(つまり、ARM プロセッサの Bochs で Windows '95 を実行し、Qemu で x86 で ARM ディストリビューションを起動しました。)
上記とは異なる別の主題もあります。
コンテナ技術。Docker/Rkt/LXD などのコンテナーは、上の表には収まりません。コンテナー内のアプリケーションは、通常の方法でカーネルを呼び出す通常のプログラムであり、ハイパーバイザーは関与しません。
コンテナーが cgroup と名前空間のカーネル機能を使用して、アプリが VM 内にあるかのように "感じさせる" だけです。各コンテナーは、システムの「分割された」ビューを取得します。それは独自のファイルシステム、独自のユーザー ID、独自のプロセス ID、独自のホスト名 + IP アドレスなどです。しかし、外部からは、すべてのコンテナー内のすべてのプロセスを「 ps'。
私の考えでは、ハイパーバイザー以外の仮想化とは、その上で OS 以外のものを実行する仮想化レイヤーを意味します。最も一般的には、他のオペレーティング システムのユーザー レベルの環境を仮想化することです。たとえば、WINE プロジェクトは非ハイパーバイザー仮想化であり、Linux (または他の) ホストで win32 プログラムを実行できます。実際の Windows OS を実行したり、仮想化された OS の「ベア」ハードウェアをエミュレートしたりする試みはありません。代わりに、仮想層は、ユーザー レベルの抽象化とウィンドウのシステム コールを直接提供します。
これを、タイプ 1 (ベア メタル上で実行) またはタイプ 2 (OS 上で実行) のいずれかであり、ハードウェア レベルの抽象化を提供し、その上で OS 全体を実行するハイパーバイザーと比較してください。
ハイパーバイザーは、定義上、ハードウェアをエミュレートします。（物理的に存在する場合と存在しない場合があります）-一部を仮想化する場合もあります。
仮想化は通話を傍受し、別の場所にリダイレクトします。
これらは 2 つの異なるトピックですが、相互に関連しています。
タイプ 1 ハイパーバイザーは「ベア メタル」で実行され、ハードウェアと仮想オペレーティング システムの間に位置します (ハイパーバイザー自体がオペレーティング システムです)。たとえば、VMWare ESX、Citrix XenServer、またはMicrosoft Hyper-V
タイプ 2 ハイパーバイザーは、既存のオペレーティング システム上で実行され、ハードウェアまたはソフトウェアの仮想化をサポートする場合があります。たとえば、QEmuとBochsの両方) は、CPU 全体をエミュレートし、オプションで異なる CPU アーキテクチャをエミュレートします。どちらもタイプ 2 ハイパーバイザーですが、エミュレーションが必要なため、パフォーマンスに大きなオーバーヘッドがあります。
VMware Workstation / Server / Player / Fusion、Parallels、Virtualboxはすべて、ハードウェア支援による仮想化をサポートするタイプ 2 ハイパーバイザーの例です。これは、CPU 命令をエミュレートするのではなく、CPU 命令がエミュレーションや変換なしで直接通過できることを意味します。プロセッサがサポートしている場合、パフォーマンスを損なうことなく実行できます。
次は、 （事実上）アプリケーション仮想化である非ハイパーバイザー仮想化です。ハードウェア自体はまったくエミュレートされていません。仮想化レイヤーは特定のシステム コールをインターセプトし、それらを仮想化しているだけです。このカテゴリの例には、 VMWare Thinapp、Microsoft App-Vなどがあります。Windows Vista 自体は、特定のレジストリとディスクの書き込みを、ユーザーが書き込み権限を持たない領域に仮想化します。Vista でのこの仮想化は、多くのレガシー アプリケーションとの下位互換性にとって重要です。
最後に、純粋なエミュレーターがあります。ここでは仮想化は行われていません。このカテゴリにはWINEと、ある程度のCygwinがあります。また、 Bochsは、仮想化がなく、ハードウェア エミュレーションのみであるため、このカテゴリとタイプ 2 ハイパーバイザーに適合します。DOSEMUは、ここに収まる別の 1 つです。
私は多くの例を見逃したと確信していますが、
(「コメントするには評判が 50 でなければならない」という要件を満たすためのポイントがほとんどないため、ここで #answer-16868851にコメントを投稿します)
BraveNewCurrencyは次のように書いています。
タイプ 1 + 純粋なソフトウェア (SW) - これが存在するかどうかはわかりませんが、構築するのはそれほど難しくありません。ソフトウェア エミュレーションは遅いため、実際の OS を起動して Type 2 を実行するオーバーヘッドは大した問題ではありません。
これまでのところ、これを実行できるType 1ハイパーバイザーは 1 つしか見つかりませんでした。それはVMware ESXiです。
vSphere 5 ドキュメント センター | ESXi ハードウェア要件には次のように記載されています。
■ 64 ビット仮想マシンをサポートするには、x64 CPU でハードウェア仮想化 (Intel VT-x または AMD RVI) のサポートを有効にする必要があります。
したがって、32 ビットのゲストは VT-x がなくても動作します。
私はそれが来た（プロプライエタリまたはオープンソースのいずれかで）ゼロの競争を見ているので、VT-xサポートなしで（つまりPure Software で）機密性の高いCPU命令をトラップすることは実際には深刻な課題だと思います。
以下は元の質問とはまだ関係ありませんが、v5.0 (および v4.x) では CPU からの 64 ビット サポートが必要です。
■ ESXi 5.0 は、64 ビット x86 CPU を搭載したサーバーにのみインストールして実行できます。
■ ESXi 5.0 には、少なくとも 2 つのコアを備えたホスト マシンが必要です。
Type 1 + SWハイパーバイザーを 32 ビット マシン (私のように)で実行することに興味がある人は、以前のバージョンを使用することができます。 ESXi/ESX をインストールするための最小システム要件 (1003661)は次のように述べています。
ESX 3.5.x
ESX 3.5.x のハードウェア要件は、ESX 3.0.x セクションに記載されているものと同じですが、以下が追加されています。
[...]
ESX 3.0.x
ESX 3 をインストールして使用するには、次のハードウェアおよびシステム リソースが必要です。
At least two processors: 1500 MHz Intel Xeon and above, or AMD Opteron (32bit mode) for ESX 1500 MHz Intel Xeon and above, or AMD Opteron (32bit mode) for Virtual SMP 1500 MHz Intel Viiv or AMD A64 x2 dual-core processors
+ ESX 3.5 インストール ガイドは、次のセクション/サブセクションでこれを繰り返します。
ESX Server 3 の要件
このセクションでは、ESX Server 3 バージョン 3.5 でサポートされる最小および最大のハードウェア構成について説明します。
サーバー ハードウェアの最小要件
...
したがって、純粋な（および32ビットのみの）ソフトウェア:)