> For the complete documentation index, see [llms.txt](https://docs.verge.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.verge.io/learn-the-platform/fr/module-9-supervision-et-depannage/06-common-issues.md). # Problèmes courants et solutions ## Référence rapide de dépannage Cette page regroupe les problèmes les plus courants rencontrés par les administrateurs VergeOS, classés par sous-système. Chaque section inclut les symptômes, les causes racines et les procédures de résolution étape par étape. ```mermaid graph TD A["Identifier le symptôme"] --> B{"Quel sous-système ?"} B -->|VM| C["Réseau / Mémoire"] B -->|Stockage| D["vSAN / NAS"] B -->|Matériel| E["SEL / IPMI"] B -->|Installation| F["Démarrage / jonction"] C --> G["Étapes de résolution"] D --> G E --> G F --> G G --> H{"Résolu ?"} H -->|Oui| I["Documenter et clôturer"] H -->|Non| J["Escalader au support"] style A fill:#4a90d9,color:#fff style B fill:#2c3e50,color:#fff style G fill:#27ae60,color:#fff style J fill:#e74c3c,color:#fff ``` *** ## Connectivité réseau des VM Les problèmes de connectivité réseau sont le sujet de support le plus courant. Avant d’aller plus loin, vérifiez si **d’autres VM** dans le même environnement peuvent atteindre Internet. Si aucune n’y parvient, le problème se situe probablement en amont de VergeOS (commutateur, pare-feu, FAI). Si les autres VM fonctionnent correctement, le problème est presque toujours une erreur de configuration sur la VM concernée. ### Configuration NIC manquante **Symptôme :** La VM démarre mais aucune interface réseau n’est visible dans le système d’exploitation invité. **Résolution :** 1. Ouvrez le tableau de bord de la VM et vérifiez la **des NIC** section 2. Si aucune NIC n’est listée, cliquez sur **Ajouter une NIC** 3. Sélectionnez le réseau approprié et définissez le type d’interface sur **VirtIO** (recommandé) ou **E1000** pour la compatibilité avec les systèmes anciens 4. La NIC apparaît immédiatement dans l’invité lorsque le hot-plug est activé (par défaut) — une nouvelle détection dans le système invité peut être nécessaire sur certains systèmes d’exploitation. Redémarrez uniquement si le hot-plug est désactivé. ### Affectation de réseau incorrecte **Symptôme :** La VM possède une NIC mais ne peut pas atteindre les autres VM ni Internet. **Résolution :** 1. Accédez au tableau de bord de la VM → **des NIC** 2. Vérifiez que l’état de la NIC est **En ligne** 3. Confirmez que la **Réseau** colonne affiche le bon réseau — comparez avec une VM fonctionnelle dans le même environnement 4. Si c’est incorrect, modifiez la NIC et réaffectez-la au bon réseau 5. Redémarrez la VM ### Pilotes VirtIO manquants **Symptôme :** La VM Windows n’affiche aucun adaptateur réseau dans le Gestionnaire de périphériques, alors qu’une NIC est configurée dans VergeOS. **Résolution :** 1. Vérifiez qu’une NIC existe dans la **des NIC** section de la VM dans VergeOS 2. Connectez-vous à la VM via la **Console distante** 3. Installez les pilotes VirtIO à partir de l’ISO de l’agent invité — reportez-vous à la documentation VergeOS sur [Agent invité de la VM](https://docs.verge.io/product-guide/virtual-machines/vm-guest-agent/) pour les étapes de téléchargement et d’installation 4. Après l’installation du pilote, Windows détectera automatiquement l’adaptateur réseau ### Configuration IP invité incorrecte **Symptôme :** La NIC est présente et les pilotes sont installés, mais la VM ne peut toujours pas atteindre le réseau. **Résolution :** 1. Dans le système d’exploitation invité, vérifiez que l’adaptateur réseau est détecté et activé 2. Pour DHCP : assurez-vous qu’un service DHCP fonctionne sur le réseau (vérifiez **Réseaux → \[Réseau] → DHCP**) 3. Pour une adresse IP statique : confirmez que l’adresse IP, le masque de sous-réseau, la passerelle et les paramètres DNS correspondent à la conception du réseau 4. Utilisez l’outil de **Diagnostics réseau** (ping, balayage ARP) depuis le contexte réseau VergeOS pour vérifier la connectivité de couche 2 *** ## Rapport de mémoire invité Les administrateurs migrant depuis VMware ou Nutanix remarquent souvent que VergeOS affiche une utilisation mémoire plus élevée que prévu. C’est normal — ce n’est pas un problème. ### Mémoire allouée vs mémoire active **Symptôme :** VergeOS indique qu’une VM utilise 8 Go de RAM, mais le gestionnaire de tâches du système invité n’en montre que 2 Go utilisés. **Explication :** VergeOS affiche la mémoire **allouée** — la RAM physique réservée sur l’hôte pour cette VM. Lorsque vous attribuez 8 Go à une VM, l’hyperviseur réserve immédiatement 8 Go de mémoire physique, indépendamment de ce que l’invité consomme activement. C’est l’engagement réel de ressources sur l’hôte. ### Pas de ballooning mémoire Contrairement aux plateformes qui s’appuient sur le ballooning mémoire pour récupérer la mémoire invitée inutilisée, **VergeOS n’utilise volontairement pas le ballooning**. Ce choix de conception offre : * **Des performances prévisibles** — pas de surcharge du pilote de ballooning ni de pression mémoire inattendue * **Une planification de capacité simplifiée** — allouée = engagée ; pas d’estimation des ratios de surallocation * **Une fiabilité accrue** — aucun risque d’état OOM induit par le ballooning dans les invités * **Un dimensionnement de migration précis** — ce que vous allouez est ce dont vous aurez besoin sur l’hôte de destination ### Bonnes pratiques de planification de capacité | Métrique | Où vérifier | Ce que cela signifie | | ------------------------------------------- | --------------------------------------------------------------------------- | -------------------------------------------- | | **RAM allouée à la VM** | Tableau de bord de la VM | RAM physique réservée pour cette VM | | **RAM active de l’invité** | Dans le système d’exploitation invité (Gestionnaire des tâches / `free -h`) | Ce que l’invité utilise réellement | | **RAM disponible du nœud** | Tableau de bord du nœud → Mémoire | Quantité de RAM hôte encore non allouée | | **Pourcentage max cible de RAM du cluster** | Système → Paramètres → Avancé | Seuil pour les décisions de placement des VM | {% hint style="success" %} **Dimensionnement correct des VM** Comme VergeOS alloue le montant total, il est plus important de dimensionner correctement la mémoire des VM que sur les plateformes avec ballooning. Commencez avec des allocations conservatrices et augmentez uniquement lorsque la surveillance de l’invité montre une utilisation élevée soutenue. {% endhint %} *** ## Bruit SEL (journaux IPMI faux positifs) Certains matériels de serveur génèrent des entrées IPMI répétitives et bénignes qui remplissent le journal des événements système (SEL) et déclenchent des alertes inutiles. Le plus courant est le message **« Get SEL Info command failed »** . ### Comprendre le SEL Le journal des événements système est stocké dans le matériel (sur le contrôleur BMC/IPMI) avec une capacité limitée. Une fois plein, **de nouveaux événements ne peuvent plus être enregistrés** tant que le journal n’a pas été vidé. Le tableau de bord du nœud affiche la capacité SEL sous forme de barre de pourcentage. ### Filtrer le bruit SEL via l’API Pour supprimer les faux positifs sans perdre les vraies alertes matérielles : 1. Accédez à **Système → Documentation de l’API** 2. Trouvez la **paramètres** table et développez-la 3. Cliquez sur l’ **POST** option et saisissez ce corps : ```json { "key": "syslog_regex_list", "value": "2E2A4765742053454C20496E666F20636F6D6D616E64206661696C65642E", "default_value": "", "description": "Lignes encodées en hexadécimal d’expressions régulières à filtrer du syslog" } ``` 4. Cliquez sur **Exécuter** La valeur est une expression régulière encodée en hexadécimal : `.*Get SEL Info command failed.` — vous pouvez encoder des motifs supplémentaires avec un outil d’encodage hexadécimal et séparer plusieurs motifs avec `|`. **Exemple — filtrage de deux motifs :** L’expression régulière `(Get SEL Info command failed|Unable to send command: Device or resource busy)` s’encode en : ``` 284765742053454C20496E666F20636F6D6D616E64206661696C65647C556E61626C6520746F2073656E6420636F6D6D616E643A20446576696365206F72207265736F75726365206275737929 ``` ### Redémarrage du service IPMI Après avoir appliqué le filtre, redémarrez la capture des journaux sur chaque nœud concerné : **Option A — Via l’interface utilisateur :** 1. Accédez à **Infrastructure → Nœuds → \[Nœud]** 2. Modifiez le nœud, **décochez** « Capture System Logs », validez 3. Attendez 15 secondes 4. Modifiez à nouveau le nœud, **réactivez** « Capture System Logs » **Option B — Via SSH :** ```bash sudo systemctl restart openipmi ``` ### Vider un SEL plein Si le SEL est déjà plein : 1. Accédez à **Infrastructure → Nœuds → \[Nœud]** 2. Cliquez sur **Vider le SEL** dans le menu de gauche 3. Confirmez avec **Oui** *** ## Problèmes de partage NAS ### Windows : Impossible de se connecter aux partages CIFS **Symptôme :** Les clients Windows 10/11 ne peuvent pas accéder aux partages CIFS et reçoivent des erreurs « accès refusé » ou « impossible de se connecter », même avec des identifiants corrects. **Cause racine :** Par défaut, les versions modernes de Windows désactivent les ouvertures de session invité non sécurisées pour les connexions SMB. **Résolution — Activer les ouvertures de session invité non sécurisées :** 1. Appuyez sur `Win + R`, saisissez `gpedit.msc`, appuyez sur Entrée 2. Accédez à : **Configuration de l'ordinateur → Modèles d'administration → Réseau → Lanman Workstation** 3. Repérez **Activer les connexions invité non sécurisées** → Clic droit → **Modifier** 4. Sélectionnez **Activé** → Cliquez sur **OK** 5. **Redémarrer** l’appareil Windows {% hint style="warning" %} **Windows Édition Familiale** `gpedit.msc` n’est pas disponible sur Windows Home. Utilisez plutôt l’Éditeur du Registre : accédez à `HKEY_LOCAL_MACHINE\\SYSTEM\\CurrentControlSet\\Services\\LanmanWorkstation\\Parameters` et définissez `AllowInsecureGuestAuth` (DWORD) sur `1`. {% endhint %} ### macOS : échecs de connexion ou mauvaises performances **Symptôme :** Le Finder de macOS ne parvient pas à se connecter aux partages CIFS, les connexions se coupent par intermittence ou les performances sont inutilisables. **Résolution — Forcer SMB3 via `nsmb.conf`:** 1. Ouvrez Terminal et créez ou modifiez la configuration SMB : ```bash sudo nano /etc/nsmb.conf ``` 2. Ajoutez ce qui suit : ```ini [default] smb_neg=smb3_only signing_required=no ``` 3. **Videz le cache SMB de macOS :** ```bash sudo rm -rf /var/db/samba/* sudo rm -rf /var/db/smb/* ``` 4. **Redémarrez votre Mac** pour appliquer les changements **Options de configuration avancées pour les clients macOS :** Pour une meilleure compatibilité avec macOS, ajoutez les directives orientées macOS (y compris `vfs objects = fruit streams_xattr` et les options `fruit:*` associées) sous **Options de configuration avancées** dans les paramètres CIFS NAS (**NAS → CIFS**). Cela active les extensions SMB natives d’Apple. ### Erreurs d’accès refusé **Symptôme :** Les utilisateurs reçoivent « Accès refusé » lorsqu’ils parcourent ou ouvrent des fichiers sur un partage, alors qu’ils peuvent voir le nom du partage. **Liste de vérification de résolution :** 1. **Liste des utilisateurs valides :** Accédez à **NAS → Partages → \[Partage]** et confirmez que l’utilisateur ou le groupe figure dans la liste des utilisateurs valides 2. **Paramètre browseable :** Assurez-vous que le partage est défini sur **browseable** si les utilisateurs doivent le découvrir 3. **Utilisateur forcé / Groupe forcé :** Si configuré, vérifiez que l’utilisateur/groupe forcé dispose des autorisations lecture/écriture sur le volume sous-jacent 4. **Redémarrage du service NAS :** Après les changements d’autorisations, redémarrez le service NAS pour appliquer ### Performances CIFS lentes **Symptôme :** Les transferts de fichiers via CIFS sont nettement plus lents que prévu. **Résolution :** 1. **Version du protocole SMB :** Sous **NAS → Volumes → \[Volume] → Configuration avancée**, vérifiez la version minimale du protocole SMB. La définir trop bas (SMB1) force une négociation héritée 2. **Chemin réseau :** Utilisez Diagnostics réseau (ping, traceroute) pour vérifier la latence entre le sous-réseau client et le réseau NAS 3. **Charge de connexion :** Utilisez Diagnostics NAS → **État de Samba** pour vérifier les connexions actives et identifier les partages surchargés 4. **Ressources NAS :** Vérifiez l’allocation CPU et mémoire du service NAS — des VM NAS sous-dimensionnées créeront un goulot d’étranglement du débit *** ## Dépannage de l’installation ### Problèmes de démarrage **Symptôme :** Le nœud ne parvient pas à démarrer depuis l’installateur USB VergeOS. **Résolution :** * Vérifiez que les paramètres de démarrage BIOS/UEFI correspondent au type de support d’installation (UEFI recommandé) * Testez le support USB sur un système connu comme fonctionnel pour écarter un disque défectueux * Confirmez la compatibilité matérielle — vérifiez que le CPU prend en charge le 64 bits avec la virtualisation matérielle (VT-x/AMD-V) * Désactivez Secure Boot dans le BIOS si l’installateur ne parvient pas à se charger ### Incohérences de configuration réseau **Symptôme :** L’installation se termine mais le nœud ne peut pas communiquer avec les autres nœuds ni avec le réseau. **Résolution :** * Pendant l’installation, **arrêtez immédiatement** si l’adresse IP ou l’interface détectée ne correspond pas à la conception de votre réseau * Vérifiez que les configurations VLAN correspondent aux paramètres du port du commutateur * Vérifiez les connexions physiques des câbles — l’installateur détecte automatiquement les interfaces ; un câblage incorrect entraîne une mauvaise affectation des interfaces * Confirmez que le plan d’adressage IP n’entre pas en conflit avec les appareils existants sur le réseau ### Mode JBOD du contrôleur de stockage **Symptôme :** L’installateur VergeOS ne détecte pas tous les disques attendus. **Résolution :** * VergeOS exige que les disques soient présentés comme des disques individuels (mode JBOD/passthrough), **pas** comme des matrices RAID * Entrez dans le BIOS du contrôleur de stockage (par exemple, PERC, MegaRAID) et configurez chaque disque comme un volume JBOD ou un RAID-0 individuel * Certains contrôleurs nécessitent des mises à jour du firmware pour prendre en charge le mode JBOD — consultez la documentation du fournisseur matériel ### Échecs de jonction du nœud secondaire **Symptôme :** Le contrôleur secondaire ou le nœud de calcul ne parvient pas à rejoindre le cluster existant. **Résolution :** 1. Vérifiez que vous avez sélectionné **"Non"** lorsqu’on vous demande s’il s’agit d’une nouvelle installation (pour les nœuds secondaires) 2. Confirmez que vous avez saisi les **identifiants d’administration du contrôleur principal** correctement 3. Assurez-vous que les deux nœuds sont sur le même réseau et peuvent se joindre (vérifiez les affectations VLAN des ports du commutateur) 4. Faites correspondre exactement les paramètres de chiffrement du contrôleur principal 5. Faites correspondre les affectations de niveaux de disques du contrôleur principal 6. Si le secondaire démarre mais n’est pas visible dans l’interface principale, vérifiez la configuration réseau du fabric central et la connectivité du commutateur entre les nœuds *** ## Problèmes de stockage ### État dégradé du vSAN **Symptôme :** Le tableau de bord affiche un niveau vSAN en état « dégradé » ou « non redondant ». **Explication :** Un état dégradé signifie qu’un ou plusieurs disques d’un niveau ont échoué ou sont indisponibles, mais que le vSAN reste opérationnel. Les données restent accessibles parce que VergeOS maintient la redondance entre les nœuds. **Résolution :** 1. Accédez à **Système → vSAN → Disques** pour identifier le ou les disques défaillants 2. Vérifiez les données SMART du disque via **Diagnostics du nœud → Test de diagnostic S.M.A.R.T.** 3. Si un remplacement physique est nécessaire, utilisez **Diagnostics du nœud → Contrôle des LED** pour allumer le tiroir de disque afin de l’identifier 4. Contactez le support Verge pour obtenir des conseils sur le remplacement du disque — le vSAN reconstruira automatiquement la redondance une fois le disque de remplacement ajouté ### Durées de reconstruction des disques **Comprendre les attentes :** Les durées de reconstruction dépendent de la quantité de données sur le niveau et de la capacité d’E/S des disques restants. Pendant une reconstruction : * Le système reste pleinement opérationnel * Les performances d’écriture peuvent être légèrement réduites * Surveillez la progression via l’indicateur de progression du niveau dans le tableau de bord vSAN (100 % = terminé) {% hint style="success" %} **Minimiser l’impact de la reconstruction** Évitez de planifier des migrations de charges de travail lourdes ou de grands imports de données pendant une reconstruction. Le vSAN priorise les opérations de reconstruction, mais des E/S supplémentaires prolongent la fenêtre de reconstruction. {% endhint %} ### Avertissements de seuil de capacité **Symptôme :** Les alertes du tableau de bord signalent une capacité de stockage approchant des limites. **Résolution :** 1. Vérifiez l’utilisation du niveau dans **Système → vSAN** — chaque niveau affiche la capacité utilisée par rapport à la capacité totale 2. Examinez les données SMART du disque via **Infrastructure → Nœuds → \[Nœud] → Diagnostics → Test de diagnostic S.M.A.R.T.** pour vérifier les niveaux d’usure et les indicateurs de santé des disques 3. Pour un soulagement immédiat, identifiez et supprimez les instantanés inutiles ou les disques de VM non utilisés 4. Pour une résolution à long terme, ajoutez des disques ou des nœuds pour étendre le niveau — référez-vous aux procédures d’extension du vSAN Les points de rupture suivants sont **des consignes de formation** pour la planification, et non des seuils documentés. Les valeurs documentées sont le **seuil par défaut d’utilisation élevée à 80 %** (utilisé par les alertes de forte utilisation vSAN/niveau de stockage préconfigurées) et le **90% `sync_max_usage`** seuil à partir duquel vSAN limite les écritures et marque le niveau `outofspace`. | Niveau d’utilisation | Action requise | | -------------------- | ------------------------------------------------------------------------------------------- | | **< 70%** | Fonctionnement normal — aucune action requise | | **70–85%** | Planifiez l’extension de capacité ; examinez les politiques de conservation des instantanés | | **85–90%** | Réduisez activement l’utilisation ou ajoutez de la capacité | | **> 90%** | Critique — priorisez l’extension ; risque d’échecs d’écriture | *** ## Arbre de décision de dépannage Lorsqu’un problème ne correspond pas aux catégories ci-dessus, suivez ce flux de travail général : ### 1. Définir le périmètre du problème Le problème affecte-t-il une VM, un réseau, un nœud ou l’ensemble du système ? Le périmètre détermine avec quel outil de diagnostic commencer. ### 2. Utiliser les diagnostics du composant Commencez par l’outil de diagnostic spécifique au composant (Diagnostics réseau, nœud, NAS ou vSAN) — ils s’exécutent automatiquement dans le bon contexte. ### 3. Vérifier les journaux système Examinez les journaux du tableau de bord et les alertes système pour les événements corrélés. Recherchez des schémas — plusieurs alertes ont-elles été déclenchées en même temps ? ### 4. Escalader avec des données Si le problème n’est pas résolu, générez un **Diagnostics système** bundle (Système → Diagnostics système) et soumettez-le avec votre demande de support. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.verge.io/learn-the-platform/fr/module-9-supervision-et-depannage/06-common-issues.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.