Sortie de Proxmox VE 6.3

Posté par  . Édité par Davy Defaud, Xavier Teyssier, palm123 et Pierre Jarillon. Modéré par Xavier Claude. Licence CC By‑SA.
28
29
nov.
2020
Virtualisation

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.

Proxmox VE 6.3 Backup Server Encryption.

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

  • # Comparaison avec VMWARE

    Posté par  . É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  . É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  . Évalué à 1.

        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.

        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é.

        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.

        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  . Évalué à 0. Dernière modification le 02/12/20 à 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

          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 ?

          Ce n'est pas possible sans vCenter.

          • [^] # Re: Comparaison avec VMWARE

            Posté par  . Évalué à 4.

            Proxmox est un hyperviseur de type 1 (barre metal). Il faudrait le comparer avec vSphere (ESXi) de VMware dans ce cas.

            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  . Évalué à 2.

          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é.

          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 nomme vm-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.

          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 ?

          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  . Évalué à 3.

            Ç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.

            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.

            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.

            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  . Évalué à 2.

              Je pense que tu pourrais tout à fait avoir un CSI pour proxmox qui s'occupe de créer les disque comme pour VMWare.

              Bah, non, puisque tu peux pas le déplacer d’une VM à une autre.

              • [^] # Re: Comparaison avec VMWARE

                Posté par  . É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  . Évalué à 2. Dernière modification le 04/12/20 à 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  . É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  . É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 mv ou lvrename sur ton stockage, mais c’est pas ce dont on parle.

                      • [^] # Re: Comparaison avec VMWARE

                        Posté par  . Évalué à 2.

                        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 ».

                        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  . É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  . Évalué à 3. Dernière modification le 04/12/20 à 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  . É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  . Évalué à 4.

        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.

        Je ne vois pas trop ce que tu veux dire avec ça. De mémoire, c'est assez similaire.

        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.

        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

        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é.

        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  . Évalué à 2.

          Je ne vois pas trop ce que tu veux dire avec ça. De mémoire, c'est assez similaire.

          J’ai répondu à tao popus et j’en ai profité pour faire une boucle infinie (désolé si vous restez coincés :D).

          Et cela complique les maintenances. 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 retrouvent sur le même hôte.

          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  . Évalué à 3.

            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.

            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.

            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.

            Ç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  . É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  . Évalué à 2.

        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.

        N'hésite pas à nous faire dans quelques mois une dépêche retour d'expérience:

        • ce qui a bien fonctionné, les qualités de la solution
        • les workaround que tu as mis en place pour résoudre d'éventuels problèmes
        • les faiblesses que tu n'as pas pu éviter

        Surtout, ne pas tout prendre au sérieux !

  • # proxmox et kubernetes

    Posté par  . Évalué à 1. Dernière modification le 02/12/20 à 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  . Évalué à 2. Dernière modification le 02/12/20 à 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  . É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  . É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  . É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  . Évalué à 2. Dernière modification le 03/12/20 à 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.