Proxmox VE 6 on Zwindler's Reflection

Les soucis que j’ai rencontrés en upgradant Proxmox VE 7

Mon, 19 Jul 2021 06:55:00 +0000

TL;DR - Lisez encore plus attentivement que d’habitude la release note de Proxmox VE 7

La version 7 de mon hyperviseur préférée vient de sortir ! Comme je n’ai rien d’important qui tourne dessus, je me suis dis que c’était une bonne idée de tester la mise à jour day 1 sans préparation.

Ça n’est évidemment pas une bonne idée ;-p.

Au delà de la valse d’upgrades habituelle ainsi quelques features très sympas (SSO surtout), une modification importante est le passage à Debian 11, Bullseye, qui n’est d’ailleurs pas totalement officiellement sortie (même si on est depuis le 17 en Full freeze…), mais aussi les cgroups v2 et leur configuration, ainsi que OpenZFS.

Lisez donc bien :

pve6to7 OK

Si vous avez déjà fait quelques upgrade de Proxmox VE, vous savez qu’à la dernière mineure de chaque version, un binaire pveXtoY est mis à disposition pour vérifier que la machine (ou éventuellement le cluster) est prêt à être mis à jour.

Dans mon cas, pas de soucis, à part un warning sur le fait que mes VMs actives devraient être migrées (mais comme je n’ai pas de stockage partagé, j’accepte ce downtime).

/boot plein

Cette « erreur » ne m’est pas arrivée mais c’est un grand classique de Proxmox VE. Il n’est pas rare que les /boot soient taillés un peu juste lors de l’installation, et que les kernel (ceux de debian + ceux de proxmox qui a le sien, plus récent) prennent toute la place dans le /boot.

Avant de lancer l’upgrade, vérifiez bien que vous avez de la place pour un kernel dans /boot et nettoyez ce qui dépasse

sudo apt autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
pve-kernel-5.4.101-1-pve pve-kernel-5.4.106-1-pve pve-kernel-5.4.73-1-pve pve-kernel-5.4.78-2-pve
0 upgraded, 0 newly installed, 4 to remove and 0 not upgraded.

Dépôts bullseye pas présents chez votre provider

Une partie de mes machines sont hébergées par Online. Je ne sais pas si c’est toujours le cas, mais au moment où j’ai fais l’upgrade, les miroirs n’existaient pas chez eux.

La commande permettant de mettre à jour les fichiers de configuration d’apt n’est donc pas utilisable en l’état si c’est toujours le cas.

Dans mon cas, j’ai donc du aller modifier les dépôts ciblés pour aller chercher un autre miroir FR

cat /etc/apt/sources.list
# deb http://mirrors.online.net/debian bullseye main
#deb http://mirrors.online.net/debian bullseye main non-free contrib
#deb-src http://mirrors.online.net/debian bullseye main non-free contrib
deb http://ftp2.fr.debian.org/debian/ bullseye main contrib non-free
deb-src http://ftp2.fr.debian.org/debian/ bullseye main contrib non-free
deb http://security.debian.org/debian-security bullseye-security main contrib non-free
deb-src http://security.debian.org/debian-security bullseye-security main contrib non-free

hwaddress pour les bridges

Ça c’est LE « piège à c%% » de cette version de Proxmox. C’était d’ailleurs écrit (mais pas hyper clairement) dans la section Known upgrade issues du guide d’Upgrade.

Mais comme ce n’était pas clair ils ont rajouté un gros pavé qui explique un peu mieux le problème :

Jusqu’à présent, il n’était pas nécessaire de donner une adresse MAC à un bridge et ma config réseau n’en avait pas du coup. En lisant, ce message, j’ai (bêtement) pensé « peu importe si Debian en donner une autre après l’upgrade ».

Grave erreur. Comme pas mal de monde, je me suis coupé la chique après reboot. Comme je suis loin d’être le seul, les équipes de Proxmox ont rajouté a posteriori un paragraphe pour expliquer POURQUOI c’est un souci et pourquoi il faut setter soit même la MAC.

TL;DR, récupérez la MAC de vos interfaces réseau branchées sur un bridge avec ip -c link et ajouter la mac address dans votre bridge avant upgrade.

old systemd (< v232) detected, container won’t run in a pure cgroupv2 environment

Là encore, petite surprise due à une mauvaise lecture de ma part. Proxmox VE 6 utilisait déjà les cgroups v2 pour les containers LXC, mais avec une configuration hybride. J’ai donc pensé qu’il n’y avait pas de changement de ce côté.

Grave erreur. Après upgrade, 2 de mes containers LXC en CentOS ont arrêté de fonctionner. Les machines étaient vue « UP » dans l’interface mais impossible de s’y connecter ni de lancer la console. Pas de message d’erreur particulier.

Heureusement, quand on relance les containers, j’ai réussi à voir dans la console l’erreur suivante :

WARN: old systemd (< v232) detected, container won’t run in a pure cgroupv2 environment! Please see documentation -> container -> cgroup version.TASK WARNINGS: 1

Un retour rapide sur les Known upgrade issues permet de trouver le problème assez vite

Grosso modo, Proxmox VE 7 ne supporte plus les CentOS 7 en mode container LXC (sauf à bidouiller des paramètres pour revenir dans l’ancien mode, ce que je n’ai pas fait). Et là, c’était pas fun du tout…

Replication ZFS HS pendant l’upgrade

Petit point d’attention, j’ai eu mes réplications asynchrones de mes VMs via ZFS qui étaient HS entre les nodes de différentes versions (6 vers 6 ok, 7 vers 7 ok, 6 vers 7 KO).

Je n’ai malheureusement pas copié le message d’erreur mais il s’agit d’un bête changement d’arguments dans la ligne de commande entre OpenZFS dans la version de PVE 6 et OpenZFS 2 (PVE 7).

Là, il n’y a pas grand chose à part ne pas trop trainer pour mettre à jour tous vos nodes (ou faire les synchro à la main, peut être ?).

ovs qui ne s’instancie pas, ovs-vsctl show n’affiche rien

Je n’ai pas dig particulièrement, mais j’ai eu un souci assez pénible avec mes bridges OpenvSwitch, qui étaient correctement déclarés dans le fichier /etc/network/interfaces mais qui n’apparaissaient jamais.

Un restart du service n’y faisait rien, pas plus qu’essayer d’ajouter un nouveau bridge en ligne de commandes.

Finalement, ça a fini par « tomber en marche » en ajoutant un bridge OVS depuis la console (et pas en ligne de commandes comme j’avais testé initialement).

Weird. Peut être un coup de « pas de chance ».

Conclusion

Si vous voulez mettre à jour vos Proxmox VE pour bénéficier des nouvelles fonctionnalités (le SSO OpenIDConnect me fait rêver), faites donc bien bien attention de ne pas avoir de containers LXC trop anciens et de bien setter vos mac address dans le fichier /etc/network/interfaces.

Au delà de ça, ça devrait aller maintenant.

Changement de provider, mon hyperviseur sur un dédié Hetzner

Tue, 19 Nov 2019 07:30:00 +0000

Au revoir OneProvider, bonjour Hetzner

Certains d’entre vous m’ont peut être vu me plaindre de OneProvider et plus particulièrement le support avec qui j’ai eu plusieurs accrochages (Spoiler, j’ai migré vers Hetzner).

Sans rentrer dans les détails (j’ai échangé avec certains d’entre vous sur le sujet), après cette déconvenue, j’ai donc cherché une alternative pour héberger mes machines.

Les prérequis étaient d’avoir :

une machine physique
avec suffisamment de RAM (minimum 8 Go, 16 c’est mieux)
idéalement, une gestion des réseaux virtuels entre machines du provider (type RPN ou vRack)
si possible pas un ATOM en CPU (le souci de l’ATOM, c’est que c’est tellement faiblard que ça pénalise les IO)
si possible du VT-x (je n’en ai pas besoin d’en l’absolu, je vais surtout du LXC, mais ça peut dépanner)
si possible du SSD parce que c’est quand même cool
si possible 2 disques pour avoir du RAID ou que je puisse me faire un équivalent (ZFS/ZRAID)
un prix pas trop élevé (genre pas OVH) car j’ai été mal habitué avec les prix agressifs de OneProvider (oui je sais, je l’ai payé avec le support)

L’état du marché

Chez OneProvider, j’avais tout ça pour environ 20-25 euros / mois, à l’exception du réseaux privé virtuel entre machine.

Autant dire qu’on est très loin du premier prix de chez OVH (>60€/mois TTC). Si on descend en gamme chez OVH, on perd le réseau privé virtuel entre machines (vRack) en passant chez SoYouStart et pourtant on est toujours à plus de 42€ / mois TTC. Toujours 2 fois plus cher que OneProvider :-/.

Il faut descendre encore de gamme et passer chez Kimsufi pour trouver des prix comparables dans mes critères (et toujours pas de réseau privé virtuel), avec de vieux CPU et surtout un réseau bridé au 100 Mbps (ce qui est pénible pour les transferts de gros fichiers, les réplications de VMs et les sauvegardes).

J’avais aussi jeté un œil côté Online.net, qui eux proposent sur certaines machines identiques à celles que j’avais avec EN PLUS le graal, un réseau privé virtuel entre dédiés (RPN).

Ces deux configs me disaient vraiment quelque chose… et pour cause ! OneProvider les revends en marque blanche.

Donc c’est exactement les mêmes machines que celle que j’ai pu avoir dans le passé, mais avec le RPN en plus, et un peu plus cher (beaucoup plus cher même).

Ce qui est dommage ici, c’est que le RPN ne soit pas disponible sur les machines un peu plus petites (mon PRA n’est pas aussi gros, juste de quoi faire tourner le blog en cas de gros crash).

Vient alors Hetzner

Ça fait pas mal de fois que je voyais circuler le nom. Des bloggeurs et d’autres confrères en disaient beaucoup de bien, et j’ai voulu aller voir. La première chose intéressante est que Hetzner, comme OVH et Online, propose bien un service de type réseau privé virtuel entre vos serveurs !

Plus de puissance chez Hetzner !

Par contre, quand j’ai vu les machines… au début je me suis dis que ça allait pas le faire…

Voilà leur machine “bas de gamme” :

Pour à peine plus que le moins cher des SoYouStart (un vieux Xeon E3 v2 4c/4t avec 16Go de RAM et 2 HDD), vous avez un tout nouveau Ryzen 5 6c/12t, 64 Go de RAM et un RAID de 2 SSD NVMe de 512 Go.

Bon clairement on était hors budget mais ils avaient piqué ma curiosité avec leurs config fofolles.

Et je suis donc tombé en fouillant un peu sur leur “server auction”, qui est ni plus ni moins que les serveurs de leurs anciennes gammes qu’ils louent à nouveau. Et là c’était déjà plus proche de mon besoin.

Pour un peu plus de 30€/mois soit 50% plus que mon serveur précédent, mais comparable au prix Online, j’ai un i7-4770, 32 Go de RAM et 2 disques “Entreprise”. Soit beaucoup mieux que la machine chez Online.

Quitte à changer, j’ai donc tenté Hetzner et commandé un serveur.

C’est puissant mais… qu’est ce que c’est moche

Bon, l’UI n’est pas follement attrayante. C’est… spartiate.

Dans le menu “Servers”, vous avez une bête liste de vos serveurs avec le numéro de commande, un hostname (une fois que vous l’aurez setté) et un ID (peu parlant). Bof pratique, surtout au début ou si vous en avez beaucoup.

Et quand on sélectionne un serveur, ce n’est malheureusement guère mieux. Les informations importantes éclatées dans un nombre incalculable de menus.

Bref, côté expérience utilisateur, on repassera. Cependant, tout ce qu’il faut pour bien administrer son serveur est là. On finira par s’y retrouver avec un peu d’habitude…

Installation de l’hyperviseur

Pour installer notre serveur, on peut utiliser l’interface web pour installer un Debian, ou passer par l’image de rescue.

J’ai préféré utiliser la 2ème solution, car elle est immédiatement disponible à la livraison du serveur, avec votre clé SSH.

On arrive sur un login on ne peut plus classique, avec un résumé des caractéristiques de vos serveurs.

Point intéressant, il existe un binaire installimage sur l’OS rescue de Hetzner. Il permet, comme son nom l’indique, d’installer une image.

Comme j’utilise Proxmox VE comme hyperviseur, j’ai donc installé une Debian 10 :

Une fois l’image de base choisie, vous allez arriver à un éditeur de texte. Il va vous permettre de configurer de manière plus fine votre installation. Je trouve cette méthode assez originale. Ça change des interfaces webs pas toujours stables vous demandant la taille de vos partitions pour finalement planter dès que vous demandez un truc non standard.

Ici tout a très bien marché, j’ai configuré le hostname, ainsi qu’un RAID soft et un partitionnement LVM.

Là encore, je suis navré qu’on tombe dans le cliché, mais si ce n’est pas “joli” ni “user friendly”, au moins c’est efficace.

Passer de Debian 10 à Proxmox VE 6

Une fois validé, l’image Debian 10 a été copié extrêmement rapidement (une ou deux minutes). Forcément, c’est une “minimal”. Mais bon c’est quand même agréable d’avoir son serveur “up and running” en moins d’une demie heure entre la commande et la fin de l’installation.

Reste donc à installer PVE 6 sur notre dédié Hetzner. Sans trop de surprise, j’ai réutilisé mon playbook Ansible qui configure de A à Z la Debian pour en faire un Proxmox. Pour ceux qui l’ont loupé, c’est par ici que ça se passe.

J’ai juste eu un petit souci lors de l’installation. La debian étant minimale, je n’avais même pas python d’installé. C’est gênant quand on fait du Ansible !

cat inventory_hetzner.yml
all:
children:
proxmoxve:
hosts:
<fqdn_hyperviser>:
ansible proxmoxve -i inventory_hetzner.yml -u root -m ping
<fqdn_hyperviser> | FAILED! => {
"changed": false,
"module_stderr": "Shared connection to <fqdn_hyperviser> closed.\r\n",
"module_stdout": "/bin/sh: 1: /usr/bin/python: not found\r\n",
"msg": "MODULE FAILURE",
"rc": 127
}

Heureusement j’avais déjà eu le souci dans un autre contexte. J’ai donc écris un playbook supplémentaire (dispo sur le Github) pour installer les prérequis manquants.

ansible-playbook -i inventory_hetzner.yml -u root proxmox_python_firstinstall.yml
ansible-playbook -i inventory_hetzner.yml -u root proxmox_prerequisites.yml

Et en quelques minutes, mon Proxmox VE était opérationnel sur Hetzner !