Edit: Mise à jour le 1er octobre 2013 - Une partie de ma réponse d'origine est depuis devenue obsolète.
Je ne sais pas si vous êtes toujours actif sur ce site ou si vous le verrez, mais je voulais que vous sachiez que j'ai lu cette question aujourd'hui et qu'elle m'a fasciné, et donc j'ai passé toute la journée (quand j'aurais dû travaille) en recherchant les composants internes d'Hyper-V et de Windows et même en creusant dans les concepts mêmes de la virtualisation elle-même dans l'espoir que je serais prêt à répondre à votre question.
Permettez-moi de commencer en disant que je viens du point de vue d'Hyper-V en tant que plate-forme de virtualisation, car c'est là que j'ai le plus d'expérience. Même s'il peut y avoir certains principes de virtualisation, comme nous le savons, qui ne peuvent être écartés, Microsoft et VMware et Xen ont tous des stratégies différentes pour la conception de leurs hyperviseurs.
C'est la première chose qui rend votre question difficile. Vous posez votre question comme si elle était indépendante de l'hyperviseur, alors qu'en vérité ce n'est pas le cas. Amazon EC2, par exemple, utilise l'hyperviseur Xen et la métrique "CPU Steal Time" que vous voyez dans la sortie d'une topcommande émise à partir d'une machine virtuelle Linux exécutée sur cet hyperviseur est le résultat des services d'intégration installés sur cet OS invité (ou des outils compatibles avec la virtualisation sur l'invité) conjointement avec les données fournies par cet hyperviseur spécifique.
Tout d'abord, permettez-moi de répondre directement à votre question: il n'y a aucun moyen de voir depuis l'intérieur d'une machine virtuelle exécutant Windows combien de temps les processeurs appartenant à la machine physique sur laquelle l'hyperviseur s'exécute passent à faire autre chose, à moins que les outils virtuels particuliers / des services ou des outils compatibles avec la virtualisation pour votre hyperviseur particulier sont installés dans la machine virtuelle invitée etl'hyperviseur particulier sur lequel s'exécute l'invité expose ces données à l'invité. Même un invité Windows fonctionnant sur un hyperviseur Hyper-V n'aura pas immédiatement accès aux informations concernant le temps passé par les processeurs physiques de l'hyperviseur à faire autre chose. (Pour citer voretaq7, quelque chose qui «brise le quatrième mur».) Même si les systèmes d'exploitation client et serveur Windows fonctionnant en tant qu'invités virtualisés dans Hyper-V avec les bons services / outils d'intégration installés utilisent des «éclaircissements» (qui sont littéralement du noyau les modifications de code conçus spécialement pour les machines virtuelles) qui augmentent de manière significative leurs performances dans l' utilisation des ressources d'un hôte physique, la ligne de fond est que l'hyperviseur ne disposepour donner plus d'informations au SE invité qu'il ne le souhaite. Cela signifie que l'hyperviseur n'ont à dire à un invité VM quoi d' autre il fait d' ailleurs le service que VM ... à moins qu'il veut. Et ces informations sur ce que font les processeurs physiques sont nécessaires pour dériver une métrique du point de vue de la machine virtuelle telle que "CPU Steal Time: le pourcentage de temps pendant lequel le vCPU attend un CPU physique".
Comment l'OS invité pouvait-il savoir cela, s'il ne réalisait même pas qu'il était réellement virtualisé?
En d'autres termes, sans les bons outils d'intégration installés sur l'invité, le système d'exploitation invité ne saura même pas que son processeur est en fait un processeur v . Il ne saura même pas qu'il existe une autre force en dehors de lui-même qui "vole" les cycles du processeur, donc cette métrique n'existera pas sur la machine virtuelle invitée.
VMware a commencé à exposer ces données aux clients Windows ainsi qu'à ESXi 5.0. Les outils d'intégration VMware doivent également être mis à jour sur l'invité. Voici une référence ; ils l'appellent "CPU Stolen Time".
Un hyperviseur tel que Hyper-V ne donne pas aux clients un accès direct aux ressources physiques telles que les processeurs physiques ou les cœurs de processeur. À la place, l'hyperviseur leur donne des vDev - des périphériques virtuels - tels que des vCPU.
Un excellent exemple de la raison: Supposons qu'un OS invité de machine virtuelle effectue l'appel pour vider le TLB (tampon de traduction de côté) qui est un composant physique d'un CPU physique. Si le système d'exploitation invité était autorisé à effacer l' intégralité du TLB sur un processeur physique, cela aurait des effets négatifs sur les performances de toutes les autres machines virtuelles qui partageaient également ce même TLB physique. Dans le cas de Windows, cet appel dans le système d'exploitation invité est traduit en un appel "hypercall" ou "éclairé" qui est interprété par l'hyperviseur de sorte que seule la section du TLB qui est pertinente pour cette machine virtuelle est vidée.
(Fait intéressant, cela me donne à penser que les machines virtuelles invitées qui ne disposent pas des outils d'intégration et / ou des services appropriés pourraient avoir la capacité d'avoir un impact sur les performances de toutes les autres machines virtuelles sur le même hôte, mais cela sort complètement du cadre de cette rubrique. .)
Tout cela pour dire que vous pouvez toujours détecter dans un hôte Hyper-V le temps qu'un processeur virtuel a passé à attendre qu'un vrai processeur soit disponible pour qu'il puisse être planifié pour s'exécuter. Mais vous ne pouvez voir ces données que sur un hyperviseur Windows Hyper-V. S'il est possible de voir cela dans d'autres hyperviseurs, j'exhorte les autres à nous dire comment voir cela dans cet hyperviseur et aussi s'il est exposé aux invités. (Edit 01/10/2013 Merci evilensky pour faire juste ça!)
Ma machine de test était Hyper-V Server 2012, qui est l'édition gratuite de Server 2012 qui n'exécute que Core et le rôle Hyper-V. C'est en fait la même chose que tout Windows Server 2012 exécutant Hyper-V.
Lancez Perfmon sur votre partition parent, alias hôte physique. Chargez ce compteur:
Hyper-V Hypervisor Virtual Processor\CPU Wait Time Per Dispatch\*
Vous remarquerez qu'il y aura une instance de ce compteur pour chaque machine virtuelle sur cet hyperviseur, ainsi que _Total. La définition Microsoft de ce compteur Perfmon est:
Temps moyen (en nanosecondes) passé à attendre qu'un processeur virtuel soit distribué sur un processeur logique.
Évidemment, vous voulez que ce nombre soit aussi bas que possible. Pour les ordinateurs, attendre n'est presque jamais une bonne chose.
D' autres compteurs de performance sur l'hyperviseur que vous voulez enquêter sont Hyper-V Hypervisor Root Virtual Processor\% Guest Run Time, % Hypervisor Run Timeet % Total Run Time. Ces compteurs vous fournissent les pourcentages qui pourraient être utilisés pour déterminer des faits tels que le temps que les «vrais» processeurs passent à faire autre chose que l'entretien d'une VM ou de toutes les VM.
Donc, en conclusion, la métrique que vous recherchez dans une machine virtuelle invitée dépend de l'hyperviseur sur lequel elle s'exécute, si cet hyperviseur choisit de fournir les données sur la façon dont il passe son temps autre que l'entretien de cette machine virtuelle, et si l'invité Le système d'exploitation dispose des bons outils / services / pilotes d'intégration de virtualisation pour être suffisamment conscient du fait que l'hyperviseur rend ces données disponibles.
Je ne connais aucun moyen sur un invité Windows, que des outils d'intégration soient installés ou non, pour voir combien de temps, en termes de secondes ou de pourcentage, cet hôte de VM a passé à le réparer ou à ne pas le faire par rapport au temps total du processeur physique. (Édition 01/10/2013: ESXi 5.0 ou supérieur expose ces données à la machine virtuelle invitée via les outils d'intégration. Toujours rien sur Hyper-V cependant.)