Problèmes d'ordre général

Cette section examine des problèmes d'ordre général concernant la fonctionnalité DR sur le serveur Enterprise 10000, veuillez la lire avant d'essayer d'installer ou de configurer DR.

DR et les processus utilisateurs liés

Dans l'environnement d'exploitation Solaris 8 2/02, DR ne sépare plus automatiquement les processus utilisateurs liés aux UC qui vont être détachées. Les utilisateurs sont à présent priés d'effectuer cette opération eux-mêmes avant de lancer une opération de détachement. L'opération de vidage échoue s'il y a des processus liés aux UC.

Problème lié à oprom_checknodeid() au cours d'une opération DR (4474330)

Une condition de panique peut survenir dans certaines circonstances, lorsque l'interface /dev/openprom accède à l'arborescence du périphérique PROM, après une déconnexion DR. Le pilote openprom met en cache les informations de nud, celles-ci pouvant ne plus être disponibles après une déconnexion DR. Par conséquent, une adresse de nud erronée peut être transmise à OpenBoot PROM.

Procédure : pour éviter cette situation, n'utilisez plus les applications, telles que prtconf, qui font appel à l'interface /dev/openprom pendant ou juste avant/après une opération de déconnexion DR. Notez que picld(1M) utilise le pilote /dev/openprom.

Echec de reprise de QFE après une opération DR Detach (4499428)

Après l'interruption du pilote qfe survenant au cours d'une mise au repos d'une opération DR de l'environnement d'exploitation Solaris, le pilote qfe peut se trouver en condition d'échec de reprise, ceci se traduisant par une perte de connectivité réseau. Si cette condition se produit, le domaine sera encore accessible par le biais de la console réseau à partir du SSP.

Procédure : réinitialisez le périphérique qfe en exécutant la séquence de commandes suivante à partir de la console réseau :

Où périphérique_qfe correspond au périphérique qfe concerné, p.ex. qfe0.

L'activation de DR 3.0 nécessite une étape en plus dans certains cas (Bug ID 4507010)

Si vous effectuez une mise à niveau ou une installation à partir de zéro de l'environnement d'exploitation Solaris sur un domaine avant de mettre à niveau le SSP vers SSP 3.5, le domaine ne sera pas correctement configuré pour DR 3.0.

Procédure : exécutez la commande suivante en tant que super-utilisateur sur le domaine, après la mise à niveau du SSP vers SSP 3.5. Cette procédure n'est pas nécessaire tant que DR 3.0 n'est pas activé sur le domai

# devfsadm -i ngdr