Page 40
__rendered_path__1
GNUFDL PID_00174426
40
El núcleo Linux
La carga general de módulos, en función del momento y la forma, puede ha-
cerse manualmente, como hemoscomentado, medianteinitrd/initramfs
o por medio deudev.
En el caso de initrd/initramfs, cuando el sistema arranca, se necesitan
inmediatamente algunos módulos, para acceder al dispositivo y al sistema de
ficheros raíz del sistema, por ejemplo controladores específicos de disco o ti-
pos de sistemas de ficheros. Estos módulos, necesarios se cargan mediante un
sistema de ficheros especial en RAM denominado initrd/initramfs. De-
pendiendo de la distribución GNU/Linux se utilizan estos términos de forma
indiferente, aunque en algunos casos se han producido cambios a lo largo de
la vida de la distribución. Por convención, suele denominarse a este elemento
como filesystem RAM inicial, y se le refiere comunmente comoinitramfs.
El sistema inicial de ficheros en RAM, initramfs, es cargado por el bootloa-
der en la especificación de la entrada correspondiente a la carga del núcleo
correspondiente (por ejemplo en la línea/opcióninitrd de la entrada corres-
pondiente de Grub).
En la mayoría de distribuciones, ya sea con el núcleo distribuido originalmen-
te o bien con nuestra configuración del núcleo, suele crearse un initramfs
inicial. En todo caso, si dependiendo de la distribución no se produce (pue-
de no ser necesario), entonces podemos crearlo y sintonizarlo manualmen-
te. El comando mkinitramfs permite crearlo a partir de sus opciones ge-
néricas, que no suelen cambiarse y que se pueden configurar en el archivo
/etc/initramfs-tools/initramfs.conf y, específicamente, losmódulos
que se cargarán en inicio automáticamente, que podemos encontrarlos en
/etc/initramfs-tools/modules.
Un mkinitramfs -o new_initrd_file nos permitirá crearlo, y normal-
mentepodemosproceder a copiarlo en el directorio/boot para hacerlo accesi-
ble al bootloader usado. Por ejemplo, mediante un cambio en Grub de su fiche-
ro de configuración/boot/grub/menu.lst, modificando la línea deinitrd
oportuna. En cualquier caso, siempre esinteresante establecer en el bootloader
una configuración alternativa de text durante estas pruebas, para poder reini-
ciar y probar la nueva configuración, pero de la misma manera mantener la
configuración estable antigua.
Durante el proceso de arranque, además del initramfs necesario para el
arranque inicial, se producirá también la carga del resto de módulospor detec-
ción automática. Si no se carga algún módulo deseado siempre puede forzarse
su carga al incluir su nombre implícitamente en el fichero de configuración
/etc/modules.
También puededarseo desearseel caso contrario: evitar la carga deun módulo
quepuededetectarseerróneamenteo para el queexistemásdeuna alternativa
posible. En este caso se utilizan técnicas de listas negras de módulos (típica-
mente la lista negra se guarda en/etc/modprobe.d/blacklist.conf).

Page 41
__rendered_path__1
GNUFDL PID_00174426
41
El núcleo Linux
5.1. DKM S: m ódulos r ecom pilados dinám icam ent e
Respecto a los módulos dinámicos, un problema clásico ha sido la recompi-
lación de estos frente a nuevas versiones del núcleo. Los módulos dinámicos
de terceros, no incluidos a priori en el núcleo, necesitan de código fuente para
compilarse, proporcionado por la comunidad o por el fabricante del hardware
del dispositivo.
Durante la compilación, normalmente es necesario disponer de los paquetes
de desarrollo del núcleo, de los paquetes del código fuente del núcleo y de
sus headers para desarrollo, con la misma numeración que el núcleo usado ac-
tualmente, para el que se quiere compilar el módulo. Este hecho obliga a una
recompilación constante con el cambio de versiones del núcleo del sistema,
en especial ahora que lasdistribucionesdistribuyen revisionesdel núcleo con
un menor tiempo, ya sea para solventar potencialesproblemasde seguridad o
para corregir errores detectados.
Algunas distribuciones, para minimizar esta problemática, distribuyen un en-
torno denominado DKMS, que permite facilitar la recompilación automática
de un módulo con los cambios de versión del núcleo. Esto normalmente se
produce en arranque al detectar un numero de núcleo: todos los módulos de
terceros registrados por el sistema DKMS se recompilan a partir de los archi-
vosfuente de losmódulosy de losarchivosfuente o headers del núcleo nuevo.
De esta manera el proceso total es transparente al usuario. Una vez realizado
este proceso, el sistema o el usuario mediante comandos de manipulación de
módulos (comomodprobe), pueden utilizar directamente el nuevo módulo.
Algunas distribuciones ofrecen solo el paquete base (dkms) del sistema, en
algunas se proporcionan paquetes dkms preparados para módulos concretos,
o incluso el fabricante puede ofrecer su módulo con soporte dkms.
El proceso habitualmente pasa por los siguientes pasos:
1) Obtener los archivos fuente del módulo (un paquete o un archivo TGZ
suele ser lo más normal).
2) Instalar los paquetes necesarios para el proceso: dkms, kernel-source,
kernel-headers (los nombres dependen de la distribución, y en el caso de
los paquetes fuente del núcleo, hay que tener en cuenta que sean las versio-
nes asociados a la versión del núcleo actual para la que se quiere instalar el
módulo).
3) Activar el servicio DKMS en arranque. Habitualmente el servicio es deno-
minadodkms_autoinstaller
4) Crear un directorio en /usr/src para los paquetes fuente del módulo y
colocarlos allí.

Page 42
__rendered_path__1
GNUFDL PID_00174426
42
El núcleo Linux
5) Crear un ficherodkms.conf en el directorio anterior, que le especifica co-
mo construir (compilar) e instalar el módulo.
6) Añadir el servicio a la base de datos DKMS, compilarlo e instalar, normal-
mente con unos comandos:
dkms add -m nombre-modulo -v numero-version-modulo
dkms build -m nombre-modulo -v numero-version-modulo
dkms install -m nombre-modulo -v numero-version-modulo
Respecto al fichero dkms.conf mencionado, podría ser como sigue (donde
nombre-modulo es el nombre del módulo y version, el código numérico
de su versión):
#
# /usr/src/nombre-modulo/dkms.conf
#
PACKAGE_NAME="nombre-modulo"
PACKAGE_VERSION="version"
CLEAN="make clean"
MAKE[0]="make module"
BUILD_MODULE_NAME[0]="nombre-modulo"
DEST_MODULE_LOCATION[0]="/kernel/drivers/video"
AUTOINSTALL="yes"
# End Of File
En este caso tenemos ubicados los paquetes fuente del módulo en un directo-
rio /usr/src/nombre-modulo donde ponemos este fichero dkms.conf. La
opción MAKE da los pasos para compilar y construir el módulo, previamente
limpiados con CLEAN. BUILD_MODULE_NAME establece el nombre del módu-
lo construido (cuidado en este punto porque depende del sistema de com-
pilación y puede coincidir con el nombre del módulo general o no, algunos
paquetes fuente permiten construir varios controladores/módulos diferentes,
con diferente denominación).
DEST_MODULE_LOCATION definedondeseinstalara el módulo final en el árbol
asociado al núcleo, en este caso suponemos que es un controlador de vídeo,
(recordad que la raíz está en /lib/modules/version-kernel, lo que se co-
loca aquí es a partir de esta raíz). AUTOINSTALL permite que se reconstruya
automáticamente el módulo durante cambios del núcleo actual.
En los casos de
CLEAN,MAKE,BUILD_MODULE_NAME yDEST_MODULE_LOCATION

Page 43
GNUFDL PID_00174426
43
se recomienda consultar el fichero de explicación (normalmente un README
o INSTALL) que acompaña a los paquetes fuentes de los módulos, ya que
pueden ser necesarios comandos adicionales, o tener que modificarlos para
que se compile y se instale correctamente el módulo.
__rendered_path__1
El núcleo Linux

Page 44
__rendered_path__1
GNUFDL PID_00174426
44
El núcleo Linux
6. V ir t ualización en el núcleo
.
Una de las áreas en expansión, en la administración de IT, es la virtualización
de sistemas. GNU/Linux ha ido con el tiempo incorporando diferentes posi-
bilidades provenientes tanto de soluciones comerciales, como de diferentes
proyectos de código abierto.
La virtualización de sistemas es un recurso básico actual en las empresas y
organizaciones para mejorar su administración de sistemas, disminuir costes
y aprovechar los recursos de hardware de manera más eficiente.
En general, en el pasado si necesitábamos varias instancias de uno (o más)
sistemas operativos, teníamos que adquirir un servidor para cada instancia a
implantar. La corriente actual es comprar servidores mucho más potentes y
utilizar virtualización en estos servidores para implantar los diferentes siste-
mas en desarrollo o producción.
Normalmente, en virtualización disponemos de un sistema operativo insta-
lado (que habitualmente se denomina sistema host) y una serie de máquinas
virtuales sobre este sistema (denominados sistemas guest). Aunque también
hay solucionesque sustituyen al sistema operativo host por una capa denomi-
nada hypervisor.
La virtualización como solución nospermite optimizar el uso de nuestrosser-
vidores o bien, por ejemplo en el caso de escritorio, disponer de máquinas de
test de otros sistemas operativos conviviendo en la misma máquina simultá-
neamente. En el caso de GNU/Linux disponemosde múltiplessolucionesque
permiten tanto un caso como el otro. También podemos disponer tanto de
GNU/Linux como sistema host que aloja máquinas virtuales, como utilizarlo
como máquina virtual sobre otro sistema diferente o bien sobre otro sistema
host también GNU/Linux. Un esquema, este último, particularmente útil en
el caso de administración porque nos permitirá, por ejemplo, examinar y eje-
cutar diferentesdistribucionesGNU/Linux sobre un mismo sistema host base.
Existen muchas soluciones de virtualización, pero por mencionar algunas de
las más populares en sistemas GNU/Linux, disponemos (ordenamos de más a
menos en relación directa con el núcleo):
KVM
Xen
OpenVZ

Page 45
__rendered_path__1
GNUFDL PID_00174426
45
El núcleo Linux
__rendered_path__11
VirtualBox
__rendered_path__12__rendered_path__13
VMware
__rendered_path__12
VMware es uno de los líderes comerciales en soluciones de virtualización, y
__rendered_path__11
Enlace de int er és
__rendered_path__15
dispone de productosde virtualización para escritorio (VMware Workstation),
__rendered_path__16__rendered_path__17
mientras que para servidor dispone de un producto VMware Server que está
Podéis visitar la web de
__rendered_path__16
VMware en:
__rendered_path__15
disponible para Linux para descarga gratuita. El caso de servidor permite ges-
http://www.vmware.com
tionar varias máquinas virtuales con un interfaz de gestión simple. Otra línea
de producto VMware ESX implementa necesidades mayores para centros de
datos (data centers), con gestión elaborada de máquinas, tolerancia a fallos,
migraciones y otras necesidades explícitas para centros de datos.
Sun/Oracle VirtualBox ofrece virtualización orientada a escritorio, que nos
permite una opción bastante sencilla para probar máquinas con diferentes
sistemas operativos. Dispone de versión de código libre utilizable en gran nú-
mero de distribuciones GNU/Linux.
OpenVZ esuna solución de virtualización que utiliza el concepto de contene-
dor de máquina virtual. Así el host arranca con un núcleo común a lasmáqui-
nas virtuales (existen paquetes de imágenes de núcleo con soporte OpenVZ
integrado en las distribuciones, como por ejemplo en Debian), que permite
arrancar máquinas con el núcleo en común pero cada una dentro de un en-
torno aislado del resto. OpenVZ solo permite máquinas virtuales guest Linux
(debido al núcleo compartido).
Xen usa el concepto de hypervisor, utilizando un tipo de virtualización deno-
minada paravirtualización, en la que se elimina el concepto de host-guest y se
delega a la capa de hypervisor la gestión de los recursos físicos de la máqui-
na, de manera que permita el máximo acceso a los recursos de hardware por
parte de las máquinas virtuales. En estos casos se necesitan núcleos sintoni-
zados que puedan beneficiarse de las posibilidades de la paravirtualización.
En el caso de GNU/Linux en la mayoría de distribuciones se ofrecen núcleos
optimizados para Xen (véase el caso de Debian, para el que existen imágenes
binarias para xen de los núcleos). En general, la paravirtualización y la capa
de hypervisor para acceder al hardware aprovechan las facilidades de las CPU
actuales, con recursos de hardware dedicados a facilitar la virtualización. Si se
dispone de las características se pueden usar sistemas como Xen, sino, puede
utilizarse un sistema más clásico de host-guest como por ejemplo VirtualBox.
En general, para ver si la CPU dispone de soporte de virtualización, hay que
examinar sus datos en /proc/cpuinfo, en concreto el flag VMX, para proce-
sadores Intel, que puede verse en la secciónflags:
$ cat /proc/cpuinfo
processor
: 0
vendor_id
: GenuineIntel

Page 46
__rendered_path__1
GNUFDL PID_00174426
46
El núcleo Linux
__rendered_path__32
cpu family
: 6
__rendered_path__33__rendered_path__34
model
: 23
__rendered_path__33
model name
: Intel(R) Xeon(R) CPU E5405 @ 2.00GHz
__rendered_path__32
stepping
: 10
__rendered_path__36
cpu MHz
: 1994.999
__rendered_path__37__rendered_path__38
cache size
: 6144 KB
__rendered_path__37
physical id
: 0
__rendered_path__36
siblings
: 4
core id
: 0
cpu cores
: 4
apicid
: 0
fpu
: yes
fpu_exception : yes
cpuid level
: 13
wp
: yes
flags
: fpu vme de pse tsc msr pae mce cx8 apic sep
mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2
ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl
vmx tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
bogomips
: 3989.99
clflush size : 64
cache_alignment : 64
address sizes : 38 bits physical, 48 bits virtual
power management:
6.1. KV M
Finalmente, la solución en que nos centraremos en este subapartado, KVM ,
Enlace de int er és
está presente desde el núcleo 2.6.20, como solución incluida para la virtuali-
zación de sistemas. Es una solución parecida a Xen, pero con diferencias en
Podéis acceder a la web de
KVM en:
cuanto a la implementación. Xen es un producto complejo, con diferentes
http://www.linux-kvm.org
capas y, en especial, su diseño de capa hipervisora. Por contra, KVM se imple-
menta como un módulo del núcleo existente, que se complementa con otras
soluciones. Es la opción por defecto para virtualización en distribuciones co-
mo Debian y Fedora.
Normalmente una solución de virtualización basada en KVM se compone de
una mezcla de:
El módulo de núcleo kvm.ko, que proporciona la infraestructura base de
virtualización, y además un módulo adicional según el modelo de proce-
sadorkvm-intel.ko okvm-amd.ko. Estosmódulosdeberán cargarse ma-
nualmente (modprobe) o habilitarlosdurante el arranque para disponer de
soporte de virtualización KVM.

Page 47
GNUFDL PID_00174426
47
Qemu, un simulador cruzado de arquitecturas de CPU, que nos permite
simular una CPU virtual sobre otra de igual o diferente arquitectura real.
KVM utiliza una versión modificada de Qemu para la gestión y creación
de las máquinas guest (este paquete suele aparecer como qemu-kvm en las
distribuciones).
La biblioteca libvirt, que es una API que permite una gestión de la vir-
tualización independiente del sistema de virtualización usado (sea Xen,
KVM u otros).
Utilidadesbasadasenlibvirt para la creación delasVM guest y su mante-
nimiento, como virt-manager una interfaz gráfica de gestión de máqui-
nas virtuales (figura 4), virt-install, una utilidad de línea para la ges-
tión de máquinas virtuales, o virtsh, un shell basado en comandos de
gestión de las máquinas virtuales. Estas utilidades suelen necesitar un ser-
vicio de sistema, denominadolibvirtd. Tenemosque asegurarnosde po-
ner en marcha el servicio (/etc/init.d/libvirtd start) o bien de car-
garlo al inicio.
Figura 4.Virt-manager durante la instalación de una máquina virtual
Image_370_0
A continuación veremoslosprocesosbásicosasociadosa la utilización deKVM
y describiremos algunas de las fases de la instalación de KVM y la puesta en
marcha de algunas máquinas virtuales.
Para comenzar debemos examinar si disponemos de soporte de harwdare en
la CPU: como hemos comentado buscamos el flag vmx en /proc/cpuinfo
(para procesadores Intel) o el flag svm para procesadores AMD. Por ejemplo,
con (sustituirvmx porsvm en AMD):
grep vmx /proc/cpuinfo
__rendered_path__1
El núcleo Linux
__rendered_path__55
Soporte de virtualización
__rendered_path__56__rendered_path__57
Hay que tener cuidado con el
__rendered_path__56
hecho de que muchasde las
__rendered_path__55
máquinasactualespermiten
__rendered_path__59
desactivar/activar en BIOS el
__rendered_path__60
soporte de virtualización;
__rendered_path__60
comprobemosprimero que
__rendered_path__59
no esté desactivado.