他の場所で提案されているように、VMWare ESXiは無料のベアメタルハイパーバイザーの観点から利用できるものです。「ベアメタル」とは、最終的にロードしたものがフルOS未満であることを意味します。
Xenには、ハードウェアレベルの仮想化が使用されるHVMモードもあります。このモードでは、Windowsゲストを実行できます。Xenには明らかに「ベアメタル」ハイパーバイザーがあります（Dom0 OSでも実行されます）が、構成と保守がかなり複雑であり、非HVMドメイン（Dom0 、他へのハードウェアアクセスを通過し、管理者権限を持つプライマリカーネルは1）です。HVMには、ハードウェア仮想化サポートを備えたCPUとマザーボードが必要です。Xen wikiのHVM互換マザーボードのリストを参照してください。
とはいえ、KVMの方がおもしろいかもしれません。Linuxを使用して（ESXと同様に）独自のハイパーバイザーカーネルを管理するのではなく、KVMはハイパーバイザー機能をLinux自体に構築します。どのように「ベアメタル」であるかはあなたの解釈に依存しますが、KVMを実行しているホストが40MBのinitrdであり、kvm + libvirt +関連のツールがインプレース（Red HatのoVirtのようなもの）だけである場合、実際には、ESXとまったく異なるものではありません。KVMのユーザー空間コンポーネントはQEMUから派生しています、これはあらゆる種類の強力かつ柔軟なものになります-デスクトップには必ずしも必要ではありませんが、組み込みシステムのシミュレーションでは非常に興味深いです（たとえば、シリアルI / OのみでVGAアダプターなし）、セットアップストレージをバックエンドするための複雑なCOWイメージのチェーン、または興味深い仮想ネットワークトポロジのセットアップ。Xen HVMと同様に、KVMにはハードウェアアクセラレーションが必要です。KVMは、要求の厳しいWindowsゲスト（Vistaを含む）を適切に実行しますが、現時点では、Windows用の準仮想ネットワークドライバーのみが利用可能です。他のドライバーはエミュレートされたハードウェアを使用する必要がありますが、これは多少遅くなります。（QumranetはWindows用の他のドライバーの開発に資金を提供しているので、最終的にそれらを見ると期待しています。Linuxカーネルの新しいバージョンには、多くのKVM互換の準仮想ドライバー（ディスクI / O、クロック、その他のデバイス用）が含まれています）。
デスクトップの使用にはVirtualBoxが適していますが、「ベアメタル」の使用はまったく受け入れられません。欠如のためにlibvirtのサポート、私はまた、QAオートメーション用途には不適切考えます。VirtualBoxには、「ゲストユーティリティ」の中に準仮想ビデオドライバーがあり、自動ウィンドウサイズ変更と、ゲストのウィンドウがホストの中で表示されるときのバギー「シームレスモード」を提供します。
仮想化専用ではない「プライマリOS」を使用している場合、「ベアメタル」仮想化と、プライマリの（マイクロ）カーネルが使用される最小限の完全な「ベアメタル」ソリューションを実行していません。 Windowsデスクトップを同じハードウェア上に表示する場合、仮想化の目的のために厳密に構築されたコントロールは真剣に最適化されません。必要なものが「ベアメタル」ではなく、ハードウェア支援の仮想化である場合、ここで提案するすべてがそれを提供します。ただし、VirtualBoxの場合はチェックボックスで選択可能な構成オプションです デフォルトでは、より伝統的な方法を使用します。