il faut que ces systèmes virtuels soient préparés à être virtualisés pour que la paravirtualisation; ceci empêche d’utiliser n’importe quel système de virtualisation, tels que KVM ou VirtualBox.
Xen sait aussi exploiter les extensions de virtualisation pour virtualiser du code non modifié, mais surtout, ce que ne fait pas KVM et consorts, c'est de virtualiser du code modifié.
On pourrait plutôt écrire :
En préparant les systèmes virtuels à la paravirtualisation; ceci permet aussi de virtualiser quand les autres systèmes de virtualisation ne peuvent fonctionner, tels KVM ou VirtualBox.
Alors oui, au final, depuis une machine virtuelle Xen, on ne peut plus bénéficier de KVM, tout comme depuis une machine virtuelle KVM, on ne peut plus non plus lancer virtualbox et bénéficier d'une virtualisation complète...
Là où il y aurai une différence, c'est une différence d'usage : Xen n'est PAS linux, donc lorsqu'on utilise Xen, l'interface de contrôle (virsh du projet libvirt ou xm des xen-tools) tourne déjà dans un linux virtualisé :
Pour administrer des machines virtuelles qui exploitent KVM, on utilise communément virt-manager (gui) ou virsh (cli), ces mêmes outils sont également exploitables avec Xen. Au niveau "expérience utilisateur" de l'admin, KVM en soit n'apporte rien par rapport à Xen si on a un processeur avec extension vmx/svm, l'inverse est vrai aussi, au niveau "expérience utilisateur" de l'admin, Xen en soit n'apporte rien par rapport à KVM si on a un processeur avec extension vmx/svm. Par contre, sans ces extensions, seul Xen fonctionne.
Ce qui est très pratique avec KVM, c'est que puisque le Linux qui fournit l'interface d'admin n'est pas virtualisé, on peut exploiter directement le matériel comme une carte graphique ou une carte son. Ainsi, on installe Ubuntu sur son portable, et à coté de d'un jeu vidéo qui va exploiter des ressources matérielles non virtualisable (par exemple Xonotic), on peut faire tourner une vm avec une carte vidéo générique émulée et des applis bureautiques.
De plus, avec KVM, la séquence de démarrage est plus simple, qu'on veuille virtualiser ou non on a
BIOS -> GRUB2 -> Linux
alors que avec Xen il faut
BIOS -> GRUB2 -> Xen -> Linux
Si on souhaite faire de la virtualisation pour s'amuser, KVM c'est mieux
Si on souhaite faire de la virtualisation en prod', KVM et Xen se valeront1. KVM est sous les projecteurs et est la solution d'avenir, les solutions basées sur KVM seront meilleures parce que tout simplement c'est là que ça pousse. Pour le moment, Xen est le choix historique et donc le choix de la robustesse et de la stabilité.
Par exemple si aujourd'hui vous voulez virtualiser sérieusement avec Debian Squeeze... J'ai été moi-même confronté à ce problème : je voulais que mes machines virtuelles soient endormies à l'extinction de la machine physique, que leur état soit conservé et qu'elles soient réveillées au démarrage. Par contre, si la machine physique est éteinte par accident (coupure EDF plus longue que l'onduleur :/ ) les scripts d'extinctions ne feront pas leur travail, et aucune machine virtuelle ne sera redémarrée lorsque le courant reviendra, ce qui est très gênant.
Pour avoir les deux comportements, réveil de machines virtuelles endormies ET démarrage de machines virtuelles dans le cas d'un état indéterminé, les versions fournies dans Squeeze sont incomplètes, avec Xen il faudra ajouter une dépendance obsolète pas très critique de Lenny (python-xml), alors que pour KVM il faudra remplacer le paquet libvirt-bin (le coeur de l'outil, très critique) par celui du dépôt expérimental (qui paniquait à l'endormissement quand j'ai essayé). Entre un paquet non maintenu qui fontionne, et un paquet expérimental, le choix est fait.
Si vous n'avez pas de processeur avec extension de virtualisation (et que vous n'avez aucune raison de renouveler votre parc), Xen est le seul choix, ce n'est pas un inconvénient pour Xen.
Les technos sont mutuellement exclusives, ça n'a rien de notable et je trouve étrange de présenter comme inconvénient quelque chose d'évident et de normal.
1 Probablement qu'avec Red-Hat on peut parler au présent.
ce commentaire est sous licence cc by 4 et précédentes
# drôle de formulation
Posté par Thomas Debesse (site web personnel, Mastodon) . En réponse à la dépêche Petites brèves : Phonon 4.5 et Xen 4.1. Évalué à 10.
Je trouve étrange cet argument :
Xen sait aussi exploiter les extensions de virtualisation pour virtualiser du code non modifié, mais surtout, ce que ne fait pas KVM et consorts, c'est de virtualiser du code modifié.
On pourrait plutôt écrire :
Alors oui, au final, depuis une machine virtuelle Xen, on ne peut plus bénéficier de KVM, tout comme depuis une machine virtuelle KVM, on ne peut plus non plus lancer virtualbox et bénéficier d'une virtualisation complète...
Là où il y aurai une différence, c'est une différence d'usage : Xen n'est PAS linux, donc lorsqu'on utilise Xen, l'interface de contrôle (virsh du projet libvirt ou xm des xen-tools) tourne déjà dans un linux virtualisé :
Ainsi, quand on utilise Xen, il n'est donc plus possible à Qemu d'exploiter KVM, puisque nous sommes déjà dans une machine virtuelle.
Avec KVM, l'interface de contrôle n'est pas dans une machine virtuelle :
Pour administrer des machines virtuelles qui exploitent KVM, on utilise communément virt-manager (gui) ou virsh (cli), ces mêmes outils sont également exploitables avec Xen. Au niveau "expérience utilisateur" de l'admin, KVM en soit n'apporte rien par rapport à Xen si on a un processeur avec extension vmx/svm, l'inverse est vrai aussi, au niveau "expérience utilisateur" de l'admin, Xen en soit n'apporte rien par rapport à KVM si on a un processeur avec extension vmx/svm. Par contre, sans ces extensions, seul Xen fonctionne.
Ce qui est très pratique avec KVM, c'est que puisque le Linux qui fournit l'interface d'admin n'est pas virtualisé, on peut exploiter directement le matériel comme une carte graphique ou une carte son. Ainsi, on installe Ubuntu sur son portable, et à coté de d'un jeu vidéo qui va exploiter des ressources matérielles non virtualisable (par exemple Xonotic), on peut faire tourner une vm avec une carte vidéo générique émulée et des applis bureautiques.
De plus, avec KVM, la séquence de démarrage est plus simple, qu'on veuille virtualiser ou non on a
BIOS -> GRUB2 -> Linuxalors que avec Xen il fautBIOS -> GRUB2 -> Xen -> LinuxSi on souhaite faire de la virtualisation pour s'amuser, KVM c'est mieuxSi on souhaite faire de la virtualisation en prod', KVM et Xen se valeront1. KVM est sous les projecteurs et est la solution d'avenir, les solutions basées sur KVM seront meilleures parce que tout simplement c'est là que ça pousse. Pour le moment, Xen est le choix historique et donc le choix de la robustesse et de la stabilité.
Par exemple si aujourd'hui vous voulez virtualiser sérieusement avec Debian Squeeze... J'ai été moi-même confronté à ce problème : je voulais que mes machines virtuelles soient endormies à l'extinction de la machine physique, que leur état soit conservé et qu'elles soient réveillées au démarrage. Par contre, si la machine physique est éteinte par accident (coupure EDF plus longue que l'onduleur :/ ) les scripts d'extinctions ne feront pas leur travail, et aucune machine virtuelle ne sera redémarrée lorsque le courant reviendra, ce qui est très gênant.
Pour avoir les deux comportements, réveil de machines virtuelles endormies ET démarrage de machines virtuelles dans le cas d'un état indéterminé, les versions fournies dans Squeeze sont incomplètes, avec Xen il faudra ajouter une dépendance obsolète pas très critique de Lenny (python-xml), alors que pour KVM il faudra remplacer le paquet libvirt-bin (le coeur de l'outil, très critique) par celui du dépôt expérimental (qui paniquait à l'endormissement quand j'ai essayé). Entre un paquet non maintenu qui fontionne, et un paquet expérimental, le choix est fait.
Si vous n'avez pas de processeur avec extension de virtualisation (et que vous n'avez aucune raison de renouveler votre parc), Xen est le seul choix, ce n'est pas un inconvénient pour Xen.
Les technos sont mutuellement exclusives, ça n'a rien de notable et je trouve étrange de présenter comme inconvénient quelque chose d'évident et de normal.
1 Probablement qu'avec Red-Hat on peut parler au présent.
ce commentaire est sous licence cc by 4 et précédentes