Systemverwaltungshandbuch: Oracle Solaris Container - Ressourcenverwaltung und Solaris Zones

Kapitel 30 Behebung von verschiedenen Problemen mit Solaris Zones

Dieses Kapitel wurde für das Solaris-Release 10 6/06 neu aufgenommen.

Eine vollständige Liste der neuen Funktionen in Solaris 10 sowie eine Beschreibung der Solaris-Releases finden Sie in Neuerungen in Oracle Solaris 9 10/10.

Solaris 10 6/06, Solaris 10 11/06, Solaris 10 8/07 und Solaris 10 5/08: Das Root-Dateisystem einer nicht-globalen Zone nicht auf einem ZFS ablegen

Der zonepath einer nicht-globalen Zone darf sich bei diesen Releases nicht auf einem ZFS befinden. Anderenfalls könnten sich Probleme beim Patchen einstellen und das System kann eventuell nicht mehr auf ein höheres Solaris 10-Release aktualisiert werden.

Bitte beachten Sie, dass sich das Root-Dateisystem einer nicht-globalen Zone ab Solaris-Release 10&;10/08 auf ZFS befinden darf. Das System kann dann mit Solaris Live Upgrade aktualisiert werden.

Exclusive IP-Zone verwendet Gerät, somit schlägt `dladm` `reset-linkprop` fehl

Wenn die folgende Fehlermeldung angezeigt wird:

dladm: warning: cannot reset link property 'zone' on 'bge0': operation failed

Der Versuch, dladm reset-linkprop zu verwenden, ist fehlgeschlagen. Lesen Sie hierzu auch So verwenden Sie dladm reset-linkprop Die laufende Zone excl verwendet das Gerät, das durch Ausführen von ifconfig bge0 plumb innerhalb der Zone zugewiesen wurde.

Um den Wert zurückzusetzen, führen Sie das Verfahren ifconfig bge0 unplumb innerhalb der Zone aus und geben dann den Befehl dladm erneut ein.

Vom Zonenadministrator erzwungenes Einhängen über Dateisysteme, die von der globalen Zone aus bestückt wurden

Wenn schon nach dem ersten Booten einer nicht-globalen Zone Dateien in der Dateisystemhierarchie vorhanden sind, so deutet dies darauf hin, dass die Dateisystemdaten von der globalen Zone verwaltet werden. Bei der Installation der nicht-globalen Zone werden verschiedene Paketdateien der globalen Zone in der nicht-globalen Zone dupliziert. Diese Dateien müssen sich direkt unter dem zonepath befinden. Wenn sich die Dateien in einem vom Zonenadministrator erstellten Dateisystem auf Plattengeräten oder ZFS-Datasets befinden, die der Zone hinzugefügt wurden, könnten Paket- und Patch-Probleme auftreten.

Das Problem beim Speichern von Dateisystemdaten, die von der globalen Zone verwaltet werden, in einem nur für die Zone geltenden Dateisystem kann beispielhaft für ZFS beschrieben werden. Wenn ein ZFS-Dataset an eine nicht-globale Zone delegiert wurde, sollte der Zonenadministrator dieses Dataset nicht zum Speichern von Dateisystemdaten verwenden, die von der globalen Zone verwaltet werden. Die Konfiguration kann nicht korrekt gepatcht oder aktualisiert werden.

Beispielsweise sollte ein delegiertes ZFS-Dataset nicht als /var-Dateisystem verwendet werden. Das Betriebssystem Solaris enthält Core-Pakete, die unter /var installiert werden. Wenn sie aktualisiert oder gepatcht werden, haben diese Pakete Zugriff auf /var. Dies ist nicht möglich, wenn /var als ein delegiertes ZFS-Dataset eingehängt ist.

Das Einhängen des Dateisystems in Teilen der von der globalen Zone gesteuerten Hierarchie wird unterstützt. Wenn beispielsweise ein leeres Verzeichnis /usr/local in der globalen Zone existiert, kann der Zonenadministrator andere Inhalte in diesem Verzeichnis einhängen.

Sie können ein delegiertes ZFS-Dataset für Dateisysteme verwenden, auf die während des Patchens oder Aktualisierens nicht zugegriffen werden muss, z. B. /export in der nicht-globalen Zone.

Zone lässt sich nicht anhalten

Wenn der einer Zone zugeordnete Systemstatus nicht korrekt gelöscht werden kann, schlägt ein Vorgang zum Anhalten („halt“) während des Vorgangs fehl. Dies versetzt eine Zone in einen Zwischenstatus, einem Zustand zwischen „running“ und „installed“. In diesem Zustand gibt es keine aktiven Benutzerprozesse oder Kernel-Threads und es können keine erstellt werden. Wenn der „halt“-Vorgang fehlschlägt, müssen Sie manuell eingreifen und den Prozess vervollständigen.

Die häufigste Ursache eines Fehlers ist die Unfähigkeit des Systems, alle Dateisysteme auszuhängen. Im Gegensatz zum traditionellen Herunterfahren eines Solaris-Systems, wobei der Systemstatus vollständig gelöscht wird, müssen Zonen sicherstellen, dass während des Bootens der Zone keine Mounts vorgenommen werden und dass keine Zonenvorgänge nach dem Anhalten der Zone aktiv bleiben. Obwohl zoneadm sicherstellt, dass keine Prozesse mehr in der Zone ausgeführt werden, kann das Aushängen fehlschlagen, wenn Prozesse in der globalen Zone Dateien in der betreffenden Zone geöffnet haben. Verwenden Sie die in den Manpages proc(1) (siehe pfiles) und fuser(1M), beschriebenen Tools, um diese Prozesse zu finden und die erforderlichen Maßnahmen einzuleiten. Nachdem diese Prozesse korrekt verarbeitet wurden, sollte die Zone durch erneutes Aufrufen von zoneadm halt vollständig angehalten werden.

Ab Solaris-Release 10 10/09 können Sie für Zonen, die nicht angehalten werden können und nicht getrennt wurden, mit zoneadm attach - F einen attach-Vorgang ohne Validierung erzwingen. Das Zielsystem muss zum Hosten der Zone richtig konfiguriert sein. Bei einer falschen Konfiguration kann sich ein unerwartetes Verhalten einstellen. Es gibt außerdem keine Möglichkeit, den Status der Dateien innerhalb der Zone festzustellen.

Falsches Berechtigungsset in der Zonenkonfiguration angegeben

Enthält das Berechtigungsset einer Zone eine nicht zulässige Berichtigung, fehlt eine erforderliche Berechtigung oder enthält es einen unbekannten Berechtigungsnamen, schlägt der Versuch, die Zone zu überprüfen, fertig zu stellen oder zu booten fehl und es wird eine Fehlermeldung wie die Folgende angezeigt:

zonecfg:zone5> set limitpriv="basic"
.
.
.
global# zoneadm -z zone5 boot
 	required privilege "sys_mount" is missing from the zone's privilege set
 	zoneadm: zone zone5 failed to verify

`netmasks`-Warnung wird beim Booten der Zone angezeigt

Die folgende Meldung könnte beim Booten einer Zone gemäß der Beschreibung unter So booten Sie eine Zone angezeigt werden:

# zoneadm -z my-zone boot
zoneadm: zone 'my-zone': WARNING: hme0:1: no matching subnet
	found in netmasks(4) for 192.168.0.1; using default of
	255.255.255.0.

Diese Meldung ist nur eine Warnung. Der Befehl war erfolgreich. Die Meldung weist darauf hin,, dass das System nicht in der Lage war, die netmask zu finden, die für die in der Zonenkonfiguration angegebene IP-Adresse verwendet werden soll.

Damit diese Warnung bei kommenden Neustarts nicht erneut angezeigt wird, stellen Sie sicher, dass die korrekten netmasks-Datenbanken in der Datei /etc/nsswitch.conf der globalen Zone aufgeführt sind, und das mindestens eine dieser Datenbanken das Teilnetz und die netmasks enthält, die für die Zone my-zone verwendet werden.

Angenommen, die Datei /etc/inet/netmasks und die lokale NIS-Datenbank werden für die Auflösung der netmasks in der globalen Zone verwendet, so lautet der entsprechende Eintrag in /etc/nsswitch.conf:

netmasks: files nis

Die Teilnetz- und entsprechenden Netzmasken-Informationen für die Zone my-zone können /etc/inet/netmasks für eine spätere Nutzung hinzugefügt werden.

Weitere Informationen zum Befehl netmasks finden Sie in der Manpage netmasks(4).

Auflösen von Problemen bei einem `zoneadm` `attach`-Vorgang

Patches und Pakete sind nicht synchron

Das Zielsystem muss die gleichen Versionen der folgenden Betriebssystempakete und -Patches wie auf dem Ursprungshost aufweisen.

Pakete, die Dateien unter einer inherit-pkg-dir-Ressource bereitstellen
Pakete, bei denen Folgendes gesetzt ist: SUNW_PKG_ALLZONES=true

Wenn Pakete und Patches auf dem Ursprungshost und dem neuen Host unterschiedlich sind, wird eventuell eine Meldung ähnlich der Folgenden angezeigt:

host2# zoneadm -z my-zone attach
	These packages installed on the source system are inconsistent with this system:
            SUNWgnome-libs (2.6.0,REV=101.0.3.2005.12.06.20.27) version mismatch
                    (2.6.0,REV=101.0.3.2005.12.19.21.22)
            SUNWudaplr (11.11,REV=2005.12.13.01.06) version mismatch
                    (11.11,REV=2006.01.03.00.45)
            SUNWradpu320 (11.10.0,REV=2005.01.21.16.34) is not installed
            SUNWaudf (11.11,REV=2005.12.13.01.06) version mismatch
                    (11.11,REV=2006.01.03.00.45)
            NCRos86r (11.10.0,REV=2005.01.17.23.31) is not installed
	These packages installed on this system were not installed on the source system:
            SUNWukspfw (11.11,REV=2006.01.03.00.45) was not installed
            SUNWsmcmd (1.0,REV=2005.12.14.01.53) was not installed
	These patches installed on the source system are inconsistent with this system:
            120081 is not installed
            118844 is not installed
            118344 is not installed
	These patches installed on this system were not installed on the source system:
            118669 was not installed
            118668 was not installed
            116299 was not installed

Sie können die Zone mithilfe eines der folgenden Verfahren migrieren:
- Aktualisieren Sie den neuen Host mit den korrekten Paketen und Patches, so dass dieser Inhalt auf beiden Systemen gleich ist. Weitere Informationen finden Sie in Kapitel 25Allgemeine Informationen zu den Paketen und Patches auf einem Solaris-System mit installierten Zonen und Kapitel 26Hinzufügen und Entfernen von Paketen und Patches auf einem Solaris-System mit installierten Zonen (Vorgehen).
- Wenn auf dem neuen Host neuere Versionen der zonenabhängigen Pakete und deren Patches installiert sind, verwenden Sie den Befehl zoneadm attach mit der Option -u oder - U, um diese Pakete innerhalb der Zone an den neuen Host anzupassen. Siehe Allgemeine Informationen zum Migrieren einer Zone.

Betriebssystem-Releases stimmen nicht überein

Um die Zone erfolgreich zu migrieren, installieren Sie das gleiche Solaris-Release, das auf dem Ursprungshost ausgeführt wird, auf einem System mit der gleichen Architektur.

Überprüfen Sie, welches Solaris-Release auf dem Ausgangssystem installiert ist.
host1# uname -a

Installieren Sie das gleiche Release auf dem neuen Host.

Weitere Informationen finden Sie in der Solaris-Installationsdokumentation unter docs.sun.com.

Rechnerarchitekturen stimmen nicht überein

Um die Zone erfolgreich zu migrieren, verwenden Sie die Option -u des Befehls zoneadm attach.

Überprüfen Sie die Architekturen auf beiden Systemen.
host1# uname -a

Wenn die Architekturen unterschiedlich·sind, sollten Sie die Zone mithilfe der Option -u des Befehls zoneadm attach anhängen.
host2# zoneadm -z my-zone attach -u
Weitere Informationen finden Sie unter So migrieren Sie eine nicht-globalen Zone.

Zonen mit einer `fs`-Ressource, die mit einem `lofs`-Typ definiert wurden, können nicht auf das Solaris-Release 10 11/06 aktualisiert werden

Hinweis –

Dieses Problem wurde für das Solaris-Release 10 8/07 behoben.

Wenn alle nicht-globalen Zonen, die mit lofs fs-Ressourcen konfiguriert wurden, im Miniroot vorhandene Verzeichnisse einhängen, kann das System von einem Release vor Solaris 10 mithilfe eines standardmäßigen Upgrade-Verfahrens auf das Solaris-Release 10 11/06 aktualisiert werden. Beispielsweise stellt ein als lofs eingehängtes Verzeichnis /opt keine Probleme für ein Upgrade dar.

Wenn jedoch eine Ihrer nicht-globalen Zone mit einem nicht-standardmäßigen lofs-Mount konfiguriert ist (z. B. ein als lofs eingehängtes Verzeichnis /usr/local), wird die folgende Fehlermeldung angezeigt:

The zones upgrade failed and the system needs to be restored
from backup.  More details can be found in the file
/var/sadm/install_data/upgrade_log on the upgrade root file
system.

Obwohl diese Fehlermeldung darauf hinweist, dass das System aus einer Sicherungskopie wiederhergestellt werden muss, ist das System tatsächlich fehlerfrei und es kann mithilfe der folgenden Problemumgehung erfolgreich aufgerüstet werden:

Starten Sie das System mit dem installierten Betriebssystem neu.
Konfigurieren Sie die Zonen neu und entfernen Sie die fs-Ressourcen, die als lofs-Typ definiert wurden.
Nachdem Sie diese Ressourcen entfernt haben, führen Sie ein Upgrade des Systems auf Solaris 10 11/06 durch.
Nach dem Upgrade können Sie die Zone erneut konfigurieren, um die entfernten fs-Ressourcen wiederherzustellen.