ES2719301T3 - Canal de gestión habilitado por el host - Google Patents
Canal de gestión habilitado por el host Download PDFInfo
- Publication number
- ES2719301T3 ES2719301T3 ES12804372T ES12804372T ES2719301T3 ES 2719301 T3 ES2719301 T3 ES 2719301T3 ES 12804372 T ES12804372 T ES 12804372T ES 12804372 T ES12804372 T ES 12804372T ES 2719301 T3 ES2719301 T3 ES 2719301T3
- Authority
- ES
- Spain
- Prior art keywords
- host
- target
- packet
- hypervisor
- network
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L65/00—Network arrangements, protocols or services for supporting real-time applications in data packet communication
- H04L65/1066—Session management
- H04L65/1069—Session establishment or de-establishment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/563—Data redirection of data network streams
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/56—Provisioning of proxy services
- H04L67/59—Providing operational support to end devices by off-loading in the network or by emulation, e.g. when they are unavailable
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45595—Network integration; Enabling network access in virtual machine instances
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/54—Store-and-forward switching systems
- H04L12/56—Packet switching systems
- H04L12/5601—Transfer mode dependent, e.g. ATM
- H04L2012/5603—Access techniques
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- Signal Processing (AREA)
- Computer Networks & Wireless Communication (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Physics & Mathematics (AREA)
- Business, Economics & Management (AREA)
- General Business, Economics & Management (AREA)
- Multimedia (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Computer And Data Communications (AREA)
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)
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.
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US13/169,024 US9191454B2 (en) | 2011-06-27 | 2011-06-27 | Host enabled management channel |
PCT/US2012/041043 WO2013002978A2 (en) | 2011-06-27 | 2012-06-06 | Host enabled management channel |
Publications (1)
Publication Number | Publication Date |
---|---|
ES2719301T3 true ES2719301T3 (es) | 2019-07-09 |
Family
ID=47363068
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
ES12804372T Active ES2719301T3 (es) | 2011-06-27 | 2012-06-06 | Canal de gestión habilitado por el host |
Country Status (8)
Country | Link |
---|---|
US (2) | US9191454B2 (es) |
EP (2) | EP2724512B1 (es) |
JP (1) | JP6077536B2 (es) |
KR (1) | KR101948951B1 (es) |
CN (1) | CN103621041B (es) |
ES (1) | ES2719301T3 (es) |
TW (1) | TWI544417B (es) |
WO (1) | WO2013002978A2 (es) |
Families Citing this family (44)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2005115205A1 (ja) * | 2004-05-26 | 2005-12-08 | Tomoda Selling & Sailing Co., Ltd. | 間接加熱ボイル装置、間接加熱冷却装置および濃縮装置 |
TWI451245B (zh) * | 2011-09-14 | 2014-09-01 | Inst Information Industry | 虛擬機器監控方法、系統及儲存其之電腦可讀取紀錄媒體 |
WO2013099414A1 (ja) * | 2011-12-26 | 2013-07-04 | インターナショナル・ビジネス・マシーンズ・コーポレーション | レジスタ・マッピング方法 |
WO2013097117A1 (zh) * | 2011-12-28 | 2013-07-04 | 华为技术有限公司 | 虚拟机全盘加密下预启动时的密钥传输方法和设备 |
US8825550B2 (en) * | 2012-08-23 | 2014-09-02 | Amazon Technologies, Inc. | Scaling a virtual machine instance |
US9135051B2 (en) * | 2012-11-02 | 2015-09-15 | Red Hat Israel, Ltd. | Redirecting guest-generated events to an event aggregator in a networked virtualization environment |
US9141416B2 (en) | 2013-03-15 | 2015-09-22 | Centurylink Intellectual Property Llc | Virtualization congestion control framework for modifying execution of applications on virtual machine based on mass congestion indicator in host computing system |
US9430259B2 (en) | 2013-03-15 | 2016-08-30 | Centurylink Intellectual Property Llc | Virtualization congestion control framework for modifying execution of applications on virtual machine based on mass congestion indicator in host computing system |
US10389577B2 (en) | 2013-08-14 | 2019-08-20 | Centurylink Intellectual Property Llc | Ethernet carrier group alarm (CGA) |
US9628433B2 (en) * | 2013-08-27 | 2017-04-18 | International Business Machines Corporation | Transmission of short message service (SMS) message and notifications in virtualized wireless mobile computing device based on the status of intended recipient |
US9619248B2 (en) * | 2013-08-30 | 2017-04-11 | Bluedata Software, Inc. | Configuration manager and method for configuring a host system for processing a processing job in a virtual data-processing environment |
US9832256B1 (en) * | 2013-09-20 | 2017-11-28 | Ca, Inc. | Assigning client virtual machines based on location |
US9065854B2 (en) * | 2013-10-28 | 2015-06-23 | Citrix Systems, Inc. | Systems and methods for managing a guest virtual machine executing within a virtualized environment |
US9864623B2 (en) * | 2013-11-21 | 2018-01-09 | Centurylink Intellectual Property Llc | Physical to virtual network transport function abstraction |
GB2521412A (en) * | 2013-12-18 | 2015-06-24 | Continuumbridge Ltd | An apparatus for network bridging |
KR101571810B1 (ko) * | 2013-12-30 | 2015-11-25 | 주식회사 시큐아이 | 복수의 가상 머신들을 포함하는 컴퓨팅 시스템 |
JP6591143B2 (ja) * | 2014-03-31 | 2019-10-16 | 株式会社東芝 | 通信装置、通信方法、通信システムおよびプログラム |
US10110710B2 (en) | 2014-04-03 | 2018-10-23 | Centurylink Intellectual Property Llc | System and method for implementing extension of customer LAN at provider network service point |
US9948493B2 (en) | 2014-04-03 | 2018-04-17 | Centurylink Intellectual Property Llc | Network functions virtualization interconnection gateway |
CN106134203A (zh) * | 2014-04-30 | 2016-11-16 | Lg电子株式会社 | 广播信号发送装置、广播信号接收装置、广播信号发送方法、和广播信号接收方法 |
US9762625B2 (en) * | 2014-05-28 | 2017-09-12 | Apple Inc. | Device and method for virtual private network connection establishment |
US10225327B2 (en) | 2014-08-13 | 2019-03-05 | Centurylink Intellectual Property Llc | Remoting application servers |
US9898318B2 (en) | 2014-08-15 | 2018-02-20 | Centurylink Intellectual Property Llc | Multi-line/multi-state virtualized OAM transponder |
US9697026B1 (en) | 2014-10-17 | 2017-07-04 | Trend Micro Inc. | High availability service virtual machine in virtualization environment |
US10481938B2 (en) | 2015-05-06 | 2019-11-19 | Centurylink Intellectual Property Llc | System and method for implementing network experience shifting |
US10169061B2 (en) | 2015-05-06 | 2019-01-01 | Ford Global Technologies, Llc | Scalable and flexible operating system platform |
US10673978B2 (en) | 2015-05-06 | 2020-06-02 | Centurylink Intellectual Property Llc | Method and system for implementing network experience shifting using shared objects |
US9882833B2 (en) | 2015-09-28 | 2018-01-30 | Centurylink Intellectual Property Llc | Intent-based services orchestration |
US10078528B2 (en) | 2015-10-06 | 2018-09-18 | Centurylink Intellectual Property Llc | Virtual machine-to-port peripheral device driver for implementing communications between virtual machines and client devices |
US10846117B1 (en) * | 2015-12-10 | 2020-11-24 | Fireeye, Inc. | Technique for establishing secure communication between host and guest processes of a virtualization architecture |
CN105681547B (zh) * | 2015-12-31 | 2019-07-19 | 努比亚技术有限公司 | 中间件实例管理装置和方法 |
US9930029B2 (en) * | 2016-02-25 | 2018-03-27 | Nutanix, Inc. | Hypervisor agnostic bidirectional secure channel for guest agent transport |
US10270692B1 (en) * | 2016-11-10 | 2019-04-23 | Juniper Networks, Inc. | Establishing a connection to multiple network devices using a single internet protocol (IP) address |
US10360410B2 (en) * | 2016-11-14 | 2019-07-23 | International Business Machines Corporation | Providing containers access to container daemon in multi-tenant environment |
US10810030B2 (en) * | 2016-12-06 | 2020-10-20 | Nutanix, Inc. | Identifying entities in a virtualization environment by converting heterogeneous string identifiers for interaction with a single API |
US10496439B1 (en) * | 2016-12-15 | 2019-12-03 | Space Sciences Corporation | Finite resource allocator with intrinsically subordinate operating system |
US10191762B2 (en) * | 2017-01-31 | 2019-01-29 | Vmware, Inc. | Transparent deployment of intermediary manager into guest operating system network traffic |
US10644948B1 (en) * | 2017-08-29 | 2020-05-05 | Juniper Networks, Inc. | Hypervisor detection of virtual machine and network interface compatibility |
KR102337182B1 (ko) * | 2017-09-29 | 2021-12-09 | 한국전력공사 | 기능 확장용 미들웨어 플랫폼이 탑재된 전자식 전력량계, 이를 이용한 전력량계 애플리케이션 관리 시스템 및 그 방법 |
US11044229B2 (en) * | 2017-12-22 | 2021-06-22 | International Business Machines Corporation | Dynamically opening ports for trusted application processes hosted in containers |
US10909010B2 (en) | 2018-04-10 | 2021-02-02 | Nutanix, Inc. | Efficient data restoration |
US11182187B2 (en) * | 2018-04-17 | 2021-11-23 | Red Hat Israel, Ltd. | Dynamic network connectivity verification in distributed virtual environments |
US11635970B2 (en) | 2020-04-17 | 2023-04-25 | Nutanix, Inc. | Integrated network boot operating system installation leveraging hyperconverged storage |
KR102327886B1 (ko) * | 2021-03-30 | 2021-11-18 | (주)지란지교시큐리티 | 가상 머신 운영 장치 및 방법 |
Family Cites Families (33)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7424710B1 (en) | 2002-12-18 | 2008-09-09 | Vmware, Inc. | TCP/IP offloading for virtual machines |
US7257811B2 (en) * | 2004-05-11 | 2007-08-14 | International Business Machines Corporation | System, method and program to migrate a virtual machine |
US7434003B2 (en) | 2005-11-15 | 2008-10-07 | Microsoft Corporation | Efficient operating system operation on a hypervisor |
US20070174429A1 (en) * | 2006-01-24 | 2007-07-26 | Citrix Systems, Inc. | Methods and servers for establishing a connection between a client system and a virtual machine hosting a requested computing environment |
WO2007087558A2 (en) | 2006-01-24 | 2007-08-02 | Citrix Systems, Inc. | Methods and systems for providing access to a computing environment |
JP4434168B2 (ja) * | 2006-03-30 | 2010-03-17 | 日本電気株式会社 | オンデマンドクライアントサービスシステム、その管理方法、及びプログラム |
US7546398B2 (en) * | 2006-08-01 | 2009-06-09 | International Business Machines Corporation | System and method for distributing virtual input/output operations across multiple logical partitions |
US7996835B2 (en) | 2006-10-10 | 2011-08-09 | International Business Machines Corporation | System, method and program for managing communication with multiple configurations for virtual machine |
US8079030B1 (en) * | 2007-03-13 | 2011-12-13 | Symantec Corporation | Detecting stealth network communications |
US7984449B2 (en) | 2007-08-15 | 2011-07-19 | International Business Machines Corporation | In-band communication with virtual machines via a hypervisor message bus |
US8156492B2 (en) | 2007-09-07 | 2012-04-10 | Oracle International Corporation | System and method to improve memory usage in virtual machines running as hypervisor guests |
US20090287571A1 (en) | 2008-03-26 | 2009-11-19 | Robb Fujioka | Hypervisor and virtual machine ware |
US8359593B2 (en) | 2008-04-21 | 2013-01-22 | Vmware, Inc. | Computer machine migration of file system images using a redo-log file |
US8195774B2 (en) * | 2008-05-23 | 2012-06-05 | Vmware, Inc. | Distributed virtual switch for virtualized computer systems |
US8135921B2 (en) * | 2008-06-06 | 2012-03-13 | International Business Machines Corporation | Automated paging device management in a shared memory partition data processing system |
CN101631110B (zh) * | 2008-07-15 | 2013-01-02 | 国际商业机器公司 | 基于相对位置动态确定连接建立机制的装置和方法 |
US9009329B2 (en) * | 2008-11-25 | 2015-04-14 | Microsoft Technology Licensing, Llc | Platform for enabling terminal services virtualization |
US9086913B2 (en) | 2008-12-31 | 2015-07-21 | Intel Corporation | Processor extensions for execution of secure embedded containers |
US8918488B2 (en) * | 2009-02-04 | 2014-12-23 | Citrix Systems, Inc. | Methods and systems for automated management of virtual resources in a cloud computing environment |
US8150971B2 (en) | 2009-05-31 | 2012-04-03 | Red Hat Israel, Ltd. | Mechanism for migration of client-side virtual machine system resources |
US8352941B1 (en) * | 2009-06-29 | 2013-01-08 | Emc Corporation | Scalable and secure high-level storage access for cloud computing platforms |
US8954957B2 (en) * | 2009-07-01 | 2015-02-10 | Riverbed Technology, Inc. | Network traffic processing according to network traffic rule criteria and transferring network traffic metadata in a network device that includes hosted virtual machines |
US8238324B2 (en) * | 2009-07-24 | 2012-08-07 | Broadcom Corporation | Method and system for network aware virtual machines |
CN101998629B (zh) * | 2009-08-28 | 2014-05-21 | 国际商业机器公司 | 搜索虚拟资源的位置的方法、装置和*** |
CN102549977B (zh) | 2009-09-24 | 2014-11-05 | 日本电气株式会社 | 虚拟服务器间通信识别***和虚拟服务器间通信识别方法 |
US8392497B2 (en) | 2009-11-25 | 2013-03-05 | Framehawk, LLC | Systems and algorithm for interfacing with a virtualized computing service over a network using a lightweight client |
US20110131330A1 (en) * | 2009-12-02 | 2011-06-02 | International Business Machines Corporation | Collocating desktop virtual machines to proximity of the user |
WO2011068091A1 (ja) * | 2009-12-04 | 2011-06-09 | 日本電気株式会社 | サーバ及びフロー制御プログラム |
US8468550B2 (en) * | 2010-06-18 | 2013-06-18 | At&T Intellectual Property I, L.P. | Mobile devices having plurality of virtual interfaces |
US20120054486A1 (en) * | 2010-08-31 | 2012-03-01 | MindTree Limited | Securing A Virtual Environment And Virtual Machines |
US9473518B2 (en) * | 2010-10-22 | 2016-10-18 | International Business Machines Corporation | Securing network communications with logical partitions |
US20120287931A1 (en) * | 2011-05-13 | 2012-11-15 | International Business Machines Corporation | Techniques for securing a virtualized computing environment using a physical network switch |
US20140006638A1 (en) * | 2012-06-29 | 2014-01-02 | Alan Kavanagh | Method and a network node, for use in a data center, for routing an ipv4 packet over an ipv6 network |
-
2011
- 2011-06-27 US US13/169,024 patent/US9191454B2/en active Active
-
2012
- 2012-05-01 TW TW101115467A patent/TWI544417B/zh not_active IP Right Cessation
- 2012-06-06 CN CN201280031632.3A patent/CN103621041B/zh active Active
- 2012-06-06 EP EP12804372.6A patent/EP2724512B1/en active Active
- 2012-06-06 JP JP2014518587A patent/JP6077536B2/ja active Active
- 2012-06-06 ES ES12804372T patent/ES2719301T3/es active Active
- 2012-06-06 KR KR1020137034642A patent/KR101948951B1/ko active IP Right Grant
- 2012-06-06 EP EP19151796.0A patent/EP3490222B1/en active Active
- 2012-06-06 WO PCT/US2012/041043 patent/WO2013002978A2/en unknown
-
2015
- 2015-10-30 US US14/928,540 patent/US9807129B2/en active Active
Also Published As
Publication number | Publication date |
---|---|
US9191454B2 (en) | 2015-11-17 |
US20160248818A1 (en) | 2016-08-25 |
EP2724512A4 (en) | 2015-08-05 |
JP2014524086A (ja) | 2014-09-18 |
US20120331461A1 (en) | 2012-12-27 |
WO2013002978A2 (en) | 2013-01-03 |
US9807129B2 (en) | 2017-10-31 |
KR20140037145A (ko) | 2014-03-26 |
CN103621041A (zh) | 2014-03-05 |
TWI544417B (zh) | 2016-08-01 |
TW201303734A (zh) | 2013-01-16 |
EP3490222B1 (en) | 2020-04-15 |
JP6077536B2 (ja) | 2017-02-08 |
KR101948951B1 (ko) | 2019-02-15 |
WO2013002978A3 (en) | 2013-04-11 |
EP2724512A2 (en) | 2014-04-30 |
EP3490222A1 (en) | 2019-05-29 |
CN103621041B (zh) | 2017-02-08 |
EP2724512B1 (en) | 2019-01-16 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
ES2719301T3 (es) | Canal de gestión habilitado por el host | |
US9769120B2 (en) | Method and system for VPN isolation using network namespaces | |
US20200379799A1 (en) | System and method for providing a dynamic cloud with subnet administration (sa) query caching | |
JP6771650B2 (ja) | クラウドコンピューティングシステムにおいて仮想マシンが物理サーバにアクセスするための方法、装置、およびシステム | |
US8725898B1 (en) | Scalable port address translations | |
WO2018112709A1 (zh) | 一种数据包处理方法、主机和*** | |
US9432304B2 (en) | System and method for supporting live migration of virtual machines based on an extended host channel adaptor (HCA) model | |
EP3343881A1 (en) | Packet processing method in cloud computing system, host, and system | |
US9928093B2 (en) | Methods and systems for establishing connections associated with virtual machine migrations | |
CA2991359A1 (en) | Packet processing method in cloud computing system, host, and system | |
EP2831730A1 (en) | System and method for providing a scalable signaling mechanism for virtual machine migration in a middleware machine environment | |
US10853126B2 (en) | Reprogramming network infrastructure in response to VM mobility | |
US20220086150A1 (en) | Location-aware service request handling | |
US10929169B2 (en) | Reprogramming network infrastructure in response to VM mobility | |
US11431678B2 (en) | Methods for enabling enhanced firewall rules via ARP-based annotations | |
JP2022507398A (ja) | プロバイダネットワークサービス拡張 |