Saltar a contenido

Hipervisores

Roles con acceso

Solo los administradores tienen acceso a esta característica.

Tipos de hipervisores

IsardVDI soporta diferentes configuraciones de hipervisores basadas en la arquitectura de despliegue y los requisitos de enrutamiento del tráfico de video. Comprender estos tipos es esencial para la configuración adecuada de la red y la optimización del rendimiento.

Tipo Hipervisor

El tipo hipervisor incluye servicios integrados de proxy de video que permiten conexiones directas de clientes al hipervisor para la transmisión de escritorio:

  • Servicios de video integrados: Incluye el proxy isard-video para gestionar conexiones de video de clientes
  • Acceso directo de clientes: Los clientes se conectan directamente al hipervisor para el tráfico de video/pantalla (puertos 5900-7899)
  • Auto-contenido: Solución completa de hipervisor con capacidades integradas de proxy de video
  • Soporte Letsencrypt: Puede generar sus propios certificados SSL para conexiones de video seguras
  • Rendimiento óptimo: Elimina la sobrecarga del proxy de video sirviendo clientes directamente

Características de red:

  • Requiere puertos 5900-7899 TCP abiertos para el acceso directo de video de los clientes
  • El tráfico de video fluye directamente de los clientes al hipervisor
  • Reduce la latencia de red y la carga del proxy central
  • Cada hipervisor gestiona sus propios certificados de video y proxy

Tipo Hipervisor-Standalone

El tipo hipervisor-standalone opera sin servicios de video integrados, confiando en un proxy de video central:

  • Sin proxy de video integrado: No incluye el servicio isard-video
  • Enrutamiento de video centralizado: Todo el tráfico de video se proxy a través del servicio principal de video de IsardVDI
  • Despliegue simplificado: Huella mínima de hipervisor centrada en la ejecución de VMs
  • Gestión central: Certificados de video y configuración de proxy gestionados centralmente
  • Arquitectura escalable: Ideal para despliegues grandes con muchos hipervisores

Características de red:

  • Flujo de tráfico de video: Cliente → IsardVDI Central → Hipervisor-Standalone
  • Requiere configuración VIDEO_HYPERVISOR_HOSTNAMES en el servidor central IsardVDI
  • Requiere puertos 5900-7899 TCP abiertos en el hipervisor-standalone para el acceso del proxy de video
  • El proxy central gestiona toda la terminación SSL y el enrutamiento de video
  • El hipervisor solo necesita conectividad saliente a los servicios centrales

Modos Operacionales

Independientemente del tipo, los hipervisores pueden operar en diferentes modos funcionales:

Hipervisor puro

Cuando se edita o se crea un hipervisor, se puede verificar si será solo un hipervisor. En este modo, ese servidor solo será utilizado por IsardVDI para ejecutar escritorios virtuales. Este servidor no manejará operaciones de discos virtuales.

Operaciones de disco puro

En este modo, el servidor solo se utilizará para manejar operaciones de disco de escritorios virtuales.

Hipervisor mixto + operaciones de disco

Este modo utilizará el servidor tanto para ejecutar escritorios virtuales como para ejecutar operaciones de disco virtual.

Modos de tunelización VPN

Nueva característica

La configuración del modo de tunelización VPN está disponible para hipervisores para optimizar el rendimiento de la red y la compatibilidad.

IsardVDI soporta dos modos de tunelización VPN diferentes para hipervisores, permitiendo a los administradores elegir la configuración de red más apropiada basada en sus requisitos de infraestructura:

WireGuard + Geneve (Por defecto)

Este es el modo de tunelización por defecto y recomendado que proporciona:

  • Cifrado VPN completo: Todo el tráfico entre el hipervisor y el servidor principal de IsardVDI está cifrado usando WireGuard
  • Conexiones remotas seguras: Ideal para hipervisores ubicados en diferentes redes o a través de internet
  • Configuración automática del túnel Geneve: Crea redes superpuestas para el tráfico de escritorios virtuales
  • Alta seguridad: Mejor opción cuando los hipervisores están en redes no confiables

Casos de uso:

  • Hipervisores en ubicaciones remotas
  • Hipervisores externos a través de internet
  • Despliegues multi-sitio
  • Cuando se requiere máxima seguridad

Solo Geneve

Este modo usa solo tunelización Geneve sin cifrado WireGuard:

  • Conectividad de red directa: Asume que los hipervisores pueden alcanzar directamente el servidor principal
  • Menor sobrecarga: Reduce la sobrecarga de cifrado para mejor rendimiento
  • Redes simplificadas: Más fácil de solucionar problemas y monitorear
  • Despliegues locales: Ideal para redes locales confiables

Casos de uso:

  • Hipervisores en el mismo centro de datos
  • Entornos de red local confiable
  • Requisitos de alto rendimiento con sobrecarga mínima
  • Redes donde el cifrado se maneja a nivel de infraestructura

Configuración

El modo de tunelización VPN puede configurarse al crear o editar un hipervisor:

  1. A través de la interfaz web: Seleccione el modo de tunelización deseado en el formulario de configuración del hipervisor
  2. A través de la API: Establezca el campo vpn_tunneling_mode a "wireguard+geneve" o "geneve"

Consideraciones importantes:

Requisitos de red

Puertos requeridos por modo de tunelización:

Modo WireGuard + Geneve: - 4443 UDP: Túnel WireGuard desde hipervisor a isard-vpn (configurable via WG_HYPERS_PORT) - 2022 TCP: Control SSH desde isard-engine a hipervisor - 5900-7899 TCP: Tráfico de vídeo/pantalla al hipervisor - 6379 TCP: Tareas Redis desde hipervisor a isard-storage

Modo Solo Geneve: - 6081 UDP: Túnel Geneve directo desde hipervisor a isard-vpn (puerto estándar Geneve) - 2022 TCP: Control SSH desde isard-engine a hipervisor
- 5900-7899 TCP: Tráfico de vídeo/pantalla al hipervisor - 6379 TCP: Tareas Redis desde hipervisor a isard-storage

Configuración de puertos

  • El puerto WireGuard puede personalizarse via WG_HYPERS_PORT en isardvdi.cfg (por defecto: 4443)
  • Geneve usa el puerto UDP estándar 6081 para encapsulación del túnel
  • Todos los puertos deben ser accesibles entre hipervisor y servidor IsardVDI

Rendimiento vs Seguridad

Elija WireGuard + Geneve para máxima seguridad y Solo Geneve para máximo rendimiento en redes confiables.

Detalles técnicos

  • Tunelización Geneve: Crea redes superpuestas usando encapsulación UDP (puerto 6081)
  • Cifrado WireGuard: Proporciona cifrado VPN de última generación cuando está habilitado (puerto 4443 por defecto)
  • Configuración automática: IsardVDI configura automáticamente el modo de tunelización elegido
  • Integración OVS: Ambos modos se integran perfectamente con Open vSwitch para gestión de red

Resumen de Requisitos de Puertos

Tipo de Tráfico WireGuard+Geneve Solo Geneve Dirección Abrir/Redirigir Dónde Descripción
Túnel VPN 4443/UDP 6081/UDP Hipervisor → IsardVDI Servidor IsardVDI (entrante) Conexión de túnel primario
Control SSH 2022/TCP 2022/TCP IsardVDI → Hipervisor Hipervisor (entrante) Gestión del motor
Video/Pantalla 5900-7899/TCP 5900-7899/TCP Cliente → Hipervisor Solo Hipervisor Autónomo Transmisión de escritorio
Tareas Almacenamiento 6379/TCP 6379/TCP Hipervisor (isard-storage) → IsardVDI Servidor IsardVDI (entrante) Operaciones Redis/almacenamiento

Configuración del Firewall y Redirección de Puertos

Para el modo WireGuard + Geneve: 

# En el servidor IsardVDI - redirigir conexiones entrantes a IPs específicas de contenedores
iptables -t nat -A PREROUTING -p udp --dport 4443 -j DNAT --to-destination 172.31.255.23:4443
# O usando firewalld:
firewall-cmd --add-forward-port=port=4443:proto=udp:toaddr=172.31.255.23:toport=4443 --permanent

# En el hipervisor - redirigir conexiones SSH entrantes al contenedor hipervisor
iptables -t nat -A PREROUTING -p tcp --dport 2022 -j DNAT --to-destination 172.31.255.17:22
# O usando firewalld:
firewall-cmd --add-forward-port=port=2022:proto=tcp:toaddr=172.31.255.17:toport=22 --permanent

Para el modo Solo Geneve: 

# En el servidor IsardVDI - redirigir conexiones entrantes a IPs específicas de contenedores
iptables -t nat -A PREROUTING -p udp --dport 6081 -j DNAT --to-destination 172.31.255.23:6081
iptables -t nat -A PREROUTING -p tcp --dport 6379 -j DNAT --to-destination 172.31.255.12:6379
# O usando firewalld:
firewall-cmd --add-forward-port=port=6081:proto=udp:toaddr=172.31.255.23:toport=6081 --permanent
firewall-cmd --add-forward-port=port=6379:proto=tcp:toaddr=172.31.255.12:toport=6379 --permanent

# En el hipervisor - redirigir conexiones SSH entrantes al contenedor hipervisor
iptables -t nat -A PREROUTING -p tcp --dport 2022 -j DNAT --to-destination 172.31.255.17:22
# O usando firewalld:
firewall-cmd --add-forward-port=port=2022:proto=tcp:toaddr=172.31.255.17:toport=22 --permanent

Detalles de Redirección de Puertos Docker

Estos puertos deben ser redirigidos a las direcciones IP específicas de los contenedores Docker en la red IsardVDI:

En el lado del servidor IsardVDI (red por defecto: 172.31.255.0/24): - WireGuard (4443/UDP) → Redirigir a 172.31.255.23:4443 (contenedor isard-vpn) - Geneve (6081/UDP) → Redirigir a 172.31.255.23:6081 (contenedor isard-vpn)
- Redis (6379/TCP) → Redirigir a 172.31.255.12:6379 (contenedor isard-redis si el hipervisor tiene isard-storage también)

En el lado del hipervisor (red por defecto: 172.31.255.0/24): - SSH (2022/TCP) → Redirigir a 172.31.255.17:22 (contenedor isard-hypervisor)

Puertos adicionales para hipervisor-standalone (acceso video/pantalla): 

# En hipervisor-standalone - redirigir puertos de video/pantalla para acceso directo del cliente
iptables -t nat -A PREROUTING -p tcp --dport 5900:7899 -j DNAT --to-destination 172.31.255.17:5900-7899
# O usando firewalld (ejemplo para puertos específicos):
firewall-cmd --add-forward-port=port=5900:proto=tcp:toaddr=172.31.255.17:toport=5900 --permanent
# ... repetir para el rango 5900-7899 según sea necesario

Notas: - Estas IPs son configurables via la variable de entorno DOCKER_NET (por defecto: 172.31.255) - Los hipervisores solo necesitan conexiones salientes permitidas para el establecimiento del túnel - Use docker network inspect isard-network para verificar las IPs actuales de los contenedores - El router/firewall debe redirigir puertos externos a estas IPs internas de contenedores

Configuración del Proxy de Video para hipervisor-standalone

Cuando se usa el tipo hipervisor-standalone, debe configurar los ajustes del proxy de video:

En isardvdi.cfg en el servidor IsardVDI: 

# Permitir que los hosts hipervisor-standalone sean proxied para el tráfico de video
# Nota: si el IsardVDI principal es un tipo all-in-one con un hipervisor,
#       también debe agregar a la lista el nombre isard-hypervisor mismo.
VIDEO_HYPERVISOR_HOSTNAMES=hipervisor1.ejemplo.com,hipervisor2.ejemplo.com
VIDEO_HYPERVISOR_PORTS=5900-7899

Consideraciones de seguridad: - Solo agregue nombres de host de hipervisores confiables a VIDEO_HYPERVISOR_HOSTNAMES - Esta configuración controla qué hipervisores aceptará conexiones el proxy de video de IsardVDI - Lista separada por comas de nombres de host como se ven desde el servidor IsardVDI

Hipervisores externos

El método recomendado para configurar un nuevo hipervisor es usar la imagen docker isard-generic-hiper, ya que mostrará todos los servicios necesarios en cualquier host de Linux con docker. Se requieren tres pasos:

  1. Se instala el hipervisor KVM (se recomienda docker)
  2. Se agrega claves ssh para el nuevo hipervisor KVM
  3. Se crea un nuevo hipervisor en la interfaz de usuario web de IsardVDI.

Instalar hipervisor KVM

Instalación de Docker (recomendado)

La configuración rápida y sencilla de un hipervisor externo se puede realizar utilizando el archivo de composición generado ./build.sh hipervisor hipervisor.yml. En el Linux limpio donde se ha instalado el servidor que será el hipervisor KVM, se inicia el contenedor:

./build.sh hipervisor
docker-compose -f hipervisor.yml up -d

Se tiene que configurar el archivo isardvdi.cfg antes de crear el archivo hipervisor.yml.

Principalmente, se puede configurar allí el dominio de video letsencrypt (si no, usará un certificado autogenerado). Eso debería mostrar un hipervisor Isard completo en su servidor.

Si no se establece una configuración de letsencrypt en el archivo isardvdi.cfg, se debe configurar los mismos certificados de visores en todos los hipervisores. En este caso, se debe copiar los archivos de certificado /opt/isard/certs/viewers/* del host web a la misma carpeta en sus hipervisores remotos (eliminando los que ya están allí) y se vuelve a abrir la ventana acoplable del hipervisor.

Se ejecuta este comando para restablecer las claves ssh y la contraseña:

docker exec -e PASSWORD=<YOUR_ROOT_PASSWORD> isard-hipervisor bash -c '/reset-hiper.sh'

Después de eso, se puede continuar agregando claves ssh para este hipervisor en su contenedor IsardVDI isard-engine y se crea un nuevo hipervisor en la interfaz de usuario:

docker exec -e HipeRVISOR=<IP|DNS> -e PASSWORD=<YOUR_ROOT_PASSWD> -e PORT=2022 isard-engine bash -c '/add-hipervisor.sh'; history -d $((HISTCMD-1))

Manual de instalación

Si se desea utilizar otro host como hipervisor KVM, se tiene que asegurar de que tenga:

  • libvirtd:

    • servicio funcionando: systemctl status libvirtd. Consulte con su distribución cómo instalar un hipervisor KVM completo:

    • https://wiki.debian.org/KVM#Installation

    • https://help.ubuntu.com/community/KVM/Installation
    • https://wiki.centos.org/HowTos/KVM

    • https://wiki.alpinelinux.org/wiki/KVM

    • certificados habilitados: los certificados reales en la ruta IsardVDI /opt/isard/certs/default/ se deben copiar en la nueva ruta del servidor KVM /etc/pki/libvirt-spice . También se deben agregar algunas líneas a libvirtd.conf y qemu.conf para hacer uso de los certificados:

    • bash echo "listen_tls = 0" >> /etc/libvirt/libvirtd.conf; echo 'listen_tcp = 1' >> /etc/libvirt/libvirtd.conf; echo 'spice_listen = "0.0.0.0"' >> /etc/libvirt/qemu.conf echo 'spice_tls = 1' >> /etc/libvirt/qemu.conf

    • servidor websocket: para permitir la conexión a los espectadores a través de los navegadores, también se debe configurar un servidor websocket. Se debería mirar el start_proxy.py incluido en los acopladores/hipervisores.

  • Servicio sshd en ejecución y accesible para el usuario: systemctl status sshd

  • curl: Se utilizará para obtener actualizaciones.
  • qemu-kvm: Se debe crear un enlace al qemu-system-x86_64 como este ln -s /usr/bin/qemu-system-x86_64 /usr/bin/qemu-kvm

Agregar claves ssh para el nuevo hipervisor

Previamente se debe agregar claves ssh para acceder a ese hipervisor. Para hacer esto, se proporciona un script dentro del contenedor isard-app:

docker exec -e HipeRVISOR=<IP|DNS> -e PASSWORD=<YOUR_ROOT_PASSWD> isard-engine bash -c '/add-hipervisor.sh'

Nota: Hay parámetros opcionales que se pueden configurar:

  • PORT: Default is 22
  • USER: Default is root

Después de hacer esto, se debe ir al menú de hipervisores y agregar un nuevo hipervisor con la misma IP/DNS. Engine intentará conectarse cuando habilite ese hipervisor.

Ejemplo:

Se tiene que tener en cuenta que se ha añadido ; history -d $((HISTCMD-1)) al comando para evitar que la contraseña se mantenga en nuestro historial.

root@server:~/isard# docker exec -e HipeRVISOR=192.168.0.114 -e PASSWORD=supersecret isard_isard-app_1 bash -c '/add-hipervisor.sh'; history -d $((HISTCMD-1))
fetch http://dl-cdn.alpinelinux.org/alpine/v3.8/main/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/v3.8/community/x86_64/APKINDEX.tar.gz
fetch http://dl-cdn.alpinelinux.org/alpine/edge/testing/x86_64/APKINDEX.tar.gz
(1/1) Installing sshpass (1.06-r0)
Executing busybox-1.28.4-r2.trigger
OK: 235 MiB in 127 packages
Trying to ssh into 192.168.0.114...
# 192.168.0.114:22 SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.1
# 192.168.0.114:22 SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.1
# 192.168.0.114:22 SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.1
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/root/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
expr: warning: '^ERROR: ': using '^' as the first character
of a basic regular expression is not portable; it is ignored

/usr/bin/ssh-copy-id: WARNING: All keys were skipped because they already exist on the remote system.
  (if you think this is a mistake, you may want to use -f option)

Hipervisor ssh access granted.
Access to 192.168.0.114 granted and found libvirtd service running.
Now you can create this hipervisor in IsardVDI web interface.

Si falla, se deshabilita el hipervisor, se editan los parámetros y se habilita nuevamente. El engine de IsardVDI verificará la conexión nuevamente. Se puede ver el mensaje de error en los detalles del hipervisor (se pulsa el icono "+" para ver los detalles).

Si el engine no intenta volver a conectarse después de habilitar el nuevo hipervisor, se tiene que reiniciar el contenedor de "isard-app":

docker restart isard_isard-app_1

NOTA: Probablemente se desee eliminar el hipervisor isard predeterminado después de crear un nuevo hipervisor externo. Para ello, se deshabilita "isard-hipervisor" y se elimina desde los detalles del hipervisor. Después se puede realizar la acción Forzar eliminación y se vuelve a reiniciar el contenedor de la aplicación isard.

Agregar hipervisor en la interfaz de usuario web

Se puede agregar un hipervisor externo en la interfaz de usuario web como usuario administrador. Para ello se tiene que ir al panel de administración y en el apartado de "Hipervisors", se pulsa el botón "Add new"

Y aparecerá una ventana de diálogo donde se pueden rellenar los campos. Se puede configurar cualquier cosa en el campo ID para identificar este hipervisor, pero se tiene que tener cuidado con otros campos de configuración, ya que deben coincidir con el hipervisor remoto:

El nombre de host debe ser la IP/DNS accesible desde esta instalación de IsardVDI. Podría ser una red interna entre ambos hosts. El usuario será root y el puerto ssh 2022 ya que se deja el puerto ssh predeterminado 22 para el acceso ssh al host.

Se recomienda activar las opciones de "disk operations" y "hipervisor" y configurar el host web para este servidor IP/DNS de instalación web y el proxy de video para el IP/DNS accesible externamente para el hipervisor (acceso a sus visores a través de los puertos 80 y 443).

Se establece el nombre de host del hipervisor del proxy de video a isard-hipervisor, ya que es el nombre del contenedor para los valores predeterminados del hipervisor.

VLANS en hipervisor

Para conectar una interfaz troncal con definiciones de vlan dentro del hipervisor, se debe configurar (y descomentar) las variables en el fichero isardvdi.cfg:

NOTA IMPORTANTE: Recordar rehacer un build del docker-compose emitiendo el comando ./build.sh nuevamente.

  • HipeRVISOR_HOST_TRUNK_INTERFACE: Este es el nombre de la interfaz troncal de la red del host como se ve en el host. Por ejemplo: eth1

Si no se configura HipeRVISOR_STATIC_VLANS, el hipervisor detectará automáticamente las vlans durante 260 segundos cada vez que inicie el contenedor isard-hipervisor. Por lo tanto, es mejor definir las VLANs estáticas que se sepan que están en el tronco.

  • HipeRVISOR_STATIC_VLANS: Se tiene que establecer una lista de números de vlan separados por comas. Configurar esto evitará la detección automática de VLAN durante 260 segundos.

Esto agregará a la base de datos las VLANs encontradas como 'vXXX', donde XXX es el número de VLAN encontrado. Para que esto funcione, se debe verificar que se pueda acceder a STATS_RETHINKDB_HOST en el puerto 28015 desde el hipervisor.

Se comprueba que el que contiene el isard-db tenga el nombre de host correcto. Esto solo es necesario si se tiene el hipervisor en otra máquina:

  • STATS_RETHINKDB_HOST: Se debe establecer en el host isard-db correcto si se tiene el hipervisor en otra máquina. No es necesario si se tiene un IsardVDI 'todo en uno'.

NOTA: La interfaz del host debe estar en modo promisorio: ip link set dev ethX promic on. Si se inicia el contenedor isard-hipervisor, se debe detener y volver a iniciar.

Conceptos de infraestructura

Cuando se agrega un hipervisor externo, se debe tener en cuenta (y configurar según sea necesario) lo siguiente:

  • Ruta de los discos: Por defecto almacenará los discos en /opt/isard. No es necesario crear esa carpeta, pero se recomienda montar el almacenamiento de E/S rápido (como el disco nvme) en esa ruta.

  • Rendimiento de la red: Si se va a utilizar un NAS se debe tener en cuenta que se debe utilizar una red rápida. Velocidad de red recomendada superior a 10 Gbps.

Rendimiento de los discos

Como se usan diferentes rutas para bases, plantillas y discos de grupos, se podría mejorar el rendimiento montando diferentes discos nvme de almacenamiento en cada ruta:

  • /opt/isard/bases: Allí residirán las imágenes base que se creen. Por lo general, esas imágenes de disco se utilizarán como base para muchas plantillas y discos de usuario (grupos), por lo que el almacenamiento debe proporcionar un acceso de lectura lo más rápido posible.

  • /opt/isard/templates: las plantillas también se utilizarán como discos principales para varios discos de usuario (grupos). Así que mejor usar un disco de acceso de lectura rápida.

  • /opt/isard/groups: los escritorios en ejecución residirán aquí. Por lo tanto, aquí se realizarán muchas E/S simultáneas, por lo que el almacenamiento debe proporcionar la mayor cantidad de IOPS posible. Los discos NVME (o incluso las incursiones NVME) brindarán el mejor rendimiento.

Rendimiento de la red

La red de almacenamiento entre los hipervisores y los servidores de almacenamiento NAS debe ser de al menos 10 Gbps. Todos los hipervisores deben montar el almacenamiento en la ruta /isard y ese montaje debe ser el mismo para todos los hipervisores.

Como se puede elegir al crear un hipervisor que sea un hipervisor puro, operaciones de disco puro o uno mixto, se puede agregar servidores de almacenamiento NAS como operaciones de disco puro. Eso traerá una manipulación más rápida de los discos, ya que IsardVDI utilizará el almacenamiento directo y los comandos en NAS.

En IsardVDI se tiene una infraestructura con seis hipervisores y dos NAS pacemaker agrupados de fabricación propia que comparten almacenamiento con NFSv4 y el rendimiento es muy bueno.

Documentos técnicos de alta disponibilidad/alto rendimiento

Se intenta mantener todo el conocimiento y experiencia de IsardVDI en clústeres de alto rendimiento y disponibilidad utilizando pacemaker, drbd, cachés de disco, migraciones en vivo, etc. en el apartado de Project Deploy del manual.

En ese apartado del manual se encuentran vídeos sobre la migración de almacenamiento y escritorio virtual en vivo que se hicieron en la infraestructua de IsardVDI: migrar el escritorio virtual de un hipervisor a otro mientras al mismo tiempo migramos su almacenamiento de un almacenamiento NAS a otro sin que el usuario del escritorio virtual supiera lo que había sucedido.

Flujo de Auto-registro de Hipervisores y Configuración VPN

Entendiendo el Proceso

Esta sección explica cómo los hipervisores se registran automáticamente con el sistema IsardVDI y establecen conectividad de red segura.

Cuando un contenedor hipervisor se inicia con la configuración adecuada, ocurre el siguiente proceso automatizado de auto-registro:

1. Auto-registro del Hipervisor

graph TD
    A[Hipervisor inicia con entorno cfg] --> B[Hipervisor contacta API IsardVDI]
    B --> C[API registra/actualiza hipervisor en base de datos]
    C --> D[Evento activa actualización configuración isard-vpn]
    D --> E[Hipervisor solicita configuración final de API]
    E --> F[Hipervisor configura VPN según modo de tunelización]
    F --> G[Hipervisor realiza auto-verificaciones]
    G --> H[Hipervisor se auto-habilita en base de datos]
    H --> I[isard-engine se conecta vía SSH para verificación]
    I --> J[Motor establece estado final del hipervisor]

Proceso paso a paso:

  1. Registro API: El hipervisor contacta la API IsardVDI con sus variables de entorno de configuración
  2. Actualización Base de Datos: La API crea o actualiza la entrada del hipervisor en la base de datos IsardVDI con parámetros de configuración
  3. Activación Evento VPN: El cambio en la base de datos activa un evento en isard-vpn para actualizar la configuración de red del hipervisor
  4. Recuperación Configuración: El hipervisor solicita su configuración final de la API (claves WireGuard, configuración de red, etc.)

2. Establecimiento del Túnel VPN

El proceso de configuración VPN difiere según el modo de tunelización configurado:

Modo WireGuard + Geneve

# 1. isard-vpn genera la configuración WireGuard
# 2. El hipervisor recibe configuración peer WireGuard vía API
# 3. Túnel WireGuard establecido (4443/UDP por defecto)
# 4. Red overlay Geneve creada sobre túnel WireGuard
# 5. Puentes OVS configurados para redes de máquinas virtuales

Flujo de configuración:

  • El contenedor isard-vpn genera claves WireGuard únicas para el hipervisor
  • El hipervisor recibe configuración vía llamadas API de IsardVDI
  • Se crea y configura la interfaz WireGuard (wg-hypers)
  • Los túneles Geneve se establecen sobre la conexión WireGuard cifrada
  • Se crean puertos Open vSwitch y se configuran reglas de flujo

Modo Solo Geneve

# 1. El hipervisor resuelve el hostname/IP del servidor IsardVDI
# 2. Túnel Geneve directo establecido (6081/UDP)
# 3. Puentes y puertos OVS configurados
# 4. Conexión Redis establecida para operaciones de almacenamiento (6379/TCP)

Flujo de configuración:

  • El hipervisor se conecta directamente a la IP del contenedor isard-vpn (172.31.255.23:6081)
  • Se crea la interfaz de túnel Geneve sin capa de cifrado
  • Se configuran puertos OVS y reglas de flujo para redes directas
  • Las operaciones de almacenamiento se conectan directamente a isard-redis (172.31.255.12:6379)

3. Configuración de Interfaces de Red

Configuración de Puente OVS:

# Creación automática de puente
ovs-vsctl add-br br-int
ovs-vsctl add-port br-int geneve0 -- set interface geneve0 type=geneve options:remote_ip=<IsardVDI_IP>

# Reglas de flujo para tráfico de VMs
ovs-vsctl set-controller br-int tcp:127.0.0.1:6633

Componentes clave de red:

  • br-int: Puente de integración principal para conectividad de VMs
  • geneve0: Interfaz de túnel para redes overlay
  • Reglas de flujo: Configuradas automáticamente según requisitos de escritorio virtual
  • Soporte VLAN: Detección y configuración automática de VLAN si las interfaces trunk están configuradas

4. Configuración de Certificados y Seguridad

Gestión automática de certificados:

  • Certificados de visor descargados del servidor IsardVDI
  • Certificados TLS para comunicación segura del hipervisor
  • Procesos de validación y renovación de certificados

5. Inicialización de Servicios

Servicios de contenedor iniciados:

  • isard-hypervisor: Servicio principal de gestión de hipervisor
  • isard-storage: Operaciones de almacenamiento (si está habilitado para hipervisores mixtos/almacenamiento)
  • Servicios de proxy de video (para despliegues hipervisor-standalone)

6. Monitorización de Salud y Mantenimiento

Procesos continuos:

  • Verificaciones regulares de salud vía SSH desde isard-engine
  • Renovación y actualizaciones de certificados
  • Monitorización de túnel VPN y reconexión automática
  • Actualizaciones de reglas de flujo OVS según el ciclo de vida del escritorio virtual

Resolución de Problemas Comunes

Fallos de conexión: - Verificar autenticación de clave SSH entre isard-engine e hipervisor - Comprobar que las reglas de firewall permiten puertos necesarios (2022/TCP, 4443/UDP o 6081/UDP) - Asegurar resolución DNS adecuada entre hipervisor y servidor IsardVDI

Problemas de túnel VPN: - Comprobar logs del contenedor isard-vpn para errores WireGuard/Geneve - Verificar que las reglas de reenvío IP del contenedor están configuradas correctamente - Confirmar que el entorno DOCKER_NET coincide con las IPs reales del contenedor

Problemas de configuración OVS: - Comprobar errores de creación de puertos duplicados en los logs del hipervisor - Verificar asignación adecuada de ofport de interfaz - Asegurar que no hay configuraciones de red conflictivas

Monitorizar el Proceso de Configuración

Comandos útiles para monitorizar: 

# Comprobar estado de conexión del hipervisor
docker logs isard-engine | grep <hypervisor_hostname>

# Monitorizar establecimiento de túnel VPN
docker logs isard-vpn | grep -E "(peer|tunnel|geneve)"

# Verificar configuración OVS
docker exec isard-hypervisor ovs-vsctl show

# Comprobar conexiones WireGuard activas (si se usa modo WireGuard)
docker exec isard-vpn wg show