Editar: Actualización el 1 de octubre de 2013: parte de mi respuesta original se ha vuelto obsoleta.
No estoy seguro si todavía está activo en este sitio o si verá esto, pero quería que supiera que leí esta pregunta hoy y me fascinó, así que pasé todo el día (cuando debería haberlo hecho). estado trabajando) investigando lo interno de Hyper-V y Windows e incluso profundizando en los conceptos mismos de la virtualización con la esperanza de que pueda estar listo para responder a su pregunta.
Permítanme comenzar diciendo que vengo del punto de vista de Hyper-V como una plataforma de virtualización porque es donde tengo más experiencia. Aunque puede haber ciertos principios de virtualización, tal como los conocemos, que no se pueden desviar, Microsoft y VMware y Xen tienen diferentes estrategias sobre cómo diseñan sus hipervisores.
Eso es lo primero que hace que su pregunta sea desafiante. Planteas tu pregunta como si fuera un hipervisor agnóstico, cuando en realidad no lo es. Amazon EC2, por ejemplo, utiliza el hipervisor Xen y la métrica "CPU Steal Time" que ve en la salida de un topcomando emitido desde una VM Linux que se ejecuta en ese hipervisor es el resultado de los servicios de integración instalados en ese SO huésped (o herramientas de virtualización en el invitado) junto con los datos proporcionados por ese hipervisor específico.
En primer lugar, déjenme responder su pregunta directamente: no hay forma de ver desde dentro de una máquina virtual que ejecuta Windows cuánto tiempo pasan los procesadores pertenecientes a la máquina física en la que se ejecuta el hipervisor haciendo otras cosas, a menos que las herramientas virtuales particulares / los servicios o las herramientas compatibles con la virtualización para su hipervisor particular se instalan en la máquina virtual invitada yel hipervisor particular en el que se ejecuta el invitado expone esos datos al invitado. Incluso un invitado de Windows que se ejecuta en un hipervisor Hyper-V no tendrá acceso inmediato a la información sobre el tiempo que los procesadores físicos en el hipervisor estaban haciendo otras cosas. (Para citar voretaq7, algo que "rompe la cuarta pared"). Aunque los sistemas operativos cliente y servidor de Windows que se ejecutan como invitados virtualizados en Hyper-V con los servicios / herramientas de integración instalados instalados hacen uso de "iluminaciones" (que son literalmente kernel alteraciones de código hechas especialmente para máquinas virtuales) que aumentan significativamente su rendimiento al usar los recursos de un host físico, la conclusión es que el hipervisor no tienepara dar más información al sistema operativo invitado de la que desea. Eso significa que el hipervisor no tiene que decirle a una VM invitada qué más está haciendo además de dar servicio a esa VM ... a menos que así lo desee. Y esa información sobre qué más están haciendo los procesadores físicos es necesaria para derivar una métrica desde la perspectiva de la VM, como "Tiempo de robo de CPU: el porcentaje de tiempo que la vCPU espera a una CPU física".
¿Cómo podría saber eso el SO huésped, si ni siquiera se dio cuenta de que en realidad estaba virtualizado?
En otras palabras, sin las herramientas de integración correctas instaladas en el invitado, el sistema operativo invitado ni siquiera sabrá que su CPU es realmente una CPU v . Ni siquiera sabrá que hay otra fuerza fuera de sí misma "robando" ciclos de CPU, por lo tanto, esa métrica no existirá en la máquina virtual invitada.
VMware ha comenzado a exponer estos datos a los invitados de Windows, así como a ESXi 5.0. Las herramientas de integración de VMware también deben actualizarse en el invitado. Aquí hay una referencia ; se refieren a él como "Tiempo robado de la CPU".
Un hipervisor como Hyper-V no brinda a los invitados acceso directo a recursos físicos como procesadores físicos o núcleos de procesador. En cambio, el hipervisor les da vDevs (dispositivos virtuales) como vCPU.
Un excelente ejemplo de por qué: Digamos que un sistema operativo invitado de máquina virtual hace la llamada para vaciar el TLB (búfer de traducción) que es un componente físico de una CPU física. Si se permitiera al SO huésped borrar todo el TLB en un procesador físico, eso tendría efectos negativos en el rendimiento de todas las otras máquinas virtuales que también compartían ese mismo TLB físico. En el caso de Windows, esa llamada en el sistema operativo invitado se traduce en una llamada "hipercall" o "iluminada" que es interpretada por el hipervisor para que solo se vacíe la sección del TLB que sea relevante para esa máquina virtual.
(Curiosamente, eso me sugiere que las máquinas virtuales invitadas que no tienen las herramientas o servicios de integración adecuados podrían tener la capacidad de afectar el rendimiento de todas las otras máquinas virtuales en el mismo host, pero eso está completamente fuera del alcance de este tema .)
Todo eso para decir que aún puede detectar en un host Hyper-V el tiempo que un procesador virtual pasó esperando a que un procesador real estuviera disponible para que pudiera programarse para ejecutarse. Pero solo puede ver esos datos en un hipervisor Windows Hyper-V. Si es posible ver esto en otros hipervisores, insto a otros a que nos digan cómo ver esto en ese hipervisor y también si está expuesto a los invitados. (Editar 01/10/2013 ¡Gracias evilensky por hacer eso!)
Mi máquina de prueba fue Hyper-V Server 2012, que es la edición gratuita de Server 2012 que solo ejecuta Core y la función Hyper-V. Es efectivamente lo mismo que cualquier Windows Server 2012 que ejecute Hyper-V.
Inicie Perfmon en su partición primaria, también conocida como host físico. Cargue este contador:
Hyper-V Hypervisor Virtual Processor\CPU Wait Time Per Dispatch\*
Notará que habrá una instancia de ese contador para cada máquina virtual en ese hipervisor, así como _Total. La definición de Microsoft de ese contador Perfmon es:
El tiempo promedio (en nanosegundos) dedicado a esperar que se envíe un procesador virtual a un procesador lógico.
Obviamente, desea que ese número sea lo más bajo posible. Para las computadoras, esperar casi nunca es algo bueno.
Otros contadores de rendimiento en el hipervisor que tendrá que investigar son Hyper-V Hypervisor Root Virtual Processor\% Guest Run Time, % Hypervisor Run Timey % Total Run Time. Estos contadores le proporcionan los porcentajes que podrían usarse para determinar hechos tales como cuánto tiempo pasan los procesadores "reales" haciendo otras cosas además de dar servicio a una VM o todas las VM.
En conclusión, la métrica que está buscando en una máquina virtual invitada depende del hipervisor en el que se está ejecutando, si ese hipervisor elige proporcionar los datos sobre cómo pasa su tiempo además del servicio de esa VM, y si el invitado El sistema operativo tiene las herramientas / servicios / controladores de integración de virtualización adecuados para ser lo suficientemente conscientes como para darse cuenta de que el hipervisor está haciendo que esos datos estén disponibles.
No sé de ninguna manera en un invitado de Windows, herramientas de integración instaladas o no, para ver cuánto tiempo, en términos de segundos o porcentaje, que el host de VM ha pasado reparándolo o no, respectivamente, al tiempo total del procesador físico. (Edición 10/1/2013: ESXi 5.0 o superior expone estos datos a la máquina virtual invitada a través de las herramientas de integración. Sin embargo, todavía no hay nada en Hyper-V).