Hyper-Vの合成ドライバーを使用する利点は何ですか？
仮想化プラットフォームをCitrixのXenServerからWindowsServer 2008R2のHyper-Vに移行します。このプロジェクトの一環として、いくつかのDebianLinuxサーバーを何らかの形でHyper-Vに移行する必要があります。新しいHyper-Vプラットフォーム上にDebianベースのサーバーを正常に構築し、テストを開始しています。
Debian 6（Squeeze）は、Hyper-V合成ドライバーを含む2.6.32カーネルを使用しますが、Microsoftによってサポートされているオペレーティングゲストオペレーティングシステムとは見なされていません。他の人が問題を抱えているので、やむを得ない理由がない限り、私はそれらを使用することを少し躊躇しています（ ここ 、および ここ ）。
- Hyper-V合成ドライバーは、エミュレートされたドライバーに比べてどのような利点がありますか？
- Xenハイパーバイザーの経験がある方は、ゲストオペレーティングシステムの準仮想化に類似した合成ドライバーを使用していますか？
- それでは、合成ドライバーを使用しないことの注目すべき危険または欠点はありますか？
なぜ、a）現在カーネルにあるHyper-Vドライバーの報告された不安定性に対処するか、b）新しいカーネルを構築しようとするか、c） 仮想マシンの追加 を作成する必要があるのですか？すべてが「正常に機能している」ように見えるときに、設計されていないディストリビューションで動作しますか？
編集：答えに少し追加するには...クロックドリフトは重要な問題のようです（NTP Linux Integration Servicesを使用していない限り、時計を時間どおりに保つことはできません。 KB918461 を参照してください。LinuxIntegrationServicesに含まれているvmbusコンポーネントを使用すると、これが解決されるようです。問題。
合成ドライバーは、ハイパーバイザーのほとんどをバイパスして（一般的なデータ操作の場合）、実際のハードウェアとより直接的に「通信」します。これにより、ほとんどのネットワークアクティビティに関連するハイパーバイザーのオーバーヘッドが大幅に削減されます。
サーバーがネットワーク上であまり通信しない場合、またはハードウェアが十分にコミットされていない場合は、エミュレートされたドライバーで問題ないはずです。ただし、これを行うとパフォーマンスが低下することは間違いありません。
ハイパーバイザーがハードウェアをエミュレートしている場合、NICのバッファーにパケットを入れたり、ディスクドライブのブロックにデータを入れたりするときに、クライアントのドライバーが期待するレジスターやタイミングの問題などがたくさんあります。 。
合成ドライバーを使用するときは、「このレジスターをいじる（とにかくハイパーバイザーによってエミュレートされる）」をすべてスキップし、「データはここにあります-それを使って正しいことを行う」段階に直接スキップします。
したがって、プロセス全体がはるかに効率的です。
私はあなたに完全な答えを持っていませんが、議論を締めくくるのに役立つかもしれないいくつかの経験があります。最初はRedHatマシンでエミュレートされたドライバーを使用しましたが、Linux管理者はネットワークパフォーマンスがひどいことを訴えました。最終的に、仮想マシンの追加を介して合成ドライバーが機能するようになり、それが大きな違いを生みました（証拠や詳細がないので、一粒の塩でそれを取ります）。
これとは別に、ネットワーク経由でVMをイメージ化することがあります。その場合、合成NICはサポートされていないため、WindowsボックスでエミュレートされたNICを使用する必要があります。 PXEブート。イメージングが完了したら、エミュレートされたNICを合成のものに置き換えます。ここでもWindows（Linuxではない）について話しますが、それは別の違いです。
一般に、私の理解では、エミュレートされたデバイスは、ほとんどすべてのOSまたはディストリビューションでサポートが組み込まれている、より古い、より確立された、またはより一般的なデバイスをエミュレートします。この点で、それらはより普遍的です。合成デバイスは、OSまたはディストリビューションが認識する他のデバイスをエミュレートしないため、VM Additionsをインストールすることで得られるような、Microsoftが提供するドライバーが必要です。