Problèmes courants et résolutions
Modèles de dépannage pour les problèmes VergeOS les plus fréquemment rencontrés — réseau des VM, remontée de la mémoire invité, bruit SEL, partages NAS, problèmes d’installation et dégradation du stockage.
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.
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 :
Ouvrez le tableau de bord de la VM et vérifiez la des NIC section
Si aucune NIC n’est listée, cliquez sur Ajouter une NIC
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
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 :
Accédez au tableau de bord de la VM → des NIC
Vérifiez que l’état de la NIC est En ligne
Confirmez que la Réseau colonne affiche le bon réseau — comparez avec une VM fonctionnelle dans le même environnement
Si c’est incorrect, modifiez la NIC et réaffectez-la au bon réseau
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 :
Vérifiez qu’une NIC existe dans la des NIC section de la VM dans VergeOS
Connectez-vous à la VM via la Console distante
Installez les pilotes VirtIO à partir de l’ISO de l’agent invité — reportez-vous à la documentation VergeOS sur Agent invité de la VM pour les étapes de téléchargement et d’installation
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 :
Dans le système d’exploitation invité, vérifiez que l’adaptateur réseau est détecté et activé
Pour DHCP : assurez-vous qu’un service DHCP fonctionne sur le réseau (vérifiez Réseaux → [Réseau] → DHCP)
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
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é
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
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.
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 :
Accédez à Système → Documentation de l’API
Trouvez la paramètres table et développez-la
Cliquez sur l’ POST option et saisissez ce corps :
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 :
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 :
Accédez à Infrastructure → Nœuds → [Nœud]
Modifiez le nœud, décochez « Capture System Logs », validez
Attendez 15 secondes
Modifiez à nouveau le nœud, réactivez « Capture System Logs »
Option B — Via SSH :
Vider un SEL plein
Si le SEL est déjà plein :
Accédez à Infrastructure → Nœuds → [Nœud]
Cliquez sur Vider le SEL dans le menu de gauche
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 :
Appuyez sur
Win + R, saisissezgpedit.msc, appuyez sur EntréeAccédez à : Configuration de l'ordinateur → Modèles d'administration → Réseau → Lanman Workstation
Repérez Activer les connexions invité non sécurisées → Clic droit → Modifier
Sélectionnez Activé → Cliquez sur OK
Redémarrer l’appareil Windows
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.
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:
Ouvrez Terminal et créez ou modifiez la configuration SMB :
Ajoutez ce qui suit :
Videz le cache SMB de macOS :
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 :
Liste des utilisateurs valides : Accédez à NAS → Partages → [Partage] et confirmez que l’utilisateur ou le groupe figure dans la liste des utilisateurs valides
Paramètre browseable : Assurez-vous que le partage est défini sur browseable si les utilisateurs doivent le découvrir
Utilisateur forcé / Groupe forcé : Si configuré, vérifiez que l’utilisateur/groupe forcé dispose des autorisations lecture/écriture sur le volume sous-jacent
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 :
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
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
Charge de connexion : Utilisez Diagnostics NAS → État de Samba pour vérifier les connexions actives et identifier les partages surchargés
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 :
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)
Confirmez que vous avez saisi les identifiants d’administration du contrôleur principal correctement
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)
Faites correspondre exactement les paramètres de chiffrement du contrôleur principal
Faites correspondre les affectations de niveaux de disques du contrôleur principal
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 :
Accédez à Système → vSAN → Disques pour identifier le ou les disques défaillants
Vérifiez les données SMART du disque via Diagnostics du nœud → Test de diagnostic S.M.A.R.T.
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
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é)
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.
Avertissements de seuil de capacité
Symptôme : Les alertes du tableau de bord signalent une capacité de stockage approchant des limites.
Résolution :
Vérifiez l’utilisation du niveau dans Système → vSAN — chaque niveau affiche la capacité utilisée par rapport à la capacité totale
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
Pour un soulagement immédiat, identifiez et supprimez les instantanés inutiles ou les disques de VM non utilisés
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.
< 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.
Mis à jour
Ce contenu vous a-t-il été utile ?