Ce problème affecte les deux serveurs.
Lors du basculement d'un SP qui devient le SP actif, il doit réintégrer l'ensemble de pannes actuel qui est enregistré dans la base de données de pannes. Si d'autres parties du système demandent des informations sur les pannes avant la fin de ce processus, les comportements suivants peuvent se produire :
Un nom d'erreur peut être publié en double. La même classe de rapport électronique, la même classe de panne et la même ressource sont identifiées pour les deux pannes. La seule différence réside dans l'horodatage de chaque panne.
Un fault.fruid.replay peut être publié pour une FRU qui est déjà défectueuse.
Certaines ou toutes les pannes diagnostiquées par Oracle ILOM ne sont pas affichées sur l'hôte après le basculement d'un SP, mais toutes les pannes sont indiquées si vous réinitialisez la connexion ip-transport de l'architecture de gestion des pannes.
Solution de contournement : pour éviter ce problème, vous devez résoudre toutes les conditions de panne et effectuer toutes les tâches de maintenance avant de lancer un basculement de SP.
Si une défaillance non planifiée se produit, et que ce problème est déclenché, utilisez la commande suivante à l'invite Oracle Solaris :
root@host-name:~# fmadm reset ip-transport
Récupération : utilisez la commande suivante à l'invite Oracle Solaris afin de réinitialiser la connexion ip-transport et de déclencher la répétition de la liste des pannes.
root@host-name:~# fmadm reset ip-transport