Différence entre Xen PV, Xen KVM et HVM?


53

Je sais que Xen est généralement meilleur qu'OpenVZ, car le fournisseur ne peut pas exagérer dans Xen. Cependant, quelle est la différence entre Xen PV, Xen KVMet HVM(Je passais en revue les spécifications de ce fournisseur ? Lequel est le meilleur pour quoi faire et pourquoi?


Modifier:

Pour un utilisateur final qui va simplement héberger des sites Web, lequel est le meilleur? Du point de vue de l'efficacité ou d'un autre point de vue, y a-t-il un avantage de l'un sur l'autre?

Réponses:


47

Types de virtualisation pris en charge par Xen

Xen prend en charge l'exécution de deux types d'invités différents. Les invités Xen sont souvent appelés domUs (domaines non privilégiés). Les deux types d'invités (PV, HVM) peuvent être utilisés simultanément sur un même système Xen.

Xen paravirtualisation (PV)

La paravirtualisation est une technique de virtualisation efficace et légère introduite par Xen, puis adoptée également par d'autres solutions de virtualisation. La paravirtualisation ne nécessite pas d'extensions de virtualisation à partir du processeur hôte. Toutefois, les invités paravirtualisés ont besoin d’un noyau spécial, conçu pour fonctionner en mode natif sur Xen. Les invités sont donc au courant de l’hyperviseur et peuvent fonctionner efficacement sans émulation ni matériel émulé virtuel. Les noyaux invités Xen PV existent pour les systèmes d'exploitation Linux, NetBSD, FreeBSD, OpenSolaris et Novell Netware.

Les invités PV ne disposent d'aucun type de matériel émulé virtuel, mais une console graphique est toujours possible avec l'invité pvfb (tampon de cadre paravirtuel). La console graphique de l'invité PV peut être visualisée à l'aide du client VNC ou de virt-viewer de Redhat. Il existe un serveur VNC distinct dans dom0 pour le PVFB de chaque invité.

Les noyaux Linux kernel.org amont depuis Linux 2.6.24 incluent le support d'invité Xen PV (domU) basé sur le framework pvops Linux, de sorte que chaque noyau Linux en amont puisse être automatiquement utilisé comme noyau d'invité Xen PV sans correctifs ni modifications supplémentaires.

Voir la page wiki XenParavirtOps pour plus d'informations sur la prise en charge de Linux pvops Xen.

Virtualisation complète Xen (HVM)

Les invités entièrement virtualisés, appelés HVM (machine virtuelle matérielle), nécessitent des extensions de virtualisation du processeur à partir du processeur hôte (Intel VT, AMD-V). Xen utilise la version modifiée de Qemu pour émuler tout le matériel d'un ordinateur, notamment le BIOS, le contrôleur de disque IDE, l'adaptateur graphique VGA, le contrôleur USB, l'adaptateur réseau, etc. pour les invités HVM. Les extensions de virtualisation du processeur sont utilisées pour améliorer les performances de l'émulation. Les invités entièrement virtualisés ne nécessitent pas de noyau spécial. Par exemple, les systèmes d'exploitation Windows peuvent être utilisés en tant qu'invités Xen HVM. Les invités entièrement virtualisés sont généralement plus lents que les invités paravirtualisés, en raison de l'émulation requise.

Pour améliorer les performances, les invités HVM entièrement virtualisés peuvent utiliser des pilotes de périphérique paravirtuels spéciaux pour contourner l'émulation pour les E / S réseau et sur disque. Les invités HVM Windows Xen peuvent utiliser les pilotes GPLPV opensource. Consultez la page Wiki XenLinuxPVonHVMdrivers pour plus d'informations sur les pilotes Xen PV-sur-HVM pour les invités HVM Linux.

Ceci est tiré de http://wiki.xenproject.org/wiki/XenOverview

KVM n'est pas du tout Xen, c'est une autre technologie, où KVM est un module de noyau natif Linux et non un noyau supplémentaire, comme Xen. Ce qui rend KVM un meilleur design. L'inconvénient est que KVM est plus récent que Xen et qu'il manque donc peut-être certaines de ses fonctionnalités.


9
+1 KVM n'est pas du tout Xen. Il est totalement en désaccord que KVM est un meilleur design. Xen fournit une bien meilleure isolation et ne dépend pas du noyau Linux et de ses vulnérabilités potentielles.
Antoine Benkemoun le

2
Merci pour l'info! Je ne pouvais pas tout comprendre. Du point de vue de l'utilisateur final, qui hébergera simplement des sites Web, lequel est le meilleur? Y a-t-il un avantage significatif de l'un sur l'autre?

2
Xen a ses propres vulnérabilités. Mais faire tourner un système d’exploitation avec deux noyaux amorcés est un défaut de conception, peu importe la façon dont vous le faites
dyasny

1
JP19: cela dépend des sites. Si vous pouvez définir la charge sur le VPS, vous pouvez demander ici ou google pour la meilleure solution.
Dyasny

2
Xen est un hyperviseur, de même que KVM. KVM a des périphériques PV et ajoute plus avec le temps, il permet également le transfert PCI. Donc, je ne vois pas l'intérêt de votre argument, Nils
Dyasny,

32

Xen est un hyperviseur qui s'exécute sur le métal (le PC / serveur), puis héberge des machines virtuelles appelées domaines.

Un Xen PVdomaine est un domaine paravirtualisé , ce qui signifie que le système d'exploitation (nous parlons généralement de Linux ici) a été modifié pour fonctionner sous Xen et qu'il n'est pas nécessaire d'émuler réellement du matériel. Cela devrait être le moyen le plus efficace d'aller au-delà des performances.

Un Xen HVMdomaine est un domaine matériel émulé , ce qui signifie que le système d'exploitation (qu'il s'agisse de Linux, Windows, peu importe) n'a pas été modifié de quelque manière que ce soit et que le matériel est émulé. Ceci est plutôt lent. Vous devez donc généralement installer les pilotes PV dans le système invité pour le matériel essentiel (généralement le disque et le réseau). Ainsi, l’invité s’exécutera dans son intégralité, mais les éléments matériels les plus critiques en termes de performances seront exécutés paravirtualisés. Les systèmes linux récents ont des pilotes pv pour le disque et le réseau dans le noyau, et il existe également divers pilotes PV pour Windows. Avec tout le développement sur HVM de ces dernières années, il y a généralement peu de différence de performances entre HVM et PV pour les charges de travail standard.

KVMn’est pas Xen, c’est une autre plate-forme de virtualisation construite à l’intérieur du noyau Linux. D'un point de vue invité , il ressemble à HVM Xen: l'invité est entièrement virtualisé et il existe un pilote spécifique pour exécuter certaines parties paravirtualisées (encore une fois, disque et réseau).

Xen HVM et Linux KVM nécessitent tous deux une prise en charge de la virtualisation assistée par matériel (Intel VT-x, AMD AMD-V), alors que Xen PV n’exécute pas mais ne peut pas exécuter de systèmes d’exploitation sans prise en charge de PV (vous ne pouvez pas exécuter Windows sur Xen PV).

Xen HVM et Linux KVM utiliseront tous deux des parties du logiciel de virtualisation qemu pour émuler le matériel réel des périphériques n’utilisant pas de pilotes PV dans le système invité.

Xen (PV et HVM) peut effectuer la migration en direct d'un invité en cours d'exécution d'un serveur physique à un autre. Je ne sais pas si KVM le peut également.

Xen et KVM ne peuvent pas surcharger la mémoire, vous obtenez donc généralement une "vraie RAM", tandis que d'autres plates-formes telles que VMware peuvent échanger une partie du RAM invité sur le disque.

Il existe des différences, mais elles s'appliquent généralement à des installations spécifiques et non au serveur privé virtuel générique destiné à être vendu à d'autres personnes. Par exemple, les hyperviseurs Xen récents prennent en charge la mémoire transcendante, ce qui pourrait améliorer l'utilisation de la mémoire et les performances de l'invité si l'invité était pris en charge (noyaux Linux> = 3.quelque chose).

Toutes ces technologies vous donneront une expérience enrichissante si elles sont mises en œuvre correctement et ne feront pas une grande différence de votre point de vue. Bien sûr, il y a mille façons dont les problèmes peuvent survenir, sans que cela soit lié à la solution de virtualisation spécifique (en d'autres termes, votre invité pourrait être stocké sur des disques lents, ce qui nuirait à vos performances).


3
KVM peut surcharger la mémoire, tout comme Xen.
dyasny

@dyasny Je ne connais pas le KVM, mais je suis à peu près sûr que Xen ne peut pas surcharger la mémoire au sens réel du terme (autoriser une taille maximale différente est une chose différente). Veuillez relier vos sources si vous le croyez.
Luke404

Xen soutient le balooning. Ajoutez à cela un échange standard et vous disposez déjà d’au moins 2 mécanismes de sur-engagement. C'est aussi vieux que 2008: blog.xen.org/index.php/2008/08/27/…
dyasny

3
@dyasny, vous pensez probablement que le sur- engagement permet un maximum plus élevé. D'après les informations dont je dispose, le sens accepté est d'allouer réellement aux invités plus de mémoire que physiquement présente dans l'hôte, ce qui n'est pas implémenté dans Xen. Vous ne pouvez pas dégonfler un ballon d’invité (par exemple, lui donner plus de mémoire) si vous ne disposez pas de mémoire physique disponible sur l’hôte, et vous ne pouvez pas non plus démarrer un nouvel invité si vous avez déjà alloué toute votre mémoire d’hôte faire fonctionner des ballons d’invités, réduisant ainsi réellement la mémoire allouée afin de ne pas surcharger la tâche)
Luke404

1
Je pense à la surconsommation non seulement en autorisant plus que ce que l’hôte a physiquement, mais aussi en utilisant réellement plus que ce que l’hôte a physiquement. L'échange est horrible, mais c'est un mécanisme qui vous permet d'allouer plus de pages de mémoire que vous n'en avez physiquement sur un hôte, que ce soit pour des processus ou des VM - peu importe. C'est aussi loin que je vais aller dans la sémantique sur celui-ci.
dyasny
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.