Débogage et dépannage

Recueillez les informations relatives au cluster et les journaux de débogage afin de résoudre les problèmes liés à l' Standard Edition.

Attention :

Standard Edition en auto-hébergement 1.10.3 and earlier versions :

Pour les installations en ligne (sans isolation physique), la plupart des commandes liées au cycle de vie stanctl , telles que, ne stanctl up s'exécutent pas.
Pour les installations en mode « air-gap », les commandes stanctl restent opérationnelles.

Action requise : effectuez une mise à niveau stanctl vers la version 1.10.4 ou une version ultérieure avant d'effectuer une opération liée au cycle de vie.

Exemple : dans les déploiements en ligne exécutant stanctl1.10.3 ou une version antérieure, tout workflow qui arrête des services, par exemple une stanctl down commande, avant une sauvegarde, ne peut pas aboutir car la commande stanctl up suivante échoue. Mettez à jour stanctl votre système vers la version 1.10.4 ou une version ultérieure avant de suivre ces étapes.

Remarque :

Si votre backend Instana auto-hébergé consomme beaucoup de ressources, il se peut que les agents envoient un volume trop important de données vers ce backend. Avant d'ajouter de nouvelles infrastructures, réduisez le volume de données collectées au niveau des agents. Vous pouvez modifier les paramètres des agents, tels que la fréquence d'interrogation et les filtres de collecte des métriques, afin de réduire le volume de données envoyées au backend. Cette modification réduit l'utilisation du processeur, de la mémoire et de l'espace disque au niveau des composants backend et peut améliorer les performances. Pour plus d'informations, consultez la section « Optimiser l'ingestion des données » sur Instana.

Recueillir des informations de diagnostic pour le dépannage

Utilisez la commande de diagnostic pour collecter des informations de diagnostic sur l' Kubernetes, la plate-forme, le nœud et le datastore afin de résoudre un problème dans un environnement Standard Edition ( k3s ).

Utilisez la syntaxe suivante pour exécuter la commande :

stanctl diagnostics [flags]
stanctl debug [flags]    # Alias (identical behavior)

Important :

Vous devez disposer d'une connexion au cluster active avant d'exécuter cette commande.

Une fois la collecte terminée, la commande affiche l'emplacement du package de diagnostics généré.

Done!
Diagnostics package ->
<output-dir>
<output-dir>/diagnostics_<YYYYMMDDHHmmss>.tar.gz

Comportement du répertoire de sortie

La commande crée toujours un répertoire portant un horodatage à diagnostics_<YYYYMMDDHHmmss> l'intérieur du répertoire que vous indiquez avec --output-dir. --output-dirSi vous ne le précisez pas, la commande utilise le répertoire de travail actuel.

Options de commande

Les options suivantes permettent de contrôler le comportement de la collecte des données de diagnostic.


Indicateur	Court	Type	Par défaut	Description
--output-dir	-o	Répertoire	Répertoire de travail en cours	Répertoire racine dans lequel la commande crée le dossier de diagnostics horodaté et l'archive compressée. Indiquez un chemin d'accès à un répertoire, et non à un fichier.
--deep-debug	Non disponible	Booléen	false	Exécute une série supplémentaire de scripts de débogage approfondi après la collecte des diagnostics standard. La collecte standard s'exécute systématiquement et n'active que la couche de scripts supplémentaire.
--max-log-lines	-l	Entier	20000	Nombre maximal de lignes de journal collectées par conteneur. Réglez sur `0` pour collecter les journaux complets.
--log-collection-days	—	Entier	7	Nombre de jours de journaux historiques à collecter.
--node-collector-image	—	Chaîne	Résolu lors de l'exécution	Image de conteneur pour l' DaemonSet « node-collector ». Remplacez cette valeur dans les environnements de registre isolés ou privés.
--node-collector-namespace	—	Chaîne	Espace de nom par défaut	Espace de noms dans lequel la commande crée et supprime le collecteur de nœuds temporaire DaemonSet.
--external-script	—	Extrait de chaîne	Aucun	Exécute un ou plusieurs scripts shell fournis par l'utilisateur lors de la collecte. Transmettez plusieurs scripts sous forme de liste séparée par des virgules. Par exemple, (`--external-script a.sh,b.sh`) ou en répétant le drapeau (`--external-script a.sh --external-script b.sh`).

Indicateur global hérité


Indicateur	Description
--env-file	Chemin d'accès à un .env fichier. La commande transmet les valeurs contenues dans ce fichier au moteur de diagnostic afin de déterminer les informations d'identification du magasin de données.

Quelles sont les données collectées?

Le moteur de diagnostic exécute les collecteurs suivants de manière séquentielle. Chaque collecteur enregistre ses données de sortie dans un répertoire dédié au sein du package « diagnostics ».

Pour les collecteurs de données ( Kafka, Cassandra, Elasticsearch et BeeInstana ), stanctl les identifiants sont chargés automatiquement à partir de la configuration.

Ressources d' Kubernetes s au niveau du cluster

Le moteur collecte les ressources d' Kubernetes s au niveau du cluster, notamment :
- Noeuds
- Espaces de nom
- ClusterRoles
- ClusterRoleBindings
- StorageClasses
- PersistentVolumes
- CustomResourceDefinitions (CRD)
- Autres ressources sans espace de noms
Informations sur la mise en réseau des nœuds

Le moteur recueille des informations relatives au réseau des nœuds, notamment :
- règles iptables
- Tables de routage
- Interfaces réseau
- Paramètres réseau sysctl
- Informations sur la connectivité
Envoy diagnostics

Le moteur recueille des données de diagnostic d’ Envoy provenant des pods du répartiteur de charge « Instana Core » dans l’espace instana-core de noms, notamment :
- Statistiques sur les grappes
- Configuration de l'écouteur
- Routes
- Informations sur la santé
Ressources « Kubernetes » avec espace de noms

Le moteur rassemble les ressources Kubernetes associées à des espaces de noms dans tous les espaces de noms Instana, notamment :
- Pods
- Déploiements
- StatefulSets
- services
- ConfigMaps
- Secrets (valeurs sensibles masquées)
- Evénements
- ReplicaSets
- DaemonSets
- PersistentVolumeClaims
- HorizontalPodAutoscalers
- Ressources personnalisées (Core, Unit, ClickHouseInstallation, Kafka, Elasticsearch, et autres)
Diagnostic des nœuds

Le moteur met en place une instance temporaire de « DaemonSet » afin de collecter des données de diagnostic au niveau des nœuds, notamment :
- UC
- Mémoire
- Topologie des disques
- Version du noyau et du système d'exploitation
- Informations sur le matériel
- Points de montage
- Utilisation du disque
- valeurs sysctl
- dmesg
fichiers journaux de systemd

Le moteur collecte les journaux systemd au niveau de l'hôte pour :
- k3s.service
- Services système associés
Configuration et stockage de stanctl

Le moteur recueille stanctl les fichiers de configuration et les données relatives à l'utilisation de l'espace de stockage.

Fichiers de configuration :
- instana.yaml
- instana-values.yaml
- dependencies.yaml
- Fichier d'état
- journaux de stanctl
Utilisation du stockage :
- analytique
- données
- métriques
- objets
Instana diagnostics du backend

Le moteur recueille les données de diagnostic du backend d' Instana provenant des instana-core espaces de noms et instana-unit , notamment :
- Critères d'évaluation en matière de santé
- Indicateurs internes
- Utilisation des ressources des pods
Kafka diagnostics

Le moteur recueille des données de diagnostic « Kafka », notamment :
- Liste des thèmes
- Décalage dans le groupe de consommateurs
- courtier, configuration
- Kafka Statut CR
Remarque :
Les informations d'identification sont automatiquement extraites de la configuration de stanctl.
Cassandra diagnostics

Le moteur recueille des données de diagnostic « Cassandra », notamment :
- nodetool status
- nodetool info
- Statistiques des tables
- Validation CQL
Remarque :
Les informations d'identification sont automatiquement extraites de la configuration de stanctl.
Elasticsearch diagnostics

Le moteur recueille des données de diagnostic « Elasticsearch », notamment :
- État de santé du cluster
- Statistiques d'index
- Allocation des fragments
- Elasticsearch Statut CR
Remarque :
Les informations d'identification sont automatiquement extraites de la configuration de stanctl.
BeeInstana diagnostics

Le moteur recueille des données de diagnostic « BeeInstana », notamment :
- Journaux de l'agrégateur
- Journaux d'Ingestor
- Journaux Monconfig
- BeeInstana Statut CR
- Indicateurs internes
Remarque :
Les informations d'identification sont automatiquement extraites de la configuration de stanctl.
Helm informations sur la sortie

Le moteur recueille les informations relatives aux publications d' Helm s dans tous les espaces de noms, notamment :
- Noms des versions
- Versions de charte
- Statut de déploiement
- Valeurs (champs sensibles masqués)
Scripts de débogage approfondi

Remarque :
Le moteur n'utilise ce collecteur que lorsque vous le spécifiez --deep-debug.

Le moteur exécute un ensemble de scripts de diagnostic au sein du cluster, sélectionnés avec soin, afin de permettre un dépannage plus approfondi; ces scripts comprennent généralement des diagnostics avancés des datastores.

Métadonnées intégrées au paquet

Chaque ensemble de diagnostics comprend les métadonnées suivantes au format SUMMARY.log.


Zone	Description
Version de Stanctl	Exécution de la version binaire de stanctl
Édition	Standard ( k3s )
Mode cluster	Nœud unique ou plusieurs nœuds (comprend le type d'installation et le nombre de nœuds)
Mode réseau	Isolé physiquement (mentionné uniquement le cas échéant)

Comportement multi-nœuds

Dans un environnement à plusieurs nœuds, la commande déploie automatiquement un nœud-collecteur temporaire DaemonSet doté de tolérances supplémentaires afin de collecter des informations auprès de tous les nœuds. Aucun indicateur supplémentaire n'est nécessaire.

Régler le niveau de journalisation des composants d' Instana

Pour régler le niveau des composants d' Instana, procédez comme suit :

Modifiez le fichier de configuration principal, par exemple, $HOME/.stanctl/values/instana-core/custom-values.yaml.

Configurer le niveau de journalisation d'un composant dans le CR Core ou Unit. Dans l'exemple suivant, le niveau de journalisation est modifié pour DEBUG le butler composant :

componentConfigs:
  - name: butler
    env:
      - name: COMPONENT_LOGLEVEL
        # Possible values are DEBUG, INFO, WARN, ERROR (not case-sensitive)
        value: DEBUG

Appliquez les valeurs personnalisées en exécutant la commande suivante :
```
stanctl backend apply
```
Pour consulter les journaux, exécutez la commande suivante :
```
kubectl logs <component name> -n instana-core
```
<nom du composant> est le nom du composant pour lequel vous souhaitez effectuer un dépannage.

Certificats SSL ( SSL )

Comprendre les configurations prises en charge, les restrictions et les procédures de dépannage relatives aux certificats d' SSL.

Certificats Wildcard d' SSL

Vous pouvez utiliser des certificats génériques ( SSL ) avec Instana Standard Edition. Certaines configurations utilisant des caractères génériques ne sont pas prises en charge, et certains modèles de déploiement nécessitent un examen plus approfondi.

Exemple de scénario

Supposons la structure d' DNS suivante :

Certificat générique : *.company.com
Instana backend : instana.company.com
Point final de l'accepteur d'agent : agent-acceptor.instana.company.com
Instana Interface utilisateur : unit-tenant.instana.company.com

Limites des caractères génériques à un seul niveau

Dans ce cas de figure, *.company.com vous ne pouvez pas utiliser de certificat générique.

Raison : par définition, un astérisque (*) ne peut remplacer qu'un seul élément dans un nom d' DNS. Il ne peut pas s'étendre sur plusieurs niveaux de sous-domaines.

Règles de correspondance des certificats

Le certificat *.company.com correspond à :

www.company.com
api.company.com
mail.company.com

Le certificat *.company.com ne correspond pas :

a.b.company.com
dev.api.company.com
company.com

Remarque :

Chaque point (.) sépare les libellés d' DNS. Le caractère générique ne remplace qu'une seule étiquette.

Pour prendre en charge le déploiement d' Instana, utilisez l'une des options suivantes :

Créer un certificat générique pour le domaine de base complet Instana :
```
*.instana.company.com 
```
Utilisez un certificat SAN qui répertorie tous les noms d'hôte requis.
```
DNS: api.example.com
DNS: dev.api.example.com
DNS: prod.api.example.com
```
Combiner plusieurs entrées avec caractères génériques au sein d'un certificat SAN :
```
DNS: *.example.com
DNS: *.api.example.com
```

Restaurer le certificat auto-signé

Vous pouvez restaurer un certificat d' TLS e auto-signé qui a été supprimé précédemment.

Supprimez le secret existant « TLS » :

kubectl delete secret instana-tls -n instana-core

Générer un nouveau certificat auto-signé :
```
stanctl be apply --core-tls-generate-cert
```
Résultat :
- Un nouveau certificat auto-signé SSL est généré et appliqué.
- TLS Le chiffrement est activé pour les terminaux d' Instana.
- Les navigateurs modernes (tels que Chrome ou Firefox ) affichent des avertissements de sécurité car le certificat n'est pas délivré par une autorité de certification de confiance.
Important :
Même si les navigateurs signalent que la connexion n'est pas fiable, toutes les communications restent cryptées.

Récapitulatif

Les certificats génériques à un seul niveau (par exemple, *.company.com) ne prennent pas en charge les sous-domaines à plusieurs niveaux.
Instana La norme exige généralement des certificats SAN ou des certificats génériques de domaine de base.
Vous pouvez régénérer en toute sécurité des certificats auto-signés lorsque cela s'avère nécessaire, en tenant compte des avertissements habituels des navigateurs.

Traitement des incidents

Résolvez ces problèmes.

Instana l'agent n'apparaît pas dans l'interface utilisateur

Une fois que vous avez supprimé l'agent Instana configuré pour la surveillance à distance et installé l'agent Instana pour l'autosurveillance, il se peut que l'agent n'apparaisse pas dans l'interface utilisateur de Instana.

Il se peut que l'agent tente de se connecter au serveur distant Instana au lieu du serveur local Instana.

Pour résoudre ce problème, installez l'agent et spécifiez l'hôte du noeud final dorsal et une clé d'agent:

stanctl agent apply --agent-cluster-name <cluster-name> --agent-endpoint-host acceptor.instana-core --agent-endpoint-port 8600 --agent-zone-name <zone-name> --agent-key <agent-key-of-local-backend>

Instana Le backend cesse de fonctionner lorsque le disque de données de l' Elasticsearch ation dépasse 85 % de son espace disponible

Elasticsearch passe automatiquement son magasin de données en mode lecture seule lorsque le disque qu'il utilise atteint un taux d'utilisation supérieur à 85 %. Cela entraîne l'arrêt du fonctionnement du backend Instana. Libérez de l'espace sur le disque de données de l' Elasticsearch, ou augmentez sa capacité afin de rétablir un fonctionnement normal. Remarque : les autres disques « Instana » ne passent pas en mode lecture seule à des taux d'utilisation similaires (même supérieurs à 95 %), ce qui peut rendre ce problème difficile à comprendre.

Pour résoudre ce problème, procédez de l'une des manières suivantes :

Espace libre sur le disque de données de l' Elasticsearch
Augmenter l'espace disque alloué à Elasticsearch

Lorsque l'espace disponible est suffisant, Elasticsearch reprend ses opérations d'écriture normales et le backend redevient opérationnel.

Remarque :

Les autres disques « Instana » ne passent pas en mode lecture seule à des niveaux d'utilisation similaires (même supérieurs à 95 %), ce qui peut prêter à confusion lors du dépannage.

Instana La mise à jour du backend échoue en raison d'une installation défectueuse du graphique « Helm »

La mise à niveau du backend d' Instana échoue après l'exécution de la stanctl backend apply commande. L'erreur suivante peut s'afficher :

Error: another operation (install/upgrade/rollback) is in progress

Dans ce fichier console.log , vous pourriez trouver des informations telles que les entrées suivantes :

ts=2025-05-26T12:26:09Z level=INFO msg="upgrading Helm chart" name=instana-core release=instana-core version=1.8.1 namespace=instana-core
ts=2025-05-26T12:26:09Z level=DEBUG msg="preparing upgrade for instana-core"

Ce problème indique une installation corrompue du graphique « Helm » du graphique principal actuel; vous pouvez la réinitialiser à l'aide de la commande suivante :

Supprimez l'ancienne clé secrète « Helm » de l'espace instana-core de noms.
```
kubectl delete secret -n instana-core -l owner=helm
```
Mettre à jour le backend.

stanctl up

L'agent hôte ne parvient pas à se connecter au backend Instana sur les hôtes SLES

Une fois l'agent hôte installé sur l'hôte local sous SUSE Linux Enterprise Server (SLES) 15 SP5 à des fins d'autosurveillance, l'agent ne se connecte pas automatiquement au backend Instana.

Vous devez utiliser l'agent externe URL pour vous connecter au serveur en tant qu'hôte distant.

Utilisez la commande suivante :

stanctl agent apply --agent-endpoint-host agent-acceptor.<base_domain> --agent-endpoint-port 8443

Kafka Les pods affichent l'état de l' CrashLoopBackOff

Kafka Les pods ne redémarrent pas après l'arrêt de l'hôte backend d' Instana. Vous pouvez consulter CrashLoopBackOff l'état des pods de l' Kafka.

Pour résoudre le problème, redémarrez le backend d' Instana.

Arrêtez le système de back end.
```
stanctl down
```
Démarrez le système de back end.
```
stanctl up
```

Une fois le système dorsal redémarré, vérifiez le statut des pods Kafka .

kubectl get pods --all-namespaces | grep kafka

Le statut du pod Kafka doit être Running.

Les tests synthétiques planifiés ne s'exécutent pas après une sauvegarde et une restauration d' Instana

Une fois les données du backend et des agents d' Instana s restaurées, les tests synthétiques planifiés ne s'exécutent pas.

Pour résoudre ce problème, redémarrez le pod synthetic-pop-controller sur le cluster où il est installé.

Standard Edition L'installation sur RHEL 9.3 échoue

Red Hat® Enterprise Linux® 9.3 utilise l' 1.8.8 iptables.

Si vous installez Standard Edition sur RHEL 9.3, l'installation risque d'échouer en raison d'un problème avec iptables 1.8.8.

Pour contourner le problème, mettez à niveau votre hôte vers RHEl 9.4, qui met également à niveau iptables vers la version 1.8.10.

Échec de la mise à niveau sur Standard Edition 1.9.x

Lorsque vous mettez à niveau Standard Edition 1.9.x vers une version plus récente, vous pouvez rencontrer l'erreur suivante :

Error: installation failed for prerequisite app coredns: Unable to continue with install: ConfigMap "coredns" in namespace "kube-system" exists and cannot be imported into the current release: invalid ownership metadata; label validation error: missing key "app.kubernetes.io/managed-by": must be set to "Helm"; annotation validation error: missing key "meta.helm.sh/release-name": must be set to "coredns"; annotation validation error: missing key "meta.helm.sh/release-namespace": must be set to "kube-system"

Pour résoudre ce problème, relancez la stanctl up commande.

La mise à niveau échoue avec les messages d'erreur « CPU insuffisant » ou « Mémoire insuffisante »

Vous pourriez rencontrer l'un des problèmes suivants lors de mises à niveau sur des déploiements à nœud unique d' K3s, dans des environnements aux ressources limitées ou où l'ajout de capacité temporaire n'est pas envisageable :

Des erreurs telles que"Insufficient CPU"ou"Insufficient memory"
Les cosses qui restent dans unPendingétat

La stratégie de mise à niveau par défaut « RollingUpdate » nécessite une capacité supplémentaire temporaire pour exécuter simultanément les anciens et les nouveaux pods pendant la mise à niveau. Sur les systèmes aux ressources limitées, cette exigence peut dépasser la capacité disponible du processeur ou de la mémoire, même lorsque le taux d'utilisation global semble faible.

Pour résoudre ce problème, utilisez la stratégie de mise à jour « Recreate », qui ne nécessite pas de capacité supplémentaire pendant les mises à niveau :

stanctl up --core-update-strategy=Recreate

Pour plus d'informations sur la stratégie de mise à jour, consultez la section « Configuration de la stratégie de mise à jour pour les mises à niveau ».

Remarque :

La stratégie « Recreate » entraîne une brève interruption de service (de quelques minutes) pendant le processus de mise à niveau. Ce compromis est généralement acceptable pour les environnements hors production ou les systèmes dans lesquels il n'est pas possible d'augmenter la capacité matérielle.

Systemd ne définit pas de répertoire de travail par défaut

Lorsqu'il stanctl est lancé par un service systemd, systemd ne définit pas de répertoire de travail de lui-même. Si vous n'indiquez pas de répertoire de travail, systemd exécute le service à partir de /. Cette opération peut entraîner stanctl la création de fichiers, tels que des données de cluster, .stanctl ou des fichiers de configuration de l' Kubernetes, à un emplacement incorrect (souvent / ou /root/), même si le service utilise un utilisateur autre que root.

Pour remédier à ce problème, vous devez ajouter une WorkingDirectory= ligne au service systemd afin de créer les fichiers dans le répertoire personnel approprié de chaque utilisateur. Par exemple, WorkingDirectory=/home/instana.

Impossible de mettre à jour la licence

Lorsque vous exécutez la stanctl license update commande, celle-ci peut échouer et afficher le message d'erreur suivant :

...
no dependency found: 'instana-core'
...

Exécutez les commandes suivantes pour mettre à jour la licence :

stanctl license download --sales-key=<your-key>
stanctl backend apply

Instana La mise à niveau du backend échoue en raison d'une surcharge du disque du nœud

L'installation ou la mise à niveau du backend d' Instana peut échouer si le nœud est soumis à une forte charge de lecture/écriture sur le disque.

Symptômes

Vous pourriez constater l'un ou plusieurs des symptômes suivants :

L'installation ou la mise à jour du backend échoue.
Les pods sont toujours en attente.
Certaines charges de travail présentent ContainerStatusUnknown.

Cause

Lors de l'installation, de la mise à niveau ou de l'importation de paquets en mode air-gapped, l'utilisation du disque augmente temporairement pendant le traitement des images de conteneurs et des artefacts. Si le nœud manque d'espace disque, Kubernetes déclenche une condition d' DiskPressure e et empêche le démarrage de nouveaux pods.

Vérification

Exécutez la commande suivante pour vérifier l'état du nœud :
```
kubectl describe node <node-name>
```
Dans la section « Conditions », consultez la rubrique « DiskPressure ».
Exécutez la commande suivante pour vérifier l'utilisation du disque :
```
df -h
```
Vérifiez si l'espace disque disponible est proche de la limite maximale ou s'il a déjà atteint cette limite.

La solution

Effectuez l'une des opérations suivantes pour résoudre le problème :

Supprimez les images de conteneurs inutilisées ou les fichiers superflus pour libérer de l'espace disque.
Augmenter la capacité de stockage du nœud.

Récupération

Si les charges de travail restent dans cet ContainerStatusUnknown état après avoir libéré de l'espace disque, redémarrez le nœud. Une fois le redémarrage terminé, réessayez l'installation ou la mise à jour.

La licence n'est pas valide ou est manquante

Si la licence n'est pas valide ou fait défaut, le serveur empêche les agents de se connecter.

Lorsque cela se produit

La licence importée n'est pas valide.
L'opérateur « Instana » ne peut pas appliquer la licence au backend de Groundskeeper.

Comment résoudre les problèmes

Vérifiez que la clé de vente figurant dans le secret principal correspond aux chaînes de licence contenues dans le secret de l'unité. Si elles ne correspondent pas, téléchargez à nouveau la licence en utilisant la clé de vente appropriée.
Vérifiez les journaux de l'opérateur « Instana » pour détecter d'éventuelles erreurs d'importation de licence :
```
kubectl logs -n instana-operator deployment/instana-operator --tail=100
```
Vérifiez le composant backend de Groundskeeper, l'état du pod et les journaux :
```
kubectl get pods -n instana-core | grep groundskeeper 
```
Si la licence apparaît toujours comme non valide, contactez le service d'assistance d' IBM.

L'installation échoue avec le message « Erreur fatale glibc : le processeur ne prend pas en charge l' x86‑64‑v3” »

Symptôme

L'installation échoue dès le début lorsque vous exécutez stanctl install, avec une erreur du type :

Fatal glibc error: CPU does not support x86-64-v3

Cette erreur survient généralement avant l'installation de tous les composants et peut empêcher le démarrage de certains services, tels que Cassandra et Kafka.

Cause

Cette erreur indique que le système d'exploitation ne parvient pas à détecter le jeu d'instructions « x86‑64‑v3 ». La cause la plus fréquente est une configuration du processeur de la machine virtuelle qui ne met pas à disposition les indicateurs CPU requis, souvent en raison de paramètres de compatibilité avec les versions antérieures.

Résolution

Dans les environnements VMware et vSphere, ce problème est généralement dû au choix d'une architecture de processeur virtuel obsolète ou à l'activation de modes de compatibilité CPU qui limitent les jeux d'instructions. Pour résoudre le problème, procédez comme suit :

Évitez d'utiliser les profils de compatibilité CPU hérités lors de la configuration de la machine virtuelle.
Assurez-vous que le masquage du processeur n'est pas activé.
Si la fonctionnalité « Enhanced vMotion Compatibility » (EVC) est activée, vérifiez qu’elle est configurée à un niveau prenant en charge les instructions « x86‑64‑v3 ».
Éteignez la machine virtuelle et mettez à jour la configuration du processeur.
Si nécessaire, recréez la machine virtuelle avec les paramètres CPU mis à jour.

Une fois les modifications appliquées, vérifiez que les indicateurs CPU requis sont bien visibles dans le système d'exploitation invité avant de relancer l'installation.

Contacter le support

Si vous ne parvenez pas à résoudre le problème, contactez le service d'assistance d' IBM. Fournissez le fichier archive que vous avez créé à l'équipe de support.