Problemi generali

Questa sezione contiene i problemi generali che crea DR sul server Sun Enterprise 10000. Prima di tentare di installare o configurare DR, leggere questa sezione.

Processi dell'utente DR e vincolati

Per l'ambiente operativo Solaris 8 2/02, DR non svincola più i processi dell'utente alle CPU che vengono staccate. Adesso gli utenti hanno bisogno di eseguire questa operazione manualmente prima di avviare una sequenza Detach. L'operazione Drain non sarà possibile, se vengono trovate CPU con processi vincolati.

Problema con oprom_checknodeid() durante DR (ID 4474330)

In alcune circostanze, quando l'interfaccia /dev/openprom accede alla struttura ad albero dei dispositivi PROM dopo un'operazione DR disconnect, può verificarsi un errore panic. Il driver openprom memorizza nella cache informazioni sui nodi che possono divenire non valide dopo un'operazione DR disconnect. Di conseguenza, può essere trasmesso a OpenBoot PROM un indirizzo di nodo errato.

Soluzione: per ridurre al minimo la possibilità di incorrere in questa situazione, non utilizzare applicazioni, quali prtconf, che usano l'interfaccia /dev/openprom durante un'operazione DR disconnect o immediatamente prima o dopo. Si noti che picld(1M) utilizza il driver /dev/openprom.

Il ripristino del driver QFE non riesce dopo un'operazione detach di DR (4499428)

Dopo avere sospeso un driver qfe durante un'operazione DR quiesce dell'ambiente operativo Solaris, il ripristino del driver qfe può non riuscire correttamente, con una conseguente perdita di connettività di rete. Se si verifica questa condizione, il dominio sarà comunque accessibile da SSP tramite la console di rete.

Soluzione: resettare il dispositivo qfe eseguendo la sequenza di comandi seguente dalla console di rete:

Dove dispositivo_qfe è il dispositivo qfe interessato, per esempio qfe0.

L'abilitazione di DR 3.0 richiede un passaggio extra in alcune situazioni (ID 4507010)

Se si esegue l'aggiornamento o una prima installazione dell'ambiente operativo Solaris su un dominio prima di effettuare l'aggiornamento di SSP a SSP 3.5, il dominio non sarà correttamente configurato per DR 3.0.

Soluzione: eseguire il comando seguente come supertutente sul dominio, dopo aver aggiornato SSP a SSP 3.5. Questa soluzione non è necessaria finché DR 3.0 è abilitato sul dominio.

# devfsadm -i ngdr