Je lis sur KVM
et Qemu
depuis un certain temps. À partir de maintenant, j'ai une compréhension claire de ce qu'ils font.
KVM prend en charge la virtualisation matérielle pour fournir des performances quasi natives aux systèmes d'exploitation invités. D'un autre côté, QEmu émule le système d'exploitation cible.
Ce que je suis confus, c'est à quel niveau ces deux coordonnées. Comme
Qem:
QEmu est un logiciel complet et autonome qui lui est propre. Vous l'utilisez pour émuler des machines, il est très flexible et portable. Il fonctionne principalement par un "recompilateur" spécial qui transforme le code binaire écrit pour un processeur donné en un autre (par exemple, pour exécuter le code MIPS sur un PPC mac ou ARM dans un x86 PC).
Pour émuler plus que le processeur, Qemu inclut une longue liste d'émulateurs périphériques: disque, réseau, VGA, PCI, USB, ports série/parallèle, etc.
KQem:
Dans le cas spécifique où à la fois la source et la cible sont la même architecture (comme le cas commun de x86 sur x86), il doit encore analyser le code pour supprimer toutes les `` instructions privilégiées '' et les remplacer par des changements de contexte. Pour le rendre aussi efficace que possible sur Linux x86, il existe un module de noyau appelé KQemu qui gère cela.
Étant un module du noyau, KQemu est capable d'exécuter la plupart du code inchangé, en remplaçant uniquement les instructions ring0 uniquement de niveau le plus bas. Dans ce cas, l'espace utilisateur Qemu alloue toujours tous les RAM pour la machine émulée et charge le code. La différence est qu'au lieu de recompiler le code, il appelle KQemu pour le scanner/patcher/l'exécuter. Toute l'émulation matérielle périphérique se fait dans Qemu.
C'est beaucoup plus rapide que Qemu ordinaire car la plupart du code est inchangé, mais doit toujours transformer le code ring0 (la plupart du code dans le noyau de la machine virtuelle), donc les performances en souffrent encore.
KVM :
KVM est un couple de choses: c'est d'abord un module de noyau Linux - maintenant inclus dans la ligne principale - qui fait passer le processeur dans un nouvel état "invité". L'état invité a son propre ensemble d'états de sonnerie, mais les instructions ring0 privilégiées retombent dans le code de l'hyperviseur. Puisqu'il s'agit d'un nouveau mode d'exécution du processeur, le code ne doit en aucun cas être modifié.
Outre le changement d'état du processeur, le module du noyau gère également quelques parties de bas niveau de l'émulation comme les registres MMU (utilisés pour gérer la VM) et certaines parties du matériel émulé PCI.
Deuxièmement, KVM est un fork de l'exécutable Qemu. Les deux équipes travaillent activement pour maintenir les différences au minimum, et il y a des progrès dans la réduction de celles-ci. Finalement, l'objectif est que Qemu fonctionne n'importe où, et si un module de noyau KVM est disponible, il pourrait être utilisé automatiquement. Mais dans un avenir prévisible, l'équipe Qemu se concentre sur l'émulation matérielle et la portabilité, tandis que les gens de [KVM se concentrent sur le module du noyau (y déplaçant parfois de petites parties de l'émulation, si cela améliore les performances), et l'interfaçage avec le reste du code de l'espace utilisateur.
L'exécutable kvm-qemu fonctionne comme Qemu normal: alloue de la RAM, charge le code et au lieu de le recompiler ou d'appeler KQemu, il génère un thread (c'est important). Le thread appelle le module de noyau KVM pour passer en mode invité et exécute le code VM. Sur une instruction privilégiée, il revient au module de noyau KVM, qui, si nécessaire, signale au thread Qemu de gérer la plupart de l'émulation matérielle.
Une des bonnes choses de cette architecture est que le code invité est émulé dans un thread posix que vous pouvez gérer avec des outils Linux normaux. Si vous voulez un VM avec 2 ou 4 cœurs, kvm-qemu crée 2 ou 4 threads, chacun d'eux appelle le module de noyau KVM pour démarrer l'exécution. La simultanéité - si vous avez suffisamment de cœurs réels - ou la planification - sinon - est gérée par l'ordonnanceur Linux normal, gardant le code petit et les surprises limitées.
Lorsque vous travaillez ensemble, KVM arbitre l'accès au CPU et à la mémoire, et QEMU émule les ressources matérielles (disque dur, vidéo, USB, etc.). Lorsque vous travaillez seul, QEMU émule à la fois le CPU et le matériel .