Manuel pratique Comp’Assist · Révision : 2 octobre 2026. Exemples pédagogiques, à adapter. Les fonctions visibles dépendent de la version, des droits et des paquets installés.
Préparer un ISO officiel, le stockage système, une quantité de RAM, un bridge/VLAN et le plan de sauvegarde. Vérifier capacité réelle et disponibilité des pilotes VirtIO pour le système invité. Exemple de départ pour un petit Linux : 2 vCPU, 2 à 4 Go de RAM et un disque système adapté aux logiciels ; il faut ajuster à la charge, pas considérer cet exemple comme un dimensionnement garanti.
| Champ | Quoi choisir | Pourquoi |
|---|---|---|
| Node | Hôte avec les ressources et réseaux nécessaires | Le stockage et les périphériques doivent y être accessibles |
| VM ID | Identifiant libre du cluster | Éviter collisions et conventions ambiguës |
| Name | Nom fonctionnel stable | Différent du nom que l’OS adoptera après installation |
| Resource Pool / tags | Groupe logique et étiquettes utiles | Organisation et droits, pas répartition physique automatique |
| ISO storage / image | Support d’installation vérifié | Ne pas choisir une image parce que son nom semble récent |
| Guest OS / version | Famille réellement installée | Sert aux valeurs et compatibilités par défaut |
L’option sans média convient à une VM qui démarrera autrement, pas à une installation classique sans disque préparé. Pour Windows, prévoir le média de pilotes si le disque ou le réseau ne sont pas reconnus.
| Champ | Choix raisonné | Point de vigilance |
|---|---|---|
| BIOS | OVMF pour UEFI lorsque requis ; SeaBIOS pour certains systèmes hérités | Changer après installation peut rendre le système non amorçable |
| Machine | Modèle compatible avec OS et périphériques, souvent q35 pour usages modernes | Conserver la compatibilité lors d’une migration |
| EFI storage | Stockage fiable pour les variables UEFI | Ne contient pas le système d’exploitation entier |
| Pre-enrolled keys / Secure Boot | Selon exigences de l’OS et pilotes | Ne pas désactiver comme premier réflexe |
| TPM state / version | TPM virtuel approprié, notamment pour OS qui l’exigent | Sauvegarder son état avec la VM et les clés de récupération |
| SCSI controller | VirtIO SCSI adapté si pilotes disponibles | Coordonner avec bus des disques et IO thread |
| QEMU Guest Agent | Activer puis installer le composant dans l’OS | Une case seule n’installe pas le service invité |
| Display | Modèle reconnu par l’OS | Le GPU physique nécessite une étude distincte |
Choisir le stockage selon le manuel dédié. Une image raw et qcow2 n’offrent pas les mêmes mécanismes selon le backend ; sur stockage bloc, le format est souvent imposé. Ne pas choisir qcow2 simplement parce qu’il paraît plus moderne.
| Champ | Effet | Choix initial prudent |
|---|---|---|
| Bus / Device | Présentation du disque | SCSI/VirtIO avec pilote adapté |
| Disk size | Capacité vue par l’invité | Prévoir croissance et capacité physique réelle |
| Cache | Comportement du cache d’écriture | Garder le défaut supporté sans activer un mode dangereux pour un benchmark |
| Discard | Transmission des libérations de blocs | Seulement avec chaîne compatible et politique adaptée |
| SSD emulation | Informe l’invité du type attendu | Ne transforme pas un HDD en SSD |
| IO thread | Traitement dédié dans les configurations compatibles | Tester latence et charge après activation |
| Backup | Inclusion du disque dans les backups | Exclure seulement avec autre protection documentée |
| Limites I/O | Plafond de débit / opérations | Utile pour une charge secondaire qui sature les autres |
Un socket avec quelques cœurs est souvent un point de départ simple. Le nombre total dépend sockets × cœurs et de la configuration. Le type host peut améliorer l’usage des instructions locales mais limiter la compatibilité de migration. Pour un cluster hétérogène, définir un modèle compatible commun. Ne pas inventer une topologie NUMA sans rapport avec l’hôte.
Renseigner mémoire maximale et minimum de ballooning si utilisé. Installer les pilotes nécessaires ; ne pas sous-dimensionner une base critique en espérant que le ballooning résoudra la contention. Garder de la mémoire pour l’hôte et les sauvegardes. La mémoire affichée dans Proxmox et dans l’OS peut être mesurée différemment.
Bridge choisit le réseau virtuel ; VLAN tag sélectionne une zone transportée par ce bridge ; Model doit être reconnu par l’OS, VirtIO étant courant pour les systèmes compatibles. MAC doit être unique ; une MAC clonée peut créer un conflit. Firewall active la participation de cette interface aux mécanismes de filtrage configurés, mais n’écrit pas à lui seul une politique complète. Rate limit limite le débit et se dimensionne selon unités affichées.
Ne pas attribuer une IP sur le bridge hôte pour chaque VM. Configurer l’adresse dans l’invité ou via Cloud-Init. Si le tag est déjà géré dans Proxmox, ne pas le dupliquer dans l’OS sauf architecture volontaire.
Relire hôte, ID, stockage, taille, RAM et réseau avant création. Démarrer, installer l’OS, appliquer ses mises à jour et installer l’agent invité. Retirer l’ISO et vérifier l’ordre de boot. Configurer arrêt propre, sauvegarde, notifications et compte administrateur de l’application.
Dans Options, choisir Start at boot et ordre/délai de démarrage selon dépendances. Activer Protection contre les suppressions accidentelles si pertinent ; cela ne remplace pas les droits. Les modifications matérielles marquées en attente exigent une action adaptée pour prendre effet. Ne pas forcer un arrêt pendant une écriture de base.
Vérifier démarrage sans ISO, accès réseau attendu, refus depuis une zone interdite, agent, arrêt propre et backup. Restaurer sous un autre ID sur réseau isolé. Avant changement firmware ou contrôleur d’une VM existante, conserver la configuration et un backup ; l’OS peut nécessiter un pilote avant changement du bus. Revenir au contrôleur d’origine si le démarrage échoue, plutôt que réinstaller immédiatement.