Je suis tombé sur un cas intéressant où je ne pouvais pas modifier ma bootlist lorsque je spécifier un disque SAN car il avait “trop” de chemins d’accès. La solution simple aurait consisté à supprimer des chemins d’accès au niveau du zoning SAN(la meilleure solution) mais ce n’étais pas possible à ce moment là. Voilà une description de la solution.
Description du problème
Lorsque l’on spécifie le disque hdisk34 à la commande bootlist, on obtient le message suivant :
# bootlist -m normal hdisk34
0514-222 bootlist: Unable to write boot device list to NVRAM
Pour avoir une explication plus détaillée sur ce qui se passe lors de l'exécution de la commande bootlist, on ajoute l'option -v :
bootlist -v -m normal hdisk34
'ibm,max-boot-devices' = 0x5
match_specific_info: ut=disk/fcp/2107
Processing fcp device
bootinfo_aix = /pci@80000002000001a/pci@2,4/fibre-channel@1/disk@5005076305034120,4018400500000000:1
boot list for device: '/pci@80000002000001a/pci@2,4/fibre-channel@1/disk@5005099905034120,9918400500000000:2'
Processing fcp device
boot list for device: '/pci@80000002000001a/pci@2,4/fibre-channel@1/disk@50050999051b4120,9918400500000000:2'
Processing fcp device
boot list for device: '/pci@80000002000001a/pci@2,4/fibre-channel@1/disk@5005099905084120,9918400500000000:2'
Processing fcp device
boot list for device: '/pci@80000002000001a/pci@2,4/fibre-channel@1/disk@5005099905104120,9918400500000000:2'
Processing fcp device
boot list for device: '/pci@80000002000001d/pci@2,4/fibre-channel@1/disk@5005099905080120,9918400500000000:2'
Processing fcp device
boot list for device: '/pci@80000002000001d/pci@2,4/fibre-channel@1/disk@50050999051b0120,9918400500000000:2'
Exceeded max devs, ignoring dev 'hdisk34', (/pci@80000002000001d/pci@2,4/fibre-channel@1/disk@50050763051b0120,4018400500000000:2)
Setting NVRAM variable: (boot-device=/pci@80000002000001a/pci@2,4/fibre-channel@1/disk@5005076305034120,4018400500000000:2 /pci@80000002000001a/pci@2,4/fibre-channel@1/disk@50050763051b4120,4018400500000000:2 /pci@80000002000001a/pci@2,4/fibre-channel@1/disk@5005076305084120,4018400500000000:2 /pci@80000002000001a/pci@2,4/fibre-channel@1/disk@5005076305104120,4018400500000000:2 /pci@80000002000001d/pci@2,4/fibre-channel@1/disk@5005076305080120,4018400500000000:2)
0514-222 bootlist: Unable to write boot device list to NVRAM
Le message Exceeded max devs indique que l’on a dépassé la valeur maximum de chemins d’accès, lors de l’ajout du 6 ème chemin.
L’option ibm,max-boot-devices qu’on voit au dessus indique un maximum de 5 chemins possibles.
Il s’agit d’une baie ds8000 :
DEV#: 34 DEVICE NAME: hdisk34 TYPE: 2107900 ALGORITHM: Load Balance
SERIAL: 99ZZZZ11805
===========================================================================
Path# Adapter/Path Name State Mode Select Errors
0 fscsi0/path0 OPEN NORMAL 88215 0
1 fscsi0/path1 OPEN NORMAL 88194 0
2 fscsi2/path4 OPEN NORMAL 101033 0
3 fscsi2/path5 OPEN NORMAL 100733 0
4 fscsi0/path2 OPEN NORMAL 100158 0
5 fscsi0/path3 OPEN NORMAL 100147 0
On va donc supprimer 2 chemins d’accès.
Suppression des chemins
On supprime d’abord les chemins path2 et path3 au niveau du driver SDDPCM, :
# pcmpath set device 34 path 2 offline
Success: set device 34 path 2 to offline
DEV#: 34 DEVICE NAME: hdisk34 TYPE: 2107900 ALGORITHM: Load Balance
SERIAL: 99ZZZZ11805
===========================================================================
Path# Adapter/Path Name State Mode Select Errors
0 fscsi0/path0 OPEN NORMAL 88287 0
1 fscsi0/path1 OPEN NORMAL 88266 0
2 fscsi2/path4 OPEN NORMAL 101120 0
3 fscsi2/path5 OPEN NORMAL 100852 0
4 fscsi0/path2 OPEN OFFLINE 100210 0
5 fscsi0/path3 OPEN NORMAL 100210 0
# pcmpath set device 34 path 3 offline
Success: set device 34 path 3 to offline
DEV#: 34 DEVICE NAME: hdisk34 TYPE: 2107900 ALGORITHM: Load Balance
SERIAL: 99ZZZZ11805
===========================================================================
Path# Adapter/Path Name State Mode Select Errors
0 fscsi0/path0 OPEN NORMAL 88296 0
1 fscsi0/path1 OPEN NORMAL 88275 0
2 fscsi2/path4 OPEN NORMAL 101131 0
3 fscsi2/path5 OPEN NORMAL 100864 0
4 fscsi0/path2 OPEN OFFLINE 100210 0
5 fscsi0/path3 OPEN OFFLINE 100210 0
Les chemins sont maintenant en statut offline. Cela ne permet toujours pas de lancer la commande bootlist mais cela facilite la détection des chemins à supprimer avec la commande rmpath.
On identifie les chemins avec lspath :
# lspath -l hdisk34 -s available -F"connection:parent:path_status:status"
5005076305034120,4018400500000000:fscsi0:Available:Enabled
50050999051b4120,9918400500000000:fscsi0:Available:Enabled
5005099905084120,9918400500000000:fscsi0:Available:Disabled
5005099905104120,9918400500000000:fscsi0:Available:Disabled
5005099905080120,9918400500000000:fscsi2:Available:Enabled
50050999051b0120,9918400500000000:fscsi2:Available:Enabled
On supprime ensuite les chemins en spécifiant la connection :
# rmpath -l hdisk34 -p fscsi0 -w 5005099905104120,9918400500000000
path Defined
# rmpath -l hdisk34 -p fscsi0 -w 5005099905084120,9918400500000000
path Defined
On dispose maintenant uniquement de 4 chemins d’accès :
pcmpath query device 34
DEV#: 34 DEVICE NAME: hdisk34 TYPE: 2107900 ALGORITHM: Load Balance
SERIAL: 99ZZZZ11805
===========================================================================
Path# Adapter/Path Name State Mode Select Errors
0 fscsi0/path0 OPEN NORMAL 89559 0
1 fscsi0/path1 OPEN NORMAL 89516 0
2 fscsi2/path4 OPEN NORMAL 102475 0
3 fscsi2/path5 OPEN NORMAL 102147 0
Et la commande bootlist fonctionne correctement :
bootlist -v -m normal hdisk34
'ibm,max-boot-devices' = 0x5
match_specific_info: ut=disk/fcp/2107
Processing fcp device
bootinfo_aix = /pci@80000002000001a/pci@2,4/fibre-channel@1/disk@5005099905034120,9918400500000000:1
boot list for device: '/pci@80000002000001a/pci@2,4/fibre-channel@1/disk@5005099905034120,9918400500000000:2'
Processing fcp device
boot list for device: '/pci@80000002000001a/pci@2,4/fibre-channel@1/disk@50050999051b4120,9918400500000000:2'
Processing fcp device
boot list for device: '/pci@80000002000001d/pci@2,4/fibre-channel@1/disk@5005099905080120,9918400500000000:2'
Processing fcp device
boot list for device: '/pci@80000002000001d/pci@2,4/fibre-channel@1/disk@50050999051b0120,9918400500000000:2'
Setting NVRAM variable: (boot-device=/pci@80000002000001a/pci@2,4/fibre-channel@1/disk@5005099905034120,9918400500000000:2 /pci@80000002000001a/pci@2,4/fibre-channel@1/disk@50050999051b4120,9918400500000000:2 /pci@80000002000001d/pci@2,4/fibre-channel@1/disk@5005099905080120,9918400500000000:2 /pci@80000002000001d/pci@2,4/fibre-channel@1/disk@50050999051b0120,9918400500000000:2)
Setting NVRAM variable: (boot-file=)
Setting NVRAM variable: (boot-command=boot)
Setting NVRAM variable: (bootinfo-aix=/pci@80000002000001a/pci@2,4/fibre-channel@1/disk@5005099905034120,9918400500000000:1)
Setting NVRAM variable: (ibm,aix-fc-bootinfo=)
Ce qui nous donne :
# bootlist -m normal -o
hdisk34 blv=hd5
hdisk34 blv=hd5
hdisk34 blv=hd5
hdisk34 blv=hd5
Conclusion
La technique proposée ci-desus n’est qu’une solution de controunement. En effet, dès que cfgmgr est exécuté, les chemins seront recréé et si la commande bootlist est exécuté par la suite, elle échouera. Je l’ai utilisé car je n’avais pas la possibilité d’accéder à la configuration du zoning au moment des opérations. J’en ai fait un billet car je pense que la démarche et les commandes sont intéressantes.