La virtualización de plataformas se trata de compartir una plataforma entre dos o más sistemas operativos para lograr un uso más eficiente de los recursos. Sin embargo, una plataforma implica mucho más que un simple procesador y deben considerarse los otros elementos de importancia que la conforman, como el almacenamiento, las redes, y otros recursos de hardware. Algunos recursos de hardware, como el procesador o el almacenamiento, pueden virtualizarse con facilidad, pero éste no es el caso de otros recursos de hardware, como un adaptador de video o un puerto serial. Peripheral Component Interconnect (Interconexión de Componentes Periféricos - PCI) passthrough proporciona los medios para usar esos recursos de manera eficiente cuando no resulta posible o útil compartirlos. Este artículo estudia el concepto de passthrough, aborda su implementación en los hipervisores y detalla los hipervisores que soportan esta reciente innovación.
Emulación de dispositivos de plataformas
Antes de referirnos a passthrough, veamos cómo funciona la actual emulación de dispositivos en dos arquitecturas de hipervisor. La primera arquitectura incorpora la emulación de dispositivos dentro del hipervisor, mientras que la segunda inserta la emulación de dispositivos en una aplicación externa al hipervisor.
La emulación de dispositivos dentro del hipervisor es un método de uso común que se implementa dentro del producto VMware workstation (hipervisor basado en sistemas operativos). En este modelo, el hipervisor incluye emulaciones de dispositivos comunes para que compartan los diferentes sistemas operativos huéspedes, como discos virtuales, adaptadores de redes virtuales y otros elementos de plataforma necesarios. La Figura 1 muestra este modelo en particular.
Figura 1. Emulación de dispositivos basada en un hipervisor
La segunda arquitectura se denomina emulación de dispositivos en el espacio de usuario (ver Figura 2). Como su nombre lo indica, en lugar de que la emulación de dispositivos se incruste dentro del hipervisor, ésta se implementa en el espacio de usuario. QEMU (brinda tanto emulación de dispositivos como un hipervisor) proporciona emulación de dispositivos y puede ser usado por una gran cantidad de hipervisores independientes (dos de los tantos son: Kernel-based Virtual Machine [KVM] y VirtualBox). Este modelo es muy conveniente, ya que la emulación de dispositivos es independiente del hipervisor y, por consiguiente, puede compartirse entre hipervisores. El modelo también permite la emulación de dispositivos arbitrarios sin tener que cargar el hipervisor (el cual opera en estado privilegiado) con esta funcionalidad.
Figura 2. Emulación de dispositivos en el espacio de usuario
Insertar la emulación de dispositivos del hipervisor al espacio de usuario presenta una serie de ventajas evidentes. La más importante se relaciona con lo que se denomina la base segura de cómputo (TCB). La TCB de un sistema es el conjunto de todos los componentes esenciales para su seguridad. Como indica la lógica, si se minimiza un sistema, se reducirá la probabilidad de errores, y, por lo tanto, se obtendrá un sistema más seguro. Esta misma idea se aplica al hipervisor. La seguridad del hipervisor es crucial, debido a que éste aísla múltiples sistemas operativos huéspedes independientes. A menor cantidad de código en el hipervisor (insertando la emulación de dispositivos al espacio de usuario, el cual posee menos privilegios), habrá menor probabilidad de que se cuelen privilegios a usuarios no confiables.
Otra variante en la emulación de dispositivos basada en un hipervisor es la de drivers paravirtualizados. En este modelo, el hipervisor incluye los drivers físicos, mientras que cada sistema operativo huésped incluye un driver que reconoce al hipervisor y trabaja en combinación con los drivers de éste (denominados drivers paravirtualizados o PV).
Independientemente de si la emulación de dispositivos sucede en el hipervisor o en el nivel superior en una máquina virtual (VM) huésped, los métodos de emulación son similares. La emulación de dispositivos puede imitar a un dispositivo específico (por ejemplo, un adaptador de red Novell NE1000) o a un tipo de disco específico (por ejemplo, una unidad Integrated Device Electronics [IDE]). El hardware físico puede variar enormemente,—por ejemplo, mientras que una unidad IDE se emula a los sistemas operativos huéspedes, la plataforma de hardware físico puede usar una unidad serial ATA (SATA). Esto resulta muy útil porque una gran cantidad de sistemas operativos poseen soporte IDE y éste puede emplearse como denominador común para evitar que todos los sistemas operativos deban soportar tipos de unidades más avanzadas.
Como vimos en los dos modelos de emulación de dispositivos antes explicados, compartir dispositivos implica sacrificar otros aspectos. Tanto en la emulación de dispositivos en el hypervisor como en el espacio de usuario dentro de una VM independiente, existe una sobrecarga. Esta sobrecarga tiene sentido siempre que los dispositivos deban ser compartidos entre varios sistemas operativos huéspedes. Si éste no es el caso, existen otros métodos más efectivos para compartir dispositivos.
Entonces, en el nivel superior, el passthrough de dispositivos logra el aislamiento de los dispositivos en un sistema operativo determinado y, de esta manera, el dispositivo puede ser usado exclusivamente por ese huésped (ver Figura 3) ¿Pero qué utilidad tiene esto? Como era de esperarse, existen una serie de motivos que justifican el uso del passthrough de dispositivos. Dos de las principales razones son el rendimiento y la posibilidad de uso exclusivo de un dispositivo que no es compartible en su esencia.
Figura 3. Passthrough dentro del hipervisor
En lo que respecta al rendimiento, usando passthrough se puede lograr un rendimiento casi nativo. Esto resulta ideal para aplicaciones de redes (o aquellas que poseen una tasa elevada de E/S de disco) que no han adoptado la virtualización debido al deterioro de la contención y el rendimiento que se genera a través del hipervisor (hacia un driver del hipervisor o a través del hipervisor hacia una emulación en el espacio de usuario). Sin embargo, la asignación de dispositivos a huéspedes específicos también resulta útil cuando dichos dispositivos no pueden compartirse. Por ejemplo, si un sistema incluyera adaptadores de video múltiples, esos adaptadores podrían transferirse a dominios de huéspedes únicos.
Por último, puede haber dispositivos PCI especializados que un solo dominio huésped use, o dispositivos que el hipervisor no soporta y por lo tanto deben transferirse al huésped. Los puertos USB individuales podrían aislarse a un dominio determinado o un puerto serial específico (que en sí no es compartible) podría aislarse a un huésped en particular.
Tras bambalinas de la emulación de dispositivos
Las formas iniciales de emulación de dispositivos implementaban sombras de interfaces de dispositivos en el hipervisor para proporcionar al sistema operativo huésped una interfaz virtual al hardware. Esta interfaz virtual estaba formada por la interfaz esperada e incluía un espacio de direcciones virtual que representaba al dispositivo (por ejemplo: PCI sombra) y la interrupción virtual. Sin embargo, como este sistema implicaba que un driver de dispositivo se comunicara con un interfaz virtual y que luego el hipervisor tradujera esta comunicación al hardware real, se generaba una sobrecarga considerable,— en especial en casos de dispositivos de gran ancho de banda, como los adaptadores de red.
Xen generalizó el enfoque PV (explicado en la sección anterior), el cual logró reducir el deterioro del rendimiento haciendo que el driver del sistema operativo huésped reconociera que estaba siendo virtualizado. En este caso, el sistema operativo huésped no veía un espacio PCI para el dispositivo (por ejemplo, para un adaptador de red), sino una Interfaz de Programación de Aplicaciones (API) que proporcionaba abstracción más elevada (como una interfaz de paquetes). La desventaja de este enfoque fue que el sistema operativo huésped debía modificarse para PV. La ventaja se centró en que, en algunos casos, se podía lograr rendimiento casi nativo.
Las versiones iniciales de passthrough de dispositivos usaban un modelo de emulación ligero, en el que el hipervisor proporcionaba gestión de memoria basada en software (traduciendo el espacio de direcciones de los sistemas operativos huéspedes a espacio de direcciones de host confiable). Si bien las versiones iniciales proporcionaban los medios para aislar un dispositivo para un sistema operativo huésped en particular, el enfoque carecía de la escalabilidad y el rendimiento requeridos por los entornos de virtualización de gran tamaño. Afortunadamente, los proveedores de procesadores han equipado a los procesadores de avanzada con instrucciones para el soporte a hipervisores y lógica para passthrough de dispositivos mediante la inclusión del soporte a la virtualización de interrupciones y al acceso directo a memoria (DMA). Es decir que, en lugar de captar y emular el acceso a los dispositivos físicos por debajo del hipervisor, los nuevos procesadores proporcionan traducción de direcciones DMA y verificación de permisos para un passthrough de dispositivos más eficiente.
Soporte de hardware para passthrough de dispositivos
Tanto Intel como AMD proporcionan soporte para passthrough de dispositivos en sus arquitecturas de procesadores más nuevas (además de nuevas instrucciones que asisten al hipervisor). Intel dio a esta opción el nombre de Virtualization Technology for Directed I/O (VT-d), mientras que AMD la llama I/O Memory Management Unit (IOMMU). En ambos casos, las nuevas CPU proporcionan los medios para mapear direcciones físicas PCI a direcciones virtuales huéspedes. Durante este mapeo, el hardware se ocupa del acceso (y de la protección) y el sistema operativo huésped puede usar el dispositivo como si se tratase de un sistema no virtualizado. Además de mapear al huésped a la memoria física, el aislamiento se proporciona de manera tal que otros huéspedes (o el hipervisor) quedan excluidos de su acceso. Las CPU de Intel y AMD brindan funcionalidad de virtualización mucho más amplia que la aquí explicada. Obtenga más información en la sección de Recursos.
Otra innovación que ayuda a las interrupciones a escalar a mayor cantidad de máquinas virtuales se denomina Interrupciones Señalizadas por Mensajes (Message Signaled Interrupts - MSI). En lugar de depender de pins de interrupción física que se asocian con un huésped, MSI transforma a las interrupciones en mensajes que se virtualizan más fácilmente (y escalan a miles de interrupciones individuales). MSI se introdujo desde la versión 2.2 de PCI pero también se encuentra disponible en PCI Express (PCIe) y, en éste último, permite un escalamiento de las tramas a varios dispositivos. MSI es ideal para la virtualización de E/S, ya que permite el aislamiento de las fuentes de interrupciones (a diferencia de los pins físicos que deben multiplexarse o rutearse a través de software).
Soporte de passthrough de dispositivos en hipervisores
Mediante las últimas arquitecturas de procesadores mejoradas para la virtualización,
algunas soluciones de hipervisores y virtualización soportan passthrough de
dispositivos. Encontrará soporte de passthrough de dispositivos (usando VT-d o
IOMMU) en Xen y KVM, así como también en otros hypervisores. En la mayoría de los
casos, el sistema operativo huésped (dominio 0) debe estar compilado para soportar
passthrough, lo cual se presenta como una opción al momento de construcción del
kernel. También podría requerirse la capacidad de ocultar los dispositivos de la VM
host (como lo hace el comando pciback en Xen). PCI posee
algunas restricciones (por ejemplo, los dispositivos PCI detrás de un puente PCIe a
PCI se deben asignar al mismo dominio), que en PCIe no existen.
Además, en libvirt (junto con virsh), encontrará soporte de configuración para passthrough de dispositivos y una abstracción de los esquemas de configuración usados por los hipervisores subyacentes.
Problemas con el passthrough de dispositivos
Uno de los problemas del passthrough de dispositivos surge cuando se necesita realizar migración en vivo. La migración en vivo es la suspensión y subsiguiente migración de una VM a un nuevo host físico, momento en el cual la VM se reinicia. Esta es una característica excelente para soportar el equilibro de cargas de máquinas virtuales en una red de hosts físicos, pero presenta un problema cuando se usan dispositivos passthrough. El hotplug de PCI (del que existen varias especificaciones) es un aspecto que debe ser tomado en cuenta. El hotplug de PCI permite a los dispositivos PCI ir y volver de un determinado kernel, lo cual resulta ideal —, especialmente cuando se evalúa la migración de una VM a un hipervisor de una nueva máquina host (los dispositivos deben desconectarse y luego volverse a conectar al nuevo hipervisor). Cuando se emulan dispositivos, como, por ejemplo, adaptadores de red virtuales, la emulación proporciona un nivel para abstraer el hardware físico. De esta manera, se logra que un adaptador de red virtual migre fácilmente dentro de la VM (también soportado por el driver de conexión de Linux®, el cual permite que varios adaptadores de redes lógicas se conecten a la misma interfaz).
Próximos pasos en la virtualización de E/S
Los próximos pasos en la virtualización de E/S ya se están aplicando en la actualidad. Como ejemplo, PCIe ya incluye soporte para virtualización. Un concepto de virtualización ideal para la virtualización de servidores se denomina Single-Root I/O Virtualization (SR-IOV). Esta tecnología de virtualización (creada a través del PCI-Special Interest Group o PCI-SIG) proporciona virtualización de dispositivos en instancias complejas de root única (en este caso, un único servidor con varias máquinas virtuales que comparten un dispositivo). Otra variante se llama Multi-Root IOV y soporta topologías de mayor tamaño (como servidores blade) en las que varios servidores pueden acceder a uno o más dispositivos PCIe. En cierto sentido, esto posibilita la existencia de redes de dispositivos arbitrariamente grandes que incluyan servidores, dispositivos finales y switches (que se completan con detección de dispositivos y ruteo de paquetes).
Con SR-IOV, un dispositivo PCIe puede exportar no sólo una serie de funciones físicas PCI, sino también un conjunto de funciones virtuales que comparten recursos en el dispositivo de E/S. La Figura 4 muestra una arquitectura de virtualización de servidores simplificada. En este modelo, no se requiere de passthrough, ya que la virtualización se da en el dispositivo final, lo cual permite al hipervisor simplemente mapear las funciones virtuales a las máquinas virtuales y logra un rendimiento de dispositivo nativo con la seguridad que proporciona el aislamiento.
Figura 4. Passthrough con SR-IOV
La virtualización se encuentra en desarrollo desde hace alrededor de 50 años, pero recién hoy la vitualización de E/S está recibiendo atención generalizada. Los procesadores comerciales soportan la virtualización desde hace apenas cinco años. Básicamente, nos encontramos a punto de presenciar lo que vendrá en términos de virtualización de E/S. La virtualización, como la computación en nube, es un elemento clave de las arquitecturas del futuro y una tecnología cuya evolución resultará realmente interesante observar. Como de costumbre, Linux está en la vanguardia en el soporte de estas nuevas arquitecturas y sus kernels más recientes (2.6.27 y posteriores) han comenzado a incluir soporte de estas nuevas tecnologías de virtualización.
Aprender
- El instructivo VTdHowTo wiki proporciona
detalles acerca de Xen con VT-d para passthrough de dispositivos. Xen proporciona
una gran cantidad de información en su sitio.
- El Grupo de usuarios Waikato Linux proporciona algunos detalles acerca de la
habilitación de PCI passthrough para el hipervisor Xen.
- Libvirt proporciona una API de gestión para la construcción de aplicaciones de
gestión de hipervisores. Este wiki del sitio Web de libvirt incluye un artículo
acerca de los aspectos necesarios para una migración de máquinas
virtuales entre hipervisores.
- En este documento
de Intel del proyecto Fedora, el tema de la migración en vivo de una VM Linux
se trata en el contexto del passthrough de dispositivos.
- En el sitio Web de PCI-SIG,
descargue las especificaciones de las tecnologías Single-Root y Multi-Root IOV. Se
proporciona virtualización de E/S en topologías de root única (un único host) o de
raíz múltiple (hosts múltiples, como en el servidor blade). Estas tecnologías son
producto de PCI-SIG.
- Lea " Virtual Linux " (developerWorks,
diciembre 2006) y conozca otras soluciones de virtualización. También puede
profundizar en KVM y QEMU en " Discover the Linux Kernel Virtual
Machine " (developerWorks, abril 2007) y " System emulation with QEMU "
(developerWorks, septiembre 2007).
- En la Zona Linux de developerWorks , encuentre
más recursos para desarrolladores Linux y dé una mirada a los artículos y tutoriales más
populares.
- Encuentre todos los consejos de Linux y tutoriales Linux en
developerWorks.
- Manténgase al día con los eventos técnicos y las transmisiones por
Internet de developerWorks .
Obtener los productos y tecnologías
- Con El software de prueba de IBM, disponible
para su descarga directa desde developerWorks, construya su próximo proyecto de
desarrollo en Linux.
Comentar
- Participe en la comunidad My developerWorks ; con un
perfil personal y una página principal personalizada, puede ajustar developerWorks a
sus intereses e interactuar con otros usuarios de developerWorks.

M. Tim Jones is an embedded firmware architect and the author of Artificial Intelligence: A Systems Approach, GNU/Linux Application Programming (now in its second edition), AI Application Programming (in its second edition), and BSD Sockets Programming from a Multilanguage Perspective. His engineering background ranges from the development of kernels for geosynchronous spacecraft to embedded systems architecture and networking protocols development. Tim is a Consultant Engineer for Emulex Corp. in Longmont, Colorado.