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

, , , ,

  1. Poster un commentaire

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :