編集：2013年10月1日に更新-私の元の答えのいくつかは、その後廃止されました。
あなたがまだこのサイトで活動しているのか、これが表示されるのかはわかりませんが、私は今日この質問を読んで、それが私を魅了したことを知ってほしかったので、一日中過ごしましたHyper-VとWindowsの内部構造を調査し、仮想化自体の概念を掘り下げて、あなたの質問に答える準備ができていることを望んでいます。
仮想化プラットフォームとしてのHyper-Vの観点から来ていると言って、序文を述べましょう。なぜなら、それが私が最も経験を積んでいるところだからです。私たちが知っているように、それから逸脱することのできない特定の仮想化の原則があるかもしれませんが、Microsoft、VMware、およびXenはすべて、ハイパーバイザーの設計方法について異なる戦略を持っています。
それがあなたの質問に挑戦する最初のことです。質問はハイパーバイザーに依存しないように見せますが、実際にはそうではありません。たとえば、Amazon EC2はXenハイパーバイザーを使用し、topそのハイパーバイザーで実行されているLinux VM内から発行されたコマンドの出力に表示される「CPU Steal Time」メトリックは、そのゲストOSにインストールされた統合サービスの結果です（またはゲストの仮想化対応ツール）とその特定のハイパーバイザーによって提供されるデータを組み合わせて使用します。
まず第一に、私はちょうどまっすぐあなたの質問に答えてみましょう：プロセッサがハイパーバイザーを実行すると、他のことをやって過ごしている物理マシンに属するどのくらいの時間のWindowsを実行している仮想マシンの内側から見る方法はありませんしない限り、特定の仮想ツール/あなたの特定のハイパーバイザーのためのサービスや仮想化対応のツールは、ゲストVMにインストールされているとゲストが実行されている特定のハイパーバイザーは、そのデータをゲストに公開します。Hyper-Vハイパーバイザーで実行されているWindowsゲストでさえ、ハイパーバイザーの物理プロセッサーが他のことを行っていた時間に関する情報にすぐにアクセスすることはできません。（voretaq7を引用すると、「第4の壁を破る」ものです。）Windowsクライアントおよびサーバーオペレーティングシステムは、適切な統合サービス/ツールがインストールされたHyper-Vで仮想ゲストとして実行されますが、「enlightenments」（文字通りカーネルです）コードの変更が大幅に物理ホストのリソースを使用して彼らのパフォーマンスを向上させること）のVMのために特別に作られた、一番下の行は、ハイパーバイザがないということである持っていますゲストOSに必要以上の情報を提供します。つまり、ハイパーバイザーは、ゲストVMにサービスを提供する以外に何をしているのかをゲストVMに伝える必要がないことを意味します... そして、物理プロセッサが他に何をしているかに関するその情報は、「CPU Steal Time：vCPUが物理CPUを待機する時間の割合」など、VMの観点からメトリックを導き出すために必要です。
ゲストOSは、実際に仮想化されていることに気付かなかった場合、どのようにしてそれを知ることができますか？
つまり、ゲストに適切な統合ツールがインストールされていないと、ゲストOSはそのCPUが実際にはv CPUであることすら知りません。CPUサイクルを「盗み」、それ自体の外側に別の力があることすら知らないため、そのメトリックはゲストVMに存在しません。
VMwareはこのデータをWindowsゲストおよびESXi 5.0に公開し始めました。VMware統合ツールもゲストで更新する必要があります。ここに参考文献があります。彼らはそれを「CPU盗難時間」と呼んでいます。
Hyper-Vなどのハイパーバイザーでは、ゲストが物理プロセッサーやプロセッサーコアなどの物理リソースに直接アクセスすることはできません。代わりに、ハイパーバイザーはvCPUなどの仮想デバイスであるvDevを提供します。
理由の主な例：仮想マシンのゲストOSが、物理CPUの物理コンポーネントであるTLB（変換ルックアサイドバッファー）をフラッシュする呼び出しを行ったとします。ゲストOSが物理プロセッサのTLB 全体をクリアできる場合、同じ物理TLBを共有している他のすべてのVMのパフォーマンスに悪影響を及ぼします。Windowsの場合、ゲストOSでのその呼び出しは、ハイパーバイザーによって解釈される「ハイパーコール」または「エンライテンド」呼び出しに変換され、その仮想マシンに関連するTLBのセクションのみがフラッシュされます。
（興味深いことに、適切な統合ツールやサービスを持たないゲストVMは、同じホスト上の他のすべてのVMのパフォーマンスに影響を与える可能性があることを示唆していますが、それはこのトピックの範囲外です。 ）
すべてのことは、あなたがと言うことができ、まだHyper-Vホストに仮想プロセッサは実際のプロセッサは、それが実行するようにスケジュールができることを利用できるようになるのを待った時間を検出します。ただし、そのデータはWindows Hyper-Vハイパーバイザーでのみ表示できます。他のハイパーバイザーでこれを確認できる場合は、そのハイパーバイザーでこれを確認する方法と、ゲストに公開されているかどうかを他のユーザーに教えてください。 （2013年10月1日編集、それを行ってくれてありがとうevilensky！）
私のテストマシンはHyper-V Server 2012でした。これは、CoreとHyper-Vの役割のみを実行するServer 2012の無料版です。Hyper-Vを実行しているWindows Server 2012と実質的に同じです。
親パーティション（別名物理ホスト）でPerfmonを起動します。このカウンターをロードします。
Hyper-V Hypervisor Virtual Processor\CPU Wait Time Per Dispatch\*
ハイパーバイザー上の各仮想マシンおよび_Totalには、カウンターのインスタンスがあることに気づくでしょう。そのPerfmonカウンターのMicrosoft定義は次のとおりです。
仮想プロセッサが論理プロセッサにディスパッチされるのを待機するのに費やした平均時間（ナノ秒）。
明らかに、あなたはその数をできるだけ低くしたいです。コンピューターにとって、待つことはほとんど良いことではありません。
あなたが調査したいと思うことを、ハイパーバイザ上のその他のパフォーマンスカウンタがありHyper-V Hypervisor Root Virtual Processor\% Guest Run Time、% Hypervisor Run Timeと% Total Run Time。これらのカウンタは、「実際の」プロセッサがVMまたはすべてのVMのサービス以外の処理に費やす時間などの事実を判断するために使用できるパーセンテージを提供します。
したがって、結論として、ゲスト仮想マシンで探しているメトリックは、実行中のハイパーバイザー、そのハイパーバイザーがそのVMのサービス以外の時間の使い方に関するデータを提供することを選択するかどうか、およびゲストがOSには、ハイパーバイザーがそのデータを利用可能にしていることを十分に認識できる適切な仮想化統合ツール/サービス/ドライバーがあります。
Windowsゲストでは、統合ツールがインストールされているかどうかにかかわらず、VMのホストが物理プロセッサの合計時間に応じてVMのサービスに費やした時間を秒またはパーセンテージで確認する方法はありません。 （2013年10月1日編集：ESXi 5.0以上では、統合ツールを介してこのデータがゲストVMに公開されます。Hyper-Vにはまだ何もありません。）