PROXMOX : Pourquoi tuer le LVM entre autre ?

Comment j'ai atterri sous Proxmox (et pourquoi j'y reste)

Avant de rentrer dans le vif du sujet, laissez-moi vous raconter mon parcours de rescapé de la virtualisation. Parce que si vous êtes ici, y'a des chances que vous aussi, vous ayez un passé douloureux.

L'ère ESXi : la drogue douce de VMware

J'ai commencé comme beaucoup : avec VMware ESXi. À titre perso d'abord, puis au boulot. Et je vais être honnête : quand tu découvres ESXi sans avoir connu autre chose, tu trouves ça génial. L'interface est propre, c'est stable, ça marche. Tu te sens un peu comme un sysadmin de la NASA dans ton garage.

Sauf que.

Sauf que c'est payant. Sauf que Broadcom a racheté VMware et a décidé que ton portefeuille était un buffet à volonté. Sauf que le jour où tu essaies Proxmox, tu te rends compte que t'as passé des années à payer pour un truc que tu peux avoir en mieux, en gratuit, et en open-source. C'est un peu comme découvrir que le restau étoilé du coin sert exactement les mêmes surgelés Picard que toi, mais à 45€ le plat.

ESXi c'est de la merde payante bien pratique quand on le découvre sans trop avoir connu autre chose. Une fois que t'as goûté Proxmox, y'a plus photo.

Le syndrome du NAS : j'ai tout testé (et j'ai tout désinstallé)

Avant de trouver la paix intérieure avec Proxmox, j'ai traversé ma phase "NAS". Accrochez-vous, parce que j'en ai testé des trucs :

• TrueNAS : solide, sérieux, ZFS natif. Mais au final, tu veux toujours faire tourner des trucs dessus et tu te retrouves à bidouiller des jails ou des VMs dans un truc qui est censé être un NAS. C'est comme installer un home cinéma dans ta voiture : ça marche, mais c'est pas fait pour.

• OpenMediaVault : l'alternative Debian-based, sympa sur le papier, mais dès que tu veux sortir des sentiers battus, tu te retrouves en CLI à te demander pourquoi t'as pas installé Proxmox directement.

• Synology (et le Hacksyno/Xpenology) : alors là, je vais être fair-play. Les NAS Synology sont d'excellentes machines. Le DSM est un des meilleurs OS NAS du marché. Et quand tu fais tourner un Xpenology sur du hardware custom, c'est le bonheur. Les apps sont bien foutues, la gestion est intuitive. Mais voilà : ça reste un NAS. C'est pas un hyperviseur. Tu finis toujours par buter sur les limites du truc.

• Hyper-V : ...

Bon. J'en parle parce que c'est arrivé. C'était un moment de faiblesse. Un épisode dépressif, probablement. J'ai installé Hyper-V. J'ai essayé de virtualiser des trucs avec. J'ai regardé l'interface. J'ai pleuré un peu. Je l'ai désinstallé. Je me suis excusé auprès de mon serveur depuis. On n'en parle plus.

Et puis Proxmox est arrivé

Proxmox, c'est le truc qui fait que tu te demandes pourquoi tu t'es infligé tout le reste. C'est un hyperviseur complet, gratuit, basé sur Debian, qui fait KVM + LXC nativement, avec une interface web qui tient la route, un système de backup dédié (PBS), du clustering, du SDN, et maintenant même du support OCI. Le tout sans vendre un rein pour une licence.

Mais — et c'est tout l'objet de cet article — Proxmox arrive avec des choix par défaut qu'il faut, à mon humble avis, remettre en question immédiatement. Et le premier d'entre eux, c'est le LVM.

Acte I : Faut-il virer le LVM sur un Proxmox tout neuf ? (Spoiler : oui)

Le problème avec LVM-Thin par défaut

Quand tu installes Proxmox avec les options par défaut, voilà ce que tu obtiens :

• Une partition root (LV classique, formatée ext4) pour l'OS
• Un thin pool data (LVM-Thin) pour stocker tes VMs et containers
• Un swap

Sur le papier, le LVM-Thin c'est malin : ça fait du thin provisioning, c'est-à-dire que l'espace disque n'est consommé qu'au fur et à mesure que les données sont réellement écrites. Tu donnes 100 Go à une VM, elle n'en utilise que 10, ça ne prend que 10 Go sur ton disque. Génial, non ?

Non.

Enfin, pas pour moi. Et voilà pourquoi.

Pourquoi le thin provisioning me rend dingue

1. L'effet bombe à retardement

Le thin provisioning, c'est de l'overcommit. Tu promets plus que ce que t'as. C'est le principe des compagnies aériennes qui vendent plus de billets que de sièges dans l'avion. Et comme pour les compagnies aériennes, le jour où tout le monde se pointe en même temps, c'est le drame.

Concrètement : tu as un SSD de 500 Go. Tu crées 10 VMs avec 100 Go chacune. Le thin provisioning te dit "pas de souci patron, y'a la place". Sauf que le jour où tes VMs grandissent toutes en même temps — et ça arrive, crois-moi — ton thin pool se remplit à 100% et là... toutes tes VMs et tous tes LXC se flinguent en même temps. Et rien n'est récupérable facilement. C'est pas un crash propre avec un message d'erreur poli. C'est un carnage.

2. C'est chiant à gérer au quotidien

Avec LVM-Thin, tes disques virtuels sont des block devices. Ça veut dire que quand tu veux aller fouiner dans les fichiers de tes VMs depuis l'hôte Proxmox, tu peux pas juste naviguer dans un répertoire et retrouver tes fichiers. Tout est abstrait derrière des volumes logiques. Pour un mec comme moi qui aime avoir la main sur ses données et savoir exactement où elles sont, c'est l'enfer.

3. La fausse économie

Oui, le thin provisioning économise de l'espace disque. Mais en 2025, un SSD de 1 To coûte le prix d'un resto. Est-ce que ça vaut vraiment le coup de jouer à la roulette russe avec tes données pour économiser quelques gigas ? Perso, je préfère allouer des capacités réelles à mes VMs et LXC. Quand je donne 50 Go à un container, il a 50 Go. Pas 50 Go virtuels qui existent peut-être, si personne d'autre n'a décidé de les utiliser en même temps.

Ce que je fais : virer le LVM et passer en Directory Storage

Ma philosophie, c'est simple : je vire le LVM-Thin dès l'installation, et je travaille avec un stockage de type Directory sur la partition root, en ext4. C'est rustique, c'est pas sexy, mais c'est fiable et prévisible. Je sais exactement ce que j'ai, où c'est, et combien il reste de place.

Comment virer le LVM-Thin sur un Proxmox tout neuf

Voilà la procédure, à faire juste après l'installation tant que y'a rien sur la machine :

Étape 1 : Supprimer le thin pool LVM

# On vérifie ce qu'on a
lvs

# On supprime le logical volume "data" (le thin pool)
lvremove /dev/pve/data

# On confirme que c'est parti
lvs

Étape 2 : Étendre la partition root pour récupérer l'espace

# On étend le LV root pour occuper tout l'espace libre du VG
lvextend -l +100%FREE /dev/pve/root

# On redimensionne le filesystem ext4
resize2fs /dev/pve/root

# On vérifie
df -h

Étape 3 : Configurer le stockage dans Proxmox

Dans l'interface web :

1. Va dans Datacenter → Storage
2. Sélectionne local (le storage Directory existant sur /var/lib/vz)
3. Clique sur Edit
4. Dans Content, coche tout : Disk image, Container, ISO image, VZDump, Container template, Snippets
5. Valide

Tu peux maintenant supprimer le storage local-lvm qui ne sert plus à rien.

Étape 4 : (Optionnel) Vérifier que tout est propre

# L'état final devrait ressembler à ça :
pvs
# Un seul PV, un seul VG

lvs
# Deux LV : root (gros) et swap

df -h
# /dev/mapper/pve-root monté sur / avec tout l'espace

Et voilà. T'as un Proxmox avec un stockage simple, prévisible, où tu retrouves tes images disques en .qcow2 dans /var/lib/vz/images/, tes ISOs dans /var/lib/vz/template/iso/, et tes backups dans /var/lib/vz/dump/. Comme des fichiers normaux. Dans des dossiers normaux. Qu'on peut copier, déplacer, sauvegarder avec des outils normaux.

"Mais attends, et ZFS ?"

Ah, ZFS. Le chouchou des forums Proxmox. Et à raison ! ZFS c'est objectivement supérieur sur le papier : checksums sur toutes les données (adieu le bit rot), compression transparente, snapshots efficaces, réplication native intégrée à Proxmox, portabilité des pools entre machines...

Mais.

ZFS bouffe de la RAM. Minimum 8 Go recommandés, idéalement 16 Go ou plus. Sur un homelab avec 32 Go de RAM, c'est du budget mémoire que tu ne donnes pas à tes VMs. ZFS augmente l'usure des SSD (write amplification). ZFS veut de la RAM ECC idéalement, et des SSD enterprise avec power-loss protection pour être vraiment fiable.

Mon avis : si t'as les moyens en RAM et en hardware, ZFS c'est le top. Sinon, ext4 en Directory c'est la valeur sûre. LVM-Thin, c'est le compromis bâtard que je ne recommande à personne pour du homelab.

Un mec sur le forum Proxmox résume parfaitement la situation : "ZFS is amazing until your 8GB RAM server starts swapping. LVM-thin is fast until you need to migrate VMs. Directory storage is simple until you want snapshots."

Mon choix personnel : Directory en ext4, la simplicité d'abord. Et toi, tu fais comme tu veux. Mais au moins maintenant, tu sais pourquoi.

Aparté : C'est quoi VM et LXC ? Qu'est-ce qui est mieux ?

Avant d'aller plus loin, faut qu'on parle de cette question fondamentale, parce que je vois encore beaucoup de gens qui confondent ou qui ne savent pas quand utiliser l'un ou l'autre.

La VM (Virtual Machine) — La maison individuelle

Une VM, c'est un ordinateur complet simulé. Elle a son propre noyau, son propre OS, sa propre mémoire, ses propres "disques durs" virtuels. Quand tu crées une VM Debian sur Proxmox, c'est exactement comme si t'avais un PC physique dédié qui fait tourner Debian, sauf qu'il est virtuel.

Les plus :

• Isolation totale : une VM ne peut pas impacter les autres, ni l'hôte. Si elle se fait pirater, l'attaquant est coincé dedans.
• N'importe quel OS : Windows, Linux, BSD, macOS (chut), FreeDOS si ça t'amuse.
• Passthrough hardware : tu peux dédier un GPU, une carte réseau, un contrôleur USB directement à la VM.
• Docker officiel : Proxmox recommande officiellement de faire tourner Docker dans une VM.

Les moins :

• Gourmand : chaque VM embarque un OS complet. Compte 2 à 4 Go de RAM minimum par VM.
• Démarrage lent : 30 à 60 secondes pour booter.
• Overhead : performances à 80-90% du natif. Le hardware est émulé, même si VirtIO aide beaucoup.

Le LXC (Linux Container) — L'appartement en colocation

Un LXC, c'est un container système. Il partage le noyau Linux de l'hôte Proxmox, mais il a son propre espace utilisateur : ses propres processus, son propre filesystem, sa propre configuration réseau. C'est comme un OS Linux complet... sans le noyau.

Attention : un LXC n'est pas un container Docker. Docker, c'est un container applicatif (une app isolée). Un LXC, c'est un container système (un mini-OS). Tu dois l'administrer comme une VM : installer les paquets, faire les mises à jour, configurer les services. C'est juste que c'est beaucoup plus léger.

Les plus :

• Ultra léger : 100 à 500 Mo de RAM contre 2-4 Go pour une VM équivalente.
• Démarrage instantané : 2 à 5 secondes.
• Performances quasi natives : 95-98% du natif, l'overhead est négligeable.
• Densité : tu peux faire tourner 10 à 20 LXC là où tu aurais mis 3 VMs.

Les moins :

• Linux only : pas de Windows, pas de BSD, pas de macOS.
• Isolation réduite : le container partage le noyau de l'hôte. Un exploit kernel peut théoriquement remonter jusqu'à l'hôte.
• Pas de Docker (officiellement) : Proxmox déconseille fortement Docker dans un LXC. Ça marche techniquement (en privilegié avec nesting), mais c'est du YOLO.
• Le casse-tête privilegié/unprivileged : les containers unprivileged (recommandés pour la sécurité) posent régulièrement des soucis de permissions, surtout pour les montages NFS et le passthrough GPU. Depuis Proxmox 9 et AppArmor 4.1, c'est devenu encore plus galère pour le GPU Intel QuickSync. Un blogueur a résumé la situation sans détour : faire tourner un container "unprivileged" avec AppArmor désactivé et des paramètres kernel modifiés, c'est du "security theater".

Alors, VM ou LXC ?

Ma règle perso :

• LXC pour tout ce qui est service Linux léger : reverse proxy, Pi-hole, monitoring, bases de données, Mailcow, etc.
• VM pour : Windows, Docker (avec Portainer/Compose), tout ce qui a besoin de passthrough GPU, tout ce qui nécessite une isolation de sécurité forte, Home Assistant OS.

En résumé : LXC par défaut, VM quand c'est nécessaire.

Et le support OCI de Proxmox 9.1 dans tout ça ?

Depuis novembre 2025, Proxmox 9.1 permet de puller des images Docker Hub directement et de les convertir en LXC. Tu vas dans ton stockage, tu cliques "Pull from OCI Registry", tu tapes le nom de l'image, et Proxmox te crée un LXC à partir de l'image Docker. Sans installer Docker. Sans VM dédiée.

Sur le papier, c'est révolutionnaire. En pratique, c'est encore en tech preview : pas de mise à jour facile des containers (faut recréer le LXC), la console marche pas toujours, pas de docker-compose, et certaines images ne fonctionnent tout simplement pas. Mais la direction est la bonne, et ça promet pour la suite.

Question existentielle : Helper Scripts or Not Helper Scripts ?

Ah, le sujet qui fâche. Accrochez-vous, ça va être sportif.

C'est quoi les "Helper Scripts" ?

Si tu fréquentes la communauté Proxmox depuis plus de 10 minutes, tu as forcément croisé les Proxmox VE Helper-Scripts. C'est une collection de scripts bash qui automatisent l'installation de centaines de services dans des LXC ou des VMs Proxmox. Un Pi-hole en une commande. Un Home Assistant en une commande. Un Nextcloud en une commande. Plus de 400 scripts pour à peu près tout ce qu'un homelabber peut rêver d'installer.

Tu colles ça dans le shell de ton Proxmox :

bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/ct/pihole.sh)"

Et paf, t'as un LXC Pi-hole configuré et fonctionnel en 2 minutes. Mode simple pour les débutants, mode avancé pour les power users. Un système de mise à jour intégré. Franchement, c'est beau.

L'histoire de tteck : un hommage nécessaire

Avant de débattre, il faut rendre hommage. Ces scripts ont été créés par un mec connu uniquement sous le pseudo tteck. Personne ne connaissait son vrai nom. Il a commencé à les publier sur GitHub en 2022, et en quelques mois, il est devenu une légende de la communauté homelab.

Un mec. Tout seul. Patient, humble, présent pour aider tout le monde sur les forums. Ses scripts ont littéralement permis à des milliers de personnes de se lancer dans le self-hosting et Proxmox. Sans lui, beaucoup auraient abandonné dès la première semaine.

Fin 2024, tteck a annoncé qu'il était en soins palliatifs. Il a eu la lucidité d'organiser la transmission du projet : un nouveau mainteneur (Mickey), une organisation GitHub communautaire, une migration propre. Sa femme Angie a annoncé son décès peu après. Le projet continue sous le nom "Proxmox VE Helper-Scripts (Community Edition)" sur community-scripts.org, maintenu par des bénévoles. 30% des dons vont à la recherche contre le cancer.

Un commentaire parmi des centaines résume tout : "tteck is the reason I am homelabbing to this day."

Respect éternel, tteck. Ton impact sur la communauté est immense et ton héritage perdure.

Le camp "Pour" : la porte d'entrée du self-hosting

Soyons honnêtes : ces scripts sont incroyablement pratiques. Et ils comblent un vrai vide dans l'écosystème Proxmox.

Parce que la réalité, c'est qu'installer un service dans un LXC manuellement, c'est pas anodin. Faut créer le container, choisir le bon template, configurer le réseau, installer les dépendances, configurer le service, ouvrir les bons ports, etc. Pour un débutant, c'est des heures de galère et de documentation. Le helper script fait tout ça en 2 minutes, avec des valeurs par défaut sensées.

C'est exactement ce qu'il manque à Proxmox nativement : un espèce de "App Store" pour LXC, façon HACS pour Home Assistant. Tu veux un service, tu cliques, c'est déployé. Et tant que cette fonctionnalité n'existe pas officiellement, les helper scripts remplissent ce rôle.

Le camp "Contre" : le syndrome curl | bash en root

Et c'est là que ça se corse. Parce que ce qu'on fait concrètement quand on lance un helper script, c'est ça :

On télécharge du code depuis internet et on l'exécute en root sur notre hyperviseur. Sans le lire. Sans le vérifier.

Un article de XDA Developers de février 2026 a décortiqué le script Ollama : une seule commande utilisateur déclenche le téléchargement et l'exécution de 8 scripts distants différents, tous avec les privilèges root. Si un seul de ces fichiers est compromis — commit malveillant, compte GitHub hacké, attaque supply chain — c'est game over. Accès root à ton hyperviseur. Toutes tes VMs. Toutes tes données.

"Mais c'est open-source, on peut auditer !"

Certes. Mais est-ce que tu le fais ? Sincèrement ? Comprendre un script bash de 10 pages, ça peut prendre un après-midi entier. Et l'affaire xz Utils a prouvé qu'un attaquant patient peut infiltrer un projet open-source pendant des années sans que personne ne s'en rende compte.

Un membre du forum officiel Proxmox résume parfaitement : "Si je dis à mon chef que je veux télécharger et exécuter directement un script depuis internet en tant qu'admin, il va (à juste titre) me bloquer et me demander pourquoi j'ai besoin d'un script pour faire mon boulot."

Et il y a un autre problème : quand ça casse, tu sais pas pourquoi. Après une mise à jour Proxmox, quand un script ne fonctionne plus, l'utilisateur qui ne comprend pas ce que le script a fait sous le capot est totalement perdu. Et il va inonder le forum officiel Proxmox avec des questions auxquelles personne ne peut répondre sans auditer le script.

Et Proxmox dans tout ça, ils en pensent quoi ?

Proxmox n'a jamais intégré ni officiellement soutenu ces scripts. Quand la communauté a proposé que Proxmox reprenne le projet après le décès de tteck, la réponse a été claire : non merci. Les TurnKey Templates existent déjà, et le temps de développement serait mieux investi sur le produit lui-même. Un développeur Proxmox a même noté que les entreprises qui migrent depuis VMware (le gros marché actuel de Proxmox) n'ont pas vraiment besoin de scripts d'installation LXC — elles cherchent des fonctionnalités enterprise manquantes.

Et avec le support OCI dans Proxmox 9.1, Proxmox propose sa propre réponse au problème : puller directement des images Docker Hub et les transformer en LXC, de manière intégrée et supportée. C'est encore limité (tech preview), mais ça va dans la bonne direction.

Mon avis (parce que c'est mon blog)

Je vais être nuancé, et ça va surprendre ceux qui me connaissent.

Les helper scripts sont géniaux ET c'est une mauvaise pratique de sécurité. Les deux sont vrais en même temps.

Ma position :

1. Pour découvrir et apprendre : fonce. Les helper scripts sont une porte d'entrée fantastique. Installe des trucs, casse des trucs, recommence. C'est exactement pour ça qu'ils existent.

2. Pour de la prod ou des données importantes : prends le temps de faire les choses à la main. Ou au minimum, lis le script avant de l'exécuter. Télécharge-le, ouvre-le, comprends ce qu'il fait. C'est chiant, mais c'est ton hyperviseur. C'est la clé de voûte de tout ton labo.

3. Le vrai problème : c'est qu'il n'existe pas de système de paquets standardisé, signé et auditable pour les LXC Proxmox. Tant que ce trou existe, les gens utiliseront des curl | bash. La solution, c'est pas de gueuler sur les utilisateurs, c'est de construire l'infrastructure qui rend cette pratique obsolète.

Conclusion : la philosophie du homelabber

Si t'as lu jusqu'ici, t'as compris que derrière des questions techniques en apparence simples — LVM ou pas LVM, VM ou LXC, scripts ou pas scripts — se cachent des questions plus profondes sur comment on veut gérer notre infrastructure.

Ma philosophie tient en quelques principes :

Comprends ce que tu fais. Le self-hosting, c'est pas juste copier-coller des commandes depuis internet. C'est comprendre pourquoi on fait les choses. Pourquoi on vire le LVM. Pourquoi on choisit un LXC plutôt qu'une VM. Pourquoi on lit un script avant de l'exécuter en root. C'est cette compréhension qui fait la différence entre un homelab qui tourne et un château de cartes.

Garde ça simple. Le mieux est l'ennemi du bien. Un stockage ext4 en directory, c'est pas glamour, mais ça marche et tu sais où sont tes fichiers. Un LXC Debian avec un service installé à la main, c'est pas aussi rapide qu'un script, mais tu sais exactement ce qu'il y a dedans. La simplicité, c'est de la résilience.

Fais des backups. J'en ai pas beaucoup parlé dans cet article, mais Proxmox Backup Server est gratuit et il est fantastique. Installez-le. Sur une machine séparée si possible. Configurez des backups automatiques. Testez vos restaurations. Parce que le jour où ton thin pool explose, où ton script a foiré, ou où ta VM refuse de démarrer, la seule chose qui va te sauver, c'est un backup fonctionnel.

Amuse-toi. Parce qu'à la fin, un homelab c'est ça. C'est un terrain de jeu pour apprendre, expérimenter, casser des trucs et les réparer. C'est pour ça qu'on fait tout ça. Pas pour avoir le setup parfait — mais pour le plaisir du chemin.

Et si le chemin passe par un curl | bash de temps en temps... je jugerai pas. Mais lis le script quand même, hein ;)