ProxMenux/web/messages/fr/docs/post-install/virtualization.json

{
  "meta": {
    "title": "Post-installation : Virtualisation | Documentation ProxMenux",
    "description": "Options de virtualisation dans le script post-installation personnalisable ProxMenux : installer automatiquement le bon agent invité si Proxmox fonctionne à l'intérieur d'un VM, et activer IOMMU / VFIO afin que vous puissiez passer les périphériques PCI (GPU, NIC, HBAs) à vos propres VM."
  },
  "header": {
    "title": "Post-Installation : Virtualisation",
    "section": "Paramètres post-installation de Proxmox"
  },
  "intro": {
    "title": "Ce que cette catégorie couvre",
    "body": "Deux options indépendantes. <strong>Installer l’agent invité adapté</strong> aide lorsque Proxmox fonctionne lui-même dans un autre hyperviseur. <strong>Activer la prise en charge de VFIO IOMMU</strong> intéresse la plupart des utilisateurs : active les fonctions du noyau pour attribuer directement un GPU, HBA ou une carte réseau à une VM avec des performances quasi natives."
  },
  "guestAgent": {
    "heading": "installer l'agent invité approprié",
    "intro": "Détecte l'environnement de virtualisation sur lequel s'exécute l'hôte Proxmox (en utilisant <code>systemd-detect-virt</code> et <code>dmidecode</code>) et installe le paquet d'outils invités correspondant afin que l'hyperviseur externe puisse communiquer avec Proxmox de manière propre (arrêt progressif, synchronisation d'horloge, reportage IP, etc.).",
    "headerDetected": "Hôte détecté",
    "headerPackage": "Paquet installé",
    "rows": [
      {
        "detected": "QEMU / KVM",
        "package": "qemu-guest-agent"
      },
      {
        "detected": "VMware (ESXi, Workstation)",
        "package": "open-vm-tools"
      },
      {
        "detected": "VirtualBox",
        "package": "virtualbox-guest-utils"
      },
      {
        "detected": "Matériel physique (aucun)",
        "package": "— non-op, rien installé"
      }
    ],
    "skipTitle": "Ignorez cette option si Proxmox fonctionne sur du matériel physique",
    "skipBody": "Si Proxmox fonctionne directement sur le matériel, le cas habituel, cocher cette option ne change rien : le détecteur retourne <code>none</code> et le script quitte sans modification. L’option concerne seulement les installations où Proxmox fonctionne <em>en tant qu’invité</em> pour des tests ou des laboratoires."
  },
  "vfio": {
    "heading": "Activer la prise en charge de VFIO IOMMU",
    "intro": "Active IOMMU sur l’hôte et charge les modules permettant l’accès direct PCI (<code>vfio</code>, <code>vfio_iommu_type1</code>, <code>vfio_pci</code>). Vous pouvez alors attribuer un périphérique physique à une VM, qui y accède directement avec des performances proches du matériel natif.",
    "whoTitle": "Qui en a besoin ?",
    "whoItems": [
      "Vous voulez attribuer directement un GPU à une VM Windows de jeu ou à une VM macOS.",
      "Vous avez un 10G NIC dédié pour un pare-feu/routeur VM (OPNsense, pfSense).",
      "Vous souhaitez passer un HBA directement à un TrueNAS/Unraid VM pour ZFS sur disques nus.",
      "Vous prévoyez utiliser <em>Coral TPU</em>, une carte de capture, ou un dongle SDR dans un VM."
    ],
    "whoOutro": "Si aucun de ces éléments ne s'applique, vous pouvez ignorer cette option en toute sécurité. Pour le relais vers un <strong>LXC</strong> (et non un VM), IOMMU n'est <em>pas</em> requis.",
    "doesTitle": "Ce que fait ProxMenux",
    "doesIntro": "La fonction tient compte du chargeur de démarrage : elle détecte ZFS (systemd-boot) ou LVM/ext4 (GRUB) et écrit dans le bon fichier. Elle est idempotente : les paramètres déjà présents ne sont pas ajoutés une seconde fois.",
    "headerBoot": "Type de démarrage",
    "headerFile": "Fichier touché",
    "headerPost": "Étape postérieure à la mise à jour",
    "bootRows": [
      {
        "boot": "systemd-boot (ZFS)",
        "file": "/etc/kernel/cmdline",
        "post": "proxmox-boot-tool refresh"
      },
      {
        "boot": "GRUB (LVM/ext4)",
        "file": "/etc/default/grub",
        "post": "update-grub"
      }
    ],
    "kernelIntro": "Paramètres du noyau ajoutés:",
    "modulesIntro": "Modules de noyau ajoutés au <code>/etc/modules</code>:",
    "blacklistIntro": "Pilotes en conflit bloqués dans <code>/etc/modprobe.d/blacklist.conf</code> :",
    "blacklistTitle": "Bloquer les pilotes GPU empêche l’utilisation du GPU par l’hôte",
    "blacklistBody": "La liste de blocage empêche le noyau hôte de lier <em>tout</em> pilote GPU, pour que VFIO puisse prendre le contrôle du GPU. C’est souhaitable pour l’attribution directe à une VM, mais c’est l’<strong>opposé</strong> de ce qu’il faut pour <link>installer les pilotes NVIDIA sur l’hôte</link>, par exemple pour le transcodage LXC. Choisissez une voie par GPU :",
    "pathItems": [
      "<strong>GPU → VM:</strong> activez VFIO/IOMMU ici, laissez les pilotes GPU sur la liste noire.",
      "<strong>GPU → LXC (ou hôte) :</strong> ignorez cette option, utilisez l’installation NVIDIA sur l’hôte et ne bloquez pas nvidia/nouveau.",
      "<strong>Deux GPU :</strong> l’un peut aller à une VM, l’autre à un LXC, mais une configuration plus précise est nécessaire : lier une seule carte à <code>vfio-pci</code> par son identifiant PCI. La liste de blocage par défaut est trop large ; modifiez ensuite <code>blacklist.conf</code>."
    ],
    "acsTitle": "À propos de pcie_acs_override — comprenez ce que vous activez",
    "acsBody": "<code>pcie_acs_override=downstream,multifunction</code> assouplit la vérification PCIe Access Control Services. Le noyau peut alors séparer des groupes IOMMU signalés comme indivisibles par le firmware, parfois seul moyen d’attribuer un périphérique sans tout le groupe. En contrepartie, <strong>l’isolation entre périphériques est réduite</strong> : une VM malveillante ou compromise avec accès direct dispose d’une plus grande surface d’attaque via DMA. Acceptable en laboratoire domestique, à bien évaluer pour des charges non fiables. Si inutile, retirez le paramètre de <code>/etc/kernel/cmdline</code> ou <code>/etc/default/grub</code> après le script et relancez la mise à jour du chargeur de démarrage.",
    "rebootTitle": "Redémarrage nécessaire",
    "rebootBody": "IOMMU, les modules VFIO et la liste de blocage prennent effet après régénération d’initramfs et redémarrage. Le script exécute <code>update-initramfs -u -k all</code>, actualise le chargeur de démarrage et indique qu’un redémarrage est nécessaire pour que Personnalisable le propose à la fin.",
    "verifyTitle": "Vérification après redémarrage",
    "revertTitle": "Réversible depuis le menu Désinstaller",
    "revertBody": "<link>Désinstaller les optimisations</link> annule toutes les modifications : retire les paramètres IOMMU de <code>/etc/kernel/cmdline</code> ou GRUB, les modules VFIO de <code>/etc/modules</code> et les entrées de blocage des pilotes, puis reconstruit initramfs. Un redémarrage applique le retour en arrière."
  },
  "related": {
    "heading": "Voir aussi",
    "items": [
      {
        "label": "Ajouter GPU à VM (Passthrough)",
        "href": "/docs/hardware/gpu-vm-passthrough",
        "tail": "— l'étape suivante naturelle une fois IOMMU + VFIO activé."
      },
      {
        "label": "Ajouter le contrôleur ou NVMe au VM",
        "href": "/docs/disk-manager/add-controller-nvme-vm",
        "tail": "— la même infrastructure de transmission pour les contrôleurs de stockage."
      },
      {
        "label": "commandes GPU Passthrough",
        "href": "/docs/help-info/gpu-commands",
        "tail": "— Référence de vérification IOMMU."
      },
      {
        "label": "Désinstaller les optimisations",
        "href": "/docs/post-install/uninstall",
        "tail": " — annuler proprement IOMMU / VFIO."
      },
      {
        "label": "Post-installation personnalisable",
        "href": "/docs/post-install/customizable",
        "tail": "— retour au menu parent."
      }
    ]
  }
}