BRPI0709166B1

BRPI0709166B1 - criando modelos de recursos fora de linha

Info

Publication number: BRPI0709166B1
Application number: BRPI0709166A
Authority: BR
Inventors: S Araujo Nelson Jr; P Robertson Steven
Original assignee: Microsoft Corp; Microsoft Technology Licensing Llc
Priority date: 2006-03-30
Filing date: 2007-02-21
Publication date: 2019-01-15
Also published as: US20170147390A1; KR20080114752A; EP2011020A4; US9600276B2; EP2011020A1; AU2007235540B2; JP2009532757A; TWI411958B; MX2008011907A; BRPI0709166A2; RU2436150C2; CA2644167C; US20070234334A1; KR101344163B1; CN101416175A; EP2011020B1; BRPI0709166A8; JP5113831B2; US9213542B2; MY155040A

Abstract

criando modelos de recursos fora de linha. implementações da presente invenção permitem que recursos de software sejam duplicados eficientemente e efetivamente enquanto estão fora de linha. em uma implementação, um programa de preparação recebe uma identificação de um recurso de software, tais como uma máquina virtual instalada em um volume diferente, um sistema operacional fora de linha ou um programa de aplicação. o programa de preparação também recebe uma indicação das marcas distintivas customizadas que devem ser removidas do recurso de software. estas marcas distintivas podem incluir informação personalizada, bem como o nível das atualizações de software, ajustes de segurança, ajustes de usuário ou congêneres. mediante a execução, o programa de preparação redireciona as chamadas de função do programa de preparação ao recurso de software no volume diferente (ou até no mesmo volume) enquanto o recurso de software não estiver em execução. assim, o programa de preparação pode criar um modelo do recurso de software de uma maneira segura sem afetar necessariamente o volume no qual o programa de preparação estiver em execução.

Description

“CRIANDO MODELOS DE RECURSOS FORA DE LINHA”

ANTECEDENTES DA INVENÇÃO

Antecedentes e Tecnologia Relevante

Há inúmeras maneiras de distribuir diferentes tipos de recursos (software, hardware ou combinações destes) em um ambiente computadorizado. Por exemplo, Do vista de software, uma empresa pode instalar múltiplas cópias do sistema operacional (ou programa de aplicação) em múltiplos computadores diferentes e, desse modo, distribuir uma cópia entre muitos sistemas. Ao longo dessas linhas de ação, a empresa também pode precisar instalar diversas atualizações adicionais de software ao sistema operacional copiado ou compartilhado e, assim, também compartilhar múltiplas cópias destas atualizações entre os muitos sistemas. Maneiras convencionais de compartilhar hardware incluem ajustar sistemas de computador em uma rede para que múltiplos diferentes sistemas de computador possam acessar o espaço de unidade de um outro computador em relação a várias necessidades de armazenamento ou de compartilhamento de arquivos.

Maneiras adicionais de distribuir recursos do ponto de vista de software e de hardware incluem criar entidades exclusivas em um único sistema de computador físico, em que as entidades se comportam como sistemas de computador separados e independentes, mas compartilham as mesmas mídias físicas e recursos de processamento. Por exemplo, uma empresa pode criar múltiplas máquinas virtuais no mesmo único servidor, cada uma das quais pode ser separadamente endereçada por um outro computador como se cada dada máquina virtual fosse seu próprio sistema de computador separado. Em uma implementação como esta, um ou alguns servidores em uma grande empresa também podem hospedar diversas máquinas virtuais no mesmo conjunto de hardware, em que cada uma destas máquinas virtuais pode servir como servidores adicionais, ou computadores pessoais acessíveis pela rede, entretanto configuradas.

Entende-se que tais entidades, como máquinas virtuais, combinam o compartilhamento de recursos de software e de hardware já que, tipicamente, elas ajustam com uma cópia existente de um sistema operacional usado por uma outra máquina virtual, e já que elas podem mesmo compartilhar uma unidade que já está sendo usada pela outra máquina virtual. Entretanto, apesar do compartilhamento do mesmo sistema operacional, a empresa precisará customizar aspectos do sistema operacional para que a máquina virtual não seja confundida com outras máquinas virtuais que usam a mesma cópia do sistema operacional, particularmente, quando instalada na mesma unidade física. Portanto, para criar uma máquina virtual customizada, um administrador do sistema precisará fornecer a nova máquina virtual com marcas distintivas exclusivas que a distingue das outras máquinas virtuais (ou de outros sistemas de computador), tais como o nome da máquina, zona de horário, nome de domínio, nome da companhia, chaves do produto e congêneres.

Entretanto, simplesmente customizar a máquina virtual pode ser bastante difícil. Por exemplo, o administrador do sistema pode desejar simplesmente instalar a máquina virtual a partir da cópia de instalação básica de um sistema operacional e, então, aplicar todos os vários caminhos de software de interesse, bem como as marcas distintivas exclusivas da máquina virtual. Certamente, isto pode ser bastante inconveniente se houver um grande número de caminhos de software e outras customizações exclusivas que o administrador do sistema deseja aplicar. Assim, o administrador do sistema pode preferir copiar uma instância de um sistema operacional que já foi customizada em relação às preferências do administrador do sistema do ponto de vista de software e, então, instalar aquela cópia na nova máquina virtual, embora com diferentes marcas distintivas exclusivas. Como tal, o administrador do sistema precisará remover as marcas distintivas customizadas da cópia de interesse existente antes de instalar aquela cópia na nova máquina virtual.

Contudo, há diferentes dificuldades em simplesmente remover marcas distintivas customizadas de uma cópia do sistema operacional e, então, adicionar novas marcas distintivas customizadas na cópia do sistema operacional em uma nova máquina virtual. Em particular, software de preparação convencional que pode ser usado para criar uma cópia “genérica” ou “modelo” de um sistema operacional (ou aplicação) pode ser difícil de usar, e pode levar uma quantidade significativa de tempo. Por exemplo, um administrador de sistema pode precisar iniciar uma cópia do sistema operacional de interesse e, então, executar certo software de preparação no topo do sistema operacional enquanto ele está em execução. À medida que o software de preparação remove certos recursos exclusivos da cópia do sistema operacional, o software de preparação pode exigir que o sistema operacional reinicie diversas vezes até que todos os recursos exclusivos tenham sido removidos.

Além das dificuldades inerentes em reiniciar continuamente o sistema operacional (ou aplicação) em função do simples atraso, software de preparação convencional também pode ser tecnicamente complexo e difícil de usar. Em particular, se um usuário deixar de configurar apropriadamente o software de preparação antes de tentar converter um sistema operacional em uma cópia genérica ou modelo, o usuário pode tirar itens que o usuário não pretendia tirar. Isto pode resultar no fato de o usuário gastar mais tempo retornando o sistema operacional até um ponto apropriado, ou mesmo tornando o dado sistema operacional de interesse (ou seu modelo) inoperável.

Dessa maneira, há inúmeros problemas com a criação de novas instâncias de entidades que usam software pré-existente que podem ser endereçadas.

SUMÁRIO DA INVENÇÃO

Implementações da presente invenção resolvem um ou mais problemas na tecnologia com sistemas, métodos e produtos programa de computador configurados para criar cópias modelos de recursos fora de linha. Em particular, implementações da presente in venção permitem que uma cópia de um recurso em particular, tal como uma cópia de um sistema operacional ou aplicação, seja transformada em uma cópia genérica ou modelo do recurso de acordo com as especificações de um usuário, e enquanto o recurso não estiver em execução (isto é, fora de linha). Portanto, implementações da presente invenção permitem que um usuário crie tantas cópias modelos do mesmo recurso quantas forem desejadas com bastante eficiência e configurabilidade. Tais implementações também podem fornecer uma conveniente experiência de usuário no sentido de customizar o modelo durante o processo em um ponto posterior.

Por exemplo, um método para criar um modelo de pelo menos um dos um ou mais recursos de software, enquanto o pelo menos um recurso de software estiver fora de linha, pode envolver identificar um recurso de software fora de linha, bem como identificar um ou mais ajustes de modelos. No geral, estes ajustes de modelos indicarão uma ou mais marcas distintivas a ser removidas do recurso de software. Além do mais, o método pode envolver executar, em um primeiro sistema operacional, um programa de preparação configurado para remover marcas distintivas de acordo com o ajuste de modelo. O método também pode envolver redirecionar uma ou mais chamadas de função do programa de preparação ao recurso de software identificado. Como tal, as marcas distintivas identificadas pelos um ou mais ajustes de modelo são removidas do recurso de software, e um modelo do recurso de software é criado.

Além do mais, um método para duplicar uma máquina virtual, enquanto ela estiver fora de linha, de maneira tal que a máquina virtual e a máquina virtual duplicada tenham identidades distinguíveis durante a execução, pode envolver receber a identidade de um arquivo de máquina virtual instalado em um primeiro espaço de armazenamento. O método também pode envolver receber uma ou mais chamadas de função de um programa de preparação instalado em um segundo espaço de armazenamento, onde as uma ou mais chamadas de função solicitam a remoção das uma ou mais marcas distintivas. Além do mais, o método pode envolver executar as uma ou mais chamadas de função no arquivo de máquina virtual, o que pode resultar na remoção das marcas distintivas solicitadas no primeiro espaço de armazenamento. Além do mais, o método pode envolver criar uma cópia modelo do arquivo de máquina virtual.

Este Sumário é fornecido para introduzir uma seleção de conceitos de uma forma simplificada que será adicionalmente descrita a seguir na Descrição Detalhada. Não pretende-se que este Sumário identifique recursos chaves ou recursos essenciais do assunto em questão reivindicado, nem pretende-se que seja usado como um auxílio na determinação do escopo do assunto em questão reivindicado.

Recursos e vantagens adicionais das implementações exemplares da invenção serão apresentados na descrição que segue e, em parte, ficarão óbvios a partir da descrição ou podem ser aprendidos pela prática de tais implementações exemplares. Os recursos e vantagens de tais implementações podem ser realizados e obtidos por meio de instrumentos e combinações particularmente salientados nas reivindicações anexas. Estes e outros recursos ficarão mais completamente aparentes a partir das seguintes descrição e reivindicações anexas ou podem ser aprendidos pela prática de tais implementações exemplares doravante apresentadas.

DESCRIÇÃO RESUMIDA DOS DESENHOS

A fim de descrever a maneira pela qual as vantagens e recursos expostos da invenção podem ser obtidos, uma descrição mais particular da invenção anteriormente descrita em resumo será fornecida em relação às suas modalidades específicas, que são ilustradas nos desenhos anexos. Entende-se que estes desenhos representam somente modalidades típicas da invenção e que, portanto, não devem ser considerados limitantes do seu escopo, e que a invenção será descrita e explicada com especificidade e detalhes adicionais por meio do uso dos desenhos anexos, nos quais:

a figura 1A ilustra um diagrama esquemático de visão geral de acordo com uma implementação da presente invenção na qual um programa de preparação cria uma ou mais cópias modelos de um recurso fora de linha e instala o recurso em um ou mais volumes hospedeiros;

a figura 1B ilustra uma vista mais detalhada do diagrama esquemático mostrado na figura 1A, na qual um programa de preparação faz interface com um agente de preparação para criar modelos de um recurso em uma mídia de armazenamento, e instala versões customizadas daquele recurso em diferentes mídias de armazenamento em diferentes volumes de hospedeiro;

a figura 1C ilustra um conjunto de camadas de aplicação de acordo com a presente invenção configurado para redirecionar chamadas de função de um programa de preparação até um arquivo alvo de recurso apropriado; e a figura 2 ilustra fluxogramas que compreendem uma série de atos, a partir da perspectiva de um programa de preparação e de um agente de preparação, para criar uma cópia modelo de um recurso fora de linha.

DESCRIÇÃO DETALHADA

A presente invenção se estende a sistemas, métodos e produtos programa de computador configurados para criar cópias modelos de recursos fora de linha. Em particular, implementações da presente invenção permitem que uma cópia de um recurso em particular, tal como uma cópia de um sistema operacional ou aplicação, seja transformada em uma cópia genérica ou modelo do recurso de acordo com as especificações de um usuário, e enquanto o recurso não estiver em execução (isto é, fora de linha). Portanto, implementações da presente invenção permitem que um usuário crie tantas cópias modelos do mesmo recurso quantas forem desejadas com bastante eficiência e configurabilidade. Tais implementações também podem fornecer uma experiência de usuário conveniente no sentido de customizar o modelo durante o processo em um ponto posterior.

Entende-se mais completamente a partir da descrição e das reivindicações aqui expostas que pelo menos uma vantagem destas implementações é que usuários (por exemplo, administradores de sistema) podem fornecer eficientemente uma máquina virtual customizada a um grande número de outros usuários sem precisar recriar aquela máquina virtual customizada a partir de um nível de base. Além do mais, o usuário ou titular de uma máquina virtual customizada podem criar facilmente um modelo da máquina virtual do usuário sem precisar, necessariamente, passar por diversas reiniciações e/ou reinicializações do hardware ou do software associado com ele. Além do mais, já que o processo pode ser automatizado, algumas das decisões tipicamente difíceis, para as quais usuários regulares não saberão a resposta (tais como Chaves do Produto, DNS, WINS, etc.), podem ser abordadas pelo sistema automaticamente, em última análise, economizando custos, por exemplo, em chamadas de serviço de apoio ou administrativas. Ainda adicionalmente, as implementações da presente invenção permitem que as chamadas de função de certo software de preparação sejam facilmente redirecionadas para um outro local para que o usuário possa criar um modelo de uma máquina virtual remotamente localizada.

Da forma aqui usada, um “programa de preparação” diz respeito a um conjunto de instruções executáveis por computador, no geral, independentes, configurado para fazer interface com um arquivo em particular da forma instruída por um usuário em particular, tais como um arquivo de imagem de uma máquina virtual ou sistema operacional, ou uma imagem (ou arquivo executável) de um arquivo de programa de aplicação. Então, de acordo com os ajustes de modelo fornecidos, o programa de preparação pode remover certas marcas distintivas customizadas daquele arquivo. Em pelo menos uma implementação, em relação ao ambiente operacional MICROSOFT, por exemplo, um programa de preparação (por exemplo, 145) que pode ser usado de acordo com uma ou mais implementações da presente invenção, é a ferramenta de Preparação do Sistema, também chamada de “Sysprep”.

Em todo caso, em alguns casos, como aqui descrito primariamente, o programa de preparação fará adicionalmente a interface com um “agente de preparação” pela configuração do usuário ou de outro administrador. Um agente de preparação também é um conjunto de instruções executáveis por computador que age efetivamente como uma interface de enchimento (por exemplo, figura 1C) entre o programa de preparação e o arquivo de interesse (e/ou também por meio de quaisquer outros componentes de interface apropriados relevantes para um sistema operacional em particular). Em particular, o agente de preparação será configurado para receber e redirecionar chamadas do programa de preparação. Em pelo menos uma implementação, o agente de preparação é configurado para tomar e redirecionar chamadas do programa de preparação sem o conhecimento do programa de preparação de tal recepção e/ou redirecionamento.

A figura 1A ilustra um diagrama esquemático de visão geral de acordo com uma implementação da presente invenção na qual um programa de preparação cria uma ou mais cópias modelos de um recurso fora de linha, e os instala. Então, um ou mais outros recursos ou componentes (não mostrados) (por exemplo, um ou mais outros módulos ou mecanismos de redistribuição ou de armazenamento) podem fornecer as cópias modelos do recurso em um ou mais volumes hospedeiros. Por exemplo, a figura 1A mostra que o servidor 105 hospeda um ou mais recursos, tal como o recurso 140, que está atualmente “fora de linha” ou não está em execução. Neste exemplo, o recurso 140 compreende uma “máquina virtual” que é, essencialmente, uma entidade independente em execução em uma partição de disco rígido alocada no servidor 105.

Como uma máquina virtual, o recurso 140 pode fornecer a maior parte ou todos os benefícios de uma máquina física convencional, tal como executar programas de aplicação, interagir com outras máquinas físicas ou virtuais, servir aplicações / funções de rede ou de base de dados, e assim por diante. Por exemplo, em uma implementação, o servidor 105 compreende uma parte principal que age, primariamente, como um servidor de armazenamento, enquanto o recurso 140 age como um servidor de correio eletrônico ou de base de dados. Como tal, no geral, outros na rede não estão cientes de que o recurso 140 é somente uma máquina virtual hospedada pelo servidor 105, pelo menos em parte, já que o recurso 140 é suficientemente customizado e independentemente endereçável, se comparado com outras máquinas na rede.

A figura 1A mostra adicionalmente que, em algum ponto, um usuário deseja duplicar o recurso 140. Por exemplo, o usuário gosta da maneira que vários ajustes, atualizações e configurações de software foram aplicados no recurso 140 e, portanto, gostariam de duplicar o recurso 140 para uso nos outros hospedeiros, sem começar a apagar ou remover estas customizações de software. Dessa maneira, a figura 1A mostra que o programa de preparação 145 faz interface com o recurso 140 enquanto ele está fora de linha e cria cópias modelos 140a correspondentes. Então, estes modelos podem ser transmitidos, instalados e opcionalmente customizados como apropriado, em hospedeiros 110 e 115, em volumes separados (isto é, 165, 180). Mediante customização apropriada, estas novas versões do recurso 140 (isto é, recursos 140b, 140c), podem ser, então, visualizados como entidades independentes que, para todos os objetivos e propósitos, são máquinas novas para outros usos na rede.

A figura 1B ilustra uma vista mais detalhada do diagrama esquemático mostrado na figura 1A no qual o programa de preparação 145 exposto faz interface com o agente de preparação 150 para criar modelos 140a do recurso 140. Em particular, a figura 1B mostra que o servidor 105 compreende uma pluralidade de diferentes máquinas e/ou máquinas virtuais e, portanto, age, em alguns aspectos, como uma biblioteca da máquina virtual. Por exemplo, a figura 1B mostra que o servidor 105 compreende entidades separadas armazenadas no volume principal 160 (“c:\”), bem como volumes adicionais de máquina virtual (“x:\”) 170 e (“z:\”) 175. Cada tal volume neste exemplo também inclui um recurso em particular com seu próprio sistema operacional separadamente customizado. Por exemplo, o volume 160 tem o recurso 130 nele armazenado e/ou instalado, enquanto que os volumes 170 e 175 têm recursos 135 e 140 nele armazenados e/ou instalados, respectivamente. Neste caso em particular, ambos os recursos 135 e 140 estão atualmente fora de linha (isto é, “recursos fora de linha” 125).

A título de explicação, este exemplo em particular mostra que cada volume 160, 170, 175, etc. é identificável por meio de uma designação de letra de unidade em particular. Entretanto, percebe-se que isto não é exigido, de acordo com implementações da presente invenção. Por exemplo, um caminho de unidade pode ser designado por qualquer Identificador Exclusivo Global (“GUID”) apropriado para um dado sistema operacional. Um caminho de unidade também pode ser designado sem um GUID em outros casos. Por exemplo, o caminho de unidade pode designar um volume não montado, um volume montado sem uma letra de unidade (por exemplo, um ponto de montagem), um volume montado com uma letra de unidade, ou mesmo um instantâneo transportável. Em última análise, precisa haver somente uma maneira de endereçar o volume em particular. Assim, as ilustrações e designações da unidade ou dos caminhos de arquivo em particular aqui feitas ilustram pelo menos uma implementação possível de conveniência descritiva.

Em qualquer caso, e como exposto, no geral, cada recurso será separadamente customizado pelo menos em termos de marcas distintivas básicas que permitem que o recurso seja distinguido por um sistema de computador local ou remoto. Por exemplo, a figura 1B mostra que o recurso 130 compreende “marcas distintivas customizadas a, b, c”, enquanto o recurso 135 compreende “marcas distintivas customizadas c, d,e”eo recurso 140 compreende “marcas distintivas customizadas c, f, g”. Notavelmente, neste caso, cada recurso tem pelo menos uma marca distintiva “c” comum, que pode indicar um nome de domínio, um ajuste de zona de hora, ou alguma outra marca distintiva ou propriedade que pode ser compartilhada. Entretanto, cada recurso compreende adicionalmente marcas distintivas exclusivas, tais como “a, b” para o recurso 130, “d, e” para o recurso 135, e “f, g” para o recurso 140. Por exemplo, a marca distintiva “c” comum pode ser uma associação em nome de domínio de rede comum, enquanto que as marcas distintivas exclusivas “a, b”, “d, e” e “f, g” podem ser nomes de computador, contas de titular, ajustes de configuração ou congêneres exclusivos.

A figura 1B mostra adicionalmente que cada recurso também pode ser separada mente customizado com várias versões, atualizações e/ou caminhos, etc. de software. Por exemplo, os recursos 130 e 135 incluem “atualizações de software x, y, z”, enquanto que o recurso 140 inclui “atualizações de software v, y e z”. No mesmo ponto, um usuário pode decidir que ele tem uma preferência para a maneira que o recurso 140 executa por qualquer número de motivos, tal como ser baseado nas atualizações “v, y, z” em vez de “x, y, z”. Como tal, então, o usuário pode decidir criar um modelo do recurso 140 que preserva as atualizações de software relevantes, mas remove outras marcas distintivas customizadas, tais como o nome do computador, contas de titular, ajustes de economia à luz do dia ou congêneres.

Dessa maneira, o usuário prepara os ajustes de modelo 155, que alvejam o recurso 140 por meio do volume “z:\” 175, e inclui uma solicitação específica somente para remover as marcas distintivas customizadas “f e g”. Em uma implementação, os ajustes de modelo 144 são simplesmente dados eletrônicos fornecidos ao programa de preparação 145 e criados em resposta à entrada recebida por meio de uma interface de usuário. Em outros casos, os ajustes de modelo 155 podem ser um arquivo ou componente separadamente criado usando um outro programa, em que o programa de preparação 145 simplesmente recebe os dados ali contidos. Em todo caso, a figura 1B mostra adicionalmente que o programa de preparação 145 incorpora os ajustes de modelo 155 à medida que ele executa por meio do agente de preparação 150.

Por exemplo, da forma mostrada na figura 1C, o agente de preparação 150 serve, de fato, como um enchimento entre o programa de preparação 145 e todos os outros componentes apropriados, tal como um montador de unidade rígida de volume 195 que, por sua vez, pode fazer interface diretamente com um arquivo correspondente para o recurso. Como tal, o agente de preparação 150 pode servir, pelo menos em parte, como uma blindagem, em que as chamadas de função feitas pelo programa de preparação 145 podem ser direcionadas como ajustes pelos ajustes de modelo 155 até outro volume fora de linha em vez de até o sistema operacional no qual o programa de preparação 145 está em execução. Isto é, o agente de preparação 150 pode ser configurado para redirecionar funções de chamada até um alvo apropriado e, desse modo, garantir que o programa de preparação 145 faça somente um modelo do recurso 140, em vez do recurso 130, onde o programa de preparação 145 e o agente de preparação 150 são instalados.

Novamente, em relação à figura 1B, a figura mostra que o agente de preparação 150 redireciona as chamadas de função do programa de preparação 145 que incluem instruções para retirar as marcas distintivas customizadas “f, g” do recurso fora de linha 140. Em uma implementação, os programas de preparação 145 simplesmente tiram as uma ou mais marcas distintivas especificadas antes que o recurso 140 possa ser retornado em linha. Em uma outra implementação, o usuário filtra os resultados das chamadas de função de cópia e filtragem para um outro arquivo sem remover marcas distintivas diretamente do recurso 140. Em uma ainda outra implementação, primeiro, o usuário pode copiar o arquivo fora de linha do recurso 140 até um local separado e, então, tirar a marca distintiva incluída nos ajustes de modelo 155. Apesar de configuradas, as chamadas de função do programa de preparação 145 podem fazer com que o recurso 140 seja tirado como especificado, resultando em tantas cópias do modelo 140a quantas forem desejadas com mínima interrupção. Como exposto, pelo menos em parte, isto ocorre desde que a execução destas chamadas de função não exijam reiniciação ou reinicialização adicionais do recurso 140.

Por exemplo, em relação particular às máquinas virtuais, o programa de preparação 145, por meio do agente de preparação 150, pode montar todos os discos rígidos virtuais (por exemplo, volume 175) do recurso correspondente (isto é, arquivo de imagem do recurso). Alternativamente, o programa de preparação 145 pode ser configurado para simplesmente ler ou gravar no arquivo de recurso sem, necessariamente, montar o volume. Então, o programa de preparação 145 pode ajustar o agente de preparação 150 com todos os indicadores apropriados, tal como pela iniciação do agente de preparação 150 como um novo processo no modo de depuração. Durante a iniciação do agente de preparação 150, o programa de preparação 145 pode ajustar o agente de preparação 150 de acordo com os ajustes do modelo 155 para capturar todas as chamadas ao sistema de arquivos, capturar todas as chamadas ao registro de sistema, e capturar todas as outras chamadas necessárias para fazer a execução ser realizada com sucesso. Então, o programa de preparação 145 pode começar a passar as chamadas de função apropriadas para o agente de preparação 150 que, então, redireciona aquelas chamadas de função de acordo com o ajuste (isto é, ajustes de modelo 155). Por exemplo, os comandos do programa de preparação 145 para remover marcas distintivas customizadas do recurso 130 são redirecionados ao contrário pelo agente de preparação 150 até o recurso 140.

Uma vez que as customizações apropriadas foram removidas, a figura 1B mostra adicionalmente que, agora, o modelo recém-criado 140a pode ser instalado em outro lugar, como desejado. Por exemplo, a figura 1B mostra que o servidor 105 fornece o modelo de recurso 140a e um conjunto de novas marcas distintivas 185 ao volume “p:\” no hospedeiro 110 para, desse modo, criar o recurso 140b. Similarmente, a figura 1B mostra que o servidor 105 fornece modelo de recurso 140a e novas marcas distintivas 190 ao volume “j:\” no hospedeiro 115 para, desse modo, criar o recurso 140c. Em ambos os casos, a nova iteração do recurso 140 (isto é, recurso 140b-c) retém as atualizações de software solicitadas “v, y, z”, bem como a marca distintiva customizada “c”. Contudo, a figura 1B mostra que o recurso 140b é pelo menos exclusivo pela inclusão de marcas distintivas adicionais, tais como “h, i” para o recurso 140b e “j, k” para o recurso 140c. Como exposto, estas marcas distintivas exclusivas podem corresponder a qualquer número de itens, tais como nome do computador ou outra informação de ajuste apropriada.

Há inúmeras diferentes maneiras pelas quais as novas marcas distintivas 185, 190 podem ser fornecidas durante uma nova instalação do modelo de recurso 140a. Por exemplo, como exposto, estes ajustes podem ser fornecidos em antecipação ao programa de preparação 145 por meio de um sinal de prontidão da interface de usuário durante a retirada das marcas distintivas do recurso 140, ou podem ser recebidos de uma mídia de armazenamento diferente, tal como um disco flexível, em qualquer momento apropriado. Em outros casos, o programa de preparação 145 (ou congêneres) pode ser usado novamente no hospedeiro 110, 115 para lembrar um usuário sobre esta informação por meio de uma interface de usuário apropriada na instalação.

Além do mais, percebe-se que pode haver inúmeras variações dos componentes e mecanismos supramencionados no contexto da presente invenção. Por exemplo, além da retirada das marcas distintivas customizadas e/ou dos componentes ou atualizações de software específicos de um recurso alvejado instalado em um volume local, um administrador de sistema também pode realizar tais funções em recursos fora de linha remotos. Por exemplo, um administrador de sistema pode usar o programa de preparação 145 e o agente de preparação 150 para tirar certas atualizações de software de todos os recursos fora de linha em uma grande empresa. Similarmente, o administrador de sistema pode usar o programa de preparação 145 e o agente de preparação 150 para tirar todas as marcas distintivas customizadas de uma máquina virtual de propriedade de um empregado anterior. Além do mais, um administrador de sistema pode usar o programa de preparação 145 e o agente de preparação 150 para ajustar uma versão particularmente customizada de um sistema operacional para uso em estações pessoais ao redor de uma empresa e, então, criar cópias que podem ser instaladas com mínimo esforço em cada estação.

Ainda adicionalmente, usuários individuais podem usar estes componentes em vários ajustes pessoais. Por exemplo, um usuário pode criar uma cópia de uma versão em funcionamento e atualizada de um sistema operacional que tem todos os caminhos e vários softwares de segurança instalados e configurados, remover as chaves de produtos relevantes e, então, reinstalar esta cópia em um outro computador, de um amigo ou de um membro da família, com diferentes, mas válidas chaves, nomes de computador, e assim por diante. Dessa maneira, as figuras 1A-1C ilustram inúmeros diagramas esquemáticos e componentes que podem ser usados em uma ampla faixa de ajustes para criar modelos de recursos existentes com bastante eficiência e precisão.

Implementações da presente invenção também podem ser descritas em termos dos fluxogramas de um ou mais métodos que compreendem uma série de diferentes atos para realizar um resultado em particular. Em particular, a figura 2 ilustra fluxogramas de atos a partir da perspectiva do programa de preparação 145 e do agente de preparação 150 para criar uma cópia modelo de um recurso fora de linha. Os atos da figura 2 são descritos a seguir em relação aos componentes e mecanismos descritos nas figuras 1A até 1C.

Como uma questão preliminar, algumas vezes, a referência é aqui feita a um “primeiro”, “segundo” ou “terceiro” componente (por exemplo, primeiro, segundo ou terceiro espaço de armazenamento). Entretanto, percebe-se que tais designações são meramente para diferenciar componentes, de maneira tal que o “primeiro” componente do espaço de armazenamento precise ser diferente somente de um “segundo” ou “terceiro” componentes ou espaços de armazenamento, sem considerar pontos nos quais o componente pode ser acessado. Por exemplo, o uso de um primeiro espaço de armazenamento, e de um segundo ou de um terceiro espaços de armazenamento somente significa que aqueles primeiro, segundo ou terceiro espaços de armazenamento são pelo menos diferentes um em relação aos outros, e estas designações não exigem que os primeiro, segundo ou terceiro espaços de armazenamento sejam necessariamente apresentados, acessados, criados ou ter outra ação neles realizada em qualquer seqüência ou ordem em particular.

Por exemplo, a figura 2 mostra que um método, a partir da perspectiva do programa de preparação 145, para criar um modelo de pelo menos um dos um ou mais recursos de software enquanto o pelo menos um recurso de software estiver fora de linha, compreende um ato 200 de identificar um recurso fora de linha. O ato 200 inclui identificar um recurso de software fora de linha. Por exemplo, o programa de preparação 145 recebe entrada de um usuário para criar um modelo do recurso 140, que fica localizado no volume “z:\” 175.

Similarmente, a figura 2 mostra que o método, da perspectiva do agente de preparação 150, para duplicar uma máquina virtual enquanto ela estiver fora de linha, de maneira tal que a máquina virtual e a máquina virtual duplicada tenham identidades distinguíveis durante a execução, compreende um ato 210 de receber uma identidade de arquivo fora de linha. Um ato 210 inclui receber a identidade de um arquivo de máquina virtual instalado em um primeiro espaço de armazenamento. Por exemplo, o agente de preparação 150 recebe uma indicação do programa de preparação para alvejar o recurso 140 no volume “z:\” 175. No caso específico de uma máquina virtual, o recurso 140 pode ser identificável como um único arquivo, tal como um arquivo de Disco Rígido Virtual (isto é, “.vhd”, “VHD” ou “.vhd). Percebe-se que, em alguns casos, uma máquina virtual pode ser altemativamente representada por uma pluralidade de arquivos “.vhd”.

A figura 2 também mostra que o método, da perspectiva do programa de preparação 145, compreende um ato 220 de identificar ajustes de modelo. O ato 220 inclui identificar um ou mais ajustes de modelo que identificam uma ou mais marcas distintivas a ser removidas do recurso de software. Por exemplo, o agente de preparação 145 recebe ajustes de modelo 155, que incluem instruções para remover as marcas distintivas customizadas “f, g”, mas para preservar qualquer uma ou mais das atualizações de software “v, y, z”, como desejado. Além do mais, a figura 2 mostra que o método, da perspectiva do programa de preparação 145, compreende um ato 230 de executar o programa de preparação. O ato 230 inclui executar, em um primeiro sistema operacional, um programa de preparação configurado para remover marcas distintivas de acordo com os ajustes de modelo. Por exemplo, a figura 1B mostra que o programa de preparação 145 opera e/ou executa no recurso 130 (isto é, o sistema operacional correspondente), mas redireciona chamadas de função ao recurso 140 de acordo com os ajustes de modelo 155.

Dessa maneira, a figura 2 mostra que o método, a partir da perspectiva do programa de preparação 145, compreende adicionalmente um ato 240 de redirecionar chamadas de função ao recurso identificado. O ato 240 inclui redirecionar uma ou mais chamadas de função do programa de preparação ao recurso de software identificado, de maneira tal que as marcas distintivas identificadas pelos um ou mais ajustes de modelo sejam removidas do recurso de software, e de maneira tal que um modelo do recurso de software seja criado. Por exemplo, o programa de preparação 145 inicia o agente de preparação 150 como um novo processo no modo de depuração, e ajusta o agente de preparação 150 com todas as funções de redirecionamento apropriadas, de acordo com os ajustes de modelo 155. Assim, quando o programa de preparação 145 transmitir uma chamada de função para remover uma marca distintiva customizada, a chamada é apropriadamente redirecionada ao recurso de software alvejado e, em última análise, o modelo é criado.

Portanto, similarmente, a figura 2 mostra adicionalmente que o método, a partir da perspectiva do agente de preparação 150, compreende um ato 250 de receber uma ou mais chamadas de função. O ato 250 inclui receber uma ou mais chamadas de função de um programa de preparação instalado em um segundo espaço de armazenamento, as uma ou mais chamadas de função solicitando a remoção das uma ou mais marcas distintivas. Por exemplo, da forma mostrada em ambas as figuras 1B e 1C, o agente de preparação 150 faz interface diretamente com o programa de preparação 145 para receber instruções e implementar estas instruções onde for indicado pelos ajustes de modelo 155. Como tal, o agente de preparação 150 pode garantir que, apesar de o programa de preparação 145 ser executado no volume principal 160, as funções de retirada pretendidas somente ocorrem no volume (por exemplo, 175) do alvo fora de linha apropriado (por exemplo, recurso 140).

Além do mais, a figura 2 mostra que o método, a partir da perspectiva do agente de preparação 150, compreende um ato 260 de executar as uma ou mais chamadas de função no arquivo. O ato 260 inclui executar as uma ou mais chamadas de função no arquivo de máquina virtual, de maneira tal que as uma ou mais marcas distintivas sejam removidas no primeiro espaço de armazenamento. Por exemplo, no caso particular de uma máquina virtual que é representada por um arquivo de máquina virtual, o agente de preparação 150 faz interface diretamente com o arquivo de máquina virtual (ou diretamente com um montador de unidade rígida de volume 195) para remover as marcas distintivas customizadas especificadas (por exemplo, “f, g” do recurso 140) ou componentes de software indesejados do arquivo de máquina virtual. Esta execução pelo agente de preparação 150 pode ser feita localmente no servidor 105, ou mesmo por meio de chamadas de função remotas em uma rede.

A figura 2 mostra adicionalmente que o método, a partir da perspectiva do agente de preparação 150, compreende um ato 270 de criar uma cópia modelo do arquivo fora de linha. O ato 270 inclui criar uma cópia modelo do arquivo de máquina virtual. Por exemplo, da forma mostrada na figura 1B, os resultados da execução no recurso 140 são a criação da cópia do modelo 140, que inclui atualizações de software “v, y, z”, e somente a marca distintiva customizada “c”.

Dessa maneira, os métodos, e componentes e diagramas esquemáticos correspondentes aqui descritos fornecem uma ou mais implementações para criar um modelo de um recurso de software fora de linha muito mais eficientemente do que disponível em outras circunstâncias. Em particular, implementações da presente invenção permitem que modelos sejam criados usando processos que são relativamente rápidos, confiáveis e, tipicamente, não exigem interface ou credenciais de usuário final para realizar as customizações. Além do mais, não há necessidade explícita de executar o recurso de software (isto é, a máquina virtual) ou de instalar componentes de software adicionais no recurso de software antes de o preparar. Além do mais, todos estes recursos podem ser realizados com pouca interface na máquina virtual, isto é, sem exigir necessariamente a conexão do usuário, a criação de perfil do usuário, ou congêneres. Ainda adicionalmente, já que, no geral, estes programas e componentes de preparação são genéricos o suficiente para ser usados em uma ampla faixa de recursos, estes programas e componentes de preparação não precisam, necessariamente, ser atualizados toda vez que um recurso de software alvo correspondente passar por uma mudança de versão.

Como exposto, esta capacidade de criar modelos de uma maneira eficiente como esta pode ser muito útil para grandes empresas que desejam instalar recursos de software particularmente customizados ou atualizados em várias estações de computador. Em particular, implementações da presente invenção permitem que tais cópias sejam feitas com menos tempo e esforço do que anteriormente necessário, e permitem que tais cópias sejam instaladas em um ponto particularmente customizado, também, com muito menos tempo e esforço do que anteriormente necessário. Tais vantagens podem ser particularmente proveitosas para duplicar máquinas virtuais, sistemas operacionais e programas de aplicação que podem ser customizados, do ponto de vista de software e/ou de personalização, muitas vezes durante sua vida útil.

A título de exemplo, e sem limitações, tais mídias legíveis por computador podem compreender RAM, ROM, EEPROM, CD-ROM ou outro armazenamento em disco ótico, armazenamento em disco magnético ou outros dispositivos de armazenamento magnético, ou qualquer outra mídia que pode ser usada para portar ou armazenar dispositivo de código de programa desejado na forma de instruções executáveis por computador ou estruturas de dados e que pode ser acessada por um computador de uso geral ou de uso especial. Quando a informação for transferida ou fornecida em uma rede ou em uma outra conexão de comunicações (seja com fios, sem fios ou uma combinação de com fios ou sem fios) em um computador, o computador visualiza apropriadamente a conexão como uma mídia legível por computador. Assim, todas tais conexões são apropriadamente chamadas de uma mídia legível por computador. Combinações dos expostos também devem ser incluídas no escopo da mídia legível por computador.

Instruções executáveis por computador compreendem, por exemplo, instruções e dados que fazem com que um computador de uso geral, computador de uso especial ou dispositivo de processamento de uso especial realizem uma certa função ou grupo de funções. Embora o assunto em questão tenha sido descrito em linguagem específica para recursos estruturais e/ou atos metodológicos, entende-se que o assunto em questão definido nas reivindicações anexas não é necessariamente limitado aos recursos específicos ou atos supradescritos. Em vez disto, os recursos específicos e atos supradescritos são divulgados como formas de exemplo da implementação das reivindicações.

A presente invenção pode ser incorporada em outras formas específicas sem fugir do seu espírito ou das suas características essenciais. As modalidades descritas devem ser consideradas, em todos os aspectos, somente ilustrativas e não restritivas. Portanto, o escopo da invenção é indicado pelas reivindicações anexas, em vez de pela descrição exposta. Todas as mudanças que caem no significado e na faixa de equivalência das reivindicações devem ser abraçadas pelo seu escopo.

Claims

REIVINDICAÇÕES

1. Método para criar um modelo de um recurso de software em um ambiente computadorizado, em que o ambiente computadorizado compreende um ou mais sistemas de computador que hospedam pelo menos uma primeira máquina virtual e compreende um primeiro sistema operacional em que um programa de preparação está em execução, o método caracterizado pelo fato de que compreende:

identificar, pelo programa de preparação, durante a operação do primeiro sistema de operação no ambiente computadorizado, uma primeira instância de um recurso de software instalado, mas não em execução, na primeira máquina virtual em resposta ao recebimento de uma solicitação para criar um modelo do recurso de software, a primeira instância do recurso de software tendo um primeiro conjunto de marcas distintivas;

identificar, pelo programa de preparação, um ou mais ajustes de modelo que identificam pelo menos uma dentre uma ou mais marcas distintivas a ser removidas da primeira instância do recurso de software e uma ou mais marcas distintivas a serem adicionadas à primeira instância do recurso de software;

iniciar, pelo programa de preparação, chamadas de função para customizar a primeira instância do recurso de software de acordo com o um ou mais ajustes de modelo;

redirecionar, por um agente de preparação, as chamadas de função do recurso de software para criar o modelo do recurso de software, em que criar o modelo do recurso de software pelo agente de preparação compreende ainda:

acessar as marcas distintivas para serem pelo menos um dentre removidas e adicionadas para customizar a primeira instância do recurso de software; e pelo menos um dentre adicionar e remover as marcas distintivas na primeira instância do recurso de software em que a primeira instância do recurso de software é agora o modelo criado.
2. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a primeira instância do recurso de software é um sistema operacional da primeira máquina virtual.
3. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a primeira instância do recurso de software é um programa de aplicação instalado no sistema operacional da primeira máquina virtual.
4. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que o agente de preparação é configurado para passar as uma ou mais chamadas de função à terceira instância do recurso de software por meio de um montador de recurso.
5. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que a primeira instância do recurso de software é um arquivo de disco rígido de volume, e em que o montador de recurso é pelo menos um de um montador de unidade rígida de volume e de uma biblioteca de aplicação ou de sistema configurada para prover acesso em um disco físico correspondente.
6. Método, de acordo com a reivindicação 5, caracterizado pelo fato de que o arquivo de

Petição 870180128898, de 11/09/2018, pág. 4/10 disco rígido de volume corresponde à primeira máquina virtual.
7. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que os um ou mais ajustes de modelo compreendem um ajuste de sistema ou de usuário que compreende uma indicação de qualquer um ou mais de nome de computador, nome de usuário, nome da companhia, nome de domínio ou endereço de rede.
8. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que os um ou mais ajustes de modelo compreendem um ajuste de sistema ou de usuário que compreende uma indicação de qualquer um ou mais de um ajuste de economia à luz do dia ou de um ajuste de zona de hora.
9. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que os um ou mais ajustes de modelo compreendem um ajuste de sistema ou de usuário que compreende uma indicação de qualquer um ou mais de uma chave de produto de recurso, de uma versão de software ou de um ajuste de segurança.
10. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que as uma ou mais marcas distintivas customizadas são recebidas de qualquer um de uma mídia de armazenamento ou de interface de rede.
11. Método, de acordo com a reivindicação 1, caracterizado pelo fato de que as uma ou mais marcas distintivas customizadas são recebidas por meio de uma interface de usuário.
12. Método para duplicar um arquivo de máquina virtual em um ambiente computadorizado compreendendo pelo menos uma primeira máquina virtual, uma segunda máquina virtual, uma terceira máquina virtual, um primeiro espaço de armazenamento, um segundo espaço de armazenamento, e um terceiro espaço de armazenamento, o arquivo de máquina virtual e o arquivo de máquina virtual duplicado tendo identidades distinguíveis, o método caracterizado pelo fato de que compreende:

identificar, por um programa de preparação instalado no segundo espaço de armazenamento, durante a operação da segunda máquina virtual no ambiente computadorizado, um arquivo de máquina virtual instalado, mas não em execução, na primeira máquina virtual em resposta ao recebimento de uma indicação do arquivo de máquina virtual, em que a primeira máquina virtual está localizada no primeiro espaço de armazenamento e o arquivo de máquina virtual tem um primeiro conjunto de marcas distintivas customizadas;

receber, pelo agente de preparação instalado no segundo espaço de armazenamento, a identidade do arquivo de máquina virtual;

receber uma ou mais chamadas de função do programa de preparação por meio do agente de preparação, as uma ou mais chamadas de função solicitando pelo menos uma dentre a remoção de uma ou mais marcas distintivas a serem removidas a partir do arquivo de máquina virtual e a solicitação da adição de uma ou mais marcas distintivas a serem adicionadas ao arquivo de máquina virtual;

Petição 870180128898, de 11/09/2018, pág. 5/10 executar as uma ou mais chamadas de função no arquivo de máquina virtual, de maneira tal que pelo menos uma das uma ou mais marcas distintivas a serem removidas sejam removidas na primeira máquina virtual localizada no primeiro espaço de armazenamento e tal que as uma ou mais marcas distintivas a serem adicionadas sejam adicionadas na primeira máquina virtual localizada no 5 primeiro espaço de armazenamento;

criar um modelo do arquivo de máquina virtual tendo um segundo conjunto de marcas distintivas customizadas; e instalar o modelo do arquivo de máquina virtual na terceira máquina virtual localizada no terceiro espaço de armazenamento.

10
13. Método, de acordo com a reivindicação 12, caracterizado pelo fato de que compreende adicionalmente armazenar as uma ou mais marcas distintivas removidas que foram removidas do arquivo de máquina virtual.
14. Método, de acordo com a reivindicação 12, caracterizado pelo fato de que o arquivo de máquina virtual compreende adicionalmente uma primeira e uma segunda atualizações de
15 software.

15. Método, de acordo com a reivindicação 14, caracterizado pelo fato de que as uma ou mais marcas distintivas a serem removidas incluem uma solicitação para remover a segunda atualização de software mas não a primeira atualização de software.