Gérer les modules du VMkernel avec vmkload_mod et esxcfg-module

Décharger un module peu sembler superflu de prime abord. En effet, l’hôte ESX sur lequel vous allez effectuer l’opération ne sera probablement pas plus performant et bien malin qui pourrait voir une augmentation des performances CPU et/ou RAM. Pourtant, au niveau réseau, vous pourrez observer dans certains cas (installations avec de nombreuses LUNs et volumes VMFS…) une rapidité accrue dans le rafraîchissement de vos datastores et de vos adaptateurs de stockage iSCSI et Fiber Channel.

Opérations en environnement VMware ESX 3.5

Pour lister les modules actifs du VMkernel, on utilise soit la commande vmkload_mod -l, soit la commande esxcfg-module -l.

[root@srv5 etc]# vmkload_mod -l
Name           R/O Addr     Length      R/W Addr     Length        ID Loaded
vmklinux       0x87e000     0x20000     0x28a3280    0x4d000       1  Yes
ata_piix       0x89e000     0xb000      0x28f02a0    0x4000        2  Yes
megaraid_sas   0x8a9000     0x7000      0x28f42c0    0x3000        3  Yes
bnx2           0x8b0000     0x10000     0x28f72e0    0x17000       4  Yes
e1000          0x8c0000     0x1c000     0x290e300    0x6000        5  Yes
lvmdriver      0x8dc000     0xb000      0x292b580    0x2000        6  Yes
vmfs3          0x8e7000     0x2c000     0x292d5c0    0x1000        7  Yes
etherswitch    0x913000     0x3000      0x292e688    0x1000        8  Yes
shaper         0x916000     0x3000      0x292fb80    0x1000        9  Yes
tcpip          0x919000     0x3a000     0x2930c00    0x1c000       10 Yes
cosShadow      0x953000     0x3a000     0x294cc80    0x1c000       11 Yes
migration      0x98d000     0xf000      0x2968ca0    0x2000        12 Yes
nfsclient      0x99c000     0x12000     0x296acc0    0x1000        13 Yes
deltadisk      0x9ae000     0x7000      0x296bf60    0x1000        14 Yes
vmfs2          0x9b5000     0x10000     0x296cf80    0x11000       15 Yes
iscsi_mod      0x9c5000     0x35000     0x297dfa0    0xa000        16 Yes

Ici, on remarque que le module vmfs2 est chargé, or nous n’utilisons que vmfs3. On peut donc désactiver ce module pour décharger le VMkernel de cette gestion inutile. Pour cela, on utilise à nouveau la commande vmkload_mod mais cette fois avec l’argument -u (pour unload). La commande esxcfg-module -d aurait également été possible.

[root@srv5 etc]# vmkload_mod -u vmfs2

Ne reste plus qu’à lister de nouveau pour vérifier que le module vmfs2 a bien été désactivé. Vous pouvez bien sûr répéter l’opération pour tout autre module qui vous serait inutile. Comme nous avons pris l’exemple du stockage, continuons dedans. Si vous n’utilisez pas NFS (module nfsclient), désactivez-le à son tour et validez l’opération en listant de nouveau les modules.

[root@srv5 etc]# vmkload_mod -l
Name           R/O Addr     Length      R/W Addr     Length        ID Loaded
vmklinux       0x87e000     0x20000     0x28a3280    0x4d000       1  Yes
ata_piix       0x89e000     0xb000      0x28f02a0    0x4000        2  Yes
megaraid_sas   0x8a9000     0x7000      0x28f42c0    0x3000        3  Yes
bnx2           0x8b0000     0x10000     0x28f72e0    0x17000       4  Yes
e1000          0x8c0000     0x1c000     0x290e300    0x6000        5  Yes
lvmdriver      0x8dc000     0xb000      0x292b580    0x2000        6  Yes
vmfs3          0x8e7000     0x2c000     0x292d5c0    0x1000        7  Yes
etherswitch    0x913000     0x3000      0x292e688    0x1000        8  Yes
shaper         0x916000     0x3000      0x292fb80    0x1000        9  Yes
tcpip          0x919000     0x3a000     0x2930c00    0x1c000       10 Yes
cosShadow      0x953000     0x3a000     0x294cc80    0x1c000       11 Yes
migration      0x98d000     0xf000      0x2968ca0    0x2000        12 Yes
deltadisk      0x9ae000     0x7000      0x296bf60    0x1000        14 Yes
iscsi_mod      0x9c5000     0x35000     0x297dfa0    0xa000        16 Yes

Seul bémol, les modifications effectuées ne seront plus valables au prochain boot. Il faudrait donc envisager de scripter les opérations pour bénéficier de vos modifications à long terme.

Opérations en environnement VMware vSphere 4

Il y a eu peu de changements dans la gestion des modules avec l’arrivée de VMware vSphere 4, néanmoins, ils sont assez significatifs pour être décrits ici. En effet, les commandes de listage et de déchargement de modules sont les mêmes mais la commande esxcfg-module permet désormais de préserver les modifications, même après redémarrage !

Si la désactivation d’un module par esxcfg-module -d <module> fonctionne sans problème, la confirmation n’apparaît pas en listant les modules avec esxcfg-module -l ce qui peut être déroutant. Pourtant, en utilisant la commande esxcfg-module -q (pour lister les modules actifs), on verra bien que le module est déchargé, de même que dans le fichier /etc/vmware/esx.conf, à la ligne correspondante.

/vmkernel/module/vmfs2/enabled = "false"

Pour information, voici le détail des arguments les plus utiles de la commande esxcfg-module :

-e --enable
Enable the given module, indicating it should load at boot time.
-d --disable
Disable the given module preventing it from loading at boot.
This will have no immediate effect on the module state on a running system.
-q --query
Query the system for the modules to load at boot.
-l --list
Detailed list of loaded modules

Remarquez que l’argument -d se comporte donc bien différemment de VMware ESX 3.5. : “Disable the given module preventing it from loading at boot”.

Créer et présenter un LUN avec une baie Dell EqualLogic PS4000 et VMware ESX 3.5

Rappel : pour présenter un volume iSCSI à un hôte (ici ce sera un ESX), on suit le cheminement classique disque physique > Raid Group > LUN

Création de la LUN

Rendez-vous dans l’utilitaire Java de configuration de votre baie EqualLogic. Cliquez sur la partie Volumes puis Create Volume.

Dans notre cas, étant donné qu’un seul Raid Group existe (RG0), le nouveau volume sera créé dedans par défaut.

On crée un volume de 1175 Go, soit à peu près la moitié de la taille utile totale de 2.35 TB (la deuxième moitié correspond d’après mes tests à 1228 Go). Sauf utilisation bien spécifique, on n’utilise pas la fonction de Snapshot. Ainsi, on garde plus d’espace disque pour le stockage de ressources en production.

Pour l’instant on ne s’attache pas à créer d’accès iSCSI. Les seules informations dont on s’occupe sont l’accès à la LUN en lecture et écriture (Set read-write) et la possibilité pour plusieurs initiateurs d’y accéder (Enable shared access to the iSCSI target from multiple initiators). En effet, peu de cas impliquent l’utilisation d’un stockage centralisé pour un seul hôte…

La LUN de 1.15 TB est désormais en ligne dans le Raid Group RG0.

Configuration de la présentation iSCSI

Dans le VIC, allez sur un hôte ESX, onglet Configuration, puis repérez la partie Storage Adapters. Dès lors on obtient l’information qui nous intéresse : l’identifiant iSCSI de l’hôte.

De retour dans l’interface de gestion de votre baie, copiez-collez la chaîne de caractères dans la partie Limit access to iSCSI initiator name et validez.

Cela a pour effet de créer une access list basée sur le nom de l’initiateur indiqué. Vous pouvez en rajouter autant que vous le désirez.

Enfin, notez l’adresse IP (fonctionne un peu comme une VIP) du groupe de baies EqualLogic. Si vous en avez plusieurs en pile, ce sera le moyen de communiquer simplement et de façon centralisée avec les hôtes ESX.

Présentation de la LUN dans l’hôte ESX

Retournez dans le VIC, toujours dans la partie Storage Adapters, et cliquez cette fois sur Properties…. Ajouter à présent l’adresse IP de votre groupe de baies sur le port 3260 (port iSCSI par défaut)

Ne reste plus qu’à cliquer sur Rescan… pour rafraîchir les connexions iSCSI vers les targets déclarées. Si vous avez bien suivi les opérations précédentes, vous devez voir apparaître la ou les LUN(s) créée(s).