Como una continuación del artículo Cómo contribuir al kernel de Linux, en esta entrada voy a entrar en materia para explicar de qué manera en Qindel Group identificamos el problema que dio lugar a la necesidad de contribuir al kernel de Linux.
¿Cómo encontrar un problema en el kernel?
Quiero empezar explicando que la base para hacer una contribución al kernel es encontrar un problema o una necesidad no cubierta. Puede parecer sencillo, pero es la parte más difícil tomando en cuenta el gran número de programadores con experiencia trabajando de manera constante revisando el código, arreglando bugs.
Pero ¿cómo saben ellos dónde buscar? ¿Cómo hacen esos programadores con experiencia para encontrar problemas en el kernel? La respuesta es que esos programadores no buscan los problemas, se topan con ellos. Un buen día estás trabajando, estás haciendo algo nuevo y no funciona como tú crees que debería… O más habitual, un día actualizas el kernel a una versión más moderna, y algo que solías hacer con tranquilidad no funciona, y suelta una ristra larguísima en el log de sistema que incluye algo como KERNEL BUG.
En definitiva, la forma más habitual de encontrar un problema en las fuentes del kernel no es buscando errores de manera intencionada, lo más normal es encontrarlo mientras trabajas en el desarrollo de algún producto o solución que haga uso del kernel. Y eso nos pasó aquí, en Qindel Group, mientras trabajaba en el desarrollo de nuestro producto de virtualización de escritorios y aplicaciones Linux QVD encontré un problema en el kernel que me impedía avanzar en mi trabajo.
A continuación, haré un repaso rápido a la capacidad de QVD que dio lugar a la contribución:
Dispositivos USB en QVD
Una de las capacidades de la solución VDI QVD, es la redirección de dispositivos USB. Esto es, el usuario que arranca su Cliente de QVD, dispuesto a trabajar en su escritorio remoto, puede conectar al mismo tiempo su unidad flash, lector de huellas dactilares u otro dispositivo USB y conectarlo de manera remota a su escritorio virtual.
A través de la ventana de dispositivos USB de QVD el usuario puede conectar sus dispositivos de manera más rápida, solo tiene que elegirlos y hacer clic en Conectar.
Este es un resumen de los pasos:
Conectar lector de huellas al USB (o cualquier otro dispositivo)
Arrancar cliente de QVD
En la pestaña de preferencias, marcar el lector de huellas para compartir.
Volver a la pestaña principal, rellenar nuestro usuario y contraseña y clic en Conectar
Cuando aparece nuestro escritorio virtual, acceder a la aplicación de nuestra empresa y usar el lector de huellas como si nada.
QVD simplifica la redirección de dispositivos USB, sin necesidad de repetir los mismos pasos para conectar cada dispositivo.
Una mirada a QVD entre bastidores
¿Cómo funciona esto?
QVD es un producto de código abierto, y como tal, al código abierto se ciñe: USB/IP, una característica del kernel de Linux, que permite hacer muy literalmente lo que su nombre indica, conectar dispositivos USB a través de conexiones IP. Enchufar un dispositivo USB a la máquina A, y mandarlo por red a la máquina B para usarlo como si en B estuviera conectado.
Sin profundizar mucho, el funcionamiento de esta tecnología es sencillo de explicar. Tenemos dos lados:
Lado servidor: en este lado es donde se conectan físicamente los dispositivos USB. Se cuenta en este lado con un driver de USB/IP que se llama usbip_host, y un ejecutable: usbipd.
Lado cliente: en este lado es donde se desea conectar remotamente los dispositivos USB. El driver de este lado se llama vhci_hcd.
En ambos lados se cuenta con otro ejecutable: usbip, que permite controlar ambos drivers. Los pasos básicos para utilizar estas herramientas serían:
Cargar el driver apropiado a cada lado.
Ejecutar usbipd en el lado servidor.
Utilizar el otro ejecutable, usbip, para asignar un dispositivo USB al driver usbip_host.
Desde el otro lado, usar usbip para realizar la conexión.
Cuando seguimos estos pasos, por debajo estamos desconectando el dispositivo de su driver habitual (el driver del lector de huellas, p.ej.), y conectándolo al driver usbip_host. Al realizar la conexión desde el otro lado, lo que hacemos es un túnel IP, que comunica el dispositivo con el driver vhci_hcd del lado cliente, que literalmente es un hub USB virtual. Este hub virtual pone a disposición del kernel de este lado el dispositivo como si fuera un dispositivo físico conectado de manera local.
Si nuestro ancho de banda y tiempo de latencia cumple con las necesidades del lector de huellas, todo funciona correctamente.
Necesidad que dio lugar a la contribución
QVD utiliza USB/IP para conectar dispositivos USB desde el lado del usuario a la máquina virtual que contiene su escritorio. Pero este sistema solo se puede usar cuando QVD utiliza como virtualizador KVM, no con LXC.
Para los lectores que acaban de perderse un poco, aclarar que KVM y LXC son dos sistemas de virtualización, lo que significa que permiten crear múltiples máquinas virtuales dentro de una máquina física. La solución de virtualización QVD permite utilizar tanto KVM como LXC como tecnología de virtualización.
A modo de resumen, KVM es un virtualizador completo: cada máquina virtual que se crea ve su propio hardware virtual, tiene su propio kernel y su propio software. LXC es una solución de contenedores: las máquinas virtuales que se crean tan solo tienen su propio software, y tanto el kernel como el hardware, se comparten con la máquina física y con el resto de las máquinas virtuales (que en este caso llamaremos contenedores).
KVM -> un kernel por máquina virtual
LXC -> un kernel para todas las máquinas virtuales
USB/IP -> un hub virtual … por kernel
Cuando usamos contenedores LXC, y al haber un único kernel en juego, tenemos un único hub virtual, con un número muy pequeño de puertos (16) para conectar dispositivos USB. Un único hub para todos los contenedores LXC, esto es, para todos los escritorios de los usuarios que se conectan a una máquina física. Teniendo en cuenta la alta densidad de escritorios que permite alcanzar QVD cuando el hipervisor que se usa es LXC (que puede ser de hasta 400 escritorios por servidor), un único hub virtual es insuficiente.