Peut-on installer Proxmox sur un VPS ?

La réponse courte

La virtualisation imbriquée consiste à exécuter un hyperviseur dans une machine virtuelle : votre VPS est déjà un invité, et vous voulez qu’il héberge ses propres invités. Elle ne fonctionne que si l’hyperviseur de votre fournisseur expose délibérément les extensions de virtualisation du processeur à votre instance. Vérifiez /proc/cpuinfo pour rechercher l’indicateur vmx (Intel) ou svm (AMD). Si aucun des deux n’apparaît, aucune configuration effectuée dans le VPS ne pourra résoudre le problème.

Commençons par clarifier un point : Docker n’a besoin de rien de tout cela. Les conteneurs partagent le kernel de votre VPS et n’utilisent jamais /dev/kvm. Si votre objectif réel est d’exécuter plusieurs services dans des conteneurs sur votre serveur, vous disposez déjà de tout ce qu’il faut. La virtualisation imbriquée devient utile si vous avez besoin d’un second kernel, d’un lab Proxmox, d’un invité Windows, de microVM Firecracker, d’un émulateur Android, d’un environnement de test Kubernetes composé de véritables machines virtuelles ou de runners CI qui démarrent des images de machines virtuelles.

Ce qui est réellement imbriqué

Trois couches :

• L0, l’hyperviseur du fournisseur, sur le serveur physique. Vous n’y avez pas accès.
• L1, votre VPS. Pour L0, il s’agit simplement d’un guest.
• L2, la VM que vous souhaitez exécuter dans votre VPS.

La virtualisation matérielle repose sur VT-x (l’indicateur vmx) et EPT sur Intel, ainsi que sur AMD-V / SVM (svm) et RVI/NPT sur AMD. Un hyperviseur utilise ces instructions pour passer en mode guest et permettre au processeur de parcourir simultanément deux tables de pages.

Aucune de ces technologies n’a été conçue pour être réentrante. La virtualisation imbriquée est donc émulée : lorsque L1 exécute une instruction VMX, celle-ci déclenche une interception vers L0, qui gère pour L1 les structures shadow de L2. KVM le fait efficacement, mais L0 doit effectuer un traitement supplémentaire à chaque sortie de VM. C’est pourquoi le fournisseur doit activer explicitement cette fonction.

Deux conditions doivent être réunies pour obtenir une L2 accélérée :

1. Le module KVM de L0 doit être chargé avec nested=1.
2. L0 doit fournir à votre VPS un modèle de processeur qui expose l’indicateur correspondant : <cpu mode='host-passthrough'/> dans libvirt, cpu: host dans Proxmox et -cpu host avec QEMU brut. Un modèle générique émulé (qemu64, kvm64) masque vmx, même lorsque la virtualisation imbriquée est activée globalement.

Vérifier votre VPS en une minute

# 1. Are you in a VM, and under what?
systemd-detect-virt          # kvm, vmware, xen, microsoft, or "none" on metal

# 2. Does the CPU expose the extensions to you?
grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u
lscpu | grep -i -E 'virtual|hypervisor'

# 3. The definitive check
sudo apt update && sudo apt install -y cpu-checker
kvm-ok

# 4. The device node the whole stack depends on
ls -l /dev/kvm

Une instance opérationnelle affiche vmx ou svm, kvm-ok indique KVM acceleration can be used et /dev/kvm existe avec le mode root:kvm 660. Si le flag est présent, mais pas le device node, chargez le module manuellement et consultez le journal du noyau :

sudo modprobe kvm_intel     # or kvm_amd
sudo dmesg | tail -n 20

Un fichier est cité en permanence et souvent mal interprété :

cat /sys/module/kvm_intel/parameters/nested   # Y or N

Dans votre VPS, il s’agit du paramètre de votre module KVM. Il indique si un guest L2 pourrait imbriquer un troisième niveau. Il ne dit rien sur l’activation du nesting par L0 pour votre VPS : /proc/cpuinfo et kvm-ok répondent à cette question. Le paramètre nested est celui que vous définissez sur une machine qui vous appartient entièrement :

echo 'options kvm_intel nested=1' | sudo tee /etc/modprobe.d/kvm-nested.conf
sudo modprobe -r kvm_intel && sudo modprobe kvm_intel

La suppression du module est refusée lorsqu’une VM est en cours d’exécution. Arrêtez donc d’abord les guests.

Pourquoi la plupart des hébergeurs de VPS la désactivent

• Migration à chaud. Vous attribuer vmx revient à exposer un modèle de CPU qui prend en charge ce flag. Une machine virtuelle qui dépend de ces fonctionnalités CPU ne peut pas être migrée de manière fiable vers une machine dont le CPU ne les prend pas en charge. Un hébergeur qui évacue des nœuds en migrant les clients renonce à cette possibilité dès qu’il active la virtualisation imbriquée.
• Surface d’attaque. Les chemins VMX/SVM imbriqués comptent parmi les parties les plus complexes de la couche de virtualisation du kernel, avec un historique de CVE à l’avenant.
• L0 n’est peut-être pas KVM. Si systemd-detect-virt affiche vmware, xen ou microsoft, les règles de virtualisation imbriquée sont celles de cette stack, et non celles de KVM.

Aucun flag sur votre instance ? Demandez au support (certains l’activent VM par VM), choisissez une offre qui documente la virtualisation imbriquée ou passez à une machine dédiée. La suite suppose que vous disposez de root sur une machine qui affiche ce flag.

Exécuter un invité L2 avec libvirt

sudo apt install -y qemu-system-x86 libvirt-daemon-system virtinst ovmf
sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt,kvm "$USER"   # log out and back in

virt-install \
  --name guest1 \
  --memory 2048 \
  --vcpus 2 \
  --cpu host-passthrough \
  --disk path=/var/lib/libvirt/images/guest1.qcow2,size=20,format=qcow2,bus=virtio \
  --network network=default,model=virtio \
  --os-variant debian13 \
  --location https://deb.debian.org/debian/dists/trixie/main/installer-amd64/ \
  --graphics none \
  --console pty,target_type=serial \
  --extra-args 'console=ttyS0,115200n8'

Aucune session graphique n’est nécessaire. Une installation série dure un certain temps ; lancez-la donc dans un shell persistant : le même workflow tmux qui maintient les sessions Claude Code actives sur un VPS conserve une console virt-install attachée malgré une connexion SSH interrompue. Si --os-variant debian13 est refusé, votre osinfo-db est antérieur à cette version ; exécutez osinfo-query os et choisissez un nom existant. --cpu host-passthrough transmet vmx à la couche L2, uniquement si L2 doit à son tour virtualiser. Rendez l’invité compatible avec le démarrage automatique avec virsh autostart guest1.

Le bus virtio utilisé par le disque et la carte réseau n’est pas anodin : les périphériques IDE et e1000 émulés provoquent beaucoup plus souvent des sorties vers l’hyperviseur que les files virtio, et avec la virtualisation imbriquée, chaque sortie est traitée deux fois.

Réseau : la partie que les tutoriels omettent

Votre VPS possède une seule IP publique et se trouve derrière une infrastructure qui filtre les adresses MAC inconnues. Deux conséquences en découlent.

Le bridging de guests L2 sur le réseau public ne fonctionnera généralement pas. Placez br0 sur la carte réseau publique, attribuez sa propre adresse MAC au guest, et vous verrez les requêtes ARP sortir sans recevoir de réponse : le switch du fournisseur supprime les trames provenant d’une adresse MAC qui ne vous a jamais été attribuée. Si c’est le symptôme observé, cessez de déboguer le bridge : c’est le fonctionnement attendu.

Utilisez plutôt le réseau NAT. libvirt fournit default : virbr0, 192.168.122.0/24, des baux dnsmasq et une connectivité sortante immédiatement opérationnelle. Pour les connexions entrantes, terminez TLS sur L1 et utilisez un proxy vers le guest. Les chemins des certificats ci-dessous proviennent de l’émission d’un certificat Let’s Encrypt avec Certbot sur Nginx :

server {
    listen 443 ssl;
    server_name lab.example.com;

    ssl_certificate     /etc/letsencrypt/live/lab.example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/lab.example.com/privkey.pem;

    location / {
        proxy_pass http://192.168.122.50:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

Commencez par attribuer un bail statique au guest (virsh net-edit default), afin que l’adresse indiquée dans proxy_pass reste inchangée.

Les interfaces d’administration ne doivent pas être exposées sur Internet : VNC sur 5900 et l’interface web Proxmox sur 8006 doivent rester liées à loopback. Accédez-y via un tunnel SSH (ssh -N -L 8006:127.0.0.1:8006 you@your-vps) ou au moyen d’un VPN WireGuard auto-hébergé vers le VPS, qui place toute la plage de guests 192.168.122.0/24 à un seul saut réseau privé. Limitez le firewall à sudo ufw allow 22,80,443/tcp, et à rien d’autre. Si les guests perdent leur connectivité sortante juste après l’activation d’ufw, la cause habituelle est DEFAULT_FORWARD_POLICY="DROP" dans /etc/default/ufw. Définissez-le sur ACCEPT, puis rechargez ufw.

Proxmox sur un VPS

Proxmox VE 9 repose sur Debian 13. Il s’installe donc sur un VPS Debian en ajoutant le dépôt pve-no-subscription et le paquet proxmox-ve. Reprenez les lignes du dépôt et du keyring dans la documentation officielle actuelle de Proxmox. Une URL copiée depuis un ancien article de blog peut bloquer l’installation. Avant de consacrer une soirée à la configuration réseau ci-dessous, il est préférable de déterminer si Proxmox a réellement sa place sur du matériel loué. La comparaison des coûts et des capacités entre un serveur Proxmox à domicile et un VPS loué répond à cette question en intégrant déjà les calculs liés à l’alimentation et au matériel.

Les paquets ne sont pas le point difficile. Proxmox attend que vmbr0 soit bridgé sur une carte réseau physique, ce qui mène directement à l’impasse du filtrage MAC décrite plus haut. Sur un VPS, la configuration qui fonctionne est un vmbr0 en NAT ou routé, sans port physique attaché, avec les guests sur une plage privée et des règles DNAT ou un reverse proxy sur l’hôte pour les services publics. Lorsque les services exposés sont des conteneurs plutôt que des VM, Traefik qui place plusieurs applications derrière un même fichier Docker Compose assure le même routage avec des certificats automatiques. Prenez d’abord un snapshot de /etc/network/interfaces : une mauvaise définition du bridge peut vous verrouiller hors d’une machine dont vous n’avez peut-être pas accès à la console.

Performances, sans exagération

L’imbrication est plus lente qu’une virtualisation à un seul niveau, et le mécanisme en cause est précis : le coût ne vient pas des accès mémoire, mais des sorties du mode invité. Lorsque EPT/NPT est disponible, L0 gère des tables de pages shadow pour L2 et les lectures mémoire ordinaires s’exécutent à la vitesse du matériel. Ce qui coûte cher, ce sont les opérations qui quittent le mode invité : E/S, interruptions de timer, MMIO et interruptions interprocesseur. En effet, une sortie de L2 est traitée par L0 et peut être réfléchie vers L1. Les traitements limités par le CPU, qui utilisent des données déjà présentes en RAM, restent proches des performances natives. En revanche, les traitements dominés par les appels système, les paquets et les E/S disque subissent les différentes couches.

Conclusion : utilisez des périphériques virtio partout. Votre fichier qcow2 se trouve sur un disque que le fournisseur a déjà virtualisé. Deux couches de thin provisioning sont alors empilées, et cache=none sur le disque invité empêche les mêmes blocs de rester simultanément dans deux caches de pages. Aucun chiffre de benchmark ici : mesurez votre propre charge de travail sur votre propre instance.

Modes de défaillance et messages affichés

INFO: /dev/kvm does not exist / KVM acceleration can NOT be used depuis kvm-ok. Soit le module n’est pas chargé, soit le flag n’est pas exposé. Vérifiez d’abord /proc/cpuinfo.

kvm: disabled by bios dans dmesg. Sur une machine bare metal, activez l’option VT-x/SVM dans le firmware. Dans un VPS, cela signifie que L0 ne vous transmet pas les extensions. Aucune commande saisie dans le guest ne peut modifier ce comportement.

modprobe: ERROR: could not insert 'kvm_intel': Operation not supported. Le CPU vu par votre kernel ne fournit pas vmx. Là encore, c’est une décision de L0.

Could not access KVM kernel module: Permission denied. Le problème vient des permissions, pas du matériel. ls -l /dev/kvm doit afficher le groupe kvm et le mode 660. Ajoutez-vous à ce groupe, puis ouvrez une nouvelle session de login. L’appartenance à un groupe ne s’applique pas à une session déjà ouverte.

kvm: Device or resource busy au démarrage de QEMU. Un autre module d’hyperviseur utilise le CPU. Exécutez lsmod, recherchez vboxdrv ou les modules VMware à côté de kvm_intel, puis déchargez le module dont vous ne voulez pas.

/var/run/libvirt/libvirt-sock: No such file or directory depuis virsh. Le daemon est arrêté : sudo systemctl enable --now libvirtd.

Proxmox : KVM virtualisation configured, but not available. Un guest utilise l’accélération KVM sur un host qui ne peut pas la fournir. Corrigez la virtualisation imbriquée, ou désactivez cette option et acceptez l’émulation.

Émulateur Android : x86_64 emulation currently requires hardware acceleration! /dev/kvm à nouveau, généralement à cause du groupe.

Aucune erreur, mais tout est extrêmement lent. Sans flag d’accélération, QEMU bascule sur TCG, son émulateur logiciel. Le fonctionnement est correct, mais lent : un boot mesuré en secondes prend alors plusieurs minutes. Passez explicitement -accel kvm afin que QEMU s’arrête avec une erreur au lieu de lancer discrètement l’émulation.

Un guest disparaît en cours d’exécution. Consultez dmesg pour rechercher Out of memory: Killed process ... qemu-system-x86_64. Un guest L2 est un processus sur L1, et l’OOM killer le traite comme n’importe quel autre processus. La RAM de L2 est prélevée sur l’allocation fixe de L1 ; elle ne peut pas emprunter de mémoire à l’host.

Fonctionnement : sauvegardes, mises à niveau, limites

Sauvegardes. Copier le fichier qcow2 d’un guest en fonctionnement produit une image corrompue. Utilisez soit virsh shutdown guest1 et copiez le fichier, soit créez un snapshot externe (virsh snapshot-create-as guest1 snap1 --disk-only --atomic) afin que les écritures soient redirigées vers un overlay pendant que vous copiez la base devenue statique, puis réintégrez-le avec virsh blockcommit. Transférez les copies hors du VPS : un snapshot sur le même disque ne protège contre rien.

Mises à niveau. apt full-upgrade installe de nouveaux modules kvm_intel/kvm_amd, mais le kernel en cours d’exécution conserve les anciens jusqu’au redémarrage. Conservez le kernel précédent et relancez kvm-ok après chaque modification du kernel : si l’hôte redémarre sans vmx, il suffit alors de sélectionner une autre entrée de boot pour le remettre en service.

Limites de cette architecture. Une seule IP publique signifie que chaque service L2 accède au réseau externe par l’intermédiaire d’un proxy ou d’une règle DNAT sur L1. La migration à chaud n’est pas possible. En cas de contention CPU, le chemin de sortie nested est le premier à en subir les effets. De plus, un hyperviseur qui héberge plusieurs guests est une machine dont la RAM est déjà allouée : les VM nested ne peuvent pas contourner une allocation fixe par overcommit. Lorsqu’un lab dépasse ces limites, la solution n’est pas d’ajouter un niveau nested, mais d’utiliser une machine dédiée où vous êtes L0 et où aucune de ces contraintes ne s’applique.

FAQ

Ai-je besoin de la virtualisation imbriquée pour exécuter Docker sur un VPS ?

Non. Les conteneurs partagent le kernel de votre VPS et n’ouvrent jamais /dev/kvm. Une instance standard, sans l’option vmx ni le flag svm, exécute correctement Docker et Docker Compose. La virtualisation imbriquée est uniquement nécessaire lorsque vous voulez un second kernel : un lab Proxmox, un guest Windows, des microVM Firecracker, un émulateur Android ou des runners CI qui démarrent des images de VM.

Comment vérifier si mon VPS prend en charge la virtualisation imbriquée ?

Exécutez grep -o -E 'vmx|svm' /proc/cpuinfo | sort -u, puis kvm-ok du package cpu-checker. Une instance compatible affiche vmx (Intel) ou svm (AMD). kvm-ok indique KVM acceleration can be used, et /dev/kvm existe avec le groupe kvm et le mode 660. Ignorez /sys/module/kvm_intel/parameters/nested pour cette vérification : ce fichier décrit votre propre module KVM, pas ce que l’hyperviseur du fournisseur vous a exposé.

Pourquoi la plupart des fournisseurs de VPS désactivent-ils la virtualisation imbriquée ?

Exposer vmx revient à fournir au guest un modèle de CPU qui inclut ce flag. Un guest qui dépend de ces fonctionnalités CPU ne peut pas être migré à chaud vers une machine dont le CPU ne les prend pas en charge. Un fournisseur qui répartit la charge des nœuds en déplaçant les clients doit donc renoncer à cette possibilité. Les chemins de code VMX/SVM imbriqués présentent également un historique important de CVE. Certains hébergeurs l’activent encore par VM sur demande. D’autres indiquent que la virtualisation imbriquée dépend de l’offre choisie.

Ma VM imbriquée n’a pas de réseau sur le bridge public. Quel est le problème ?

Le switch du fournisseur abandonne les trames provenant d’une adresse MAC qu’il ne vous a jamais attribuée. Un guest L2 relié au bridge de la carte réseau publique envoie donc des requêtes ARP sans recevoir de réponse. Arrêtez de déboguer br0. Utilisez le réseau NAT default de libvirt (virbr0, 192.168.122.0/24), attribuez un bail statique au guest, puis publiez les services accessibles depuis Internet via un reverse proxy ou une règle DNAT sur le VPS lui-même.

Quelle est la perte de performances d’une VM imbriquée ?

Le coût concerne les sorties de VM, pas les accès mémoire. Lorsque EPT/NPT est actif, les lectures et écritures ordinaires dans L2 s’exécutent à la vitesse du matériel. En revanche, les entrées-sorties, les interruptions de timer, les accès MMIO et les IPI sont traités par L0 et peuvent être renvoyés via L1. Les traitements limités par le CPU, qui utilisent des données déjà présentes en RAM, restent proches des performances natives. Les charges importantes en appels système, en paquets réseau ou en accès disque subissent le coût de chaque couche. Utilisez des périphériques virtio partout et cache=none sur les disques des guests, puis mesurez les performances de votre propre charge.