SupportConsoleDéveloppeursCommencer un essaiContact

14.14. Runbooks de virtualisation OpenShift

Vous pouvez utiliser les procédures de ces runbooks pour diagnostiquer et résoudre les problèmes qui déclenchent des alertes OpenShift Virtualization.

Les alertes OpenShift Virtualization sont affichées sur la page Virtualization > Overview.

14.14.1. CDIDataImportCronOutdated

Signification

Cette alerte se déclenche lorsque DataImportCron ne peut pas interroger ou importer les dernières versions des images de disque.

DataImportCron ce processus permet de mettre à jour les images de disques Polls, de vérifier les dernières versions et d'importer les images en tant que réclamations de volumes persistants (PVC). Ce processus garantit que les PVC sont mis à jour à la dernière version afin qu'ils puissent être utilisés comme sources de clone fiables ou comme images dorées pour les machines virtuelles (VM).

Pour les images dorées, latest fait référence au dernier système d'exploitation de la distribution. Pour les autres images de disque, latest renvoie au dernier hachage de l'image disponible.

Impact

Les machines virtuelles peuvent être créées à partir d'images de disque obsolètes.

Les machines virtuelles peuvent ne pas démarrer parce qu'aucun PVC source n'est disponible pour le clonage.

Diagnostic

  1. Vérifiez que le cluster dispose d'une classe de stockage par défaut : 

    $ oc get sc

    La sortie affiche les classes de stockage avec (default) à côté du nom de la classe de stockage par défaut. Vous devez définir une classe de stockage par défaut, soit sur le cluster, soit dans la spécification DataImportCron, pour que DataImportCron interroge et importe des images dorées. Si aucune classe de stockage n'est définie, le contrôleur DataVolume ne parvient pas à créer de PVC et l'événement suivant s'affiche : DataVolume.storage spec is missing accessMode and no storageClass to choose profile.

  2. Obtenir l'espace de noms et le nom de DataImportCron: 

    $ oc get dataimportcron -A -o json | jq -r '.items[] | \
  select(.status.conditions[] | select(.type == "UpToDate" and \
  .status == "False")) | .metadata.namespace + "/" + .metadata.name'

  3. Si une classe de stockage par défaut n'est pas définie sur le cluster, vérifiez la spécification DataImportCron pour une classe de stockage par défaut : 

    $ oc get dataimportcron <dataimportcron> -o yaml | \
  grep -B 5 storageClassName

    Exemple de sortie

          url: docker://.../cdi-func-test-tinycore
    storage:
      resources:
        requests:
          storage: 5Gi
    storageClassName: rook-ceph-block

  4. Obtenir le nom de l'objet DataVolume associé à l'objet DataImportCron: 

    $ oc -n <namespace> get dataimportcron <dataimportcron> -o json | \
  jq .status.lastImportedPVC.name

  5. Vérifiez les messages d'erreur dans le journal DataVolume: 

    oc -n <namespace> get dv <datavolume> -o yaml

  6. Définir la variable d'environnement CDI_NAMESPACE: 

    $ export CDI_NAMESPACE="$(oc get deployment -A | \
  grep cdi-operator | awk '{print $1}')"

  7. Vérifiez les messages d'erreur dans le journal cdi-deployment: 

    $ oc logs -n $CDI_NAMESPACE deployment/cdi-deployment
Atténuation
  1. Définissez une classe de stockage par défaut, soit sur le cluster, soit dans la spécification DataImportCron, pour interroger et importer les images dorées. La mise à jour de Containerized Data Importer (CDI) résoudra le problème en quelques secondes.
  2. Si le problème n'est pas résolu, supprimez les volumes de données associés aux objets DataImportCron concernés. Le CDI recréera les volumes de données avec la classe de stockage par défaut.

  3. Si votre cluster est installé dans un environnement réseau restreint, désactivez la fonctionnalité enableCommonBootImageImport afin de ne pas recevoir de mises à jour automatiques : 

    $ oc patch hco kubevirt-hyperconverged -n $CDI_NAMESPACE --type json \
  -p '[{"op": "replace", "path": \
  "/spec/featureGates/enableCommonBootImageImport", "value": false}]'

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.2. CDIDataVolumeUnusualRestartCount

Signification

Cette alerte se déclenche lorsqu'un objet DataVolume redémarre plus de trois fois.

Impact

Les volumes de données sont responsables de l'importation et de la création d'un disque de machine virtuelle sur une revendication de volume persistant. Si un volume de données redémarre plus de trois fois, il est peu probable que ces opérations aboutissent. Vous devez diagnostiquer et résoudre le problème.

Diagnostic

  1. Obtenir le nom et l'espace de noms du volume de données : 

    $ oc get dv -A -o json | jq -r '.items[] | \
  select(.status.restartCount>3)' | jq '.metadata.name, .metadata.namespace'

  2. Vérifiez l'état des pods associés au volume de données : 

    $ oc get pods -n <namespace> -o json | jq -r '.items[] | \
  select(.metadata.ownerReferences[] | \
  select(.name=="<dv_name>")).metadata.name'

  3. Obtenir les coordonnées des nacelles : 

    oc -n <namespace> describe pods <pod>

  4. Vérifiez les messages d'erreur dans les journaux de pods : 

    oc -n <namespace> describe logs <pod>
Atténuation

Supprimez le volume de données, résolvez le problème et créez un nouveau volume de données.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.3. CDINotReady

Signification

Cette alerte se déclenche lorsque l'importateur de données conteneurisées (CDI) est dans un état dégradé :

  • Pas de progrès
  • Non disponible à l'utilisation
Impact

CDI n'est pas utilisable, les utilisateurs ne peuvent donc pas construire de disques de machines virtuelles sur des réclamations de volumes persistants (PVC) en utilisant les volumes de données de CDI. Les composants de CDI ne sont pas prêts et ils ont cessé de progresser vers un état prêt.

Diagnostic

  1. Définir la variable d'environnement CDI_NAMESPACE: 

    $ export CDI_NAMESPACE="$(oc get deployment -A | \
  grep cdi-operator | awk '{print $1}')"

  2. Vérifier le déploiement du CDI pour les composants qui ne sont pas prêts : 

    $ oc -n $CDI_NAMESPACE get deploy -l cdi.kubevirt.io

  3. Vérifier les détails du pod défaillant : 

    oc -n $CDI_NAMESPACE describe pods <pod>

  4. Vérifiez les journaux du module défaillant : 

    $ oc -n $CDI_NAMESPACE logs <pod>
Atténuation

Essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.4. CDIOperatorDown

Signification

Cette alerte se déclenche lorsque l'opérateur de l'importateur de données conteneurisées (CDI) est hors service. L'opérateur CDI déploie et gère les composants de l'infrastructure CDI, tels que les contrôleurs de volumes de données et de réclamations de volumes persistants (PVC). Ces contrôleurs aident les utilisateurs à construire des disques de machines virtuelles sur des PVC.

Impact

Les composants CDI peuvent ne pas se déployer ou rester dans un état requis. L'installation du CDI peut ne pas fonctionner correctement.

Diagnostic

  1. Définir la variable d'environnement CDI_NAMESPACE: 

    $ export CDI_NAMESPACE="$(oc get deployment -A | grep cdi-operator | \
  awk '{print $1}')"

  2. Vérifier si le pod cdi-operator est en cours d'exécution : 

    $ oc -n $CDI_NAMESPACE get pods -l name=cdi-operator

  3. Obtenir les coordonnées de la nacelle cdi-operator: 

    $ oc -n $CDI_NAMESPACE describe pods -l name=cdi-operator

  4. Vérifiez si le journal du pod cdi-operator contient des erreurs : 

    $ oc -n $CDI_NAMESPACE logs -l name=cdi-operator
Atténuation

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.5. CDIStorageProfilesIncomplete

Signification

Cette alerte se déclenche lorsqu'un profil de stockage Containerized Data Importer (CDI) est incomplet.

Si un profil de stockage est incomplet, le CDI ne peut pas déduire les champs PVC (persistent volume claim), tels que volumeMode et accessModes, qui sont nécessaires pour créer un disque de machine virtuelle (VM).

Impact

Le CDI ne peut pas créer de disque VM sur le PVC.

Diagnostic

  • Identifier le profil de stockage incomplet : 

    oc get storageprofile <storage_class> $ oc get storageprofile <storage_class>
Atténuation

  • Ajoutez les informations manquantes du profil de stockage comme dans l'exemple suivant : 

    $ oc patch storageprofile local --type=merge -p '{"spec": \
  {"claimPropertySets": [{"accessModes": ["ReadWriteOnce"], \
  "volumeMode": "Filesystem"}]}}'

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.6. CnaoDown

Signification

Cette alerte se déclenche lorsque le Cluster Network Addons Operator (CNAO) est hors service. Le CNAO déploie des composants réseau supplémentaires au-dessus du cluster.

Impact

Si l'ACAO n'est pas en cours d'exécution, le cluster ne peut pas réconcilier les modifications apportées aux composants des machines virtuelles. Par conséquent, les modifications risquent de ne pas être prises en compte.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get deployment -A | \
  grep cluster-network-addons-operator | awk '{print $1}')"

  2. Vérifier l'état du pod cluster-network-addons-operator: 

    $ oc -n $NAMESPACE get pods -l name=cluster-network-addons-operator

  3. Vérifiez les messages d'erreur dans les journaux de cluster-network-addons-operator: 

    $ oc -n $NAMESPACE logs -l name=cluster-network-addons-operator

  4. Obtenir les informations sur les nacelles du site cluster-network-addons-operator: 

    $ oc -n $NAMESPACE describe pods -l name=cluster-network-addons-operator
Atténuation

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.7. HPPNotReady

Signification

Cette alerte se déclenche lorsqu'une installation de Hostpath Provisioner (HPP) est dans un état dégradé.

Le HPP provisionne dynamiquement les volumes du chemin d'accès de l'hôte afin de fournir un stockage pour les réclamations de volumes persistants (PVC).

Impact

Le HPP n'est pas utilisable. Ses composants ne sont pas prêts et ne progressent pas vers un état de préparation.

Diagnostic

  1. Définir la variable d'environnement HPP_NAMESPACE: 

    $ export HPP_NAMESPACE="$(oc get deployment -A | \
  grep hostpath-provisioner-operator | awk '{print $1}')"

  2. Vérifier les composants HPP qui ne sont pas encore prêts : 

    $ oc -n $HPP_NAMESPACE get all -l k8s-app=hostpath-provisioner

  3. Obtenir les coordonnées de la nacelle défaillante : 

    oc -n $HPP_NAMESPACE describe pods <pod>

  4. Vérifiez les journaux du module défaillant : 

    $ oc -n $HPP_NAMESPACE logs <pod>
Atténuation

Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.8. HPPOperatorDown

Signification

Cette alerte est déclenchée lorsque l'opérateur HPP (hostpath provisioner) est en panne.

L'opérateur HPP déploie et gère les composants de l'infrastructure HPP, tels que le jeu de démons qui approvisionne les volumes des chemins d'accès à l'hôte.

Impact

Les composants HPP risquent de ne pas se déployer ou de ne pas rester dans l'état requis. Par conséquent, l'installation HPP peut ne pas fonctionner correctement dans le cluster.

Diagnostic

  1. Configurez la variable d'environnement HPP_NAMESPACE: 

    $ HPP_NAMESPACE="$(oc get deployment -A | grep \
  hostpath-provisioner-operator | awk '{print $1}')"

  2. Vérifier si le pod hostpath-provisioner-operator est en cours d'exécution : 

    $ oc -n $HPP_NAMESPACE get pods -l name=hostpath-provisioner-operator

  3. Obtenir les coordonnées de la nacelle hostpath-provisioner-operator: 

    $ oc -n $HPP_NAMESPACE describe pods -l name=hostpath-provisioner-operator

  4. Vérifiez si le journal du pod hostpath-provisioner-operator contient des erreurs : 

    $ oc -n $HPP_NAMESPACE logs -l name=hostpath-provisioner-operator
Atténuation

Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.9. HPPSharingPoolPathWithOS

Signification

Cette alerte se déclenche lorsque le hostpath provisioner (HPP) partage un système de fichiers avec d'autres composants critiques, tels que kubelet ou le système d'exploitation (OS).

HPP fournit dynamiquement des volumes de chemin d'accès à l'hôte pour assurer le stockage des réclamations de volumes persistants (PVC).

Impact

Un pool de chemins d'accès partagés exerce une pression sur les disques du nœud. Les performances et la stabilité du nœud peuvent se dégrader.

Diagnostic

  1. Configurez la variable d'environnement HPP_NAMESPACE: 

    $ export HPP_NAMESPACE="$(oc get deployment -A | \
  grep hostpath-provisioner-operator | awk '{print $1}')"

  2. Obtenir l'état du démon hostpath-provisioner-csi set pods : 

    $ oc -n $HPP_NAMESPACE get pods | grep hostpath-provisioner-csi

  3. Consultez les journaux de hostpath-provisioner-csi pour identifier le pool partagé et le chemin d'accès : 

    oc -n $HPP_NAMESPACE logs <csi_daemonset> -c hostpath-provisioner

    Exemple de sortie

    I0208 15:21:03.769731       1 utils.go:221] pool (<legacy, csi-data-dir>/csi),
shares path with OS which can lead to node disk pressure

Atténuation

À l'aide des données obtenues dans la section Diagnostic, essayez d'empêcher le partage du chemin d'accès au pool avec le système d'exploitation. Les étapes spécifiques varient en fonction du nœud et d'autres circonstances.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.10. KubeMacPoolDown

Signification

KubeMacPool est en panne. KubeMacPool est responsable de l'attribution des adresses MAC et de la prévention des conflits d'adresses MAC.

Impact

Si KubeMacPool est en panne, les objets VirtualMachine ne peuvent pas être créés.

Diagnostic

  1. Définir la variable d'environnement KMP_NAMESPACE: 

    $ export KMP_NAMESPACE="$(oc get pod -A --no-headers -l \
  control-plane=mac-controller-manager | awk '{print $1}')"

  2. Définir la variable d'environnement KMP_NAME: 

    $ export KMP_NAME="$(oc get pod -A --no-headers -l \
  control-plane=mac-controller-manager | awk '{print $2}')"

  3. Obtenir les coordonnées du pod KubeMacPool-manager: 

    $ oc describe pod -n $KMP_NAMESPACE $KMP_NAME

  4. Vérifiez les messages d'erreur dans les journaux de KubeMacPool-manager: 

    $ oc logs -n $KMP_NAMESPACE $KMP_NAME
Atténuation

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.11. KubeMacPoolDuplicateMacsFound

Signification

Cette alerte se déclenche lorsque KubeMacPool détecte des adresses MAC en double.

KubeMacPool est responsable de l'attribution des adresses MAC et de la prévention des conflits d'adresses MAC. Au démarrage de KubeMacPool, il recherche dans le cluster les adresses MAC des machines virtuelles (VM) dans les espaces de noms gérés.

Impact

Les adresses MAC en double sur le même réseau local peuvent causer des problèmes de réseau.

Diagnostic

  1. Obtenir l'espace de noms et le nom du pod kubemacpool-mac-controller: 

    $ oc get pod -A -l control-plane=mac-controller-manager --no-headers \
  -o custom-columns=":metadata.namespace,:metadata.name"

  2. Obtenir les adresses MAC dupliquées à partir des journaux kubemacpool-mac-controller: 

    $ oc logs -n <namespace> <kubemacpool_mac_controller> | \
  grep "already allocated"

    Exemple de sortie

    mac address 02:00:ff:ff:ff:ff already allocated to
vm/kubemacpool-test/testvm, br1,
conflict with: vm/kubemacpool-test/testvm2, br1

Atténuation
  1. Mettez à jour les machines virtuelles pour supprimer les adresses MAC en double.

  2. Redémarrez le pod kubemacpool-mac-controller: 

    oc delete pod -n <namespace> <kubemacpool_mac_controller>

14.14.12. KubeVirtComponentExceedsRequestedCPU (composant KubeVirt)

Signification

Cette alerte se déclenche lorsque l'utilisation de l'unité centrale d'un composant dépasse la limite demandée.

Impact

L'utilisation des ressources de l'unité centrale n'est pas optimale et le nœud pourrait être surchargé.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Vérifier la limite de demande de l'unité centrale du composant : 

    oc -n $NAMESPACE get deployment <component> -o yaml | grep requests : -A 2

  3. Vérifiez l'utilisation réelle de l'unité centrale à l'aide d'une requête PromQL : 

    node_namespace_pod_container:container_cpu_usage_seconds_total:sum_rate
{namespace="$NAMESPACE",container="<component>"}

Voir la documentation Prometheus pour plus d'informations.

Atténuation

Mettre à jour la limite de demande de CPU dans la ressource personnalisée HCO.

14.14.13. KubeVirtComponentExceedsRequestedMemory (Dépasse la mémoire demandée)

Signification

Cette alerte se déclenche lorsque l'utilisation de la mémoire d'un composant dépasse la limite demandée.

Impact

L'utilisation des ressources mémoire n'est pas optimale et le nœud peut être surchargé.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Vérifier la limite de demande de mémoire du composant : 

    $ oc -n $NAMESPACE get deployment <component> -o yaml | \
  grep requests: -A 2

  3. Vérifiez l'utilisation réelle de la mémoire à l'aide d'une requête PromQL : 

    container_memory_usage_bytes{namespace="$NAMESPACE",container="<component>"}

Voir la documentation Prometheus pour plus d'informations.

Atténuation

Mettre à jour la limite de demande de mémoire dans la ressource personnalisée HCO.

14.14.14. KubevirtHyperconvergedClusterOperatorCRModification

Signification

Cette alerte se déclenche lorsqu'un opérande de l'opérateur de cluster hyperconvergé (HCO) est modifié par quelqu'un ou quelque chose d'autre que HCO.

HCO configure OpenShift Virtualization et ses opérateurs de support d'une manière fondée sur l'opinion et écrase ses opérandes lorsqu'il y a un changement inattendu à leur égard. Les utilisateurs ne doivent pas modifier les opérandes directement. La ressource personnalisée HyperConverged est la source de vérité pour la configuration.

Impact

La modification manuelle des opérandes entraîne une fluctuation de la configuration du cluster et peut conduire à une instabilité.

Diagnostic

  • Vérifiez la valeur component_name dans les détails de l'alerte pour déterminer le type d'opérande (kubevirt) et le nom de l'opérande (kubevirt-kubevirt-hyperconverged) qui sont modifiés : 

    Labels
  alertname=KubevirtHyperconvergedClusterOperatorCRModification
  component_name=kubevirt/kubevirt-kubevirt-hyperconverged
  severity=warning
Atténuation

Ne modifiez pas directement les opérandes HCO. Utilisez les objets HyperConverged pour configurer le cluster.

L'alerte se résout d'elle-même après 10 minutes si les opérandes ne sont pas modifiés manuellement.

14.14.15. KubevirtHyperconvergedClusterOperatorInstallationNotCompletedAlert (alerte d'installation non terminée)

Signification

Cette alerte se déclenche lorsque l'opérateur de cluster hyperconvergé (HCO) fonctionne pendant plus d'une heure sans ressource personnalisée (CR) HyperConverged.

Cette alerte a les causes suivantes :

  • Au cours de la procédure d'installation, vous avez installé le HCO mais vous n'avez pas créé le CR HyperConverged.
  • Au cours du processus de désinstallation, vous avez supprimé le CR HyperConverged avant de désinstaller le HCO et le HCO est toujours en cours d'exécution.
Atténuation

L'atténuation dépend de l'installation ou de la désinstallation du HCO :

  • Terminez l'installation en créant un CR HyperConverged avec ses valeurs par défaut : 

    $ cat <<EOF | oc apply -f -
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
  name: hco-operatorgroup
  namespace: kubevirt-hyperconverged
spec: {}
EOF
  • Désinstallez le HCO. Si le processus de désinstallation continue de s'exécuter, vous devez résoudre ce problème afin d'annuler l'alerte.

14.14.16. KubevirtHyperconvergedClusterOperatorUSModification

Signification

Cette alerte se déclenche lorsqu'une annotation JSON Patch est utilisée pour modifier un opérande de l'opérateur de cluster hyperconvergé (HCO).

HCO configure OpenShift Virtualization et ses opérateurs de support d'une manière fondée sur l'opinion et écrase ses opérandes lorsqu'il y a un changement inattendu à leur égard. Les utilisateurs ne doivent pas modifier les opérandes directement.

Toutefois, si une modification est nécessaire et qu'elle n'est pas prise en charge par l'API du HCO, vous pouvez forcer le HCO à définir une modification dans un opérateur à l'aide d'annotations JSON Patch. Ces modifications ne sont pas annulées par le HCO au cours de son processus de réconciliation.

Impact

L'utilisation incorrecte des annotations JSON Patch peut conduire à des résultats inattendus ou à un environnement instable.

La mise à jour d'un système avec des annotations JSON Patch est dangereuse car la structure des ressources personnalisées des composants peut changer.

Diagnostic

  • Consultez le site annotation_name dans les détails de l'alerte pour identifier l'annotation JSON Patch : 

    Labels
  alertname=KubevirtHyperconvergedClusterOperatorUSModification
  annotation_name=kubevirt.kubevirt.io/jsonpatch
  severity=info
Atténuation

Il est préférable d'utiliser l'API HCO pour modifier un opérande. Toutefois, si la modification ne peut être effectuée qu'à l'aide d'une annotation JSON Patch, il convient de procéder avec prudence.

Supprimer les annotations JSON Patch avant la mise à jour pour éviter les problèmes potentiels.

14.14.17. KubevirtVmHighMemoryUsage

Signification

Cette alerte se déclenche lorsqu'un conteneur hébergeant une machine virtuelle (VM) dispose de moins de 20 Mo de mémoire libre.

Impact

La machine virtuelle s'exécutant dans le conteneur est arrêtée par le moteur d'exécution si la limite de mémoire du conteneur est dépassée.

Diagnostic

  1. Obtenir les coordonnées du pod virt-launcher: 

    $ oc get pod <virt-launcher> -o yaml

  2. Identifier les processus du conteneur compute qui utilisent beaucoup de mémoire dans le pod virt-launcher: 

    oc exec -it <virt-launcher> -c compute -- top
Atténuation

  • Augmentez la limite de mémoire dans la spécification VirtualMachine comme dans l'exemple suivant : 

    spec:
  running: false
  template:
    metadata:
      labels:
        kubevirt.io/vm: vm-name
    spec:
      domain:
        resources:
          limits:
            memory: 200Mi
          requests:
            memory: 128Mi

14.14.18. KubeVirtVMIExcessiveMigrations

Signification

Cette alerte se déclenche lorsqu'une instance de machine virtuelle (VMI) migre en direct plus de 12 fois sur une période de 24 heures.

Ce taux de migration est anormalement élevé, même lors d'une mise à niveau. Cette alerte peut indiquer un problème dans l'infrastructure du cluster, comme des perturbations du réseau ou des ressources insuffisantes.

Impact

Une machine virtuelle (VM) qui migre trop fréquemment risque de voir ses performances se dégrader car des erreurs de page mémoire se produisent pendant la transition.

Diagnostic

  1. Vérifiez que le nœud de travail dispose de ressources suffisantes : 

    $ oc get nodes -l node-role.kubernetes.io/worker= -o json | \
  jq .items[].status.allocatable

    Exemple de sortie

    {
  "cpu": "3500m",
  "devices.kubevirt.io/kvm": "1k",
  "devices.kubevirt.io/sev": "0",
  "devices.kubevirt.io/tun": "1k",
  "devices.kubevirt.io/vhost-net": "1k",
  "ephemeral-storage": "38161122446",
  "hugepages-1Gi": "0",
  "hugepages-2Mi": "0",
  "memory": "7000128Ki",
  "pods": "250"
}

  2. Vérifier l'état du nœud de travail : 

    $ oc get nodes -l node-role.kubernetes.io/worker= -o json | \
  jq .items[].status.conditions

    Exemple de sortie

    {
  "lastHeartbeatTime": "2022-05-26T07:36:01Z",
  "lastTransitionTime": "2022-05-23T08:12:02Z",
  "message": "kubelet has sufficient memory available",
  "reason": "KubeletHasSufficientMemory",
  "status": "False",
  "type": "MemoryPressure"
},
{
  "lastHeartbeatTime": "2022-05-26T07:36:01Z",
  "lastTransitionTime": "2022-05-23T08:12:02Z",
  "message": "kubelet has no disk pressure",
  "reason": "KubeletHasNoDiskPressure",
  "status": "False",
  "type": "DiskPressure"
},
{
  "lastHeartbeatTime": "2022-05-26T07:36:01Z",
  "lastTransitionTime": "2022-05-23T08:12:02Z",
  "message": "kubelet has sufficient PID available",
  "reason": "KubeletHasSufficientPID",
  "status": "False",
  "type": "PIDPressure"
},
{
  "lastHeartbeatTime": "2022-05-26T07:36:01Z",
  "lastTransitionTime": "2022-05-23T08:24:15Z",
  "message": "kubelet is posting ready status",
  "reason": "KubeletReady",
  "status": "True",
  "type": "Ready"
}

  3. Connectez-vous au nœud de travail et vérifiez que le service kubelet est en cours d'exécution : 

    $ systemctl status kubelet

  4. Vérifiez les messages d'erreur dans le journal kubelet: 

    $ journalctl -r -u kubelet
Atténuation

Assurez-vous que les nœuds de travail disposent de ressources suffisantes (CPU, mémoire, disque) pour exécuter les charges de travail des VM sans interruption.

Si le problème persiste, essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.19. KubeVirtVMStuckInErrorState

Signification

Cette alerte se déclenche lorsqu'une machine virtuelle (VM) est dans un état d'erreur pendant plus de 5 minutes.

États d'erreur :

  • CrashLoopBackOff
  • Inconnu
  • Insaisissable
  • ErrImagePull
  • ImagePullBackOff
  • PvcNotFound
  • Erreur de volume de données

Cette alerte peut indiquer un problème au niveau de la configuration de la VM, par exemple une réclamation de volume persistant manquante, ou un problème au niveau de l'infrastructure du cluster, par exemple des perturbations du réseau ou des ressources insuffisantes au niveau des nœuds.

Impact

Il n'y a pas d'impact immédiat. Cependant, si l'alerte persiste, vous devez rechercher la cause première et résoudre le problème.

Diagnostic

  1. Vérifiez les détails de l'instance de machine virtuelle (VMI) : 

    $ oc describe vmi <vmi> -n <namespace>

    Exemple de sortie

    Name:          testvmi-hxghp
Namespace:     kubevirt-test-default1
Labels:        name=testvmi-hxghp
Annotations:   kubevirt.io/latest-observed-api-version: v1
               kubevirt.io/storage-observed-api-version: v1alpha3
API Version:   kubevirt.io/v1
Kind:          VirtualMachineInstance
...
Spec:
  Domain:
...
    Resources:
      Requests:
        Cpu:     5000000Gi
        Memory:  5130000240Mi
...
Status:
...
  Conditions:
    Last Probe Time:       2022-10-03T11:11:07Z
    Last Transition Time:  2022-10-03T11:11:07Z
    Message:               Guest VM is not reported as running
    Reason:                GuestNotRunning
    Status:                False
    Type:                  Ready
    Last Probe Time:       <nil>
    Last Transition Time:  2022-10-03T11:11:07Z
    Message:               0/2 nodes are available: 2 Insufficient cpu, 2
      Insufficient memory.
    Reason:                Unschedulable
    Status:                False
    Type:                  PodScheduled
  Guest OS Info:
  Phase:  Scheduling
  Phase Transition Timestamps:
    Phase:                        Pending
    Phase Transition Timestamp:   2022-10-03T11:11:07Z
    Phase:                        Scheduling
    Phase Transition Timestamp:   2022-10-03T11:11:07Z
  Qos Class:                       Burstable
  Runtime User:                    0
  Virtual Machine Revision Name:   revision-start-vm-3503e2dc-27c0-46ef-9167-7ae2e7d93e6e-1
Events:
  Type    Reason            Age   From                       Message
  ----    ------            ----  ----                       -------
  Normal  SuccessfulCreate  27s   virtualmachine-controller  Created virtual
    machine pod virt-launcher-testvmi-hxghp-xh9qn

  2. Vérifier les ressources du nœud : 

    $ oc get nodes -l node-role.kubernetes.io/worker= -o json | jq '.items | \
  .[].status.allocatable'

    Exemple de sortie

    {
  "cpu": "5",
  "devices.kubevirt.io/kvm": "1k",
  "devices.kubevirt.io/sev": "0",
  "devices.kubevirt.io/tun": "1k",
  "devices.kubevirt.io/vhost-net": "1k",
  "ephemeral-storage": "33812468066",
  "hugepages-1Gi": "0",
  "hugepages-2Mi": "128Mi",
  "memory": "3783496Ki",
  "pods": "110"
}

  3. Vérifier que le nœud ne présente pas de conditions d'erreur : 

    $ oc get nodes -l node-role.kubernetes.io/worker= -o json | jq '.items | \
  .[].status.conditions'

    Exemple de sortie

    [
  {
    "lastHeartbeatTime": "2022-10-03T11:13:34Z",
    "lastTransitionTime": "2022-10-03T10:14:20Z",
    "message": "kubelet has sufficient memory available",
    "reason": "KubeletHasSufficientMemory",
    "status": "False",
    "type": "MemoryPressure"
  },
  {
    "lastHeartbeatTime": "2022-10-03T11:13:34Z",
    "lastTransitionTime": "2022-10-03T10:14:20Z",
    "message": "kubelet has no disk pressure",
    "reason": "KubeletHasNoDiskPressure",
    "status": "False",
    "type": "DiskPressure"
  },
  {
    "lastHeartbeatTime": "2022-10-03T11:13:34Z",
    "lastTransitionTime": "2022-10-03T10:14:20Z",
    "message": "kubelet has sufficient PID available",
    "reason": "KubeletHasSufficientPID",
    "status": "False",
    "type": "PIDPressure"
  },
  {
    "lastHeartbeatTime": "2022-10-03T11:13:34Z",
    "lastTransitionTime": "2022-10-03T10:14:30Z",
    "message": "kubelet is posting ready status",
    "reason": "KubeletReady",
    "status": "True",
    "type": "Ready"
  }
]

Atténuation

Essayez d'identifier et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.20. KubeVirtVMStuckInMigratingState

Signification

Cette alerte se déclenche lorsqu'une machine virtuelle (VM) est en état de migration pendant plus de 5 minutes.

Cette alerte peut indiquer un problème dans l'infrastructure de la grappe, comme des perturbations du réseau ou des ressources insuffisantes au niveau des nœuds.

Impact

Il n'y a pas d'impact immédiat. Cependant, si l'alerte persiste, vous devez rechercher la cause première et résoudre le problème.

Diagnostic

  1. Vérifier les ressources du nœud : 

    $ oc get nodes -l node-role.kubernetes.io/worker= -o json | jq '.items | \
  .[].status.allocatable'

    Exemple de sortie

    {
   "cpu": "5",
   "devices.kubevirt.io/kvm": "1k",
   "devices.kubevirt.io/sev": "0",
   "devices.kubevirt.io/tun": "1k",
   "devices.kubevirt.io/vhost-net": "1k",
   "ephemeral-storage": "33812468066",
   "hugepages-1Gi": "0",
   "hugepages-2Mi": "128Mi",
   "memory": "3783496Ki",
   "pods": "110"
}

  2. Vérifier les conditions d'état du nœud : 

    $ oc get nodes -l node-role.kubernetes.io/worker= -o json | jq '.items | \
  .[].status.conditions'

    Exemple de sortie

    [
  {
    "lastHeartbeatTime": "2022-10-03T11:13:34Z",
    "lastTransitionTime": "2022-10-03T10:14:20Z",
    "message": "kubelet has sufficient memory available",
    "reason": "KubeletHasSufficientMemory",
    "status": "False",
    "type": "MemoryPressure"
  },
  {
    "lastHeartbeatTime": "2022-10-03T11:13:34Z",
    "lastTransitionTime": "2022-10-03T10:14:20Z",
    "message": "kubelet has no disk pressure",
    "reason": "KubeletHasNoDiskPressure",
    "status": "False",
    "type": "DiskPressure"
  },
  {
    "lastHeartbeatTime": "2022-10-03T11:13:34Z",
    "lastTransitionTime": "2022-10-03T10:14:20Z",
    "message": "kubelet has sufficient PID available",
    "reason": "KubeletHasSufficientPID",
    "status": "False",
    "type": "PIDPressure"
  },
  {
    "lastHeartbeatTime": "2022-10-03T11:13:34Z",
    "lastTransitionTime": "2022-10-03T10:14:30Z",
    "message": "kubelet is posting ready status",
    "reason": "KubeletReady",
    "status": "True",
    "type": "Ready"
  }
]

Atténuation

Vérifiez la configuration de la migration de la machine virtuelle pour vous assurer qu'elle est adaptée à la charge de travail.

Vous définissez une configuration de migration à l'échelle du cluster en modifiant la strophe MigrationConfiguration de la ressource personnalisée KubeVirt.

Vous définissez une configuration de migration pour une portée spécifique en créant une politique de migration.

Vous pouvez déterminer si une VM est liée à une politique de migration en consultant son paramètre vm.Status.MigrationState.MigrationPolicyName.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.21. KubeVirtVMStuckInStartingState (état de démarrage)

Signification

Cette alerte se déclenche lorsqu'une machine virtuelle (VM) est dans un état de démarrage pendant plus de 5 minutes.

Cette alerte peut indiquer un problème dans la configuration de la VM, comme une classe de priorité mal configurée ou un périphérique réseau manquant.

Impact

Il n'y a pas d'impact immédiat. Cependant, si l'alerte persiste, vous devez rechercher la cause première et résoudre le problème.

Diagnostic

  • Vérifiez les détails de l'instance de machine virtuelle (VMI) pour les conditions d'erreur : 

    $ oc describe vmi <vmi> -n <namespace>

    Exemple de sortie

    Name:          testvmi-ldgrw
Namespace:     kubevirt-test-default1
Labels:        name=testvmi-ldgrw
Annotations:   kubevirt.io/latest-observed-api-version: v1
               kubevirt.io/storage-observed-api-version: v1alpha3
API Version:   kubevirt.io/v1
Kind:          VirtualMachineInstance
...
Spec:
...
  Networks:
    Name:  default
    Pod:
  Priority Class Name:               non-preemtible
  Termination Grace Period Seconds:  0
Status:
  Conditions:
    Last Probe Time:       2022-10-03T11:08:30Z
    Last Transition Time:  2022-10-03T11:08:30Z
    Message:               virt-launcher pod has not yet been scheduled
    Reason:                PodNotExists
    Status:                False
    Type:                  Ready
    Last Probe Time:       <nil>
    Last Transition Time:  2022-10-03T11:08:30Z
    Message:               failed to create virtual machine pod: pods
    "virt-launcher-testvmi-ldgrw-" is forbidden: no PriorityClass with name
    non-preemtible was found
    Reason:                FailedCreate
    Status:                False
    Type:                  Synchronized
  Guest OS Info:
  Phase:  Pending
  Phase Transition Timestamps:
    Phase:                        Pending
    Phase Transition Timestamp:   2022-10-03T11:08:30Z
  Runtime User:                    0
  Virtual Machine Revision Name:
    revision-start-vm-6f01a94b-3260-4c5a-bbe5-dc98d13e6bea-1
Events:
  Type     Reason        Age                From                       Message
  ----     ------        ----               ----                       -------
  Warning  FailedCreate  8s (x13 over 28s)  virtualmachine-controller  Error
  creating pod: pods "virt-launcher-testvmi-ldgrw-" is forbidden: no
  PriorityClass with name non-preemtible was found

Atténuation

Assurez-vous que la VM est configurée correctement et qu'elle dispose des ressources nécessaires.

L'état Pending indique que la VM n'a pas encore été planifiée. Vérifiez les causes possibles suivantes :

  • Le pod virt-launcher n'est pas programmé.
  • Les indications topologiques pour l'IMV ne sont pas à jour.
  • Le volume de données n'est pas provisionné ou prêt.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.22. LowKVMNodesCount

Signification

Cette alerte se déclenche lorsque moins de deux nœuds de la grappe disposent de ressources KVM.

Impact

La grappe doit comporter au moins deux nœuds dotés de ressources KVM pour la migration en direct.

Les machines virtuelles ne peuvent pas être planifiées ou exécutées si aucun nœud ne dispose de ressources KVM.

Diagnostic

  • Identifier les nœuds disposant de ressources KVM : 

    $ oc get nodes -o jsonpath='{.items[*].status.allocatable}' | \
  grep devices.kubevirt.io/kvm
Atténuation

Installez KVM sur les nœuds ne disposant pas de ressources KVM.

14.14.23. LowReadyVirtControllersCount (Nombre de contrôleurs de protection prêts à l'emploi)

Signification

Cette alerte se déclenche lorsqu'un ou plusieurs pods virt-controller sont en cours d'exécution, mais qu'aucun de ces pods n'a été dans l'état Ready au cours des 5 dernières minutes.

Un dispositif virt-controller surveille les définitions de ressources personnalisées (CRD) d'une instance de machine virtuelle (VMI) et gère les pods associés. Le dispositif crée des pods pour les VMI et gère leur cycle de vie. Ce dispositif est essentiel pour la fonctionnalité de virtualisation à l'échelle de la grappe.

Impact

Cette alerte indique qu'une défaillance au niveau du cluster risque de se produire. Les actions liées à la gestion du cycle de vie des VM, telles que le lancement d'une nouvelle VMI ou l'arrêt d'une VMI existante, échoueront.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Vérifiez qu'un dispositif virt-controller est disponible : 

    $ oc get deployment -n $NAMESPACE virt-controller \
  -o jsonpath='{.status.readyReplicas}'

  3. Vérifiez l'état du déploiement de virt-controller: 

    $ oc -n $NAMESPACE get deploy virt-controller -o yaml

  4. Obtenez les détails du déploiement de virt-controller pour vérifier les conditions d'état, telles que les pods en panne ou les échecs d'extraction d'images : 

    $ oc -n $NAMESPACE describe deploy virt-controller

  5. Vérifiez si des problèmes sont survenus avec les nœuds. Par exemple, ils peuvent être dans l'état NotReady: 

    $ oc get nodes
Atténuation

Cette alerte peut avoir des causes multiples, notamment les suivantes :

  • La mémoire du cluster est insuffisante.
  • Les nœuds sont en panne.
  • Le serveur API est surchargé. Par exemple, le planificateur peut être très sollicité et n'est donc pas entièrement disponible.
  • Il y a des problèmes de réseau.

Essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.24. LowReadyVirtOperatorsCount (Nombre d'opérateurs prêts à fonctionner)

Signification

Cette alerte se déclenche lorsqu'un ou plusieurs pods virt-operator sont en cours d'exécution, mais qu'aucun de ces pods n'a été en état Ready au cours des 10 dernières minutes.

Le virt-operator est le premier opérateur à démarrer dans un cluster. Le déploiement virt-operator a une réplique par défaut de deux pods virt-operator.

Ses principales responsabilités sont les suivantes

  • Installation, mise à jour en direct et mise à niveau en direct d'un cluster
  • Surveiller le cycle de vie des contrôleurs de premier niveau, tels que virt-controller, virt-handler, virt-launcher, et gérer leur rapprochement
  • Certaines tâches à l'échelle de la grappe, telles que la rotation des certificats et la gestion de l'infrastructure
Impact

Une panne au niveau de la grappe peut se produire. Les fonctionnalités de gestion critiques à l'échelle de la grappe, telles que la rotation des certifications, la mise à niveau et le rapprochement des contrôleurs, peuvent devenir indisponibles. Un tel état déclenche également l'alerte NoReadyVirtOperator.

Le site virt-operator n'est pas directement responsable des machines virtuelles (VM) dans le cluster. Par conséquent, son indisponibilité temporaire n'affecte pas de manière significative les charges de travail des machines virtuelles.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Obtenir le nom du déploiement virt-operator: 

    $ oc -n $NAMESPACE get deploy virt-operator -o yaml

  3. Obtenir les détails du déploiement de virt-operator: 

    $ oc -n $NAMESPACE describe deploy virt-operator

  4. Vérifier l'absence de problèmes au niveau du nœud, tels que l'état de NotReady: 

    $ oc get nodes
Atténuation

Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.25. LowVirtAPICount

Signification

Cette alerte se déclenche lorsqu'un seul pod virt-api disponible est détecté au cours d'une période de 60 minutes, alors qu'au moins deux nœuds sont disponibles pour la planification.

Impact

Une interruption des appels API peut se produire lors de l'éviction d'un nœud, car le pod virt-api devient un point de défaillance unique.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Vérifier le nombre d'unités disponibles sur le site virt-api: 

    $ oc get deployment -n $NAMESPACE virt-api \
  -o jsonpath='{.status.readyReplicas}'

  3. Vérifiez l'état du déploiement de virt-api pour voir s'il n'y a pas de conditions d'erreur : 

    $ oc -n $NAMESPACE get deploy virt-api -o yaml

  4. Vérifiez que les nœuds ne présentent pas de problèmes, par exemple s'ils sont dans l'état NotReady: 

    $ oc get nodes
Atténuation

Essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.26. LowVirtControllersCount

Signification

Cette alerte se déclenche lorsqu'un faible nombre de pods virt-controller est détecté. Au moins un pod virt-controller doit être disponible pour assurer une haute disponibilité. Le nombre de répliques par défaut est de 2.

Un dispositif virt-controller surveille les définitions de ressources personnalisées (CRD) d'une instance de machine virtuelle (VMI) et gère les pods associés. Le dispositif crée des pods pour les VMI et gère le cycle de vie des pods. Ce dispositif est essentiel pour la fonctionnalité de virtualisation à l'échelle du cluster.

Impact

La réactivité d'OpenShift Virtualization pourrait être affectée négativement. Par exemple, certaines demandes pourraient être manquées.

En outre, si une autre instance virt-launcher se termine de manière inattendue, OpenShift Virtualization peut ne plus répondre du tout.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Vérifiez que les pods virt-controller en cours d'exécution sont disponibles : 

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-controller

  3. Vérifiez les messages d'erreur dans les journaux de virt-launcher: 

    oc -n $NAMESPACE logs <virt-launcher>

  4. Obtenez les détails du pod virt-launcher pour vérifier les conditions d'état telles qu'une terminaison inattendue ou un état NotReady. 

    oc -n $NAMESPACE describe pod/<virt-launcher>
Atténuation

Cette alerte peut avoir diverses causes, notamment

  • Mémoire insuffisante sur le cluster
  • Les nœuds sont hors service
  • Le serveur API est surchargé. Par exemple, le planificateur peut être très sollicité et n'est donc pas entièrement disponible.
  • Questions relatives à la mise en réseau

Identifiez la cause première et corrigez-la, si possible.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.27. LowVirtOperatorCount

Signification

Cette alerte se déclenche lorsqu'un seul pod virt-operator dans l'état Ready a fonctionné au cours des 60 dernières minutes.

Le site virt-operator est le premier opérateur à démarrer dans une grappe. Ses principales responsabilités sont les suivantes

  • Installation, mise à jour en direct et mise à niveau en direct d'un cluster
  • Surveiller le cycle de vie des contrôleurs de premier niveau, tels que virt-controller, virt-handler, virt-launcher, et gérer leur rapprochement
  • Certaines tâches à l'échelle de la grappe, telles que la rotation des certificats et la gestion de l'infrastructure
Impact

Le site virt-operator ne peut pas assurer la haute disponibilité (HA) du déploiement. HA nécessite au moins deux pods virt-operator dans un état Ready. Le déploiement par défaut est de deux modules.

Le site virt-operator n'est pas directement responsable des machines virtuelles (VM) dans le cluster. Par conséquent, sa baisse de disponibilité n'affecte pas de manière significative les charges de travail des machines virtuelles.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Vérifier l'état des cosses virt-operator: 

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator

  3. Examinez les journaux des pods virt-operator concernés : 

    oc -n $NAMESPACE logs <virt-operator>

  4. Obtenir les détails des pods virt-operator concernés : 

    oc -n $NAMESPACE describe pod <virt-operator>
Atténuation

Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les artefacts recueillis au cours de la procédure de diagnostic.

14.14.28. NetworkAddonsConfigNotReady

Signification

Cette alerte se déclenche lorsque la ressource personnalisée (CR) NetworkAddonsConfig de l'opérateur de modules complémentaires du réseau de grappes (CNAO) n'est pas prête.

CNAO déploie des composants réseau supplémentaires sur le cluster. Cette alerte indique qu'un des composants déployés n'est pas prêt.

Impact

La fonctionnalité du réseau est affectée.

Diagnostic

  1. Vérifiez les conditions d'état de la CR NetworkAddonsConfig pour identifier le déploiement ou l'ensemble de démons qui n'est pas prêt : 

    $ oc get networkaddonsconfig \
  -o custom-columns="":.status.conditions[*].message

    Exemple de sortie

    DaemonSet "cluster-network-addons/macvtap-cni" update is being processed...

  2. Vérifiez que le pod du composant ne contient pas d'erreurs : 

    oc -n cluster-network-addons get daemonset <pod> -o yaml

  3. Vérifiez les journaux du composant : 

    $ oc -n cluster-network-addons logs <pod>

  4. Vérifier les détails du composant pour les conditions d'erreur : 

    $ oc -n cluster-network-addons describe <pod>
Atténuation

Essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.29. NoLeadingVirtOperator

Signification

Cette alerte se déclenche lorsqu'aucun pod virt-operator avec un bail de leader n'a été détecté pendant 10 minutes, bien que les pods virt-operator soient dans un état Ready. L'alerte indique qu'aucun pod leader n'est disponible.

Le site virt-operator est le premier opérateur à démarrer dans une grappe. Ses principales responsabilités sont les suivantes

  • Installation, mise à jour en direct et mise à niveau en direct d'un cluster
  • Surveiller le cycle de vie des contrôleurs de premier niveau, tels que virt-controller, virt-handler, virt-launcher, et gérer leur rapprochement
  • Certaines tâches à l'échelle de la grappe, telles que la rotation des certificats et la gestion de l'infrastructure

Le déploiement virt-operator a une réplique par défaut de 2 pods, avec un pod détenant un bail de leader.

Impact

Cette alerte indique une défaillance au niveau de la grappe. En conséquence, les fonctionnalités critiques de gestion de la grappe, telles que la rotation des certifications, la mise à niveau et le rapprochement des contrôleurs, risquent de ne pas être disponibles.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A -o \
  custom-columns="":.metadata.namespace)"

  2. Obtenir l'état des pods virt-operator: 

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator

  3. Consultez les journaux du pod virt-operator pour déterminer l'état du leader : 

    $ oc -n $NAMESPACE logs | grep lead

    Exemple d'un pod leader : 

    {"component":"virt-operator","level":"info","msg":"Attempting to acquire
leader status","pos":"application.go:400","timestamp":"2021-11-30T12:15:18.635387Z"}
I1130 12:15:18.635452       1 leaderelection.go:243] attempting to acquire
leader lease <namespace>/virt-operator...
I1130 12:15:19.216582       1 leaderelection.go:253] successfully acquired
lease <namespace>/virt-operator
{"component":"virt-operator","level":"info","msg":"Started leading",
"pos":"application.go:385","timestamp":"2021-11-30T12:15:19.216836Z"}

    Exemple de pod non leader : 

    {"component":"virt-operator","level":"info","msg":"Attempting to acquire
leader status","pos":"application.go:400","timestamp":"2021-11-30T12:15:20.533696Z"}
I1130 12:15:20.533792       1 leaderelection.go:243] attempting to acquire
leader lease <namespace>/virt-operator...

  4. Obtenir les détails des pods virt-operator concernés : 

    oc -n $NAMESPACE describe pod <virt-operator>
Atténuation

Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez de trouver la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.30. NoReadyVirtController

Signification

Cette alerte se déclenche lorsqu'aucun dispositif virt-controller n'a été détecté pendant 5 minutes.

Les dispositifs virt-controller contrôlent les définitions de ressources personnalisées des instances de machines virtuelles (VMI) et gèrent les pods associés. Les dispositifs créent des pods pour les VMI et gèrent le cycle de vie des pods.

Par conséquent, les dispositifs virt-controller sont essentiels pour toutes les fonctionnalités de virtualisation à l'échelle de la grappe.

Impact

Toutes les actions liées à la gestion du cycle de vie des machines virtuelles échouent. Il s'agit notamment du lancement d'une nouvelle VMI ou de l'arrêt d'une VMI existante.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Vérifiez le nombre d'appareils virt-controller: 

    $ oc get deployment -n $NAMESPACE virt-controller \
  -o jsonpath='{.status.readyReplicas}'

  3. Vérifiez l'état du déploiement de virt-controller: 

    $ oc -n $NAMESPACE get deploy virt-controller -o yaml

  4. Obtenez les détails du déploiement de virt-controller pour vérifier les conditions d'état telles que les pods en panne ou l'impossibilité d'extraire des images : 

    $ oc -n $NAMESPACE describe deploy virt-controller

  5. Obtenir les informations sur les nacelles du site virt-controller: 

    $ get pods -n $NAMESPACE | grep virt-controller

  6. Vérifiez les journaux des pods virt-controller pour les messages d'erreur : 

    oc logs -n $NAMESPACE <virt-controller>

  7. Vérifiez que les nœuds ne présentent pas de problèmes, tels que l'état NotReady: 

    $ oc get nodes
Atténuation

Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez de trouver la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.31. NoReadyVirtOperator

Signification

Cette alerte se déclenche lorsqu'aucun pod virt-operator en état Ready n'a été détecté pendant 10 minutes.

Le site virt-operator est le premier opérateur à démarrer dans une grappe. Ses principales responsabilités sont les suivantes

  • Installation, mise à jour en direct et mise à niveau en direct d'un cluster
  • Surveiller le cycle de vie des contrôleurs de premier niveau, tels que virt-controller, virt-handler, virt-launcher, et gérer leur rapprochement
  • Certaines tâches à l'échelle de la grappe, telles que la rotation des certificats et la gestion de l'infrastructure

Le déploiement par défaut est constitué de deux pods virt-operator.

Impact

Cette alerte indique une défaillance au niveau du cluster. Les fonctionnalités essentielles de gestion des clusters, telles que la rotation des certifications, la mise à niveau et le rapprochement des contrôleurs, risquent de ne pas être disponibles.

Le site virt-operator n'est pas directement responsable des machines virtuelles dans le cluster. Par conséquent, son indisponibilité temporaire n'affecte pas de manière significative les charges de travail.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Obtenir le nom du déploiement virt-operator: 

    $ oc -n $NAMESPACE get deploy virt-operator -o yaml

  3. Générer la description du déploiement de virt-operator: 

    $ oc -n $NAMESPACE describe deploy virt-operator

  4. Vérifier l'absence de problèmes au niveau du nœud, tels que l'état de NotReady: 

    $ oc get nodes
Atténuation

Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les artefacts recueillis au cours de la procédure de diagnostic.

14.14.32. OrphanedVirtualMachineInstances (substances de machines virtuelles orphelines)

Signification

Cette alerte se déclenche lorsqu'une instance de machine virtuelle (VMI), ou un pod virt-launcher, s'exécute sur un nœud qui n'a pas de pod virt-handler en cours d'exécution. Une telle VMI est appelée orphaned.

Impact

Les IMV orphelines ne peuvent pas être gérées.

Diagnostic

  1. Vérifiez l'état des pods virt-handler pour connaître les nœuds sur lesquels ils s'exécutent : 

    $ oc get pods --all-namespaces -o wide -l kubevirt.io=virt-handler

  2. Vérifiez l'état des IMV pour identifier les IMV en cours d'exécution sur des nœuds qui n'ont pas de pod virt-handler en cours d'exécution : 

    $ oc get vmis --all-namespaces

  3. Vérifiez l'état du démon virt-handler: 

    $ oc get daemonset virt-handler --all-namespaces

    Exemple de sortie

    NAME          DESIRED  CURRENT  READY  UP-TO-DATE  AVAILABLE ...
virt-handler  2        2        2      2           2         ...

    Le jeu de démons est considéré comme sain si les colonnes Desired, Ready, et Available contiennent la même valeur.

  4. Si le jeu de démons virt-handler n'est pas sain, vérifiez si le jeu de démons virt-handler ne présente pas de problèmes de déploiement de pods : 

    $ oc get daemonset virt-handler --all-namespaces -o yaml | jq .status

  5. Vérifiez que les nœuds ne présentent pas de problèmes tels que l'état NotReady: 

    $ oc get nodes

  6. Vérifiez la strophe spec.workloads de la ressource personnalisée (CR) KubeVirt pour une politique de placement des charges de travail : 

    $ oc get kubevirt kubevirt --all-namespaces -o yaml
Atténuation

Si une stratégie de placement des charges de travail est configurée, ajoutez le nœud avec la VMI à la stratégie.

Les causes possibles de la suppression d'un pod virt-handler d'un nœud sont notamment les modifications apportées aux taches et tolérances du nœud ou aux règles de programmation d'un pod.

Essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.33. Charges de travail d'instances de machines virtuelles périmées

Signification

Cette alerte se déclenche lorsque des instances de machines virtuelles (VMI) en cours d'exécution dans des pods virt-launcher obsolètes sont détectées 24 heures après la mise à jour du plan de contrôle d'OpenShift Virtualization.

Impact

Les IMV obsolètes peuvent ne pas avoir accès aux nouvelles fonctionnalités d'OpenShift Virtualization.

Les IMV obsolètes ne recevront pas les correctifs de sécurité associés à la mise à jour du pod virt-launcher.

Diagnostic

  1. Identifier les IMV périmés : 

    $ oc get vmi -l kubevirt.io/outdatedLauncherImage --all-namespaces

  2. Vérifiez la ressource personnalisée (CR) KubeVirt pour déterminer si workloadUpdateMethods est configuré dans la strophe workloadUpdateStrategy: 

    $ oc get kubevirt kubevirt --all-namespaces -o yaml

  3. Vérifier chaque IMV obsolète pour déterminer s'il est possible de le migrer en direct : 

    $ oc get vmi <vmi> -o yaml

    Exemple de sortie

    apiVersion: kubevirt.io/v1
kind: VirtualMachineInstance
...
  status:
    conditions:
    - lastProbeTime: null
      lastTransitionTime: null
      message: cannot migrate VMI which does not use masquerade
      to connect to the pod network
      reason: InterfaceNotLiveMigratable
      status: "False"
      type: LiveMigratable

Atténuation
Configuration des mises à jour automatisées de la charge de travail

Mettre à jour le CR HyperConverged pour activer les mises à jour automatiques de la charge de travail.

Arrêt d'une VM associée à une VMI non migrable en direct

  • Si une IMV n'est pas migrable en direct et si runStrategy: always est défini dans l'objet VirtualMachine correspondant, vous pouvez mettre à jour l'IMV en arrêtant manuellement la machine virtuelle (VM) : 

    virctl stop --namespace <namespace> <vm>

Un nouveau VMI démarre immédiatement dans un pod virt-launcher mis à jour pour remplacer le VMI arrêté. C'est l'équivalent d'une action de redémarrage.

Note

L'arrêt manuel d'une VM live-migratable est destructeur et déconseillé car il interrompt la charge de travail.

Migration d'une VMI migrable en direct

Si une IMV est migrable en direct, vous pouvez la mettre à jour en créant un objet VirtualMachineInstanceMigration qui cible une IMV spécifique en cours d'exécution. L'IMV est migrée dans un pod virt-launcher mis à jour.

  1. Créez un manifeste VirtualMachineInstanceMigration et enregistrez-le sous migration.yaml: 

    apiVersion: kubevirt.io/v1
kind: VirtualMachineInstanceMigration
metadata:
  name: <migration_name>
  namespace: <namespace>
spec:
  vmiName: <vmi_name>

  2. Créer un objet VirtualMachineInstanceMigration pour déclencher la migration : 

    $ oc create -f migration.yaml

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.34. SSPCommonTemplatesModificationReverted

Signification

Cette alerte se déclenche lorsque l'opérateur SSP (Scheduling, Scale, and Performance) annule les modifications apportées aux modèles communs dans le cadre de sa procédure de réconciliation.

L'opérateur SSP déploie et réconcilie les modèles communs et le validateur de modèle. Si un utilisateur ou un script modifie un modèle commun, les modifications sont annulées par l'opérateur SSP.

Impact

Les modifications apportées aux modèles communs sont écrasées.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \
  awk '{print $1}')"

  2. Vérifiez les journaux de ssp-operator pour les modèles dont les modifications ont été annulées : 

    $ oc -n $NAMESPACE logs --tail=-1 -l control-plane=ssp-operator | \
  grep 'common template' -C 3
Atténuation

Essayez d'identifier et de résoudre la cause des changements.

Veillez à ce que les modifications ne soient apportées qu'aux copies des modèles, et non aux modèles eux-mêmes.

14.14.35. SSPFailingToReconcile (défaut de réconciliation)

Signification

Cette alerte se déclenche lorsque le cycle de rapprochement de l'opérateur SSP (Scheduling, Scale and Performance) échoue à plusieurs reprises, bien que l'opérateur SSP soit en cours d'exécution.

L'opérateur SSP est responsable du déploiement et du rapprochement des modèles communs et du validateur de modèles.

Impact

Les composants dépendants peuvent ne pas être déployés. Les modifications apportées aux composants peuvent ne pas être rapprochées. Par conséquent, les modèles communs ou le validateur de modèles peuvent ne pas être mis à jour ou réinitialisés en cas d'échec.

Diagnostic

  1. Exporter la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \
  awk '{print $1}')"

  2. Obtenir les informations sur les nacelles du site ssp-operator: 

    $ oc -n $NAMESPACE describe pods -l control-plane=ssp-operator

  3. Vérifiez si des erreurs se sont produites sur le site ssp-operator: 

    $ oc -n $NAMESPACE logs --tail=-1 -l control-plane=ssp-operator

  4. Obtenir l'état des pods virt-template-validator: 

    $ oc -n $NAMESPACE get pods -l name=virt-template-validator

  5. Obtenir les informations sur les nacelles du site virt-template-validator: 

    $ oc -n $NAMESPACE describe pods -l name=virt-template-validator

  6. Vérifiez si des erreurs se sont produites sur le site virt-template-validator: 

    $ oc -n $NAMESPACE logs --tail=-1 -l name=virt-template-validator
Atténuation

Essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.36. SSPHighRateRejectedVms

Signification

Cette alerte se déclenche lorsqu'un utilisateur ou un script tente de créer ou de modifier un grand nombre de machines virtuelles (VM) à l'aide d'une configuration non valide.

Impact

Les machines virtuelles ne sont ni créées ni modifiées. Par conséquent, l'environnement peut ne pas se comporter comme prévu.

Diagnostic

  1. Exporter la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \
  awk '{print $1}')"

  2. Vérifiez les journaux de virt-template-validator pour les erreurs qui pourraient indiquer la cause : 

    $ oc -n $NAMESPACE logs --tail=-1 -l name=virt-template-validator

    Exemple de sortie

    {"component":"kubevirt-template-validator","level":"info","msg":"evalution
summary for ubuntu-3166wmdbbfkroku0:\nminimal-required-memory applied: FAIL,
value 1073741824 is lower than minimum [2147483648]\n\nsucceeded=false",
"pos":"admission.go:25","timestamp":"2021-09-28T17:59:10.934470Z"}

Atténuation

Essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.37. SSPOperatorDown

Signification

Cette alerte se déclenche lorsque tous les pods de l'opérateur SSP (Scheduling, Scale and Performance) sont hors service.

L'opérateur SSP est responsable du déploiement et du rapprochement des modèles communs et du validateur de modèles.

Impact

Les composants dépendants peuvent ne pas être déployés. Les modifications apportées aux composants peuvent ne pas être rapprochées. Par conséquent, les modèles communs et/ou le validateur de modèles peuvent ne pas être mis à jour ou réinitialisés en cas d'échec.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \
  awk '{print $1}')"

  2. Vérifier l'état des pods ssp-operator. 

    $ oc -n $NAMESPACE get pods -l control-plane=ssp-operator

  3. Obtenir les informations sur les nacelles du site ssp-operator: 

    $ oc -n $NAMESPACE describe pods -l control-plane=ssp-operator

  4. Vérifiez les messages d'erreur dans les journaux de ssp-operator: 

    $ oc -n $NAMESPACE logs --tail=-1 -l control-plane=ssp-operator
Atténuation

Essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.38. SSPTemplateValidatorDown

Signification

Cette alerte se déclenche lorsque tous les modules du validateur de modèle sont hors service.

Le validateur de modèles vérifie les machines virtuelles (VM) pour s'assurer qu'elles ne violent pas leurs modèles.

Impact

Les machines virtuelles ne sont pas validées par rapport à leurs modèles. Par conséquent, les machines virtuelles peuvent être créées avec des spécifications qui ne correspondent pas à leurs charges de travail respectives.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get deployment -A | grep ssp-operator | \
  awk '{print $1}')"

  2. Obtenir l'état des pods virt-template-validator: 

    $ oc -n $NAMESPACE get pods -l name=virt-template-validator

  3. Obtenir les informations sur les nacelles du site virt-template-validator: 

    $ oc -n $NAMESPACE describe pods -l name=virt-template-validator

  4. Vérifiez les messages d'erreur dans les journaux de virt-template-validator: 

    $ oc -n $NAMESPACE logs --tail=-1 -l name=virt-template-validator
Atténuation

Essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.39. VirtAPIDown

Signification

Cette alerte se déclenche lorsque tous les pods du serveur API sont hors service.

Impact

Les objets OpenShift Virtualization ne peuvent pas envoyer d'appels API.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Vérifier l'état des pods virt-api: 

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-api

  3. Vérifiez l'état du déploiement de virt-api: 

    $ oc -n $NAMESPACE get deploy virt-api -o yaml

  4. Vérifiez les détails du déploiement de virt-api pour des problèmes tels que des pods en panne ou des échecs d'extraction d'image : 

    $ oc -n $NAMESPACE describe deploy virt-api

  5. Vérifiez si des nœuds se trouvent dans l'état NotReady: 

    $ oc get nodes
Atténuation

Essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.40. VirtApiRESTErrorsBurst

Signification

Plus de 80 % des appels REST ont échoué dans les pods virt-api au cours des 5 dernières minutes.

Impact

Un taux très élevé d'échecs des appels REST à virt-api peut entraîner une lenteur de réponse et d'exécution des appels d'API, voire un rejet total des appels d'API.

Toutefois, les charges de travail des machines virtuelles en cours d'exécution ne devraient pas être affectées.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Obtenez la liste des pods virt-api sur votre déploiement : 

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-api

  3. Vérifiez les messages d'erreur dans les journaux de virt-api: 

    oc logs -n $NAMESPACE <virt-api>

  4. Obtenir les informations sur les nacelles du site virt-api: 

    oc describe -n $NAMESPACE <virt-api>

  5. Vérifiez si des problèmes sont survenus avec les nœuds. Par exemple, ils peuvent être dans l'état NotReady: 

    $ oc get nodes

  6. Vérifiez l'état du déploiement de virt-api: 

    $ oc -n $NAMESPACE get deploy virt-api -o yaml

  7. Obtenir les détails du déploiement de virt-api: 

    $ oc -n $NAMESPACE describe deploy virt-api
Atténuation

Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.41. VirtApiRESTErrorsHigh

Signification

Plus de 5 % des appels REST ont échoué dans les pods virt-api au cours des 60 dernières minutes.

Impact

Un taux élevé d'échecs des appels REST à virt-api peut entraîner un ralentissement de la réponse et de l'exécution des appels API.

Toutefois, les charges de travail des machines virtuelles en cours d'exécution ne devraient pas être affectées.

Diagnostic

  1. Définissez la variable d'environnement NAMESPACE comme suit : 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Vérifier l'état des pods virt-api: 

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-api

  3. Consultez les journaux de virt-api: 

    $ oc logs -n  $NAMESPACE <virt-api>

  4. Obtenir les informations sur les nacelles du site virt-api: 

    oc describe -n $NAMESPACE <virt-api>

  5. Vérifiez si des problèmes sont survenus avec les nœuds. Par exemple, ils peuvent être dans l'état NotReady: 

    $ oc get nodes

  6. Vérifiez l'état du déploiement de virt-api: 

    $ oc -n $NAMESPACE get deploy virt-api -o yaml

  7. Obtenir les détails du déploiement de virt-api: 

    $ oc -n $NAMESPACE describe deploy virt-api
Atténuation

Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez d'identifier la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.42. VirtControllerDown

Signification

Aucun pod virt-controller en cours de fonctionnement n'a été détecté pendant 5 minutes.

Impact

Toutes les actions liées à la gestion du cycle de vie des machines virtuelles (VM) échouent. Il s'agit notamment du lancement d'une nouvelle instance de machine virtuelle (VMI) ou de l'arrêt d'une VMI existante.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Vérifiez l'état du déploiement de virt-controller: 

    $ oc get deployment -n $NAMESPACE virt-controller -o yaml

  3. Examinez les journaux du pod virt-controller: 

    $ oc get logs <virt-controller>
Atténuation

Cette alerte peut avoir diverses causes, dont les suivantes :

  • Épuisement des ressources du nœud
  • Mémoire insuffisante sur le cluster
  • Les nœuds sont hors service
  • Le serveur API est surchargé. Par exemple, le planificateur peut être très sollicité et n'est donc pas entièrement disponible.
  • Questions relatives à la mise en réseau

Identifiez la cause première et corrigez-la, si possible.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.43. VirtControllerRESTErrorsBurst

Signification

Plus de 80 % des appels REST dans les pods virt-controller ont échoué au cours des 5 dernières minutes.

Le site virt-controller a probablement perdu complètement la connexion avec le serveur API.

Cette erreur est souvent due à l'un des problèmes suivants :

  • Le serveur API est surchargé, ce qui entraîne des dépassements de délai. Pour vérifier si c'est le cas, vérifiez les métriques du serveur API et affichez ses temps de réponse et le nombre total d'appels.
  • Le pod virt-controller ne peut pas atteindre le serveur API. Cela est généralement dû à des problèmes de DNS sur le nœud et à des problèmes de connectivité réseau.
Impact

Les mises à jour d'état ne sont pas propagées et les actions telles que les migrations ne peuvent pas avoir lieu. Cependant, les charges de travail en cours d'exécution ne sont pas affectées.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Liste des pods virt-controller disponibles : 

    $ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-controller

  3. Vérifiez dans les journaux de virt-controller les messages d'erreur lors de la connexion au serveur API : 

    $ oc logs -n  $NAMESPACE <virt-controller>
Atténuation

  • Si le module virt-controller ne peut pas se connecter au serveur API, supprimez le module pour forcer un redémarrage : 

    oc delete -n $NAMESPACE <virt-controller>

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.44. VirtControllerRESTErrorsHigh

Signification

Plus de 5 % des appels REST ont échoué sur virt-controller au cours des 60 dernières minutes.

Cela est probablement dû au fait que virt-controller a partiellement perdu la connexion avec le serveur API.

Cette erreur est souvent due à l'un des problèmes suivants :

  • Le serveur API est surchargé, ce qui entraîne des dépassements de délai. Pour vérifier si c'est le cas, vérifiez les métriques du serveur API et affichez ses temps de réponse et le nombre total d'appels.
  • Le pod virt-controller ne peut pas atteindre le serveur API. Cela est généralement dû à des problèmes de DNS sur le nœud et à des problèmes de connectivité réseau.
Impact

Les actions liées aux nœuds, telles que le démarrage, la migration et la planification des machines virtuelles, sont retardées. Les charges de travail en cours d'exécution ne sont pas affectées, mais la communication de leur état actuel peut être retardée.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Liste des pods virt-controller disponibles : 

    $ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-controller

  3. Vérifiez dans les journaux de virt-controller les messages d'erreur lors de la connexion au serveur API : 

    $ oc logs -n  $NAMESPACE <virt-controller>
Atténuation

  • Si le module virt-controller ne peut pas se connecter au serveur API, supprimez le module pour forcer un redémarrage : 

    oc delete -n $NAMESPACE <virt-controller>

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.45. VirtHandlerDaemonSetRolloutFailing

Signification

Le jeu de démons virt-handler n'a pas réussi à se déployer sur un ou plusieurs nœuds de travail après 15 minutes.

Impact

Cette alerte est un avertissement. Elle n'indique pas que tous les ensembles de démons virt-handler n'ont pas été déployés. Par conséquent, le cycle de vie normal des machines virtuelles n'est pas affecté, sauf si le cluster est surchargé.

Diagnostic

Identifiez les nœuds de travail qui n'ont pas de pod virt-handler en cours d'exécution :

  1. Exporter la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Vérifiez l'état des pods virt-handler pour identifier les pods qui n'ont pas été déployés : 

    $ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-handler

  3. Obtenir le nom du nœud de travail du pod virt-handler: 

    oc -n $NAMESPACE get pod <virt-handler> -o jsonpath='{.spec.nodeName}'
Atténuation

Si les pods virt-handler n'ont pas pu être déployés en raison de ressources insuffisantes, vous pouvez supprimer d'autres pods sur le nœud de travail affecté.

14.14.46. VirtHandlerRESTErrorsBurst

Signification

Plus de 80 % des appels REST ont échoué sur virt-handler au cours des 5 dernières minutes. Cette alerte indique généralement que les pods virt-handler ne peuvent pas se connecter au serveur API.

Cette erreur est souvent due à l'un des problèmes suivants :

  • Le serveur API est surchargé, ce qui entraîne des dépassements de délai. Pour vérifier si c'est le cas, vérifiez les métriques du serveur API et affichez ses temps de réponse et le nombre total d'appels.
  • Le pod virt-handler ne peut pas atteindre le serveur API. Cela est généralement dû à des problèmes de DNS sur le nœud et à des problèmes de connectivité réseau.
Impact

Les mises à jour d'état ne sont pas propagées et les actions liées au nœud, telles que les migrations, échouent. Cependant, les charges de travail en cours d'exécution sur le nœud affecté ne sont pas affectées.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Vérifier l'état du pod virt-handler: 

    $ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-handler

  3. Vérifiez dans les journaux de virt-handler les messages d'erreur lors de la connexion au serveur API : 

    $ oc logs -n  $NAMESPACE <virt-handler>
Atténuation

  • Si le site virt-handler ne peut pas se connecter au serveur API, supprimez le module pour forcer un redémarrage : 

    oc delete -n $NAMESPACE <virt-handler>

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.47. VirtHandlerRESTErrorsHigh

Signification

Plus de 5 % des appels REST ont échoué sur virt-handler au cours des 60 dernières minutes. Cette alerte indique généralement que les pods virt-handler ont partiellement perdu la connexion au serveur API.

Cette erreur est souvent due à l'un des problèmes suivants :

  • Le serveur API est surchargé, ce qui entraîne des dépassements de délai. Pour vérifier si c'est le cas, vérifiez les métriques du serveur API et affichez ses temps de réponse et le nombre total d'appels.
  • Le pod virt-handler ne peut pas atteindre le serveur API. Cela est généralement dû à des problèmes de DNS sur le nœud et à des problèmes de connectivité réseau.
Impact

Les actions liées aux nœuds, telles que le démarrage et la migration des charges de travail, sont retardées sur le nœud sur lequel virt-handler est exécuté. Les charges de travail en cours d'exécution ne sont pas affectées, mais la communication de leur état actuel peut être retardée.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Vérifier l'état du pod virt-handler: 

    $ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-handler

  3. Vérifiez dans les journaux de virt-handler les messages d'erreur lors de la connexion au serveur API : 

    $ oc logs -n $NAMESPACE <virt-handler>
oc logs -n $NAMESPACE <virt-handler>
Atténuation

  • Si le site virt-handler ne peut pas se connecter au serveur API, supprimez le module pour forcer un redémarrage : 

    oc delete -n $NAMESPACE <virt-handler>

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.48. VirtOperatorDown

Signification

Cette alerte se déclenche lorsqu'aucun pod virt-operator dans l'état Running n'a été détecté pendant 10 minutes.

Le site virt-operator est le premier opérateur à démarrer dans une grappe. Ses principales responsabilités sont les suivantes

  • Installation, mise à jour en direct et mise à niveau en direct d'un cluster
  • Surveiller le cycle de vie des contrôleurs de premier niveau, tels que virt-controller, virt-handler, virt-launcher, et gérer leur rapprochement
  • Certaines tâches à l'échelle de la grappe, telles que la rotation des certificats et la gestion de l'infrastructure

Le déploiement virt-operator a une réplique par défaut de 2 pods.

Impact

Cette alerte indique une défaillance au niveau de la grappe. Les fonctionnalités critiques de gestion à l'échelle de la grappe, telles que la rotation des certifications, la mise à niveau et le rapprochement des contrôleurs, peuvent ne pas être disponibles.

Le site virt-operator n'est pas directement responsable des machines virtuelles (VM) dans le cluster. Par conséquent, son indisponibilité temporaire n'affecte pas de manière significative les charges de travail des machines virtuelles.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Vérifiez l'état du déploiement de virt-operator: 

    $ oc -n $NAMESPACE get deploy virt-operator -o yaml

  3. Obtenir les détails du déploiement de virt-operator: 

    $ oc -n $NAMESPACE describe deploy virt-operator

  4. Vérifier l'état des pods virt-operator: 

    $ oc get pods -n $NAMESPACE -l=kubevirt.io=virt-operator

  5. Vérifier l'absence de problèmes au niveau du nœud, tels que l'état de NotReady: 

    $ oc get nodes
Atténuation

Sur la base des informations obtenues au cours de la procédure de diagnostic, essayez de trouver la cause première et de résoudre le problème.

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.49. VirtOperatorRESTErrorsBurst

Signification

Cette alerte se déclenche lorsque plus de 80 % des appels REST dans les modules virt-operator ont échoué au cours des 5 dernières minutes. Cela indique généralement que les modules virt-operator ne peuvent pas se connecter au serveur API.

Cette erreur est souvent due à l'un des problèmes suivants :

  • Le serveur API est surchargé, ce qui entraîne des dépassements de délai. Pour vérifier si c'est le cas, vérifiez les métriques du serveur API et affichez ses temps de réponse et le nombre total d'appels.
  • Le pod virt-operator ne peut pas atteindre le serveur API. Cela est généralement dû à des problèmes de DNS sur le nœud et à des problèmes de connectivité réseau.
Impact

Les actions au niveau du cluster, telles que la mise à niveau et le rapprochement des contrôleurs, peuvent ne pas être disponibles.

Toutefois, les charges de travail telles que les machines virtuelles (VM) et les instances VM (VMI) ne devraient pas être affectées.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Vérifier l'état des pods virt-operator: 

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator

  3. Vérifiez dans les journaux de virt-operator les messages d'erreur lors de la connexion au serveur API : 

    oc -n $NAMESPACE logs <virt-operator>

  4. Obtenir les coordonnées de la nacelle virt-operator: 

    oc -n $NAMESPACE describe pod <virt-operator>
Atténuation

  • Si le module virt-operator ne peut pas se connecter au serveur API, supprimez le module pour forcer un redémarrage : 

    oc delete -n $NAMESPACE <virt-operator>

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.50. VirtOperatorRESTErrorsHigh

Signification

Cette alerte se déclenche lorsque plus de 5 % des appels REST dans les pods virt-operator ont échoué au cours des 60 dernières minutes. Cela indique généralement que les modules virt-operator ne peuvent pas se connecter au serveur API.

Cette erreur est souvent due à l'un des problèmes suivants :

  • Le serveur API est surchargé, ce qui entraîne des dépassements de délai. Pour vérifier si c'est le cas, vérifiez les métriques du serveur API et affichez ses temps de réponse et le nombre total d'appels.
  • Le pod virt-operator ne peut pas atteindre le serveur API. Cela est généralement dû à des problèmes de DNS sur le nœud et à des problèmes de connectivité réseau.
Impact

Les actions au niveau du cluster, telles que la mise à niveau et le rapprochement des contrôleurs, peuvent être retardées.

Toutefois, les charges de travail telles que les machines virtuelles (VM) et les instances VM (VMI) ne devraient pas être affectées.

Diagnostic

  1. Définir la variable d'environnement NAMESPACE: 

    $ export NAMESPACE="$(oc get kubevirt -A \
  -o custom-columns="":.metadata.namespace)"

  2. Vérifier l'état des pods virt-operator: 

    $ oc -n $NAMESPACE get pods -l kubevirt.io=virt-operator

  3. Vérifiez dans les journaux de virt-operator les messages d'erreur lors de la connexion au serveur API : 

    oc -n $NAMESPACE logs <virt-operator>

  4. Obtenir les coordonnées de la nacelle virt-operator: 

    oc -n $NAMESPACE describe pod <virt-operator>
Atténuation

  • Si le module virt-operator ne peut pas se connecter au serveur API, supprimez le module pour forcer un redémarrage : 

    oc delete -n $NAMESPACE <virt-operator>

Si vous ne parvenez pas à résoudre le problème, connectez-vous au portail client et ouvrez un dossier d'assistance, en joignant les éléments recueillis au cours de la procédure de diagnostic.

14.14.51. VMCannotBeEvicted

Signification

Cette alerte se déclenche lorsque la stratégie d'éviction d'une machine virtuelle (VM) est définie sur LiveMigration mais que la VM n'est pas migrable.

Impact

Les machines virtuelles non migrables empêchent l'éviction des nœuds. Cette condition affecte les opérations telles que la vidange et la mise à jour des nœuds.

Diagnostic

  1. Vérifier la configuration VMI pour déterminer si la valeur de evictionStrategy est LiveMigrate: 

    $ oc get vmis -o yaml

  2. Vérifiez l'état False dans la colonne LIVE-MIGRATABLE pour identifier les IMV qui ne sont pas migrables : 

    $ oc get vmis -o wide

  3. Obtenez les détails de l'IMV et consultez le site spec.conditions pour identifier le problème : 

    $ oc get vmi <vmi> -o yaml

    Exemple de sortie

    status:
  conditions:
  - lastProbeTime: null
    lastTransitionTime: null
    message: cannot migrate VMI which does not use masquerade to connect
    to the pod network
    reason: InterfaceNotLiveMigratable
    status: "False"
    type: LiveMigratable

Atténuation

Réglez le site evictionStrategy de la VMI sur shutdown ou résolvez le problème qui empêche la VMI de migrer.

Red Hat logoGithubRedditYoutubeTwitter

Apprendre

Essayez, achetez et vendez

Communautés

À propos de la documentation Red Hat

Nous aidons les utilisateurs de Red Hat à innover et à atteindre leurs objectifs grâce à nos produits et services avec un contenu auquel ils peuvent faire confiance.

Rendre l’open source plus inclusif

Red Hat s'engage à remplacer le langage problématique dans notre code, notre documentation et nos propriétés Web. Pour plus de détails, consultez leBlog Red Hat.

À propos de Red Hat

Nous proposons des solutions renforcées qui facilitent le travail des entreprises sur plusieurs plates-formes et environnements, du centre de données central à la périphérie du réseau.

© 2024 Red Hat, Inc.