Al momento de actualizar el kernel en un guest CentOS, las VMware Tools dejan de funcionar debido a que los módulos del kernel Linux provistos por VMware para dar soporte a las mismas dejan de ser cargados. Esto ocurre porque estos módulos dependen de librerías del kernel. Y luego de una actualización del kernel (o si se inicia desde un kernel diferente) dejan de funcionar porque la configuración apunta a librerías diferentes.
Esta es la versión oficial del Knowledge Base de VMware. La realidad es que los módulos precompilados son compatibles entre diferentes versiones del kernel, y sólo se trata de una cuestión de configuración de módulos, tal como demostraré unos párrafos más adelante.
Veamos un caso puntual. He actualizado el kernel en un servidor CentOS 6 desde la versión "2.6.32-504.8.1" a la "2.6.32-504.12.2". Luego de reiniciar el sistema, las VMware Tools no están corriendo.
Al listar los módulos del kernel actualmente cargados, se observa que faltan los módulos de VMware vmci, vsock y vmxnet:
[root@centos6 ~]# lsmod Module Size Used by ipv6 334740 0 ipt_LOG 5845 1 xt_limit 2118 1 ipt_REJECT 2351 1 nf_conntrack_ipv4 9506 8 nf_defrag_ipv4 1483 1 nf_conntrack_ipv4 xt_state 1492 8 nf_conntrack 80422 2 nf_conntrack_ipv4,xt_state iptable_filter 2793 1 ip_tables 17831 1 iptable_filter ext2 68236 1 ppdev 8537 0 vmware_balloon 7199 0 parport_pc 22658 0 parport 36209 2 ppdev,parport_pc e1000 160675 0 i2c_piix4 11776 0 i2c_core 29964 1 i2c_piix4 sg 29318 0 shpchp 29130 0 ext4 378476 5 jbd2 93427 1 ext4 mbcache 8193 2 ext2,ext4 sd_mod 36998 5 crc_t10dif 1305 1 sd_mod sr_mod 15049 0 cdrom 39085 1 sr_mod mptspi 16411 3 mptscsih 36636 1 mptspi mptbase 93647 2 mptspi,mptscsih scsi_transport_spi 25447 1 mptspi pata_acpi 3701 0 ata_generic 3837 0 ata_piix 24409 0 dm_mirror 14384 0 dm_region_hash 12085 1 dm_mirror dm_log 9930 2 dm_mirror,dm_region_hash dm_mod 95622 20 dm_mirror,dm_log
La versión actual del kernel es la más recientemente instalada:
[root@centos6 ~]# uname -r 2.6.32-504.12.2.el6.x86_64
Entonces, los módulos de VMware deberían estar instalados en el directorio /lib/modules/2.6.32-504.12.2*:
[root@centos6 ~]# cd /lib/modules/2.6.32-504.12.2.el6.x86_64/
Sin embargo, una búsqueda rápida demuestra que no se encuentran:
[root@centos6 2.6.32-504.12.2.el6.x86_64]# find . -type f -iname "vm*" ./kernel/drivers/scsi/vmw_pvscsi.ko ./kernel/drivers/net/vmxnet3/vmxnet3.ko ./kernel/drivers/misc/vmware_balloon.ko ./kernel/crypto/vmac.ko
Esto es bastante lógico si se piensa que el manejador de paquetes no tiene forma de saber qué módulos se han instalado manualmente. O sí, si fuese más flexible y examinara el contenido del archivo modules.dep antes de instalar el nuevo kernel. Aunque el problema sería que desconoce si estos módulos son compatibles o no con el nuevo kernel (entonces, tal vez por una cuestión de seguridad y robustez, no los agrega).
Sea como sea, los módulos no son cargados (sólo el balloon):
[root@centos6 2.6.32-504.12.2.el6.x86_64]# lsmod | grep vm vmware_balloon 7199 0
Al buscar dentro del directorio de módulos correspondientes al kernel anterior, encontramos los módulos faltantes:
[root@centos6 2.6.32-504.12.2.el6.x86_64]# find ../2.6.32-504.8.1.el6.x86_64/ -iname "vm*" ../2.6.32-504.8.1.el6.x86_64/kernel/drivers/scsi/vmw_pvscsi.ko ../2.6.32-504.8.1.el6.x86_64/kernel/drivers/net/vmxnet3 ../2.6.32-504.8.1.el6.x86_64/kernel/drivers/net/vmxnet3/vmxnet3.ko ../2.6.32-504.8.1.el6.x86_64/kernel/drivers/misc/vmware_balloon.ko ../2.6.32-504.8.1.el6.x86_64/kernel/crypto/vmac.ko ../2.6.32-504.8.1.el6.x86_64/misc/vmxnet.ko ../2.6.32-504.8.1.el6.x86_64/misc/vmci.ko
En cambio, en el kernel actual ni siquiera existe el directorio misc:
[root@centos6 2.6.32-504.12.2.el6.x86_64]# ll misc ls: cannot access misc: No such file or directory
Entonces no queda otra alternativa que reinstalar las VMware Tools, tarea que se encarga de instalar los módulos faltantes, entre otras cosas. Para ello ejecutar vmware-config-tools.pl:
[root@centos6 2.6.32-504.12.2.el6.x86_64]# vmware-config-tools.pl Initializing... Making sure services for VMware Tools are stopped. [EXPERIMENTAL] The VMware FileSystem Sync Driver (vmsync) is a new feature that creates backups of virtual machines. Please refer to the VMware Knowledge Base for more details on this capability. Do you wish to enable this feature? [no] Found a compatible pre-built module for vmci. Installing it... Found a compatible pre-built module for vsock. Installing it... The module vmxnet3 has already been installed on this system by another installer or package and will not be modified by this installer. Use the flag --clobber-kernel-modules=vmxnet3 to override. The module pvscsi has already been installed on this system by another installer or package and will not be modified by this installer. Use the flag --clobber-kernel-modules=pvscsi to override. The module vmmemctl has already been installed on this system by another installer or package and will not be modified by this installer. Use the flag --clobber-kernel-modules=vmmemctl to override. The VMware Host-Guest Filesystem allows for shared folders between the host OS and the guest OS in a Fusion or Workstation virtual environment. Do you wish to enable this feature? [no] Found a compatible pre-built module for vmxnet. Installing it... The vmblock enables dragging or copying files between host and guest in a Fusion or Workstation virtual environment. Do you wish to enable this feature? [no] No X install found. Creating a new initrd boot image for the kernel. vmware-tools start/running The configuration of VMware Tools 8.6.10 build-913593 for Linux for this running kernel completed successfully. You must restart your X session before any mouse or graphics changes take effect. You can now run VMware Tools by invoking "/usr/bin/vmware-toolbox-cmd" from the command line or by invoking "/usr/bin/vmware-toolbox" from the command line during an X server session. To enable advanced X features (e.g., guest resolution fit, drag and drop, and file and text copy/paste), you will need to do one (or more) of the following: 1. Manually start /usr/bin/vmware-user 2. Log out and log back into your desktop session; and, 3. Restart your X session. Enjoy, --the VMware team
Al finalizar la instalación, los módulos quedan cargados en el kernel:
[root@centos6 2.6.32-504.12.2.el6.x86_64]# lsmod | grep vm vmxnet 17152 0 vmci 42456 1 vsock vmware_balloon 7199 0
Y se ha creado el directorio misc, como era de esperarse:
[root@centos6 2.6.32-504.12.2.el6.x86_64]# find . -type f -iname "vm*" ./kernel/drivers/scsi/vmw_pvscsi.ko ./kernel/drivers/net/vmxnet3/vmxnet3.ko ./kernel/drivers/misc/vmware_balloon.ko ./kernel/crypto/vmac.ko ./misc/vmxnet.ko ./misc/vmci.ko
Desde el host ESX se comprueba que las VMware Tools están corriendo:
Ahora bien, si comparamos los módulos recientemente instalados con los de la versión anterior del kernel, vemos que son exactamente los mismos (notar que poseen el mismo tamaño en bytes):
[root@centos 2.6.32-504.12.2.el6.x86_64]# ll misc/ total 192 -rw-r--r-- 1 root root 79440 abr 20 09:56 vmci.ko -rw-r--r-- 1 root root 34048 abr 20 09:57 vmxnet.ko -rw-r--r-- 1 root root 73768 abr 20 09:56 vsock.ko
[root@centos 2.6.32-504.12.2.el6.x86_64]# ll ../2.6.32-504.8.1.el6.x86_64/misc/ total 192 -rw-r--r-- 1 root root 79440 ene 29 09:01 vmci.ko -rw-r--r-- 1 root root 34048 ene 29 09:01 vmxnet.ko -rw-r--r-- 1 root root 73768 ene 29 09:01 vsock.ko
Basta con calcular el checksum MD5 de uno para comprobarlo:
[root@centos 2.6.32-504.12.2.el6.x86_64]# cat misc/vmci.ko | md5sum e3f79d2cf0b65cc84d6b699cf240c84c - [root@centos 2.6.32-504.12.2.el6.x86_64]# cat ../2.6.32-504.8.1.el6.x86_64/misc/vmci.ko | md5sum e3f79d2cf0b65cc84d6b699cf240c84c -
Se observa que ambos módulos son exactamente iguales, por ende lo único que hizo el instalador vmware-config-tools.pl fue copiar los módulos al nuevo directorio "misc" dentro de la versión actual del kernel, y luego regenerar la imagen initrd para que sean cargados automáticamente durante el inicio.
Un experimento
Entonces, si son exactamente iguales, ¿qué pasa si intento instalarlos manualmente (en otro servidor CentOS similar)?
Comprobar la versión del kernel:
[root@another-centos ~]# uname -r 2.6.32-504.12.2.el6.x86_64
Cambiar al directorio de módulos correspondiente al kernel actual:
[root@another-centos ~]# cd /lib/modules/2.6.32-504.12.2.el6.x86_64/
Copiar los módulos desde la versión anterior:
[root@another-centos 2.6.32-504.12.2.el6.x86_64]# cp -a ../2.6.32-504.8.1.el6.x86_64/misc/ .
A continuación, intentar cargar el módulo vmci:
[root@another-centos 2.6.32-504.12.2.el6.x86_64]# modprobe vmci FATAL: Module vmci not found.
El sistema no reconoce al módulo vmci ya que no está configurado en el archivo modules.dep. Para ello sería necesario ejecutar depmod -a. Sin embargo, a modo de prueba, es posible instalar módulos manualmente utilizando la herramienta insmod y especificando la ruta al archivo:
[root@another-centos 2.6.32-504.12.2.el6.x86_64]# cd misc/ [root@another-centos misc]# insmod vmci.ko [root@another-centos misc]# insmod vsock.ko [root@another-centos misc]# insmod vmxnet.ko
Ahora sí, con los módulos cargados, es posible iniciar el demonio vmtoolsd para levantar las VMware Tools:
[root@another-centos misc]# /usr/sbin/vmtoolsd & [1] 3714
Las VMware Tools están corriendo al igual que en el servidor anterior:
Esto es lo que, básicamente, ejecuta el script Perl vmware-tools-config.pl (además de regenerar la imagen initrd).
¿Por qué en Debian no ocurre lo mismo? Al actualizar el kernel Linux no siempre es necesario reinstalar las VMware Tools.
Porque a diferencia de CentOS y derivados, en Debian existe un único directorio para cada rama del kernel Linux dentro de /lib/modules (hasta el cuarto número). Por ejemplo, mientras que en un sistema CentOS existen los siguientes directorios:
[root@centos ~]# ll /lib/modules total 20 drwxr-xr-x. 3 root root 4096 ago 7 2014 2.6.32-431.5.1.el6.x86_64 drwxr-xr-x 8 root root 4096 abr 20 09:57 2.6.32-504.12.2.el6.x86_64 drwxr-xr-x 8 root root 4096 ene 6 09:18 2.6.32-504.3.3.el6.x86_64 drwxr-xr-x 8 root root 4096 ene 29 09:01 2.6.32-504.8.1.el6.x86_64 drwxr-xr-x 7 root root 4096 nov 5 09:49 2.6.32-504.el6.x86_64
Es decir, cuatro directorios individuales para cada versión del kernel perteneciente a la rama 2.6.32-504.
En un sistema Debian existe un único directorio para la rama 2.6.32-5:
root@debian:~# ll /lib/modules/ total 20 drwxr-xr-x 3 root root 4096 nov 9 2012 . drwxr-xr-x 11 root root 12288 mar 10 07:53 .. drwxr-xr-x 4 root root 4096 feb 26 07:40 2.6.32-5-amd64
Cada vez que se actualiza a una nueva versión dentro de una misma rama, no es necesario reconfigurar los módulos ya que se detectan automáticamente, pues utiliza el mismo directorio. Solo será necesario reinstalar las VMware Tools al actualizar a una rama diferente (cosa poco probable al utilizar un kernel de la rama estable).
Por lo tanto, cada vez que se actualiza el kernel en un sistema CentOS, es necesario reconfigurar las VMware Tools, debido a esta cuestión particular de CentOS de utilizar un directorio nuevo para cada kernel.
Si se desea automatizar el proceso de reconfiguración de VMware Tools, es posible ejecutar el script Perl vmware-tools-config.pl de forma desatendida (respondiendo a todas las preguntas con la respuesta por defecto) utilizando el parámetro -d:
vmware-config-tools.pl -d
Espero que sea útil y les haya servido para comprender un poco cómo interactuan los diferentes componentes que hacen al funcionamiento de las VMware Tools en sistemas GNU/Linux.
Referencias
- VMware Tools fail to start after a Linux guest operating system kernel upgrade
- VMCI Overview
- VMware Tools Balloon
Fuente: linuxito
