Il y a six semaines, je déballais le MS-01 et je me disais que l’installation de Proxmox allait prendre une heure. Elle en a pris trois, dont quarante-cinq minutes à débugger une interface réseau mal nommée. Depuis, j’ai accumulé suffisamment d’erreurs intéressantes pour valoir un bilan.
Ce texte n’est pas un tutoriel. C’est ce que j’aurais voulu lire avant de commencer – avec les vraies rugosités, pas la version lissée qu’on trouve dans la documentation officielle.
Le point de départ : la machine
Le MS-01 tourne sur un i9-13900H (14 cœurs, 20 threads), 32 Go de DDR5-5600 (A-DATA), un NVMe Kingston OEM PCIe 4.0 de 1 To. Proxmox VE 8.3, hôte nommé heighliner. Le tout branché sur un TP-Link TL-SG108-M2 (switch 2.5GbE non manageable) et derrière un ZenWifi XT8 pour le routage.
Je savais que le matériel était surdimensionné pour un début. C’est volontaire : je voulais de la marge pour expérimenter sans me retrouver à la limite tout de suite. À 1189 € le bundle, c’est le budget d’un NAS de milieu de gamme – sauf que là, j’ai un hyperviseur x86 complet.
Ce que j’aurais fait différemment à l’installation
Le réseau, dès le départ
J’ai commencé avec un seul bridge vmbr0 sur l’interface physique, sans réfléchir aux VLANs. Résultat : quand j’ai voulu segmenter le réseau en VLAN Management(1), LAN(10), IoT(20), Serveurs(30), Stockage(40), j’ai dû tout reconfigurer à chaud – les conteneurs en production inclus. Ce n’est pas dramatique, mais c’est une heure de sueur inutile.
La bonne approche dès l’install : configurer vmbr0 en trunk (VLAN-aware), créer les bridges VLAN secondaires une fois pour toutes, et ne démarrer aucun service avant d’avoir la topologie réseau claire sur papier. Cinq minutes de dessin évitent beaucoup de ip addr dans la panique.
Dans Proxmox VE 8.x, cocher « VLAN Aware » sur un bridge Linux (vmbr0) ne fait rien par lui-même – il faut aussi configurer le bridge-vlan-aware yes dans /etc/network/interfaces et redémarrer le service réseau. L’UI et le fichier doivent être cohérents.
Le stockage : ZFS ou pas ?
J’ai choisi de laisser Proxmox créer rpool en ZFS sur le NVMe unique, ce qui est le défaut de l’installeur. C’est une décision raisonnable sur un NVMe rapide, mais j’aurais dû y réfléchir avant plutôt que d’accepter le défaut sans lire. ZFS sur un seul disque sans mirror n’apporte pas la redondance – il apporte les snapshots, le CoW, et ARC cache. C’est déjà utile, mais il faut savoir ce qu’on prend.
Pour le stockage NFS, le Synology DS414 est déclaré comme stockage Proxmox (pve-nfs, type NFS, path /volume1/proxmox). Il sert uniquement pour les ISO et les templates – je ne stocke pas de disques VM dessus, les performances NFS du DS414 ne le justifient pas.
L’erreur qui m’a coûté une soirée : la RAM et le swap
Trois semaines après le démarrage, j’ai remarqué que heighliner commençait à swapper. Pas beaucoup – 200-400 Mo – mais régulièrement. Le Shelly EM montrait des pics de conso qui ne correspondaient pas à l’activité visible.
Le problème : j’avais alloué les RAM des VMs de façon statique et généreuse. Ubuntu Server (VM pour les tests) : 8 Go fixes. PBS : 4 Go fixes. Total alloué aux VMs : 12 Go. Les LXC ajoutaient encore 4-5 Go de limites nominales. Le nœud Proxmox lui-même a besoin de mémoire pour le kernel, ZFS ARC, et ses propres processus. Résultat : on frôlait les 32 Go physiques en charge normale.
La solution : activer les balloon drivers sur les VMs KVM. Dans Proxmox VE, ça se configure dans les paramètres de la VM, onglet « Hardware » : on définit une RAM minimale (par exemple 1 Go pour PBS) et une RAM maximale (4 Go). Le balloon driver QEMU négocie dynamiquement entre ces deux bornes selon la pression mémoire réelle de la VM. Il faut que qemu-guest-agent soit installé dans la VM pour que ça fonctionne correctement.
# Dans la VM (Debian 12 / Ubuntu 24.04)
apt install -y qemu-guest-agent
systemctl enable --now qemu-guest-agent
Après activation des balloon drivers sur les deux VMs, le swap sur heighliner a disparu. ZFS ARC a récupéré 2-3 Go de cache supplémentaire, et les temps de réponse I/O se sont améliorés de façon perceptible (moins de cache miss sur les lectures répétées).
Ne pas activer le balloon driver sans qemu-guest-agent installé et actif dans la VM. Sans guest agent, Proxmox ne peut pas négocier la mémoire avec le kernel invité et le balloon restera bloqué à sa valeur minimale, ce qui peut provoquer des OOM kills dans la VM.
La bonne surprise : les LXC
Je sous-estimais les conteneurs LXC. Dans mon imaginaire précédent, « conteneur Linux » = Docker, et Docker = couche d’abstraction avec ses propres frictions. LXC sur Proxmox, c’est différent : c’est un namespace Linux avec un init système complet. Tu as un vrai systemd, des services qui démarrent normalement, un accès aux interfaces réseau du nœud via veth, et des performances proches du bare metal.
Pour les services qui n’ont pas besoin d’un kernel isolé – Pi-hole, Nginx Proxy Manager, Vaultwarden, Gitea, Uptime Kuma – le LXC est strictement supérieur à la VM : démarrage en 3-4 secondes contre 25-30 secondes pour une VM, consommation RAM de base divisée par 3 à 4, densité de services bien meilleure sur le nœud.
Nextcloud est la seule exception dans ma stack actuelle : je le fais tourner en LXC aussi, mais en « unprivileged container » avec ajustements des droits pour les montages NFS. C’est possible, pas trivial, et j’y reviendrai dans un article dédié.
L’état des lieux après 6 semaines
Six LXC actifs sur heighliner : Pi-hole (DNS/adblocking, LXC 101), Nginx Proxy Manager (reverse proxy, LXC 102), Vaultwarden (gestionnaire de mots de passe, LXC 103), Gitea (forge Git, LXC 104), Uptime Kuma (monitoring externe, LXC 105), Nextcloud (stockage et sync, LXC 106).
Deux VMs : Ubuntu Server 24.04 pour les tests et expérimentations (VM 201), PBS pour les sauvegardes (VM 250). PBS est décrit en détail dans l’article sur Proxmox Backup Server.
Toutes les VMs et LXC sont dans le VLAN Serveurs (30), sauf Pi-hole qui a une patte dans le VLAN LAN (10) pour être joignable depuis les clients domestiques.
PBS : mieux que prévu
Franchement, je ne m’attendais pas à ce que PBS soit aussi bien intégré. La déduplication est effective dès le deuxième backup : sur mes 6 LXC et 2 VMs, le datastore PBS affiche un taux de déduplication d’environ 40 % après deux semaines de sauvegardes quotidiennes. En pratique, les quatre LXC Debian 12 partagent l’essentiel de leurs blocs système – kernel, libs, /usr – et PBS ne les stocke qu’une fois.
Le catalogue de restauration est particulièrement pratique : je peux naviguer dans les fichiers d’un backup spécifique depuis l’interface web avant de décider quoi restaurer. J’ai testé la restauration d’un LXC complet (Vaultwarden) après une fausse manipulation – 4 minutes 30 secondes pour retrouver un service fonctionnel. C’est rassurant.
Ce qui manque : PBS lui-même n’a pas de sauvegarde hors-site dans ma config actuelle. La règle 3-2-1 dit une copie hors-site. Je n’en ai pas encore. C’est le point faible le plus évident du setup.
Les lacunes qui restent
L’accès distant sans ouvrir de ports. Actuellement, je n’ai pas de VPN configuré sur heighliner. Si je veux accéder à mes services depuis l’extérieur, je passe par un tunnel ponctuel ou je reste sur le réseau local. Tailscale ou WireGuard sont sur la liste – c’est l’objet de l’article sur la sécurisation du homelab.
Le clustering HA. Un seul nœud physique signifie zéro tolérance aux pannes matérielles. Si le MS-01 tombe, tout tombe. Pour un homelab personnel c’est acceptable – mes services ne sont pas critiques – mais c’est une limite claire que j’assume consciemment.
Les chiffres réels
À vide, heighliner consomme environ 15 W au Shelly EM, ventilateurs en profil silence. Avec les 6 LXC et 2 VMs actives en charge légère (trafic DNS Pi-hole, quelques sync Nextcloud, quelques requêtes Git), la consommation monte à environ 22 W. C’est inférieur à une ampoule incandescente. Pour un homelab qui tourne 24/7, c’est la bonne machine.
Le monitoring complet de l’infrastructure – node_exporter sur chaque LXC/VM, pve-exporter sur le nœud Proxmox, tout centralisé dans Grafana sur hubble.arewel.com – est décrit dans l’article sur le monitoring. C’est la chose dont je suis le plus content dans ce setup : voir en temps réel ce que consomment réellement mes conteneurs, pas des estimations.
Ce que je referai différemment
Trois choses. Premièrement, dessiner le schéma réseau avec les VLANs avant d’allumer la première VM – pas après. Deuxièmement, dimensionner la RAM des VMs avec des balloon drivers dès le départ, pas après avoir swappé. Troisièmement, prévoir PBS dans la conception initiale plutôt que de l’ajouter en rattrapage : le backup doit être dans la liste des premières choses qu’on configure, pas la dernière.
La prochaine étape concrète : centraliser l’authentification avec un SSO. Gérer N mots de passe différents pour N services, c’est la friction quotidienne la plus pénible de ce setup. C’est le sujet du prochain article.
slug: bilan-6-semaines-proxmox
meta: Bilan honnête après 6 semaines de homelab sur Proxmox VE 8.3 : erreurs de config réseau, RAM et swap, surprise LXC, PBS et métriques mesurées au Shelly EM.
tags: proxmox, homelab, retour-experience, lxc, vm, pbs, reseau, rex