Memoria TFG

Facultad de Informática
Trabajo fin de grado
Grado en Ingenierı́a Informática

Tecnologı́as de la Información y las Comunicaciones
Implementación de una solución VDI para

escritorios Linux en la Universidade da Coruña
Autor: Xacobe Macı́a da Silva

Director profesional: Antonio Daniel López Rivas
Director académico: Francisco Javier Nóvoa de Manuel
A Coruña, a 24 de septiembre de 2014

Copyright (C) 2014 XACOBE MACÍA DA SILVA.
Permission is granted to copy, distribute and/or modify this document

under the terms of the GNU Free Documentation License, Version 1.3 or any
later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled ‘‘GNU Free Documentation License’’.
D. A. Daniel López Rivas D. Fco J. Nóvoa de Manuel
Técnico de Sistemas Profesor Ayudante Doctor
Universidade da Coruña Universidade da Coruña
CERTIFICAN:
Que la memoria titulada “Implementación de una solución VDI para escritorios

Linux en la Universidade da Coruña” ha sido realizada por Xacobe Macı́a da Silva
bajo nuestra dirección en la Universidade da Coruña y concluye el proyecto que presenta
para optar al Grado en Ingenierı́a Informática.
A Coruña, 24 de septiembre de 2014
D. A. Daniel López Rivas D. Fco. J. Nóvoa de Manuel

Director profesional Director académico
A mis abuelos, a los que están y a los que no;
por todas las historias que me habéis contado
y por las que os quedan por contar.

Agradecimientos
Mis primeras palabras de agradecimiento no pueden ser a otras personas que no

sean mis tutores Daniel y Fran. Gracias por vuestro tiempo, paciencia e interés, por
vuestra amabilidad y tranquilad, por vuestras enseñanzas, por permitirme realizar este
proyecto y sobre todo, por darme la oportunidad de conoceros.
Unas breves lı́neas no son ni serán nunca suficientes para agradecer a las dos perso-
nas más importantes en mi vida, mis padres. Padres buenos hay muchos, pero buenos
padres sólo vosotros. Gracias.
A una persona muy especial, por haber sido y seguir siendo mi compañera de viaje
durante estos años, por animarme y comprenderme siempre. Gracias Judit.
Por último y no menos importante, gracias a todas esas personas que conocı́ y
compartieron conmigo todos estos años de facultad, hoy grandes amigos. Gracias haber
compartido y seguir compartiendo una parte de vosotros conmigo.
De verdad, gracias.
Xacobe Macı́a da Silva
A Coruña, a 24 de septiembre de 2014

Resumen
Desde hace años, el entorno tradicional de las redes corporativas se ha desarro-

llado sobre una infraestructura en la que cada usuario poseı́a su propio ordenador,
totalmente dedicado y conectado a la red. Todos los usuarios y dispositivos eran ad-
ministrados por el personal TI, necesario para gestionar las diferentes configuraciones,
licencias y actualizaciones de cada equipo. Se trata de un modelo que ha funcionado
correctamente durante décadas, pero con altos costes de mantenimiento, grandes ciclos
de configuración y puesta en funcionamiento y vulnerabilidades en la seguridad. Todos
estos factores impulsan a las organizaciones a considerar soluciones informáticas más
sencillas, autónomas, eficientes y seguras.
Es en este marco donde encajan a la perfección las infraestructuras de escritorios

virtuales (Virtual Desktop Infraestructure, VDI) que hace referencia al uso de “equipos
de escritorio virtualizados” alojados de forma centralizada en un servidor. De este
modo, el equipo de escritorio del usuario consiste en una imagen de pantalla en la
estación de trabajo, mientras que los archivos, datos y aplicaciones se almacenan y
administran desde un servidor central. Mediante el uso de Thin Clients, dispositivos
móviles o equipos convencionales, los usuarios pueden acceder a sus escritorios desde
cualquier lugar, tanto dentro como fuera del entorno corporativo, proporcionando ası́
una gran flexibilidad y movilidad.
Con el amparo de la experiencia previa de la Universidade da Coruña en el des-

pliegue de una infraestructura Windows, en este trabajo se aborda la temática de la
virtualización de escritorios, primero desde un punto plenamente teórico y genérico
para sentar unas bases mı́nimas, para posteriormente tratar una parte práctica cuyos
principales objetivos son: el análisis de las posibles soluciones VDI para escritorios Li-
nux disponibles en el mercado actual, la selección de aquella más adecuada al entorno
de la UDC, la realización del diseño, la implantación y despliegue de la infraestructura
en el entorno corporativo real de la Universidad. Todo ello, desde la perspectiva de un
proyecto piloto que permitirá, en un futuro cercano, cubrir y completar las necesidades
de la comunidad universitaria.
Palabras clave
√
Virtualización
√
Escritorios
√
Linux
√
Universidade da Coruña
√
VDI
√
QVD
√
Open Source
Índice general
Página
1. Introducción 1
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Planificación 5
2.1. Metodologı́a de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Definición de tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Estimacion de tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4. Seguimiento del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5. Estimación de costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3. Contextualización 17
3.1. Virtualización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
i
ÍNDICE GENERAL ii
3.1.1. Conceptos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Un poco de historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3. Tipos de virtualización . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1. Virtualización de plataforma . . . . . . . . . . . . . . . . . . . . 26
3.3.2. Virtualización de recursos . . . . . . . . . . . . . . . . . . . . . . 28
3.3.3. Virtualización de aplicaciones . . . . . . . . . . . . . . . . . . . . 30
3.3.4. Virtualización de biblioteca (API) . . . . . . . . . . . . . . . . . 30
3.3.5. Virtualización de escritorios . . . . . . . . . . . . . . . . . . . . . 30
3.4. Virtualización de escritorios . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.5. Ventajas e Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.5.1. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.2. Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6. Soluciones en el mercado actual . . . . . . . . . . . . . . . . . . . . . . . 42
3.6.1. VMware Horizon View . . . . . . . . . . . . . . . . . . . . . . . . 43
3.6.2. Microsoft VDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.6.3. Citrix XenDesktop . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.6.4. Citrix VDI in a BOX . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6.5. Oracle VDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6.6. Ulteo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6.7. QVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.6.8. RedHat Enterprise Virtualization for Desktops . . . . . . . . . . 45

ÍNDICE GENERAL iii
4. Virtualización de escritorios en la UDC 46
4.1. Situación de partida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2. Usuarios y personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3. Situación actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1. ¿Por qué VDI? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.2. Infraestructura VDI . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.3. ¿Por qué VDI Linux? . . . . . . . . . . . . . . . . . . . . . . . . 51
5. Posibles alternativas 53
5.1. Ulteo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.2. Caracterı́sticas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.1.3. Comparativa de versiones . . . . . . . . . . . . . . . . . . . . . . 57
5.1.4. Requisitos técnicos . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.1.5. Soporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2. QVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.5. Soporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3. Red Hat Enterprise Virtualization: Spice . . . . . . . . . . . . . . . . . . 67
5.3.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
ÍNDICE GENERAL iv
5.3.4. Soporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4. Comparativa de productos . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.4.1. Comparativa de las versiones de pago . . . . . . . . . . . . . . . 70
5.4.2. Comparativa de las versiones gratuitas . . . . . . . . . . . . . . . 73
5.5. Solución a implantar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6. Implantación 79
6.1. ¿Qué es QVD? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.2. Componentes principales . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.3. Componentes secundarios . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.4. Componentes internos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.4.1. L7R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.4.2. HKD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.5. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.6. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.7. Tecnologı́as de virtualización . . . . . . . . . . . . . . . . . . . . . . . . 93
6.7.1. Virtualización KVM . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.7.2. Virtualización LXC . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.8. Diseño del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.8.1. Selección de la tecnologı́a . . . . . . . . . . . . . . . . . . . . . . 96
6.8.2. Diseño de la arquitectura de QVD . . . . . . . . . . . . . . . . . 97

ÍNDICE GENERAL v
6.8.3. Diseño de la arquitectura de red . . . . . . . . . . . . . . . . . . 99
6.9. Implementación del sistema . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.9.1. Configuración de la base de datos . . . . . . . . . . . . . . . . . . 103
6.9.2. Configuración del servidor de administración . . . . . . . . . . . 109
6.9.3. Configuración de los nodos QVD . . . . . . . . . . . . . . . . . . 114
6.10. Operación del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
6.10.1. Pruebas de funcionamiento . . . . . . . . . . . . . . . . . . . . . 120
6.11. Optimización del sitema . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
6.11.1. Autenticación externa . . . . . . . . . . . . . . . . . . . . . . . . 125
6.11.2. Auto provisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.11.3. Almacenamiento compartido . . . . . . . . . . . . . . . . . . . . 128
6.11.4. Balanceador de carga . . . . . . . . . . . . . . . . . . . . . . . . 132
6.11.5. Configuración del balanceador de carga . . . . . . . . . . . . . . 133
6.11.6. Configuración SSL . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.11.7. Componentes hardware . . . . . . . . . . . . . . . . . . . . . . . 135
6.11.8. Politica de copia de seguridad . . . . . . . . . . . . . . . . . . . . 136
6.11.9. Mejoras futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
7. Conclusiones 141
7.1. Evaluación del trabajo realizado . . . . . . . . . . . . . . . . . . . . . . 141
7.2. Difusión del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
7.3. Lı́neas de trabajo futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
7.4. Reflexión personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143

ÍNDICE GENERAL vi
A. Glosario de acrónimos 146
B. Glosario de términos 147
C. Análisis y prueba de Raspberry Pi como Thin Client 150
C.1. Pruebas básicas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
C.2. Mejoras de rendimiento . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
C.3. Alternativas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Bibliografı́a 154
Índice de figuras
Figura Página
2.1. Metodologı́a PPDIOO . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Estimación de las tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3. Diagrama de Gant estimado . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4. Duración real de las tareas . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.5. Diagrama de Gant real . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1. Diagrama máquina virtual de sistema . . . . . . . . . . . . . . . . . . . 20
3.2. Diagrama hipervisor tipo I . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3. Diagrama hipervisor tipo II . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.4. Panel frontal IBM 7040 . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.5. Sistema IBM System/360-67 . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6. Mainframe IBM System 370/Advanced Function . . . . . . . . . . . . . 25
3.7. Esquema virtualización completa vs paravirtualización . . . . . . . . . . 28
3.8. Esquema virtualización de escritorios . . . . . . . . . . . . . . . . . . . . 32
3.9. Thin Client Dell Wyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
vii
ÍNDICE DE FIGURAS viii
4.1. Distrubución de las máquinas en los armarios rack . . . . . . . . . . . . 51
6.1. Esquema básica de QVD . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.2. Esquema de QVD con componentes adicionales . . . . . . . . . . . . . . 84
6.3. Arquitectura general de QVD . . . . . . . . . . . . . . . . . . . . . . . . 86
6.4. Interacción cliente-servidor y L7R . . . . . . . . . . . . . . . . . . . . . . 88
6.5. Esquema básico cliente-servidor de una infraestructura QVD . . . . . . 91
6.6. Esquema básico administración-servidor de una infraestructura QVD . . 92
6.7. Máquinas hardware para QVD . . . . . . . . . . . . . . . . . . . . . . . 97
6.8. Arquitectura de QVD en la UDC . . . . . . . . . . . . . . . . . . . . . . 99
6.9. Arquitectura de red para QVD en la UDC . . . . . . . . . . . . . . . . . 102
6.10. Modelo relacional de la base de datos de QVD . . . . . . . . . . . . . . 104
6.11. Administración de hosts a través de la interfaz web . . . . . . . . . . . . 112
6.12. Administración de máquinas virtuales a través de la interfaz web . . . . 113
6.13. Pantalla de login desde un cliente de escritorio . . . . . . . . . . . . . . 121
6.14. Pantalla de login desde un cliente Android . . . . . . . . . . . . . . . . . 122
6.15. Prueba de QVD desde un cliente Windows . . . . . . . . . . . . . . . . . 122
6.16. Prueba de QVD desde un cliente Android . . . . . . . . . . . . . . . . . 123
6.17. Prueba de QVD desde un cliente Mac OS . . . . . . . . . . . . . . . . . 124
6.18. Prueba de QVD trabajando con LibreOffice . . . . . . . . . . . . . . . . 124
6.19. Prueba de navegación con QVD . . . . . . . . . . . . . . . . . . . . . . . 125
6.20. Acceso a almacenamiento compartido . . . . . . . . . . . . . . . . . . . 128
6.21. Nuevas máquinas hardware para QVD . . . . . . . . . . . . . . . . . . . 136

ÍNDICE DE FIGURAS ix
C.1. Monitorización de la Raspberry Pi en estado original . . . . . . . . . . . 151
C.2. Monitorización de la Raspberry Pi con overclocking . . . . . . . . . . . . 152

Índice de cuadros
Tabla Página
2.1. Costes del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Resumen ventajas e inconvenientes VDI . . . . . . . . . . . . . . . . . . 42
5.1. Comparativa de versiones de Ulteo . . . . . . . . . . . . . . . . . . . . . 59
5.2. Comparativa de versiones de QVD . . . . . . . . . . . . . . . . . . . . . 64
5.3. Comparativa de alternativas de pago: Clientes . . . . . . . . . . . . . . . 71
5.4. Comparativa de alternativas de pago: Administración . . . . . . . . . . 72
5.5. Comparativa de alternativas de pago: Soporte . . . . . . . . . . . . . . . 72
5.6. Comparativa de alternativas de pago: Precio . . . . . . . . . . . . . . . . 73
5.7. Comparativa de alternativas gratuitas: Clientes . . . . . . . . . . . . . . 74
5.8. Comparativa de alternativas gratuitas: Administración . . . . . . . . . . 75
5.9. Comparativa de alternativas gratuitas: Soporte . . . . . . . . . . . . . . 75
6.1. Estados de una máquina virtual en QVD . . . . . . . . . . . . . . . . . 89
x
ÍNDICE DE CUADROS xi
Capı́tulo 1
Introducción
Índice general
1.1. Motivación . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2. Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . 3
1.1. Motivación
Durante décadas, los entornos corporativos se han desarrollado sobre una infraes-
tructura en la que cada usuario hacı́a uso de su propio equipo dedicado, con aplicaciones
propias y datos almacenados localmente. Los usuarios, normalmente eran administra-
dos desde un servidor en red, siendo el personal de gestión TI el encargado de mantener
todos estos equipos; licencias, actualizaciones y configuraciones prácticamente de for-
ma independiente. El continuo avance de las tecnologı́as y las necesidades cada vez
mayores por parte de los usuarios, impulsaron a las organizaciones a considerar op-
ciones informáticas más eficientes, más sencillas, autónomas y seguras. Nacen ası́ las
plataformas de Virtualización de Escritorios (Virtual Desktop Infraestructure).
La tecnologı́a VDI se ajusta a la idea de sustituir el PC dedicado en las actividades

cotidianas, especialmente en el mundo educativo donde cada usuario tiende a utilizar su
propio dispositivo móvil para la conexión a las redes y servicios del campus. Por ello se
hace necesario potenciar la presencia de esta tecnologı́a en la Universidade da Coruña,
1
1. Introducción 2
en la que actualmente ya se cuenta con una plataforma de este tipo para escritorios
Windows.
Una de las filosofı́as de la Universidade da Coruña radica en trabajar a favor del

fomento y la promoción del software libre y de los estándares abiertos, ası́ como apostar
por la tecnologı́a española, de cara a conseguir unos modelos tecnológicamente más
sostenibles y fácilmente administrables, y todo ello primado por el ahorro de costes.
Ası́, con el objetivo de dar respuesta a las mencionadas necesidades de movilidad del
alumnado y del personal de investigación, y buscando un alto rendimiento y la optimiza-
ción de recursos, surge la idea de implantar una solución basada en escritorios virtuales
Linux, que proporcione la seguridad imprescindible en un entorno universitario que en
esencia tiende a ser vulnerable, y que además permita dar servicio a los innumerables
dispositivos móviles de los que se dispone actualmente conectándose desde diferentes
puntos de acceso. Con esta solución se aumenta la flexibilidad de los usuarios de la
comunidad universitaria de una forma segura y a su vez se mejora la eficiencia de los
equipos Linux ya distribuidos por los diferentes campus y facultades.
1.2. Objetivos
El objeto de este proyecto es analizar y posteriormente implantar una infraestruc-

tura de virtualización de escritorios Linux, tratando también de explicar de forma breve
y concisa el amplio panorama de la temática VDI en general.
Consistirá básicamente en el diseño, configuración y despligue de una plataforma

plenamente funcional, pero desde la perspectiva de un proyecto piloto, para labores de
prueba y evaluación de la aceptación por parte de la comunidad universitaria.
Además, se pretende cumplir los siguientes objetivos, complementarios a lo anterior:
Ofrecer una perspectiva de la virtualización en general, desde sus orı́genes hasta

la actualidad, con sus ventajas e inconvenientes.
Dar una visión lo suficientemente amplia para analizar y seleccionar entre varias
plataformas de virtualización de escritorios existentes (tanto Open Source como
privativas). Se escogerá aquella que mejor se adapte a los requisitos necesarios
para la Universidade da Coruña.
1. Introducción 3
Relización del proyecto teniendo en cuenta siempre las posibles necesidades fu-
turas de eficiencia, alta disponibilidad y escalabilidad.
1.3. Estructura de la memoria
La presente memoria del proyecto está estructurada en capı́tulos de la siguiente

forma:
Introducción: Trata el marco sobre el que se desarrolla el proyecto, el problema

a resolver y los objetivos a lograr.
Planificación: Explica todos los detalles relacionados con el plan de proyecto,

las tareas llevadas a cabo, la estimación de las mismas y la metodologı́a empleada
durante el proyecto.
Contextualización: Ofrece una visión global del ámbito en el que se desarrolla

el proyecto, la virtualización, abordado desde un punto de vista teórico.
Virtualización en la UDC: Realiza una descripción breve y concisa del entorno

y de la situación de partida en la Universidade da Coruña.
Posibles alternativas: Muestra el análisis previo a todo el trabajo realizando

una elaborada comparativa de las posibles soluciones VDI Linux disponibles en
el mercado para decantarse por la ideal para el entorno de la UDC.
Implantación: Abarca la descripción y análisis de la solución seleccionada y

la explicación de todo el proceso de implantación de la infraestructura para su
puesta en producción.
Conclusiones: Proporciona una evaluación del trabajo realizado y las posibles

lı́neas de explotación y mejora futura del proyecto en su puesta en producción.
Apéndices: Formado por varios documentos:
• Glosario: Subdividido a su vez en dos: Un glosario de términos y un glo-

sario de acrónimos. En el primero se definen todos los términos técnicos
empleados en la memoria y en el segundo de ellos se muestra el significado
de todos los acrónimos.
1. Introducción 4
• Proceso de instalación: Documento puramente técnico que muestra los

pasos necesarios para la instalación de la infraestructura QVD exclusiva-
mente, sin entrar en instalaciones complementarias.
• Pruebas con clientes ligeros: Recoge una serie de pruebas realizadas
para el uso de una Raspberry Pi como cliente de acceso ligero a los escritorios
virtuales.
• Bibliografı́a: Listado de documentos, libros y material digital empleados
para la realización del proyecto.
Capı́tulo 2
Planificación
Índice general
2.1. Metodologı́a de desarrollo . . . . . . . . . . . . . . . . . . . . . 6
2.2. Definición de tareas . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Estimacion de tareas . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4. Seguimiento del proyecto . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1. Problemas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5. Estimación de costes . . . . . . . . . . . . . . . . . . . . . . . . 14
Este capı́tulo está dedicado a la planificación del proyecto, identificando todas las
actividades a llevar a cabo para alcanzar los objetivos descritos en la Sección 1.2, es-
timando todo el esfuerzo y la duración de cada una de ellas. De esta forma, se puede
conocer en cualquier momento si el proyecto sufre alguna desviación del plan inicial
previsto para poder aplicar las correciones oportunas. Como en cualquier proyecto real,
realizar una buena planificación será vital para lograr un trabajo rápido, eficiente y or-
ganizado, además de evitar problemas inesperados que causen retrasos en la realización
del proyecto.
5
2.1. Metodologı́a de desarrollo
El primero de los pasos antes de abordar la realización del proyecto es la decisión de

la metodologı́a a emplear, para posteriormente adecuar a dicha metodologı́a las tareas
a realizar. Esta selección debe ser estudiada y analizada previamente pues definirá el
marco de trabajo y la guı́a para todo el proyecto.
Para el desarrollo de este proyecto, la decisión de la metodologı́a es relativamente

sencilla, pues al tratarse de un proyecto de implantación de un sistema, existen múltiples
metodologı́as completamente validadas y con resultados satisfactorios en la mayorı́a de
los casos. Un ejemplo es la metodologı́a PPDIOO1 desarrollada por Cisco2 para el
despligue de redes corporativas.
La metodologı́a PPDIOO [7] permite formalizar el ciclo de vida (y despligue) de

una red en seis fases: Preparación, Planificación, Diseño, Implementación, Operación y
Optimización. Cada una de ellas cumple con su función especı́fica y se relacionan con
su antecesora y predecesora. En la Figura 2.1 se muestra el ciclo de vida de acuerdo
con la metodologı́a PPDIOO [7].
Figura 2.1: Metodologı́a PPDIOO
Aunque la metodologı́a PPDIOO está diseñada inicialmente para el despligue de

redes de comunicación corporativas, se adapta a la perfección a cualquier proyecto de
1
Preparación, Planificación, Diseño, Implementación, Operación y Prueba
2
http://www.cisco.com/
sistemas que impligue la implantación de una infraestructura, simplemente con unas pe-
queñas variaciones teóricas en la metodologı́a. A continuación se muestra la descripción
de cada una de las fases del ciclo PPDIOO [8] adaptado a este proyecto.
Fase de preparación: Es la primera de las fases. En ella, fundamentalmente se

definen los objetivos, las limitaciones, el personal requerido, la estrategia a seguir,
el presupuesto y se analizan todos y cada uno de los condicionantes iniciales.
Se establecen aquı́ las decisiones a cerca de en qué va consistir el proyecto, qué
tecnologı́as se van a emplear y de que forma se realizará.
Fase de planificación: Esta fase involucra el análisis de la infraestructura actual

y la definición de los requerimientos de la organización. Es importante barajar
aquı́ las ventajas e inconvenientes y realizar un buen plan de proyecto para ad-
ministrar las tareas.
Fase de diseño: En esta fase se realiza el diseño de la infraestructura en base a lo

analizado y establecido en las fases anteriores. Incluye la realización de diagramas
de red y lista de equipos, de tal forma que muestre de forma clara y concisa toda
la información. Una vez aprobada esta fase, empieza la implementación.
Fase de Implementación: Instalación y configuración de todo el equipamiento.

Es la fase de aplicación del plan de proyecto. Cualquier cambio o variación del
diseño en esta fase debe ser debidamente justificado y previamente analizado.
Fase de Operación: Es la fase más larga de la metodologı́a PPDIOO. Consiste

en la monitorización, gestión, actualización y control de la infraestructura en
su funcionamiento diario. Además deben identificarse y corregirse los errores
detectados. Es la fase de prueba del diseño.
Fase de Optimización: Abarca la administración pro-activa, es decir, identificar

y resolver cuestiones que afecten a la infraestructura. Es común que se produzcan
pequeñas variaciones en el diseño durante esta etapa, sobre todo a la hora de
mejorar cuestiones relacionadas con el rendimiento y las funcionalidades.
2.2. Definición de tareas
A continuación, se muestra el desglose de tareas de las que se compone el proyecto,

agrupadas en las etapas de la metodologı́a empleada descrita en la Sección 2.1.
Fase de preparación
• Esbozo: Es la primera tarea del proyecto. Se compone de una serie de

reuniones en la que se definen los objetivos del proyecto, la infraestructura
disponible, el presupuesto y se acuerda un plan de trabajo y horario a seguir.
• Estudio previo: Tarea destinada al análisis de las alternativas de virtua-
lización de escritorios disponibles en el mercado actual.
• Comparativa: Selección de varias soluciones candidatas y realización de
una exahustiva comparativa de caracterı́sticas de todos sus aspectos: fun-
cionalidades, soporte, precio, etc.
• Prueba: Comprende la realización de pruebas prácticas con las versiones
de evaluación de cada una de las candidatas para conseguir una visión más
amplia antes de seleccionar la solución a implantar.
• Decisión: Esta tarea incluye la selección de la solución a implantar, tras
la fase de pruebas. Una vez tomada la decisión, comenzará la ejecución del
proyecto.
Fase de planificación
• Realización del plan de proyecto: Engloba la realización de este sencillo

plan de proyecto.
• Análisis de requisitos: Trata la lectura de la documentación relacionada
con la solución VDI seleccionada para implantar, para conocer las necesi-
dades técnicas de la misma.
Fase de diseño
• Diseño de la infraestructura: En función de la documentación de la

solución y de la infraestructura disponible, realizar un diseño previo.
• Diseño de la red: Al igual que en el caso anterior, basándose en la do-

cumentación, es necesario elaborar un diseño de la infraestructura de red
necesaria.
Fase de implementación
• Preparación de la infraestructura: Se centra en el montaje y confi-

guración de los equipos fı́sicos y/o virtuales necesarios para instalación de
la solución. De igual forma, se tratan aquı́ la creación de la/s red/es de
comunicaciones necesaria para la infraestructura VDI.
• Instalación: Es una de las tareas más largas. Se realiza aquı́ toda la imple-
mentación, instalación y configuración para el funcionamiento básico del
conjunto.
Fase de Operación
• Pruebas básicas: Tarea en la que se realizan todas las pruebas necesarias

para comprobar el funcionamiento de la solución VDI. Se realizan aquı́
pruebas objetivas, a través de la monitorización de la misma.
• Pruebas de clientes: Comprobada la funcionalidad, se realizan pruebas
de los clientes software de acceso a los escritorios virtuales.
• Otras pruebas: Se incluye aquı́ una tarea adicional para la realización de
pruebas personales o de investigación, si ası́ se desea.
Fase de Optimización
• Instalaciones adicionales: Tarea que trata la instalación y configuración

de funcionalidades adicionales de una solución VDI.
• Estrategı́a de backup: Destinada a la elaboración de una politica de bac-
kup. Aunque pueda considerarse adecuado incluir esta tarea en la etapa de
diseño, se ubicó en esta etapa ya que tras la instalación de la infraestructu-
ras se posee un mayor conocimiento de la misma y de esta forma el diseño
de la polı́tica de backup será más completo.
En las tareas comentadas anteriormente no se incluye en ningún punto la elabora-

ción de esta memoria, por considerarse de forma implı́cita una tarea paralela a todas
las anteriores. Si se tendrá en cuenta la existencia de una tarea final dedicada al repa-
so y revisión de toda la documentación una vez finalizada, en la que se aplicarán las
correcciones y mejoras necesarias.
2.3. Estimacion de tareas
La estimación de la duración del proyecto y de cada una de las tareas se realizó

basándose en la metodologı́a descrita en la 2.1 y el desglose de tareas realizado en la
Sección 2.2.
Para la realización del proyecto y la estimación de las tareas, se tomó como base
una jornada laboral de 4h diarias de lunes a jueves, con la existencia de un pequeño
descanso y un parón quincenal por la época de exámenes finales. Aunque normalmente
este tipo de cuestiones no se tratan como tareas, en este caso se consideró oportuno
el tenerlas en cuenta para ası́ dar una visión más global y clara de la duración y la
influencia de dichos parones en el proyecto.
La utilización de herramientas automatizadas que existen en el mercado puede

facilitar la estimación de un proyecto e incluso permiten contrastar dicha estimación
con el seguimiento del mismo, es decir, comparar la situación en la que se encuentran
con la prevista durante esta etapa. La herramienta seleccionada para la estimación y
seguimiento de las tareas de este proyecto es GanttProyect 3 , debido a su sencillez y
compatibilidad con la filosofı́a software libre del proyecto.
Las tareas, la fecha de inicio, duración y fecha de finalización prevista se muestra

en la Figura 2.2. Además, a partir de ellas se generó el diagrama de Gant estimado,
mostrado en la Figura 2.3.
3
http://www.ganttproject.biz/
Figura 2.2: Estimación de las tareas
Figura 2.3: Diagrama de Gant de estimación
2.4. Seguimiento del proyecto
La actividad de seguimiento de un proyecto, tiene como principal objetivo el control

de todas las tareas de las que se compone, revisando todos los puntos clave: respon-
sables, estado en el momento del seguimiento, evolución previsible y problemas que se

están encontrando y se encontraron durante su ejecución.
La lista de las tareas y la fecha de inicio, duración y fecha de finalización real se

muestra en la Figura 2.4 extraı́da de la aplicación GantProyect. El diagrama de Gant
de la duración real de las tareas se presenta en la Figura 2.4.
Figura 2.4: Duración real de las tareas
Figura 2.5: Diagrama de Gant real

2.4.1. Problemas
A continuación se detallan las tareas que fueron objeto de problemas, ası́ como
también la explicación del problema y la resolución del mismo.
Tarea prueba: Se produjo el retraso de un dı́a por motivos de incompatibilidad

Java en las pruebas realizadas con la solución de virtualización Ulteo. La solución
consistió en la prueba de diferentes versiones del motor de ejecución Java y niveles
de seguridad.
Tarea análisis de requisitos: Retraso de un dı́a debido al desconocimiento

inicial. Documentación desconocida y complicada. Fue necesario realizar diversas
consultas y revisar documentación adicional para la total comprensión de los
conceptos.
Tarea preparación de la infraestructura: Se generó un retraso de un dı́a por

imposibilidad de acceso al Centro de Datos donde se ubican los equipos hardware,
por problemas ajenos al proyecto.
Tarea instalación: Es una de las tareas más largas y en la que más retrasos se
acumularon. Existieron aquı́ diversos tipos de problemas, algunos de gravedad y
otros caracterı́sticos de cualquier proyecto de sistemas. Los más importantes por
retraso acumulado fueron:
• Configuración Apache: Una vez realizada la configuración del servidor Apa-

che del servidor de administración, se detectó un error en el acceso a la
interfaz web de administración. El problema residı́a en los permisos de lec-
tura y escritura de los ficheros de configuración y log del Apache. Aunque
a simple vista es un error tı́pico y sencillo, debido al conjunto de configura-
ciones y a la poca experiencia en este tipo de proyectos, ocasionó un retraso
significativo en la planificación del proyecto.
• Configuración de la red: Problema ocasionado por las caracterı́sticas de
la infraestructura. Fue necesario idear una configuración personalizada y
adaptada a la red de la Universidad, completamente diferente a la mostrada
en la documentación técnica de la solución.
• Desconocimiento: A pesar de ya contemplarse este problema en la planifi-
cación del proyecto, el desconocimiento inicial de muchas de las tecnologı́as
a emplear en el proceso de instalación, provocó la necesidad de analizar

documentación adicional, retrasando la tarea.
Tarea instalaciones adicionales: Dentro de esta tarea existieron también muchos

problemas menores y otros importantes como los citados a continuación:
• Conexión servidor LDAP: Problemas de conexión con el servidor LDAP

desde la infraestructura. Se trata de un problema ajeno a este proyecto
y dependiente del Departamento de Red. La coincidencia de este con un
problema mayor que afectaba a la red de toda la infraestructura de la Uni-
versidade da Coruña provocó un retraso considerable.
• Espacio de almacenamiento: El agotamiento del espacio de almacenamiento
del servidor de administración en la partición raı́z ocasionó una serie de
fallos de este que fue necesario solventar.
• Conexión entre nodos: Es probablemente el problema más grave (en lo que
a retraso se refiere) ocurrido en el proyecto. Un error en el diseño de la
red y la configuración de esta, provocó que fuese necesario realizar una
nueva configuración, ya que la anterior no permitı́a la conexión entre los
nodos de la infraestructura, derivando incluso a el mal funcionamiento del
balanceador de carga interno y de las máquinas virtuales. Para dar con la
solución fue necesario realizar una consulta al soporte técnico.
2.5. Estimación de costes
Esta sección se dedicará a tratar de estimar lo mejor posible los costes del desarrollo
de este proyecto, teniendo en cuenta que existen una serie de variables que dificulta
dicha tarea.
Para poder estimar el presupuesto teórico de la realización del proyecto, es necesario

tener en cuenta varios aspectos:
Se realizará un cálculo de únicamente el coste del proyecto sin tener en cuenta

ninguna otra variable.
El proyecto ha sido desarrollado por una sola persona cuyo nivel profesional
podrı́a corresponder al de un ingeniero júnior.
Ha existido una colaboración exhaustiva e indispensable por parte de los tutores

del proyecto que favorecieron el avance del mismo. El nivel profesional de los
mismos se corresponde con el de ingenieros sénior.
Se ha empleado hardware reciclado y en desuso para su realización, por lo que

no se considerará coste alguno de estos servidores al estar ya completamente
amortizados tras haber estado dando servicio durante años.
Al realizar el proyecto en la infraestructura existente en la universidad es impo-

sible realizar el cálculo de los costes de energı́a como la electricidad o la refrigue-
ración, al igual que la conectividad a Internet, pues sólo se conocen los costes del
conjunto de la infraestructura.
Tras estos condicionantes iniciales, el desglose de gastos para este proyecto se com-
pone únicamente de los recursos humanos utilizados en el proyecto. Dicho coste se
ha calculado teniendo en cuenta una jornada laboral media de 20h semanales para el
alumno y una duración de algo más de seis meses y medio (Ver seguimiento 2.4)
Tomando como base las tablas salariales del convenio TIC 2007-2009, se establece
un sueldo de ochocientos euros brutos mensuales a media jornada para un técnico de
grado superior.
Por lo tanto:
Coste del alumno: Salario bruto + Seguridad Social.
Coste del alumno: 800 euros durante 6.5 meses (+7 % SS) = 5564 euros brutos.
Además, también es importante destacar el coste de las horas de asesorı́a y cola-

boración del tutor profesional y el tutor académico. Aproximadamente constan de tres
semanales en caso del tutor profesional y una hora en el caso del tutor académico. Se
toma como base el coste que supone a la universidad el trabajo de ambos tutores. En el
caso del tutor profesional el coste bruto incluida la seguridad social (7 %) es de quince
euros la hora, mientras que en el caso del tutor académico el coste es de algo más de
doce euros. Es importante destacar que se trata del coste que supone para la organiza-
ción la hora de trabajo, que como es evidente, serı́a superior en el caso de encontrarse
en el mundo empresarial y ser realizado a través de contrataciones externas.
Por lo tanto:
Tutor profesional: 15 euros x 3 horas semanales x 26 semanas (6.5 meses) =

1170 euros brutos.
Tutor académico: 12.25 euros x 1 horas semanales x 26 semanas (6.5 meses)

= 318.5 euros brutos.
A continuación, en la Tabla 2.1 se muestra un resumen de los costes teóricos del

proyecto.
Cantidad Coste
6.5 meses/20h semanales 5564 euros
6.5 meses/3h semanales 1170 euros
6.5 meses/1h semanal 318.5 euros
TOTAL: 7052.5 euros
Cuadro 2.1: Costes del proyecto.

Capı́tulo 3
Contextualización
Índice general
3.1. Virtualización . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2. Un poco de historia . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3. Tipos de virtualización . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.1. Virtualización de plataforma . . . . . . . . . . . . . . . . . . . . 26
3.3.2. Virtualización de recursos . . . . . . . . . . . . . . . . . . . . . . 28
3.3.3. Virtualización de aplicaciones . . . . . . . . . . . . . . . . . . . . 30
3.3.4. Virtualización de biblioteca (API) . . . . . . . . . . . . . . . . . 30
3.3.5. Virtualización de escritorios . . . . . . . . . . . . . . . . . . . . . 30
3.4. Virtualización de escritorios . . . . . . . . . . . . . . . . . . . . 31
3.5. Ventajas e Inconvenientes . . . . . . . . . . . . . . . . . . . . . 34
3.5.1. Ventajas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.2. Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.6. Soluciones en el mercado actual . . . . . . . . . . . . . . . . . . 42
3.6.1. VMware Horizon View . . . . . . . . . . . . . . . . . . . . . . . . 43
3.6.2. Microsoft VDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.6.3. Citrix XenDesktop . . . . . . . . . . . . . . . . . . . . . . . . . . 43
17
3.6.4. Citrix VDI in a BOX . . . . . . . . . . . . . . . . . . . . . . . . 44

3.6.5. Oracle VDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6.6. Ulteo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6.7. QVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.6.8. RedHat Enterprise Virtualization for Desktops . . . . . . . . . . 45
3.1. ¿Qué es la virtualización?
Se puede definir formalmente la virtualización de infraestructuras como la abstrac-

ción o multiplexación lógica de una infraestructura fı́sica. Es decir, la creación de un
sistema computacional lógicamente segmentado, que funciona en una base real. Técni-
camente, la virtualización permite ocultar los recursos fı́sicos reales de las aplicaciones,
servicios o usuarios que los utilizan, a través de la encapsulación, proporcionando un
entorno lógico o virtual que elimina la dependencia del sistema fı́sico subyacente.
La virtualización de infraestructuras, surge bajo el desafı́o actual de la industria de

las tecnologı́as de la información (TI), que persigue encontrar soluciones de sistemas
más simples, más rápidas y al mismo tiempo con una capacidad de administración
superior. A todo esto, se suma la búsqueda de una mayor seguridad y flexibilidad. El
concepto de virtualización el que abre la posibilidad de construir y diseñar infraestruc-
turas empresariales más potentes, autónomas, seguras y fiables.
3.1.1. Conceptos básicos
Antes de introducirse por completo en el núcleo del trabajo, es muy importante

tener claros una serie de conceptos del ámbito de la virtualización [11] que crearán una
base y facilitarán al lector la total comprensión del proyecto.
3.1.1.1. Máquina virtual
A grandes rasgos, una máquina virtual es un software que simula una computadora
y que puede ejecutar programas como si fuese un ordenador real. Una caracterı́stica
esencial de las máquinas virtuales es que los procesos que ejecutan están limitados por
los recursos y abstracciones de la máquina fı́sica subyacente. En la actualidad es muy
importante distinguir entre dos contextos en los que se ubica el concepto de máqui-
na virtual. Según las caracterı́sticas y la funcionalidad se puede hablar de máquinas
virtuales hardware o de sistema o de máquinas virtuales de proceso o de aplicación.
Máquinas virtuales hardware o de sistema: Son aquellas que permiten a

la máquina fı́sica subyacente multiplicarse en varias máquinas virtuales, es decir,
abstraen el hardware de una máquina fı́sica y hacen uso de él. Cada una de estas
máquinas pueden ejecutar su propio sistema operativo y son controladas a través
de un software denominado hipervisor, que se describirá más adelante. La funcio-
nalidad y aplicación de este tipo de máquinas virtuales es muy amplia, aunque
alguna de sus caracterı́sticas más destacadas son la posibilidad de coexistencia de
varios S.O, la virtualización de servidores o la prueba y testeo de proyectos (soft-
ware o hardware) en arquitecturas diferentes (permiten a un desarrollador, por
ejemplo, probar el programa desarrollado en varias arquitecturas sin necesidad
de instalar nativamente los operativos). En la Figura 3.1 se muestra un diagrama
que representa un equipo o servidor sobre el que corren dos máquinas virtuales.
Figura 3.1: Esquema de representación de una máquina virtual de hardware o

sistema
Máquinas virtuales de proceso o aplicación: Este tipo de máquina virtual

no representan una máquina al completo, si no más bien simulan un proceso sobre
el sistema operativo, es decir, la máquina se inicia automáticamente cuando se
lanza el proceso y se detiene cuando este finaliza.
Su objetivo fundamental es proporcionar un entorno de ejecución independiente
del hardware y del operativo para las aplicaciones que se ejecutan sobre ella. Los
ejemplos más representativos de este tipo son Java Virtual Machine o Common
Language Runtime.
3.1.1.2. Hipervisor
A grandes rasgos, se puede definir un hipervisor [9] como un programa software que
permite que diferentes sistemas operativos compartan recursos alojados bajo el mismo
hardware, es decir, es un gestor de máquinas virtuales (Virtual Machine Manager ).
De esta forma, aunque aparentemente cada máquina virtual utiliza para sı́ misma los
recursos del host “anfitrión”, en realidad es el hipervisor el que controla dichos recursos
y los distribuye entre las máquinas virtuales según sus necesidades y sin que interfieran
entre ellos. Se pueden diferenciar dos tipos de hipervisores en función de su arquitectura:
Hipervisor tipo I: Este tipo de hipervisor se despliega como una instalación

bare-metal o native [11]. Esto significa que lo primero que se instala en un
servidor es el hipervisor, lo que tiene como ventaja que será el hipevisor el que
se comunicará directamente con el hardware del servidor fı́sico. Se instala en
el servidor fı́sico sin la necesidad de que exista un sistema operativo previo1 . Se
agrupan como hipervisores de tipo I tecnologı́as como VMware vSphere, Microsoft
Hyper-V o Citrix XenServer, algunas de las cuales serán descritas en sucesivos
apartados.
Figura 3.2: Esquema de representación de un hipervisor de tipo I
Hipervisor tipo II: Se conoce también como hipervisor alojado o “hosted”. Este
tipo de hipervisores requieren ser instalados sobre un sistema operativo previo.
Es la solución más conocida a nivel usuario con programas como VirtualBox o
VMware Workstation.
1
la denominación bare-metal hace referencia a la instalación sobre el “metal desnudo”, es
decir, instalación del software hipervisor directamente sobre el hardware como si de un sistema
operativo se tratase
Figura 3.3: Esquema de representación de un hipervisor de tipo II
3.2. Un poco de historia
En este apartado se profundizará sobre el concepto histórico de virtualización [11],

haciendo un pequeño repaso de la tecnologı́a, no tan reciente como se suele pensar.
Viendo sus orı́genes y entendiendo las causas que provocaron su evolución, se llegará al
punto en el que hoy en dı́a se encuentra: un amplio abanico de soluciones que encajan
con las necesidades actuales de las organizaciones.
Virtualizar ha sido considerado históricamente y de manera general como tomar algo

en cierto estado y hacer parecer que se encuentra en otro estado diferente. A partir de
esta idea, el concepto ha ido evolucionando hasta obtener las diferentes aproximaciones
de virtualización existentes hoy en dı́a.
Tratando de encontrar los orı́genes de esta tecnologı́a, es necesario remontarse a

la década de los 60, años en los cuales el concepto de virtualización se establecı́a a
través de la creación de una máquina virtual empleando una combinación de hardware
y software. Se asienta en este momento el término de máquina virtual, que vendrá dado
por la creación del sistema de paginación experimental IBM M44/44X basado en el

conocido IBM 7044 (Figura 3.4).
Figura 3.4: Parte frontal del IBM 7040 empleado como base para el primer sistema
de virtualización
Aparece poco tiempo después el sistema operativo CP-40 de también de IBM, con-
siderado el primer sistema que usa técnicas de virtualización completa, entendiendo
como tal un entorno de ejecución de máquinas virtuales que soportaba que otros opera-
tivos pudiesen ser instalados y empleados como si de una máquina fı́sica se tratase. Se
puede añadir “a modo de curiosidad” que el sistema operativo CP-40 soportaba hasta
14 máquinas virtuales ejecutándose simultáneamente.
El CP-40 pronto fue re-implementado como CP-67 para el nuevo sistema de IBM, el
IBM System/360-67 (Figura 3.5), una máquina fabricada en 1966 que incluı́a una tabla
hardware con traducción de páginas para la memoria virtual además de otra serie de
caracterı́sticas que permitı́a la virtualización de todas las tareas y procesos del kernel,
como la E/S o las interrupciones.
Figura 3.5: Computador IBM System/360-67 de la Universidad de Michigan en

1969
Tras los sistemas operativos anteriormente descritos aparece el sistema CP/CMS

como parte de un intento de IBM de construir sistemas robustos de tiempo compartido
para sus sistemas mainframe. Al correr varios sistemas operativos al mismo tiempo,
el hipervisor [3.1.1.2] incrementaba la fiabilidad y estabilidad y incluso en el caso de
fallo de un sistema operativo, por lo que los demás podrı́an continuar su ejecución sin
interrupción de ningún tipo.
Será en 1972 cuando Robert Goldberg asienta la base teórica de una arquitectu-
ra orientada a sistemas virtuales y en ese mismo año IBM introduce en el mercado
el sistema operativo VM/370 (siendo una re-implementación del CP/CMS), empleado
en el sistema mainframe IBM System 370/Advanced Function (En la Figura 3.6 se
puede apreciar una imagen del sistema), diseñado, al igual que el CP/CMS, para eje-
cutar varios sistemas operativos al mismo tiempo, bajo la supervisión de un programa
(hipervisor). Esta idea fue la predominante en el mercado durante años apareciendo
diferentes mainframes que mejoraron a este modelo de referencia. Son estos últimos
modelos y operativos los que gozaron de una pronta aceptación y desarrollo por parte
de la comunidad empresarial, militar y universitaria.
Figura 3.6: Parte frontal del mainframe IBM 370/Advanced Function
Poco tiempo más tarde se producirı́an una serie de enfrentamientos entre la vir-
tualización y el procesamiento por lotes, provocadas por las necesidades de la época,
saliendo completamente fortalecido este último. Esto trajo consigo una marcha atrás de
las máquinas virtuales de igual manera que le ocurrió a los sistemas operativos durante
años y no será hasta mediados de la década de los 90 hasta que empresas como VMware
Inc. empiezan a interesarse de nuevo por la tecnologı́a comenzando investigaciones y
desarrollos en este campo. Es a finales de los 90 cuando aparece su primera versión
comercial bajo el nombre de “VMware Virtual Platform”, basada en las investigaciones
anteriores.
Posteriormente en los primeros 2000, concretamente en 2003 aparece la primera

versión de Xen (Open Source) y surge el interés de los principales dominantes del mer-
cado de procesadores por la virtualización, comenzando la fabricación de sus primeros
procesadores con soporte para virtualización en el 2005 (tecnologı́as Intel VT y AMD-
V).
En el presente, la virtualización ha llegado al escritorio, lo que ha echo que incre-

mente exponencialmente su popularidad y esto provoque que sea una de las tecnologı́as
más innovadoras del momento debido a las notables ventajas que supone su aplicación.
Uno de los hechos que justifican esto es que prácticamente todas las grandes empresas
dentro del mundo informático han desarrollado productos y soluciones de virtualización
o han adquirido empresas que lo ofrecı́an.
Hoy en dı́a, la virtualización es uno de los puntos calientes del sector informático a
nivel mundial. Cada vez más las empresas virtualizan a prácticamente todos los niveles
sus servicios y lo más sorprendente de todo es que se trata de una tecnologı́a de hace
casi medio siglo, no explotada hasta ahora en ninguno de sus ámbitos más consolidados
en la actualidad: la virtualización de servidores y la virtualización de escritorios.
3.3. Tipos de virtualización
Actualmente el concepto de virtualización está tan ampliamente expandido que mu-

chas veces se emplea de manera errónea. No es correcto, por tanto, mezclar conceptos
de emulación, simulación, virtualización o paravirtualización y es por ello que se mos-
trará a continuación una descripción detallada de los diferentes tipos de virtualización
con el objetivo de plantear todo el entramado de forma clara.
La virtualización separa de forma lógica los servicios y los recursos (fı́sicos), que
realmente ofrecen y proporcionan ese servicio. Dicho recurso puede ser individual (al-
macenamiento, red, etc) o una plataforma completa (servidor) y es ası́ como surgen los
diferentes modelos de virtualización [11].
Para comprender en su totalidad los modelos de virtualización es importante tener

claro la diferencia entre dos conceptos clave: el recurso virtual abstraı́do y el
elemento que (virtualizado) dispone de ese recurso. Es la combinación de estos
conceptos lo que provoca la aparición de los cuatro tipos principales de virtualización:
virtualización de plataforma, virtualización de recursos, virtualización de
aplicaciones y la que será objetivo de este proyecto, virtualización de escritorios
(VDI).
3.3.1. Virtualización de plataforma
La virtualización de plataforma es aquella en la que el recurso que se abstrae o vir-

tualiza es el sistema completo, como es el caso de un servidor. Consiste básicamente en
virtualizar todo el hardware subyacente de una plataforma de tal forma que múltiples
sistemas operativos puedan ejecutarse de forma independiente, y que los recursos abs-
traı́dos se comporten de forma equivalente al sistema fı́sico. Cada una de las máquinas
ve a las otras máquinas virtuales como máquinas independientes, es decir, desconoce

que comparte con ellas ciertos recursos.
Es el modelo aplicado en lo que se conoce como virtualización de servidores, que

puede verse como el particionado de un servidor fı́sico en varios servidores virtuales
ejecutando de forma independiente su sistema operativo y los servicios que este ofrece.
A su vez, este sistema de virtualización se subdivide en diferentes paradigmas:
Sistemas operativos invitados: Es aquel sistema de virtualización que ocurre

sobre una aplicación para virtualización, que corre sobre un sistema operativo
anfitrión y que permite la ejecución de instancias virtuales. Las soluciones más
conocidas de este tipo son VirtualBox, VMware Workstation y Parallels. [11]
Emulación: Un emulador es la réplica una arquitectura hardware al completo

que permite que se ejecute sobre él máquinas virtuales, es decir, es tratar de
conseguir la apariencia de hardware real para el sistema operativo virtual o invi-
tado. Emuladores conocidos actualmente pueden ser Boch, MAME o Qemu (En
la mayorı́a de las ocasiones, las soluciones de virtualización hacen uso interno de
emuladores). [11]
Paravirtualización: La paravirtualización es una técnica de virtualización que

mediante un sistema operativo o un hipervisor. Este operativo (o hipervisor) es el
que interactúa y gestiona los recursos del hardware, creando una capa de abstrac-
ción que emula componentes fı́sicos como tarjeta de red, de vı́deo, discos duros, y
RAM; para que los sistemas operativos virtualizados funcionen de manera trans-
parente. Es decir, consiste en ejecutar sistemas operativos guests o invitados sobre
otro sistema operativo que actúa como hipervisor (host). Los guests tienen que
comunicarse con el hipervisor para lograr la virtualización. Las soluciones más
conocidas dentro de la paravirtualización son Xen, Logical Domains, Oracle VM
y Sun xVM Server.
Las ventajas de este enfoque son un muy buen rendimiento y la posibilidad de eje-
cutar múltiples y distintos sistemas operativos. Su desventaja es que los sistemas
operativos invitados deben ser modificados expresamente para esta arquitectura,
al igual que las librerı́as y utilidades ejecutadas por las máquinas virtuales, que
deben estar compiladas y preparadas para el hardware de la máquina fı́sica. [11]
Virtualización completa: La virtualización completa es similar a la paravir-

tualización en la existencia de un hipervisor, pero no requiere que los sistemas
operativos invitados colaboren con él. Este método tiene todas las ventajas de la
paravirtualización, con el añadido de que no es necesaria ninguna modificación
en los sistemas operativos virtualizados. La única restricción es que estos últimos
deben soportar la arquitectura de hardware subyacente. Dentro de esta categorı́a
se pueden encontrar algunas de las soluciones más importantes del mercado como
VMware Server, Microsoft Hyper-V, Oracle VM, etc. En la Figura 3.7 se puede
ver una comparativa de esta arquitectura con respecto a la paravirtualización. [11]
Figura 3.7: Representación esquematizada de una arquitectura de virtualización

completa y una arquitectura de paravirtualización
Virtualización a nivel de sistema operativo: Consiste en la virtualización de

servidores sobre el propio sistema operativo, sin introducir un hipervisor como ca-
pa intermedia. Requiere cambios en el núcleo del sistema operativo, aunque esto
se compensa con un notable aumento del rendimiento, ofreciendo caracterı́sticas
similares a las del sistema sin virtualizar. Las soluciones comerciales que em-
plean esta técnica no son mayoritarias, destacando OpenVZ, Linux V-Server o
Virtuozzo. [11]
Virtualización a nivel de kernel: El hipervisor pasa a ser el núcleo del sistema

operativo (el kernel), lo que permite ejecutar varias máquinas virtuales en el
espacio de usuario del núcleo Linux anfitrión. Se agrupan aquı́ soluciones tan
importantes como KVM o User-mode Linux. [11]
3.3.2. Virtualización de recursos
La virtualización de recursos consiste en la abstracción individual de un componente

o recurso de un ordenador, como puede ser la red, el almacenamiento o la entrada y
salida. Los ejemplos más representativos de este paradigma de virtualización son el uso
de memoria virtual, los sistemas RAID (Redundant Array of Independent Disks), LVM
(Logical Volume Manager ) o la virtualización de red. En función de la abstracción y la
tecnologı́a se pueden clasificar a su vez en varios subtipos:
Encapsulación: Consiste en ocultar la complejidad y las caracterı́sticas del re-

curso abstrayendo el mismo y creando una interfaz simple. [11]
Memoria virtual: Se trata de la técnica de gestión de memoria que permite

que el sistema operativo disponga de mayor cantidad de memoria de la que está
disponible fı́sicamente. En este caso, el recurso abstraı́do es la memoria y el
disco. La mejor representación de este modelo es el conocido espacio para Swap,
empleado en sistemas Unix. [11]
Virtualización del almacenamiento: Virtualización del sistema de almacena-

miento fı́sico. Consiste en abstraer completamente el hardware de almacenamien-
to en componentes lógicos. Se incluyen en este grupo las mencionadas tecnologı́as
RAID o LVM, ası́ como también SAN (Storage Area Network ), NAS (Network-
Attached Storage), NFS (Network File System) o iSCSI (Internet SCSI ). [11]
Virtualización de red: Se fundamenta en la creación de direcciones de red

virtuales dentro de una red o entre subredes. El recurso abstraı́do es en este caso
la propia red. Como ejemplos destacados en este campo se encuentra la creación
de VPN’s a través de software como OpenVPN o OpenSwarm o la virtualización
de switches y routers. [11]
Unión de interfaces de red: Puede englobarse dentro de la virtualización de

red o tratarse de forma independiente. Es también conocido como NIC Bonding
o EtherChannel y consiste en crear varios enlaces de red que son usados como un
único enlace de mayor ancho de banda. El recurso abstraı́do son los enlaces de red
o interfaces de red. Soluciones ejemplo son vHBA (Virtual Host Bus Adapter ) y
vNIC (Virtual Network Interfaces Card ). [11]
Virtualización de la E/S: En este tipo de modelo se produce la abstracción

de los protocolos de capas superiores de las conexiones fı́sicas o del transporte
fı́sico. Ejemplos: Xsigo Systems o 3Leaf Systems. [11]
Virtualización de la memoria RAM: Trata de conseguir la unión de me-

morias RAM de varios sistemas conectados en red para conseguir una memoria
común de mayor capacidad. [11]
3.3.3. Virtualización de aplicaciones
Consiste en la encapsulación y ejecución de las aplicaciones sobre un sistema opera-

tivo (virtualizado o no). Es decir, permite ejecutar aplicaciones en sistemas operativos
para los cuales no fueron implementadas, proporcionando ası́ portabilidad y compatibi-
lidad. Usualmente, la aplicación se descarga bajo demanda y se ejecuta en un entorno
virtual protegido sin que modifique el equipo local o interfiera con otras aplicaciones.
Presentan las ventajas de reducir el coste y el tiempo de mantenimiento, el disponer

de la aplicación en cualquier momento y lugar, la posibilidad de instalar más de una
versión de una aplicación y la no degradación del sistema operativo al ser instalada.
Los ejemplos destacados y conocidos en este grupo son Microsoft App-V, Citrix
XenApp o VMware Thinapp. [11]
3.3.4. Virtualización de biblioteca (API)
La virtualización a nivel de biblioteca emula porciones de un sistema operativo

implementando una API especı́fica. En este caso, el entorno virtual se limita a la emu-
lación de una determinada API, lo que permite ejecutar binarios compilados para un
operativo en otro sistema operativo diferente.
Ejemplos de este grupo son WineHQ (reimplementación de la API de programa-

ción de aplicaciones Windows que permte su ejecución en entornos UNIX), o Cedega
(conocido anteriormente como WineX ), que es un fork no libre de Wine diseñado pa-
ra ejecutar juegos de ordenador de Windows en entornos GNU/Linux (básicamente
implementa la API de DirectX). [11]
3.3.5. Virtualización de escritorios
Consiste en la manipulación de forma remota del escritorio de usuario (aplicaciones,

archivos y datos), que se encuentra separado de la máquina fı́sica, almacenado en un
servidor central. Será mayormente el tipo de virtualización abordado en este trabajo,
por consistir en la implantación de una infraestructura de este tipo en la Univesidade
da Coruña y será tratado de forma más completa en sucesivos apartados. [11]
3.4. Virtualización de escritorios o VDI
Durante décadas, el entorno tradicional TIC se ha desarrollado en una infraestruc-

tura en la que cada usuario tiene su propio PC con una CPU dedicada, un sistema
operativo instalado a nivel local y un disco duro que contiene todas las aplicaciones.
En una organización, todos estos usuarios de un sistema convencional se administran
a través de un servidor de red, que ocasionalmente, puede incluir espacio de almacena-
miento adicional para discos de red compartidos. Es el personal del departamento de TI
el encargado de mantener todas las configuraciones, licencias, actualizaciones y demás
labores de administración comunes, de forma independiente en cada una de las máqui-
nas. Este es un modelo que funcionó correctamente durante décadas pero ahora, son
muchos los factores que están impulsando a las organizaciones a considerar soluciones
más eficientes y seguras.
La virtualización de escritorios o VDI (Virtual Desktop Infraestructure) consiste en

la configuración de varios equipos virtuales en un servidor fı́sico para la optimización
de los recursos disponibles. Es, en esencia, la creación de un ordenador virtual que
se almacena en un servidor de virtualización de manera remota, en lugar de estar
almacenado en el propio computador.
Esta técnica, permite que múltiples máquinas virtuales, con sistemas operativos he-
terogéneos entre sı́, funcionen aisladamente unas de otras dentro de una misma máquina
fı́sica. Como es evidente, cada máquina virtual posee su propio hardware virtual (me-
moria RAM, disco duro, procesador, CPU, tarjeta de red, etc) sobre el cual se ejecuta
un sistema operativo con sus correspondientes aplicativos de la misma manera que lo
harı́an como si se tratase de un equipo convencional. La idea básica de esta arquitectura
se ejemplifica en la Figura 3.8.
Figura 3.8: Representación básica de una arquitectura VDI
Esta infraestructura, permite a los usuarios acceder remotamente a sus escritorios

desde cualquier dispositivo (PC, portátil, smartphone, etc) y desde cualquier lugar,
poniendo a disposición del usuario o empleado su entorno de trabajo.
Las infraestructuras VDI permiten que múltiples usuarios de la red mantengan de

forma independiente sus escritorios individuales en un único servidor, habitualmente
localizado en un Data Center2 . Los usuarios pueden conectarse a su escritorio mediante
una red de área local (LAN), mediante una red de área extensa (WAN) o a través de
Internet.
A priori, una vez explicado, puede suceder que el término de virtualización de

escritorios resulte confuso o en la práctica, equivalente a la virtualización de servidores,
pues igualmente se habla de máquinas virtuales a las que usuarios o administradores
pueden acceder a través de algún protocolo.
La diferencia radica en la infraestructura en su conjunto, es decir, la virtualización

de servidores hace referencia al particionamiento de un servidor fı́sico en varios ser-
vidores virtuales, con el objetivo de aprovechar el hardware. En este caso el software
de virtualización es empleado para dividir el servidor fı́sico y administrar todas esas
2
Un data center o centro de procesamiento de datos (CPD) es una ubicación donde se
concentran los recursos necesarios para el procesamiento de información de una organización.
máquianas virtuales.
Por otra parte, la virtualización de escritorios o hace referencia a la “virtualización

del cliente” (mayor orientación hacia los usuarios), esto es, es la que permite realizar
una separación fı́sica entre el escritorio y el ordenador fı́sico. Se trata básicamente de
un modelo de virtualización cliente-servidor, de tal forma que aunque haga uso de
máquinas virtuales (igual que la virtualización de servidores), una infraestructura VDI
permite a mayores tareas de monitorización y administración de usuarios y aplicaciones,
ası́ como un control centralizado y controlado de todos los escritorios de los usuarios.
3.4.1. Conceptos básicos
Dentro del ámbito de la virtualización de escritorios existen una serie de conceptos

propios de la temática que deben ser definidos y aclarados previamente, ya que apare-
cerán frecuentemente en el resto de las secciones, al igual que los ya mencionados en la
sección de conceptos básicos de virtualización [3.1.1].
3.4.1.1. Thin client
La definición de thin client o cliente ligero engloba tanto un software como un

equipo hardware real y, de forma básica, se podrı́a definir como la tecnologı́a hardware
o software que permite el acceso a una máquina virtual o escritorio virtual remoto,
siendo en el servidor donde se realizarán las tareas de computación. Es decir, su única
labor residirá en transportar la entrada y la salida entre el usuario y su escritorio
virtual. Existen dos tipos diferenciados:
Thin client software: En términos de software, un cliente ligero es un programa

que es en gran parte una interfaz simple. El usuario del software de cliente ligero
ve los datos, herramientas y caracterı́sticas como lo harı́a en sistema operativo
normal, pero realmente, es otro programa que se ejecuta en un servidor remoto
y que realiza el trabajo. Puede ser tanto un software cliente instalado sobre S.O
o bien puede como un pequeño sistema operativo en sı́ mismo que únicamente
permita el acceso a un escritorio virtual almacenado en un servidor remoto.
Thin client hardware: Básicamente, se trata de un pequeño equipo (similar a

un ordenador de sobremesa, pero de muy pequeño tamaño), carente en la mayorı́a

de los casos de disco duro, pues su tarea reside únicamente en realizar la conexión
con el servidor externo y proporcionar al usuario su escritorio virtual, manejando
los datos de entrada y salida del mismo. La práctica totalidad de fabricantes de
hardware presentan en el mercado algún dispositivo de este tipo. En la Figura 3.9
se puede apreciar la solución de la empresa Dell, la adoptada en la Universidade
da Coruña para la infraestructura actual de escritorios Windows.
Figura 3.9: Equipo thin client Dell Wyse, usados en la infraestructura actual de
la UDC para la conexión con escritorios Windows
3.5. Ventajas e Inconvenientes
Una vez realizado un recorrido completo por los conceptos básicos de la virtuali-
zación, su historia y sus diferentes tipos se pasa ya a centrar toda la atención en la
materia que trata este trabajo: la virtualización de escritorios. Es por ello que en este
apartado se buscará y revisará el porqué hoy en dı́a la tecnologı́a VDI ha cobrado tanta
importancia dentro del sector empresarial hasta llegar a ser uno de los sectores punteros
en cuanto a su uso y proyección.
Para ello, es fundamental estudiar y analizar todas las razones y causas que han
motivado este auge ası́ como también los posibles problemas o desventajas que este tipo
de infraestructuras pueden tener. Si bien es cierto, que aunque muchas de ellas serán
aplicables a todos los ámbitos, es muy importante antes de la realización de cualquier
proyecto barajar todas las ventajas y desventajas en particular, pues muchas veces lo
que para un ámbito u organización puede ser favorable para otros puede ser un gran
problema.
3.5.1. Ventajas
Como es lógico, serán mayorı́a, pues en caso contrario su implantación estarı́a caren-
te de sentido. A continuación se enumeran algunas de sus caracterı́sticas más importan-
tes muchas de ellas comunes a cualquier otro tipo de infraestructura de virtualización
y no exclusivamente propias de VDI.
3.5.1.1. Aprovechamiento de hardware
Es muy habitual que muchos de los servidores ubicados en Data Centers de or-
ganizaciones estén utilizando una pequeña parte de su potencia total de computación
(entre un 15 % y 20 % en muchos casos), lo que conduce a un desperdicio considerable
del hardware disponible.
Es aquı́ donde surge el rol de la virtualización, permitiendo que un sólo equipo

servidor almacene a su vez diversos sistemas. Por lo tanto, el uso de virtualización en
las organizaciones pueden elevar las tasas de utilización del hardware y hacer un uso
más eficiente de los mismos, lo que se traducirá, a largo plazo en un aumento de la
productividad y del capital empresarial.
Esta caracterı́stica se ve fortalecida por el gran incremento del potencia de cálculo

de las máquinas actuales, las cuales son capaces de mover una gran cantidad de servicios
virtualizados gracias al continuo crecimiento de la industria del chip, sobre todo en lo
referente con las extensiones de virtualización VT-Intel y AMD-V.
En resumen, se puede decir que trata de reducir el número de servidores hardware al

mismo tiempo que aumenta el porcentaje de su utilización. Esta estrategia es conocida
como consolidación de servidores. [11]
3.5.1.2. Eficiencia energética
Se trata de una ventaja derivada en gran parte de la anterior, pues realmente, una
lleva a la otra. Hasta hace años, los recursos y costes energéticos eran totalmente asu-
mibles sin dificultad por cualquier organización, pero desde hace un tiempo, todas las
empresas comenzaron a considerar la escasez y encarecimiento de la energı́a, surgiendo
de este modo la necesidad de buscar alternativas para aumentar la eficiencia energéti-
ca de sus infraestructuras. Es decir, tratar en la medida de lo posible de reducir la
dependencia energética.
Es en este punto donde la virtualización de escritorios entra en juego, ya que un

estudio de 2008 realizado por The Climate Group3 indica que la implantación de es-
critorios remotos y la virtualización de servidores en una organización puede disminuir
el consumo energético hasta una tercera parte. Esto es debido, en gran medida a los
altos costes de climatización, que se verán reducidos de forma muy significativa, pues
el reducir el número de equipos hardware, reduce la potencia necesaria para el enfria-
miento. [11]
3.5.1.3. Ahorro de espacio
Como consecuencia del imponente crecimiento de las tecnologı́as de la información,

todas las empresas y organizaciones han sufrido un crecimiento masivo de sus infraes-
tructuras, llegando a situaciones de agotamiento del espacio disponible para sus centros
de datos.
Ante esta situación, y con la posibilidad de aglutinar varios servicios dentro del
mismo hardware, se evitan los costes de la ampliación de espacio del centro de datos. [11]
3.5.1.4. Administración de sistemas simplificada
Todo el mundo sabe que las tareas de administración de sistemas pueden llegar a
ser intensas y laboriosas, además de que en una gran mayorı́a de los casos los adminis-
tradores de sistemas deben estar ubicados junto a los servidores de los centros de datos,
ya que en ocasiones es probable que se necesite acceso fı́sico al hardware para realizar
ciertas operaciones tanto de substitución de componentes, como de monitorización.
El uso de la virtualización de escritorios ofrece una administración sencilla y cen-

3
Es una organización sin ánimo de lucro que trabaja internacionalmente con empresas y
gobiernos para tratar de promover las energı́as limpias, ası́ como también polı́ticas de ahorro
energético y emisiones contaminantes.
tralizada de todas sus actividades (lo que reducirá los costes de mantenimiento), como
puede ser la provisión de máquinas virtuales de forma automática (gracias a técnicas
de clonación de máquinas o las virtual appliances4 ), el proceso de copia de seguridad o
la restauración de las mismas. Desaparecen también muchas de las labores de adminis-
tración que antes eran fı́sicas, ya que los sistemas administrados pasan a ser instancias
de máquinas virtuales.
Es importante remarcar aquı́ (dada la importancia de este punto) que por norma
general, el número de máquinas (virtuales o no) de las que es responsable un adminis-
trador en una organización siempre será el mismo, por lo que es fundamental de cara
a su trabajo, mantener la infraestructura lo más independiente posible de los sistemas
fı́sicos, algo que se consigue con la virtualización de escritorios. [11]
3.5.1.5. Alta disponibilidad y recuperación ante desastres
Trata de reducir en la medida de lo posible los tiempos de parada de los servicios y

los datos crı́ticos de una organización, algo que se ve facilitado por la implantación de
escritorios VDI al incluir mecanismos como la migración de máquinas. Si un sistema
fı́sico falla, los sistemas virtuales contenidos en él pueden ser migrados o redistribuidos
en caliente o dinámicamente a otros sistemas. [11]
3.5.1.6. Alto rendimiento y redundancia
Se trata de una caracterı́stica compatible con la anterior por la facilidad de mantener

sistemas virtuales redundados en diferentes sistemas fı́sicos, además de aumentar el
rendimiento (P.ej: procesamiento en paralelo o balanceo de carga). Todo ello facilita la
recuperación ante desastres. [11]
3.5.1.7. Seguridad
La virtualización de escritorios hace que todos los datos de los usuarios de los
escritorios, y por lo tanto de las organizaciones, se almacenen de forma centralizada en
los servidores y absolutamente nada a nivel local. De este modo, el único punto de fallo
4
Instancias de máquinas virtuales ya preconfiguradas
pasa a ser el servidor, mientras que en una arquitectura convencional se puede producir
la pérdida o robo de datos o fallos de seguridad en cualquier ordenador.
Otro de los ámbitos donde se ve mejorada la seguridad, es en las aplicaciones y los

operativos, pues al ser aislados independientemente (cada máquina virtual es indepen-
diente entre sı́), el acceso o ataque a un aplicativo afectará sólo y exclusivamente a él
mismo. [11]
3.5.1.8. Reducción de costes
La aplicación de la técnicas de virtualización de escritorios supone un ahorro de

costes en prácticamente todos los campos. Esto permite a organizaciones y empresas
destinar los esfuerzos y recursos en otras tareas como innovación o desarrollo.
Como ya se comentó anteriormente, también permite ahorrar costes en la adqui-

sición de nuevo hardware (consolidación de servidores), reducir los costes en infra-
estructura de refrigeración (al necesitar menos hardware, menores serán los costes de
enfriamiento) o el precio de cada puesto de trabajo (mediante el uso de thin clients[3.9]).
3.5.1.9. Escalabilidad
Una infraestructura virtual proporciona caracterı́sticas de escalabilidad muy supe-

riores a una fı́sica tradicional. Al tratarse de máquinas virtuales lógicas, un servidor
puede gestionar un gran número de máquinas. De esa forma, si se necesita cualquier
servicio o ante necesidades crecientes de la organización, únicamente se debe crear la
máquina virtual correspondiente. En cambio, si la estructura fuese convencional, serı́a
necesario adquirir un nuevo servidor o integrar el servicio en uno existente (En el mejor
de los casos). [11]
3.5.1.10. Compatibilidad hacia atrás
Otra de las caracterı́sticas indispensables de estas infraestructuras, es la posibilidad

que ofrecen para el uso y mantenimiento de sistemas y aplicaciones heredados que no
fueron adaptados a versiones actuales, y por lo tanto sin compatibilidad en sistemas de
hoy en dı́a. En una infraestructura VDI requiere únicamente crear una máquina virtual
con el sistema necesario, lo que la hace una solución ideal y simple para casos en los
cuales es necesario continuar empleando software antiguo o heredado.
3.5.1.11. Clústers virtuales
Posibilidad de creación de clústeres de servidores virtuales para unificar múltiples

servidores en un único sistema. Presenta por tanto en este caso, todas las caracterı́sti-
cas propias de un clúster fı́sico, a las cuales se añaden muchas de las citadas para
infraestructuras VDI. El ejemplo más claro, serı́a la creación de un clúster totalmente
personalizable, con opción de añadir recursos hardware en función de la demanda de
los servicios ofrecidos por el mismo. [11]
3.5.1.12. Personalización y flexibilidad
Prácticamente cualquier elemento de una infraestructura VDI es personalizable y

configurable, desde el hardware empleado por las máquinas virtuales hasta cualquier
opción y configuración (sobre todo en muchas soluciones como Xen o QVD que son
Open Source).
3.5.2. Inconvenientes
Antes de aplicar o implantar una infraestructura de escritorios virtuales es comple-

tamente indispensable tener claro las posibles desventajas que puedan surgir una vez
realizada su puesta en marcha, ya que en determinadas organizaciones, algunas de ellas
pueden provocar el derrumbe de un proyecto de virtualización.
3.5.2.1. Disminución del rendimiento
Aunque todas las empresas que ofrecen soluciones VDI trabajan diariamente en
tratar de aumentar el rendimiento, como es normal, la ejecución de una máquina vir-
tual no ofrece (y es posiblemente nunca ofrecerá) un rendimiento igual o superior a la
ejecución totalmente equivalente sobre la máquina fı́sica.
Estas pequeñas pérdidas de rendimiento son producidas por la introducción de capas

intermedias, entre la capa fı́sica y la lógica, como son los hipervisores [3.1.1.2], o bien
otros factores como la propia aplicación o el tipo de virtualización empleado. [11]
3.5.2.2. Punto único de fallo
Es uno de los inconvenientes más importantes, sobre todo en organizaciones en las

cuales un fallo puede suponer grandes pérdidas (P. ej: Actividades financieras). Un
problema en el servidor provocará la caı́da de todas las máquinas virtuales corriendo
en el mismo.
Es muy importante tratar de realizar una correcta planificación de los proyectos de

virtualización, para que cubran correctamente posibles problemas de este tipo mediante
disponibilidad y recuperación ante fallos. Algunas de las soluciones más comunes son
la redundancia de hardware (replicación de la infraestructura VDI al completo), redun-
dancia de máquinas virtuales (en servidores distintos), haciendo uso del clustering y
definiendo una correcta polı́tica de administración y monitorización. [11]
3.5.2.3. Dependencia de la solución elegida y el operativo anfitrión
Una parte importante de los proyectos VDI, recae en el análisis y la posterior

selección de la solución a implantar, que será crucial en todos los aspectos. Dicha
decisión estará claramente condicionada por el servicio a ofrecer, pues cada una de
ellas ofrece caracterı́sticas diferentes para entornos distintos.
Por otro lado se encuentra la elección del sistema operativo anfitrión, algo muy
importante también, pues de él colgará el control de una serie de máquinas virtuales
(estabilidad y seguridad). [11]
3.5.2.4. Hardware y vı́deo
Tal y como se comentó en secciones anteriores, en la mayorı́a de los casos no es

posible utilizar hardware que no esté soportado por el hipervisor [3.1.1.2], y es el pro-
pio software de virtualización el que establece la tecnologı́a hardware a las máquinas
virtuales, lo que puede traer problemas derivados de la incompatibilidad por parte de

ciertas aplicaciones.
Aademás no es posible en casi ningún caso disponer de aceleración de vı́deo por

hardware, lo que provoca que muchas aplicaciones que necesitan vı́deo 3D no funcionen
correctamente sobre las máquinas virtuales. Bien es cierto, que existen algunos casos
como VMware o Parallels que soportan OpenGL5 y DirectX6 , pero ofrecen rendimientos
muy inferiores al de una máquina fı́sica. [11]
Otro de los problemas dentro de la temática hardware, es el efecto colateral de la

disminución de ventas de hardware provocado por la continua implantación de infra-
estructuras de este tipo en las organizaciones. Bien es cierto, que aunque se produzca
una disminución en las ventas, el hardware comprado debe ser de una potencia supe-
rior y es por ello que las grandes empresas como Intel o AMD han apostado por la
virtualización.
3.5.2.5. Número de máquinas virtuales
La existencia de máquinas virtuales innecesarias provoca un mayor consumo y una

disminución general del rendimiento de los servidores, por lo que no es aconsejable la
creación de máquinas sin control y por lo tanto, el uso de los recursos y número de
máquinas virtuales debe ser acorde a las condiciones (más que un inconveniente innato
de las infraestructuras VDI es un problema derivado de la mala administración).
3.5.2.6. Complejidad añadida y nuevos problemas
Aunque en la mayorı́a de los casos las actividades de administración se ven me-

joradas, si es cierto que pueden existir casos (sobre todo durante la implantación) en
los cuales el efecto sea el contrario. Dicha complejidad se verá agravada por ejemplo,
por trabajar con varias soluciones de administración al mismo tiempo, o en el caso de
la administración de la red, la cual se complica bastante (cada máquina virtual dis-
pondrá ahora de una o varias interfaces de red propias, lo cual complicará también la
5
Se trata de una serie de librerı́as y especificaciones estándar que definen un API multipla-
taforma para el desarrollo de aplicaciones con gráficos 2D y 3D.
6
Son una serie de API’s creadas y desarrolladas para facilitar tareas multimedia en entornos
Windows.
Ventajas Inconvenientes
Aprovechamiento de hardware Pérdida de rendimiento
Eficiencia energética Punto único de fallo
Administración simplificada Aceleración 3D
Ahorro de espacio Dependencia de la solución
Compatibilidad hacia atrás Dependencia del anfitrión
Alta disponibilidad Hardware soportado
Recuperación ante fallos Punto único de fallos
Escalabilidad Incremento complejidad
Consolidación de servidores Servidor compartido
Reducción de costes Alto desembolso inicial
Seguridad y aislamiento -
Backups -
Aprovisionamiento de máquinas -
Reducción servidores fı́sicos -
Clonación de máquinas -
Personalización y flexibilidad -
Automatización simple -
Cuadro 3.1: Tabla resumen de las ventajas e inconvenientes que proporciona una
infraestructura de escritorios virtuales VDI
configuración del firewall y otras actividades relacionadas).
Además de la complejidad añadida, surgen en este ámbito nuevos problemas oca-

sionados por la introducción de nuevas tecnologı́as y componentes. Ejemplos de esto
pueden ser el conocer qué máquinas se encuentran en cada servidor fı́sico, qué máquinas
se encuentran actualmente en funcionamiento, el balanceo de carga o el manejo de las
licencias de software para cada una de las aplicaciones de cada una de las máquinas
virtuales.
3.6. Soluciones en el mercado actual
La tecnologı́a de la virtualización de escritorios es un estándar que actualmente

se ofrece bajo el amparo de los distintos fabricantes de soluciones de herramientas de
virtualización. En esta sección se procederá a describir de forma breve algunas de las
soluciones VDI más conocidas que se pueden encontrar actualmente en el mercado.
3.6.1. VMware Horizon View
Se trata de la solución comercial de escritorios virtuales proporcionada por la em-

presa VMware, Inc. Esta solución encuentra implantada y completamente funcional
en la infraestructura de la Universidad, para la virtualización de escritorios Microsoft
Windows.
Sus primeras dos versiones (2.0.0 y 2.1.0) eran conocidas bajo el nombre de VMware
VDM posteriormente renombradas a VMware View y no siendo hasta su última versión
cuando se le da el nombre de VMware Horizon View.
Se trata de una infraestructura que proporciona el uso y las caracterı́sticas de la

virtualización de escritorios, pero únicamente para los operativos de Microsoft.
Dentro de VMware Horizon View se encuentran a su vez, una serie de productos

y componentes caracterı́sticos de VMware (vSphere, vCenter, Thinapp, vShield, etc),
todos ellos necesarios para posibilitar la completa implantación de la infraestructura
VDI.
VMware Horizon View se comercializa a través de dos posibles licencias, Enterprise

o Premier, siendo esta última la más cara por incluir mayor número de caracterı́sticas.
[16]
3.6.2. Microsoft VDI
Solución de escritorios virtuales de Microsoft, basada en este caso en la tecnologı́a

de Windows Server 2012 junto con los Servicios de Escritorio Remoto (RDS) y el
hipervisor Hyper-V de Microsoft. [19]
3.6.3. Citrix XenDesktop
Citrix XenDesktop es la solución VDI ofrecida por Citrix para la virtualización de

escritorios, orientada únicamente a la virtualización de escritorios Windows a través
también de Windows Server 2012. [18]
3.6.4. Citrix VDI in a BOX
Es las solución ofrecida por Citrix para la pequeña y mediana empresa. La idea
original, fue desarrollada por la empresa Kaviza, pero en Mayo de 2011 es adquirida
por Citrix Systems Inc, la cual se hace cargo del proyecto.
Citrix VDI-in-a-Box es una solución “todo en uno” y arquitectura monoservidor

de fácil implantación y alcance para cualquier empresa.
En comparación con la anterior solución (Citrix XenDesktop), está es una solu-

ción más simple, tanto en configuración como administración, más ligera (en requisitos
hardware) y más barata. Aunque VDI-in-a-Box ofrece una gran escalabilidad que per-
mitirı́a ser implantada en una gran empresa, Citrix recomienda en dicho caso optar por
la solución anterior, por ofrecer caracterı́sticas más avanzadas y ser más adaptable a
los diferentes entornos existentes en grandes organizaciones. [17]
3.6.5. Oracle VDI
Es el producto de virtualización de escritorios ofrecido por Oracle, nacida a partir

de varios proyectos ya iniciados por la antigua Sun Microsystems.
Se trata de una solución para escritorios Windows equivalente a las anteriores y

compatible con los productos de virtualización más conocidos: VMware vSphere, Mi-
crosoft Hyper-V, etc. [20]
3.6.6. Ulteo
Ulteo Open Virtual Desktop nace en el 2007 como una solución de virtualización
de escritorios y aplicaciones siguiendo los principios del código abierto. Se trata de
una solución flexible por soportar tanto Windows como Linux, caracterı́stica que la
hará ideal para ser analizada de cara a una posible implantación en la Universidade da
Coruña. [12]
3.6.7. QVD
Es otro de los productos de virtualización susceptibles de ser analizados en este

trabajo. Se trata de una solución de VDI de código abierto, altamente escalable y
basada completamente en Linux. Será analizada en detalle en su momento. [2]
3.6.8. RedHat Enterprise Virtualization for Desktops
Por último, otro de las soluciones que serán analizadas en detalle en este proyecto
como una posible alternativa. Red Hat Enterprise Virtualization for Desktops es la
solución VDI que ofrece la conocida empresa Red Hat. Destaca por ofrecer un hipervisor
KVM (al igual que QVD) y emplear un procolo de comunicación con el escritorio propio,
Spice 7 . Como es lógico por parte de Red Hat, ofrece sólo virtualización para escritorios
Linux. Será analizada en detalle en posteriores apartados. [14]
7
the Simple Protocol for Independent Computing Environments, es un sistema de comunica-
ción de pantalla remota para sistemas de virtualización.
Capı́tulo 4
Virtualización de escritorios en la
UDC
Índice general
4.1. Situación de partida . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.2. Usuarios y personal . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.3. Situación actual . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.3.1. ¿Por qué VDI? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.3.2. Infraestructura VDI . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.3.3. ¿Por qué VDI Linux? . . . . . . . . . . . . . . . . . . . . . . . . 51
La Universidade de Coruña es una institución pública que tiene como principal

objetivo la generación, la gestión y la difusión de cultura y del conocimiento cientı́fico,
tecnológico y profesional a través de la investigación y la docencia. Es por todo esto
que el soporte de las tecnologı́as de la información desempeña un papel fundamental
e indispensable, ya que constituye una de las áreas de especial relevancia dentro de la
formación e investigación de nuestra universidad.
Por ello, este capı́tulo será dedicado a tratar de forma breve y especı́fica las tecno-
logı́as actuales en la UDCası́ como también realizar una explicación de la situación de
partida y de las necesidades actuales, dentro de las cuales se encuentra la virtualización
de escritorios Linux.
46
4.1. Situación de partida
La Universidade da Coruña se caracteriza en gran parte por el equipamiento y la

infraestructura informática de la que dispone, encontrándose en un puesto claramente
aventajado en este ámbito dentro de la comunidad autónoma.
Cuenta actualmente con un amplio abanico de servicios disponibles para toda la

comunidad, los cuales se entregan gracias al conjunto de sistemas de sus dos Centros de
Procesado de Datos, ubicados en el Edificio de Servicios Centrales de Investigación y en
el edificio del Rectorado. Además, todo esto, se complementa con el resto de equipos,
servidores, impresoras y demás infraestructura repartida a lo largo de las veinticuatro
facultades y escuelas, cuarenta y tres departamentos y otros edificios de administración.
Básicamente, la microinformática de la que dispone la universidad y a la que da

servicio es la siguiente:
Puestos de acceso a la información, tanto interna como de la comunidad cientı́fica

y estudiantes.
Puestos de prácticas y formación para estudiantes y profesores.
Puestos de trabajo técnico y administrativo para el personal de administración

y servicios.
Puestos de trabajo, docencia e investigación, para el personal docente e investi-

gador.
Acceso a impresión desde cualquier dispositivo.
Elementos móviles del personal.
4.2. Usuarios y personal
Aunque a primera vista pueda parecer que el número de usuarios a los que se da
servicio en la universidad no sea tan elevado, lo cierto es que los números en su conjunto
son significativos y claramente superiores incluso al de grandes empresas del sector TIC:
Cuenta con un estudiantado medio anual de veinticinco mil alumnos, con dife-
rentes exigencias y necesidades.
El personal docente roza las mil quinientas personas, que incluye tanto al profe-
sorado como al personal investigador (PDI).
La administración y los servicios cuentan con casi ochocientos trabajadores.
Para dar soporte, cobertura y mantenimiento a todo este personal y realizar la

gestión de todos los sistemas de la universidad, ésta cuenta con un reducido número de
personal en comparación con el número de usuarios, lo que trae consigo que la búsqueda
de soluciones eficientes y fácilmente administrables sea una de las prioridades.
Básicamente, el personal técnico con el que cuenta la universidad son cincuenta y

nueve personas agrupadas en ocho departamentos, de los cuales, involucrados en la ad-
ministración de los sistemas y concretamente en VDI se encuentran fundamentalmente
los departamentos:
Centro de atención al usuario (CAU): Consta de dieciocho personas. Se encargan

de inventariar todos los puestos de trabajo, ofrecer todo tipo de ayuda a los
usuarios, gestionar software y realizar pruebas de aplicaciones.
Red de comunicaciones y datos: Formado por seis trabajadores. Encargado de

administrar, gestionar y monitorizar toda la red de comunicaciones de la univer-
sidad que interconectan todos los centros.
Sistemas de Internet e Intranet: Consituido por siete técnicos. Encargado de la

administración tanto de los sistemas y servicios informáticos.
4.3. Situación actual
Hasta hace menos de un año, la situación actual de la universidad era la de cualquier

organización hasta la aparición de la virtualización:
Elevado número de equipos hardware anticuados y arquitectura x86.

Uso de equipos Microsoft Windows XP en un elevado porcentaje y Windows 7

de forma reducida.
Uso de roaming profiles 1 y redirección de carpetas para la centralización de los

datos del usuario en servidores de ficheros. Uso de técnicas de VPN y acceso
remoto para accesos a los equipos de los usuarios desde el exterior.
Sistemas de gestión centralizadas basadas en técnicas de clonación para las Au-

laNet con software como FOG 2 o Rembo 3 .
4.3.1. ¿Por qué VDI?
Además de los innumerables ventajas de un entorno VDI descritas en la sección

3.5, el entorno de la UDC buscaba una serie de objetivos difı́cilmente alcanzables sin
la puesta en marcha de una infraestructura de este tipo: dar servicio a través de los
dispositivos móviles, conseguir una migración rápida de Windows XP a Windows7, y
sobre todo, reducir el trabajo de operación y mantenimiento. Por otro lado, existen una
serie de condicionantes básicos y caracterı́sticos que marcan el por qué de la necesitad
de la existencia de una infrastructura VDI en la UDC:
Facilitar al estudiante y personal investigador acceder a su escritorio, sus datos

y sus aplicaciones desde cualquier lugar.
Reducir el tiempo de puesta en funcionamiento de nuevos equipos, aplicaciones

o servicios, algo que mejora notablemente el rendimiento en un entorno docente.
Mejora de la seguridad y la pérdida de datos, al centralizar el almacenamiento

en un servidor central amparado por una estricta polı́tica de copia de seguridad.
Homegeneizando los sistemas operativos y aplicaciones.
Reutilización de hardware. Aumento de la vida útil de equipos con varios años y

reducción del consumo de energı́a. De esta forma se favorece el ahorro de costes
1
Es un concepto de la familia de sistemas de Microsoft conocido como perfiles móviles de
usuario, que consiste en proporcionar movilidad al usuario. Es decir, en almacenar los datos de
los usuarios de forma centralizada y que estos se carguen tras un proceso de login en su puesto
de trabajo.
2
http://www.fogproject.org/
3
http://rembowiz.sourceforge.net/sysadm/main.shtml
que repercutirá positivamente en la calidad de la enseñanza pública, al poder

destinar los fondos hacia otros campos como la investigación.
La mejora en la administración permite destinar al personal TIC a otras tareas

de mejora en soporte, como puede ser la Docencia.
La decisión final del uso de VMware como solución de virtualización de escritorios

Windows está amparada por una gran cantidad de análisis de soluciones y proyectos
pilotos llevados a cabo por el personal técnico de la universidad desde el año 2009 hasta
el 2012, donde la balanza se decanta por Horizon, por su rendimiento y adaptabilidad
al entorno.
4.3.2. Infraestructura VDI
La infraestructura VDI para Windows de la universidad cuenta con una serie de

elementos software y hardware que hacen posible dar servicio a casi mil usuarios de
forma simultanea. A continuación se enumeran los equipos hardware y el software
necesario para todo el servicio. Es importante hacer notar que todos los equipos se
encuentran replicados en ambos CPD (Edificio de Servicios Centrales de Investigación
y Rectorado) para dotar ası́ de replicación y alta disponibilidad al sistema. En la Figura
4.1 se muestra un esquema de la distribución de los equipos dentro de los armarios rack.
Infraescructura Hardware
• Para escritorios virtuales:
◦ 10 Servidores HP SL230s Gen8 . 16 x 2.2GHz Quad-Core Intel®Xeon®E5-

2660 64-bit. Memoria: 128GB RAM.
◦ 37,8 TB Brutos de almacenamiento SAN.
◦ 22 TB Netos Network RAID 10.
◦ Conectividad 10GbE.
Figura 4.1: Distribución de las máquinas en los armarios rack
• Para administración:
◦ 2 Servidores HP DL360 Gen8. 12 x 2.3GHz Intel®Xeon®E5-2630.

64GB de memoria.
Infraescructura Software
• VMware Horizon View 5.2

• VMware Thinapp
• VMware Horizon Workspace 5.2
• vSphere 5.1
• vCenter Server 5
4.3.3. ¿Por qué VDI Linux?
Aunque el orden de prioridades establecen que la infraestructura Windows debı́a ser

la primera, son muchos los factores y condicionantes que hacen que sea necesaria la pre-
sencia de una infraestructura de virtualización de escritorios Linux en la Universidade
da Coruña.
Necesidades técnicas del alumnado: Existen ciertos grupos de alumnos de

enseñanzas técnicas que requieren el uso de distribuciones Linux para la elabo-
ración de sus prácticas. El ejemplo más claro es el alumnado de la Facultad de
Informática.
Necesidades del personal investigador: Departamentos o grupos de inves-

tigación que hacen uso de herramientas y caracterı́sticas propias de los sistemas
Linux.
Necesidad de entornos aislados: Creación de entornos aislados entre sı́ que

permitan un rápido despligue y una fácil configuración y gestión de las máquinas
virtuales. Un ejemplo claro son ciertas asignaturas de la Facultad de Informática,
en la que es necesario disponer de una máquina virtual por alumno, que permita
la total manipulación de la misma sin problemas de corrupción de datos o fallos
de seguridad.
Flexibilidad: Sirve como perfecto complemento a la infraestructura Windows,

de tal forma que permita al usuario flexibilizar la decisión de emplear un siste-
ma operativo u otro. Posibilidad de arranque dual de escritorio virtual Linux o
Windows.
Fomento, promoción y difusión del software libre y los estándares

abiertos: Como disciplina fundamental de la UDC, el uso del software libre
se ve profundamente reflejado al disponer e una infraestructura de este tipo.
Capı́tulo 5
Alternativas
Índice general
5.1. Ulteo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.1.5. Soporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2. QVD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.5. Soporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3. Red Hat Enterprise Virtualization: Spice . . . . . . . . . . . . 67
5.3.1. Descripción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3.4. Soporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.4. Comparativa de productos . . . . . . . . . . . . . . . . . . . . . 70
53
5.4.1. Comparativa de las versiones de pago . . . . . . . . . . . . . . . 70

5.4.2. Comparativa de las versiones gratuitas . . . . . . . . . . . . . . . 73
5.5. Solución a implantar . . . . . . . . . . . . . . . . . . . . . . . . 76
Son muchas las soluciones existentes en el mercado para llevar a cabo la implanta-
ción de un sistema de virtualización de escritorios Linux. Es en este momento donde
se presenta la difı́cil tarea de seleccionar y decidir cuál será la adecuada de cara a la
Universidade da Coruña.
Actualmente, ya existe una infraestructura de virtualización para escritorios Win-

dows montada sobre Vmware. Es por esto, que será necesario tratar de acercarse lo
máximo posible a esta solución, debido a su fácil adaptación al entorno, facilidad de
mantenimiento y el ya conocimiento por parte de los administradores. Tras un estudio
previo de las posibles alternativas realizado por el Servicio de Informática de la Univer-
sidad, se pueden considerar tres de cara a la implantación VDI: Ulteo, QVD o Red Hat.
En sucesivos apartados se realizará un análisis de cada una de ellas y una exhaustiva
comparativa de las mismas para finalmente decidirse por la más adecuada.
5.1. Ulteo
5.1.1. Descripción
Ulteo Open Virtual Desktop (OVD) es un proyecto que nace en el año 2007 bajo la
entidad comercial de Ulteo SAS. Se trata de una aplicación o plataforma de virtuali-
zación de escritorios basada en GNU/Linux que nace con el objetivo de proporcionar
un sistema no propietario, de código abierto, seguro y escalable para la implatación de
escritorios virtuales.
OVD está preparada para soportar tanto la virtualización de escritorios Windows

como escritorios Linux o aplicaciones SaaS1 . Básicamente, permite a las organizaciones
o empresas integrar y proporcionar escritorios virtuales con un acceso seguro por parte
1
Software as a service, es un modelo de distribución de software donde el soporte lógico y los
datos que maneja se alojan en servidores de una compañı́a TIC (Tecnologı́as de la información
y comunicación. Dichos servicios son accedidos desde un navegador web de un cliente.
de los clientes. [13]
5.1.2. Caracterı́sticas
Se exponen a continuación las caracterı́sticas fundamentales del proyecto OVD de

Ulteo, realizando una clasificación temática en función del rango de aplicación de la
caracterı́stica. [12]
Caracterı́sticas de la plataforma
• Escalable: Ofrece una correcta manipulación y control de la carga dando

un posible soporte de hasta 50.000 usuarios (Evidentemente, en muchos
casos la limitación de usuarios vendrá impuesta por la infraestructura).
• Hi-Def: Buena definición de pantalla para ofrecer una correcta visualiza-
ción del escritorio para acercarse lo máximo posible a una experiencia de
usuario similar a la de un escritorio nativo.
• Seguridad: Permite el acceso a los escritorios remotos tanto desde LAN’s2
como WAN’s3 y es completamente compatible con SSL o VPN’s4 .
• Servidores de ficheros: Ofrece un entorno de persistencia para almacenar
los datos personales y de configuración (P.ej: El perfil de un usuario Linux).
• Compatibilidad con Vmware: Es una caracterı́stica que lo hace ideal
para organizaciones que disponen ya de infraestructuras Vmware. Permite
complementarla, añadiendo a esta una el soporte para escritorios Linux.
Además Ulteo incorpora herramientas o métodos que facilitan dicha inte-
gración.
Caracterı́sticas entregables
2
Local Area Network o red de área local es una red que se emplea para interconectar equipos
de una misma compañı́a u organización.
3
Una Wide Area Network es una red que abarca varias ubicaciones fı́sicas, proveyendo servi-
cio a una zona, un paı́s o incluso a varios continentes. Se trata básicamente de una red encargada
de unir varias redes de área local.
4
Una VPN o “Virtual Private Network” es una tecnologı́a de red que permite una exten-
sión segura de una red local sobre una red pública insegura o no controlada. Permite enviar
información por una red pública con todas las funcionalidades de una red privada
• Compatibilidad: La infraestructura Ulteo destaca por su compatibilidad

con la virtualización de escritorios Linux y Windows, permitiendo ası́ a
las organizaciones seleccionar el sistema operativo que más se adapte a
sus necesidades. Es por tanto también compatible con cualquier aplicación
destinada a operar en cualquiera de estos dos sistemas.
• Modo “Portal”: Permite iniciar aplicaciones desde el Navegador o nati-
vamente desde el host anfitrión dentro de la intranet de la organización,
es decir, presenta la oportunidad de ejecutar aplicaciones directamente sin
necesidad de acceder al escritorio virtual.
• Integración: Integración del escritorio dinámica de tal forma que la expe-
riencia de usuario sea similar a ejecutar la aplicación o el escritorio local-
mente.
• Modo “Kiosk”: Es un modo que permite restringir a los usuarios las
aplicaciones que estos pueden ejecutar.
• Otras caracterı́sticas: Soporte de sonido, control de impresoras locales y
compartición de portapapeles entre el escritorio virtual y el escritorio virtual
(“Copy & Paste”).
Carecterı́sticas de mantenimiento
• Gestión centralizada: Proporciona una consola web que permite la con-

figuración, el mantenimiento, la gestión y monitorización centralizada de
servidores, usuarios y aplicaciones.
• Asistente: Incorpora una completa guı́a para facilitar las labores de confi-
guración y mantenimiento.
• Integración de la consola: Proporciona una consola que puede ser inte-
grada en otros frameworks de administración.
• Integración de dominios: Permite establecer control de acceso a través
de dominios ya existentes, es decir, permite facilitar la autenticación a los
escritorios virtuales a través de sistemas como el “Microsoft Active Direc-
tory”, “LDAP” o “Novell eDirectory” [Apéndice B.
• Sistema de alertas por e-mail: Presenta un sistema de monitorización
que permite el envı́o de correos electrónicos a los administradores para in-
formar del estado del sistema.
• Balanceo de carga: Proporciona la posibilidad de balancear automática-

mente la carga de los servidores en función de los escritorios virtuales en
activo.
5.1.3. Comparativa de versiones
Ulteo presenta dos posibles soluciones o versiones: “Ulteo OVD Community Edi-
tion” o “Ulteo OVD Premium Edition”, enfocadas hacia entornos diferentes. [12]
Ulteo OVD Community Edition: Se trata de la versión base de la plataforma

Ulteo. Es la opción gratuı́ta y proporciona las funcionalidades pertenecientes al
núcleo de la aplicación, es decir, las funcionalidades más básicas. Serı́a la versión
adecuada para uso particular o de pequeña empresa.
Ulteo OVD Premium Edition: Es la versión adecuada para importantes in-

fraestructuras de virtualización de empresas medianas o grandes. Ofrece mejores
capacidades que la anterior. Es necesario un contrato de suscripción de Ulteo
(SA).
En la Tabla 5.1 se ofrece una comparativa de versiones. Dicha tabla está compuesta
por una serie de caracterı́sticas, una descripción de las mismas y la indicación de en
qué versiones está disponible dicha caracterı́stica.
5.1.4. Requisitos técnicos
Los requisitos técnicos de la infraestructura Ulteo, se dividen por componentes.

Se muestran a continuación, por tanto, los requisitos mı́nimos para cada uno de los
componentes necesarios en la implantación de una infraestructura Ulteo [12]
Servidores de aplicación OVD: CPU dual o quad-core. RAM 1GB o más

para 15 usuarios concurrentes. Sistemas operativos mı́nimos soportados: Ubuntu
10.04, RHEL 5.2 o 5.3, CentOS 5.2+, Fedora 10, OpenSuSE 11.2, o superiores.
5
Se trata de un mecanismo de autenticación basado en “tokens”, que pueden ser generados
por herramientas hardware o software. Dicho token se emplea para generar posteriormente un
código de autenticación.
Caracterı́stica Descripción Community Premium

Las aplicaciones están instaladas
en un data center y están dispo-
nibles remotamente a los usuarios
Hosting de aplicaciones a través del escritorio virtual. Uso
de las mismas de forma análoga a
las aplicaciones de escritorios na-
tivos.
Compatibilidad con sistemas ope-
S.O Compatibles
rativos Windows y Linux.
Integración de las aplicaciones
virtualizadas en el escritorio local,
es decir, ejecución de aplicaciones
Integración de las aplicaciones ×
remotas desde el escritorio local
como si se tratase de una aplica-
ción instalada de forma nativa.
Modo que proporciona un gestor
de archivos y la posible ejecución
“Modo portal”
de aplicaciones desde un navega-
dor web.
Modo que permite restringir a
ciertos usuarios ciertas aplicacio-
“Modo kiosk” nes, es decir, permite seleccionar
las aplicaciones que un usuario
puede ejecutar.
Conexión al escritorio remoto a
Cliente web través de un navegador web com-
patible con Java.
Acceso al escritorio virtual a
Cliente nativo Windows través de un software nativo des- ×
de S.O Windows.
Cliente nativo Linux través de un software nativo des- ×
de S.O Linux.
Cliente iOS través de un cliente para iPhone ×
e iPad.
Cliente Android través de un cliente para dispo- ×
sitivos Android.
Cuando existe más de un servidor
de escritorios virtuales Ulteo pro-
Balanceo de carga porciona un balanceo de carga en-
tre ellos para alcanzar el máximo
rendimiento.
Mecanismo de reconexión o recu-
peración de una sesión estableci-
Recuperación de sesiones
da en caso de interrupción del ser-
vicio.
Sistema de monitorización, “log-
Monitorización y reporte
ging” y reporte de incidencias.
Caracterı́stica Descripción Community Premium

Sistema de envı́o de correos
Alertas por correo electrónicos a los administradores
en caso de incidencias.
La consola de administración per-
mite establecer varios niveles de
delegación de los administrado-
Administración delegada
res, es decir, permite establecer
niveles en los derechos de admi-
nistración.
Permite configurar o establecer
dominios para el control de acce-
so. La autenticación de usuarios
Control de acceso
puede ser facilitada por distintos
sistemas como LDAP o “Active
Directory”.
Acceso al los escritorios virtuales
SSL VPN haciendo uso de VPN mediante el ×
protocolo SSL.
Soporte para autenticación a
RSA SecureID través de RSA SecureID ((Two ×
factor authentication support)5 .
Cuadro 5.1: Comparativa de versiones de Ulteo

Servidores administradores de sesión OVD: Cualquier CPU Pentium x86

con 1GB o más RAM. Soporta los mismos sistemas operativos que el anterior.
Servicios de directorio: LDAP, e-Directory, ZENwork y Active Directory.
Servidores de ficheros: CIFS o cualquier servidor WebDAV embebido.
5.1.5. Soporte
El soporte de Ulteo es uno de sus puntos fuertes, destacando fundamentalmente

por ofrecer un soporte de nivel tres en sus versiones de suscripción [12].
Un soporte de nivel tres es el nivel de mayor capacidad para resolver problemas.

Es conocido también como soporte de alto nivel. Un soporte de este nivel estipula
que cualquier problema será atendido por profesionales expertos en el campo, ası́ como
también personal de investigación y desarrollo para crear soluciones a problemas nuevos
y desconocidos. Es de suponer también que se trata de un soporte a disponibilidad
completa, es decir, que en caso de incidencia habrá un servicio técnico disponible las
veinticuatro horas del dı́a, los siete dı́as de la semana y durante todo el año (24x7x365 ).
Básicamente, se puede considerar el soporte ofrecido por Ulteo un soporte completo

para cualquiera de sus versiones de suscripción.
5.2. QVD
QVD es un proyecto open-source (código abierto) del grupo Quindel Group y que
proporciona una infraestructura para la implantación de escritorios virtuales Linux en
una organización.
Se trata de una alternativa a un precio asequible, altamente escalable, fácil de gestio-

nar y que permite tanto la virtualización de escritorios como la disponer de aplicaciones
en la nube (Saas). Es una solución flexible que permite soluciones escalables y de bajo
costo para una gran cantidad de usuarios.
La filosofı́a de la empresa QVD es presentar independencia tecnológica y ahorro.

Es por ello que se centra principalmente en ofrecer escritorios Linux a los usuarios, con
el objetivo de reducir los costes de licencias y fomentar la adopción de la tecnologı́a de
código abierto [1].
QVD presenta una serie de caracterı́sticas básicas completamente equivalentes a las

de cualquier otro software de virtualización disponible en el mercado. [2]
Alta densidad: Ofrece la posibilidad de ejecutar múltiples máquinas virtuales

a partir de una o más imágenes en un solo nodo de la red. Permite por tanto,
reutilizar una imagen de sistema base para varias máquinas virtuales. Al ejecutar
varias imágenes por nodo permite dar servicio a un elevado número de usuarios.
Balanceo de carga: Dispone de un sistema de balanceo de carga automático

que lo hace adecuado para ser implantado en clústers de un servidor. Dispone de
una serie de servicios para asegurarse de que el cliente que se conecte a cualquier
nodo del servidor se redirige al nodo correcto.
Alta disponibilidad: Presenta la posibilidad de determinar automáticamente

que nodo servidor del clúster tiene la mayor parte de recursos disponibles, lo que
ayuda a asegurar una alta disponibilidad de los entornos de escritorio.
Autoprovisión: En QVD cada usuario es identificado de forma independiente

a través de un nombre y una contraseña, de tal forma que se puede asignar una
imagen de escritorio por usuario.
QVD permite establecer su propio nombre de usuario y contraseña o integrar
dicho sistema con sistemas de autenticación externos como LDAP o “Active
Directory”.
Clientes: QVD presenta clientes software para Linux y Windows, al igual que
un cliente Android que actualmente se encuentra en desarollo.
Simplemente ejecutando alguno de estos clientes, el usuario puede tener acceso a
su propio escritorio virtual.
Administración web: Proporciona herramientas de lı́nea de comandos, lo que

permite ejecución de scripts o trabajar a través de SSH6 . Además, QVD tiene un
completo entorno de administración web, lo que facilita la tarea del administra-
dor.
Seguridad: Alto nivel de seguridad. Proporciona un entorno aislado a nivel de

máquina, de tal forma que cualquier compromiso a nivel de máquina virtual sólo
afectará al escritorio en ejecución. El mal comportamiento de una máquina no
afecta a las máquinas de los demás usuarios.
Por otra parte, la conexión con los escritorios virtuales se realizará a través de
SSL/TLS de tal forma que todas las comunicaciones entre un cliente y el servidor
están securizadas.
Acceso remoto: QVD hace uso de una versión modificada de NX7 , lo que permi-
te reducir la carga de ancho de banda. Ofrece distintos algoritmos de compresión
en función de la configuración del usuario (usuarios con alto o bajo ancho de
banda).
Cliente ligero QVD: La solución QVD proporciona un cliente ligero que permi-
te que los usuarios experimenten una relación más transparente con los escritorios
virtuales. Es decir, el cliente ligero software de QVD, hace las funciones de siste-
ma operativo anfitrión, de tal forma que le presenta únicamente al usuario una
ventana de login tan pronto como inicia el ordenador.
6
SSH o “Secure Shell” es un protocolo para acceder remotamente a una máquina a través
de la red. Permite manejar remotamente una máquina a través del intérprete de comandos.
7
Software que realiza conexiones remotas X11 muy rápidas, lo que permite a los usuarios
acceder a escritorios remotos Linux o Unix bajo conexiones lentas. Es un protocolo que propor-
ciona una alta eficiencia en la conexión gracias a una correcta compresión.
Soporte de migración: Muchas empresas frecuentemente disponen ya de una

serie de sistemas o infraestructuras de escritorios y bases de datos de usuarios.
QVD proporciona asistentes de migración de infraestructuras anteriores a la nue-
va infraestructura.
Imagenes preconfiguradas: QVD ofrece ayuda para la construcción de imáge-

nes de sistemas operativos. Ofrecen la posibilidad de enviar una serie de reque-
rimientos, a partir de los cuales generan una imagen de un sistema operativo
adaptada a las necesidades de cada organización.
Integración de dominios: Permite establecer control de acceso a través de

dominios ya existentes, es decir, permite facilitar la autenticación a los escritorios
virtuales a través de sistemas como el “Microsoft Active Directory” o “LDAP”.
5.2.3. Comparativa de versiones
La solución o infraestructura de escritorios virtuales QVD ofrece tres versiones

distintas, enfocadas cada una de ellas hacı́a un público diferente. [2]
QVD Community Edition: Versión gratuita destinada fundamentalmente pa-

ra desarrolladores, testers o para uso particular sencillo. Está fundamentalmente
orientada hacia instalaciones de un único servidor de pruebas y poco crı́tico.
QVD Online Suscription: Es la versión intermedia con el objetivo principal

de ser asentada en pequeñas y medianas empresas que poseen administradores
de sistemas propios.
QVD Enterprise Edition: Versión más completa y como es lógico, más cara.
Está destinada a organizaciones relativamente grandes o con infraestructuras
crı́ticas que requieren unas necesidades altamente funcionales y con un soporte
completo.
Al igual que para Ulteo, se realizó una comparativa de versiones en la de aquellas

caracterı́sticas más importantes de QVD. Dicha comparativa se expone en la Tabla 5.2.
8
En fase beta.
9
En fase beta.
Caracterı́stica Descripción Community Online Suscription Enterprise

Consiste en el núcleo de funciona-
lidades de QVD, es decir, aque-
llas funcionalidades más básicas
QVD Core (Se incluyen aquı́ las caracterı́sti-
cas de Alta disponibilidad, balan-
ceo de carga, autoprovisión, etc,
vistas en la Sección 5.2.2).
Cliente Windows través de un software nativo des-
de S.O Windows.
Cliente Linux través de un software nativo des-
de S.O Linux.
Cliente OS X través de un software nativo des- 8
de S.O MAC OS X.
Posiblidad de conectarse al escri-
Cliente Android torio virtual con un dispositivo 9
Android
Posiblidad de conectarse al escri-
Cliente iOS torio virtual con un dispositivo × ×
iOS (iPhone & iPad).
Incluye una herramienta de ges-
tión, monitorización y control a
Herramienta de administración web
través de una sencilla interfaz
web.
Existencia de algún plan de so-
Soporte prioritario porte (Se comentarán en la Sec- ×
ción 5.2.5).
Solución de problemas en linea y
Soporte por e-mail y online personalizado a través de correo ×
electrónico
Correción de bugs y acceso a los
Actualizaciones prioritarias repositorios internos de QVD con ×
actualizaciones.
Opción de que QVD proporcio-
Imágenes personalizadas ne imágenes de S.O personaliza- ×
das bajo unos requisitos.
Mini S.O que ejerce las funciones
Software de cliente ligero × ×
de Thin Client.
QVD ofrece la posibilidad de cer-
tificar las instalaciones software y
Certificación de las instalaciones × ×
hardware bien por ellos mismos o
por un partner autorizado.
Cuadro 5.2: Comparativa de versiones de QVD

Las especificaciones técnicas o requisitos mı́nimos de un sistema QVD es una de sus

ventajas, pues al tratarse en su base de un sistema operativo Linux, bajo condiciones
teóricas, los requisitos mı́nimos de los equipos servidores podrı́an ser los mismos que
para una instalación de un operativo Linux en un ordenador convencional.
Aunque no existen unos requisitos mı́nimos de instalación, es evidente de que serán

necesarios mejores equipos en la infraestructura cuanto mayor sea el servicio que se
desea ofrecer a los usuarios (Por ejemplo, un usuario medio que emplee su escritorio
virtual para navegación e ofimática puede emplear alrededor de 200 o 300 megabytes
de memoria RAM y otros 200 megabytes de espacio en disco). Esto quiere decir, que
los requisitos mı́nimos de instalación vendrán dados por el propio diseño y el futuro
uso de la infraestructura. [2]
5.2.5. Soporte
QVD ofrece un soporte prioritario para los clientes suscritos a alguna de sus ver-
siones de pago. Aunque acepta envı́os de error y peticiones de mejora por parte de los
usuarios de las versiones gratuitas, la solución QVD ofrece a sus usuarios suscritos una
gran preferencia en el caso de errores, de tal forma que los desarrolladores e ingenieros
se ocupan directamente de cualquier problema.
QVD ofrece dos sistemas de soporte distintos en en función del plan contratado. Uno
de ellos es el sistema “Siguiente-Dı́a-Laborable” (8x5), es decir, ofrecido en la versión de
“Online Suscription” que proporciona una respuesta rápida pero dentro de los cinco dı́as
laborables de una semana. El otro de los sistemas de soporte es el 24x7x365 (ofrecido en
la versión “Enterprise Edition”), en el cual se ofrece solución a incidencias a cualquier
hora del dı́a durante los siete dı́as de la semana.
En lo referente al soporte, dispone también de una amplia base de datos de pro-

blemas y soluciones, que incluye una gran cantidad de problemas frecuentes, con sus
respectivas guı́as de solución y gran variedad de scripts.
Además, ofrece la posibilidad de configuración de soporte remoto, opción ideal para

organizaciones en las que el equipo informático sea reducido. El personal de soporte de
QVD puede colaborar remotamente en las labores de administración, haciendo uso de

protocolos como SSH. [2]
5.3. Red Hat Enterprise Virtualization: Spice
SPICE o Simple Protocol for Independent Computing Enviroments es la solución

de escritorios virtuales presentada por la empresa Red Hat. Se trata de un protocolo de
rendering remoto, adaptativo y de código abierto (open-source) que emplea se emplea
en la infraestructura Red Hat Enterprise Virtualization for Desktops para conectar los
usuarios con sus escritorios virtuales.
Está basada en el Red Hat Enterprise Virtualization Hypervisor10 , una máquina

virtual KVM [Apéndice B] y el proyecto de virtualización abierta oVirt11 .
La empresa Red Hat se diferencia de las dos anteriores, por tanto, en que además de
aportar una solución a la infraestructura de escritorios, esta utiliza su propio protocolo
(SPICE). [14]
Al igual que se realizó con sus dos competidores anteriores, se muestran aquı́ las
caracterı́sticas fundamentales de la solución de Red Hat. Es importante remarcar que
Red Hat Enterprise Virtualization comprende todos los productos y caracterı́sticas, es
decir, no existen diferentes versiones, por lo que para esta solución no tiene sentido la
realización de la tabla comparativa de versiones. [14]
Rendimiento: La empresa Red Hat ofrece como una de sus principales carac-
terı́sticas un gran rendimiento y una gran robustez de sus sistemas. Ofrece un
alto rendimiento en operaciones E/S12 , lo que la hace adecuada para entornos
de grandes cargas de trabajo (P.ej: Entornos con grandes bases de datos como
10
Un hipervisor o monitor de máquina virtual es una plataforma que permite aplicar diver-
sas técnicas de control de virtualización para utilizar, al mismo tiempo, diferentes sistemas
operativos, en un mismo ordenador.
11
Se trata de una plataforma libre de gestión y mantenimiento vı́a aplicación web de infraes-
tructuras de virtualización.
12
Operaciones de entrada-salida.
Oracle). Certifica su alto rendimiento en las pruebas SPECvirt13 en las cuales

se demuestra un alto rendimiento incluso con un número elevado de máquinas
virtuales en un mismo nodo servidor.
Flexibilidad: Al igual que sus dos competidores, otra de sus caracterı́sticas fun-
damentales es su flexibilidad propiciada fundamentalmente por ser código abierto,
lo que permite una amplia personalización. Además la solución Red Hat posibi-
lita la virtualización tanto de escritorios Linux como Windows y está preparada
para trabajar también con aplicaciones empresariales como Oracle, SAP y SAS.
Por último, también ofrece una gran flexibilidad en cuanto a integración con
servicios externos, ya que proporciona una serie de plug-ins que permiten una
integración perfecta con herramientas de terceros.
Gestión centralizada: Sistema de gestión centralizada a través de una interfaz

gráfica pensada para controlar, gestionar y monitorizar grandes cantidades de
equipos. Es decir, ofrece un portal de administración que proporciona todo tipo
de información.
Gestión empresarial: Permite la migración de aplicaciones y datos en vivo,

alta disponibilidad de los mismos y equilibrio de la carga de trabajo basado
en polı́ticas (balanceo de carga). Aprovisiona de herramientas que permiten la
generación de informes e históricos para poder ofrecer una ı́ntegra información
del sistema.
Seguridad: Proporciona un nivel de seguridad a nivel de kernel y asegura la

solución de vulnerabilidades crı́ticas en el máximo de 24h.
Desarrollo: La solución Red Hat proporciona una API Restful, que permite
la programación propia de utilidades o aplicaciones para la infraestructura. Es
también completamente integrable con OpenStack 14 .
Portal de usuario autoservicio: Sercicio de administración propio para los

usuarios. Permite a los usuarios finales aprovisionarse de máquinas virtuales por
sı́ mismos, al igual que definir plantillas y administrar su máquina/s virtuales.
13
www.spec.org
14
Es un proyecto de computación en la nube para proporcionar una infraestructura como
servicio (IaaS), bajo la filosofı́a del software libre y código abierto distribuido. Básicamente, se
trata de un proyecto para el desarrollo de plataformas cloud.
Almacenamiento flexible: Admite cualquier tipo de almacenamiento y siste-

mas de ficheros: iSCASI, Fibre Channel, NFS, almacenamiento local, almacena-
miento Red Hat y cualquier otros sistemas compatibles con el estándar POSIX.
El entorno Red Hat Enterprise Virtualization presenta una serie de requerimientos

de sistema mı́nimos para cada uno de sus componentes. Son los siguientes [14]:
Red Hat Enterprise Virtualization Manager: Recomendado 1-2 quad core

x86 64 processors, 16GB de RAM, 50GB de disco y una conexión ethernet gigabit.
Red Hat Enterprise Virtualization Hypervisor: Recomendaciones mı́nimas

de 1 CPU Intel 64 o AMD64 con las extensiones hardware para virtualización
AMD-VTM o Intel VT. Memoria RAM mı́nima 2GB de RAM y 10GB de alma-
cemiento local. Conexión ethernet gigabit.
5.3.4. Soporte
Red Hat presenta dos tipos de soporte en función del plan contratado: Bussiness-
hour y 24x7x365. Como es evidente, el primero de ellos es un soporte en horas labora-
bles, es decir, durante 8 horas diarias los dı́as de semana, mientras que la segunda de
las opciones ofrece un soporte completo durante todo el año.
Por otra parte, es importante destacar que para implantar una infraestructura de
virtualización Red Hat, es necesaria también una suscripción de Linux Red Hat (Red Hat
Enterprise Linux ) en cada servidor de la infraestructura y cada una de estas licencias
es vendida de forma separada a la licencia de la infraestructura (Red Hat Enterprise
Virtualization), lo que incrementa los costes en caso de no disponer ya de licencias o
servidores Red Hat en el data center. [14]
5.4. Comparativa de productos
Una vez realizado el análisis pormenorizado de cada una de las posibles alternativas
es necesario realizar una exhaustiva comparativa de las mismas poniendo especial aten-
ción en aquellas caracterı́sticas indispensables, por ser necesarias en el entorno en el que
se realizará la implantación de la infraestructura. Por otra parte, como es evidente, se
omitirán en la comparativa aquellas caracterı́sticas innatas de los sistemas analizados
o aquellas que pueden darse por supuestas (P.ej: Compatibilidad con escritorios Linux
es una caracterı́stica evidente y alta disponibilidad, alta densidad y balanceo de carga
son caracterı́sticas que todas las soluciones poseen).
Dadas las caracterı́sticas de la Universidade da Coruña y el entorno en el que se

realizará la instalación del sistema, la solución ideal serı́a la implantación de cualquiera
de las soluciones anteriores en sus versiones “enterprise” destinadas a ser implantadas
organizaciones con grandes infraestructuras informáticas y que precisan de un soporte
de calidad. Por ser este un proyecto piloto y carente de presupuesto, la implantación
del sistema de virtualización deberá ser realizada con alguna de las versiones gratuitas
de las soluciones anteriores.
Teniendo en mente una posible ampliación del proyecto de cara a un futuro cercano,
se realizará tanto la comparativa de las versiones más completas, como de las versiones
gratuitas. De este modo, se podrá tomar una decisión final objetiva y siempre conside-
rando la posibilidad de que en un futuro el sistema sea migrado hacia una versión más
completa.
5.4.1. Comparativa de las versiones de pago
A continuación se muestra en una serie de tablas la comparativa de Ulteo, QVD y

Red Hat en sus versiones más completas. La división es la siguiente:
Tabla 5.3: En la primera de las tablas se ofrece una comparativa de los distintos
clientes de acceso al escritorio virtual. Se trata de una caracterı́stica que ofrece
movilidad y flexibilidad al usuario y es por ello que debe ser considerada.
Tabla 5.4: Se muestra la comparación de las caracterı́sticas relacionadas con

la instalación, configuración y administración del sistema, centrándose en aque-
llas consideradas fundamentales para la organización en la cual el sistema será

implantado.
Tabla 5.5: La tercera de las tablas ofrece la comparación entre los distintos tipos
de soporte, ası́ como sus caracterı́sticas.
Tabla 5.6: Comparativa de precios. Aunque para la realización de este proyecto

se empleará alguna de las versiones gratuitas, es importante mostrar una compa-
rativa de los precios de las versiones más avanzadas de cara a un posible cambio
hacia las versiones de pago en un futuro.
Caracterı́stica Descripción Ulteo QVD SPICE

Cliente Windows través de un software nativo des-
de S.O Windows.
Cliente Linux través de un software nativo des-
de S.O Linux.
Cliente OS X través de un software nativo des- × 15 ×
de S.O MAC OS X.
Acceso al escritorio virtual con un
Cliente Android 16 ×17
dispositivo Android
Cliente iOS × ×
dispositivo iOS (iPhone & iPad).
Cliente Web × ×
través de un navegador web
de Thin Client.
Cuadro 5.3: Comparativa de los clientes de acceso al escritorio de las alternativas
16
En fase beta.
17
No dispone de aplicación oficial, aunque si hay una aplicación compatible con el protocolo
SPICE: aSPICE.

Administración a través de una
Administración web
completa interfaz web.
Administración delegada × ×
nistración.
Control de acceso
Directory”.
Ofrece compatibilidad con el sis-
Compatibilidad CIFS o NFS
tema de ficheros CIFS o NFS
Proporcionar imágenes de S.O
Imágenes personalizadas personalizadas bajo unos requisi- × ×
tos.
Permitir la integración y comple-
Compatibilidad con Vmware mentación de una infraestructura × ×
Vmware existente.
Cuadro 5.4: Comparativa de caracterı́sticas relacionadas con la administración y

monitorización

Soporte Plan de soporte 24x7x365 8x5 o 24x7x365 8x5 o 24x7x365
Resolución de problemas a través

Soporte por e-mail de correo electrónico con respues-
ta rápida.
Resolución de problemas simples
Soporte online ×
a través de una aplicación web.
Cuadro 5.5: Comparativa de caracterı́sticas relacionadas el soporte ofrecido


Planes de precios de las versiones
Precio ND18 Desde 90 euros 19
Desde 999 dólares 20
más completas y avanzadas.
Cuadro 5.6: Comparativa de precios de los servicios
5.4.2. Comparativa de las versiones gratuitas
Aunque la comparativa anterior es imprescindible, de cara a este proyecto, se debe

poner especial atención en las versiones que no son de pago, pues una de estas será la
solución a implantar. Se realizará por tanto una comparativa de las posibles soluciones
gratuitas, descartando en este punto la opción de Red Hat, por no disponer de una
alternativa de este tipo (únicamente dispone de una versión de prueba de 30 o 60 dı́as).
Los puntos comparativos serán análogos a los del punto anterior, por ser los más
importantes. Se muestran en las Tablas 5.7, 5.8 y 5.9.
18
No disponible.
19
Precio por usuario y para la contratación de más de 5000 usuarios. Entre 2500 y 5000
usuarios el precio es 96 euros . Entre 1000 y 2500 el precio es 102 euros . Entre 500 y 1000
usuarios el precio es 108 euros y para menos de 500 usuarios 120 euros . Precios anuales y
durante el primer año. Se reducen significativamente en años posteriores.
20
Precio con soporte básico 8x5. El precio con el soporte 24x7x365 es de 1.499 dólares. Estos
precios son anuales y por cada Hypervisor Socket Pair contratado.
Caracterı́stica Descripción Ulteo QVD

Cliente Windows través de un software nativo des- ×
de S.O Windows.
Cliente Linux través de un software nativo des- ×
de S.O Linux.
Cliente OS X través de un software nativo des- × 21
de S.O MAC OS X.
Cliente Android × 22
dispositivo Android
Cliente iOS × ×23
dispositivo iOS (iPhone & iPad).
Cliente Web ×
través de un navegador web
de Thin Client.
Cuadro 5.7: Comparativa de los clientes de acceso al escritorio
21
En fase beta.
22
En fase beta.
23
En proyecto.

Administración a través de una
Administración web
completa interfaz web.
Administración delegada ×
nistración.
Control de acceso
Directory”.
Ofrece compatibilidad con el sis-
Compatibilidad CIFS o NFS
tema de ficheros CIFS o NFS
Ofrece compatibilidad con infra-
Compatibilidad con VMware × ×
estructuras VMware
Cuadro 5.8: Comparativa de caracterı́sticas relacionadas con la administración y

monitorización

Soporte Plan de soporte Comunidad Comunidad24
Resolución de problemas a través
Soporte por e-mail de correo electrónico con respues- × ×
ta rápida.
Resolución de problemas simples
Soporte online × ×
a través de una aplicación web.
Cuadro 5.9: Comparativa de caracterı́sticas relacionadas el soporte ofrecido

5.5. Solución a implantar
Tras realizar el estudio teórico comparativo anterior y descartar la solución de Red

Hat por no disponer de alternativas gratuita, se realizó un estudio práctico de las dos
soluciones candidatas: Ulteo y QVD.
La prueba práctica consistió únicamente en la realización de distintas pruebas con

las máquinas virtuales o appliances preconfiguradas que ambas soluciones proporcionan
para dicho fin. Las pruebas y análisis realizados sobre los productos fueron las siguientes:
Prueba y análisis de la interfaz de administración Web: El estudio rea-

lizado en este apartado consistió en analizar y estudiar las diferentes opciones
y herramientas de administración que incluye la interfaz web. Dentro de este
campo, las caracterı́sticas más importantes que se tuvieron en cuenta fueron:
sencillez, completitud, usabilidad, intuitividad y diseño. Tras una comparación a
la par entre Ulteo y QVD, se consideró más adecuada para este punto la interfaz
proporcionada por Ulteo, siendo mejor en todas las caracterı́sticas analizadas.
Prueba y análisis de los diferentes clientes software: Para el análisis de los

clientes software de conexión con el escritorio remoto fue necesaria la instalación
y configuración de los clientes (que cada solución proporciona en sus versiones
gratuitas) para cada una de las plataformas:
• Ulteo: Tal y cómo se muestra en la tabla comparativa 5.3 de la sección

anterior, la solución Ulteo en su versión gratuita (Community Edition) sólo
ofrece clientes de acceso al escritorio remoto a través del navegador, bien
a través del motor Java del navegador, como recientemente a través de
HTML5. Los clientes nativos para las plataformas móviles y de escritorio
sólo están disponibles en su versión de pago (Premium Edition).
• QVD: A diferencia de Ulteo, en este caso resulta mucho más completa
la solución de QVD, pues permite la descarga y el uso de todos los clien-
tes disponibles. Es importante destacar que aunque el cliente Android se
encuentre en fase beta, es completamente funcional. Del mismo modo, el
24
Hace referencia a un soporte proporcionado por la comunidad mediante el uso de foros
propios y externos, ası́ como también fuentes de información alternativas. La empresa se des-
preocupa de cualquier mal funcionamiento o fallo, siendo labor del administrador de sistemas
su resolución.
cliente iOS se encuentra en desarrollo y será posible también emplearlo con

la alternativa gratuita.
Prueba de rendimiento de los escritorios en los diferentes clientes soft-

ware: En relación al rendimiento de los escritorios se trata de una prueba de
difı́cil justificación inicial. Es decir, con el uso de las máquinas virtuales servidor
que las soluciones ofrecen para pruebas, ambas soluciones ofrecen un rendimiento
similar. El problema reside en la imposibilidad de realizar una prueba de ambas
soluciones en un entorno real y con una carga de trabajo real (con varias decenas
o centenas de usuarios). Es por ello, que según las pruebas realizadas sobre las
máquinas virtuales, se podrı́a decir que ambas soluciones ofrecen un rendimiento
equivalente.
Análisis general de las caracterı́sticas gratuitas: En el resto de carac-

terı́sticas de las versiones gratuitas prácticamente no se aprecian diferencias sig-
nificativas, pues ambas soluciones cubren completamente el campo de elementos
necesarios para una solución VDI básica: balanceador de carga, herramientas o
elementos para permitir el control de acceso o autenticación a través de Active
Directory o LDAP, mecanismos de autoprovisión de escritorios, aislamiento de
máquinas virtuales, etc. Una vez más, ambas soluciones son totalmente completas
y funcionales
Una vez analizados en detalle todos los puntos anteriores, llegó el momento decisivo
de tomar una decisión sobre la solución que se implantará en este proyecto piloto,
siempre teniendo en cuenta las perspectivas de ampliación del mismo en un futuro.
Aunque Ulteo fuese desde un primer momento una alternativa de muy posible im-
plantación, la carencia de clientes de acceso en sus versiones gratuitas hace que no sea
tan adecuada como QVD para el uso en la Universidad, pues esta última permite y
flexibiliza a los alumnos y personal el uso de los escritorios virtuales desde cualquier
dispositivo sin coste alguno, permitiendo seguir la filosofı́a BYOD (“Bring Your Own
Device”).
Bien es cierto, que QVD ofrece una interfaz web de administración con muchas
menos funcionalidades (muy básica), pero que se complementa a la perfección con una
serie de scripts de administración de fácil uso.
En definitiva se podrı́a considerar que la solución QVD fue la seleccionada para

favorecer desde un inicio a los usuarios de los escritorios remotos en detrimento de una
administración un poco más complicada de los escritorios.
Capı́tulo 6
Implantación
Índice general
6.1. ¿Qué es QVD? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
6.2. Componentes principales . . . . . . . . . . . . . . . . . . . . . . 82
6.3. Componentes secundarios . . . . . . . . . . . . . . . . . . . . . 84
6.4. Componentes internos . . . . . . . . . . . . . . . . . . . . . . . 85
6.4.1. L7R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.4.2. HKD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.5. Objetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.6. Arquitectura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.7. Tecnologı́as de virtualización . . . . . . . . . . . . . . . . . . . 93
6.7.1. Virtualización KVM . . . . . . . . . . . . . . . . . . . . . . . . . 94
6.7.2. Virtualización LXC . . . . . . . . . . . . . . . . . . . . . . . . . . 95
6.8. Diseño del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.8.1. Selección de la tecnologı́a . . . . . . . . . . . . . . . . . . . . . . 96
6.8.2. Diseño de la arquitectura de QVD . . . . . . . . . . . . . . . . . 97
6.8.3. Diseño de la arquitectura de red . . . . . . . . . . . . . . . . . . 99
6.9. Implementación del sistema . . . . . . . . . . . . . . . . . . . . 102
6.9.1. Configuración de la base de datos . . . . . . . . . . . . . . . . . . 103
6.9.2. Configuración del servidor de administración . . . . . . . . . . . 109
79
6.9.3. Configuración de los nodos QVD . . . . . . . . . . . . . . . . . . 114

6.10. Operación del sistema . . . . . . . . . . . . . . . . . . . . . . . . 120
6.10.1. Pruebas de funcionamiento . . . . . . . . . . . . . . . . . . . . . 120
6.11. Optimización del sitema . . . . . . . . . . . . . . . . . . . . . . 125
6.11.1. Autenticación externa . . . . . . . . . . . . . . . . . . . . . . . . 125
6.11.2. Auto provisión . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
6.11.3. Almacenamiento compartido . . . . . . . . . . . . . . . . . . . . 128
6.11.4. Balanceador de carga . . . . . . . . . . . . . . . . . . . . . . . . 132
6.11.5. Configuración del balanceador de carga . . . . . . . . . . . . . . 133
6.11.6. Configuración SSL . . . . . . . . . . . . . . . . . . . . . . . . . . 134
6.11.7. Componentes hardware . . . . . . . . . . . . . . . . . . . . . . . 135
6.11.8. Politica de copia de seguridad . . . . . . . . . . . . . . . . . . . . 136
6.11.9. Mejoras futuras . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
En este capı́tulo se tratará el núcleo del proyecto: la implantación de la solución de

escritorios virtuales QVD, por ser esta la solución más adecuada para la Universidade
da Coruña, tal y cómo dictamina el análisis realizado en la Sección 5.5.
Para ello, se realizará un recorrido previo por la solución comercial QVD: des-
cripción, arquitectura y componentes para posteriormente dar paso a su instalación y
adaptación en la infraestructura de la UDC.
6.1. ¿Qué es QVD?
QVD es la solución de escritorios virtuales ofrecida por la empresa Qindel Group,

una compañı́a internacional de consultorı́a especializada en proyectos y entornos Linux,
y en el ámbito de las tecnologı́as de la información en general [1], con sedes en España,
México y Colombia.
El software, está diseñado ı́ntegramente para ofrecer virtualización de escritorios

Linux. Los clientes se conectan a un servidor central que es el responsable de cargar
el entorno y las aplicaciones propias del usuario. De esta forma, cuando los usuarios
trabajan desde su máquina local (puede ser cualquier dispositivo: desde un ordenador
convencional hasta un teléfono móvil) todos los programas, aplicaciones, procesos y
datos son almacenados y ejecutados en un servidor, lo que trae consigo una serie de
ventajas [2]:
Los usuarios pueden cambiar de ordenador dentro de la red y continuar traba-

jando exactamente en su escritorio sin apreciar diferencias. Permite a los traba-
jadores total libertad en lo que se refiere al puesto de trabajo.
Los administradores tienen control total sobre las aplicaciones y datos que están
instaladas en los escritorios de los usuarios, facilitando de este modo las tareas
de backups, mejora continua de la seguridad o permitir cierto control sobre los
empleados.
Total flexibilidad en la autoprovisión1 de nuevos escritorios e instalación de apli-

caciones en los mismos.
Caracterı́sticas propias de los sistemas virtualizados, es decir, QVD ofrece cual-

quiera de las caracterı́sticas básicas de la virtualización, descritas en en el Capı́tu-
lo 3.
En lo referente a las tecnologı́as empleadas por QVD, destaca por ser una de las
únicas soluciones VDI para Linux que ofrece la posibilidad de seleccionar la tecnologı́a
de virtualización a bajo nivel deseada: KVM o LXC[Apéndice B] permitiendo imple-
mentar cualquiera de las dos opciones, en función de las necesidades de la organización
o la preferencia deseada por los administradores.
Por otra parte, permite servir diferentes sistemas operativos que son cargados a
través de imágenes de disco independientes, en los nodos de la infraestructura de QVD,
creando ası́ un entorno totalmente personalizado para un usuario o un grupo de usua-
rios. Ofrece una flexibilidad total y bajo el control de los administradores, permitiendo
servir, por ejemplo, un Linux diferente (diferentes distribuciones y con paqueterı́a o
caracterı́sticas propias) a los distintos departamentos de una organización.
Los usuarios acceden a su escritorio virtual a través de un cliente de acceso bajo

previa autenticación y mediante el uso del protocolo NX[Apéndice B], a su vez QVD
1
Consiste en la posibilidad de asignar de forma automatica escritorios a un usuario o un
grupo de usuarios
añade una seguridad adicional en el resto del proceso, enviando el tráfico cifrado me-
diante SSL y permitiendo ası́ acceder de forma segura desde cualquier localización y
desde cualquier dispositivo.
Aunque se verá con detalle en el siguiente apartado, la estructura y diseño de QVD

permite a cada usuario disponer de un entorno totalmente aislado, de tal forma que el
mal funcionamiento o cualquier tipo de problema en el entorno de un usuario no afecte
a los otros usuarios.
6.2. Componentes principales
Para construir una solución completa de escritorios virtuales mediante QVD es

necesaria la presencia de una serie de componentes que son indispensables para el
correcto y completo funcionamiento de la plataforma [3], tal y cómo se puede ver en la
Figura 6.1. Dichos componentes pueden estar presentes de forma conjunta en un sólo
nodo servidor (pequeñas instalaciones o destinadas a pruebas) o bien distribuirse en
diferentes nodos para entornos de producción.
Figura 6.1: Esquema básica de QVD
Los componentes principales de cualquier instalación QVD son básicamente tres:
Servidor o servidores QVD (1): Se trata del nodo/s de procesamiento en

los que se ejecutarán las máquinas o escritorios virtuales. Habitualmente (en
instalaciones reales) serán una serie de servidores formando una arquitectura
clúster. Es decir, varios nodos funcionando y configurados para dar servicio de
forma conjunta.
Servidor de administración (2): Será el encargado de ejecutar la interfaz de

administración que emplearán los administradores de QVD para realizar todas
las tareas de gestión de los escritorios.
Servidor base de datos (3): Básicamente se trata de un servidor con un SGBD,

que en el caso de QVD el SGBD es PosgreSQL. Éste contiene una base de datos
incluye toda la información acerca de los usuarios, máquinas, servidores, sistemas
operativos y configuraciones del entorno.
Clientes de acceso QVD (4): Se trata del conjunto de programas software

disponibles para las diferentes plataformas y que permiten el acceso al escritorio

virtual.
6.3. Componentes secundarios
Todos y cada uno de los componentes anteriormente mencionados son indispensables

para el funcionamiento básico de una infraestructura QVD, sin posibilidad de excluir
ninguno de ellos.
Además de esos componentes existen otros [3] que pese no ser completamente ne-
cesarios, están igualmente presentes en la práctica totalidad de las infraestructuras en
funcionamiento con un mı́nimo de usuarios. Dichos componentes se muestran en un
diagrama de ejemplo en la Figura 6.2.
Figura 6.2: Esquema de QVD con componentes adicionales
Balanceador de carga (1): Necesario para cualquier entorno en producción

con más de un nodo QVD y que ejecutan múltiples máquinas virtuales para dar
servicio a varios usuarios. Dicho balanceador será el encargado de redistribuir

equitativamente las máquinas virtuales en ejecución entre los nodos de QVD.
Además, QVD permite la inclusión a la infraestructura de un balanceador hard-
ware, que será explicado en detalle en apartados posteriores.
Almacenamiento compartido (2): En una infraestructura en la que exista

más de un nodo QVD, todos los componentes de QVD deben tener acceso a
un almacenamiento compartido (normalmente NFS) en el que se almacenan las
imágenes de los sistemas operativos para cargar las distintas máquinas virtuales
y los datos propios del entorno de cada uno de los usuarios (P. ej: directorio
home).
QVD Virtual Machine Agent: Es el responsable de aceptar las conexiones

desde el cliente a la VM a través de un nodo QVD. Es un demonio o programa
software que se instala en las máquinas virtuales para facilitar el acceso por
parte de los clientes y es el elemento responsable que la infraestructura QVD
tiene ejecutándose dentro de cada máquina virtual. Al encontrarse dentro de las
máquinas virtuales no puede mostrarse en la Figura 6.2.
6.4. Componentes internos
Profundizando en la arquitectura de QVD, es el momento de tratar los componentes

que lo forman a bajo nivel [3], los realmente encargados de llevar a cabo las tareas
principales de la infraestructura para que todo funcione de forma correcta. Los “core
components” de QVD son:
L7R: Conocido como Layer-7 Router o Router de capa 7. Es el encargado de

ejercer las tareas de broker 2 , caracterı́stico de este tipo de entornos. Es decir,
será el responsable de realizar dentro de los nodos QVD, todas las tareas pa-
ra establecer las sesiones que abren los usuarios contra sus máquinas virtuales.
Gestiona los usuarios.
HKD: Es el otro de los daemons encargados del funcionamiento interno de QVD.

El House Keeping Daemon es el encargado de gestionar el estado de las máquinas
2
Es el encargado de determinar qué escritorio virtual será asignado a qué usuario, siendo
éste el que establece la conexión.
virtuales (arranques, paradas, etc). Gestiona y monitoriza cada una de las VM’s,
siendo también el responsable de actualizar la información sobre el estado de las
máquinas en la base de datos. Gestiona las máquinas virtuales.
En la Figura 6.6 se muestra un diagrama completo en el que se introducen los
dos nuevos componentes descritos y las relaciones de estos con los componentes
descritos en las secciones anteriores.
Figura 6.3: Arquitectura general de QVD
6.4.1. L7R
La conexión de un cliente a su escritorio virtual, se realiza a través de una conexión

HTTPS contra uno de los servidores de QVD (previa autenticación). Es en éste proceso
donde el Layer-7 Router cobra mayor importancia.
El L7R, una vez recibe una petición de autenticación, debe comprobar la base de
datos de la infraestructura para determinar el modo de autenticación configurado. Si la
autenticación es a través de un mecanismo externo (como LDAP), deberá realizar los
pasos apropiados para autenticar al usuario, mientras que si la autenticación se realiza
propiamente en el sistema, simplemente será necesario comprobar las credenciales en

la tabla de usuarios de la base de datos de QVD. En cualquiera de los casos, si la
autenticación es satisfactoria devolverá un mensaje HTTP OK y 401 Unautorized en
otro caso.
Una vez finalizado el proceso de autenticación, el L7R tiene que comprobar la lista
de máquinas virtuales o escritorios de los que dispone el usuario autenticado y responder
con dicha lista al cliente. El usuario deberá seleccionar la máquina virtual a la que se
desea conectar (si hay más de una).
Es labor del L7R el asegurarse de que las máquinas virtuales están disponibles y si
la máquina solicitada no se encuentra en ejecución en ninguno de los nodos, éste debe
iniciarla automáticamente en el nodo más apropiado (en función de la configuración
del balanceador de carga será más apropiado un nodo u otro). Una vez se encuentre
disponible la VM3 del usuario, el L7R establecerá la comunicación entre el usuario y
su máquina virtual a través del protocolo NX.
Por último, una vez el usuario está vinculado a su máquina, deberá actualizarse el
estado en la base de datos para indicar que un cliente está conectado, labor también
del demonio L7R.
Por otra parte, en entornos reales de balanceo de carga, el Layer-7 Router presenta
la capacidad de redirigir a un usuario al nodo en el que se encuentra en ejecución su
máquina virtual. Imaginando un entorno con un nodo A y otro nodo B, si un usuario
se conecta al nodo B, pero su VM se encuentra ya en ejecución en el nodo A, el L7R
redirigirá la conexión del usuario al nodo A. En el caso de no existir previamente la
VM en ejecución, se hace uso de un algoritmo de balanceo para determinar el nodo más
apropiado para iniciar la máquina virtual.
En la Figura 6.4 se muestra el diagrama de interacción cliente-servidor, en el que

se puede apreciar las labores del demonio L7R comentadas durante esta sección.
3
Virtual machine o máquina virtual
Figura 6.4: Interacción cliente-servidor y demonio L7R.
6.4.2. HKD
El House Keeping Daemon es el daemon o demonio que se ejecuta en cada uno

de los nodos de QVD y es el responsable de realizar la total gestión de las máquinas
virtuales en ejecución sobre los nodos. Realiza las actualizaciones de estado median-
te polls o actualizaciones periódicas en la base de datos PosgreSQL. Como es lógico el
HKD, además de tratar los cambios de estado, será también el encargado de ejecutarlos
mediante el envı́o de comandos a la máquina virtual. Ejemplificando, si se envı́a una
señal de apagado a una máquina virtual, el demonio debe enviar la señal de termina-
ción a la máquina virtual y una vez confirmado el cambio de estado deberá enviar la
actualización a la base de datos para que dicho cambio pueda se reflejado en todo el
sistema.
El funcionamiento HKD es dependiente de la tecnologı́a de virtualización empleada

(KVM o LXC) y existen ligeras diferencias en la actividad a bajo nivel:
Cuando la virtualización es KVM, el demonio de HKD ejecuta una instancia de

Estado Descripción
Máquina virtual parada. No se está ejecutando en ningún no-
Stopped
do servidor.
Señal de arranque recibida. HKD espera a tener los recursos
Starting 1
disponibles en los nodos servidor para proceder a su arranque.
La máquina virtual se está iniciando, pero el proceso de arran-
Starting 2
que no ha finalizado.
Máquina virtual en ejecución. Todos los servicios están levan-
Running
tados .
Señal de parada recibida. HKD espera a la respuesta de pa-
Stopping 1
rada por parte de la máquina virtual.
La máquina virtual respondió al proceso de parada y se está
Stopping 2
llevando a cabo el apagado.
La máquina virtual no responde. Se envı́a una señal de termi-
Zombie 1
nación (TERM).
La máquina virtual no responde. Se envı́a una señal de forzar
Zombie 2
terminación (KILL).
Cuadro 6.1: Tabla resumen de los posibles estados de una máquina virtual en una
infraestructura QVD
KVM para cada máquina virtual que es lanzada y carga la configuración de la

misma desde la base de datos y los datos del usuario.
Cuando la tecnologı́a de virtualización es LXC, el trabajo de HKD se complica,

siendo necesario que HKD seleccione la imagen del sistema operativo a cargar y la
descomprima. Hecho esto, deberá vincular o unir dicha imagen con el sistema de
ficheros del usuario de la máquina virtual (los datos propios del usuario), creando
una nueva imagen que será lanzada en una instancia LXC.
A mayores de las tareas descritas, el House Keep Daemon debe comprobar todo
el proceso de inicialización de la máquina virtual: arranque, conexión y configuración
de red y que el QVD Virtual Machine Agent[6.3] se encuentra en ejecución. Si existe
cualquier problema, HKD cambiará el estado de la máquina virtual a blocked y tras un
perı́odo de tiempo enviará una señal de terminación a la máquina. Los estados posibles
de una máquina virtual y su descripción se pueden encontrar en la Tabla 6.1.
6.5. Objetos
Es importante diferenciar antes de profundizar en la instalación de QVD, los dife-

rentes objetos [3] de los que se compone a alto nivel una infraestructura. Son aquellos
elementos manipulables por el equipo de administración.
Usuarios: Serán los beneficiarios del uso de los escritorios virtuales. Normal-
mente un usuario tendrá asignadas una o más máquinas virtuales (escritorios).
Hosts: Equipo o grupo de equipos hardware sobre los que se ejecutan las máqui-
nas virtuales.
Máquinas virtuales: Son las encargadas de correr los escritorios virtuales. Cada
máquina virtual tendrá asignada una OSF.
Operating System Flavours (OSF): Básicamente se compone de dos elemen-

tos: una imagen de disco y varios parámetros de ejecución, es decir, contiene la
información sobre el sistema operativo que se ejecuta en una máquina virtual
(memoria RAM a utilizar, cantidad de espacio de usuario, etc), pero no contie-
nen el sistema operativo en sı́ mismo (sistema de ficheros). Una OSF puede ser
asignada a varias imágenes de disco y es realmente la OSF la que se asigna a un
usuario. Es decir, cuando se habla de que un usuario posee una o más máquinas
virtuales, detrás de cada máquina virtual habrá una OSF, que es el conjunto de
la imagen de disco del sistema operativo y los parámetros de ejecución.
Imágenes de disco (DI): Contienen el sistema operativo, es decir, todo el

sistema de ficheros y los datos necesarios del operativo. Es necesario vincular
siempre una imagen de disco a una OSF, de tal forma que la imagen proporcione
el contenido del sistema operativo y la OSF el resto de parámetros.
6.6. Arquitectura
Tomando como base el esquema de la Figura 6.5 y 6.6, en esta sección se procederá
a explicar la arquitectura tı́pica de una infraestructura QVD y cómo interactúan los
componentes descritos en las Secciones 6.2 y 6.3. Es importante destacar que se trata de
una explicación a alto nivel y por lo tanto no abarcará muchos de los procesos internos
involucrados, que serán tratados más adelante con mayor detalle.
Con el objetivo de no saturar las imágenes, se dividió el proceso de interacción

en dos partes: una primera parte en la que se describirá las relaciones de todos los
componentes sin incluir el servidor de administración (tomando como base la Figura
6.5) y otra en la que se tratan las interacciones del servidor de administración con el
resto de componentes (Figura 6.6).
Figura 6.5: Interacción básica entre los clientes y servidores QVD.
1. El software cliente puede realizar la conexión a la infraestructura (hacia un nodo

servidor) desde la propia LAN corporativa o a través de Internet, empleando para
ello el protocolo HTTPS y mediante autenticación (bien mediante el mecanismo
de autenticación propio de QVD o haciendo uso de un mecanismo externo como
LDAP o Active Directory).
2. El nodo servidor contra el que se realizó la conexión anterior se conecta ahora

con la base de datos PosgreSQL para autenticar el usuario y cargar las configu-
raciones propias del mismo (es obvio que si la autenticación es a través de un
mecanismo externo como LDAP, la autenticación será primeramente contra éste
y una vez autenticado se comprobará con la base de datos para obtener única-
mente las configuraciones del usuario). La base de datos proporcionará también
la información sobre la/s máquina/s virtuales de las que dispone el usuario.

Por último, el nodo servidor actualizará la información de la sesión activa, la
máquina virtual ejecutada y el usuario para que la información de monitorización
esté actualizada.
3. Una vez autenticado el usuario y conocidos los datos necesarios sobre la máquina
virtual, se negocian los parámetros para establecer una conexión segura a través
del protocolo NX. Cuando los datos sean confirmados el cliente estará preparado
para conectarse al escritorio virtual del usuario.
4. Antes de realizar la conexión desde el cliente, el nodo servidor debe cargar la

imagen del sistema operativo desde el almacenamiento compartido (de ahı́ la im-
portancia de que todos los nodos tengan acceso al almacenamiento compartido).
Para cada máquina virtual iniciada por un usuario se crea una imagen en forma-
to .qcow que contendrá la información del directorio home de ese usuario y que
se almacenará también en el almacenamiento compartido posibilitando ası́, por
tanto, que un usuario tenga acceso a su escritorio independientemente del nodo
QVD al que realice la conexión.
Figura 6.6: Interacción básica entre el servidor de administración y los servidores

QVD.
Tras describir los pasos en la comunicación entre los clientes y los servidores QVD,
es ahora el turno de tratar los mensajes que se realizan entre el servidor o interfaz de
administración y el resto de componentes de la arquitectura de QVD.
1. Representa la conexión al servidor de administración, bien una conexión a través

de un navegador a la interfaz de administración web, como a través de SSH para
la administración a través de lı́nea de comandos. La conexión contra la interfaz
web puede ser a través de HTTP o HTTPS y es necesario una autenticación
especı́fica para la misma.
2. Representa cualquier conexión entre la interfaz de administración y la base de

datos, para almacenar cualquier tipo de configuración realizada a través de la
interfaz web o la lı́nea de comandos. Por otra parte, la información que se visualiza
en la interfaz web es extraı́da automáticamente y en tiempo real de la base de
datos (usuarios conectados, máquinas virtuales en ejecución, etc).
3. El servidor de administración hace uso del almacenamiento compartido para po-

der manipular las imágenes de los sistemas operativos, o poder crear las OSF[6.5].
4. Cada uno de los servidores QVD, periódicamente envı́an información a la bases

de datos PosgreSQL, de tal forma que le notifica todos y cada uno de los cambios
de estado de las máquinas virtuales, o el estado de los usuarios. La base de datos
actuará como un intermediario entre los servidores de QVD y la información
mostrada por el servidor de administración.
6.7. Tecnologı́as de virtualización
La solución de QVD ofrece la posibilidad de instalar y configurar la infraestructura

seleccionando la tecnologı́a de virtualización deseada a bajo nivel para la ejecución de
las máquinas virtuales de los escritorios. Aunque ya se comentó esta posibilidad de
selección en puntos anteriores, no se trataron en detalle las ventajas e inconvenientes
que cada una de ellas ofrece para cada caso en particular. Tras comentar los detalles de
cada tecnologı́a se dedicará un apartado a la explicación y justificación de la selección
tomada para la elaboración de este proyecto.
6.7.1. Virtualización KVM
La tecnologı́a de virtualización Kernel Virtual Machine es una solución de virtua-

lización completa sobre GNU/Linux que está formada por un módulo para el kernel
(kvm.ko) y herramientas en el espacio de usuario. Permite ejecutar máquinas virtuales
empleando imágenes de disco que contienen sistemas operativos sin modificar. Cada
máquina virtual contiene su propio hardware virtualizado, algo que es posible gracias
a emplear una versión modificada de QEMU4 .
Se trata, básicamente de un hipervisor que se ejecuta dentro del kernel (no es ne-
cesario modificar el kernel, ya que se trata simplemente de un módulo) de la máquina
Linux anfitriona [5]. De esta forma el KVM actúa como intermediario entre el anfi-
trión y la máquina virtual asegurando una total independencia entre ambos. Hospeda
las máquinas virtuales como procesos, por lo que cada máquina virtual podrá bene-
ficiarse de todas las caracterı́sticas del kernel de Linux5 , heredando los drivers y el
amplio soporte hardware de este con el único requisito de necesitar las extensiones para
virtualización Intel VT-x6 o AMD-V7 .
Aunque existe un gran debate alrededor de la clasificación de KVM dentro de la

virtualización, actualmente se considera en su mayorı́a, un hipervisor tipo I o “bare-
metal” [3.1.1.2]. [5]
Las ventajas más destacables de este tipo de virtualización en un entorno QVD son,
en resumen:
Diseñado para entornos de virtualización total.
No es necesaria la modificación del kernel del host anfitrión.
Compatibilidad e integración total para entornos Linux.
Es Open Source
Independencia entre máquinas virtuales y host anfitrión.

4
Emulador hardware
5
Aunque KVM está fuertemente ligado a Linux, soporta los sistemas de Microsoft como
invitados, es decir, en las máquinas virtuales. De echo, el soporte Windows está en las mismas
raı́ces del proyecto KVM, pensado inicialmente para la virtualización de escritorios Windows.
6
Intel Virtualization Technology. Soporte para virtualización de Intel.
7
AMD Virtualization. Soporte para virtualización de AMD
Facilidad de instalación, configuración y gestión.
Es un hipervisor ligero, de gran rendimiento y software libre.
6.7.2. Virtualización LXC
Linux Containers es una tecnologı́a de virtualización basada en “contenedores”,

que permite crear jaulas aisladas [6]. Una “jaula conenedora” es un sistema GNU/Li-
nux autocontenido dentro de otro, al que se le pueden aplicar cuotas de disco, CPU,
memoria, una o varias interfaces de red, algunos otros lı́mites y capacidades e iniciarlo
como si de un equipo independiente se tratase. En resumen, crear equipos o máquinas
virtuales.
LXC es construido dentro de una jaula (chroot) y proporciona un sistema virtual

completo, con mecanismos de “aislamiento y individualización (isolation)” que son com-
pletamente nativos al kernel Linux.
A diferencia de una virtualización al estilo KVM, una virtualización basada en

contenedores sólo permite emplear máquinas virtuales con el sistema operativo del
host anfitrión, en este caso, diferentes versiones o distribuciones de GNU/Linux. [6]
Destaca por no necesitar una gran cantidad de recursos para levantar un contenedor
LXC, ya que consumen menos recursos que una máquina KVM. Además de su ventaja
principal, existen otras importantes:
Recursos, servicios y aplicaciones ofrecen un rendimiento práticamente igual al

nativo.
No es necesario un hardware especial.
Es Open Source.
No necesita ningún módulo en el kernel.

6.8. Diseño del sistema
Una vez conocida la arquitectura y componentes de la solución QVD, es momen-

to de llevar a cabo la toma de otras decisiones que condicionarán la instalación y el
funcionamiento de la infraestructura.
Es necesario tomar en este punto varias decisiones: el entorno y la arquitectura de

QVD para la Universidad, el sistema operativo seleccionado para los nodos QVD y
seleccionar la tecnologı́a de virtualización a emplear.
6.8.1. Selección de la tecnologı́a
Una vez analizada toda la documentación de la solución QVD, el primero de los

pasos que se presentan previos a la instalación y configuración del producto, es decidir
la tecnologı́a de virtualización a emplear: KVM o LXC. Es uno de los pasos más impor-
tantes en el proceso de implantación de QVD y guiará la instalación y el tratamiento
de las imágenes de disco por uno u otro camino.
Para el proyecto piloto desarrollado, se barajaron desde un inicio ambas posibilida-

des, teniendo en cuenta una serie de puntos clave para la toma de decisión:
Manual técnico de QVD [3] más completo para una instalación de KVM y mayor
comunidad detrás de la tecnologı́a KVM.
Administración de máquinas virtuales más sencilla mediante KVM.
Los sistemas operativos virtualizados sobre LXC deben ser compatibles con el
kernel del host anfitrión, pues es compartido con este. Mayor independencia en
las imágenes de los sistemas operativos a favor de KVM.
Permiten ejecutar en ambos casos un gran número de instancias, aunque LXC

ofrece en todas ellas un rendimiento igual al nativo.
La desventaja que presenta LXC en lo referente a la compatibilidad de las instancias

con el kernel del host anfitrión y a la menor información existente sobre esta tecnologı́a
fueron los puntos que declinaron claramente la balanza hacia KVM como tecnologı́a de
virtualización para la infraestructura QVD a instalar en este proyecto.
La selección de KVM como tecnologı́a de virtualización, por otra parte trae consigo
una pequeña pérdida de rendimiento con respecto a LXC, pero que puede ser fácilmente
suplida gracias a la potencia hardware de los equipos actuales.
6.8.2. Diseño de la arquitectura de QVD
Existen varios condicionantes que marcan el camino a seguir en el diseño de la

arquitectura inicial de la infraestructura: el presupuesto, la disponibilidad de equipos
hardware y la posibilidad de una ampliación futura.
Por una parte, al ser este proyecto carente de presupuesto, no existe la posibilidad de
compra de unos equipos nuevos y completamente dedicados para QVD, siendo necesario
reutilizar y emplear para la instalación inicial equipos fı́sicos en desuso y servidores
virtuales. Los equipos disponibles y sus caracterı́sticas se listan a continuación:
Dos servidores fı́sicos: HP ProLiant DL140 G3 409855-001. 2 x Intel(R)

Xeon(R) CPU 5110 1.60GHz 64-bit. Memoria: 3GB RAM. Las máquinas descri-
tas se pueden ver en la Figura 6.7.
Figura 6.7: Máquinas hardware para QVD
Dos servidores virtuales: VMware ESXi Virtual Servers. Memoria: 1GB RAM.
El diseño de la arquitectura de QVD consistió básicamente en la asignación de

los componentes principales de la solución vistos en la Sección 6.2 a cada uno de los
servidores mencionados, en función de los requisitos hardware.
Un servidor virtual para el servidor base de datos: Aunque la base de

datos mantiene información vital para el funcionamiento de la infraestructura,
la carga de trabajo no es excesivamente elevada (simplemente ciertas consultas

en el proceso de conexión y actualizaciones periódicas de estado), por lo que
un servidor virtual con unos requisitos moderados es más que suficiente para
el proyecto. Evidentemente en un entorno de producción con cientos o miles de
usuarios la carga de trabajo de la base de datos se incrementa considerablemente,
pero el aumento de potencia hardware en un servidor virtual es trivial y altamente
escalable (la recomendación de QVD para entornos en producción es de dos
núcleos de procesador y 2GB de memoria RAM).
Un servidor virtual para el servidor de administración: Suficiente para la

ejecución de un servidor Apache para la aplicación web de administración. Debe
ser capaz de soportar un número reducido de conexiones a la aplicación web y
SSH que realizarán los administradores para el mantenimiento y/o monitorización
de la infraestructura. Al tratarse de un servidor virtual, es altamente escalable
aumentando la capacidad hardware, aunque en este caso será raramente necesario
pues aunque el número de usuarios de los escritorios sea elevado, la administración
será centralizada y llevada a cabo por un reducido número de personas, que este
servidor soportará holgadamente.
Dos servidores fı́sicos para los nodos QVD: Los servidores fı́sicos de mayor
potencia hardware serán los que alojarán los servidores de cómputo de QVD,
sobre los que se ejecutarán las máquinas virtuales y los demonios L7R y HKD
descritos en la Sección 6.4. La capacidad de escalabilidad de la infraestructura
se ve penalizada en este punto por falta de recursos a corto plazo, aunque nada
impide a largo plazo aumentar el número de nodos o realizar una simple migración
de estos nodos hacia unos nodos fı́sicos con mayor capacidad.
En la Figura 6.8 se muestra un diagrama del diseño inicial implementado para
este proyecto piloto, con las relaciones entre nodos.
Servidor virtual
Servidor virtual
QVD
QVD
WAT
Database
Servidor físico
Servidor físico
QVD QVD
Node Node
WAN/LAN
Figura 6.8: Arquitectura de QVD diseñada para el proyecto
6.8.3. Diseño de la arquitectura de red
Tras el diseño de los sistemas, es el momento crear el sistema de comunicación entre

los nodos de la infraestructura en el que la única labor radica en el diseño conceptual y
requisitos necesarios, ya que la propia tarea de creación y administración de las comu-
nicaciones corresponde al Departamento de Red y Comunicaciones de la Universidade
da Coruña.
La primera necesidad es una red o subred nueva (o hacer uso de una existente en la
corporación) en la que se deben alojar todas las máquinas de la infraestructura QVD.

Es válido también que se encuentren en redes distintas, pero con conexión entre ellas.
Aunque el dedicar una red no es condición indispensable para QVD, si será altamente
recomendable para mejorar rendimientos y latencias, algo que favorecerá siempre a la
experiencia de usuario en los escritorios virtuales.
Además, los nodos de cómputo de QVD, hacen uso de un bridge 8 o puente de red
e interfaces virtuales para la conexión entre cada una de las máquinas virtuales que
corren en cada nodo, por lo que será necesaria otra red para alojar a las máquinas
virtuales en ejecución.
En definitiva, serán necesarias dos redes diferentes:
Red de administración: En ella se alojarán las máquinas que conforman la

infraestructura: la base de datos, el servidor de administración y los dos nodos
QVD. Para este proyecto, se hace uso de una red existente y proporcionada por el
Departamento de Red en la que se encuentran varios servicios de la Universidad.
Dicha red presenta espacio de direcciones suficiente y escalable para albergar a
las cuatro máquinas iniciales y muchas otras en el caso de una ampliación de la
infraestructura. La red es la siguiente9 :
• Red: 10.10.10.0
• Gateway: 10.10.10.1
• Netmask: 255.255.255.0
Red de las máquinas virtuales: Alojará a todas las máquinas virtuales en eje-
cución de la infraestructura. Estará vinculada a la red de administración a través
del bridge y la interfaz de red virtual de los nodos. Es importante remarcar aquı́
que la red de las máquinas virtuales debe disponer de direcciones IP suficientes
para dar cobertura a la totalidad de usuarios de los escritorios virtuales (de ahı́
la utilización de una red con máscara /22), pues la única forma de dividir u or-
denar los usuarios es la asignación de rangos de IP diferentes a cada uno de los
grupos. Para el caso de este proyecto y a modo de ejemplo, si se desea clasificar
8
Dispositivo de conexión de redes que opera en la capa 2 (nivel de enlace) del modelo OSI.
Interconecta o divide una red en segmentos haciendo la transferencia de datos de una red a otra
con base en la dirección fı́sica de destino de cada paquete.
9
Por motivos evidentes de seguridad, las direcciones IP mostradas en el diagrama no son las
reales, pero totalmente válidas para la comprensión y explicación del diseño.
los usuarios en función de las facultades o la titulación, es necesario asignar un

rango de IP dentro de esa red para los usuarios de cada facultad10 .
• Red: 10.11.11.0
• Gateway: 10.11.11.1
• Netmask: 255.255.252.0
En la Figura 6.9 se ofrece un diagrama de red completo y a alto nivel de la infra-

estructura.
10
Otra opción para la clasificación para la creación de grupos de usuarios, serı́a la implantación
de una infraestructura QVD completa para cada grupo, algo mucho más costoso y más difı́cil
de administrar.
WAN
10.10.10.0/24
DB WAT QVD1 QVD2
VM VM VM VM ... VM
10.11.11.0/22
WAN
Figura 6.9: Arquitectura de QVD diseñada para el proyecto
6.9. Implementación del sistema
Tras las etapas de decisión, planificación y diseño es el momento de llevar a cabo la

tarea puramente técnica: la instalación y configuración de la infraestructura. Para ello,
fue clave la ayuda del manual técnico proporcionado por QVD, en el cual se tratan en
detalle la instalación de cada uno de los componentes principales [6.2] y componentes
secundarios [6.3], ası́ como el orden de configuración adecuado. Todo el proceso de
instalación se abordará en la siguientes secciones.
6.9.1. Configuración de la base de datos
La base de datos de la infraestructura QVD es el componente que establece el

vı́nculo entre todas las partes del sistema y permite a todas trabajar conjuntamente.
El gestor seleccionado por QVD es PosgreSQL [4].
Toda la información en tiempo real de las máquinas virtuales, usuarios y configu-

raciones se encuentra almacenada en la base de datos y por tanto, esta constituye un
SPOF11 o punto único de fallo. Por esta razón es muy recomendable que la base de da-
tos se encuentre instalada y configurada en un entorno altamente disponible (HA), pero
debido a las restricciones de tiempo y presupuesto (es necesario un servidor adicional)
quedará como una posible mejora futura.
A continuación se muestra en la Figura 6.10 el diagrama relacional de la base de

datos de la solución QVD, para dar una visión global del tipo y cantidad de datos
manejados en la infraestructura.
11
Single Point Of Failure.
Figura 6.10: Modelo relacional de la base de datos de QVD
Los pasos técnicos principales de instalación del servidor base de datos [3] se mues-
tran en sucesivos apartados.
6.9.1.1. Preparación y configuración básica del entorno
1. Instalación del sistema operativo Ubuntu Server y configuración básica de usua-

rios, grupos, cuentas y acceso SSH.
2. Configuración de la red. Configurar una IP estática para el servidor base de datos

dentro de la red de administración descrita en la Sección 6.8.3. La configuración
empleada es:
i f a c e l o i n e t loopback
auto l o
auto e t h 0
i f a c e eth0 i n e t s t a t i c
address 10.10.10.10
netmask 2 5 5 . 2 5 5 . 2 5 5 . 0
up r o u t e add d e f a u l t gw 1 0 . 1 0 . 1 0 . 1
dns−n a m e s e r v e r s 1 0 . 2 . 2 . 2 1 0 . 3 . 3 . 3
6.9.1.2. Instalación del software y paqueterı́a
1. Añadir la clave pública de los paquetes de QVD al fichero de claves (como root).
$ wget −qO − h t t p : / / theqvd . com/ p a c k a g e s / key / p u b l i c

. key | sudo apt−key add −
2. Seguidamente, añadir los repositorios al apt sources y actualizarlos.
$ echo ” deb h t t p : / / theqvd . com/ p a c k a g e s / ubuntu QVD

− 3 . 4 . 0 main” > / e t c / apt / s o u r c e s . l i s t . d/qvd −34.
list
$ apt−g e t update
3. Instalación de la paqueterı́a de QVD necesaria para la base de datos. Dentro de

dicho paquete se encuentra, a su vez, la paquerı́a del gestor PosgreSQL, que en
el momento de la instalación se corresponde con la versión 9.1.
$ apt−g e t i n s t a l l p e r l −qvd−db
6.9.1.3. Creación de usuarios y base de datos
1. El primer paso es cambiar de usuario y realizar login con el usuario posgres

creado automáticamente durante la instalación del gestor, con este usuario ya se
disponen de los permisos suficiente para las tareas de gestión y configuración del
gestor PosgreSQL.
$ sudo su − p o s t g r e s
2. Haciendo uso de los comandos de administración12 de PosgreSQL, se crea un

usuario dentro del gestor para acceder a la base de datos y a las tablas de QVD.
$ c r e a t e u s e r −SDRP qvd
Enter password new r o l e : p a s s
Enter i t a g a i n : p a s s
3. Creado un nuevo usuario Posgres, este ya puede ser asignado como propietario
de una base de datos. Es momento por tanto, de crear la base de datos de QVD
y asignar al usuario anteriormente creado (qvd ) como propietario de la misma.
$ c r e a t e d b −O qvd qvddb
4. Todos y cada uno de los nodos de la infraestructura, deben tener un fichero de

configuración (node.conf ) que les indique en qué lugar se encuentra la base de
datos, ası́ como los datos de acceso a la misma. Aunque la creación de este fichero
es uno de los primeros pasos, en este caso al tratarse propiamente el nodo BD, no
se disponı́a de la información necesaria para la configuración de sus parámetros
hasta este punto. Dicho fichero debe ser alojado en la ruta /etc/qvd y no es
necesario crearlo manualmente, ya que QVD proporciona una plantilla. Una vez
creado, se establecen los parámetros de la base de datos correctamente.
$ cp −R / u s r / s h a r e /qvd/ c o n f i g / e t c /qvd
$ v i / e t c /qvd/ node . c o n f
#
# QVD Node C o n f i g u r a t i o n
#
12
Más información en: http://www.postgresql.org/docs/9.1/static/app-createuser.
html
# Name o f t h i s node i n QVD. U s u a l l y t h e machine ’ s

hostname .
nodename=v d i l i n u x −p o s t g r e s q l
# Database c o n n e c t i o n i n f o r m a t i o n .
# d a t a b a s e . h o s t : where t h e QVD d a t a b a s e i s found
# d a t a b a s e . name : t h e name o f t h e QVD d a t a b a s e
# d a t a b a s e . u s e r : t h e u s e r a c c o u n t needed t o
connect
# d a t a b a s e . password : t h e password needed t o
connect
database . host = 1 0 . 1 0 . 1 0 . 1 0
d a t a b a s e . name = qvddb
d a t a b a s e . u s e r = qvd
d a t a b a s e . password = p a s s
path . run = / var / run /qvd

path . l o g = / var / l o g /qvd
path . tmp = / var /tmp/qvd
l o g . f i l e n a m e = / var / l o g /qvd/qvd . l o g
l o g . l e v e l=INFO
6.9.1.4. Configuración de PosgreSQL
La base de datos está sometida a accesos concurrentes por parte de los nodos que
conforman la infraestructura y por ello será necesario aplicar ciertas configuraciones
adicionales. Es un paso muy importante y si por cualquier motivo el estado de la base
de datos fuese inconsistente, provocarı́a un mal funcionamiento de la totalidad de la
infraestructura.
1. El acceso concurrente a la base de datos está controlado por el parámetro de-

fault transaction isolation del fichero posgresql.conf. Se establece, por tanto, del
valor read commited a serializable.
$ v i / e t c / p o s g r e s q l / 9 . 1 / main/ p o s g r e s q l . c o n f
...
default transaction isolation = ’ serializable ’
...
2. Hecho esto, en el mismo fichero de configuración anterior, se cambia el parámetro

listen addresses de localhost a *, para permitir el acceso por red a PosgreSQL.
$ v i / e t c / p o s g r e s q l / 9 . 1 / main/ p o s g r e s q l . c o n f
...
l i s t e n a d d r e s s e s = ’∗ ’
...
3. Además de permitir el acceso a PosgreSQL, se debe activar también el acceso a la

propia base de datos. Se edita el fichero pg hba.conf y se añade una lı́nea por cada
una de las IP de las máquinas que forman parte de la infraestructura (aunque en
este punto todavı́a no están configuradas todas las máquinas, las direcciones IP
son conocidas, por estar reservadas de antemano).
$ v i / e t c / p o s g r e s q l / 9 . 1 / main/ pg hba . c o n f
...
h o s t qvddb qvd 1 0 . 1 0 . 1 0 . 1 0 / 3 2 md5
h o s t qvddb qvd 1 0 . 1 0 . 1 0 . 1 1 / 3 2 md5
h o s t qvddb qvd 1 0 . 1 0 . 1 0 . 1 2 / 3 2 md5
h o s t qvddb qvd 1 0 . 1 0 . 1 0 . 1 3 / 3 2 md5
...
4. Se reinicia el servicio para aplicar las configuraciones anteriores.
$ service posgresql restart
6.9.1.5. Creación de las tablas
La paqueterı́a instalada de QVD, incluye un script en perl (se encuentra en la ruta

/usr/lib/qvd/bin), que ayuda a la creación de todas las tablas de la base de datos QVD.
Una vez ejecutado el script, la base de datos está lista para su funcionamiento.
$ cd / u s r / l i b /qvd/ b i n
$ . / qvd−d e p l o y . p l
6.9.2. Configuración del servidor de administración
El servidor de administración es el punto desde el cual se realizaran todas la ta-

reas administrativas de la infraestructura QVD por parte del personal de TI. Se trata
básicamente de un servidor Apache con una aplicación web, que permite realizar las
tareas de más comunes de forma local o remota: crear/eliminar usuarios, crear/eliminar
máquinas virtuales, crear/eliminar imágenes de disco y monitorizar el estado de varios
de los componentes de la solución.
Además de la interfaz web, también se instalan una serie de scripts que permiten
la realización de las mismas tareas a través de la consola de comandos. Esto puede
resultar muy útil para la elaboración de scripts personalizados o en caso de fallo del
servidor web. La instalación y configuración [3] se muestra a continuación.

2. Configuración de la red. Configurar una IP estática para el servidor de adminis-

tración dentro de la red principal comentada en la Sección 6.8.3. La configuración
de red es:
auto l o
auto e t h 0
address 10.10.10.11
netmask 2 5 5 . 2 5 5 . 2 5 5 . 0
dns−n a m e s e r v e r s 1 0 . 2 . 2 . 2 1 0 . 3 . 3 . 3
3. Creación del fichero de configuración base de QVD que debe poseer cada uno
de los nodos. Es importante recordar que dicho fichero sirve para proporcionar
al nodo la información de acceso a la base de datos. Tanto el servidor de admi-
nistración como posteriormente el resto de nodos, deben incluir en este fichero
un campo “nodename” que debe coincidir con el nombre asignado a la máquina.
Este campo será utilizado por la base de datos para ofrecer información sobre las
máquinas de la infraestructura.
$ mkdir / e t c /qvd
#
#
hostname .
nodename=v d i l i n u x −wat
connect
connect
database . host = 1 0 . 1 0 . 1 0 . 1 0

1. Añadir la clave pública de los paquetes de QVD al fichero de claves.



list
3. Instalación de la paqueterı́a de QVD necesaria para el servidor web Apache y los

scripts de administración.
$ apt−g e t i n s t a l l p e r l −qvd−admin−web (WAT)

$ apt−g e t i n s t a l l p e r l −qvd−admin ( S c r i p t s )
6.9.2.3. Configuración del puerto de la WAT
La aplicación web, evidentemente, escucha en un puerto determinado, que por

defecto es el puerto 3000 para las peticiones HTTP. Si en la infraestructura existe
algún conflicto con ese puerto (puede estar usado), puede cambiarse editando el fichero
/etc/default/qvd-wat.
$ echo ’PORT=6000 ’ > / e t c / d e f a u l t /qvd−wat
6.9.2.4. Autenticación en la WAT
El último de los pasos en la configuración de la aplicación web de administración es

establecer el usuario y contraseña de la misma, haciendo uso de los scripts anteriormente
instalados.
$ qa c o n f i g set wat . admin . l o g i n=l o g i n

$ qa c o n f i g set wat . admin . password=p a s s
Básicamente, estos dos comandos anteriores sirven para modificar los campos de la
base de datos y por ello es muy importante seguir el orden de instalación de QVD.
Una vez instalada la consola de administración ya se puede acceder a ella sin mayores
problemas. A continuación, en la Figura 6.11 se muestra la pantalla de administración
de los nodos a través de la interfaz web y en la Figura 6.12 la administración de las
máquinas virtuales.
Figura 6.11: Administración de hosts a través de la WAT

Figura 6.12: Administración de VM’s a través de la WAT
6.9.2.5. Problemas
Una vez aplicada toda la configuración era imposible acceder a la máquina a través
del navegador, es decir, el servidor Apache no respondı́a correctamente, lanzando un
Internal Server Error.
Para identificar error, fue necesario cambiar en la configuración del Apache(/etc/apache2/sites-

enabled/qvd-wat.conf ) el LogLevel (tipo o nivel de detalle de los log) a modo Debug, de
esta forma, el log de error del Apache es maś descriptivo (/var/log/apache2/error.log),
dando ası́ con el problema.
El error residı́a en un problema de escritura del Apache en los ficheros de log de

qvd (/var/log/qvd-wat.log). El Apache no tenı́a permisos para escribir en los ficheros
de log, por lo tanto, la solución fue cambiar el propietario del fichero qvd-wat.log al
usuario Apache (www-data) y cambiar los permisos del mismo, haciendo uso de las
herramientas propias de Linux para dicho fin (chmod y chown).
6.9.3. Configuración de los nodos QVD
Realizadas las configuraciones de la base de datos y el servidor de administración,

es el momento de instalar el nodo o nodos de cómputo sobre el que se ejecutarán las
máquinas virtuales. Los nodos QVD son los encargados de gestionar y controlar los
demonios L7R y HKD, explicados en la Sección 6.4.
Normalmente, son instalados más de un nodo formando arquitecturas clúster, y

para este proyecto, serán inicialmente dos, lo que significa que el proceso de instalación
será repetido en cada uno de los nodos. La diferencia en el proceso de uno a otro nodo
será únicamente las direcciones IP (de la red de administración y de la red de las VM)
del mismo. Para este caso concreto se instalaron dos nodos.
Es indispensable en este punto observar el diagrama básico de red 6.9 mostrado

en la Sección 6.8.3 para comprender el por qué los nodos hacen uso de un bridge y
una interfaz de red virtual para conectarse con las máquinas virtuales que están en
ejecución en un nodo. Además, debe configurarse un servidor DHCP para proporcionar
dinámicamente direcciones IP dentro de un rango a las VM.
En el proceso de instalación de los nodos fue indispensable la colaboración externa

del Departamento de Red de la Universidade da Coruña, que fue el encargado de la
creación de una vlan y una subred propia para las máquinas virtuales. Todo el proceso
de instalación e información técnica [3] se detalla a continuación.

2. Configuración de la red. Configurar una IP estática para cada uno de los nodos
QVD. Es importante comentar aquı́ que esta es una configuración de red inicial
de los nodos con el único objetivo de poder acceder remotamente vı́a SSH. En
apartados posteriores del proceso de instalación se realizará la configuración de
red definitiva de los mismos.
auto l o
auto e t h 0
address 10.10.10.12∗
netmask 2 5 5 . 2 5 5 . 2 5 5 . 0
dns−n a m e s e r v e r s 1 0 . 2 . 2 . 2 1 0 . 3 . 3 . 3
*Nota: La dirección IP del segundo nodo es 10.10.10.13
3. Creación del fichero de configuración base de QVD que debe poseer cada uno de
los nodos. Recordar que dicho fichero sirve para proporcionar al nodo la infor-
mación de acceso a la base de datos.
$ mkdir / e t c /qvd
#
#
hostname .
nodename=v d i l i n u x −qvd1
connect
connect
database . host = 1 0 . 1 0 . 1 0 . 1 0

1. Añadir la clave pública de los paquetes de QVD al fichero de claves.


list
3. Instalación de la paqueterı́a de QVD necesaria para el/los nodo/s.

$ apt−g e t i n s t a l l p e r l −qvd−node
4. El comando anterior instalará sólo los componentes necesarios para el nodo, aun-
que también es altamente recomendable instalar los scripts de administración en
todas y cada una de las máquinas de la infraestructura para facilitar y acelerar
en ocasiones las labores de administración.
$ apt−g e t i n s t a l l p e r l −qvd−admin
6.9.3.3. Configuración de red de los nodos
Los nodos de QVD, hacen uso de un bridge y una interfaz de red virtual para
conectarse con las máquinas virtuales que están en ejecución en un nodo. Además,
debe configurarse un servidor DHCP para proporcionar dinámicamente direcciones IP
dentro de un rango a las VM.
Es indispensable en este punto recordar el diagrama básico de red 6.9 mostrado en

la Sección 6.8.3 para comprender los pasos que se mostrarán a continuación.
1. Instalar o configurar un servidor DHCP. QVD hace uso de dnsmasq (el cual
también puede actuar como servidor DNS). Para ello, es necesario comprobar si
dnsmasq se encuentra instalado y si no instalarlo.
$ dpkg −s dnsmasq
O bien, instalarlo:
$ apt−g e t i n s t a l l dnsmasq
2. Por defecto, Ubuntu inicia el proceso dnsmasq como un demonio en background.

Es muy importante que el demonio dnsmasq se ejecute bajo el control del proceso
qvd-node, por lo tanto se debe desactivar el inicio automático de dnsmasq.
$ s e r v i c e dnsmasq s t o p
$ sed − i s /ENABLED=1/ENABLED=0/ / e t c / d e f a u l t /
dnsmasq
3. Configurar IP forwarding. Es necesario para enrutar los clientes a la localización

correcta, es decir, cuando un cliente se conecta a un nodo, si su máquina virtual
no está ejecutándose en ese nodo, este sea capaz de “enrutarlo” al nodo correcto.
Para ello, es necesario cambiar el valor del parámetro net.ipv4.ip forward en el
fichero /etc/sysctl.conf.
$ vi / etc / s y s c t l . conf
...
n e t . i p v 4 . i p f o r w a r d =1
...
4. Configuración del bridge y la interfaz virtual. Existen múltiples caminos de con-

figuración, muy dependientes todos ellos de las caracterı́sticas del entorno, red y
disposición de las máquinas. Básicamente, la configuración reside en la creación
de una nueva red para alojar a los clientes (VM’s), ası́ como a los propios nodos
de QVD, a través del bridge y la interfaz virtual. En resumen, bastarı́a con decir
que los nodos QVD tienen una interfaz fı́sica conectada a la red de administra-
ción y una interfaz virtual conectada a esta nueva red de las máquinas virtuales.
La configuración de red de este proyecto se elaboró de forma personalizada para
el entorno, con colaboración externa [6.9.3].
$ cat / e t c / network / i n t e r f a c e s
auto l o
auto e t h 0 e t h 1 qvdnet0 v l a n 2 0 0
address 10.10.10.12∗
netmask 2 5 5 . 2 5 5 . 2 5 5 . 0
network 1 0 . 1 0 . 1 0 . 0
gateway 1 0 . 1 0 . 1 0 . 1
i f a c e e t h 1 i n e t manual
i f a c e v l a n 2 0 0 i n e t manual
vlan−raw−d e v i c e e t h 1
up i p l i n k set up dev v l a n 2 0 0
i f a c e qvdnet0 i n e t s t a t i c
address 10.11.11.3∗∗
netmask 2 5 5 . 2 5 5 . 2 5 2 . 0
b r i d g e p o r t s vlan200
b r i d g e s t p on
dns−n a m e s e r v e r s 1 0 . 8 . 8 . 8 1 0 . 8 . 8 . 9
*Nota: La dirección del segundo nodo es: 10.10.10.13.

**Nota: La dirección del segundo nodo es: 10.11.11.4
Es fácil ver que el nodo configurado presenta la IP 10.10.10.12 dentro de la red
de administración a través de la interfaz fı́sica eth0 y la IP 10.11.11.3 dentro de
la red de las máquinas virtuales a través de la interfaz virtual qvdnet0.
5. Para que la configuración anterior sea posible y tenga efecto, es necesario la

instalación del paquete vlan.
$ apt−g e t i n s t a l l v l a n
6. Una vez editado el fichero de configuración de la red e instalado el paquete vlan,

hay que reiniciar el servicio para aplicar la nueva configuración.
$ / e t c / i n i t . d/ n e t w o r k i n g r e s t a r t
6.9.3.4. Parámetros de QVD
Cuando se finaliza la instalación de los nodos, es necesario dar a conocer todos

los datos de la nueva red en la base de datos de QVD. Este paso es realizado
únicamente una vez, al ser independiente del número de nodos de los que se
componga la infraestructura.
Antes de ajustar los parámetros se explicará brevemente para qué se usa cada
uno de ellos:
vm.network.ip.start: Indica la IP de inicio a partir de la cual el servidor

DHCP asignará ordenadamente a las máquinas virtuales.
vm.network.netmask: Parámetro para conocer la máscara de red de la
red de las VM’s.
vm.network.gateway: Como su propio nombre indica, este parámetro
contiene la dirección IP del router de la red.
vm.network.dns server: Debe contener la dirección IP del nodo QVD
que se desea emplear como servidor DHCP y DNS (Recordar el paso de
instalación del paquete dnsmasq).
vm.network.bridge: Indica la interfaz virtual de los nodos que se em-
plea como bridge entre la red de administración y la red de las máquinas
virtuales.
Conocida la utilidad de los parámetros, se deben establecer (haciendo uso de

los scripts de administración) a los valores propios del entorno, que en este caso
serán:
# qa c o n f i g s e t vm . network . i p . s t a r t = 1 0 . 1 1 . 1 1 . 2 0
# qa c o n f i g s e t vm . network . netmask=22
# qa c o n f i g s e t vm . network . gateway = 1 0 . 1 1 . 1 1 . 1
# qa c o n f i g s e t vm . network . d n s s e r v e r = 1 0 . 1 1 . 1 1 . 3 ∗
# qa c o n f i g s e t vm . network . b r i d g e=q v d n e t 0
*Nota: Como se realizó la instalación del servidor DHCP y DNS en ambos nodos,
es válido el uso de cualquiera de ellos para realizar dicha labor.
6.10. Operación del sistema
Todas las organizaciones gastan un tiempo considerable en la fase de operación

y representarán por tanto una parte importante del proyecto. A través de la fase de
operación, se comprueba el funcionamiento del sistema, monitorizando y administrando
la infraestructura maximizar su rendimiento, capacidad, disponibilidad, confiabilidad
y seguridad. Es en esta fase también, dónde se deben resolver problemas o realizar los
cambios necesarios.
Para este proyecto, es necesario modificar levemente el contenido de esta fase, de tal
forma que se realice en este momento una pequeña prueba de funcionamiento general y
relegar a la última fase, las pruebas en profundidad de la infraestructura, tras la fase de
optimización. Esta decisión es debida a que aunque el sistema funcione correctamente,
muchas de las tareas de la fase de optimización son imprescindibles en un entorno de
este tipo. Es decir, realizar ahora unas pruebas de operación en profundidad no tendrı́a
sentido sin antes incluir todas aquellas funcionalidades que van a estar presentes en la
infraestructura una vez puesta en producción.
6.10.1. Pruebas de funcionamiento
Las pruebas básicas de funcionamiento realizadas en esta fase consisten básicamente

en la creación de un usuario y una máquina virtual a partir de una imagen de disco por
defecto que QVD proporciona en su página web para labores de prueba13 , a la que se
accederá desde los distintos clientes disponibles en QVD (Windows, Linux, MAC OS y
Android).
El único objetivo es comprobar que la instalación realizada hasta el momento y los

clientes, funcionan de forma correcta. De esta forma se puede continuar la instalación
y configuración de nuevas funcionalidades.
Concretamente consistieron en probar los escritorios virtuales realizando tareas ca-

racterı́sticas de un usuario común, como la edición de textos (o imágenes) o la navega-
ción por Internet con programas como Libreoffice o Gimp.
En la Figuras 6.13 y 6.14 se muestra la pantalla de login que se ofrece a los usuarios
13
http://theqvd.com/product/download
(desde un cliente de escritorio y desde un cliente Android respectivamente) y en las

sucesivas Figuras se muestran las pruebas llevadas a cabo ya comentadas.
Figura 6.13: Pantalla de login desde un cliente de escritorio

Figura 6.14: Pantalla de login desde un cliente móvil Android
Figura 6.15: Prueba de QVD desde un cliente Windows

Figura 6.16: Prueba de QVD desde un cliente Android

Figura 6.17: Prueba de QVD desde un cliente Mac OS
Figura 6.18: Prueba de QVD trabajando con LibreOffice

Figura 6.19: Prueba de navegación con QVD
6.11. Optimización del sitema
6.11.1. Autenticación externa
El primero y más necesario de los puntos de mejora de la infraestructura, es el

realizar la autenticación al sistema a través de un mecanismo como LDAP[B]. Aunque
QVD proporciona su propio framework de autenticación (que almacena los usuarios
dentro de la base de datos de QVD), el uso de un mecanismo externo de autenticación
en grandes organizaciones es algo común.
En el servicio LDAP de la Universidad es el lugar donde se mantienen centralizados

una serie de datos de los miembros de la comunidad. De esta forma, una vez configurado
el mecanismo en el sistema QVD, cualquier usuario de la Universidad podrá autenticarse
en la infraestructura.
Para la realización de esta configuración, de nuevo fue necesaria la colaboración del

Departamento de Red, para permitir el acceso desde las máquinas de la infraestructura
QVD a la máquina del servicio LDAP. Los pasos técnicos [3] de esta configuración se
muestran en el siguiente apartado.
6.11.1.1. Configuración LDAP
Los datos de LDAP mostrados a continuación, al igual que las direcciones IP ante-
riores no son reales, pero totalmente válidos para la explicación.
Dirección servidor LDAP: 10.10.15.225
Usuario: cn=sic.vdi.linux,ou=users,dc=udc,dc=es
1. Una vez concecido el acceso (por parte del Departamento de Red) desde la red
de las máquinas QVD a la máquina del servicio LDAP, se prueba la conexión con
este:
ldapsearch -xLLL -H ldap://10.10.15.225 “cn=sic.vdi.linux,ou=users,dc=udc,dc=es”
-W -b “ou=People,dc=udc,dc=es” “(objectClass=udcPersona)”
Comprobada la conexión, el acceso en lectura al servidor LDAP es posible y se
puede pasar por tanto al proceso de configuración.
2. Se instala el plugin en cada uno de los nodos QVD.
$ apt−g e t i n s t a l l p e r l −qvd−l 7 r −a u t h e n t i c a t o r −
p l u g i n −l d a p
3. Se configura el LDAP mediante los scripts de administración instalados.
$ qa c o n f i g set l 7 r . auth . mode=l d a p ( 1 )

$ qa c o n f i g set auth . l d a p . h o s t=l d a p
://10.10.15.225:389 (2)
$ qa c o n f i g set auth . l d a p . b a s e=ou=p e o p l e , dc=udc , dc
=e s ( 3 )
$ qa c o n f i g set auth . l d a p . binddn=cn=s i c . v d i . l i n u x ,
ou=u s e r s , dc=udc , dc=e s
$ qa c o n f i g set auth . l d a p . f i l t e r =(&( o b j e c t C l a s s=
udcPersona ) ( u i d= %u ) ) ( 4 )
$ qa c o n f i g set auth . l d a p . s c o p e=sub ( 5 )
El primero de los comandos (1) simplemente dice al sistema que la autenticación

se realizará a través de LDAP. El segundo (2) especifica la dirección y el puerto de
escucha del servicio LDAP. El siguiente (3), especifica el directorio de información
del árbol. El (4) sirve para filtrar los resultados obtenidos de la consulta al LDAP
y por último (5), el alcance que permite descender en el árbol.
4. Aplicadas las configuraciones, se reinicia el servicio L7R en los nodos QVD y el

sistema está preparado para realizar autenticación a través de LDAP
$ s e r v i c e qvd−l 7 r r e s t a r t
6.11.2. Auto provisión
Aunque el mecanismo de autenticación externa es muy útil, por si sólo no facilita

mucho la vida de los administradores de sistemas, ya que aunque no sea necesario
crear todos los usuarios manualmente, si debe crear una máquina virtual y realizar la
asignación de esta a cada usuario. Es por este motivo que la autenticación externa debe
ser complementada con otro tipo de métodos.
La auto provisión consiste en la creación y asignación automática de máquinas

virtuales a usuarios. Es decir, cuando un usuario es autenticado por primera vez, si este
no dispone de una VM, el sistema de auto provisión genera una nueva máquina(haciendo
uso de una OSF[6.5] configurada) y se la asigna a este de forma totalmente transparente,
tanto para los usuarios como para los administradores.
6.11.2.1. Configuración de autoprovisión
La configuración del aprovisionamiento automático de máquinas virtuales [3] es

muy sencilla y consta de los siguientes pasos:
1. Instalar el plugin de auto provisión en los nodos QVD de la infraestructura.
$ p e r l −qvd−l 7 r −a u t h e n t i c a t o r −p l u g i n −auto
2. Configurar los parámetros de la base de datos adecuados.

$ qa c o n f i g set l 7 r . auth . p l u g i n s =’ auto , ldap ’ ( 1 )

$ qa c o n f i g set auth . auto . o s f i d =1 ( 2 )
El primer parámetro indica a la infraestructura que debe emplear auto provisión

conjuntamente con LDAP y el segundo sirve para establecer la OSF (imagen de
disco parametrizada que se empleará como base para las máquinas).
6.11.3. Almacenamiento compartido
En el momento en el una infraestructura pasa de una arquitectura mononodo a la

existencia de varios nodos (como es el caso), se hace indispensable la incorporación de
un almacenamiento compartido entre ellos, de tal forma que sea accesible por todos los
sistemas que componen la “granja” QVD.
En la Figura 6.20 se observa un diagrama sencillo del acceso de los hosts al alma-
cenamiento.
Figura 6.20: La WAT y los nodos de QVD acceden a almacenamiento compartido
Para la creación de un sistema de almacenamiento en red, existen diversas tecno-

logı́as. QVD ofrece compatibilidad con GFS14 , OCFS215 (sobre algún servidor SAN) o
bien con NFS.
14
Global File System. Más información en Apéndice B
15
Oracle Clúster File System. Más información en Apéndice B
6.11.3.1. Directorios afectados
Los ficheros que son objetivo de ser compartidos se albergan bajo el directorio
/var/lib/qvd/storage 16 de los nodos. En este directorio, en función te la tecnologı́a de
virtualización seleccionada (Sección 6.7) existirán unos subdirectorios u otros [3] pero
en este caso se describirán aquellos que afectan a la virtualización KVM, por ser la
empleada para este proyecto.
staging: Se trata de un directorio de almacenamiento temporal para las imáge-

nes de disco que estarán disponibles a través de la interfaz web de administración
para poder ser manipuladas. Las imágenes de disco incluidas aquı́ están dispo-
nibles mediante la opción “Add Image” de la WAT. Una vez añadida a través
de la interfaz, la imagen es copiada al directorio images. Es por tanto necesa-
rio el acceso del nodo de administración (el nodo que contiene la WAT) a este
subdirectorio.
images: Lugar de almacenamiento de las imágenes de disco que serán cargadas

por los nodos para cada una de las máquinas virtuales que sean lanzadas. Como
es lógico, debe estar accesible para todos los nodos de la infraestructura.
homes: Es el subdirectorio en el que se almacenan los datos del directorio home

de los usuarios. Existirá un fichero en formato .qcow para cada usuario. También
necesita ser accedido por los nodos.
overlays: Se emplea para almacenar datos que constantemente se escriben en los

sistemas operativos de las máquinas en ejecución. Almacenamiento de archivos
temporales.
6.11.3.2. Selección de la tecnologı́a
Tras conocer los directorios y subdirectorios susceptibles de ser compartidos, es ne-

cesario escoger la tecnologı́a a emplear para el servicio de almacenamiento compartido.
La disponibilidad de documentación por parte de QVD, la conocida estabilidad y

seguridad, la imposibilidad económica de disponer de una cabina SAN y el ya conoci-
16
Ruta por defecto, salvo previo cambio de configuración.
miento de la tecnologı́a por parte de los administradores fueron condiciones clave para
el uso de NFS como protocolo de compartición de almacenamiento.
6.11.3.3. Diseño e implementación del almacenamiento compartido
Decidida la balanza a favor de NFS, es el momento de determinar dónde se ubicará el

nuevo servidor NFS: en un nuevo servidor dedicado (virtual) o como servicio en alguna
de las máquinas de la infraestructura. Dado el poco uso del hardware del servidor
de administración (máquina WAT) y el ahorro que supone el no emplear un servidor
adicional, es el sitio idóneo para ubicar el servidor NFS.
Para ello, únicamente será necesario conectar a este servidor un dispositivo de

almacenamiento adicional y convertir este en el espacio de almacenamiento compartido.
Al ser un servidor virtualizado a través de VMware, la tarea de añadir un dispositivo es
sencilla y aunque inicialmente será de unos pocos GB, es posible aumentar el tamaño
cuando sea necesario de forma fácil y rápida.
Un detalle importante en cualquier instalación NFS es la seguridad de los archivos,

ya que este no fue diseñado pensando en la seguridad. Aunque la seguridad es muy
importante, para este proyecto no es necesario tomar medidas adicionales, pues todo
el sistema NFS y los nodos se encuentran en una red Intranet completamente segura,
dónde solo acceden los administradores de sistemas.
La implementación consistirá en formatear y preparar ese nuevo dispositivo, mover

los archivos existentes en directorio /var/lib/qvd/storage de los nodos al nuevo disco
y realizar la configuración del servicio NFS en la máquina tal y cómo se detalla a
continuación.
6.11.3.4. Configuración almacenamiento compartido: NFS
La configuración del servidor NFS [3] se realiza en el servidor de administración

(máquina WAT). Se supone ya añadido un disco duro de 100GB(/dev/sdb).
1. Crear una única partición en el disco.

$ sudo f d i s k / dev / sdb ( o p c i o n e s n para c r e a r y w
para g u a r d a r )
2. Formatear el disco en formato ext4.
$ sudo mkfs . e x t 4 / dev / sdb
3. Crear la carpeta que contendrá toda la información (imágenes de disco, datos de

los usuarios, directorios home, etc).
$ sudo mkdir / q v d s t o r a g e
4. Copiar la estructura de directorios de uno de los nodos QVD al directorio anterior,

ubicado en el nuevo disco. (No fue necesario copiar la información, pues sólo
existı́an máquinas virtuales de las pruebas realizadas).
$ nodoWAT˜ :# s c p −r qvd@10 . 1 0 . 1 0 . 1 2 : / v a r / l i b / qvd /

s t o r a g e /∗ / q v d s t o r a g e
5. Montar el directorio en el dispositivo /dev/sdb.
$ sudo mount / dev / sdb / q v d s t o r a g e
Nota: El comando anterior no es persistente. Al reiniciar el servidor se perderá

la configuración (el montaje). Es necesario realizar una configuración persistente.
6. Editar el fichero /etc/fstab y añadir:
/ dev / sdb / qvdstorage ext4 defaults 0 1
7. Instalar los paquetes necesarios para el servidor NFS.
$ sudo apt−g e t i n s t a l l n f s −k e r n e l −s e r v e r
8. Realizar la configuración del servidor NFS. Editar el fichero /etc/exports.
/ qvdstorage ∗ ( rw , sync , n o s u b t r e e c h e c k ,
no root squash )
9. Reiniciar el servicio NFS.
$ / e t c / i n i t . d/ n f s −k e r n e l −s e r v e r r e s t a r t
10. Instalar el cliente NFS en el resto de nodos de la infraestructura (en este caso
solo en los nodos QVD y en el nodo de administración propiamente, ya que el
nodo base de datos no necesita acceso al almacenamiento compartido).
$ sudo apt−g e t i n s t a l l n f s −common
11. Configurar los clientes. Editar en cada uno de los clientes el fichero /etc/fstab
para indicar dónde está el servidor NFS y qué carpeta comparte.
1 0 . 1 0 . 1 0 . 1 1 : / q v d s t o r a g e / var / l i b /qvd/ s t o r a g e nfs

rw , s o f t , i n t r , r s i z e =8192 , w s i z e =8192
12. Montar el directorio en los clientes.
$ mount / var / l i b /qvd/ s t o r a g e
6.11.4. Balanceador de carga
QVD es una solución de escritorios completamente diseñada para funcionar en en-

tornos de balanceo de carga. Cualquier entorno en producción requerirá tanto la inclu-
sión de un balanceador hardware externo como la correcta configuración del balanceador
de carga integrado con L7R.
Balanceador hardware externo: Se sitúa antes de los nodos, de tal forma que
se encargue de aceptar las peticiones de los clientes. Su funcionamiento básico
consiste en enviar la petición del cliente a aquel nodo con menos carga. Para
conocer el estado de carga de los nodos se vale de un mecanismo conocido como
“health checking”, que consiste en el envı́o de mensajes periódicos a través de
HTTP a los que los nodos responden de la misma forma. Una vez aceptada
la petición del cliente y redirigida esta al nodo con menor carga, este debe ser
el encargado de levantar la máquina virtual del cliente si no está encendida o
bien redirigir de nuevo al cliente al nodo en el que ya se encuentra operativa su
máquina virtual.
Balanceador interno: Se incluye dentro del demonio L7R comentado en la

Sección 6.4. Es el encargado de redirigir las peticiones entre un nodo y otro en
función del lugar donde se encuentre levantada la máquina virtual de un usuario.
(Por ejemplo, si una máquina A corre sobre un nodo A y un usuario se conecta
al nodo B, éste nodo B debe ser capaz de redirigir la petición del usuario al nodo
A). Consta de varios algoritmos de balanceo de carga de tal forma que permite
configuraciones diferentes en función de la caracterı́stica a primar a la hora de
iniciar una VM en un nodo u otro: menor uso de CPU, menor ocupación de

memoria, asignación de nodo aleatoria, etc.
Para un entorno piloto de pruebas de dos nodos, como es el caso de este proyecto,
será suficiente la configuración del balanceador interno, que se detalla en el siguiente
apartado, quedando relegada la inclusión de un balanceador hardware a una mejora
futura.
6.11.5. Configuración del balanceador de carga
Gracias al desarrollo del personal de QVD, la configuración del balanceador de

carga es trivial y básicamente consiste en la asignación de pesos a las prioridades en
el reparto de la carga. El algoritmo de balanceo de carga que incorpora L7R calcula
la carga instantánea de cada uno de los nodos del sistema, comprobando la RAM y la
CPU libre de cada uno de ellos.
QVD presenta tres posibles caracterı́sticas a las que asignar pesos para el balanceo:
la RAM, la CPU o introduciendo un componente de aleatoriedad.
Si se incrementa el peso de la variable RAM en el algoritmo, el balanceador

asignará preferencia al nodo con más RAM disponible.
Si se incrementa el peso de la variable CPU, el balanceador asignará la preferencia

al nodo con más CPU disponible.
Si se incrementa el peso de la componente de aleatoriedad, el algoritmo de ba-

lanceo asignará la preferencia aleatoriamente entre los nodos.
Todas estas caracterı́sticas son configurables a través de parámetros de configura-

ción disponibles en la Base de Datos de la infraestructura y pueden ser variadas a través
de los scripts de configuración, tal y cómo se muestra a continuación:
$ qa c o n f i g set l 7 r . l o a d b a l a n c e r . p l u g i n . d e f a u l t . w e i g h t
. cpu=3
. ram=2
. random=1
Para la configuración de esta infraestructura, se aplicó una preferencia por CPU,

seguida de la preferencia de RAM y dejando la componente de aleatoriedad al mı́ni-
mo. El resultado será que las nuevas máquinas virtuales se arrancarán en aquel nodo
con mayor capacidad de CPU disponible. Esto es ası́ debido a que los recursos de los
servidores empleados son más limitados en cuanto a CPU.
6.11.6. Configuración SSL
Para aumentar la seguridad de sus conexiones, QVD puede hacer uso de HTTPS
con un certificado x509 y clave privada [3]. En un entorno de producción real esto es
altamente recomendable, sobre todo el hacer uso de un certificado de una autorizad
certificadora de confianza como Verisign 17 , BelSign 18 o cualquier otro tipo de entidad
certificada.
En este proyecto piloto, al no disponer de presupuesto, se creará y configurará el

uso de SSL a través de un certificado autofirmado, completamente válido y funcional.
1. Instalación de la paqueterı́a de Open SSL.
$ apt−g e t i n s t a l l o p e n s s l
2. Se crea un subdirectorio dentro del directorio /etc/qvd para trabajar con los
certificados creados propiamente para la infraestructura.
$ mkdir / e t c /qvd/ c e r t s
3. Dentro del directorio creado, se genera primeramente la clave privada del servidor,
con entropı́a 1024.
$ o p e n s s l g e n r s a 1024 > qvd−s e r v e r −p r i v a t e −key . pem
4. Con la clave privada creada, ya se puede crear un certificado autofirmado. Se

crea un certificado normal, con una validez de 180 dı́as.
17
https://www.verisign.es/
18
https://www.globalsign.com/
$ o p e n s s l r e q −new −x509 −nodes −sha1 −days 180 −

key qvd−s e r v e r −p r i v a t e −key . pem > qvd−
c e r t i f i c a t e . pem
Nota: Tras el comando anterior, durante la generación del certificado es necesario

introduccir información del mismo en diferentes campos.
5. Configurar la infraestructura QVD para hacer uso del certificado haciendo uso
de uno de los scripts de administración.
$ qa c o n f i g s s l key=/ e t c /qvd/ c e r t s /qvd−s e r v e r −

p r i v a t e −key . pem c e r t =/ e t c /qvd/ c e r t s /qvd−
c e r t i f i c a t e . pem
6. Para que un certificado sea válido, es necesario añadirlo al directorio del sistema
donde se encuentran alojados todos los certificados de los que hace uso. Dicho
directorio es /usr/lib/ssl, en derivados de Debian, como es el caso.
Para que el protocolo SSL reconozca el certificado, por tanto, debemos copiarlo
en el directorio anterior o bien crear link simbólicos al mismo, que es lo que se
realizará. A su vez, se renombran también los certificados.
$ t r u s t e d s s l p a t h =/u s r / l i b / s s l / c e r t s
$ c e r t p a t h =/ e t c /qvd/ c e r t s / s e r v e r − c e r t i f i c a t e . pem
$ c e r t n a m e =‘ o p e n s s l x509 −noout −hash −i n
$cert path ‘ . 0
$ cp $ c e r t p a t h $ t r u s t e d s s l p a t h /QVD−L7R−c e r t . pem
$ l n −s $ t r u s t e d s s l p a t h /QVD−L7R−c e r t . pem
$trusted ssl path$cert name
6.11.7. Componentes hardware
Desde el inicio del proyecto, se barajó la posibilidad de ampliación de las máqui-

nas hardware hacia otras más potentes, una vez probado el entorno y finalizada su
configuración se procedió a realizar una migración a otros nodos más potentes (no se
detallarán los pasos seguidos para su configuración por ser idénticos a los ya mostrados
en la Sección 6.9.3.
Las nuevas máquinas fı́sicas que alojarán los dos servidores de QVD son:
2 Servidores HP ProLiant DL785 G5 409855-001. 16 x 2.2GHz Quad-Core AMD

Opteron(tm) Processor 8354 64-bit. Memoria: 128GB RAM. En la Figura 6.21
se muestra la máquina descrita.
Figura 6.21: Nuevas máquinas hardware para QVD
Con estos dos servidores fı́sicos, además de mejorar enormemente la potencia de

la infraestructura y la capacidad de dar servicio a un mayor número de usuarios, se
mejora también la disponibilidad del entorno, al convertir de esta forma al servicio VDI
Linux en un servicio de alta disponibilidad. Esto se produce por la localización fı́sica
de ambos servidores: uno se encuentra en el ESCI19 y otro en el edificio de Reitorı́a20 .
6.11.8. Politica de copia de seguridad
Habilitar a una organización para continuar con sus operaciones principales en caso
de algún tipo de interrupción y darle la posibilidad de sobrevivir a un desastre que
afecte a los sistemas de información, son hoy en dı́a unas de las principales tareas de
todos los grupos de seguridad informática.
Ataques informáticos y problemas como atentados o desastres naturales, incendios

o en algunos casos la maldad de ciertas personas, hacen necesario contar con un plan de
19
Edificio de Servicios Centrales de Investigación, situado en el Campus de Elviña.
20
Edificio de oficinas, situado en Maestranza
contingencia, aplicado a los sistemas y tecnologı́as de la información, capaz de devolver

la infraestructura a su estado natural.
Por otra parte, es importante resaltar el enfoque de este apartado, pues se dejará
de lado toda la temática relacionada con los planes de contingencia, los tipos de copias
de seguridad y ciertos conceptos técnicos que serı́an objeto de trabajos completos por
sı́ solos.
Además, en un proyecto de este tipo no resulta de especial importancia tratar en

profundidad la polı́tica de seguridad pues al tratarse de un proyecto destinado a pruebas
no va a tratar con información de usuarios ni ningún tipo de información importante.
La única labor de la polı́tica de seguridad que se aplicará será la de salvaguardar
todos aquellas configuraciones ya realizadas para en caso de error o problema en la
infraestructura poder recuperarla a un estado consistente, sin necesidad de comenzar
la instalación desde el principio.
6.11.8.1. Backup de los servidores
El primero de los pasos en la copia de seguridad viene dado implı́citamente gracias

a la infraestructura de la UDC. Periódicamente se realiza una copia completa de cada
uno de los servidores y una copia incremental diaria, tanto de los servidores fı́sicos como
los virtuales. Para una infraestructura de pruebas como esta, esta polı́tica serı́a más
que suficiente, pero con el objetivo de una más rápida recuperación en caso de caı́das
o problemas especı́ficos se tomaron una serie de medidas adicionales que se describen
en los siguientes apartados.
6.11.8.2. Backup de las configuraciones
El primero de los planes de copia de seguridad de la solución QVD, es el resguardo

de todos y cada uno de los ficheros de configuración implicados hasta el momento. En
la infraestructura de la Universidade da Coruña, existe un moderno y completo robot
de cintas que será el encargado de llevar a cabo esta labor, pasando diariamente por
cada una de las máquinas indicadas para realizar la copia de seguridad de los ficheros
o directorios indicados. Basta con una copia diaria, o incluso bastarı́a con una copia
semanal, pues los ficheros de configuración no sufren variaciones una vez realizados. A
continuación se muestran los ficheros afectados en cada una de las máquinas.
Servidor base de datos
• /etc/qvd/node.conf : Es el fichero que almacena la información básica del

nodo, el lugar y las credenciales de la base de datos.
• /etc/posgresql/9.1/main/pg-hba.conf y /etc/posgresql/9.1/main/posgresql.conf :
Son ficheros de configuración de la base de datos.
• /etc/network/interfaces: Fichero de configuración de la red del servidor base
de datos.
Servidor de administración
• /etc/qvd/node.conf : Fichero de información del nodo de administración.

Incluye también el lugar y las credenciales del servidor base de datos y
SGDB.
• /etc/default/qvd-wat: Almacena el puerto de la interfaz de administración
web.
• /etc/apache2/sites-enabled/qvd-wat.conf : Fichero de configuración del ser-
vidor Apache que ejecuta la aplicación web de administración.
• /etc/fstab y /etc/exports: Contienen las configuraciones relacionadas con el
servidor NFS para el almacenamiento compartido. Recordar que el servidor
de administración realiza las tareas también de servidor NFS.
• /etc/network/interfaces: Fichero de configuración de la red del nodo de
administración.
Servidores QVD21
• /etc/qvd/node.conf : Fichero de información del nodo. Como los nodos QVD

también deben poder acceder a la base de datos, este también almacena las
credenciales de la misma.
• /etc/fstab: Configuración del cliente NFS. Necesaria para poder montar el
almacenamiento compartido en cada uno de los nodos.
• /etc/network/intefaces: Fichero de configuración de la red de los nodos de
QVD.
21
Se da por supuesto que los ficheros tratados en este apartad deben guardarse tantos como
nodos QVD existan. Uno por nodo.
6.11.8.3. Backup de las tablas de la base de datos
Para la copia de las tablas de la base de datos se optó por una sencilla solución: la
realización de un script que se ejecuta diariamente a las 5:00am y que copia todas las
tablas a una determinada localización en el servidor. Será después el robot de cintas el
encargado de obtener la copia de las tablas, también de forma diaria.
Al igual que en todos los casos anteriores, es lógico que este tipo de polı́tica no
serı́a para nada adecuado para un futuro entorno en producción, pero suficiente para
el entorno actual.
6.11.8.4. Backup del almacenamiento compartido
Tal y cómo se describe en la Sección 6.11.3 y en la posterior instalación en el Apéndi-

ce 6.11.3.4, la zona de almacenamiento compartido se encuentra en un disco adicional
conectado al servidor de administración y montado bajo el directorio /qvdstorage. Es
aquı́ donde se encuentran todos los datos de las máquinas virtuales e imágenes de disco
empleadas en las pruebas por lo que diariamente el robot de cintas también copiará los
datos de este directorio.
6.11.9. Mejoras futuras
Aunque desde un inicio no fue posible barajar la posibilidad de mejorar ciertos

aspectos, bien por desconocimiento pleno de la caracterı́stica como por la imposibilidad
de disponer de equipos nuevos. Es por ello que se dedicará un pequeño apartado a tratar
dos caracterı́sticas todavı́a en proceso de realización. Dichas actividades consisten en la
inclusión de un balanceador hardware (comentado en la Sección 6.11.5) y la migración
de los equipos actuales a otros más actuales y potentes.
6.11.9.1. Balanceador hardware
La solución QVD ofrece una gran compatibilidad con el uso de balanceadores hard-
ware y ofrece mecanismos para facilitar su uso e inclusión en las infraestructuras.
Otra de las mejoras posibles y que se llevarán a cabo en un futuro es la inclusión

de un balanceador de este tipo. Ası́, los clientes se conectarán a la infraestructura a
través del balanceador hardware y será este el que envı́e la petición del cliente al nodo
con menos carga de trabajo en ese momento. De esta forma, se complementará a la
perfección con el balanceador interno con el que cuenta la infraestructura.
QVD cuenta con un método conocido como “health checking” que permite conocer
el estado de cada uno de los nodos. Esto es posible gracias al demonio L7R, que es el
encargado de responder a las peticiones HTTP de “health checking”.
6.11.9.2. Mejora de la seguridad
Aunque es uno de los apartados más a tener en cuenta en una infraestructura de

futuro uso público como esta, por motivos de falta de tiempo y necesidad de realizar
análisis, auditorı́as y estudios de seguridad, se incorpora a este apartado de trabajos
pendientes a corto plazo.
Capı́tulo 7
Conclusiones
Índice general
7.1. Evaluación del trabajo realizado . . . . . . . . . . . . . . . . . 141
7.2. Difusión del trabajo . . . . . . . . . . . . . . . . . . . . . . . . . 142
7.3. Lı́neas de trabajo futuro . . . . . . . . . . . . . . . . . . . . . . 142
7.4. Reflexión personal . . . . . . . . . . . . . . . . . . . . . . . . . . 143
7.1. Evaluación del trabajo realizado
El proyecto sobre el que trata la presente memoria es una solución de virtualización

de escritorios Linux orientada a completar y dar servicio a los diferentes equipos Linux
distribuidos por los diferentes campus y facultades de la Universidade da Coruña, una
vez en producción.
De todos los requisitos y objetivos iniciales a cumplir por parte de un proyecto

piloto destinado a pruebas, la infraestructura configurada proporciona, todos ellos e
incluso se complementa con algunos otros adicionales. De este modo se consiguió obtener
un proyecto sólido y con caracterı́sticas muy similares a las de cualquier entorno en
producción: capacidad, rendimiento, estabilidad y alta disponibilidad, todo ello en un
entorno real.
La realización de este proyecto permitió al alumno conocer nuevas técnicas, trabajar
141
7. Conclusiones 142
en un entorno organizacional y hacer uso de tecnologı́as predominantes y con gran

expansión en el mundo de las tecnologı́as de la información. Todo esto, sumado a
la obtención de los objetivos iniciales permiten culminar este trabajo de una forma
excelente.
7.2. Difusión del trabajo
Debido a la naturaleza del proyecto y con el objetivo de dar a conocer este trabajo y
compartir la experiencia con otras Universidades españolas, se presentó una propuesta
a las XXV Jornadas Técnicas de RedIRIS 2014, que se llevarán a cabo los dı́as 25 al 27
de Noviembre de 2014 en el Complejo Cultural de San Francisco, centro de congresos
y exposiciones de la Diputación de Cáceres.
La decisión de presentar una propuesta es debida a la gran adaptación del proyecto

a una de las temáticas que se abordarán: Redes de campus y servicios en movilidad :
cómo el ordenador fijo se ve desplazado por los dispositivos móviles, las tendencias
BYOD1 , cómo esta tendencia afecta a las redes de campus y los despliegues, mejoras y
aspectos a tener en cuenta en un futuro.
Básicamente, la propuesta de ponencia radica en la explicación del análisis de al-

ternativas llevadas a cabo en este trabajo, la exposición de los pasos realizados para el
despligue y la puesta en marcha de la solución de escritorios virtuales Linux con QVD,
mostrando las ventajas de una infraestructura de este tipo en un entorno universitario
ası́ como la valoración de las posibles lineas de explotación actuales y futuras bajo la
experiencia previa de la Universidade da Coruña y el apoyo del personal de QVD.
7.3. Lı́neas de trabajo futuro
Tras la finalización de este proyecto, se abren una serie de lineas de continuidad que
permiten establecer una serie de objetivos a largo plazo:
Puesta en producción: La primera de las lı́neas de continuidad es implı́cita en

1
Bring Your Own Device
7. Conclusiones 143
un proyecto piloto de este estilo y reside en la aplicación de las mejoras y cambios

que permitan la puesta en producción de la infraestructura.
Mejora hardware: Destinar una partida presupuestaria a la compra de hard-

ware potente y actual, para dar cabida a la totalidad de posibles usuarios de los
escritorios Linux.
Automatización de tareas: Creación de programas o scripts que permitan rea-

lizar de forma automática tareas de administración caracterı́sticas de un entorno
universitario.
Clasificación de usuarios: Configuración y despligue de infraestructuras sepa-

radas que permitan dar servicio a diferentes grupos de usuarios de forma aislada.
Por ejemplo, una infraestructura de escritorios para la Facultad de Caminos, otra
para la Facultad de Informática, etc.
Creación de Imágenes de disco: Creación de imágenes de disco personalizadas

para cada uno de los grupos de usuarios o incluso imágenes propias para la
impartición de asignaturas determinadas. Por ejemplo, crear una imagen de disco
de una distribución Linux orientada a Seguridad, con software caracterı́stico para
facilitar la docencia de una determinada asignatura.
Búsqueda del Thin Client ideal: Realizar un análisis exhaustivo de las posi-
bles alternativas a equipos ligeros para dar con una solución ideal (coste-rendimiento)
para substituir, por ejemplo, los equipos convencionales de las AulaNet y/o per-
sonal PAS por equipos Thin Client.
Otras mejoras: En una infraestructura de este tipo siempre quedará abierta a

lineas futuras por su naturaleza cambiante, en la que se deben introducir conti-
nuas mejoras a medida que las necesidades de los usuarios son más exigentes.
7.4. Reflexión personal
En una persona sin experiencia previa en un proyecto real, las expectativas residı́an
únicamente en logar materializar lo máximo posible los conocimientos teóricos adqui-
ridos durante los años de estudio de la carrera. Tras la finalización de este proyecto y
tras seis meses de trabajo puedo decir que tanto mis objetivos como mis expectativas
fueron claramente superadas.
7. Conclusiones 144
En general, creo que fue una experiencia más, una experiencia que me acercó a
la realidad de la empresa y me facilitó aprender a trabajar de forma muy similar al
mundo laboral, estrechar relaciones y desarrollar competencias y actitudes positivas en
el mundo del trabajo.
Son estas las últimas lı́neas de un trabajo que llega a su fin, y que marca el final de
una etapa de mi vida, un punto y aparte hacia un futuro que se me presenta, espero,
con las puertas abiertas.
Apéndices
Apéndice A
Glosario de acrónimos
CPD Centro de procesamiento de datos
GFS Global File System
OCFS Oracle Cluster File System
OCFS2 Oracle Cluster File System Version 2
HA High Availability
KVM Kernel-based Virtual Machine
LDAP Lightweight Directory Access Protocol
LXC Linux Containers
NFS Network File System
SAN System Area Network
SCSI Small Computer System Interface
SGBD Sistema de Gestión de Bases de Datos
SPICE Simple Protocol for Independent Computing Environments
SPOF Single Point of Failure
VDI Virtual Desktop Infraestructure
VM Virtual Machine
VMM Virtual Machine Monitor
146
Apéndice B
Glosario de términos
KVM o Kernel-based Virtual Machine es la solución más conocida dentro del grupo
de la virtualización a nivel de kernel, es decir, aquel tipo de virtualización que
convierte un kernel Linux en un hipervisor empleando un módulo. De este modo,
dicho kernel permite la ejecución de máquinas virtuales y hace uso del módulo
para la comunicación con las mismas.
LXC Se trata de un sistema o tecnologı́a de virtualización poco pesado para el control

del espacio de usuario de Linux Containers. Es decir, un método de virtualización
a nivel de sistema para ejecutar instancias completamente aisladas entre sı́ dentro
de un mismo host anfitrión (de ahı́ los llamados “containers” o “contenedores”).
A diferencia de otras técnicas de virtualización como KVM, LXC no proporciona
una máquina virtual, si no que ofrece un entorno virtual que tiene su propio
espacio de procesos procesos y elementos de red.
LXC se basa principalmente en las funcionalidades cgroups y chroot de Linux.
NX Se trata de una tecnologı́a que permite ejecutar sesiones X11 remotas de manera
rápida y con excelente calidad gráfica. Fue desarrollada por la compañı́a francesa
NoMachine.
La velocidad de transmisión de la tecnologı́a NX se debe en gran parte al algorit-
mo de compresión y cacheo empleado que realiza el protocolo de ventanas X11,
lo que trae consigo una gran reducción en la cantidad de información transferida
entre el cliente y el servidor. Además de la velocidad NX tampoco deja de lado
la seguridad, pues envı́a la información a través del servicio seguro SSH.
NX posee una arquitectura de dos componentes básicos ya nombrados: el cliente
147
NX y el servidor NX. El cliente se ejecuta en el sistema remoto y es el encargado de

proporcionar una capa que permite a las aplicaciones del sistema remoto utilizar
el protocolo de forma totalmente transparente. Existe una componente en el
cliente (nxproxy) que es la encargada de realizar todo el proceso de conversión al
protocolo NX ası́ como también es el encargado de mantener las sesiones y del
transporte de información a través de la red.
En el lado servidor además se instala el componente nxagent. En su conjunto el
sistema NX el servidor actúa como un servidor X server, por lo que las aplicacio-
nes no tienen que sufrir ninguna modificación para trabajar con NX y çreen”tener
el sistema remoto en modo local.
LDAP o Lightweight Directory Access Protocol hace referencia a un protocolo a nivel

de aplicación que permite el acceso a un servicio de directorio ordenado y dis-
tribuı́do para buscar diversa información en un entorno de red. Considera una
base de datos de usuarios u otros objetos de la red y almacena información de
autenticación
Active Directory Servicio de directorio de Microsoft en una red distribuida. Se trata

de un servicio establecido en varios servidores en donde se crean objetos tales co-
mo usuarios, equipos o grupos con el objetivo de administrar los inicios de sesión
en los equipos conectados a la red, ası́ como también administrar las polı́ticas de
toda la red.
GFS Sistema de almacenamiento compartido para arquitecturas clúster de sistemas

Linux. Presenta ciertas diferencias con respecto a sistemas de ficheros distribuidos
(AFS, Coda, etc) como el permitir a los nodos acceso concurrente al mismo bloque
de disco. Además, permite ser empleado como sistema de ficheros local.
OCFS Se trata de un sistema de almacenamiento compartido desarrollado por Oracle

y con licencia libre. Es un proyecto nacido con el objetivo de compartir o crear
bases de datos en arquitectura clúster. A partir de la segunda versión (OCFS2),
amplió sus objetivos incluyendo caracterı́sticas de almacenamiento adicional.
NFS Network File System, es un popular protocolo utilizado para compartir sistemas
de archivos de manera transparente entre anfitriones dentro de una red de área
local. Es utilizado para sistemas de archivos distribuido.
Fue desarrollado en 1984 por Sun Microsystems, teniendo en mente la indepen-
dencia del anfitrión, sistema operativo, protocolo de transporte. Funciona a través
de los protocolos XDR (nivel de presentación del modelo OSI de TCP/IP) y ONC
RPC (nivel de sesión del modelo OSI de TCP/IP).
Es muy popular entre sistemas basados sobre el estándar POSIX y viene incluido
en la mayorı́a de éstos de modo predeterminado. Es muy fácil de configurar y
utilizar, sin embargo debe tomarse en cuenta que su seguridad se basa sobre listas
de de control de acceso compuestas por direcciones IP o nombres de anfitrión.
Es por ésto que es importante que el administrador de la red de área local com-
prenda que un servidor NFS puede ser un serio problema de seguridad, si éste es
configurado incorrectamente.
Existen tres versiones de NFS que se utilizan hoy en dı́a: NFSv2, NFSv3 y NFSv4,
cada una de ellas con caracterı́sticas adicionales a la anterior.
Apéndice C
Análisis y prueba de Raspberry

Pi como Thin Client
El bajo coste, la sencillez y la flexibilidad de la Raspberry Pi, hacen que inicialmente

se presente como un claro candidato a Thin Client para la solución de escritorios Linux.
En este apéndice se expone la realización de un análisis y una serie de pruebas

con la Raspberry Pi como protagonista. En el caso de un óptimo funcionamiento,
estarı́a suponiendo un ahorro de entre un 75 %-90 % del valor de un equipo Thin Client
comercial.
Dichas pruebas, fueron posibles gracias a la existencia de un cliente software com-

pilado para arquitectura ARM (la arquitectura del procesador de la Raspberry). Se
trata básicamente de un binario compilado, en fase Beta y destinado precisamente a la
realización de pruebas.
C.1. Pruebas básicas
Los test realizados constan básicamente de pruebas de conexión al escritorio virtual

y una vez en este, hacer uso de él para las tareas más habituales de los usuarios:
navegación y ofimática. Todo ello monitorizando el estado de la Raspberry Pi.
Tras la realización de las primeras pruebas, se pudo apreciar una necesidad de me-
jorar el rendimiento, pues aunque con aplicaciones ofimáticas y sin constantes cambios
150
en la pantalla (mover ventanas, maximizar, minimizar, etc) funcionaba de una forma

relativamente fluida, en el momento de emplear un navegador el escritorio virtual se
volvı́a completamente “inusable”. Es decir, los constantes refrescos de la pantalla que
se producen, por ejemplo, al navegar (scrolls, cambios de página, etc) producı́an una
sensación de lentitud. Esto, hace que el uso de una Raspberry Pi como Thin Client sea
complicado a primera vista, sin introducir algún tipo de mejora. En la Figura C.1 se
muestra una captura del proceso de monitorización en la que claramente se observa un
alto uso de la CPU.
Figura C.1: Monitorización del uso de CPU de la Raspberry PI en estado original
Paralelamente a las pruebas mencionadas, durante la monitorización de los recursos

hardware de la Raspberry, se pudo apreciar como el mı́nimo refresco de la pantalla
provocaba que el uso de la CPU se acercase al 100 %, y en cambio, la memoria RAM,
difı́cilmente excedı́a el 40 %.
C.2. Mejoras de rendimiento
Tras las infructuosas pruebas anteriores, se comunicó el problema al equipo técnico

de QVD, quien facilitó un nuevo binario optimizado para continuar con la realización
de los test. Dicho binario, aunque mejora levemente el comportamiento, no hace que la
experiencia de usuario sea adecuada.
Por último, y para no descartar tan pronto la Raspberry, se llevó a cabo las pruebas
con tres niveles diferentes de overclocking del procesador (800MHz, 900MHz y 1GHz),
obtienendo los mismos resultados que en los casos anteriores. A modo de ejemplo, se
muestra una captura en la Figura C.2. Se corresponde con un nivel de overclocking de
1Ghz, en la que apenas se aprecia una mejora del 2 % de uso con respecto al estado
original mostrado en la Figura C.1
Figura C.2: Monitorización del uso de CPU de la Raspberry PI con overclocking
Por todo esto, la Raspberry Pi tuvo que ser completamente descartada, a pesar de
que inicialmente prometı́a ser un Thin Client ideal y de bajo coste.
C.3. Alternativas
Por motivos de tiempo y coste, no se hicieron pruebas con ningún otro equipo
hardware, quedando relegada la búsqueda del Thin Client ideal a una posible ampliación
del proyecto en un futuro próximo, con el posible análisis de alternativas a la Raspberry.
Un ejemplo podrı́a ser la Cubie Board, también de arquitectura ARM, pero en este caso
con dos o más núcleos de procesador, lo que a simple vista, podrı́a solucionar el problema
de falta de CPU.
Bibliografı́a
[1] Qindel Group. 2014. Web http://www.qindel.com/.
[2] QVD (Quality Virtual Desktop). Qindel Group. 2014. Web http://theqvd.com/.
[3] QVD Docs Team. Version 22780. Qindel Group. 2014. Web http:
//docs.theqvd.com/.
[4] PosgreSQL. Versión 9.1. Web http://www.postgresql.org.es/.
[5] Kivity, Avi and Kamay, Yaniv and Laor, Dor and Lublin, Uri and Liguori,
Anthony. KVM: The Linux Virtual Machine Monitor. Proceedings of the
Linux Symposium. 2007. 225–230p. Volumen 1.
[6] Javier, Miguel G and Neves, Marcelo Veiga and Rossi, Fabio D and Ferreto, Tiago
C and Lange, Timoteo and De Rose, Cesar AF. Performance evaluation of
container-based virtualization for high performance computing environments.
Parallel, Distributed and Network-Based Processing (PDP), 2013 21st Euro-
micro International Conference on . 2013. 233-240p.
[7] Hutton, Keith T and Schofield, Mark D and Teare, Diane. Designing Cisco
Network Service Architectures (ARCH)(Authorized Self-study Guide). Pearson
Education. 2008.
154
BIBLIOGRAFÍA 155
[8] Wilkins, Sean. Cisco’s PPDIOO Network Cycle. Cisco Press. 2011. Web: http:
//www.ciscopress.com/articles/article.asp?p=1697888&seqNum=3.
[9] Lamela Martı́nez, Denis. Sistema de virtualización multinodo basado en KVM.

Proyecto final de carrera. A Coruña, 2012. 166p. TI 1024.
[10] Mosquera Sánchez, Javier. Estudio sobre virtualización hardware aplicada a la

arquitectura x86. Proyecto final de carrera. A Coruña, 207. 100p. PDI 1294.
[11] Villa Fernández, Eugenio. Virtualización de servidores de telefonı́a IP en GNU/-

Linux. Proyecto final de carrera. Almerı́a, 2010. Web: www.adminso.es.
[12] Ulteo Open Virtual Desktop. Web http://www.ulteo.com/.
[13] Fernández, Arturo. Ulteo: un escritorio virtual remoto. Todo Linux: la revista
mensual para entusiastas de GNU/Linux. 2009. Número 99. 25–29p. Volumen
9.
[14] Red Hat Virtualization for Desktops. Red Hat Inc. 2014. Web http:
//es.redhat.com/.
[15] VMware. Web http://www.vmware.com/.
[16] VMware Horizon View. Web http://www.vmware.com/es/products/

horizon-view.
[17] Brown, Stuart Arthur. Getting Started with Citrix VDI-in-a-Box. 2013. Packt
Publishing Ltd.
[18] James, Gareth R. Citrix XenDesktop implementation: a practical guide for IT

professionals. Elsevier. 2010.
[19] Cerling, Tim and Buller, Jeff and Enstall, Chuck and Ruiz, Richard. Introducing
Microsoft Desktop Virtualization. Mastering Microsoft® Virtualization.
BIBLIOGRAFÍA 156
409–441p. 2014. Wiley Online Library.
[20] Oracle VDI. Web http://www.oracle.com/us/technologies/virtualization/

virtual-desktop-infrastructure/overview/index.html.

Memoria TFG

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Memoria TFG

Cargado por

Copyright:

Formatos disponibles

Facultad de Informática

Trabajo fin de grado

Grado en Ingenierı́a Informática

Implementación de una solución VDI para

Autor: Xacobe Macı́a da Silva

A Coruña, a 24 de septiembre de 2014

Permission is granted to copy, distribute and/or modify this document

Que la memoria titulada “Implementación de una solución VDI para escritorios

A Coruña, 24 de septiembre de 2014

D. A. Daniel López Rivas D. Fco. J. Nóvoa de Manuel

por todas las historias que me habéis contado

y por las que os quedan por contar.

Mis primeras palabras de agradecimiento no pueden ser a otras personas que no

Xacobe Macı́a da Silva

A Coruña, a 24 de septiembre de 2014

Desde hace años, el entorno tradicional de las redes corporativas se ha desarro-

Es en este marco donde encajan a la perfección las infraestructuras de escritorios

Con el amparo de la experiencia previa de la Universidade da Coruña en el des-

1.3. Estructura de la memoria . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2.1. Metodologı́a de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2.2. Definición de tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.3. Estimacion de tareas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.4. Seguimiento del proyecto . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2.5. Estimación de costes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1.1. Conceptos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3.2. Un poco de historia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3. Tipos de virtualización . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3.1. Virtualización de plataforma . . . . . . . . . . . . . . . . . . . . 26

3.3.2. Virtualización de recursos . . . . . . . . . . . . . . . . . . . . . . 28

3.3.3. Virtualización de aplicaciones . . . . . . . . . . . . . . . . . . . . 30

3.3.4. Virtualización de biblioteca (API) . . . . . . . . . . . . . . . . . 30

3.3.5. Virtualización de escritorios . . . . . . . . . . . . . . . . . . . . . 30

3.4. Virtualización de escritorios . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.4.1. Conceptos básicos . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.5. Ventajas e Inconvenientes . . . . . . . . . . . . . . . . . . . . . . . . . . 34

3.6. Soluciones en el mercado actual . . . . . . . . . . . . . . . . . . . . . . . 42

3.6.1. VMware Horizon View . . . . . . . . . . . . . . . . . . . . . . . . 43

3.6.2. Microsoft VDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.6.3. Citrix XenDesktop . . . . . . . . . . . . . . . . . . . . . . . . . . 43

3.6.4. Citrix VDI in a BOX . . . . . . . . . . . . . . . . . . . . . . . . 44

3.6.5. Oracle VDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.6.8. RedHat Enterprise Virtualization for Desktops . . . . . . . . . . 45

4. Virtualización de escritorios en la UDC 46

4.1. Situación de partida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.2. Usuarios y personal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.3. Situación actual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.3.1. ¿Por qué VDI? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3.2. Infraestructura VDI . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.3.3. ¿Por qué VDI Linux? . . . . . . . . . . . . . . . . . . . . . . . . 51

5.1.3. Comparativa de versiones . . . . . . . . . . . . . . . . . . . . . . 57

5.1.4. Requisitos técnicos . . . . . . . . . . . . . . . . . . . . . . . . . . 57

5.2.3. Comparativa de versiones . . . . . . . . . . . . . . . . . . . . . . 63

5.2.4. Requisitos técnicos . . . . . . . . . . . . . . . . . . . . . . . . . . 65

5.3. Red Hat Enterprise Virtualization: Spice . . . . . . . . . . . . . . . . . . 67

5.3.3. Requisitos técnicos . . . . . . . . . . . . . . . . . . . . . . . . . . 69

5.4. Comparativa de productos . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.4.1. Comparativa de las versiones de pago . . . . . . . . . . . . . . . 70

5.4.2. Comparativa de las versiones gratuitas . . . . . . . . . . . . . . . 73

5.5. Solución a implantar . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.1. ¿Qué es QVD? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.2. Componentes principales . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.3. Componentes secundarios . . . . . . . . . . . . . . . . . . . . . . . . . . 84

6.4. Componentes internos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

6.7. Tecnologı́as de virtualización . . . . . . . . . . . . . . . . . . . . . . . . 93