Guide d'administration système : Gestion des ressources des conteneurs et des zones Oracle Solaris

Chapitre 30 Dépannage de problèmes liés aux zones Solaris

Ce chapitre est nouveau pour la version Solaris 10 6/06.

Vous trouverez une liste complète des nouvelles fonctionnalités de Solaris 10 et la description des différentes versions de Solaris dans le guide Nouveautés apportées à Oracle Solaris 10 9/10.

Solaris 10 6/06, Solaris 10 11/06, Solaris 10 8/07 et Solaris 10 5/08 : ne pas placer le système de fichiers racine d'une zone non globale sur le ZFS

Pour ces version, zonepath d'une zone non globale ne doit pas résider sur un ZFS. Cette opération pourrait entraîner des problèmes de patch et, éventuellement, empêcher toute mise à niveau du système vers une version ultérieure de Solaris 10.

Notez que le système de fichiers racine d'une zone non globale peut résider sur un ZFS à compter de la version 10 10/08 de Solaris. Solaris Live Upgrade peut ensuite être utilisé pour mettre le système de fichiers à niveau.

La zone en mode IP exclusif utilise un périphérique et entraîne l'échec de `dladm` `reset-linkprop`

Si le message suivant s'affiche :

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

Après avoir consulté Utilisation de la commande dladm reset-linkprop , vous avez essayé d'utiliser dladm reset-linkprop sans succès. La zone en cours d'exécution excl utilise le périphérique assigné lors de l'exécution de la commande ifconfig bge0 plumbau sein de la zone.

Pour rétablir la valeur, suivez la procédure ifconfig bge0 unplumb à l'intérieur de la zone et réexécutez la commande dladm.

L'administrateur de zone effectue le montage sur des systèmes de fichiers gérés par la zone globale

La présence de fichiers au sein d'une arborescence de système de fichiers lors du démarrage initial d'une zone non globale indique que les données du système de fichiers sont gérées par la zone globale. Lors de l'installation de la zone non globale, certains fichiers de conditionnement de la zone globale ont été dupliqués à l'intérieur de la zone. Ces fichiers doivent résider directement sous le zonepath. Si les fichiers résident sous un système de fichiers créé par un administrateur de zone sur des périphériques de disque ou des jeux de données ZFS ajoutés à la zone, des problèmes de patch et de conditionnement peuvent se produire.

Le ZFS permet d'illustrer le problème de stockage des données de système de fichiers gérées par la zone globale dans un système de fichiers résidant dans une zone. Si un ensemble de données ZFS a été délégué à une zone non globale, l'administrateur de zone ne doit pas utiliser cet ensemble de données pour stocker des données de système de fichiers gérées par la zone globale. La configuration ne pourrait être corrigée ou mise à niveau correctement.

Par exemple, un ensemble de données délégué ZFS ne doit pas être utilisé en tant que système de fichiers /var. Le système d'exploitation Solaris fournit des packages de base qui installent des composants dans /var. Ces packages doivent accéder à /var lors de leur mise à niveau ou de leur correction. Si /var est monté sur un ensemble de données ZFS, cela s'avère impossible.

Le montage de systèmes de fichiers sous des parties de l'arborescence contrôlée par la zone globale est pris en charge. Par exemple, s'il existe un répertoire /usr/local vide dans la zone globale, l'administrateur de zone peut monter du contenu supplémentaire sous ce répertoire.

Vous pouvez utiliser un jeu de données ZFS délégué pour les systèmes de fichiers auxquels l'accès n'est pas nécessaire lors de l'application de patch ou de mise à jour, comme /export dans la zone non globale.

La zone ne s'arrête pas

Si l'état système associé à la zone ne peut pas être détruit, l'arrêt échoue à mi-étape. La zone se trouve alors dans un état intermédiaire, entre exécution et installation. Aucun processus utilisateur ou thread de noyau n'est actif et vous ne pouvez pas en créer. En cas d'échec de l'arrêt, vous devez terminer le processus manuellement.

Cet échec s'explique généralement par l'incapacité du système à démonter tous les systèmes de fichiers. Contrairement à un arrêt classique du système Solaris, qui détruit l'état du système, les zones doivent veiller à ce qu'aucun montage effectué lors de l'initialisation de la zone ou lors d'une opération de zone ne soit conservé après l'arrêt de la zone. zoneadm garantit qu'aucun processus n'est exécuté dans la zone, mais le démontage peut échouer si les processus dans la zone globale présentent des fichiers ouverts dans la zone. Utilisez les outils décrits dans les pages de manuel proc(1) (voir pfiles) et fuser(1M) pour rechercher ces processus et prendre les mesures adéquates. Une fois ces processus gérés, le rappel de la commande zoneadm halt devrait arrêter complètement la zone.

À partir de la version Solaris 10 10/09, si vous ne parvenez pas à arrêter une zone, vous pouvez migrer une zone qui n'a pas été détachée à l'aide de la commande zoneadm attach avec l'option - F pour forcer le rattachement sans validation. Le système cible doit être configuré correctement pour héberger la zone. Une configuration incorrecte peut entraîner un comportement indéfini. En outre, il n'existe aucun moyen de connaître l'état des fichiers situés dans la zone.

Privilèges incorrects spécifiés dans la configuration de zone

Si le jeu de privilèges de la zone comporte un privilège non autorisé, ne contient pas un privilège requis ou inclut un nom de privilège inconnu, toute tentative de vérification, de préparation ou d'initialisation de la zone échoue et le message d'erreur suivant s'affiche :

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

Un avertissement `netmasks` s'affiche lors de l'initialisation de la zone

Le message suivant peut s'afficher lorsque vous initialisez la zone d'après la description donnée à la section Initialisation d'une zone:

# 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.

Ce message n'est qu'un avertissement. La commande s'est correctement exécutée. Le message indique que le système n'a pas pu trouver le masque de réseau à utiliser pour l'adresse IP spécifiée dans la configuration de la zone.

Pour empêcher qu'il ne s'affiche lors des initialisations suivantes, veillez à ce que les bases de données de masques de réseau correctes soient répertoriées dans le fichier /etc/nsswitch.conf dans la zone globale et qu'au moins l'une d'entre elles contienne le sous-réseau et les masques de réseau à utiliser pour la zone my-zone.

Par exemple, si le fichier /etc/inet/netmasks et la base de données NIS locale sont utilisés dans le cadre de la résolution de masques de réseau au sein de la zone globale, l'entrée correcte dans /etc/nsswitch.conf est la suivante :

netmasks: files nis

Vous pouvez alors ajouter le sous-réseau et les informations de sous-réseau correspondantes pour la zone my-zone au fichier /etc/inet/netmasks pour une utilisation ultérieure.

Pour plus d'informations sur la commande netmasks, reportez-vous à la page de manuel netmasks(4).

Résolution de problèmes via l'opération `zoneadm` `attach`

Les patchs et les packages ne sont pas synchronisés

Les patchs et packages de système d'exploitation requis suivants exécutés par le système cible doivent être de la même version que ceux qui sont installés sur l'hôte d'origine.

packages délivrant les fichiers avec une ressource inherit-pkg-dir
packages où SUNW_PKG_ALLZONES=true

Lorsque les packages et les patchs de l'hôte d'origine et du nouvel hôte sont différents, le texte suivant peut s'afficher :

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

Pour faire migrer la zone, employez l'une des méthodes suivantes :
- Mettez à jour le nouvel hôte avec les packages et patchs adéquats, afin que le contenu soit identique sur les deux systèmes. Pour plus d'informations, reportez-vous au Chapitre 25À propos des packages et des patchs pour les systèmes Solaris comportant des zones installées (présentation) et au Chapitre 26Ajout et suppression de packages et de patchs sur un système Solaris comportant des zones installées (tâches).
- Si le nouvel hôte dispose de versions plus récentes des packages dépendants des zones ou des patchs qui leur sont associés, utilisez la commande zoneadm attach avec l'option -u ou -U pour mettre à jour les packages de la zone afin qu'ils correspondent au nouvel hôte. Voir À propos de la migration d'une zone.

Les versions de système d'exploitation ne correspondent pas

Pour migrer la zone, installez la version Solaris exécutée sur l'hôte d'origine sur un système présentant la même architecture.

Vérifiez la version de Solaris exécutée sur le système d'origine.
host1# uname -a

Installez la même version sur le nouvel hôte.

Consultez la documentation relative à l'installation Solaris sur le site Web docs.sun.com.

Les architectures des machines ne correspondent pas

Pour migrer la zone, utilisez l'option -u avec la commande zoneadm attach.

Vérifiez l'architecture système des deux systèmes.
host1# uname -a

Si les architectures sont différentes, utilisez l'option -u de la commande zoneadm attach pour effectuer le rattachement.
host2# zoneadm -z my-zone attach -u
Pour plus d'informations, reportez-vous à la section Migration d'une zone non globale.

Mise à niveau vers Solaris 10 11/06 impossible pour les zones ayant une ressource `fs` de type `lofs`

Remarque –

Ce problème a été corrigé dans la version Solaris 10 8/07.

Si toutes les zones non globales configurées avec des ressources fs lofs sont des répertoires de montage existant dans la mini-racine, le système peut être mis à niveau à partir d'une version Solaris 10 antérieure à la version 10 11/06 via une mise à niveau standard. Par exemple, un répertoire /opt monté avec une ressource lofs ne pose pas de problème lors des mises à niveau.

Cependant, si au moins une zone non globale est configurée avec un montage lofs non standard, par exemple un répertoire /usr/local monté avec une ressource lofs, le message d'erreur suivant s'affiche :

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.

Ce message d'erreur indique que le système doit être restauré à partir de la sauvegarde. En réalité, le système est en parfait état et peut être mis à niveau via la solution ci-dessous :

Redémarrez le système avec le système d'exploitation installé.
Reconfigurez les zones en supprimant les ressources fs définies avec le type lofs.
Une fois ces ressources supprimées, mettez le système à niveau vers Solaris 10 11/06.
Ensuite, vous pouvez reconfigurer les zones afin de restaurer les ressources fs supplémentaires supprimées.