Proxmox Server Solutions, fournisseur de la solution de virtualisation libre Proxmox Virtual Environment (VE), annonce la sortie de la version 3.2.
Cette version Proxmox VE 3.2 apporte les fonctionnalités suivantes :
- Ceph, le système de fichiers distribué ; il est possible d’administrer le cluster Ceph via l’interface Web de Proxmox et donc d’utiliser le système de fichiers partagé Proxmox pour répliquer la configuration dans la grappe de serveurs (cluster) ;
- Spice (le protocole d’accès à distance, pas le simulateur de circuit électrique) était disponible en tant que Technology Preview pour accéder aux invités KVM, il est maintenant possible de l’utiliser pour accéder aux conteneurs OpenVZ ou même à une console sur l’hôte. Cela devrait être plus pratique que l’actuelle appliquette Java ;
- Open vSwitch, est un logiciel qui permet de simuler un commutateur réseau (switch) sur l’hôte pour interconnecter les invités, il est de plus en plus utilisé par les différentes solutions de virtualisation et prend en charge de nombreux protocoles standards comme NetFlow ou LACP ;
- et d’autres nouveautés mineures.
Aller plus loin
- Page wiki du projet Proxmox (274 clics)
- Site Web de Proxmox (742 clics)
- Communiqué de presse (91 clics)
- Téléchargement (68 clics)
# Toujours OpenVZ
Posté par Jean-Max Reymond (site web personnel) . Évalué à 1.
Je m'attendais au passage à LXC mais manifestement, cela n'est pas encore d'actualité
[^] # Re: Toujours OpenVZ
Posté par claudex . Évalué à 7.
LXC 1.0 qui est la première version à garantir une vrai isolation (où le root du conteneur ne peut pas faire n'importe quoi) date de fin février, c'est un peu tôt pour l'intégrer dans un logiciel comme Proxmox.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Toujours OpenVZ
Posté par Zenitram (site web personnel) . Évalué à 2.
Comme c'est dit, ça a l'air négatif.
Mais… En quoi est-ce génant? (A ma connaissance, OpenVZ est toujours vivant)
[^] # Re: Toujours OpenVZ
Posté par claudex . Évalué à 3.
Tu es limité dans ton choix de noyau, le dernier stable chez OpenVZ, c'est un 2.6.32 (Proxmox fournit optionnellement un 3.10 mais non supporté), ça peut poser des problèmes de pilote.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Toujours OpenVZ
Posté par Zenitram (site web personnel) . Évalué à 2.
Effectivement, comme la dernière stable de chez Red Hat.
Comme la prochaine stable de Red Hat, qui est aussi pour le moment non supportée car beta ;-).
Après oui, tout dépend de ce qu'on veut, c'est hyper stabilité contre plein de versions supportées (et potentiellement plus bugguées), et OpenVZ se base sur les versions de Red Hat. Pas sûr quand même que je me lancerai comme ça tranquille sur dans un déploiement basé sur LXC 1.0 qui peut poser d'autres problèmes…
[^] # Re: Toujours OpenVZ
Posté par claudex . Évalué à 3.
Personne n'a parlé de tranquillement se lancer avec un autre noyau pour le fun. Mais dans certains cas, c'est bien pratique d'avoir le choix entre un kernel pris en charge et un autre, ce choix n'est pas possible avec Proxmox, c'est un problème. Pas un problème qui se pose pour tout le monde, ni dans toutes les situations mais un problème quand même.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Toujours OpenVZ
Posté par MTux . Évalué à 7.
J'imagine qu'il y a une histoire de compatibilité.
Si on remplace OpenVZ par LXC on empêche les clients d'upgrader leur version de Proxmox…
Ça et le fait qu'aucune distribution ne considère LXC comme mature actuellement.
[^] # Re: Toujours OpenVZ
Posté par aderumier . Évalué à 1.
Il y a également 2 points blocants pour lxc:
# Standards ?
Posté par haleth . Évalué à -3.
"[..] prend en charge de nombreux protocoles standards comme NetFlow ou LACP" : depuis quand netflow est un standard ? C'est un standard chez cisco ouais.
Le standard est sFLow.
[^] # Re: Standards ?
Posté par claudex . Évalué à 3.
La spécification NetFlow est publié dans une RFC Informational et est utilisé par plusieurs fabricants, tout comme sFlow, je ne vois pas pourquoi l'un serait plus standard que l'autre.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Standards ?
Posté par Zenitram (site web personnel) . Évalué à -3. Dernière modification le 22 mars 2014 à 16:34.
Ha… On n'a sans doute pas la même définition de standard… Si maintenant il suffit à une entreprise de balancer une RFC pourque ce soit standard (de facto?)…
http://en.wikipedia.org/wiki/SFlow
"The sFlow.org consortium (…)"
Je dois être un peu rigide, mais les standards faits par une entreprise et une seule font moins standard que des standards créés par un groupement d'entités (et c'est encore mieux si c'est passé par les fourches d'organismes de normalisation, c'est encore "plus standard").
Après, tout est question de définition (acceptation ou non des standards de facto contrôlés par une entreprise et une seule sans aucun droti de dire quoi que ce soit pour les autres, mais à ce jeu Microsoft est un grand acteur des standards)
[^] # Re: Standards ?
Posté par claudex . Évalué à 5.
Pourquoi changer le sens de ma phrase, je n'ai pas écris que la publication d'un RFC Informational était standard mais que que le sFlow et NetFlow étaient tous les deux publiés en tant que RFC Informational. Pourquoi vouloir transformer mes propos pour donner à mon commentaire un sens qu'il n'a pas ? Je n'ai pas vraiment envie d'argumenter avec arguments qui ne répondent pas à ce que je poste. Alors, merci, au revoir.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Standards ?
Posté par BAud (site web personnel) . Évalué à 3.
c'est dommage, pour une une fois qu'il y aurait eu moyen de discuter sur standard et norme donc quelque chose de défini et cadré, plutôt que les seules allégations de Zenitram< :-)
[^] # Re: Standards ?
Posté par galactikboulay . Évalué à 4.
Si je ne dis pas d'âneries, Netflow est orienté export d'informations sur les flux IP (les équipements maintiennent donc une table des flux actifs), alors que SFlow fait du packet sampling, ce qui n'est pas la même chose.
Pour ce qui est du "standard", Cisco a toujours publié les informations sur Netflow, Netflow v9 a même servi de base à l'élaboration d'IPFIX (RFC 7011) qui est un standard IETF. D'autres constructeurs pourtant compétiteurs directs (Juniper, Alcatel, etc) ont adopté Netflow, et quand on voit le nombre de collecteurs et d'exporteurs qu'ils soient open-source ou proprio, on voit que cette techno a largement été adoptée. D'ailleurs, Cisco développait son propre collecteur et ne l'a jamais vraiment poussé par rapport aux autres solutions, et ne lui a jamais donné un avantage sur les autres avec des fonctionnalités cachées dans le protocole. Bref, Netflow est devenu un standard de facto, quoi que tu en penses.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.