10 erreurs Proxmox à éviter (et quoi faire à la place)

Si vous avez déjà plongé dans l'univers des homelabs, vous avez sûrement entendu parler de Proxmox, la plateforme de virtualisation open source que tout le monde adore. Elle est puissante, souple et entièrement gratuite. Mais cette liberté s'accompagne d'une courbe d'apprentissage qui peut vous le faire payer si vous ne faites pas attention.

Un utilisateur a décidé d'épargner cette douleur aux autres et a publié un mini-manuel de leçons durement apprises, tirées de sa propre expérience. Son guide PDF en libre accès détaille 10 erreurs Proxmox courantes, et la communauté a répondu par un mélange de « merci » et de « pareil pour moi ». Ce sont bien plus que des bourdes de débutant : même des utilisateurs aguerris se sont pris la tête dans les mains devant certaines d'entre elles.

Voici ces 10 pièges Proxmox en détail, avec les commentaires et le contexte apportés par la communauté Proxmox au sens large.

1. ZFS sans planification sérieuse de la RAM

ZFS est formidable… jusqu'au jour où il dévore votre système. La vieille règle empirique, c'est un gigaoctet de RAM par téraoctet de stockage brut. Ignorez-la, et ZFS peut faire s'effondrer vos performances ou, pire, faire planter tout le système.

Un utilisateur a relevé une confusion autour de cette règle, en pointant des incohérences dans les calculs de l'auteur lui-même. La leçon reste la même : si vous utilisez ZFS, vous devez allouer la mémoire de manière réfléchie. Et si votre système a moins de 16GB de RAM, ZFS n'est peut-être pas le meilleur choix.

À faire à la place : calculez votre ratio stockage/RAM et demandez-vous si ajouter un L2ARC ou un SLOG est plus pertinent que d'ajouter de la mémoire.

2. Le mythe « l'ECC est obligatoire »

Ah, l'éternel débat sur l'ECC. Certains affirment que ZFS sans RAM ECC, c'est chercher la corruption de données, tandis que d'autres y voient de l'alarmisme.

C'est un contributeur qui l'a le mieux résumé : l'ECC n'empêche pas les bitflips, il les journalise et les corrige. Sans ECC, vous pouvez subir une corruption silencieuse, mais ce n'est pas systématique. Tout dépend de la valeur que vous accordez à vos données et du degré de solidité que vous attendez de votre système.

À faire à la place : si vos données comptent vraiment, investissez dans l'ECC. Si vous faites des essais, les sauvegardes et une conception intelligente comptent plus que l'obsession du type de mémoire.

3. Utiliser RAIDZ pour le stockage des VM

RAIDZ est conçu pour les gros fichiers séquentiels, comme les médiathèques ou les sauvegardes. Les VM, c'est une autre histoire. Comme RAIDZ écrit des bandes réparties sur plusieurs disques, les E/S aléatoires deviennent un goulet d'étranglement.

Les vétérans de Proxmox disent que c'est une erreur fréquente au début. Pour les configurations chargées en VM, des miroirs agrégés en bandes (miroirs ZFS) offrent de bien meilleures performances et une meilleure résilience.

À faire à la place : utilisez des miroirs, voire des miroirs ZFS en bandes (une configuration proche du RAID10) pour vos VM, et gardez RAIDZ pour le stockage à froid.

4. Écarter Local-LVM parce qu'il serait trop rigide

Beaucoup d'utilisateurs supposent que Local-LVM est trop rigide pour être utile. En pratique, c'est souvent la méthode de stockage la plus rapide dès l'installation, et pour les petits déploiements, il fonctionne très bien. Oui, il lui manque les snapshots et les fonctions avancées de ZFS, mais il est stable et simple.

À faire à la place : commencez avec Local-LVM si vous n'avez pas besoin de fonctions sophistiquées. Vous pourrez toujours migrer plus tard, à mesure que vos besoins grandissent.

5. Le piège du type de CPU « host »

Sur le papier, donner à votre VM les fonctionnalités exactes du CPU de l'hôte paraît idéal, puisqu'on s'attend à des performances maximales. Le hic, c'est que vous ne pourrez pas migrer cette VM vers une autre machine si le CPU n'est pas identique.

Un utilisateur a signalé des problèmes encore plus graves : avec le CPU « host », les mitigations pour Spectre et Meltdown peuvent manquer si vous ne les gérez pas à la main.

À faire à la place : choisissez un modèle de CPU générique comme x86-64-v2-AES pour équilibrer performances et compatibilité. N'utilisez « host » que si vous êtes absolument sûr que la VM n'aura jamais besoin de migrer.

6. Mettre en place la HA sans en remplir les conditions

La HA (haute disponibilité) de Proxmox n'est pas du plug-and-play. Beaucoup d'utilisateurs la configurent avec deux nœuds et aucun dispositif de quorum, ce qui mène tout droit au split-brain.

Il faut trois votes pour le quorum. En général, cela veut dire trois nœuds physiques, ou deux nœuds plus un QDevice. Lésinez là-dessus, et vous vous retrouverez avec des VM coincées dans les limbes ou, pire, deux nœuds qui essaient de faire tourner la même VM.

À faire à la place : utilisez trois nœuds, ou deux nœuds plus un QDevice, et vérifiez que le fencing est correctement configuré.

7. Une stratégie de sauvegarde incomplète

L'erreur, c'est de traiter les sauvegardes comme un « petit plus », alors qu'elles ne se négocient pas. Un faux pas, et votre VM entière peut disparaître.

Le guide insiste sur la planification de l'endroit et du moment des sauvegardes, ainsi que de la manière de restaurer. Un utilisateur a ajouté un point important : testez toujours vos sauvegardes, parce qu'une sauvegarde qui ne se restaure pas n'est qu'un presse-papier.

À faire à la place : automatisez des sauvegardes quotidiennes ou hebdomadaires, stockez-les à distance (ou au moins sur un autre disque) et faites de temps en temps des restaurations de test.

8. Faire tourner Docker directement sur Proxmox

Celle-ci a déclenché un chœur de « mais pourquoi quelqu'un ferait… », et pourtant elle est étonnamment courante. Faire tourner Docker sur l'hôte Proxmox mélange conteneurs et hyperviseur, un cauchemar pour la stabilité comme pour la sécurité.

La recommandation est simple : isolez. Faites tourner Docker dans un conteneur LXC, ou montez une VM légère dédiée à la gestion des conteneurs (bonjour aux fans de Portainer ou de Rancher).

À faire à la place : ne lancez pas Docker sur le nœud Proxmox nu. Utilisez une VM ou un LXC, et gardez votre hyperviseur propre.

9. Pas de supervision jusqu'à la panne

C'est le « tueur silencieux ». La plupart des utilisateurs font l'impasse sur la supervision jusqu'à ce que quelque chose explose, et à ce moment-là les journaux peuvent ne plus servir à rien.

Le guide d'origine aborde la supervision de base, mais certains membres de la communauté plaident pour des installations plus poussées : traps SNMP, alertes par e-mail, Prometheus + Grafana, ou au moins une solution à base d'agents.

À faire à la place : mettez en place la supervision dès le premier jour. Même de simples alertes par e-mail valent mieux que rien.

10. Déployer des services directement sur l'hyperviseur

Vous n'installeriez pas vos applis sur le bloc moteur de votre voiture, alors pourquoi déployer des services sur votre hyperviseur ?

Proxmox est censé rester léger et ciblé, et il n'a jamais été conçu comme une distribution Linux généraliste. Ajouter des services augmente votre surface d'attaque et rend les mises à jour plus dangereuses.

À faire à la place : placez vos services dans des VM ou des conteneurs, et laissez l'hyperviseur tranquille.

Mentions honorables de la communauté

• Cloner des VM Windows sans Sysprep.
• Supprimer des pools de stockage LXC encore référencés.
• Ne pas utiliser de synchronisation horaire, ce qui est particulièrement critique pour l'authentification TOTP.
• Faire confiance aux alimentations externes des serveurs Minisforum (remplacez-les tôt !).

Pour conclure

Proxmox est comme une toile vierge : vous pouvez y construire quelque chose d'extraordinaire, ou vous enfermer tout seul dans une impasse. Éviter toutes les erreurs n'est pas réaliste, l'astuce consiste donc à tirer vite les bonnes leçons. Et grâce à la transparence d'un utilisateur (et au suivi d'une communauté passionnée), vous n'avez pas à tout apprendre à vos dépens.

Alors avant votre prochain qm create ou zfs pool create, prenez un instant, relisez ceci et épargnez-vous le drame. La seule chose pire qu'une VM corrompue, c'est de vous rendre compte que c'est vous qui l'avez corrompue.