Proxmox Virtual Environment (VE) est une solution de virtualisation libre (AGPL v3) basée sur l’hyperviseur Linux KVM. Cette semaine a été annoncée la mise à disposition de la plate‑forme de gestion de la virtualisation Proxmox VE 6.3. Cette version est basée sur Debian Buster 10.6, mais utilise le dernier noyau Linux de support à long terme (5.4), QEMU 5.1, LXC 4.0, Ceph 15.2, et inclut ZFS 0.8.5.
Proxmox VE 6.3 introduit l’intégration de la version stable 1.0 de sa nouvelle solution libre de sauvegarde des serveurs Proxmox Backup Server. Proxmox VE dispose d’un puissant chiffrement côté client et la création et la gestion des clefs de chiffrement est très simple, offrant de multiples façons de stocker les clefs. Les sauvegardes des machines virtuelles sont très rapides grâce à la fonction QEMU dirty‑bitmap.
Cette version 6.3 apporte également une intégration stable de Ceph 15.2.6 Octopus, et l’utilisateur peut maintenant sélectionner sa version préférée de Ceph pendant le processus d’installation. D’autres nombreuses nouvelles fonctionnalités de gestion spécifiques à Ceph ont été ajoutées à l’interface graphique. Dans la nouvelle version, il est maintenant possible d’afficher et de régler le mode de mise à l’échelle automatique des groupes de placement (PG) pour chaque « pool » Ceph de la grappe de stockage. Dans l’ensemble, Proxmox a ajouté encore plus de fonctionnalités et d’améliorations à l’interface graphique.
D’innombrables corrections de bogues et améliorations de moindre importance sont également incluses, voir les notes de publication complètes.
Aller plus loin
- Forum de Proxmox (54 clics)
- Feuille de route (80 clics)
- Annonce de la version 6.3 sur le site officiel (167 clics)
- Page de téléchargement (38 clics)
- LinuxFr.org : Proxmox Backup Server 1.0 (109 clics)
# Comparaison avec VMWARE
Posté par tmehdi . Évalué à 1.
Bjr,
Serait il possible d'avoir une comparaison pour le niveau de maturité de PVE en comparaison avec VMWARE.
C'est un sujet qui m'est bcp posé et pour lequel j'ai pas d'elements de reponses, vu que je ne travail que sur PVE exclusivement.
Si il y a quelqu'un qui peut m'orienter je suis preneur.
[^] # Re: Comparaison avec VMWARE
Posté par Anonyme . Évalué à 2.
C’est incomparable, VMWare a des ressources virtuellement illimitées, PVE est maintenu par une petite entreprise qui vend du support.
J’ai pas travaillé beaucoup avec VMWare (et plutôt en tant qu’utilisateur de la plateforme, qu’en tant qu’administrateur) et le plus gros truc maquant dans PVE c’est probablement les outils : pas de Veeam Backup intégré comme dans VMWare (ce qui semble être un incontournable), les providers terraform sont pas aussi complet ou aussi bon, packer ça fait genre 1 an que le provisioner existe, pas de « cloud provider » pour Kubernetes, etc.
D’ailleurs une différence avec VMWare, qui pourrait avoir une incidence dans le contexte de Kubernetes : dans PVE les disques sont fortement lié à une VM, dans VMWare tu peux très facilement déplacer un disque d’une VM à une autre.
Aussi, PVE n’a pas de DRS et beaucoup de chose sont « au niveau du host » : tu veux créer une VM il faut absolument lui dire sur quel host tu veux le faire par exemple.
Donc si tu cherche à faire un AWS en interne, c’est probablement VMWare qui gagne, mais PVE reste un très, très bon outil et je n’utiliserai probablement jamais VMWare si j’avais le choix. Bref, ça dépend fortement des besoins.
Au passage, un autre argument en faveur de VMWare c’est sa notoriété : dans une grande entreprise, ça sera probablement plus difficile de convaincre les décideurs d’utiliser PVE plutôt que d’aller chez le leader du marché.
[^] # Re: Comparaison avec VMWARE
Posté par tao popus . Évalué à 1.
On peut assez facilement détacher un disque via l'interface puis, dans une autre VM l'attacher si c'est un disque physique, ou, si c'est un fichier disque, déplacer le fichier disque dans son dossier via shell, lui dire de le rescanner, il est alors automatiquement intégré.
On crée une VM sur un host, mais on peut très bien la déplacer à chaud et sans interruption d'un host à l'autre si on les met en cluster. Est-ce que l'on peut faire cela avec VMWare ?
[^] # Re: Comparaison avec VMWARE
Posté par malagasy . Évalué à 0. Dernière modification le 02 décembre 2020 à 00:34.
Je dirai plutôt qu'il faudrait comparer ce qui est comparable.
Proxmox est un hyperviseur de type 1 (barre metal). Il faudrait le comparer avec vSphere (ESXi) de VMware dans ce cas.
J'utilise les deux, proxmox à la maison et vsphere au boulot. Je dirai que proxmox n'a pas à rougir face à vsphere, qui est juste un serveur avec des fonctionnalités très basiques (création de VMs/datastores, réseautage, etc.).
Par contre, vmware travaille sur un projet expérimental pour porter ESXi sur du matériel embarqué (esxi sur raspberry pi). Aux dernières nouvelles, proxmox a du mal à porter le projet sur les architectures arm.
A la question
Ce n'est pas possible sans vCenter.
[^] # Re: Comparaison avec VMWARE
Posté par claudex . Évalué à 4.
Pas vraiment, il faut le comparer à la solution complète, parce que c'est par rapport à celle-là que Proxmox va être comparé.
« 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: Comparaison avec VMWARE
Posté par Anonyme . Évalué à 2.
Disclaimer, ça fait bientôt 10 ans que je travaille avec PVE et même si c’est possible que j’ai loupé une feature, je pense pas me tromper dans ce que je vais dire là
Ça me parait assez hacky comme manière de faire. Dans VMWare, les disques sont complètement découplés des VM, j’ai une UI qui me permet d’attacher n’importe quel disque sur n’importe quelle VM.
Dans PVE, je viens d’essayer à l’instant : j’ai une VM avec l’ID 1000 qui a déjà un disque nommé
vm-1000-disk-0(mes disques sont stockés dans un thin volume LVM), je créé un nouveau disque que PVE nommevm-1000-disk-1, je le détache, à partir de là, comment je le rattache à une autre VM ?Je peux renommer le disque (ou le déplacer si c’est un fichier), mais ça me demande de me connecter en SSH sur le host et de le faire à la main. Il n’y a absolument aucun moyen de le faire via l’API, ou via l’interface Web.
De le même manière, si je crée un disque à la main avec un nom bidon, je peux pas l’attacher à une VM quelconque.
Si on voulait un driver CSI pour Kubernetes comme il existe un driver pour VMWare, on ne pourrait pas le faire. D’ailleurs, une preuve que c’est pas prévu dans PVE : le disque porte le nom de la VM.
Voir la réponse de Xavier Claude : dans VMWare tu crée tes VM sans te soucier du node où elle vont atterrir, tu peux créer des règles d’affinités ou d’anti-affinités, tu peux mettre un node en maintenance et les VM sont rebalancer pour toi, etc.
[^] # Re: Comparaison avec VMWARE
Posté par claudex . Évalué à 3.
Du coup, j'ai vérifié et effectivement c'est plus compliqué dans Proxmox que dans mon souvenir.
Mais dans VMWare, les disques ne sont pas si découplés des VM que ça. Tu ne peux créer un disque dans un dossier sans passer par l'api ou en cli, donc ça n'est pas très différent de Proxmox. Et par défaut, un disque que tu ajoute à une VM a le nom de la VM et est dans le dossier de la VM.
Je pense que tu pourrais tout à fait avoir un CSI pour proxmox qui s'occupe de créer les disque comme pour VMWare.
« 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: Comparaison avec VMWARE
Posté par Anonyme . Évalué à 2.
Bah, non, puisque tu peux pas le déplacer d’une VM à une autre.
[^] # Re: Comparaison avec VMWARE
Posté par claudex . Évalué à 2.
Autant que pour VMware.
« 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: Comparaison avec VMWARE
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 04 décembre 2020 à 07:39.
Si tu peux assigner à une VM le disque d'une autre VM (pourvu que cette autre VM est éteinte).
C'est assez goret, ça sort un peu des bonnes pratiques et je dirais que ça n'a d'intérêt que temporairement pour une migration de données mais c'est possible.
[^] # Re: Comparaison avec VMWARE
Posté par claudex . Évalué à 2.
Ce que tu dis est valable pour VMWare et 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: Comparaison avec VMWARE
Posté par Anonyme . Évalué à 2.
C’est pas en le répétant que ça devient vrai. Là on tourne en rond.
Dans PVE tu peux pas facilement, à travers l’UI ou l’API attacher n’importe quel disque à n’importe quelle VM et encore moins créé des disques « standalones ».
C’est ce que fait le driver CSI de Kubernetes et c’est un comportement que j’adorerai retrouver dans PVE.
Alors, oui, tu peux aller lancer
mvoulvrenamesur ton stockage, mais c’est pas ce dont on parle.[^] # Re: Comparaison avec VMWARE
Posté par claudex . Évalué à 2.
Ce n'est pas plus facile dans l'UI de VMware.
« 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: Comparaison avec VMWARE
Posté par claudex . Évalué à 2.
Pour être plus clair. Proxmox et vmware (dans l'interface), pour créer un disque, il faut qu'il soit associé à une vm, et on peut associé un disque qui n'est pas attaché à une vm dans les deux cas.
« 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: Comparaison avec VMWARE
Posté par Anonyme . Évalué à 3. Dernière modification le 04 décembre 2020 à 22:11.
Bah vas-y explique moi comment je détache un disque d’une VM pour l’attacher à une autre.
Edit: Au passage, la doc dit que c’est seulement possible via la « commandline » (et en réalité, c’est pas juste un
qm move-disk <vm1> <vm2>, c’est plusieurs étapes manuelles qui dépendent du type de stockage).[^] # Re: Comparaison avec VMWARE
Posté par claudex . Évalué à 4.
Je m'excuse, j'étais persuadé d'avoir vu l'option pour attacher un disque existant.
(d'ailleurs, je ne retrouve même pas un truc qui ressemble à ce que je pensais, donc, je ne sais même pas avec quoi j'ai confondu).
« 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: Comparaison avec VMWARE
Posté par claudex . Évalué à 4.
Je ne vois pas trop ce que tu veux dire avec ça. De mémoire, c'est assez similaire.
Et cela complique les maintenance. Avec VMWare, tu peux mettre un esxi en maintenance, et il va se charger tout seul de bouger les VM où il faut. Tu peux aussi faire des groupes pour éviter que les VM d'un même cluster se retrouver sur le même hôte. Cependant, il semblerait que ça va arriver dans Proxmox https://linuxfr.org/news/proxmox-ve-6-2-est-disponible#comment-1810775
La notoriété fait qu'il est aussi plus facile de trouver des gens compétents sur le sujet.
Un point que j'ai vu aussi, c'est qu'il n'y a pas de support 24/7 chez Proxmox, uniquement business hours, ce qui est assez bloquant pour beaucoup de clients.
Sinon, je suis d'accord, Proxmox est un très bon produit. Et c'est plus facile à debugger qu'un esx.
« 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: Comparaison avec VMWARE
Posté par Anonyme . Évalué à 2.
J’ai répondu à tao popus et j’en ai profité pour faire une boucle infinie (désolé si vous restez coincés :D).
Totalement d’accord avec ça, je rajoute juste une anecdote vu qu’on est sur DRS.
J’ai eu beaucoup de soucis avec DRS quand je travaillais chez OVH. On avait des clusters avec des VM qui consommaient énormément de ressources à certains moments de la journée (comme des tâches crons qui se lancent toutes en même temps) et DRS avait tendance à « partir en vrille » et à déplacer des VM dans tous les sens pour équilibrer la charge.
C’est pas très grave si tes VMs sont légères ou si elles ne font que des tâches de fond, mais quand elles sont énormes et que le réseau de stockage est saturé par des dizaines de VM qui bougent, ou qu’elles servent des requêtes et qu’elles commencent à perdre des paquets pendant la migration, c’est tout de suite moins drôle.
Après, il y a des configurations pour rendre DRS un peu moins con, et sur des clusters bien dimensionnés et bien gérés, j’ai rarement vu ce genre de cas.
[^] # Re: Comparaison avec VMWARE
Posté par claudex . Évalué à 3.
Je pense que tu as intérêt à avoir un stockage partagé dans ce cas pour éviter justement la saturation de ton réseau de stockage.
Ça reste un point difficile si tu n'as pas beaucoup de marge, parce que la situation optimale pour ton cas d'utilisation dépend souvent de plusieurs conditions qui bougent en fonction du temps.
« 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: Comparaison avec VMWARE
Posté par virttom . Évalué à 0.
Bonjour,
je sais que je viens après la bataille et je m'en excuse ! ceci dit il me semble que la question est suffisamment intemporelle pour qu'on y revienne, comme une bonne glace quoi.
Venant du monde professionnel et plutôt spécialisé sur VMware à la base (professionnel mainstream donc). J'ai décidé d'opérer un virage libriste il y a maintenant 2 ans et j'ai l'occasion d'enfin pouvoir le réaliser dans mon cadre de travail. Bref c'est pas pour me faire mousser, juste pour situer le niveau de mes connaissances plutot coté VMware et pas trop gnu ;)
Pour ma part j'ai découvert le produit par hasard il y a même pas 1 an et je suis plutôt bluffé par cette implémentation de KVM. Comme dit par ailleurs, Proxmox est une petite boite et à "faibles" revenu mais il y a des choses très très propre je trouve ! ça me fait penser à VMware quand ça ne s'appelait pas vSphere (et j'avais pas de poils blancs dans ma barbe mais bon).
Je suis en train d'implémenter une archi pour un client qui souhaite mettre en place des produits à base d'hyperviseurs stand alone & de cluster HCI et pour l'instant ça répond présent. J'en saurais un peu plus dans quelques mois, quand j'aurais attaqué réellement la partie cluster et pas juste stand alone mais au niveau hyperviseur pur on a du bon. Et du mature pour la prod sans problèmes.
[^] # Re: Comparaison avec VMWARE
Posté par tisaac (Mastodon) . Évalué à 2.
N'hésite pas à nous faire dans quelques mois une dépêche retour d'expérience:
Surtout, ne pas tout prendre au sérieux !
# proxmox et kubernetes
Posté par malagasy . Évalué à 1. Dernière modification le 02 décembre 2020 à 01:15.
Je me pose la question en ce qui concerne l'implémentation native de kubernetes dans proxmox, puisque tout est à configurer à la main. Sur un petit réseau, çà ne devrait pas poser de problèmes, mais ce n'est pas le cas dans une grande infrastructure.
D'autant plus que l'avenir de la virtualisation a l'air de se penche de plus en plus vers les conteneurs, vu l'effort déployé par pas mal de grandes entreprises:
- VMare avec tanzu
- Suse est en train d'acheter Rancher Lab
- Redhat avec openshift
[^] # Re: proxmox et kubernetes
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 02 décembre 2020 à 14:10.
Je crois que c'est un faux problème.
Openshift est décorellé de la gestion des vms. Quand tu demandes à un consultant Redhat de te proposer une archi openshift il va te proposer de faire tourner ça sur du RHV ou si tu as déjà du vmware sur du vmware. Au final tu dois aussi "tout configurer à la main".
VMWare Tanzu, c'est pas juste une coche que t'actives dans ton environnement vsphere. C'est tout une suite de produits que tu dois installer par dessus.
L'expérience a montré que quand un sales-ingineer te vend une "intégration" poussée entre 2 produits, il y a souvent derrière une montagnes de trucs à faire et dans de nombre cas des manques importants qui font que ce n'est pas aussi bien intégré que le whitepaper ne pourrait le faire penser.
Rancher est sympa car il peut te configurer tes VMS automatiquement mais au final le provisionning des VMs n'est pas vraiment la tâche la plus compliquée et ça peut se faire dans proxmox via ansible ou terraform.
Note: je n'ai aucun part dans proxmox et ne l'utilise pas en prod.
[^] # Re: proxmox et kubernetes
Posté par Anonyme . Évalué à 2.
Tout dépend de ce que tu cherches à faire. Je fais tourner Kubernetes dans Proxmox en perso et au taf je le fais dans VMWare, donc je peux répondre à tes questions si tu en as.
De tête, je vois déjà deux différences avec VMWare : pas de driver CSI et pas d’auto-provisioning. Pour le premier cas tu peux utiliser Ceph, dans le second cas je suppose que tu dois pouvoir développer quelque chose autours de l’API de PVE, mais je pense pas que quelque chose existe déjà pour faire ça.
[^] # Re: proxmox et kubernetes
Posté par Psychofox (Mastodon) . Évalué à 3.
C'est pas parce qu'il n'y a pas de csi pour ton système d'hypervision que t'es obligé d'utiliser ceph. Chez nous on fait tourner kubernetes sur du vmware mais on n'a pas utilisé leur csi car au moment où on l'avait évalué il ne supportait pas les redimenssionnements online. Du coup on utilise le csi trident pour les baies netapp directement qui était bien plus mature il y a déjà deux ans.
D'ailleurs c'est pas totalement idiot de décoreller csi/stockage du système d'hypervision. On avait commencé à utiliser kubernetes sur du bare-metal pour migrer sur du vmware, essentiellement par tranquilité lors des mises à jours de cluster via les reboots de vm plus rapides et le csi lié à un stockage externe nous a permis de faire ça de façon transparente. Et si un jour on veut décider de changer de système d'hypervision (on réfléchit à RHV actuellement), on le peut de façon complète ou partielle, et en tout cas progressivement. Idem si on voulait réutiliser du bare-metal pour des workloads particuliers.
# PVE avec kubernetes
Posté par tmehdi . Évalué à 0.
Merci beaucoup pour ces retours d'experiences,
Pour ma part je voudrais apporter une ptite contribution a l'echange,
Dans le cafre d'un POC, je suis entrain de travailler sur le montage d'une infra pour containers, avec les outils suivants :
Ubuntu Maas pour l auto provisonning de serveur bar metal pour deploiement de PVE
Rancher pour la mise en place de Kubernetes
Racher longhorn pour le CSI avec des VM dedié au stockage
Ou bien linstor CSI qui me parait un tres bon produit au passage.
Je pense qu avec des outils libre de ce genre on peu avoir une infra a la page avec un bon niveau d'integration et de richesse fontionnelle.
[^] # Re: PVE avec kubernetes
Posté par Psychofox (Mastodon) . Évalué à 2. Dernière modification le 03 décembre 2020 à 10:08.
longhorn a t-il gagné en maturité ? La dernière fois que j'ai regardé les perfs étaient franchement pas top et il ne supportait pas certains truc basiques comme les redimenssionnements de volumes.
EDIT: je me réponds à moi même après avoir revisité longhorn.io, à priori pour le second point c'est en tout cas réglé.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.