ES2719301T3 - Canal de gestión habilitado por el host - Google Patents

Abstract

Un procedimiento para proporcionar una conectividad de red entre una máquina virtual, VM, diana que se ejecuta en un primer host y una aplicación que se ejecuta en un segundo host, comprendiendo el procedimiento: recibir (282), mediante una red en el primer host, un paquete (223) dirigido a una dirección de red del primer host, comprendiendo el paquete una carga útil conforme a un protocolo a nivel de aplicación e información que identifica la VM diana; formar (290) un canal de comunicaciones entre un hipervisor en el primer host que gestiona la VM diana y la VM diana; en función de la información que identifica la VM diana en el paquete, pasando (292) el paquete a la VM diana a través del canal; y suministrar (298) la carga útil a un agente que se ejecuta en la VM diana después de que la VM diana ha recibido el paquete a través del canal de comunicaciones.

Description

DESCRIPCIÓN

Canal de gestión habilitado por el host

Antecedentes

En el campo de la virtualización de máquinas, las máquinas virtuales (VM) tienen una funcionalidad de red. Es decir, las VM pueden implementar una pila de protocolos de red para comunicarse mediante una red con otras VM o máquinas físicas. Por ejemplo, los anfitriones de virtualización (por ejemplo, anfitriones Hyper-V (TM)) pueden formar parte de un tejido de virtualización que alberga VM invitadoes, gestionando un controlador de tejido el tejido de virtualización (según se utiliza en esta sección de Antecedentes, “host” puede hacer referencia a un controlador de tejido, por ejemplo, o cualquier otro ordenador). Sin embargo, por diversas razones, puede no haber ninguna conectividad de red entre un host en una red y una VM, aunque haya una conectividad de red entre el host y una máquina que ejecuta la VM (denominada “VM host”). Por ejemplo, la VM podría estar en una red privada virtual (VPN) a la que no pertenece el host y la dirección de red de las VM puede no ser válida en la red del host. Un cortafuegos podría bloquear el acceso a la VM desde la red de los anfitriones mientras que permite el acceso en la red de la VM host. Una VM podría simplemente encontrarse en una red distinta que el host que podría necesitar comunicarse con la VM.

En algunas circunstancias, es deseable comunicarse con una VM utilizando un protocolo estándar tal como HTTP (Protocolo de transferencia de hipertexto), SOAP (Protocolo simple de acceso a objetos), WMI (TM) (Instrumentación de Gestión de Windows), el protocolo WS-Management (que transporta llamadas WMI mediante un protocolo basado en SOAP mediante HTTP), etcétera. Por ejemplo, en algunos centros o nubes de datos, las VM pueden tener agentes o servicios de red que se ejecutan en las mismas que llevan a cabo funciones de gestión (tales como aplicar parches a un sistema operativo invitado, gestionar tareas del tejido de la nube, etc.), quizás con uno o más canales de comunicaciones para el control (por ejemplo, WMI en HTTP) o datos (BITS mediante HTTP). Estos servicios o agentes de gestión están controlados por una aplicación de gestión (por ejemplo, un controlador de tejido), que se ejecuta en un host controlador, por ejemplo. La aplicación de gestión envía paquetes, por ejemplo paquetes de HTTP, a la dirección de red de la VM y los paquetes de HTTP son suministrados al agente de gestión. Los agentes de gestión pueden llevar a cabo funciones en respuesta a la información en las cargas útiles de los paquetes. Sin embargo, cuando la aplicación de gestión no tiene una conectividad de red con la VM, es incapaz de invocar a los agentes de gestión en la VM.

A continuación se exponen técnicas para permitir la comunicación con VM mediante canales de comunicaciones entre hipervisores y las VM.

El documento WO 2007/087558 A2 versa acerca de técnicas para establecer una conexión entre un sistema cliente y una máquina virtual. En algunos ejemplos, un componente de identificación recibe una identificación de una máquina virtual proporcionando un entorno informático solicitado, siendo sensible la máquina virtual seleccionada a una identificación recibida de un usuario de la máquina solicitante. Un componente de ejecución lanza la máquina virtual en un hipervisor. Un componente de gestión establece una conexión entre la máquina solicitante y la máquina virtual, y gestiona la conexión.

Sumario

El objeto de la presente invención es mejorar la eficacia de los sistemas de la técnica anterior.

Se soluciona este objeto mediante el contenido de la reivindicación independiente.

Las realizaciones preferentes están definidas por las reivindicaciones dependientes.

El siguiente sumario se incluye únicamente para introducir algunos conceptos expuestos en la siguiente Descripción detallada. Este sumario no es extenso y no se prevé que limite el alcance de la materia objeto reivindicada, que se define mediante las reivindicaciones presentadas al final.

Se proporciona un recorrido lógico de comunicación entre una máquina virtual (VM) diana y un host o aplicación que se comunica con la VM. Por ejemplo, un recorrido entre el host de virtualización y una VM. La VM diana se ejecuta en un hipervisor host que tiene un hipervisor y un agente delegado (por ejemplo, un delegado HTTP). El hipervisor gestiona la ejecución de la VM. Se mantiene una correspondencia que indica qué VM se ejecutan en qué anfitriones. Cuando el host o la aplicación ha de enviar un mensaje o paquete a la VM diana, se consulta la correspondencia y se identifica el hipervisor host que alberga la VM diana. El mensaje o el paquete, que puede identificar la VM diana, se transmite al hipervisor host. Un agente delegado en el hipervisor host selecciona un canal de comunicaciones entre el hipervisor y la VM diana. Entonces, el hipervisor pasa el mensaje o el paquete a través del canal seleccionado a la VM diana.

A continuación se explicarán muchas de las características concomitantes con referencia a la siguiente descripción detallada considerada en conexión con los dibujos adjuntos.

Breve descripción de los dibujos

Se comprenderá mejor la presente descripción a partir de la siguiente descripción detallada leída teniendo en cuenta los dibujos adjuntos, en los que se utilizan números similares de referencia para designar partes similares en la descripción adjunta.

La Figura 1 muestra una capa ejemplar de virtualización.

La Figura 2 muestra procesos e interacciones de virtualización de una capa con respecto a máquinas virtuales e imágenes de máquinas virtuales.

La Figura 3 muestra un ejemplo de una aplicación que se comunica con un agente que se ejecuta en un sistema operativo invitado albergado por una VM.

La Figura 4 muestra una vista general de un recorrido lógico de comunicaciones entre la aplicación y una VM. La Figura 5 muestra un host cliente que inicia una conexión con una VM.

La Figura 6 muestra un hipervisor host que gestiona un paquete procedente del cliente host.

Descripción detallada

Las realizaciones expuestas a continuación versan acerca del uso de canales internos de comunicaciones en un hipervisor host/VM para permitir una comunicación externa de red. La exposición comenzará con una vista general de la tecnología de virtualización y las capas de virtualización (también denominadas hipervisores). A continuación se describirá un ejemplo de una comunicación de red entre una aplicación y una VM. Se explicará una vista general de un recorrido lógico de comunicaciones que utiliza canales privados en un hipervisor host. Finalmente, se describirán en detalle los detalles de tal recorrido de comunicaciones, incluyendo una aplicación en un extremo del recorrido de comunicaciones y un hipervisor host (VM host) en otro extremo del recorrido de comunicaciones.

Virtualización de máquina

La Figura 1 muestra una capa ejemplar 100 de virtualización. Un ordenador 102 tiene un soporte físico 104, que incluye una unidad central 106 de procesamiento (CPU), una memoria 108, una interfaz 110 de red, un almacenamiento no volátil 112 y otros componentes no mostrados, tales como un bus, un adaptador de visualización, etc. La capa 100 de virtualización gestiona y facilita la ejecución de las máquinas virtuales 114. Aunque no se muestra en la Figura 1, cada máquina virtual 114 normalmente tiene una imagen virtual asociada de disco y un sistema operativo invitado. En aras de la brevedad, el sistema operativo y quizás el soporte lógico de aplicación de una máquina virtual 114 serán denominados, a veces, invitado, que se almacena o ejecuta desde la imagen virtual de disco asociada con la máquina virtual 114. En aras de la conveniencia, se utilizará en la presente memoria el término “hipervisor” para hacer referencia a las diversas formas de capas de virtualización. Además, como se expondrá a continuación, se utilizan las máquinas virtuales 114 para albergar elementos de aplicaciones distribuidas.

La capa 100 de virtualización puede ser de cualquier variedad de implementación conocida o futura, tal como Hyper-V Server (TM), VMWare ESX Server (TM), Xen, Oracle VM (TM), etc. La arquitectura de la capa de virtualización puede ser un tipo albergado, con un monitor de la máquina virtual (VMM) que se ejecuta en un sistema operativo host, o un tipo que parte de cero con un hipervisor o similar que se ejecuta directamente en el soporte físico 104 del ordenador 102. Según se utiliza en la presente memoria, la expresión “máquina virtual” hace referencia a una máquina virtual de tipo sistema que simula cualquier arquitectura específica de soporte físico (por ejemplo, x86) con capacidad para ejecutar código nativo para esa arquitectura de soporte físico; para el invitado, la máquina virtual puede ser casi indistinguible de una máquina de soporte físico. Las máquinas virtuales expuestas en la presente memoria no son abstractas o máquinas virtuales de tipo proceso, tales como máquinas virtuales Java.

La capa 100 de virtualización lleva a cabo la función básica de gestión de las máquinas virtuales 114 y de compartición del soporte físico 104 tanto por ella misma como por las máquinas virtuales 114. Se puede utilizar cualquiera de una variedad de técnicas para aislar las máquinas virtuales 114 del soporte físico 104. En una realización, la capa de virtualización puede proporcionar distintos entornos aislados (es decir, particiones o dominios) que se corresponden con máquinas virtuales 114. Parte de la capa 100 de virtualización tal como controladores compartidos de dispositivos virtuales, recursos de comunicaciones entre máquinas virtuales, y API (interfaces de programación de aplicaciones) de gestión de máquinas virtuales, puede ejecutarse en una partición o dominio privilegiado especial, permitiendo un hipervisor compacto y eficaz. En otras realizaciones, la funcionalidad para una gestión de una máquina virtual y una compartición coherente del soporte físico 104 puede residir en un hipervisor monolítico en el soporte físico.

La Figura 2 muestra procesos e interacciones de la capa 100 de virtualización con respecto a máquinas virtuales 114 e imágenes 140 de máquina virtual. La capa 100 de virtualización lleva a cabo un proceso 142 de arranque y ejecución de una máquina virtual 114, posiblemente según los parámetros correspondientes de configuración de la máquina virtual. Cuando se arranca una máquina virtual 114 (VM), la capa de virtualización identifica una imagen asociada 140 de máquina virtual. En la práctica, cualquier máquina virtual 114 puede utilizar cualquier imagen 140 de máquina virtual. La imagen 140 de máquina virtual puede ser un fichero formateado especialmente (por ejemplo, un VHD) en un sistema 141 de ficheros de la capa 100 de virtualización. La capa 100 de virtualización carga la imagen identificada 140 de máquina virtual. La máquina virtual arrancada 114 monta y lee la imagen 140 de máquina virtual, buscando un quizás registro maestro de arranque u otra información de arranque, y arranca un sistema operativo invitado que empieza a ejecutarse.

La capa 100 de virtualización gestiona la ejecución de la máquina virtual 114, gestionando ciertas llamadas al núcleo, hiperllamadas, etc. del invitado, y coordinando el acceso de la máquina virtual 114 al soporte físico subyacente 104. Mientras se ejecutan el invitado y su soporte lógico, la capa 100 de virtualización puede mantener el estado del invitado en la imagen virtual 140 del disco; cuando el invitado, o una aplicación ejecutada por el invitado, escribe datos al “disco”, la capa 100 de virtualización traduce los datos al formato de la imagen virtual 140 del disco y escribe to la imagen.

La capa 100 de virtualización puede llevar a cabo un proceso 144 para apagar la máquina virtual 114. Cuando se recibe una instrucción para detener la máquina virtual 114, se guarda el estado de la máquina virtual 114 y su invitado en la imagen virtual 140 de disco, y se borra el proceso (o partición) que se ejecuta de la máquina virtual 114. Puede permanecer una especificación de la máquina virtual 114 para un rearranque posterior de la máquina virtual 114.

Vista general de la comunicación con una máquina virtual

La Figura 3 muestra un ejemplo de una aplicación 180 que se comunica con un agente 182 que se ejecuta en un sistema operativo invitado (invitado 184), albergado por una VM 186. La aplicación 180, que puede ser una aplicación de gestión, por ejemplo, es ejecutada en un host cliente 188, que puede ser un ordenador normal con una tarjeta 189 de interfaz de red (NIC) para permitir las comunicaciones mediante una red 190. El cliente host 188 tiene una pila de protocolos que comprende diversas implementaciones de protocolo, incluyendo una implementación 192 de protocolo de aplicación (implementada por la aplicación 180), una implementación 194 de un protocolo de transporte y una implementación 196 de un protocolo de red.

El invitado 184 también tiene implementaciones de los protocolos mencionados anteriormente, igual que el hipervisor 196 en el hipervisor host 198. El hipervisor host 198 es un ordenador que ejecuta el hipervisor 196, que gestiona la ejecución de la VM 186. El agente 182 (también denominado “agente invitado 182”) reside en el invitado 184 y puede implementar el mismo protocolo de aplicación implementado por la aplicación 180. La aplicación 180 y el agente invitado 182 pueden ser cualquier variedad de soporte lógico, por ejemplo servicios de red en segundo plano, aplicaciones interactivas, ejecutables, componentes o conjuntos mayores de aplicaciones, etcétera. En una realización, la aplicación 180 es una aplicación de gestión de máquina virtual que gestiona las VM, y el agente 182 lleva a cabo funciones de gestión según comunicaciones con la aplicación 180.

La ejecución de la VM 186 es gestionada por el hipervisor 196,que puede gestionar otras VM no mostradas en la Figura 3. En un caso en el que es posible una conectividad directa entre el cliente host 188 y la VM 186, la aplicación 180 y el agente 182 se comunican mediante la red 190 como sigue. La aplicación 180 forma un mensaje de aplicación según el protocolo 192 de aplicación (por ejemplo, un paquete o mensaje de HTTP). La aplicación 180 solicita que su sistema operativo local envíe el mensaje a la dirección de red (por ejemplo, la dirección de HTTP) del hipervisor host 198. La pila de protocolos del sistema operativo local abre una conexión con el hipervisor host 198, encapsula el mensaje de la aplicación 180 en una carga útil de transporte y la carga útil de transporte en un paquete 202 de red. La cabecera de red del mismo (que contiene la dirección de red del hipervisor host 198) es encaminada a través de la red 190 al hipervisor host 198. El hipervisor host 192 puede pasar el paquete 202 a la VM 186 y, a su vez, al invitado 184 y al agente invitado 182. Por el camino, se extraen diversas cargas útiles mediante las implementaciones respectivas de protocolo, y el agente invitado 182 recibe el mensaje transmitido de aplicación (por ejemplo, “instrucción foo”). El proceso es similar pero invertido cuando el agente invitado 182 transmite un mensaje de aplicación a la aplicación 192.

Según se utiliza en la presente memoria, las expresiones “cliente”, “cliente host”, “aplicación” y “agente”, “hipervisor” e “hipervisor host” se utilizan en sus sentidos más generales. Las plataformas y el soporte lógico particulares que se comunican utilizando técnicas descritas en la presente memoria son de menor importancia. De hecho, puede ser notable que el soporte lógico y los protocolos existentes de nivel de aplicación pueden utilizar las técnicas de comunicaciones descritas a continuación sin una modificación significativa (si la hay), en particular en el extremo que se comunica con una VM mediante una red (por ejemplo, la aplicación 180). Además, aunque a veces se mencionan los protocolos HTTP, IP (protocolo de Internet) y TCP/UDP (Protocolo de control de transmisión/Protocolo de datagrama universal) en aras de la ilustración, las técnicas de comunicaciones descritas a continuación pueden funcionar con cualquier protocolo estándar de red o versiones de los mismos (por ejemplo, SOCKS). Además, en aras de la brevedad, se considerará que “HTTP” hace referencia a versiones o variantes de http, así como HTTPs (HTTP Seguro).

Realizaciones del recorrido lógico de comunicaciones, de aplicación y de realizaciones

La Figura 4 muestra una vista general de un recorrido lógico 220 de comunicaciones entre la aplicación 180 y la VM 186. Un agente delegado 222 en el hipervisor host 198 enlaza el cliente host 188 con la VM 186. Puede suponerse que la VM 186 y el cliente host 188 tienen los componentes de red necesarios (por ejemplo, pilas de protocolos) para comunicarse, pero son incapaces de comunicarse directamente. Por ejemplo, la red 190 puede ser incapaz de encaminar paquetes de red entre los mismos (por ejemplo, pueden ser inasequibles en la red 190). Sin embargo, en el cliente host 188, se puede dirigir un paquete 223 de red a una dirección de red de la capa de virtualización (una dirección del hipervisor host 198). Cuando se recibe el paquete 223, el agente delegado 222 determina que se pretende que el paquete 223 sea recibido por la VM 186 y hace que la capa de virtualización (hipervisor) pase el paquete a través de un canal privado o local 224 de comunicaciones a la VM 186.

En una realización, una correlación 226 de VM-host contiene información que indica qué VM residen en qué hipervisor host. El cliente host 188 puede utilizar un identificador conocido de la VM 186 (posiblemente conocido por la aplicación 180) para consultar la dirección de red del hipervisor host 198 en la correlación 226 de VM-host. Se puede añadir el identificador al paquete 223 para su uso mediante el agente delegado 22. El cliente host 188 envía el paquete 223 a la dirección consultada de red del hipervisor host 198, que la red 190 utiliza para encaminar 226 el paquete 223 al hipervisor host 198. Según se ha mencionado anteriormente, el agente delegado 222 utiliza el identificador de la VM 186 (por ejemplo, de una cabecera HTTP CONNECT) para provocar que la capa de virtualización pase el paquete 223 a la VM 186.

La Figura 5 muestra el cliente host 188 iniciando una conexión con una VM 186. El cliente host 188 tiene acceso a la correlación 226 de VM-host. El cliente host 188 lleva a cabo un proceso 250 para comunicarse con la VM 186. En la etapa 252, se recibe una solicitud 254 para comunicarse con la VM particular 186, quizás como parte de la lógica de aplicación 180, o es recibida posiblemente de una entidad externa. En la etapa 256, se utiliza un identificador de la VM 186 (por ejemplo, “VM1” en la Figura 5) para consultar el host en el que reside la VM 186; hipervisor host 186. La consulta puede devolver una dirección de red o un nombre del host de red del hipervisor host 198 (según se utiliza en la presente memoria, se da por sentado que “dirección de red” incluye tanto direcciones numéricas como nombres del host que pueden ser resueltas en direcciones numéricas). En la etapa 258, se forma el paquete 223, incluyendo la carga útil substantive (por ejemplo, un mensaje de aplicación-protocolo). En una realización en la que se utiliza HTTP, el paquete 223 formado en la etapa 258 es un paquete de HTTP y la dirección de red del hipervisor host está incluida en la cabecera HTTP. En la etapa 260, se transmite el paquete 223 a la red 190 utilizando la dirección de red del hipervisor (“dir1 de red” en la Figura 5, por ejemplo “128.1.2.3”).

En una realización, el proceso 250 puede llevarse a cabo completa o parcialmente por la aplicación 180. En otra realización, la aplicación 180 puede actuar como un delegado o servicio para otras aplicaciones que han de comunicarse con la VM 186. Esas aplicaciones pasan a la aplicación 180 un identificador de VM y un cuerpo de mensaje y la aplicación 180 construye un paquete para el cuerpo, añade el identificador de la VM y transmite el paquete al hipervisor host correspondiente. En otra realización más, en vez de mantener una tabla de consulta (correlación 226 de VM-host), los identificadores de VM pueden ser nombres del host globalmente exclusivos registrados con un servidor DNS (servicio de nombres de dominio) (posiblemente con alcance local o limitado para evitar conflictos) que se correlaciona con las direcciones de red de los hipervisores anfitriones que se corresponden con las VM. En ese caso, cuando una aplicación o cliente host desea comunicarse con una VM, consulta el identificador (por ejemplo, un nombre DNS “falso”) de la VM mediante el servidor DNS local para obtener la dirección correcta de red del hipervisor host.

La forma de los identificadores de VM no es importante siempre que el agente delegado 222 y los clientes anfitriones/aplicaciones compartan los mismos nombres. El sistema puede utilizar cualquier convención para dar nombre a las VM, por ejemplo un formato personalizado de URI (Identificador universal de recursos) tal como “host#:vm#”.

La Figura 6 muestra el hipervisor host 198 gestionando el paquete 223 procedente del cliente host 188. El agente delegado 222 opera junto con la capa de virtualización o el hipervisor 192 para llevar a cabo el proceso 280. En la etapa 282, el hipervisor host 198 recibe el paquete 223, que incluye el identificador de la VM (por ejemplo, “VM1”, “host1:VM1”, etc.) de la VM diana; VM 186. El agente delegado 222 extrae el identificador de la VM, y en la etapa 283 consulta el identificador de la VM en una tabla 284 de canales. La tabla 283 de canales correlaciona los canales 224, 224A de comunicaciones con respectivas VM 186, 186A. Cada canal 224, 224A de comunicaciones puede tener un par de puntos terminales de comunicaciones, incluyendo un punto terminal 286 del lado del hipervisor y un punto terminal 288 del lado de la VM (en una realización el punto terminal 286 del lado de la VM es una NIC virtual de la VM 186). Si la etapa 283 no descubre ningún canal de comunicaciones, se lleva a cabo una etapa 290 y se crea un nuevo canal. Entonces, se añade a la tabla 284 de canales una referencia al nuevo canal. Se debe hacer notar que una NIC virtual, o NIC de gestión, puede ser un adaptador virtual de red de bus conectado con un conmutador interno de red al que están conectados el host y las VM; teniendo las VM direcciones internas automáticas de IP (por ejemplo, en el intervalo 169). En una realización, se mantiene una ACL (lista de control de accesos) en asociación con el conmutador interno de red para evitar que cada una de las VM invitado se comuniquen entre sí sin permiso; se permite una comunicación de host a VM, pero se rechaza una comunicación entre VM a falta de un permiso explícito en la ACL.

Habiendo identificado el canal correcto 224 de comunicaciones para el paquete 223, en la etapa 292 el hipervisor 192 y/o el agente delegado 222 pasa el paquete 223 al canal 224 de comunicaciones. A su vez, la VM 186 lleva a cabo el proceso 294. En la etapa 296, el invitado 184 recibe el paquete 223. En la etapa 298, en función del paquete 223, el invitado 184 pasa el paquete 223 al agente invitado 182, que pasa a servir el contenido sustantivo del paquete 223 (por ejemplo, ejecuta la “instrucción foo”). Por ejemplo, el tipo de aplicación-protocolo del paquete 223 (por ejemplo, HTTP) podría ser correlacionado por el invitado con un número de puerto por el que escucha el agente invitado 182. Es decir, el agente invitado 182 puede escuchar por puertos específicos (por ejemplo, un puerto designado WS-Management 5986 para una gestión, un puerto BITS 8114 para datos, etc.). El agente delegado 222 (por ejemplo, delegado HTTP) escucha por los mismos puertos (5986, 8114) de las direcciones externas de IP (del hipervisor host 186). Entonces, el agente delegado 222 remite cualquier tráfico entrante a los puertos correspondientes en las VM invitadoes, permitiendo, de esta manera, la multiplexación de diversos tráficos de control y de datos en las VM invitadoes.

Con respecto a los canales de comunicaciones, en una realización, los canales de comunicaciones están basados en los mismos protocolos de red y/o de transporte utilizados para suministrar el paquete 223 al hipervisor host 198. De hecho, un canal de comunicaciones puede ser una conexión limitada de red privada entre el hipervisor host 192 y la VM 186. En otra realización, el agente delegado 222 puede buscar en el paquete 223 y cambiar la información de la cabecera o modificar de otra manera el paquete 223 antes de remitir el paquete 223 a la VM 186.

De hecho, desde el punto de vista de la aplicación 180 y del agente invitado 182, los dos pueden intercambiar comunicaciones a nivel de aplicación utilizando protocolos y direcciones normales de comunicaciones de red, en gran medida como podrían hacerlo cuando una VM es directamente accesible o asequible desde el cliente host 188. Con respecto a recibir paquetes, el agente delegado 222 funciona en gran medida como funcionan los delegados conocidos.

Según se ha mencionado anteriormente, las comunicaciones también pueden originarse desde el invitado 184 o el agente invitado 182 y ser pasadas a través del canal de comunicaciones y de la capa de virtualización al agente delegado 222. Por ejemplo, el agente invitado 182 puede estar configurado con una dirección de red del cliente host 188. A su vez, el agente delegado 222 transmite al cliente host 188 el paquete originado en el invitado.

En una realización, para proporcionar la visibilidad de las VM, los hipervisores anfitriones (anfitriones en los que se ejecutan las VM) pueden dar de alta automáticamente una VM cuando se crea una VM. Por ejemplo, un hipervisor host añade una nueva entrada en la tabla de correlación 226 de VM-host para una nueva VM, identificando el host y la nueva VM.

Conclusión

Las realizaciones y las características expuestas anteriormente pueden realizarse en forma de información almacenada en soportes volátiles o no volátiles legibles por un ordenador o dispositivo. Se considera que estos incluyen al menos soportes tales como de almacenamiento óptico (por ejemplo, un disco compacto de memoria de solo lectura (CD-ROM)), medios magnéticos, memoria flash de solo lectura (ROM) o cualquier medio actual o futuro de almacenamiento de información digital. La información almacenada puede estar en forma de instrucciones ejecutables por máquina (por ejemplo, código binario ejecutable compilado), código fuente, código de bytes o cualquier otra información que pueda ser utilizada para permitir o configurar dispositivos informáticos para llevar a cabo las diversas realizaciones expuestas anteriormente. También se considera que esto incluye al menos memoria volátil tal como memoria de acceso aleatorio (RAM) y/o memoria virtual que almacena información, tal como medios no volátiles que almacenan información que permite que se cargue y ejecute un programa o ejecutable. Las realizaciones y las características pueden llevarse a cabo en cualquier tipo de dispositivo informático, incluyendo dispositivos portátiles, estaciones de trabajo, servidores, dispositivos inalámbricos móviles, etcétera.

Claims (12)

REIVINDICACIONES

1. Un procedimiento para proporcionar una conectividad de red entre una máquina virtual, VM, diana que se ejecuta en un primer host y una aplicación que se ejecuta en un segundo host, comprendiendo el procedimiento:

recibir (282), mediante una red en el primer host, un paquete (223) dirigido a una dirección de red del primer host, comprendiendo el paquete una carga útil conforme a un protocolo a nivel de aplicación e información que identifica la VM diana;

formar (290) un canal de comunicaciones entre un hipervisor en el primer host que gestiona la VM diana y la VM diana;

en función de la información que identifica la VM diana en el paquete, pasando (292) el paquete a la VM diana a través del canal; y

suministrar (298) la carga útil a un agente que se ejecuta en la VM diana después de que la VM diana ha recibido el paquete a través del canal de comunicaciones.

2. Un procedimiento según la reivindicación 1, en el que se mantiene una lista de control de accesos y en el que se rechaza la comunicación de otra VM en el primer host con la VM diana a falta de un permiso explícito en la lista de control de accesos.

3. Un procedimiento según la reivindicación 1, en el que el paquete comprende un paquete de Protocolo de Internet, en el que el primer host tiene una primera dirección de Protocolo de Internet, IP, el segundo host tiene una segunda dirección de IP, y la VM diana tiene una tercera dirección de IP, comprendiendo el procedimiento, además, el envío del paquete del segundo host al primer host al dirigir el segundo host el paquete a la primera dirección de IP.

4. Un procedimiento según la reivindicación 1, en el que el canal de comunicaciones comprende un conmutador interno de red del hipervisor y una tarjeta virtual de interfaz de red proporcionada por el hipervisor y asignada a la VM diana.

5. Un procedimiento según la reivindicación 1, en el que el hipervisor y un agente delegado en el primer host cooperan para permitir que el segundo host se comunique con la VM diana utilizando un protocolo estándar de red.

6. Un procedimiento según la reivindicación 1, en el que el paquete se atiene a un protocolo y ha sido dirigido y enviado a la dirección de red del primer host utilizando un protocolo de red, determinando un agente delegado que la VM diana ha de recibir el paquete y, en respuesta, el hipervisor pasa el paquete a la VM diana a través del canal (224) de comunicaciones entre la VM diana y el hipervisor.

7. Un procedimiento según la reivindicación 6, que comprende, además, mantener, en el primer host, información del canal que indica qué VM se corresponden con qué VM gestionadas por el hipervisor.

8. Un procedimiento según la reivindicación 1, en el que el hipervisor gestiona la ejecución de máquinas virtuales, VM, en el primer host, comprendiendo el procedimiento:

habilitar una conectividad indirecta de red entre el segundo host y la VM diana mediante un agente delegado que se ejecuta en el primer host que provoca que el hipervisor pase el paquete a través del canal de comunicaciones a la VM diana.

9. Un procedimiento según la reivindicación 8, comprendiendo el procedimiento, además, mantener información de asociación que asocia los canales de comunicaciones entre el hipervisor y las VM, respectivamente, y cuando el agente delegado gestiona el paquete, el agente delegado utiliza la información de asociación para seleccionar el canal de comunicaciones.

10. Un procedimiento según la reivindicación 9, en el que el agente delegado comprende un protocolo de transferencia de hipertexto, HTTP.

11. Un procedimiento según la reivindicación 10, en el que el paquete comprende una cabecera HTTP que comprende el identificador que identifica la VM diana, y el agente delegado lee la cabecera HTTP, extrae el identificador y utiliza el identificador para seleccionar qué canal ha de recibir el paquete.

12. Un procedimiento según la reivindicación 8, en el que un sistema operativo invitado de la VM diana implementa un protocolo de transporte y un protocolo de red para permitir la conectividad al sistema operativo invitado mediante una dirección de red del invitado, comprendiendo el procedimiento, además, que el segundo host dirija el paquete a la dirección de red del primer host.