MX2008014860A

MX2008014860A - Actualizacion de maquina virtual con parche o similares.

Info

Publication number: MX2008014860A
Application number: MX2008014860A
Authority: MX
Inventors: Robert M Fries; Eric J Winner; Gilad Golan
Original assignee: Microsoft Corp
Priority date: 2006-05-22
Filing date: 2007-03-15
Publication date: 2008-12-01
Also published as: EP2024849B1; HK1129748A1; AU2007254474A1; BRPI0712660B1; WO2007136448A1; CA2649888A1; KR101279696B1; TWI431531B; JP2009538469A; EP2024849A4; MY151935A; BRPI0712660A2; TW200809627A; US20070271561A1; EP2024849A1; US8291409B2; CA2649888C; CN101454765B; KR20090018909A; AU2007254474B2

Abstract

Cada una de de la pluralidad de máquinas virtuales (VMs) se almacena en una forma detenida en una biblioteca para recuperación de la biblioteca y reinicio en un huésped. Cada VM reiniciada incluye una pluralidad de construcciones de software, cada una de las cuales al menos es potencialmente no actual y requiere una actualización de software. Para actualizar una VM no actual, tal VM se recupera y reinicia en un huésped de mantenimiento, y cada construcción de software no actual se permite que se actualice obteniendo la actualización de software requerida de una fuente de actualización correspondiente como un parche. Alternativamente, la VM se monta a un dispositivo de cómputo, componentes constituyentes de la VM montadas se examinan para determinar si cada construcción de software de la misma es actual, y cada construcción de software no actual se actualiza al obtener la actualización de software requerida de la fuente de actualización correspondiente como un parche y aplicar el mismo a la VM montada.

Description

ACTUALIZACION DE MAQUINA VIRTUAL CON PARCHE O SIMILARES CAMPO TECNICO La presente invención se refiere a actualizar una máquina virtual o un componente de la misma con un parche para mantener la máquina virtual o componente. En particular, la presente invención se refiere a un sistema y método que actualiza tal máquina virtual en una biblioteca o similares y de esa forma fuera de línea. Más particularmente, la presente invención se refiere a tal sistema y método que despliega la máquina virtual desde la biblioteca y en un estado en línea para aplicar el parche, o que monta la máquina virtual en la forma de una unidad con archivos para aplicar el parche.

ANTECEDENTES DE LA INVENCION Como se debe apreciar, una máquina virtual ('VM') es una construcción de software o similares que opera en un dispositivo de cómputo o similares (es decir, un 'huésped') para el propósito de emular un sistema de hardware. Típicamente, aunque no necesariamente, la VM es una aplicación o similares, y puede emplearse en el huésped para iniciar una aplicación de usuario o similares mientras al mismo tiempo aisla tal aplicación del uso de tal dispositivo huésped o de otras aplicaciones en tal huésped. En una situación típica, el huésped puede acomodar una pluralidad de VMs desplegadas, cada VM que realiza alguna función predeterminada a manera de recursos disponibles del huésped. Notablemente, cada VM es para todas las intenciones y propósitos una máquina de cómputo, aunque en forma virtual, y de esa forma se representa a sí misma como el uso de la aplicación de la misma y para el mundo exterior. Típicamente, aunque no necesariamente, un huésped despliega cada VM de la misma en una división separada. Tal huésped puede incluir una capa de virtualizacion con un monitor VM o similares que actúa como una aplicación de supervisor o 'h ípervisor' , en donde la capa de virtualizacion supervisa y/o de otra forma maneja aspectos de supervisión de cada VM del huésped, y actúa como un de enlace posible entre cada VM y el mundo exterior. Un sello de una VM es la VM como una construcción virtual que puede detenerse y reiniciarse a voluntad, y también que la VM al detenerse puede almacenarse y recuperarse en la forma de un archivo o similares. En particular, la VM como se inició en un dispositivo de cómputo particular es una construcción de software individual que puede empaquetarse ordenadamente mientras la construcción de software incluye todos los datos que se relacionan con tal VM, que incluye datos operativos e información de estado que se relacionan con la VM. Como resultado, una VM en un primer huésped puede moverse o 'migrar' a un segundo huésped al detener la VM en el primer huésped, mover la VM detenida al segundo huésped, y reiniciar la VM movida en el segundo huésped, o similares. Más generalmente, una VM puede migrar desde una primera plataforma hacia una segunda plataforma en una forma similar, en donde las plataformas representan diferentes huéspedes, diferentes configuraciones del mismo huésped, y similares. En el último caso, como se debe apreciar, un dispositivo de cómputo puede tener una configuración diferente, por ejemplo, si se agrega memoria adicional, cambia un procesador, se proporciona un dispositivo de entrada adicional, se remueve un dispositivo de selección, etc. En una forma similar, una biblioteca de VMs puede mantenerse, en donde cada VM en la biblioteca es una VM detenida y almacenada que está disponible para recuperarse y reiniciarse con el comando apropiado. De esa forma, y como un ejemplo, un usuario o similares en necesidad de un escenario de procesamiento particular puede examinar la biblioteca para una VM apropiada aquí que dirige el escenario y al encontrar tal VM puede recuperar y reiniciar la VM. En una forma similar, un usuario o similar que desplegó una VM en cualquier punto apropiado detiene la VM y almacena la VM detenida a la biblioteca para recuperación posterior, en cuyo momento la VM almacenada al recuperarse desde la biblioteca puede reiniciarse para continuar procesamiento. Se debe entender que la VM incluye un sistema operativo, una o más aplicaciones de uso, y otras varias construcciones de software (es decir, 'construcciones de software', colectivamente), y que cada construcción de software de la VM puede de vez en cuando requerir una actualización en la forma de un parche o similares. Como puede apreciarse, tal actualización puede realizarse por cualquiera de varias razones, que incluyen mantener la construcción actual, proporcionar a la construcción funcionalidad adicional, dirigir problemas de seguridad con respecto a la construcción, o similares. Generalmente, la construcción puede incluir funcionalidad de actualización que periódicamente consulta una fuente de actualización por cualquiera de los nuevos parches, y si está disponible la funcionalidad de actualización obtiene los nuevos parches e instala los mismos, tal vez con la ayuda y/o aprobación de un usuario o similares. Notablemente, una VM que se detiene y almacena en una biblioteca o similares no puede realizar ningún procesamiento, y de esa forma la funcionalidad de actualización de una construcción de tal VM detenida y almacenada no es capaz de obtener e instalar parches como puede ser apropiado. Como puede apreciarse, la incapacidad de una construcción para actualizarse mientras la VM de la misma se detiene y almacena puede ser una inconveniencia menor si la naturaleza de la actualización es relativamente insignificante, o puede ser un problema mayor si la naturaleza de la actualización es relativamente importante. En el caso anterior, una actualización que puede ser relativamente insignificante por ejemplo puede ser una actualización que proporciona características de presentación adicionales. En el último caso, una actualización que puede ser relativamente importante por ejemplo puede ser una actualización que dirige un problema de seguridad. Especialmente con respecto a una actualización que es relativamente importante, pueden no ser es aceptable esperar a aplicar la actualización a una VM hasta que pase algún tiempo indeterminado cuando la VM pueda recuperarse de la biblioteca y reiniciarse en la forma normal. Por consiguiente, existe una necesidad de un sistema y método dirigido hacia permitir cualquiera de las actualizaciones y especialmente cualquiera de las actualizaciones importantes para aplicarse a una VM en una biblioteca.

BREVE DESCRIPCION DE LA INVENCION La necesidad antes mencionada se satisface por la presente invención en donde un sistema y métodos se proporcionan con respecto a una biblioteca de máquinas virtuales (VMs) en un dispositivo de cómputo. Cada VM se almacena en una forma detenida en tal biblioteca para recuperación de la biblioteca y reinicio en un dispositivo de cómputo de huésped. Cada VM en la biblioteca es una construcción de software que cuando se reinicia en un dispositivo de cómputo huésped emula un sistema de hardware. Cada VM reiniciada incluye una pluralidad de construcciones de software. Cada construcción de software de cada VM en la biblioteca es al menos potencialmente no actual y requiere una actualización de software. En el método, para cada VM en la biblioteca, se determina periódicamente si cada construcción de software de la VM es actual. Si cualquier construcción de software de la VM no es actual, la VM se marca en la biblioteca como siendo no actual. En algún punto, se recibe una selección de una VM desde la biblioteca para recuperarse y reiniciarse en un dispositivo de cómputo huésped. Si la VM se marca en la biblioteca como siendo no actual, la VM se actualiza en un dispositivo de cómputo huésped de mantenimiento que no tiene acceso a ningún dispositivo de cómputo huésped, después de lo cual la VM actualizada se reinicia en el dispositivo de cómputo huésped. Para actualizar la VM, tal VM se recupera desde la biblioteca y se reinicia en el dispositivo de cómputo huésped de mantenimiento, y cada construcción de software no actual de la VM reiniciada se permite que se actualice en el dispositivo de cómputo de huésped de mantenimiento al obtener la actualización de software requerida de una fuente de actualización correspondiente como al menos un parche. Alternativamente, la VM se monta a un dispositivo de cómputo, componentes constituyentes de la VM montada se examinan para determinar si cada construcción de software de la VM es actual, y cada construcción de software no actual se actualiza al obtener la actualización de software requerida de la fuente de actualización correspondiente tal como al menos un parche y aplicar cada parche a la VM montada.

BREVE DESCRIPCION DE LOS DIBUJOS La Breve Descripción anterior, asi como la siguiente descripción detallada de las modalidades de la presente invención, se entenderá mejor cuando se leen en conjunto con los dibujos anexos. Para el propósito de ilustrar la invención, se muestran en los dibujos modalidades que actualmente se prefieren. Sin embargo, como se debe entender, la invención no se limita a las distribuciones e instrumentos precisos mostrados. En los dibujos: la Figura 1 es un diagrama de bloques que representa un sistema de computadora de propósito general en donde los aspectos de la presente invención y/o porciones de la misma pueden incorporarse; la Figura 2 es un diagrama de bloques que muestra un sistema con una biblioteca de máquinas virtuales (VMs), cada una de las cuales puede reiniciarse en un huésped de mantenimiento o montarse a un dispositivo de cómputo para actualizarse de acuerdo con modalidades de la presente invención; y las Figuras de 3-5 son diagramas de flujo que muestran pasos clave realizados en conexión con el sistema de la Figura 2 de acuerdo con modalidades de la presente invención.

DESCRIPCION DETALLADA DE LA iNVENCION Ambiente de Computadora La Figura 1 y la siguiente discusión pretenden proporcionar una breve descripción general de un ambiente de cómputo adecuado en donde la presente invención y/o porciones de la misma pueden implementarse. Aunque no se requiere, la invención se describe en el contexto general de instrucciones ejecutables por computadora, tal como módulos de programa, que se ejecutan por una computadora, tal como una estación de trabajo de cliente o un servidor. Generalmente, los módulos de programa incluyen rutinas, programas, objetos, componentes, estructuras de datos y similares que realizan tareas particulares o ¡mplementan tipos de datos abstractos particulares. Además, se debe apreciar que la invención y/o porciones de la misma pueden practicarse con otras configuraciones de sistema de computadora, que incluyen dispositivos portátiles, sistemas de multiprocesador, electrónica a base de microprocesador de consumidor programable, PCs de red, minicomputadoras, macrocomputadoras y similares. La invención también puede practicarse en ambientes de cómputo distribuido en donde las tareas se realizan por dispositivos de procesamiento remoto que se enlazan a través de una red de comunicaciones. En un ambiente de cómputo distribuido, los módulos de programa pueden localizarse tanto en dispositivos de almacenamiento de memoria local y remota. Como se muestra en la Figura 1, un sistema de cómputo de propósito general ilustrativo incluye una computadora personal convencional 120 ó similares, que incluyen la unidad de procesamiento 121, una memoria de sistema 122, y un conductor común de sistema 123 que acopla varios componentes de sistema que incluyen la memoria de sistema a la unidad de procesamiento 121. El conductor común de sistema 123 puede ser cualquiera de varios tipos de estructuras de conductor común que incluyen un conductor común de memoria o controlador de memoria, un conductor común periférico, y un conductor común local que utiliza cualquiera de una variedad de arquitecturas de conductor común. La memoria de sistema incluye memoria de sólo lectura (ROM) 124 y memoria de acceso aleatorio (RAM) 125. Un sistema de entrada/salida básico 126 (BIOS), que contiene las rutinas básicas que ayudan a transferir información entre elementos dentro de la computadora personal 120, tal como durante el arranque, se almacena en ROM 124. La computadora personal 120 además puede incluir una unidad de disco duro 127 para leer de y escribir a un disco duro (no mostrado), una unidad de disco magnético 128 para leer de o escribir a un disco magnético removible 129, y una unidad de disco óptico 130 para leer de o escribir a un disco óptico removible 131 tal como un CD-ROM u otro medio óptico. La unidad de disco duro 127, unidad de disco magnético 128, y unidad de disco óptico 130 se conectan al conductor común de sistema ciento 123 por una interfase de unidad de disco duro 132, una interfase de unidad de disco magnético 133, y una interfase de unidad óptica 134, respectivamente. Las unidades y sus medios legibles por computadora asociados proporcionan almacenamiento no volátil de instrucciones legibles por computadora, estructuras de datos, módulos de programa y otros datos para la computadora personal 120. Aunque el ambiente ilustrativo aquí descrito emplea un disco duro, un disco magnético removible 129, y un disco óptico removible 131, se debe apreciar que otros tipos de medios legibles por computadora pueden almacenar datos que son accesibles por una computadora también pueden utilizarse en el ambiente operativo ilustrativo. Tales otros tipos de medios incluyen un cassette magnético, una tarjeta de memoria flash, un disco de video digital, un cartucho de Bernoulli, una memoria de acceso aleatorio (RAM), una memoria de sólo lectura (ROM), y similares. Un número de módulos de programa puede utilizarse en el disco duro, disco magnético 129, disco óptico 131, ROM 124 ó RAM 125, que incluyen un sistema operativo 135, uno o más programas de aplicación 136, otros módulos de programa 137 y datos de programa 138. Un usuario puede ingresar comandos e información en la computadora personal 120 a través de dispositivos de entrada tal como un teclado 140 y dispositivo de señalamiento 142. Otros dispositivos de entrada (no mostrados) pueden incluir un micrófono, palanca de mandos, almohadilla de juegos, antena parabólica, escáner, o similares. Estos y otros dispositivos de entrada frecuentemente se conectan a la unidad de procesamiento 121 a través de una interfase de puerto en serie 146 que se acopla al conductor común de sistema, pero puede conectarse por otras interfases, tal como un puerto paralelo, puerto de juego, o conductor común en serie universal (USB). Un monitor 147 u otro tipo de dispositivo de presentación también se conecta al conductor común de sistema 123 a través de una interfase, tal como un adaptador de video 148. Además del monitor 147, una computadora personal típicamente incluye otros dispositivos de salida periféricos (no mostrados), tal como bocinas e impresoras. El sistema ilustrativo de la Figura 1 también incluye un adaptador huésped 155. Un conductor común de Interfase de Sistema de computadora pequeña (SCSI) 156, y un dispositivo de almacenamiento externo 162 conectado al conductor común de SCSI 156. La computadora personal 120 puede operar en un ambiente en red que utiliza conexiones lógicas a una o más computadoras remotas, tal como una computadora remota 149. La computadora remota 149 puede ser otra computadora personal, un servidor, un enrutador, una PC de red, un dispositivo par u otro nodo de red común, y típicamente incluye muchos o todos los elementos descritos anteriormente relativos a la computadora personal 120, aunque solo se ha ilustrado un dispositivo de almacenamiento de memoria 150 en la Figura 1. Las conexiones lógicas ilustradas en la Figura 1 incluyen una red de área local (LAN) 151 y una red de área ancha (WAN) 152. Tales ambientes en red comúnmente están ubicados en oficinas, redes de computadora extendidas en empresa, intranets, e Internet. Cuándo se utiliza en un ambiente en red de LAN, la computadora personal 120 se conecta a la LAN 151 a través de una interfase de red o adaptador 153. Cuándo se utiliza en un ambiente en red WAN, la computadora personal 120 típicamente incluye un módem 154 u otros medios para establecer comunicaciones en la red de área ancha 152, tal como Internet. El módem 154, que puede ser interno o externo, se conecta al conductor común de sistema 123 a través de la interfase de puerto en serie 146. En un ambiente en red, los módulos de programa ilustrados relativos a la computadora personal 120, o porciones de la misma, pueden almacenarse en el dispositivo de almacenamiento de memoria remota. Se apreciará que las conexiones en red mostradas son ilustrativas y pueden utilizarse otros medios para establecer un enlace de comunicaciones entre las computadoras.

Huésped y Biblioteca de Máquina Virtual Cambiando ahora a la Figura 2, se observa que la presente invención puede tener aplicabilidad particular en el contexto de una biblioteca 10 de máquinas virtuales (VMs) 12, cada una de las cuales se almacena en una forma detenida y muy probablemente cerrada en tal biblioteca 10 y puede recuperarse de la biblioteca 10 y reiniciarse en un huésped 14 en una forma apropiada. Se debe notar aquí que la biblioteca 10, VMs 12, y huésped 14 puede ser cualquier biblioteca apropiada, VMs, y el huésped sin apartarse del espíritu y alcance de la presente invención. Tal biblioteca, VMs, y huésped son conocidos o deben ser evidentes para el público relevante y por lo tanto no necesitan mencionarse aquí en detalle más allá de lo que ya se proporcionó. Como se mencionó anteriormente, cada VM 12 en la biblioteca 10 es una construcción de software o similares que cuando se reinicia en un huésped 14 emula un sistema de hardware. De esa forma, la VM 12 puede emplear los recursos del huésped 14 para iniciar una aplicación de uso o similares mientras al mismo tiempo aisla tal aplicación de uso de tal huésped 14 y otras aplicaciones en tal huésped 14. Como se muestra, el huésped 14 puede acomodar una pluralidad de VMs desplegadas 12, en donde cada VM independientemente realiza alguna función predeterminada. Por ejemplo, al menos algunas VMs 12 desplegadas en el huésped 14 pueden actuar como servidores de datos, al menos algunas de tales VMs 12 pueden actuar como servidores de red con respecto una red 16 acoplada al huésped 14, al menos algunas de tales VMs 12 pueden actuar como servidores de correo, y al menos algunas de tales VMs 12 pueden realizar funciones de nivel bajo que incluyen funciones de mantenimiento, recolección de datos, monitoreo de hardware, corrección de error, manejo de archivo, y similares. Notablemente, cada VM 12 es para todas las intenciones y propósitos una máquina de cómputo, aunque en forma virtual. El huésped 14 por si mismo puede ser un dispositivo de cómputo apropiado tal como una computadora de escritorio, una computadora portátil, un dispositivo móvil, un asistente de datos, una macrocomputadora, o cualquier otro tipo de dispositivo de cómputo con la funcionalidad y capacidad necesaria para alojar una o más de las VMs 12. Generalmente que la VM puede requerir memoria significativa, operaciones de l/O, espacio de almacenamiento, y capacidad de procesador del huésped 14, sin embargo, y también tener en mente que el huésped 14 puede esperarse que acomode 2, 5, 10, 20 ó más de las VMs 12 en cualquier momento, el huésped 14 debe tener energía significativa y recursos para ser capaces de hecho de acomodar tales VMs 12. La biblioteca 10 puede enviar cualquier clase de biblioteca en cualquier clase de dispositivo de cómputo sin apartarse del espíritu y alcance de la presente invención. Por ejemplo, la biblioteca 10 puede recibir en un servidor de capacidad suficiente para sostener todas las VMs 12 de tal biblioteca 10, o simplemente puede recibir en una unidad de disco apropiado de tal capacidad suficiente. En el último caso, la unidad de disco incluso puede ser parte del huésped 14. Se debe notar, aunque, en el caso en donde existen múltiples huéspedes disponibles 14, tal biblioteca 10 probablemente está físicamente separada de pero comunicativamente acoplada a tales huéspedes 14. Concebiblemente, la biblioteca 10 por si misma puede recibir en una máquina virtual. Como se notó anteriormente, cada VM 12 como una construcción virtual puede detenerse y reiniciarse a voluntad, y al detenerse puede almacenarse en la biblioteca 10 y recuperarse de la misma en la forma de un archivo o similares. En particular, cada VM 12 es una construcción de software singular que puede empaquetarse ordenadamente mientras la construcción de software incluye todos los datos que se relacionan con tal VM 12, que incluye datos operativos e información de estado que se relaciona con la VM 12. De esa forma, una VM 12 en un primer huésped 14 puede moverse o 'migra' entre huéspedes 14 simplemente al detener la VM 12 en un primer huésped 14, mover la VM detenida 12 a un segundo huésped 14, y reiniciar la VM movida 12 en el segundo huésped 14. Típicamente, aunque no necesariamente, el sistema de la Figura 2 incluye un controlador VM 18 que opera en un dispositivo de cómputo apropiado o similares. Principalmente, y como se puede apreciar, tal controlador VM 18 opera para recuperar una VM almacenada 12 de la biblioteca 10 y desplegar la VM recuperada 12 al reiniciar la misma en un huésped particular 14, y también detener la VM desplegada 12 y almacenar la VM detenida 12 en la biblioteca 10, todo en la dirección apropiada de un usuario o similares. De esa forma, un usuario o similares en la necesidad de un escenario de procesamiento particular puede examinar la biblioteca 10 a manera del controlador VM 18 para una VM 12 apropiada que dirige el escenario y al encontrar tal VM 12 el usuario puede emplear el controlador VM 18 para recuperar y reiniciar la VM 12. En una forma similar, un usuario o similares que desplegó una VM en cualquier punto apropiado detiene la VM y almacena la VM detenida a la biblioteca para recuperación posterior, en cuyo momento la VM almacenada al recuperarse de la biblioteca puede reiniciarse para continuar procesamiento. Aquí se debe notar que el controlador de VM 18 puede ser cualquier controlador de VM apropiado sin apartarse del espíritu y alcance de la presente invención. Tal controlador VM 18 se conoce o debe ser evidente para el público relevante y por lo tanto no necesita mencionarse aquí en cualquier detalle más allá de aquella que se proporcionó.

Actualización con Parches Como se notó anteriormente, cada VM 12 en la biblioteca 10 por sí misma es una construcción de software en un sentido físico, pero en un sentido virtual la VM 12 por si misma incluye una pluralidad de construcciones de software que incluyen un sistema operativo con un registro o similares, una o más aplicaciones de uso, varios controladores de dispositivo y bibliotecas de dispositivo, y similares (es decir, 'construcciones de software', colectivamente). Notablemente, cada construcción de software de cualquier VM 12 puede ser de vez en cuando para requerir una actualización de software en la forma de un parche o similares. Tal actualización de software en la forma de un parche 20 ó similares se conoce o debe ser evidente para el público relevante, y por lo tanto no necesita mencionarse aquí en ningún detalle. Como se puede apreciar, tal actualización puede realizarse por cualquiera de varias razones, que incluyen mantener el software de construcción actual, para proporcionar la construcción con funcionalidad adicional, para dirigir problemas de seguridad con respecto a la construcción, o similares. Por consiguiente, la presente invención puede operar sin considerar ninguna actualización de software particular o parche 20 (denominado aquí, 'parche 20') o tipo del mismo. Generalmente, un parche 20 puede aplicarse a una construcción de software para que una VM 12 en al menos una forma parcialmente automatizada. Como tal, la construcción puede incluir actualizar funcionalidad que periódicamente consulta una o más fuentes de actualización 22 para cualquiera de los nuevos parches 20, y si está disponible la funcionalidad de actualización obtiene cada nuevo parche 20 de la fuente de actualización 22 e instala algunos, tal vez con la ayuda y/o aprobación de un usuario o similares. La funcionalidad de actualización en conexión con una construcción o similares se conoce o debe ser evidente para el público relevante, y por lo tanto no necesita mencionarse aquí en ningún detalle. Por consiguiente, la presente invención puede operar sin considerar ninguna funcionalidad de actualización particular. Se debe notar, aunque, para la funcionalidad de actualización de cualquier construcción particular de una VM 12 para operar, la VM 12 por si misma puede desplegarse y operar. Puesto de otra forma, una VM que se detiene y almacena en la biblioteca o similares no puede realizar ningún procesamiento, y de esa forma la funcionalidad de actualización es la construcción de tal VM detenida y almacenada no es capaz de obtener e instalar un parche 20 de la fuente de actualización 22. Entonces, para resumir, una construcción de software de una VM 12 que es residente en la biblioteca 10 no puede actualizarse. Como una actualización, la construcción de software en efecto debe esperar para actualizarse hasta que la VM 12 se recupera de la biblioteca 10 y se reinicia en un huésped 14. Se debe notar, aunque, puede ser muy bueno el caso que una actualización significativa tal con una actualización de seguridad se emita con respecto a una construcción particular de una VM 12 almacenada en la biblioteca 10. En tal situación, la VM 12 no se protege de una amenaza de seguridad que la actualización de seguridad pretende proteger, y de esa forma no debe desplegarse a ningún huésped 14 con la construcción en tal estado no protegido. En particular, y especialmente si el huésped 14 tiene acceso a cualquier red tal como la red 16, que despliega tal VM no protegida 12 puede permitir a cualquier huésped que ocurran situaciones de seguridad serias, que incluyen una ruptura de seguridad de la red 16, el huésped 14, otros huéspedes 14 en la red 16, y similares. De esa forma, e incluso haciendo referencia a la Figura 2, y en una modalidad de la presente invención, el controlador de VM 18 despliega la VM 12 a un huésped de mantenimiento 14 M, en donde el huésped de mantenimiento 14m tiene acceso a la fuente de actualización 22 a manera de un acoplamiento comunicativo apropiado, pero no tiene acceso a ningún huésped 14 a manera de la red 16 ó de otra forma. En particular, y haciendo referencia ahora a la Figura 3, el controlador VM 18 puede operar basándose en un programador 24 (Figura 2) para desplegar periódicamente cada una o más VMs 12 al huésped de mantenimiento 14m para actualización (paso 301). Como puede apreciarse ahora, en el huésped de mantenimiento 14m, una o más de las construcciones de software de cada VM desplegada 12 se actualizan con parches apropiadamente obtenidos 20 (paso 305), después de lo cual la VM actualizada 12 se detiene y almacena en la biblioteca 10 en la forma actualizada para esperar al siguiente despliegue en un huésped 14 (paso 307). Las construcciones de software de la VM desplegada 12 pueden actualizarse basándose en procedimientos activados por tales construcciones de software (paso 303a), o pueden actualizarse basándose en procedimientos activados por el controlador de VM 18 (paso 303b). En el último caso, el controlador de VM 18 puede emplear interfases conocidas apropiadas para efectuar tal activación.

Se debe notar aquí que el programador 24 puede ser cualquier programador apropiado, tal como por ejemplo un programador de tarea que es parte del controlador de VM 18, y puede programar cada VM 12 para actualización basándose en cualquier criterio apropiado sin apartarse del espíritu y alcance de la presente invención. Por ejemplo, el programador 24 puede operar para causar que el controlador de VM 18 despliegue de cada VM 12 al huésped de mantenimiento 14m una vez cada semana, una vez cada dos semanas, y similares. Tal programador y tal programación se conoce o debe ser evidente para el público relevante por lo tanto no necesita mencionarse aquí en ningún detalle. También se debe notar que el huésped de mantenimiento 14m puede ser cualquier huésped apropiado sin apartarse del espíritu y alcance de la presente invención, sometido al requerimiento que el huésped de mantenimiento aisla o de otra forma pone en cuarentena cada VM desplegada 12 en el de otros huéspedes 14 y sólo permite acceso a la fuente de actualización 22. Como se puede apreciar, el controlador de VM 18 que opera en la forma mostrada en la Figura 3 basándose en el programador 24 de la Figura 2 de alguna forma es ineficiente en cuanto a que cada VM 12 se despliega en el huésped de mantenimiento 14m sin considerar si las actualizaciones se requieren para la VM 12. Por consiguiente, y en una modalidad de la presente invención, y cambiando ahora la Figura 4, en lugar de desplegar inicialmente cada VM programada 12 al huésped de mantenimiento 14m, el controlador de VM 18 a su vez montan la VM 12 a un dispositivo de cómputo para que el huésped de mantenimiento 14m, la biblioteca 10 o similares para los componentes constituyentes de la VM 12 puedan examinarse (paso 401). El montar tal VM 12 para examinar algunos se conoce o debe ser evidente para el público relevante y por lo tanto no necesita mencionarse aquí en ningún detalle. Por consiguiente, cualquier forma particular de montaje puede realizarse sin apartarse del espíritu y alcance de la presente invención. Por ejemplo, tal VM 12 puede montarse para que los componentes constituyentes de la misma puedan examinarse en la forma de una unidad de disco o similares que tienen una pluralidad de archivos o similares. Al montarse, después, el controlador de VM 18 puede examinar varias partes de la VM 12 para determinar si varias construcciones de la VM 12 son actuales (paso 403). En particular, y como se puede apreciar, tal determinación puede hacerse por el controlador de VM 18 al revisar información de la VM montada 12 tal como versiones de archivo, información de registro, y otros datos que típicamente se emplean para determinar si se actualiza con uno o más parches 20 se requiere. Al presumir que uno o más parches 20 de hecho se requieren, el controlador de VM 18 entonces puede efectuar la obtención de cada parche 20 de una fuente de actualización apropiada 22 (paso 405) y aplicar el mismo a la VM 12. Notablemente, tales parches 20 pueden aplicarse a la VM 12 como montados (paso 407a), o si es necesario a la VM 12 como desplegados en el huésped de mantenimiento 14m (paso 407b). En el caso anterior como en el paso 407a, el controlador VM 18 debe aplicar cada parche 20 por sustitución de archivo en la VM montada 12, modificación de archivo, y similares. Cualquiera de las modificaciones de registro necesarias pueden realizarse al localizar el archivo de colmena de registro en la VM 12 montada y después cargar la colmena de registro localizada en el huésped de mantenimiento 14m, biblioteca 10, ó similares, que modifican la colmena cargada, y guardar la colmena modificada como un reemplazo para la colmena localizada correspondiente. En el último caso, en el paso 407b, el controlador de VM 18 primero debe desmontar la VM 12 del huésped de mantenimiento 14m o similares y entonces desplegar los mismos en tal huésped de mantenimiento 14m. Finalmente, después que se actualizó la VM 12 con todos los parches requeridos 20, el controlador VM 18 entonces puede mover la VM actualizada 12 de regreso a la biblioteca 10, ya sea al desmontar la VM 12 del huésped de mantenimiento 14m o similares y almacenar la VM desmontada 12 en la biblioteca 10 (paso 409), o al detener la VM desplegada 12 y almacenar la VM detenida 12 en la biblioteca 10 (paso 409b). Como se puede apreciar, el controlador de VM 18 que opera en la forma mostrada en la Figura 4 a veces puede ser ineficiente ya que cada VM 12 se actualiza con respecto a si la VM 12 va a emplearse por el usuario o similares. Es decir, cada VM 12 se actualiza incluso si la VM 12 raramente es si alguna vez se despliega. Por consiguiente, y en una modalidad de la presente invención, y cambiando ahora a la Figura 5, en lugar de realmente actualizar cada VM no actual 12, el controlador VM a su vez marca la VM 12 como no actual, y la VM 12 de hecho se actualiza sólo previo a realmente desplegarse. En particular, y como anteriormente, el controlador de VM 18 determina si cada VM 12 programada es actual (paso 501), por ejemplo al montar la VM 12 para que los componentes constituyentes de la VM 12 puedan examinarse, como en el paso 401. Aquí, aunque, cada VM no actual 12 se marca como tal en forma apropiada (paso 503), por ejemplo el incluir una notación apropiada con la VM 12 en la biblioteca 10. De esa forma, cuando un usuario selecciona cada VM 12 de la biblioteca 10 para desplegarse (paso 505), el controlador de VM 18 primero revisa si la VM seleccionada 12 se marca como no actual (paso 507). Si no es actual, la VM 12 primero se despliega o monta al huésped de mantenimiento 14m y actualiza como en los pasos 301 et seq. ó 401 et seq. (Paso 509), después de lo cual la VM no actual 12 se despliega a un huésped 14 para uso por el usuario que selecciona (paso 511).

Conclusión La programación necesaria para efectuar los procedimientos realizados en conexión con la presente invención es relativamente directa y debe ser evidente para el público de programación relevante. Por consiguiente, tal programación no se anexa a esto. Cualquier programación particular, entonces, puede emplearse para efectuar la presente invención sin apartarse del espíritu y alcance de la misma. En la descripción anterior, se puede observar que la presente invención comprende un sistema y método nuevos y útiles para aplicar una actualización a una VM 12 que se almacena en una biblioteca 10. Se debe apreciar que pueden hacerse cambios a las modalidades descritas anteriormente sin apartarse de los conceptos inventivos de la misma. Por lo tanto, se debe entender, que esta invención no se limita a las modalidades particulares descritas, pero pretende cubrir modificaciones dentro del espíritu y alcance de la presente invención como se define por las reivindicaciones anexas.

Claims

REIVINDICACIONES

1 - Una método con respecto a una biblioteca de máquinas virtuales (VMs) en un dispositivo de cómputo, cada VM almacenada en una forma detenida en tal biblioteca para recuperación de la biblioteca y reinicio en un dispositivo de cómputo huésped, cada VM en la biblioteca siendo una construcción de software que cuando se reinicia en un dispositivo de cómputo huésped emula un sistema de huésped, cada VM reiniciada incluye una pluralidad de construcciones de software, al menos una construcción de software de cada VM en la biblioteca siendo no actual y requiriendo una actualización de software, el método comprende, para cada VM en la biblioteca: recuperar la VM de la biblioteca en una base periódica y reiniciar la VM recuperada en un dispositivo de cómputo huésped de mantenimiento que tiene acceso al menos a una fuente de actualización pero que no tiene acceso a ningún dispositivo de cómputo huésped; permitir que cada construcción de software no actual de la VM reiniciada se actualice en el dispositivo de cómputo huésped de mantenimiento al obtener la actualización de software requerida de una fuente de actualización correspondiente como al menos un parche; y detener la VM actualizada y almacenar la VM detenida en la biblioteca para esperar recuperación y reinicio en el dispositivo de cómputo huésped. 2.- El método de acuerdo con la reivindicación 1, que comprende activar externamente cada construcción de software no actual de la VM reiniciada para actualizarse. 3.- El método de acuerdo con la reivindicación 1, que comprende cada construcción de software no actual de la VM reiniciada que internamente se activa a sí misma para actualizarse. 4. - El método de acuerdo con la reivindicación 1, en donde un controlador de VM opera para recuperar una VM almacenada de la biblioteca y reiniciar la VM recuperada en el dispositivo de cómputo huésped de mantenimiento, y también para detener la VM reiniciada y almacenar la VM detenida en la biblioteca, el método siendo realizado por el controlador de VM. 5. - El método de acuerdo con la reivindicación 4, que comprende el controlador de VM que opera basándose en un programador para desplegar periódicamente cada VM de la biblioteca al dispositivo de cómputo huésped de mantenimiento para actualización . 6. - El método de acuerdo con la reivindicación 1, que comprende operar basándose en un programador para desplegar periódicamente cada VM de la biblioteca al dispositivo de cómputo huésped de mantenimiento para actualización. 7. - Un método con respecto a una biblioteca de máquinas virtuales (VMs) en un dispositivo de cómputo, cada VM almacenada en una forma detenida en tal biblioteca para recuperación de la biblioteca y reiniciar en un dispositivo de cómputo huésped, cada VM en la biblioteca siendo una construcción de software que cuando se reinicia en un dispositivo de cómputo huésped emula un sistema de hardware, cada VM reiniciada incluye una pluralidad de construcciones de software, al menos una construcción de software de cada VM en la biblioteca siendo no actual y que requiere una actualización de software, el método comprende, para cada VM en la biblioteca: recuperar la VM de la biblioteca en una base periódica y montar la VM recuperada a un dispositivo de cómputo que no tiene acceso a ningún dispositivo de cómputo huésped; examinar componentes constituyentes de la VM montada para determinar si cada construcción de software de la VM es actual, y para cada construcción de software no actual actualizar la misma en el dispositivo de cómputo huésped de mantenimiento al obtener la actualización de software requerida de una fuente de actualización correspondiente como al menos un parche y aplicar cada parche a la VM montada; y almacenar la VM actualizada en la biblioteca para esperar recuperación y reinicio en el dispositivo de cómputo huésped. 8.- El método de acuerdo con la reivindicación 7, que comprende aplicar cada parche a la construcción de software no actual como montada al dispositivo de cómputo, el método también comprende almacenar la VM actualizada en la biblioteca después de desmontar la misma del dispositivo de cómputo huésped de mantenimiento. 9. - El método de acuerdo con la reivindicación 7, que comprende aplicar cada parche a la construcción de software no actual como reiniciado en el dispositivo de cómputo huésped de mantenimiento, y que incluye desmontar la VM del dispositivo de cómputo huésped de mantenimiento y entonces reiniciar la VM en tal dispositivo de cómputo huésped de mantenimiento, el método también comprende almacenar la VM actualizada en la biblioteca después de detener la misma en el dispositivo de cómputo huésped de mantenimiento. 10. - El método de acuerdo con la reivindicación 7, que comprende la VM recuperada al dispositivo de cómputo para que los componentes constituyentes de la VM montada puedan examinarse en la forma de una unidad de disco que tiene a pluralidad de archivos. 11. - El método de acuerdo con la reivindicación 7, en donde examinar los componentes constituyentes de la VM montada para determinar si cada construcción de software en la VM es actual comprende revisar información de la VM montada incluyendo ? versiones de archivo e información de registro. 12. - El método de acuerdo con la reivindicación 7, en donde un controlador de VM opera para recuperar una VM almacenada de la biblioteca y montar la VM recuperada al dispositivo de cómputo, y también para almacenar la VM actualizada en la biblioteca, el método siendo realizado por el controlador de VM. 13. - El método de acuerdo con la reivindicación 12, que comprende el controlador de VM que opera basándose en un programador para desplegar periódicamente cada VM de la biblioteca al dispositi o de cómputo huésped de mantenimiento para actualización. 14. - El método de acuerdo con la reivindicación 7, que comprende operar basándose en un programador para desplegar periódicamente cada VM de la biblioteca al dispositivo de cómputo huésped de mantenimiento para actualización. 15.- Un método con respecto a una biblioteca de máquinas virtuales (VMs) en un dispositivo de cómputo, cada VM almacenada en una forma detenida en tal biblioteca para recuperación de la biblioteca y reinicio en un dispositivo de cómputo huésped, cada VM en la biblioteca siendo una construcción de software que cuando se reinicia en un dispositivo de cómputo huésped emula un sistema de hardware, cada VM reiniciada incluye una pluralidad de construcciones de software, cada construcción de software de cada VM en la biblioteca al menos siendo potencialmente no actual y que requiere una actualización de software, el método comprende, para cada VM en la biblioteca: determinar periódicamente si cada construcción de software de la VM es actual, y si cualquier construcción de software de la VM no es actual, marcar la VM en la biblioteca como no actual; recibir una selección de una VM de la biblioteca para recuperarse y reiniciarse en un dispositivo de cómputo huésped; determinar si la VM seleccionada se marca en la biblioteca como siendo no actual, y si no es actual actualizar la VM en un dispositivo de cómputo huésped de mantenimiento que no tiene acceso a ningún dispositivo de cómputo huésped; y reiniciar la VM actualizada en el dispositivo de cómputo huésped. 16. - El método de acuerdo con la reivindicación 15, en donde un controlador de VM opera para recuperar una VM almacenada de la biblioteca y reiniciar la VM recuperada en el dispositivo de cómputo huésped de mantenimiento, y también para detener la VM reiniciada y almacenar la VM detenida en la biblioteca, el método siendo realizado por el controlador de VM. 17. - El método de acuerdo con la reivindicación 16, que comprende el controlador de VM que opera basándose en un programador para determinar periódicamente si cada construcción de software de la VM es actual. 18. - El método de acuerdo con la reivindicación 15, que 0 comprende operar basándose en un programador para determinar periódicamente si cada construcción de software de la VM es actual. 19.- El método de acuerdo con la reivindicación 15, en donde actualizar la VM comprende: recuperar la VM de la biblioteca y reiniciar la VM recuperada en el dispositivo de cómputo huésped de mantenimiento; y permitir a cada construcción de software no actual de la VM reiniciada actualizarse en el dispositivo de cómputo huésped de mantenimiento al obtener la actualización de software requerida de una fuente de actualización correspondiente como al menos un parche. 20.- El método de acuerdo con la reivindicación 15, en donde actualizar la VM comprende: recuperar la VM de la biblioteca y montar la VM recuperada al dispositivo de cómputo; y examinar componentes constituyentes de la VM montada para determinar si cada construcción de software de la VM es actual, y para cada construcción de software no actual actualizar la misma en el dispositivo de cómputo huésped de mantenimiento al obtener la actualización de software requerida de una fuente de actualización correspondiente con al menos un parche y aplicar cada parche a la VM montada.