J'utilise beaucoup Xen et pas du tout OpenVZ, mais je vais essayer de répondre.
Déjà, Xen a trois modes de fonctionnement, dans les grandes lignes :
- PV (= ParaVirtualisé) : full software.
- HVM (= Hardware Virtual Machine) : full hardware (et son petit frère «PV on HVM», c'est à dire HVM avec des drivers PV)
- PVH (= ParaVirtualisation Hardware) : une version software qui s'aide des avancées hardware pour améliorer les perfs, mais n'a pas encore toutes les fonctionnalités (pas de migration à chaud, par exemple).
Du coup, ça complique un peu les comparaisons de perf. Dans le mode PV 64bits, les appels système sont plutôt lent par rapport à une machine sans virtualisation (genre 20 fois plus sur un sysbench CPU), mais selon les workloads ça ne se ressent pas forcément (sur de l'Apache/PHP par exemple, je n'ai pas mesuré de différence sensible.
Je n'ai pas testé le mode HVM, n'étant pas spécialement fan.
Par contre le mode PVH en terme de perfs est assez impressionnant, suffisamment pour que je ne remarque pas de différence au score sysbench CPU entre mes VMs et cette même machine sans virtualisation.
Tout ça pour dire qu'en terme de performances & ressources, j'estime Xen plutôt efficace. Là où il se démarque d'un conteneur c'est typiquement sur la gestion de la mémoire : par défaut la RAM allouée à une VM Xen lui est réservée, pas d'overcommit («sur-allocation» ?) à ce niveau, pour le meilleur et pour le pire. Par contre on a accès à la «transcendant memory», pour mutualiser la RAM inutilisée de l'host. Bref, gestion mémoire très différente.
Coté «flexibilité» c'est un grand mot... on peut déplacer des VM à chaud oui, on peut même faire de la «tolérance de panne» via Remus, c'est à dire que l'état de la RAM est synchronisée en temps réel (ou presque) vers un autre host physique, pour que cette seconde VM prenne le relais (sous 300ms je crois) en cas de plantage. Sans reboot donc. Par contre si tu veux partager des fichiers entre tes VMs, c'est plus compliqué...
Quant à la dernière question concernant les interfaces, je serais bien incapable de répondre, n'utilisant ni l'une ni l'autre.
[^] # Re: [HS] Xen par rapport aux conteneurs légers
Posté par Kioob (site web personnel) . En réponse à la dépêche Xen Orchestra, solution de gestion d'infrastructure Xen. Évalué à 6.
J'utilise beaucoup Xen et pas du tout OpenVZ, mais je vais essayer de répondre.
Déjà, Xen a trois modes de fonctionnement, dans les grandes lignes :
- PV (= ParaVirtualisé) : full software.
- HVM (= Hardware Virtual Machine) : full hardware (et son petit frère «PV on HVM», c'est à dire HVM avec des drivers PV)
- PVH (= ParaVirtualisation Hardware) : une version software qui s'aide des avancées hardware pour améliorer les perfs, mais n'a pas encore toutes les fonctionnalités (pas de migration à chaud, par exemple).
Du coup, ça complique un peu les comparaisons de perf. Dans le mode PV 64bits, les appels système sont plutôt lent par rapport à une machine sans virtualisation (genre 20 fois plus sur un sysbench CPU), mais selon les workloads ça ne se ressent pas forcément (sur de l'Apache/PHP par exemple, je n'ai pas mesuré de différence sensible.
Je n'ai pas testé le mode HVM, n'étant pas spécialement fan.
Par contre le mode PVH en terme de perfs est assez impressionnant, suffisamment pour que je ne remarque pas de différence au score sysbench CPU entre mes VMs et cette même machine sans virtualisation.
Tout ça pour dire qu'en terme de performances & ressources, j'estime Xen plutôt efficace. Là où il se démarque d'un conteneur c'est typiquement sur la gestion de la mémoire : par défaut la RAM allouée à une VM Xen lui est réservée, pas d'overcommit («sur-allocation» ?) à ce niveau, pour le meilleur et pour le pire. Par contre on a accès à la «transcendant memory», pour mutualiser la RAM inutilisée de l'host. Bref, gestion mémoire très différente.
Coté «flexibilité» c'est un grand mot... on peut déplacer des VM à chaud oui, on peut même faire de la «tolérance de panne» via Remus, c'est à dire que l'état de la RAM est synchronisée en temps réel (ou presque) vers un autre host physique, pour que cette seconde VM prenne le relais (sous 300ms je crois) en cas de plantage. Sans reboot donc. Par contre si tu veux partager des fichiers entre tes VMs, c'est plus compliqué...
Quant à la dernière question concernant les interfaces, je serais bien incapable de répondre, n'utilisant ni l'une ni l'autre.
alf.life