Quelqu'un pourrait-il expliquer en quoi il est différent ? Y a-t-il une différence de performance ? Y a-t-il une raison pour que je choisisse l'un plutôt que l'autre ?
Comme l'explique votre autre réponse, il y a quelques différences architecturales entre les deux projets.
En gros, lorsqu'il s'agit d'un hyperviseur Intel VT, pour activer l'hyperviseur, vous exécutez (en assembleur) une séquence spéciale d'instructions, qui aboutit au résultat suivant VMXON
. Cela permet d'activer le mode hyperviseur.
Une partie de ce travail consiste à définir les machines virtuelles en fonction de leur tables de pages étendues ou l'équivalent AMD. Il s'agit d'une tâche similaire à la configuration ordinaire des tables de pages (quelle mémoire se connecte où), sauf que vous le faites pour des régions de mémoire entières pour les machines virtuelles. La technologie VM précédente se contentait de piéger Sorties VM à cette fin qui sont essentiellement comme des interruptions matérielles fantaisistes.
En quoi cela fait-il référence à l'architecture ? Eh bien, vous avez deux choix pour construire un hyperviseur :
-
Construisez un hyperviseur autonome qui met en place le moniteur de la machine virtuelle et attend ensuite les systèmes d'exploitation invités. En général, il contient suffisamment de son propre système d'exploitation pour gérer les machines virtuelles, ou prend en charge un invité privilégié. Par exemple, l'hyperviseur Xen comprend un "invité" "Dom0" qui a la capacité de gérer l'hyperviseur.
-
Construire un hyperviseur en tant que partie d'un noyau existant, par exemple en tant que module du noyau. Le code peut être installé en tant que moniteur de machine virtuelle dans Intel VT à n'importe quel moment de la durée de vie d'un système d'exploitation (en supposant un privilège suffisant) et également retiré. En tant que tel, le code de l'hyperviseur configure simplement l'espace nécessaire en mémoire selon les besoins.
En pratique, la différence pour l'utilisateur final serait que vous ne pouvez pas décharger l'hyperviseur s'il est du premier type sans un redémarrage. Cela est dû au fait qu'il se comporte comme un système d'exploitation à part entière. Hyper-V agit de la sorte : si Hyper-V est installé, vous ne pouvez pas installer VirtualBox, par exemple, car les deux ne peuvent pas partager l'espace de surveillance de la machine virtuelle (puisque Hyper-V en dispose déjà). Afin de décharger l'hyperviseur, vous devez redémarrer.
Pour faire simple : si Hyper-V est installé, même si aucune VM n'est en cours d'exécution, vous ne pourrez utiliser aucun autre produit de virtualisation. Ce n'est pas le cas de Virtual PC.
Maintenant, la performance. Sur les systèmes de type Intel VT, le fait de charger le système d'exploitation ou l'hyperviseur en premier fait probablement peu de différence en termes de performances, puisqu'il s'agit uniquement d'une zone liée au CPU et que si vous utilisez déjà la virtualisation assistée par le matériel du CPU, vous êtes de toute façon aussi rapide que possible.
En ce qui concerne les performances, les différences dans la virtualisation proviennent de techniques telles que paravirtualisation et l'utilisation de IOMMU / Re-mappage DMA . En bref, l'ordre d'organisation de la mémoire du système d'exploitation et du processeur ne fera pas autant de différence que la possibilité ou non de virtualiser efficacement des éléments tels que les disques durs, les cartes graphiques, etc.
Ça ressemble beaucoup à 当ブログ記事 qu'Hyper-V a eu des problèmes dans le passé avec des préoccupations de virtualisation de type grand public : graphiques, son, etc. Je n'ai pas exécuté Hyper-V en ayant besoin de ces choses, donc je ne peux pas dire si c'est toujours un problème, mais cela peut valoir la peine de l'étudier.