Pve on Zwindler's Reflection

Proxmox 8.2.5 : bad scheduler ! Bad !

Sat, 28 Sep 2024 12:45:00 +0000

Note : cet article n’est pas écrit par moi (zwindler) mais par mon ami et ancien collègue Fabio, que j’héberge avec grand plaisir sur le blog, comme je le fais parfois pour les copain·es qui n’ont pas de blog :-)

Note : TL;DR à la fin de la page, mais attention, vous allez faire pleurer un bébé dauphin. Vous êtes prévenus.

On est dimanche, l’odeur du café et des croissants plane encore dans le séjour, c’est donc un moment parfait pour …

(comment ça, “ah bon” ?)

J’en profite pour mettre à jour mon instance Proxmox en PVE 8.2.5.

La semaine passe, je reçois mes mails de backup des VM et je ne vois pas d’erreurs.

Au bout d’un moment, quelque chose me met la puce à l’oreille : je n’en reçois qu’un sur les 3 jobs (celui de 4h00) :

Début de l’enquête

En me connectant sur mon instance, j’observe le journal des tâches qui va m’aider beaucoup :

Je vois donc que les jobs ne se lancent même pas. Tentons donc d’en lancer un à la main avec le bouton “Run now” :

NOM DE ZEUS, le job fonctionne. J’ai bien la notification par mail, tout s’est bien passé.

Le stockage de backup est un peu ric-rac, 93% d’utilisation, mais si le backup passe manuellement, y’a pas de raisons que ce soit ça (enfin, ça pourrait, mais je n’ai rien qui tourne la nuit en même temps que ces opérations).

Ce n’est pas non plus la notification par mail du backup, j’aurais des erreurs dans /var/log/mail.log et il y’aurait une ligne dans le journal des tâches en erreur.

Donc : le job se lance manuellement, mais n’est pas lancé de manière périodique.

Fin du mystère

Je commence à m’intéresser au pve-scheduler. En regardant ses logs (journalctl -eu pve-scheduler.service au besoin), j’observe quelque chose d’intéressant :

400 Parameter verification failed.
job-id: invalid format - invalid configuration ID '1e66440f10abf0aeae5d19f5d0905235c69d811d:1'
', but neither allow_blessed, convert_blessed nor allow_tags settings are enabled (or TO_JSON/FREEZE method missing) at /usr/share/perl5/PVE/Jobs.pm line 228.

Je vois que la nomenclature des jobs problématiques est effectivement de type 1e66440f10abf0aeae5d19f5d0905235c69d811d:1 alors que le job de backup encore fonctionnel est backup-684086d5-2e43.

DING DING, WE GOT A WINNER ! Je tombe sur Google sur le thread du forum communautaire Proxmox parlant de ce problème : https://forum.proxmox.com/threads/scheduled-backups-didnt-run-after-8-2-5-upgrade.154686/

pve-manager (8.2.6) bookworm; urgency=medium
* fix #5731: vzdump jobs: fix execution of converted jobs
-- Proxmox Support Team <support@proxmox.com> Fri, 20 Sep 2024 17:47:17 +0200

Et effectivement, une upgrade est disponible :

 --> apt list --upgradable
En train de lister... Fait
libpve-common-perl/stable 8.2.3 all [pouvant être mis à jour depuis : 8.2.2]
libpve-http-server-perl/stable 5.1.1 all [pouvant être mis à jour depuis : 5.1.0]
libpve-storage-perl/stable 8.2.5 all [pouvant être mis à jour depuis : 8.2.4]
pve-manager/stable 8.2.7 amd64 [pouvant être mis à jour depuis : 8.2.5]

Un coup d’apt upgrade plus tard, mes backups programmés refonctionnent \o/

TL;DR : Si vos jobs de backup ne se lancent pas après une mise à jour en 8.2.5 de votre instance Proxmox… Remettez à jour vos paquets, un fix est disponible :)

Mieux migrer ses VM de Proxmox VE vers XCP NG (part 2)

Mon, 08 Aug 2022 06:00:00 +0200

Résumé des épisodes précédents

Dans l’article d’il y a 2 semaines (Migrer une VM de Proxmox VE vers XCP NG), j’ai introduit très brièvement de XCP-NG (un OS clé en main pour faire de la virtualisation, sur une base de Xen / XenServer) et déroulé un tuto pour récupérer une VM sur Proxmox VE et l’importer dans XCP-NG.

Pour faire court, les étapes étaient les suivantes :

Récupération du disque virtuel sur Proxmox VE
Transformer le disque virtuel en VHD
Le transférer sur le serveur XCP-NG
Créer un disque dans XenOrchestra (l’UI de XCP-NG, pour faire simple)
Importer le contenu du VHD dans le disque vide qu’on a créé dans l’UI
Créer une VM dans l’UI et lui affecter le disque

Faire mieux

Dans le cadre d’un PoC avec une poignée de VMs, ça me parait totalement acceptable comme méthodologie (même si c’est un peu fastidieux) mais dans le cadre d’une migration, c’est difficilement scalable.

Note : Vates (l’entreprise qui édite XCP-NG) accompagne ses clients pro dans cette étape. A ma connaissance, ils travaillent également sur de l’outillage pour faciliter les transferts, mais Proxmox VE ne sera probablement pas la première “plateforme source” qui sera supportés par ce genre d’outils.

Dans cet article, je vais donc vous parler d’une méthode alternative qui m’a été conseillée par les gens de chez Vates pour faciliter cette migration, et plus particulièrement les étapes suivantes :

Le transférer sur le serveur XCP-NG
Créer un disque dans XenOrchestra (l’UI de XCP-NG, pour faire simple)
Importer le contenu du VHD dans le disque vide qu’on a créé dans l’UI

Because I’m API 🎶

Clap along if you feel like that’s what you wanna do

Vous l’avez deviné, on va passer par l’API de Xen Orchestra pour se faciliter la tâche. En effet, on va pouvoir rassembler les 3 actions ci dessus en seul appel via cURL !

Même s’il y a un petit prérequis (à faire une fois), ça sera quand même beaucoup plus scalable pour bouger plusieurs VMs.

You token to me?

[EDIT] Depuis la version 5.72 de Xen Orchestra, il est possible de récupérer un token directement dans la Web UI (cf ce post)

En lisant la documentation de la REST API (paragraphe authentication), on apprend, sans surprise, que la première chose à faire est de récupérer un token permettant d’authentifier nos futures requêtes.

On comprend ensuite que pour faire ça, on va avoir besoin d’un tool qui s’appelle xo-cli.

Si on suit la doc, il “suffit” d’installer ce module via npm.

npm install xo-cli

Bon… moi j’ai pas envie d’installer npm sur mon poste donc j’ai fais une image Docker cracra pour ça ;-).

FROM node

WORKDIR /app

RUN npm install --global xo-cli

ENTRYPOINT ["xo-cli"]

Le Dockerfile est disponible ici et l’image docker buildée est disponible là.

Depuis son poste (en remplaçant évidemment @IP.Xen.Orchestra par l’IP de votre serveur XenOrchestra, admin@admin.net par votre login)

docker run -it xo-cli --createToken --allowUnauthorized @IP.Xen.Orchestra admin@admin.net Password: ************
Successfully logged with admin@admin.net
Authentication token created xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Si tout s’est bien passé, on récupère un token qu’on garde précieusement pour nos futures requêtes.

champion de cURLing

De retour sur la documentation de l’API REST (paragraphe VDI import), on trouve tout ce qu’il nous faut pour “crafter” notre requête cURL.

A minima, on va avoir besoin de UUID de notre storage. Pour rappel, vous pouvez trouver ça dans l’UI.

Si vous avez la flemme, vous pouvez aussi utilisez l’API REST pour récupérer les IDs des storages avec la requête suivante :

curl \
 -k -b authenticationToken=xxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxx \
 https://@IP.Xen.Orchestra/rest/v0/srs\?fields=name_label
[
 ...
 {
 "name_label": "Local storage",
 "href": "/rest/v0/srs/bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb"
 }
]

Depuis votre machine Proxmox VE (ou tout autre machine ayant directement accès au disque à exporter/importer), vous pouvez donc maintenant directement lancer la commande suivante :

~# curl -X POST -k -b authenticationToken=xxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -T toto.vhd 'https://@IP.Xen.Orchestra/rest/v0/srs/bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb/vdis?name_label=testexport.vhd' | cat

A l’issue de l’opération, vous allez récupérer l’UUID du disque sur XCP-NG, déjà disponible pour la construction de la VM côté Xen Orchestra.

Conclusion

Avec cette méthode, une fois qu’on a un token, l’opération d’export/import Proxmox VE => XCP-NG devient donc suivante :

Récupération du disque virtuel sur Proxmox VE (en gros retrouver le disque)
Transformer le disque virtuel en VHD
Importer et créer le disque dans XCP-NG via un cURL
Créer une VM dans l’UI et lui affecter le disque

C’est déjà beaucoup plus sympa si vous avez plusieurs VMs à bouger. L’axe d’amélioration suivant est, à mon avis, de créer directement la VM avec le bon disque.

A date, ce n’est pas possible avec l’API REST (vu avec Vates), mais ça serait possible avec l’API JSON-RPC (sur laquelle se base l’UI de XenOrchestra et xo-cli). Ca sera donc mes prochaines investigations ;).

D’ici là, have fun :)

Bonus - Importer des RAW directement

Depuis la toute dernière version de Xen Orchestra, il est aussi possible d’importer directement des disques au format RAW (en rajouter le paramètre “raw” dans l’appel à l’API).

Dans mon cas, c’est mon format de disques puisque tout est stocké en RAW sur mon storage ZFS Proxmox VE, donc en théorie on peut sauter une étape de plus, à savoir :

Transformer le disque virtuel en VHD

Avec la requête suivante :

curl -X POST -k -b authenticationToken=xxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx -T toto.img 'https://@IP.Xen.Orchestra/rest/v0/srs/bbbbbbbb-bbbb-bbbb-bbbb-bbbbbbbbbbbb/vdis?raw&name_label=testexport.raw' | cat

Attention aux limitations, cependant :

Après le soucis du raw c’est que tu vas pas pouvoir profiter du copy on write, donc exit les snapshots (en l’état actuelle de la stack de storage, smapiv1)

Migrer une VM de Proxmox VE vers XCP NG

Sun, 24 Jul 2022 12:00:00 +0000

Retour de la virtualisation

Ca fait quelques mois que je n’ai pas parlé de virtualisation donc forcément, ça me démange un peu ;).

Si vous suivez ce blog depuis quelque temps, vous savez pourtant que j’ai pas mal roulé ma bosse avec Proxmox VE, un OS clé en main de virtualisation KVM (mais aussi de containerisation LXC, on en parle tellement peu). Sans aller jusqu’à dire que j’en ai fait le tour (a-t-on jamais fait le tour d’une techno ?), je commence à manquer de choses à tester avec mon lab perso.

L’an dernier, j’ai discuté avec les équipes de Vates SAS à OSXP 2021, une boite qui publie une autre distribution open source dédiée à la virtualisation : XCP-NG (mais basée sur XenServer).

J’en avais déjà entendu parler sur Twitter (coucou Cécile) donc j’étais un peu curieux. Mais j’étais aussi un peu sceptique, ma dernière expérience de XenServer datant de 2011.

Dans cet article, je ne vais pas rentrer dans une comparaison des fonctionnalités ni des avantages et inconvénients de XCP-NG par rapport à Proxmox VE. Je n’ai pas encore assez testé pour me faire une idée pertinente (ça viendra).

En revanche, je peux vous donner un premier avant goût de la solution via un petit tuto pour vous aider à migrer des VMs de l’un à l’autre, si jamais l’envie vous prend de tester.

Prérequis

Dans ce tutoriel, je pars du principe que vous avez :

d’un côté, une machine virtuelle QEMU, hébergée par un Proxmox VE, à copier/migrer
de l’autre, un serveur sous XCP-NG, dans le même LAN, gérée par XenOrchestra (l’équivalent du vCenter de VMware, pour ceux à qui ça parle)

Note: sauf erreur de ma part, on a pas de solution clé en main pour migrer un container LXC vers XCP-NG (même si XenServer gère les containers Xen, aussi appelé virtualisation PV). Trouver comment migrer ces workloads LXC sera peut-être l’objet d’un prochain article.

Pour le reste du tutoriel, on va grosso modo suivre la documentation officielle disponible ici, mais avec quelques modifs et surtout un peu plus de détails.

Option ZFS

Note: J’installe mes serveurs Proxmox VE avec ZFS comme stockage. Ca a plein d’avantages, notamment celui de me donner la possibilité de faire, à peu de frais, un PRA avec une réplication asynchrone des machines virtuelles de mon cluster. Cela induit par contre une petite difficulté complémentaire (vous allez voir c’est léger). Vous pouvez sauter cette étape si vous n’utilisez pas ZFS.

Pour rappel (je ferai aussi un article dédié à ça), avec ZFS j’ai 2 types de disques.

# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 213G 15.9G 112K /rpool
rpool/ROOT 6.32G 15.9G 96K /rpool/ROOT
rpool/ROOT/pve-1 6.32G 15.9G 6.32G /
rpool/data 2.84G 15.9G 2.84G /rpool/data
rpool/subvol-201-disk-0 3.43G 4.57G 3.43G /rpool/subvol-201-disk-0
rpool/subvol-301-disk-0 604M 15.9G 604M /rpool/subvol-301-disk-0
rpool/vm-100-disk-0 3.79G 15.9G 3.79G -
rpool/vm-213-disk-0 184G 148G 38.2G -

Des disques de type “Filesystem” qui sont directement montés à la racine de mon espace de stockage ZFS (chez moi /rpool, mais on a aussi /tank comme convention chez les aficionados de ZFS) pour les containers LXC.

# zfs get type rpool/subvol-301-disk-0
NAME PROPERTY VALUE SOURCE
rpool/subvol-301-disk-0 type filesystem -
# zfs get mountpoint rpool/subvol-301-disk-0
NAME PROPERTY VALUE SOURCE
rpool/subvol-301-disk-0 mountpoint /rpool/subvol-301-disk-0 default

Pour les VMs KVM/QEMU en revanche, je ne peux pas directement trouver un fichier toto.raw ou toto.qcow2 dans l’arborescence /rpool. Côté ZFS, ces volumes sont des volumes de type “volume” (lol).

Mais c’est un détail, car c’est presque encore plus facile puisqu’on peut aller directement dans /dev/zvol/rpool et les retrouver en tant que “special file” dans /dev.

ls -l /dev/zvol/rpool/vm-100*
lrwxrwxrwx 1 root root 10 Jul 23 02:00 /dev/zvol/rpool/vm-100-disk-0 -> ../../zd16
lrwxrwxrwx 1 root root 12 Jul 23 02:00 /dev/zvol/rpool/vm-100-disk-0-part1 -> ../../zd16p1
lrwxrwxrwx 1 root root 12 Jul 23 02:00 /dev/zvol/rpool/vm-100-disk-0-part2 -> ../../zd16p2
lrwxrwxrwx 1 root root 12 Jul 23 02:00 /dev/zvol/rpool/vm-100-disk-0-part5 -> ../../zd16p5

Dans l’étape suivante, /dev/zvol/rpool/vm-100-disk-0 remplacera donc notre image disque “input” (toto.img).

Générer un VHD

Souvent sous Proxmox, vous allez avoir des disques au format RAW ou au format QCOW2.

Dans les deux cas, XCP-NG n’accepte pas ces formats. Heureusement, l’utilitaire qemu-img, inclus dans notre distribution de Proxmox VE sait faire les conversions.

Dans le cas d’un disque RAW :

qemu-img convert -f raw toto.img -O vpc toto.vhd

Dans le cas d’un disque QCOW2 :

qemu-img convert -f qcow2 toto.qcow2 -O vpc toto.vhd

Avant d’importer le VHD dans XCP-NG

La partie un peu moins “fun” de la procédure est qu’on doit faire une partie des actions en GUI (si on suit la doc, mais je teaserai qu’on peut faire mieux en fin d’article).

La première chose qu’on va devoir faire, c’est aller dans la WebUI Xen Orchestra pour retrouver notre espace de stockage et créer manuellement un disque.

Il faut aller retrouver la liste de nos espaces de stockages (le plus simple, c’est de passer par “home”), puis, dans cet espace, créer un nouveau disque. Prenez garde à le créer de la bonne taille, en faisant attention à la différence Go/Gio. La documentation officielle conseille d’ajouter 1 Go de marge pour éviter ce genre de problématiques, mais je n’en ai pas eu besoin lors de mes tests.

Note: chaque disque et chaque “datastore” a son propre UUID. Ici, j’ai souligné en rouge celui du datastore “Local”, il nous servira plus tard (quand on passe la souris dessus, XOA nous propose de le copier dans le presse-papier).

Une fois le disque créé à la bonne taille, on récupère son UUID aussi.

VHD vers XCP-NG

Maintenant qu’on a d’un côté un VHD valide, et de l’autre un disque dur virtuel vide prêt à accueillir les données, on peut se lancer !

On envoie le VHD sur le serveur XCP-NG (via scp ou un montage NFS, par exemple) et on se connecte dessus en SSH.

Si on est pas confiant, on peut tester que le VHD est valide sur XCP-NG grâce à l’utilitaire suivant :

# vhd-util check -n /nfs/toto.vhd
 /nfs/toto.vhd is valid

Ensuite, on utilise le binaire xe qui permet d’interagir en CLI avec XCP-NG pour lancer l’import :

# xe vdi-import filename=/nfs/toto.vhd format=vhd --progress uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
 [|] ######################################################> (100% ETA 00:00:00)

On aura évidemment remplacé le paramètre uuid=aaaa par l’UUID du disque virtuel, que je vous ai demandé de récupérer plus tôt !

Créer la VM

Normalement, à l’issue de l’opération, on a un disque tout beau tout propre. La dernière étape est de créer une VM et à lui attacher ce disque.

Là encore, on peut repartir de “Home” puis aller dans le menu VM.

Note: pour passer le menu de création de VM, il faut impérativement choisir soit ISO/DVD ou PXE dans Install settings, sinon CREATE est grisé. J’ai également supprimé le disque par défaut proposé par le wizard (puisqu’on va lui en attacher un) et dans Advanced, j’ai décoché Boot VM after creation puisque de toute façon je dois lui attacher le disque avant de booter.

Une fois créé, on clique sur la VM pour lui attacher le disque qu’on a importé.

On peut maintenant booter la VM !

Lors du redémarrage, la seule chose que j’ai eu à changer était la configuration réseau, un peu différente entre mon cluster Proxmox VE et mon lab XCP-NG, ainsi que le nom d’interface qui était différent suite au passage à Xen (ens18 => eth0).

J’ai également ajouté le “Management agent” pour bénéficier d’infos dans l’UI (et probablement d’autres trucs chouettes que je n’ai pas encore exploré).

Conclusion

Voilà pour ces premiers pas avec XCP-NG. Comme vous avez pu le constater, l’opération nécessite plusieurs étapes, dont certaines peuvent être améliorées (notamment l’automatisation de certaines tâches côté XCP-NG grâce à l’API, on en reparlera, car j’ai déjà quelques résultats).

Cependant, ça permet déjà de se faire une première impression et de se familiariser avec les menus.

Dans les semaines qui viennent, je vais continuer de jouer avec, histoire de me faire une opinion un peu plus construite de XCP-NG (notamment par rapport à ce que je fais avec Proxmox). S’il y a des points que vous voulez que je creuse en particulier, n’hésitez pas à me “ping” sur les divers réseaux sociaux pour m’en parler.

D’ici là, have fun :)

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.

Créer un VPN distribué avec Tinc

Mon, 17 Feb 2020 07:30:00 +0000

Faire un VPN Tinc fullmesh sans monter un gros réseau IPSec

Un des gros problèmes que j’ai rapidement eu à régler lorsque j’ai voulu monter des clusters de serveurs Proxmox VE chez des providers de serveurs physiques, c’est la façon dont est gérée le clustering dans PVE.

Les concepteurs de PVE ne veulent pas que l’on monte des clusters sur Internet et mettent volontairement le plus de bâtons dans les roues pour vous empêcher de le faire. J’exagère à peine.

En version 5.x, PVE se basait sur la version 2 de corosync par multicast (bloqué par tous les providers) et qu’en v6.x, on nous bride en demandant explicitement un sous réseau LAN dédié, autant dire qu’on est pas aidé.

OpenVPN vs Tinc

Une solution que j’ai expérimenté est de monter un serveur OpenVPN sur un des serveurs et de connecter les autres dessus. J’ai d’ailleurs fait un tuto là dessus pour PVE.

Cette approche n’est pas optimale : si on a 2 machines, c’est bon, mais si on en a 3 ou plus, on se retrouve soit avec un SPOF, soit à devoir monter un maillage complexe de couples serveur-client. Au delà de 3, c’est pratiquement ingérable.

Au contraire, Tinc est un logiciel libre (GPLv2) permettant de monter des VPNs multipoints (full mesh routing) entre des machines sur Internet. Tinc est prévu pour notre cas d’usage !

le vrai logo de Tinc (la photo en haut du blog c’est Supercopter, of course)

On sécurise

Comme tout service “ouvert” sur Internet, il est évidemment nécessaire de faire du firewalling pour bloquer le trafic malveillant. Pour information, Tinc utilise le port 655 en TCP et UDP, que vous devrez donc ouvrir dans les deux sens entre l’ensemble de vos serveurs, mais bloquer pour le reste d’Internet.

A noter, ce n’est pas confirmé mais la page principale de Tinc indique qu’il est possible que ce logiciel (tout comme OpenVPN, Wireguard et IPSec) soit vulnérable à la CVE-2019-14899.

On l’installe et on le configure

On va devoir installer le package/binaire sur toutes les machines du VPN. Pas trop de soucis de ce côté, tinc est multiplateforme (Windows aussi) et est packagé dans de nombreuses distrib Linux. Sur les dépôts Debian, tinc est présent sans souci et j’imagine que ça sera le cas pour d’autres distribs aussi.

apt install tinc

Une fois installé, on peut créer notre VPN. Pour déclarer un VPN, il faut ajouter le nom de celui ci dans un fichier de configuration global :

echo "vpnzwindler" >> /etc/tinc/nets.boot

On créé ensuite un répertoire du même nom, contenant lui même un dossier hosts.

mkdir -p /etc/tinc/vpnzwindler/hosts

Dans ces dossiers, on va créer fichier de configuration, /etc/tinc/vpnzwindler/tinc.conf. Ce fichier va nous permettre de décrire le node courant et qui doit se connecter à qui.

Name = node01
AddressFamily = ipv4
Address = 1.1.1.1
Device = /dev/net/tun
Mode = switch
ConnectTo = node02
ConnectTo = node03
ConnectTo = node04
[...]

Dans les informations importantes, Name va être le nom (arbitraire) du node pour tout le VPN, Address représente l’adresse IP publique de votre node, et ConnectTo, la liste des autres Names des autres nodes.

A partir de là, on peut demander à tinc de nous générer des couples clé publique/clé privée pour tous nos serveurs. Sur tous les nodes du VPN, lancer :

echo -e '\n\n' | tincd -n vpnzwindler -K4096

Si tout se passe bien et que tous les fichiers de conf et dossiers ont été créés correctement, tinc devrait créer un couple clé privée/clé publique, puis créer un fichier /etc/tinc/vpnzwindler/hosts/node01 (sur celui dont le Name est node01).

Envoyez (par scp par exemple) l’ensemble des fichiers dans le dossier hosts sur tous les serveurs. Maintenant, tous les VPNs sauront quelle IP publique contacter et avec quel clé authentifier le trafic.

Autre méthode : tinc invite / tinc join

Une feature sympa de tinc, mais seulement en 1.1 (la dernière version), est la possibilité d’ajouter des nodes à un VPN existants via une simple commande tinc invite (voir la doc).

Je ne l’ai pas testée mais a priori tinc créé une URL qui permet d’inviter n’importe qui et de configurer son node avec un tinc join.

The whole URL is around 80 characters long and looks like this: server.example.org:12345/cW1NhLHS-1WPFlcFio8ztYHvewTTKYZp8BjEKg3vbMtDz7w4

Configuration du réseau de l’OS

Maintenant qu’on a tous les prérequis, on peut configurer l’aspect réseau de notre VPN. Ça dépend de votre distribution bien sûr (où dans le cas de PVE, si vous utilisez OpenVSwitch ou pas par exemple). Dans le cas d’une Debian récente, on va gérer tout ça avec ip.

Pour gérer cette partie, Tinc va vous demander de créer 2 scripts. Un tinc-up.sh et un tinc-down.sh, respectivement pour le démarrage et l’extinction de l’interface VPN.

cat /etc/tinc/vpnzwindler/tinc-up
#!/bin/bash
/sbin/ip link set vpnzwindler up
/sbin/ip addr add 10.0.0.1/24 dev vpnzwindler
/sbin/ip route add 10.0.0.0/24 dev vpnzwindler
cat /etc/tinc/vpnzwindler/tinc-down
#!/bin/bash
/sbin/ip link set vpnzwindler down
chmod +x tinc-*

Rien de bien compliqué ici, on demande au binaire ip de créer une interface vpnzwindler. Puis on lui affecte l’IP virtuelle 10.0.0.1 (notre node01). Enfin d’ajouter une route pour que tout le trafic du VPN passe par cette interface.

On le démarre

Dernière étape, on va demander à systemd de nous démarrer le vpn qu’on vient de créer dès le démarrage de la machine.

systemctl daemon-reload
systemctl enable tinc@vpnzwindler
systemctl start tinc@vpnzwindler

Et voilà !!! Vous avez maintenant un VPN multipoint simple et efficace !

root@node01 ~ # ping node02
PING node02 (10.0.0.2) 56(84) bytes of data.
64 bytes from node02 (10.0.0.2): icmp_seq=1 ttl=64 time=17.1 ms

Un cluster Proxmox VE avec seulement 2 machines !

Fri, 11 Oct 2019 06:40:55 +0000

Depuis le temps que je vous parle de clusters et de Proxmox (en gros, depuis 2015), ou même de clusters tout court, j’ai pu vous en mettre des tartines sur le fait qu’il ne faut pas faire des clusters avec un nombre pair de machines (ou tout autre cas défavorable dans lequel deux moitiés d’un cluster peuvent se retrouver isolées l’une de l’autre). Le split brain, c’est pas bon pour votre Karma, croyez moi sur parole (ou allez voir vous même).

Ça me rappelle la fois où un “““architecte””” de chez Datacore était venu nous expliquer que sa solution de stockage à 2 pattes ne POUVAIT PAS avoir de split brain (alors que si, les ingés du support ont du repasser par derrière pour nous dire que “oui désolé vous avez évidemment raison c’est un cas possible” #LOL).

Bref, et donc à force d’en parler, il fallait bien quand même que je donne un jour la solution pour le faire quand même, mais proprement. Sans trop de surprise, Corosync, la librairie qui gère les clusters Linux depuis qu’on a arrêté de faire des horreurs avec heartbeat (ou pire : cman+rgmanager, achevez moi), gère évidemment les deux possibilités :

Gérer soit même le membre prioritaire en cas de split brain avec un poids (ça on va pas en parler mais sachez que c’est possible)
Ajouter un vote externe pour obtenir un quorum (comme tous les vrais logiciels qui font du clustering un peu sérieux quoi)

Limitations du “Corosync External Vote” dans PVE

La petite déception du jour viendra surtout du fait que, si la documentation de Proxmox VE indique clairement que l’option est supportée, en réalité, le support se limite aux fonctions natives de corosync, et encore pas toutes.

Pas moyen de voir notre vote externe dans l’interface de Proxmox VE par exemple. A priori, le support des quorum disk n’est plus assuré non plus depuis la version 4 de PVE.

Ensuite, il faut aussi savoir que pour l’instant, seul l’utilisation d’une IP pour renseigner le quorum serveur est possible. On ne peut pas utiliser un FQDN, ce qui me parait dingue comme limitation en 2019, mais bon…

Ces deux points mis de côté, vous allez voir, ce n’est pas sorcier. La procédure est en bonne partie détaillée dans la documentation.

Prérequis

Pour ce tutoriel, vous allez donc avoir besoin de 2 machines (a minima), déjà en cluster. Si vous ne les avez pas déjà, je vous invite à regarder les moults tutoriels précédents, en particulier celui sur la mise en place d’un cluster Proxmox VE 6 (le plus récent).

Vous allez aussi avoir besoin d’un serveur tiers (un bout de VM ou de container quelque part, en dehors de vos 2 (ou tout autres quantité de machines étant localisées dans 2 endroits distincts dont il existe un risque qu’ils puissent subitement “ne plus se voir”, d’un point de vue réseau, induisant le fameux split brain tant redouté).

Fun fact, il y a une page de wiki pour faire la même chose à la main avec un RPi.

Ce serveur tiers n’a pas besoin de faire fonctionner Proxmox (c’est même plutôt mieux d’ailleurs car PVE n’a aucune plus-value ici). Ça doit juste être une distrib linux capable d’installer un démon corosync qnetd. Ce serveur, nous l’appellerons “quorum”, par abus de langage grossier ;-).

Configuration

Sur le serveur quorum, installer corosync qnetd. Sur une Debian like, vous avez de la chance, il existe un package présent dans les dépôts par défaut, et il faut simplement faire un :

sudo apt install corosync-qnetd

Ensuite, sur tous les serveurs Proxmox VE de notre cluster, on va installer le package corosync-qdevice, qui va leur permettre d’interroger le quorum.

sudo apt install corosync-qdevice

Sur le serveur quorum de nouveau, ajouter la clé SSH d’un des serveurs PVE (un seul suffit). Une fois que c’est fait, connecter le cluster au quorum.

Cela va sans dire, mais faire la commande depuis le serveur dont on vient d’ajouter la clé, pas l’autre hein ;-p. Et remplacez par l’IP du serveur quorum !

pvecm qdevice setup <QDEVICE-IP>
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
The authenticity of host 'x.x.x.x' can't be established.
ECDSA key fingerprint is SHA256:LPaaaaaaaaaaaaaaaaaPZjaIg.
Are you sure you want to continue connecting (yes/no)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.
(if you think this is a mistake, you may want to use -f option)

Je met volontairement une grosse partie de la trace car comme ça on peut parler de ce que fait la commande pvecm qdevice setup x.x.x.x.

Comme vous pouvez le constater, cette commande semble assez similaire à celle pour créer manuellement le cluster. A savoir, elle commence déjà par copier les clés SSH sur le serveur distant, histoire que tout le monde puisse discuter ensemble en SSH.

INFO: initializing qnetd server
Certificate database (/etc/corosync/qnetd/nssdb) already exists. Delete it to initialize new db
INFO: copying CA cert and initializing on all nodes
node 'pve01': Creating /etc/corosync/qdevice/net/nssdb
password file contains no data
node 'pve01': Creating new key and cert db
node 'pve01': Creating new noise file /etc/corosync/qdevice/net/nssdb/noise.txt
node 'pve01': Importing CA
[...]

Ensuite, on initialise, sur tous les nodes du cluster, le qdevice, qui va permet au node de communiquer avec le quorum. Là j’élude un peu car ça parle beaucoup de certificats et de clés qui sont échangées.

INFO: copy and import pk12 cert to all nodes<br>INFO: add QDevice to cluster configuration
INFO: start and enable corosync qdevice daemon on node 'pve01'...
Synchronizing state of corosync-qdevice.service with SysV service script with /lib/systemd/systemd-sysv-install.

Normalement, si tout se passe bien, vous devriez en arriver là, une fois que tout le monde s’est bien échangé ses certificats, clés et autres joyeusetés crytographiques.

Une petite commande pour vérifier l’état du bazar :

$ pvecm status
Quorum information
------------------
Date: Mon Aug 26 14:49:14 2019
Quorum provider: corosync_votequorum
Nodes: 2
Node ID: 0x00000002
Ring ID: 1/1271796
Quorate: Yes
Votequorum information
----------------------
Expected votes: 3
Highest expected: 3
Total votes: 3
Quorum: 2
Flags: Quorate Qdevice
Membership information
----------------------
Nodeid Votes Qdevice Name
0x00000001 1 A,V,NMW 10.0.0.1
0x00000002 1 A,V,NMW 10.0.0.2 (local)
0x00000000 1 Qdevice

Ça, c’est le genre de choses que j’attends d’un logiciel de clustering digne de ce nom. D’une simple commande, on peut avoir

le nombre de nodes
l’ID du node courant
le nombre de votes actuels, attendus, et minimum pour que le cluster soit “QUORATE”
et enfin l’état de tout le cluster.

Ici, avec 2 nodes + le quorum, on a bien 3 votes. Tant qu’on a 2 votes, on a le quorum, CQFD.

Dans ce cas de figure, si on perd un nœud OU le quorum, on a toujours 2 votes et le cluster doit continuer à fonctionner “normalement”.

Et c’est ce qu’on va vérifier !

On casse un nœud, pour voir

Normalement, si on a pas le serveur quorum, tout devrait être brisé (comme dirait Medieval Ops).

En gros les VMs doivent continuer à tourner, mais toute opération (démarrage de VM, modification quelconque) doit être bloquée (pour éviter de démarrer la même VM à 2 endroits et pleurer pour recoller les morceaux).

Or ici dès que l’hôte n’est plus joignable, le nœud survivant le détecte, et comme le quorum ne voit plus lui non plus qu’un seul nœud, indique au dernier qu’il peut continuer sa vie comme si de rien n’était (c’est glauque…).

$ pvecm status
Quorum information
------------------
Date: Thu Aug 29 11:10:31 2019
Quorum provider: corosync_votequorum
Nodes: 2
Node ID: 0x00000002
Ring ID: 1/1271820
Quorate: Yes
Votequorum information
----------------------
Expected votes: 3
Highest expected: 3
Total votes: 2
Quorum: 2
Flags: Quorate Qdevice
Membership information
----------------------
Nodeid Votes Qdevice Name
0x00000002 1 A,V,NMW 10.0.0.2 (local)
0x00000000 1 Qdevice

Le nombre de vote passe bien à 2 (mais comme on est toujours égal à quorum c’est bon) et le node 1 a bien disparu :

Et la petite déception, pas de visualisation en console du vote du quorum, malgré la mention “Quorate”

Mais bon, c’est quand même cool que ça marche, et en vrai c’est bien l’essentiel ;)

Bonus : Erreur insserv: FATAL: service corosync has to be enabled

Si vous rencontrez l’erreur suivante :

insserv: FATAL: service corosync has to be enabled to use service corosync-qdevice

Allez supprimer le fichier d’init SysV corosync sur tous les hôtes

rm /etc/init.d/corosync-qdevice
systemctl enable corosync-qdevice
systemctl start corosync-qdevice

Source : https://forum.proxmox.com/threads/setting-up-qdevice-fails.56061/

[Tutoriel] Faire un petit cluster Proxmox chez Kimsufi avec OpenVPN

Tue, 29 Aug 2017 11:40:23 +0000

C’est la rentrée, vous reprendrez bien un petit article sur Proxmox !

Ou plutôt, c’est bientôt la rentrée et il est grand temps que je solde les articles qui trainent dans mes tiroirs car je moi pars bientôt en vacances.

« Et tout le monde s’en fout »

J’ai donc rédigé un tutoriel pas à pas pour vous montrer qu’on peut créer rapidement un petit cluster sous Proxmox avec deux petites machines chez un hébergeur pas cher type Kimsufi (j’avais justement deux machines car j’ai profité d’une promo chez eux), sans que les machines soient dans le même sous réseau IP.

Si vous ne connaissez pas Proxmox, je vous renvoie vers les articles que M4vr0x ou moi avons écris sur le sujet.

Pourquoi un tutoriel pour les clusters Proxmox ?

Vous allez me dire, pourquoi un énième article sur le sujet ? La documentation officielle, même si elle est en anglais, est assez claire et il existe plusieurs tutoriels en Français pour le faire.

Ah ah oui… mais la distinction c’est « faire un cluster de machines Proxmox, sans que les machines soient dans le même sous réseau IP » !

Et à moins que vous ayez une chance de ouf’, il est peu probable que vos deux Kimsufi le soient.

Petit rappel des prérequis pour faire un cluster Proxmox

Deux serveurs physiques (au minimum)
Port 22 accessible au moins dans un premier temps pour configurer le cluster
Que la latence d’un serveur à l’autre soit inférieure à 2ms
Que les deux serveurs soient capables de communiquer en multicast

Et là, c’est le drame !

Jusqu’à ce qu’on arrive à la dernière ligne, nous étions sereins.

Si jamais vous avez deux serveurs chez Kimsufi (ou autre) et que vous essayez de les faire communiquer en multicast, vous allez vite vous rendre compte que le multicast est bloqué !

Impossible donc de faire fonctionner correctement votre cluster Proxmox (basé sur corosync) sans cela. Vous pouvez mettre tous les autres tutos à la poubelle ;-).

Bidouille & compagnie, et les risques encourus

Si vous vous sentez la curiosité de monter quand même un cluster sur votre Kimsufi, on va contourner le problème en montant un VPN entre les deux machines. M4vr0x a déjà détaillé l’utilisation d’OpenVPN avec pfSense sur Proxmox, mais on n’était pas dans le même contexte.

On ne peut pas se baser là dessus dans le cas présent car Proxmox a la fâcheuse manie de réinitialiser toute la configuration lorsqu’on démarre le mode « cluster » .

ATTENTION !!!
Oui, ça veut bien dire que vous ne verrez plus ni vos VMs existantes, ni le stockage que vous avez précédemment configuré…
Les VMs continuent d’exister et sont accessibles tant que vous ne rebootez pas. Le stockage aussi. Ce n’est juste plus visible.

Vous l’avez deviné, c’est du vécu : j’ai flingué ma configuration existante lorsque j’ai initialisé le cluster.

Mise en réseau

Maintenant que vous savez ce que vous risquez, on va donc configurer tout ça à la main, directement en SSH sur les machines Proxmox :

Sur le serveur 1

La première chose à faire est simplement d’installer openvpn, ainsi qu’un utilitaire qui s’appelle easy-rsa qui va nous faciliter la tâche de configuration.

apt-get update
apt-get upgrade
apt-get install openvpn easy-rsa

Une fois que c’est fait, on copie les templates de config et les scripts de easy-rsa et on modifie les valeurs par défaut par nos propres valeurs.

cp -ai /usr/share/easy-rsa/ /etc/openvpn/easy-rsa/
cd /etc/openvpn/easy-rsa/
vi vars
[...]
# These are the default values for fields
# which will be placed in the certificate.
# Don't leave any of these fields blank.
export KEY_COUNTRY="FR"
export KEY_PROVINCE="Aquitaine"
export KEY_CITY="Bordeaux"
export KEY_ORG="mondomaine.tld"
export KEY_EMAIL="key@mondomaine.tld"
export KEY_OU="key"

Sourcez le fichier nouvellement rempli :

. ./vars

Nettoyez les clés provenant d’anciennes itérations de l’outil (pas nécessaire si c’est la première fois mais si vous n’en êtes pas au premier coup, ça peut éviter des erreurs bêtes) :

./clean-all

Et enfin, on génère l’ensemble des clés dont vous aurez besoin (les CA, les clés serveurs, les clés clientes et la diffie helmann) :

./build-ca
./build-key-server serveur1.mondomaine.tld
./build-key serveur2.mondomaine.tld
./build-dh

Normalement tout devrait se passer sans encombre et vous devriez avoir plusieurs certificats nouvellement créés. On va copier les certificats du serveur OpenVPN dans le dossier /etc/openvpn, puis envoyer les certificats du client par SCP :

cp keys/ca.* keys/serveur1.mondomaine.tld.* keys/dh2048.pem /etc/openvpn/
scp keys/ca.crt keys/serveur2.mondomaine.tld.crt keys/serveur2.mondomaine.tld.key serveur2.mondomaine.tld:/etc/openvpn/

Maintenant qu’on a tout, on peut créer le fichier de configuration. Ici rien de bien compliqué à comprendre :

On créé un fichier server.conf qui va monter un VPN sur le port 1194 en UDP via un device de type TAP (j’y reviendrai) et on force le réseau en 10.9.0.0/24
On donne le chemin vers tous les certificats qu’on vient de créer
On ajoute un script « up » et un script « down », avec l’option script-security à « 2 » sinon ça ne fonctionnera pas

cat > /etc/openvpn/server.conf << EOF
# [server.conf]
port 1194
proto udp
#dev tun
dev tap
ca /etc/openvpn/ca.crt
cert /etc/openvpn/serveur1.mondomaine.tld.crt
key /etc/openvpn/serveur1.mondomaine.tld.key
dh /etc/openvpn/dh2048.pem
server 10.9.0.0 255.255.255.0
ifconfig-pool-persist ipp.txt
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status.log
verb 3
script-security 2
up /etc/openvpn/add_multicast_route
down /etc/openvpn/add_multicast_route
EOF

Bon et qu’est ce qu’il contient ce fameux script ? Et bien pour l’instant il se contente simplement d’ajouter et de supprimer une route sur les serveurs qui va router « à la main » tout le traffic multicast non par vers la gateway, mais vers le VPN ! Et c’est comme ça qu’on va contourner le blocage des flux multicast entre nos deux Kimsufi !

vi /etc/openvpn/add_multicast_route
#!/bin/bash
#
# Add a route to force multicast through VPN
[ "$script_type" ] || exit 0
case "$script_type" in
up)
route add -net 224.0.0.0 netmask 240.0.0.0 dev $1
;;
down)
route del -net 224.0.0.0 netmask 240.0.0.0 dev $1
;;
esac
chmod +x /etc/openvpn/add_multicast_route

On termine par démarrer (et activer au démarrage) le serveur OpenVPN :

systemctl enable openvpn
systemctl start openvpn

Dans ce cas là, comme on est pas en réel mode client serveur ou l’ensemble du traffic client est routé sur le serveur on a pas besoin de modifier le paramètre kernel « ip_forward » :

sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

Aparté tun vs tap

Les plus aguerris d’entre vous auront remarqués que j’ai volontairement choisi de ne pas utiliser une interface virtuelle de type tun (par défaut dans OpenVPN) mais une interface de type tap.
Historiquement, ce type d’interface est connu pour ne pas fonctionner correctement en multicast, ce qui est ici notre but principal.

A priori c’est censé être résolu depuis longtemps, mais chez moi ça n’a pas marché alors que dès que j’ai switché sur tap ça a fonctionné directement. Je vous engage à regarder si ça vous intéresse. J’ai mis un lien vers une discussion à ce sujet sur le forum d’OpenVPN en fin d’article.

Sur le serveur 2

Maintenant que le serveur est configuré, au tour du client. Même topo, à ceci près qu’on ne va pas générer de certificats (c’est déjà fait).

apt-get update
apt-get upgrade
apt-get install openvpn
cat > /etc/openvpn/client.conf << EOF
# [client.conf]
client
#dev tun
dev tap
proto udp
remote @IP_publique_du_serveur1 1194
resolv-retry infinite
nobind
persist-key
persist-tun
mute-replay-warnings
ca /etc/openvpn/ca.crt
cert /etc/openvpn/serveur2.mondomaine.tld.crt
key /etc/openvpn/serveur2.mondomaine.tld.key
ns-cert-type server
comp-lzo
verb 3
script-security 2
up /etc/openvpn/add_multicast_route
down /etc/openvpn/add_multicast_route
EOF

vi /etc/openvpn/add_multicast_route
#!/bin/bash
#
# Add a route to force multicast through VPN
[ "$script_type" ] || exit 0
case "$script_type" in
up)
route add -net 224.0.0.0 netmask 240.0.0.0 dev $1
;;
down)
route del -net 224.0.0.0 netmask 240.0.0.0 dev $1
;;
esac
chmod +x /etc/openvpn/add_multicast_route
systemctl enable openvpn
systemctl start openvpn

Facile, hein ?

Sur tous les nœuds

Pour s’assurer que tout fonctionne comme ça devrait (ou pour déboguer), vous pouvez autoriser temporairement la réponse à l’ICMP sur multicast. Un simple ping permettra de s’assurer que les deux serveurs se voient bien :

sysctl net.ipv4.icmp_echo_ignore_broadcasts=0
root@serveur1:/etc/pve# ping 224.0.0.1
PING 224.0.0.1 (224.0.0.1) 56(84) bytes of data.
64 bytes from 10.9.0.1: icmp_seq=1 ttl=64 time=0.019 ms
64 bytes from 10.9.0.2: icmp_seq=1 ttl=64 time=1.07 ms (DUP!)
64 bytes from 10.9.0.1: icmp_seq=2 ttl=64 time=0.020 ms
64 bytes from 10.9.0.2: icmp_seq=2 ttl=64 time=0.672 ms (DUP!)
64 bytes from 10.9.0.1: icmp_seq=3 ttl=64 time=0.020 ms
64 bytes from 10.9.0.2: icmp_seq=3 ttl=64 time=0.619 ms (DUP!)

Les deux serveurs répondent aux pings depuis l’interface du VPN, on est bons ! Du coup vous pouvez re-désactiver la réponse aux broadcasts avec la commande suivante :

sysctl net.ipv4.icmp_echo_ignore_broadcasts=1

Pour faciliter la résolution de noms dans le cluster, vous pouvez ajouter les IPs VPN des serveurs dans le fichier /etc/hosts.

vi /etc/hosts
[...]
10.9.0.1 serveur1-vpn
10.9.0.2 serveur2-vpn

Création du cluster

Sur le nœud 1

En théorie, si on lit la documentation il suffit simplement de faire “pvecm create mycluster” et le tour est joué.

STOOOOP !

Si vous le faite, ça ne fonctionnera pas (et vous pourrez vous en sortir avec cet article). Pourtant tout est correct au niveau des prérequis : les nœuds fonctionnent bien et que le multicast est correctement routé via le VPN. Un coup d’œil au fichier de configuration de corosync nous en apprendra plus :

cat /etc/pve/corosync.conf
logging {
debug: off
to_syslog: yes
}
nodelist {
node {
name: serveur2
nodeid: 2
quorum_votes: 1
ring0_addr: serveur2
}
node {
name: serveur1
nodeid: 1
quorum_votes: 1
ring0_addr: serveur1
}
}
quorum {
provider: corosync_votequorum
}
totem {
cluster_name: mycluster
config_version: 4
ip_version: ipv4
secauth: on
version: 2
interface {
bindnetaddr: @IP_publique_du_serveur1
ringnumber: 0
}
}

En fait le problème ici, c’est que l’adresse bindée bindnetaddr: n’est pas bonne. Si vous n’avez pas lu mon gros “STOOOOP”, il faut tout réinitialiser car il est assez compliqué de modifier un cluster existant sous Proxmox (a priori pas possible proprement mais je vous donnerai la tips dans un prochain article).

Voilà la bonne commande à taper :

pvecm create mycluster -bindnet0_addr 10.9.0.1 -ring0_addr serveur1-vpn
Corosync Cluster Engine Authentication key generator.
Gathering 1024 bits for key from /dev/urandom.
Writing corosync key to /etc/corosync/authkey.

Sur le noeud 2

En théorie, là aussi c’est très facile. Il suffit de faire “pvecm add serveur2-vpn” pour que l’hôte serveur2.mondomaine.tld rejoigne le cluster créé sur le noeud serveur1.mondomaine.tld.

Voilà ce qui va se passer si vous le faites :

pvecm add serveur1-vpn
The authenticity of host 'serveur1-vpn (10.9.0.1)' can't be established.
ECDSA key fingerprint is SHA256:VOIH2X7kTzWLUEzRPCl4431hlYnc3HCsDmzXYEs3V+g.
Are you sure you want to continue connecting (yes/no)? yes
root@serveur1-vpn's password:
copy corosync auth key
stopping pve-cluster service
backup old database
Job for corosync.service failed because the control process exited with error code.
See "systemctl status corosync.service" and "journalctl -xe" for details.
waiting for quorum...

Même principe ici. Si l’adresse ring0_addr n’est pas spécifiée explicitement, corosync va tenter de s’abonner sur une IP multicast sur l’IP de l’interface Ethernet principale. Elle ne passera donc pas pas notre VPN et le cluster ne communiquera pas en multicast !

Vous pouvez en lire plus là dessus sur ce lien.

Sur le noeud serveur2, on ajoute donc l’adresse IP (et donc l’interface) que corosync devra emprunter pour communiquer avec serveur1-vpn (via le VPN donc).

pvecm add serveur1-vpn -ring0_addr 10.9.0.2
The authenticity of host 'serveur1-vpn (10.9.0.1)' can't be established.
ECDSA key fingerprint is SHA256:oKkuOYY1pbEa1RrM0y9fWVJfnQabhUvG7la+6fZUnQ4.
Are you sure you want to continue connecting (yes/no)? yes
root@serveur2-vpn's password:
copy corosync auth key
stopping pve-cluster service
backup old database
waiting for quorum...OK
generating node certificates
merge known_hosts file
restart services
successfully added node 'serveur2' to cluster.

A partir de là, tout devrait marcher. Vous devriez avoir sur la même interface vos deux serveurs, et avoir perdu toutes vos VMs si vous n’avez pas bien lu mon avertissement ;-)

A noter : chose qui n’était pas possible entre la version 3 et la version 4 (car les deux composants n’utilisaient pas le même logiciel pour le clustering), il est possible de faire un cluster ProxMox mixant version 4 et version 5 comme le montre cette capture d’écran :

Aller plus loin : les limites d’OpenVPN

On a maintenant un cluster de 2 machines Proxmox. Pour autant, ce n’est pas idéal et ça ne suffira pas pour passer en production, notamment en cas de coupure réseau entre les deux machines (split brain). On va vite vouloir en rajouter au moins une, sinon plus.

Cependant, on sera bloqués. Les limites de cette méthode est que la configuration d’OpenVPN est en mode client-serveur. Si vous avez plus de 2 machines, vous vous rendrez vite compte que vous pouvez communiquer entre les clients et le serveurs, mais pas entre clients.

Et en gros ça ne marche pas, le 3ème noeud ne rejoindra pas le cluster car il ne peut pas joindre l’ensemble des membres et il se mettra en defaut.

Pour bien faire en conservant ce mécanisme, il va falloir monter un service VPN externe aux serveurs Proxmox, qui seront tous clients de ce service, ou alors se créer un réseau de type full mesh, par exemple avec de l’IPSec si vous êtes un maitre en Réseau/Telco.

Autant dire qu’il vaut mieux passer par un hébergeur qui permet le multicast ou qui fourni un service VPN. Ca ira plus vite…

Pve on Zwindler's Reflection

Proxmox 8.2.5 : bad scheduler ! Bad !

Début de l’enquête

Fin du mystère

Mieux migrer ses VM de Proxmox VE vers XCP NG (part 2)

Résumé des épisodes précédents

Faire mieux

Because I’m API 🎶

You token to me?

champion de cURLing

Conclusion

Bonus - Importer des RAW directement

Migrer une VM de Proxmox VE vers XCP NG

Retour de la virtualisation

Prérequis

Option ZFS

Générer un VHD

Avant d’importer le VHD dans XCP-NG

VHD vers XCP-NG

Créer la VM

Conclusion

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

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

pve6to7 OK

/boot plein

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

hwaddress pour les bridges

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

Replication ZFS HS pendant l’upgrade

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

Conclusion

Créer un VPN distribué avec Tinc

Faire un VPN Tinc fullmesh sans monter un gros réseau IPSec

OpenVPN vs Tinc

On sécurise

On l’installe et on le configure

Autre méthode : tinc invite / tinc join

Configuration du réseau de l’OS

On le démarre

Un cluster Proxmox VE avec seulement 2 machines !

Limitations du “Corosync External Vote” dans PVE

Prérequis

Configuration

On casse un nœud, pour voir

Bonus : Erreur insserv: FATAL: service corosync has to be enabled

[Tutoriel] Faire un petit cluster Proxmox chez Kimsufi avec OpenVPN

C’est la rentrée, vous reprendrez bien un petit article sur Proxmox !

Pourquoi un tutoriel pour les clusters Proxmox ?

Petit rappel des prérequis pour faire un cluster Proxmox

Bidouille & compagnie, et les risques encourus

Mise en réseau

Sur le serveur 1

Aparté tun vs tap

Sur le serveur 2

Sur tous les nœuds

Création du cluster

Sur le nœud 1

Sur le noeud 2

Aller plus loin : les limites d’OpenVPN

Sources et sujets connexes