Serveur dédié : installer Proxmox et créer ses propres VM avec KVM

Un serveur dédié, c'est une machine physique entière pour vous seul : 16 à 56 threads, 64 à 192 Go de RAM ECC, des disques NVMe. Faire tourner une seule application dessus serait du gâchis. Proxmox VE transforme cette machine en une plateforme de virtualisation complète : vous y découpez autant de machines virtuelles (KVM) et de conteneurs (LXC) que vous voulez, chacun isolé, avec son propre OS, ses ressources garanties et ses snapshots.

Concrètement, c'est ce qui vous permet de remplacer cinq VPS par un seul dédié, d'héberger un environnement de préproduction identique à la production, de proposer des VPS à vos propres clients, ou simplement de tester une distribution sans rien casser.

Ce guide couvre l'installation de Proxmox VE 9 (basé sur Debian 13) sur un serveur dédié YorkHost, la configuration réseau selon que vous disposez d'une ou plusieurs IP publiques, la création d'un template Debian avec cloud-init pour déployer une VM en trente secondes, et les bases de l'exploitation : firewall, sauvegardes, mises à jour.

Ce qu'il vous faut

• Un serveur dédié avec accès IPMI/KVM (console distante) : c'est ce qui permet de monter l'ISO Proxmox et de suivre l'installation comme si vous aviez un écran branché. Toutes les offres dédiées YorkHost l'incluent.
• Au moins 32 Go de RAM et deux disques si vous voulez un miroir ZFS. La configuration E5-2690 V4 « Virtualisation » (2 CPU, 28 cœurs / 56 threads, 64 Go ECC extensible à 128 Go, 2 To SSD) est pensée exactement pour cet usage.
• L'IP publique principale du serveur, sa passerelle et son masque (dans votre espace client ou l'email de livraison).
• Optionnel : des IP additionnelles si vous voulez que certaines VM aient leur propre adresse publique.
• Un ordinateur avec un navigateur ; Proxmox s'administre entièrement en web.

Serveur dédié ou grappe de VPS ?

Si vous avez besoin de 3 ou 4 machines, plusieurs VPS Linux YorkHost restent plus simples : rien à installer, sauvegardes 7 jours incluses, facturation à l'unité. Le dédié devient intéressant à partir d'une dizaine de VM, quand vous voulez des snapshots et du provisioning instantanés, des ressources dédiées non partagées, ou du matériel spécifique (beaucoup de RAM, NVMe local rapide). Les deux bénéficient de l'Anti-DDoS Stormwall & Gcore inclus et du réseau 1 à 10 Gbps.

Étape 1 : Installer Proxmox VE

Option A : depuis l'ISO via la console IPMI (recommandé)

1. Téléchargez l'ISO Proxmox VE 9.x sur proxmox.com/downloads.
2. Ouvrez la console IPMI/KVM de votre serveur depuis l'espace client YorkHost, puis utilisez la fonction Virtual Media pour monter l'ISO comme lecteur virtuel.
3. Redémarrez le serveur et démarrez sur le média virtuel (touche F11 ou F12 selon la carte mère pour le menu de boot).
4. Choisissez Install Proxmox VE (Graphical).

L'installateur pose peu de questions, mais deux comptent vraiment :

Le disque et le système de fichiers. Cliquez sur Options à côté du disque cible :

Choix	Quand le choisir
ZFS (RAID1)	Deux disques identiques. Miroir, checksums, snapshots instantanés, compression. Le meilleur choix pour un hyperviseur. Réservez 8 Go de RAM au cache ZFS.
ZFS (RAID0) ou ext4 / LVM-thin	Un seul disque. LVM-thin est le choix par défaut, éprouvé et léger.
ZFS (RAIDZ)	Trois disques ou plus, si vous privilégiez la capacité à la performance.

Avec ZFS, laissez ashift=12 et la compression lz4 (par défaut). Avec LVM, l'installateur crée un volume local (ISO, sauvegardes) et un local-lvm (disques des VM).

Le réseau. Renseignez le hostname au format FQDN (pve1.example.com), l'IP publique du serveur au format CIDR (203.0.113.10/24), la passerelle et un serveur DNS (1.1.1.1). L'interface sélectionnée sera attachée au pont vmbr0.

Définissez un mot de passe root fort et une adresse email pour les alertes, puis lancez l'installation. Comptez 5 minutes. Démontez l'ISO au redémarrage.

Option B : par-dessus une Debian 13 existante

Si votre panel YorkHost a déjà installé Debian 13 et que vous ne voulez pas passer par l'ISO :

cat > /etc/apt/sources.list.d/pve-install-repo.sources <<'SOURCES'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
SOURCES
wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg -O /usr/share/keyrings/proxmox-archive-keyring.gpg
apt update && apt full-upgrade -y
apt install -y proxmox-default-kernel
systemctl reboot

Après redémarrage sur le noyau Proxmox :

apt install -y proxmox-ve postfix open-iscsi chrony
apt remove -y linux-image-amd64 'linux-image-6.12*'
update-grub

Cette méthode demande de créer vmbr0 à la main (voir étape 3) et de vérifier que /etc/hosts résout le hostname vers l'IP publique, pas vers 127.0.1.1. La documentation officielle détaille ces points.

Étape 2 : Premier accès et mises à jour

L'interface web est disponible sur https://203.0.113.10:8006. Le certificat est auto-signé, acceptez l'avertissement du navigateur (on y remédie plus bas). Connectez-vous en root avec le realm Linux PAM.

Un message vous informe que vous n'avez pas de souscription : c'est normal, Proxmox VE est libre et complet sans abonnement. La souscription finance le projet et donne accès au dépôt « enterprise », testé plus longuement. Pour utiliser le dépôt communautaire, gratuit et parfaitement adapté à un usage professionnel raisonnable, passez en SSH :

ssh root@203.0.113.10

# Désactive le dépôt enterprise (Proxmox 9 utilise le format deb822)
sed -i 's/^Types:/#Types:/' /etc/apt/sources.list.d/pve-enterprise.sources
sed -i 's/^Types:/#Types:/' /etc/apt/sources.list.d/ceph.sources 2>/dev/null

# Active le dépôt no-subscription
cat > /etc/apt/sources.list.d/pve-no-subscription.sources <<'SOURCES'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
SOURCES

apt update && apt full-upgrade -y

Cette manipulation est aussi disponible dans l'interface : Datacenter → pve1 → Repositories.

Installez quelques outils utiles et redémarrez si un nouveau noyau a été installé :

apt install -y htop iotop vim curl

Étape 3 : Réseau

C'est l'étape qui bloque le plus de monde, parce qu'elle dépend de ce que vous avez : une seule IP publique, ou plusieurs.

Comprendre les ponts (bridges)

Proxmox connecte les VM au réseau via des ponts virtuels :

• vmbr0 est créé par l'installateur, attaché à votre carte réseau physique, et porte l'IP publique du serveur. Une VM branchée dessus est « sur le même câble » que le serveur.
• Vous pouvez créer d'autres ponts (vmbr1, vmbr2…) sans carte physique : ce sont des réseaux privés internes au serveur, invisibles depuis l'extérieur.

Le fichier de configuration est /etc/network/interfaces. Après l'installation, il ressemble à :

auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 203.0.113.10/24
        gateway 203.0.113.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

Cas A : une seule IP publique, VM en réseau privé avec NAT

C'est le cas le plus courant et le plus simple. Les VM reçoivent des adresses privées (10.0.0.x), sortent sur Internet via l'IP du serveur (NAT), et vous exposez des services précis avec des redirections de port ou un reverse proxy.

Ajoutez un second pont à /etc/network/interfaces :

auto vmbr1
iface vmbr1 inet static
        address 10.0.0.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up   iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o vmbr0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o vmbr0 -j MASQUERADE

Appliquez sans redémarrer :

ifreload -a
ip addr show vmbr1

Les VM branchées sur vmbr1 utiliseront 10.0.0.1 comme passerelle. Pour leur distribuer automatiquement des adresses, installez un serveur DHCP léger sur l'hôte :

apt install -y dnsmasq
cat > /etc/dnsmasq.d/vmbr1.conf <<'DNSMASQ'
interface=vmbr1
bind-interfaces
dhcp-range=10.0.0.100,10.0.0.200,12h
dhcp-option=option:router,10.0.0.1
dhcp-option=option:dns-server,1.1.1.1,8.8.8.8
DNSMASQ
systemctl restart dnsmasq

Pour rendre accessible depuis Internet un service d'une VM (par exemple le port 443 de la VM 10.0.0.101), ajoutez une redirection dans le bloc vmbr1 :

        post-up   iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 443 -j DNAT --to 10.0.0.101:443
        post-down iptables -t nat -D PREROUTING -i vmbr0 -p tcp --dport 443 -j DNAT --to 10.0.0.101:443

En pratique, on préfère souvent une VM « reverse proxy » (Nginx ou Traefik) qui reçoit les ports 80 et 443 et distribue vers les autres VM par nom de domaine : voir Configurer un reverse proxy.

Cas B : des IP additionnelles, une IP publique par VM

Si vous avez commandé des IP additionnelles (option IPv4 supplémentaire sur les serveurs dédiés YorkHost), chaque VM peut avoir la sienne et se comporter exactement comme un VPS indépendant.

La façon dont une IP additionnelle est routée dépend de l'infrastructure de l'hébergeur : soit elle est bridgée (la VM la configure directement sur vmbr0 avec la même passerelle que l'hôte), soit elle est routée vers l'IP principale du serveur (la VM utilise alors l'hôte comme passerelle). Les deux fonctionnent avec Proxmox mais ne se configurent pas de la même façon.

Configuration bridgée (la VM porte l'IP sur vmbr0), dans la VM :

# /etc/network/interfaces dans la VM
auto ens18
iface ens18 inet static
        address 203.0.113.50/24
        gateway 203.0.113.1

Configuration routée (l'hôte relaie), sur l'hôte Proxmox :

auto vmbr0
iface vmbr0 inet static
        address 203.0.113.10/24
        gateway 203.0.113.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up ip route add 203.0.113.50/32 dev vmbr0

Et dans la VM, l'IP en /32 avec l'hôte comme passerelle :

auto ens18
iface ens18 inet static
        address 203.0.113.50/32
        gateway 203.0.113.10
        pointopoint 203.0.113.10

Demandez la fiche réseau à notre support

Le mode de routage (bridgé ou routé) et l'éventuelle nécessité d'associer une adresse MAC virtuelle à chaque IP additionnelle sont propres à chaque infrastructure. Avant de configurer vos VM, ouvrez un ticket en précisant que vous installez Proxmox : nous vous indiquons la configuration exacte pour votre serveur, et nous pouvons ajouter des IP additionnelles à la demande.

Étape 4 : Sécuriser l'hôte

Votre hyperviseur est la clé de toutes vos VM. Il mérite plus d'attention qu'elles.

SSH et utilisateur

Appliquez les bases du guide Sécuriser SSH : clés uniquement, PermitRootLogin prohibit-password, Fail2ban. Dans l'interface Proxmox, créez un compte administrateur distinct de root : Datacenter → Permissions → Users → Add, realm Proxmox VE authentication server, puis attribuez-lui le rôle Administrator sur /. Activez la double authentification (TOTP) sur ce compte : Datacenter → Permissions → Two Factor.

Firewall Proxmox

Proxmox intègre un firewall à trois niveaux (datacenter, nœud, VM), piloté par l'interface. Activez-le au niveau datacenter avec une règle qui n'ouvre l'interface web et SSH qu'à votre IP :

Datacenter → Firewall → Options : Firewall: Yes. Puis Datacenter → Firewall → Add :

Direction	Action	Source	Protocole	Port	Commentaire
in	ACCEPT	VOTRE_IP/32	tcp	8006	Interface web
in	ACCEPT	VOTRE_IP/32	tcp	22	SSH
in	ACCEPT		icmp		Ping

Ajoutez la règle d'accès avant d'activer le firewall

La politique d'entrée par défaut est DROP. Si vous activez le firewall sans règle qui autorise votre IP sur les ports 8006 et 22, vous perdez l'accès. La console IPMI vous permettrait de le récupérer, mais autant l'éviter. Si votre IP change souvent (accès domestique), utilisez plutôt un VPN WireGuard sur l'hôte ou une VM bastion.

Le firewall de chaque VM se gère ensuite indépendamment dans VM → Firewall, ce qui permet d'ouvrir 443 sur la VM web et rien sur la VM base de données.

Certificat TLS valide

Pour ne plus avoir l'avertissement du navigateur : pve1 → System → Certificates → ACME, enregistrez un compte Let's Encrypt, ajoutez un domaine (pve1.example.com pointant vers l'IP du serveur) et cliquez Order Certificates Now. Le port 80 doit être joignable pendant la validation.

Étape 5 : Créer une première machine virtuelle

Téléverser une ISO

pve1 → local → ISO Images → Download from URL, collez l'URL d'une ISO Debian netinst (https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/) et validez. Proxmox la télécharge directement, sans passer par votre connexion.

Créer la VM

Create VM en haut à droite. Les réglages qui font la différence entre une VM qui rame et une VM performante :

Onglet	Réglage recommandé
General	Un nom parlant, un VM ID (100, 101…)
OS	L'ISO Debian, type Linux
System	Machine q35, BIOS OVMF (UEFI) pour un OS récent, SCSI Controller VirtIO SCSI single, cochez Qemu Agent
Disks	Bus SCSI, stockage local-lvm ou local-zfs, cochez Discard (SSD) et IO thread
CPU	Type host (expose toutes les instructions du CPU physique), le nombre de cœurs souhaité
Memory	La RAM souhaitée ; cochez Ballooning si vous surallouez
Network	Bridge vmbr1 (NAT) ou vmbr0 (IP publique), modèle VirtIO (paravirtualized)

Le choix VirtIO partout (disque, réseau) est ce qui donne aux VM KVM des performances proches du natif : le système invité sait qu'il est virtualisé et communique directement avec l'hyperviseur au lieu d'émuler un matériel ancien.

Démarrez la VM, ouvrez Console, installez Debian normalement. Une fois installée, dans la VM :

apt install -y qemu-guest-agent
systemctl enable --now qemu-guest-agent

L'agent permet à Proxmox de connaître l'IP de la VM, de l'éteindre proprement et de figer le système de fichiers pendant les snapshots.

Étape 6 : Un template cloud-init pour déployer en trente secondes

Installer Debian à la main pour chaque VM devient vite pénible. La bonne pratique consiste à créer un template à partir d'une image cloud officielle, puis à le cloner en indiquant simplement le hostname, l'IP et votre clé SSH. C'est exactement ainsi que fonctionnent les hébergeurs de VPS.

Sur l'hôte Proxmox :

cd /var/lib/vz/template
wget https://cloud.debian.org/images/cloud/trixie/latest/debian-13-generic-amd64.qcow2

# Crée la VM 9000 qui servira de template
qm create 9000 --name debian-13-template --memory 2048 --cores 2 --cpu host \
  --machine q35 --bios ovmf --efidisk0 local-lvm:1,efitype=4m \
  --net0 virtio,bridge=vmbr1 --scsihw virtio-scsi-single --agent enabled=1

# Importe l'image cloud comme disque principal
qm set 9000 --scsi0 local-lvm:0,import-from=/var/lib/vz/template/debian-13-generic-amd64.qcow2,discard=on,iothread=1
qm set 9000 --boot order=scsi0

# Ajoute le lecteur cloud-init et une console série (les images cloud l'utilisent)
qm set 9000 --ide2 local-lvm:cloudinit
qm set 9000 --serial0 socket --vga serial0

# Agrandit le disque (l'image fait 3 Go) et convertit en template
qm disk resize 9000 scsi0 20G
qm template 9000

Remplacez local-lvm par local-zfs si vous avez installé en ZFS.

Configurez ensuite les valeurs cloud-init par défaut dans VM 9000 → Cloud-Init : utilisateur (debian ou admin), votre clé SSH publique, DNS, et IP Config en DHCP si vous avez installé dnsmasq à l'étape 3.

Pour créer une nouvelle VM :

qm clone 9000 101 --name web-1 --full
qm set 101 --memory 4096 --cores 2 --ipconfig0 ip=10.0.0.101/24,gw=10.0.0.1
qm start 101

Trente secondes plus tard, ssh admin@10.0.0.101 fonctionne avec votre clé, le disque est redimensionné automatiquement, qemu-guest-agent est déjà là. Vous pouvez faire la même chose depuis l'interface (clic droit sur le template → Clone), puis ajuster l'onglet Cloud-Init.

Étape 7 : Conteneurs LXC, l'alternative légère

Pour un service Linux simple (un reverse proxy, un serveur DNS, un bot Discord), un conteneur LXC consomme dix fois moins de RAM qu'une VM et démarre en une seconde. Il partage le noyau de l'hôte, ce qui l'exclut pour Windows, pour un noyau personnalisé ou pour une isolation forte.

pve1 → local → CT Templates → Templates, téléchargez debian-13-standard. Puis Create CT : cochez Unprivileged container (toujours, sauf besoin précis), donnez une clé SSH, un disque de 8 Go, 1 cœur, 512 Mo de RAM, le réseau sur vmbr1.

Si vous voulez faire tourner Docker dans un LXC, activez les options Nesting et keyctl dans CT → Options → Features ; le guide Permissions Docker sous Proxmox détaille les pièges. Pour un hôte Docker sérieux, préférez tout de même une VM.

Étape 8 : Snapshots et sauvegardes

Snapshots

VM → Snapshots → Take Snapshot avant toute mise à jour risquée. Avec ZFS ou LVM-thin, c'est instantané. Revenir en arrière prend quelques secondes. Un snapshot n'est pas une sauvegarde : il vit sur le même disque que la VM.

Sauvegardes vzdump

Proxmox intègre un planificateur de sauvegardes : Datacenter → Backup → Add. Choisissez le stockage local (ou mieux, un stockage dédié), une planification (chaque nuit à 2 h), le mode Snapshot (sans arrêt de la VM, cohérent grâce à l'agent invité), la compression ZSTD, et une politique de rétention (keep-daily=7, keep-weekly=4).

Ces sauvegardes sont des fichiers .vma.zst dans /var/lib/vz/dump/. Comme elles restent sur le serveur, il faut les répliquer hors-site. Deux options :

• Proxmox Backup Server (PBS), installé sur un second serveur ou un VPS Storage YorkHost : sauvegardes incrémentales dédupliquées, vérification d'intégrité, restauration fichier par fichier. C'est la solution native et la plus efficace.
• Restic ou Borg pour envoyer le répertoire dump/ vers n'importe quel stockage distant : voir Backup automatique offsite avec Restic ou Borg.

Testez une restauration une fois par trimestre : local → Backups → sélectionner → Restore vers un nouvel ID de VM, démarrez-la, vérifiez, supprimez-la.

Étape 9 : Exploitation au quotidien

Mises à jour

Proxmox affiche les mises à jour disponibles dans pve1 → Updates. En ligne de commande :

apt update && apt full-upgrade -y

Un nouveau noyau demande un redémarrage de l'hôte, donc de toutes les VM. Planifiez-le, et avant de redémarrer, prenez l'habitude de vérifier que toutes les VM ont onboot=1 (VM → Options → Start at boot) et un ordre de démarrage sensé (la base de données avant l'application).

Surveiller les ressources

Le Summary de chaque nœud montre CPU, RAM, IO et réseau. Deux règles :

• La RAM totale allouée aux VM peut dépasser la RAM physique (ballooning, KSM), mais gardez au moins 10 % libre pour l'hôte et le cache ZFS.
• Surveillez l'IO delay : au-dessus de 10 % en continu, votre stockage sature. C'est la raison d'être des NVMe sur les dédiés YorkHost.

Pour aller plus loin, l'hôte Proxmox expose ses métriques pour Prometheus ou InfluxDB (Datacenter → Metric Server) ; voir Monitoring serveur.

Commandes utiles

Action	Commande
Lister les VM	qm list
Démarrer / arrêter proprement / forcer	qm start 101 / qm shutdown 101 / qm stop 101
Lister les conteneurs	pct list
Entrer dans un conteneur	pct enter 200
Voir l'état du stockage	pvesm status
État ZFS	zpool status / zfs list
Sauvegarder une VM maintenant	vzdump 101 --storage local --mode snapshot --compress zstd
Restaurer une sauvegarde	qmrestore /var/lib/vz/dump/vzdump-qemu-101-*.vma.zst 105

Checklist

• Proxmox installé, ZFS RAID1 ou LVM-thin selon les disques
• Dépôt no-subscription activé, système à jour
• vmbr1 en NAT avec dnsmasq, ou IP additionnelles configurées selon la fiche réseau YorkHost
• SSH par clé, Fail2ban, compte admin non-root avec TOTP
• Firewall Proxmox activé avec l'interface web et SSH limités à votre IP
• Certificat Let's Encrypt sur l'interface
• Template cloud-init créé et testé
• Sauvegardes vzdump planifiées, répliquées hors-site, restauration testée
• Start at boot et ordre de démarrage définis sur chaque VM

Dépannage

Plus d'accès à l'interface web après activation du firewall

Ouvrez la console IPMI, connectez-vous en root, puis pve-firewall stop. Corrigez la règle dans /etc/pve/firewall/cluster.fw et relancez avec pve-firewall start.

Les VM sur vmbr1 n'ont pas Internet

Dans l'ordre : cat /proc/sys/net/ipv4/ip_forward doit afficher 1 ; iptables -t nat -L POSTROUTING -n doit montrer la règle MASQUERADE ; la VM doit avoir 10.0.0.1 comme passerelle et un DNS configuré. Si ifreload -a n'a pas appliqué les post-up, un systemctl restart networking les rejoue.

Une VM avec IP additionnelle est injoignable

Le mode de routage ne correspond pas à celui de l'infrastructure (bridgé configuré en routé ou l'inverse), ou l'IP additionnelle nécessite une adresse MAC virtuelle spécifique sur l'interface de la VM. Consultez la fiche réseau fournie par le support.

« TASK ERROR: KVM virtualisation configured, but not available »

La virtualisation matérielle (Intel VT-x / AMD-V) est désactivée dans le BIOS. Activez-la via la console IPMI au démarrage. Tous les serveurs dédiés YorkHost la supportent.

Une VM est très lente

Vérifiez que le disque et la carte réseau sont en VirtIO, que le type de CPU est host et que qemu-guest-agent tourne. Puis regardez l'IO delay de l'hôte : si un autre invité sature le disque, limitez-le avec VM → Hardware → Disk → Bandwidth.

L'espace local-lvm ne se libère pas après suppression de fichiers dans une VM

L'option Discard n'était pas cochée sur le disque, ou la VM n'exécute pas fstrim. Activez Discard, puis dans la VM : fstrim -av (Debian le planifie hebdomadairement via fstrim.timer).

Le bare-metal YorkHost, prêt pour Proxmox

Nos serveurs dédiés sont livrés en moins de 24 h pour les configurations en stock, avec accès root, console IPMI/KVM, rDNS gérable depuis l'espace client, réseau 1 à 10 Gbps sur notre AS199415 et Anti-DDoS Stormwall & Gcore inclus. Ils sont hébergés dans deux datacenters parisiens certifiés Tier III (Digital Realty PAR5 et DC2Scale PAR3). La RAM ECC et les SSD NVMe font toute la différence pour un hyperviseur qui fait tourner une dizaine de VM.

Si votre objectif est de proposer des VPS à vos propres clients, jetez aussi un œil au programme Revendeur VPS : la marque blanche sans avoir à gérer le matériel.