Source: http://www.google.es/patents/US8522228
Timestamp: 2017-09-26 05:48:50
Document Index: 449436542

Matched Legal Cases: ['art 4000', 'art 4000', 'art 4000', 'art 4000', 'art 4000', 'art 4000', 'art 4000']

Patente US8522228 - Updating software on dormant disks - Google Patentes
In a method of updating software on a dormant disk, exposed files are accessed. The exposed files are exposed by mounting the dormant disk. The exposed files are scanned to determine the status of software residing on the dormant disk. The scanning is achieved without requiring booting of the dormant...http://www.google.es/patents/US8522228?utm_source=gb-gplus-sharePatente US8522228 - Updating software on dormant disks
Número de publicación US8522228 B1
Número de solicitud US 11/396,060
También publicado como US8949817
Número de publicación 11396060, 396060, US 8522228 B1, US 8522228B1, US-B1-8522228, US8522228 B1, US8522228B1
Inventores Bich Cau Le, Robert F. Deuel, Sirish Raghuram, Yufeng Zheng
Citas de patentes (28), Otras citas (12), Citada por (5), Clasificaciones (5), Eventos legales (2)
Updating software on dormant disks
US 8522228 B1
In a method of updating software on a dormant disk, exposed files are accessed. The exposed files are exposed by mounting the dormant disk. The exposed files are scanned to determine the status of software residing on the dormant disk. The scanning is achieved without requiring booting of the dormant disk. It is determined whether an update is available for the software residing on the dormant disk.
1. A method of updating software on a dormant disk, said method comprising:
mounting the dormant disk, the mounting includes establishing a logical connection from a server to a file system of the dormant disk through use of a virtual disk driver so as to expose files on the dormant disk to the server;
using the server,
accessing the exposed files;
scanning said exposed files to determine the status of software residing on said dormant disk, said scanning achieved without requiring booting of said dormant disk by utilizing a file system interface of the file system to look up and mount a registry file of the dormant disk;
determining whether an update is available and needed for said software residing on said dormant disk by comparing the status of scanned files with known vulnerabilities cached in a vulnerabilities database; and
applying said update to said software residing on said dormant disk based on the determining without requiring booting of the dormant disk.
generating a notification to indicate said dormant disk is in need of an update.
3. The method of claim 1, wherein said accessing files exposed by mounting said dormant disk comprises: accessing said files exposed by mounting of said dormant disk at a scheduled time.
4. The method of claim 1, wherein said applying said update to said software residing on said dormant disk comprises:
applying said update to said software residing on said dormant disk at a scheduled time.
5. The method of claim 1, wherein said scanning said exposed files to determine the status of software residing on said dormant disk comprises: utilizing a direct scanning approach to scan said software on said dormant disk, wherein said direct scanning approach couples directly to the file system interface associated with said dormant disk.
6. The method of claim 1, wherein said scanning said exposed files to determine the status of software residing on said dormant disk comprises:
utilizing an indirect scanning approach to scan said software on said dormant disk, wherein said indirect scanning approach employs a virtual environment to achieve said scanning of said dormant disk.
7. The method of claim 1, wherein said applying said update to said software residing on said dormant disk comprises:
utilizing a direct updating approach to install an update file on said dormant disk without requiring booting of said dormant disk, wherein said direct updating approach couples directly with the file system interface.
8. The method of claim 1, wherein said applying said update to said software residing on said dormant disk comprises:
utilizing an indirect updating approach to install an update file on said dormant disk without requiring booting of said dormant disk, wherein said indirect updating approach employs a virtual environment to achieve installation of said update file.
9. The method of claim 1, wherein said applying said update to said software residing on said dormant disk comprises:
storing an update file on said dormant disk without requiring booting of said dormant disk, said update file comprising information to install said update to said software residing on said dormant disk; and
causing said update file to be installed upon booting of said dormant disk.
10. The method of claim 9, storing an update file on said dormant disk comprises:
utilizing a direct updating approach to store said update file on said dormant disk, wherein said direct updating approach couples directly withthe file system interface associated with said dormant disk.
11. The method of claim 9, wherein said storing an update file on said dormant disk comprises:
utilizing an indirect updating approach to store said update file on said dormant disk, wherein said indirect updating approach employs a virtual environment to achieve storing of said update file.
12. A non-transitory computer useable storage medium having computer-readable program code embodied therein for causing a computer program system to perform a method of updating software on a dormant disk, said method comprising:
13. The non-transitory computer useable storage medium of claim 12, further comprising:
14. The non-transitory computer useable storage medium of claim 12, wherein said accessing files exposed by mounting of said dormant disk comprises:
accessing said files exposed by mounting of said dormant disk at a scheduled time.
15. The non-transitory computer useable storage medium of claim 12, wherein said applying said update to said software residing on said dormant disk comprises:
16. The non-transitory computer useable storage medium of claim 12, wherein said scanning said exposed files to determine the status of software residing on said dormant disk comprises:
utilizing a direct scanning approach to scan said software on said dormant disk, wherein said direct scanning approach couples directly to the file system interface associated with said dormant disk.
17. The non-transitory computer useable storage medium of claim 12, wherein said scanning said exposed files to determine the status of software residing on said dormant disk comprises:
18. The non-transitory computer useable storage medium of claim 12, wherein said applying said update to said software residing on said dormant disk comprises:
19. The non-transitory computer useable storage medium of claim 12, wherein said applying said update to said software residing on said dormant disk comprises:
20. The non-transitory computer useable storage medium of claim 12, wherein said applying said update to said software residing on said dormant disk comprises:
21. The non-transitory computer useable storage medium of claim 20, storing an update file on said dormant disk comprises:
utilizing a direct updating approach to store said update file on said dormant disk, wherein said direct updating approach couples directly with the file system interface associated with said dormant disk.
22. The non-transitory computer useable storage medium of claim 20, wherein said storing an update file on said dormant disk comprises:
23. A system for updating software on a dormant disk, said system comprising:
a controller configured to couple to a file system interface, said controller for coordinating system actions performed on said dormant disk;
a utility package coupled to said controller, said utility package for performing tasks related to said dormant disk, the utility package includes a disk mount manager, said disk mount manager for mounting and unmounting said dormant disk, the mounting includes establishing a logical connection from a server to a file system of the dormant disk through use of a virtual disk driver so as to expose files on the dormant disk to the server; and
a software repository coupled to said controller, wherein components of said software repository are configured to engage directly with said file system interface to perform scanning and updating operations on said dormant disk wherein the scanning and updating operations comprise:
scanning said exposed files to determine the status of software residing on said dormant disk, said scanning achieved without requiring booting of said dormant disk by utilizing said file system interface to look up and mount a registry file of the dormant disk;
24. The system of claim 23, wherein said controller comprises:
a scheduler for scheduling tasks related to scanning and updating said software residing on said dormant disk;
a control interface, said control interface providing set up and management interfaces for interacting with said system for updating software on said dormant disk; and
a discoverer, said discoverer configured for interfacing with an existing infrastructure and scanning a computing environment to enumerate devices to said controller within said computing environment.
25. The system of claim 23, wherein said utility package comprises:
a configuration database, said configuration database for providing access to schedule information and configuration information.
26. The system of claim 23, wherein said utility package comprises:
a software detector, said software detector for detecting software configurations on said dormant disk.
27. The system of claim 23, wherein said utility package comprises:
a script creator, said script creator for creating an executable script for storing on said dormant disk.
28. A system for updating software on a dormant disk, said system comprising:
a controller configured to couple to a file system interface, said controller for system actions performed on said dormant disk;
a utility package configured to couple to said controller, said utility package for performing tasks related to said dormant disk, the utility package includes a disk mount manager, said disk mount manager for mounting and unmounting said dormant disk, the mounting includes establishing a logical connection from a server to a file system of the dormant disk through use of a virtual disk driver so as to expose files on the dormant disk to the server; and
a virtual environment configured to couple between said file system interface and a software repository, wherein said virtual environment is further configured to interact with components of said software repository to achieve scanning and updating operations on said dormant disk wherein the scanning and updating operations comprise:
29. The system of claim 28, wherein said virtual environment comprises:
a redirector configured for redirecting system calls from said software repository; and an operating system interface emulator configured for interacting with said software repository, said operating system interface emulator further configured for emulating responses to said system calls and interfacing with said dormant disk.
The advantages of virtual machine technology have become widely recognized. Among these advantages is the ability to run multiple virtual machines on a single host platform. This can make better use of the capacity of the hardware, while still ensuring that each user enjoys the features of a “complete” computer. An additional benefit of virtualization, in some implementations, is greater security. For instance, virtualization increases security by isolating potentially unstable or unsafe software so that it cannot adversely affect the hardware state or system files required for running the physical (as opposed to virtual) hardware.
As is well known in the field of computer science, a virtual machine (VM) is a software abstraction, or “virtualization,” of an actual physical computer system. FIG. 1 shows one possible arrangement of a computer system 700 that implements virtualization. FIG. 1 shows a plurality of virtual machines (VMs) 200-200 n and a plurality of virtual machine monitors (VMMs) 300-300 n, coupled to an exemplary system hardware platform 100. An optional kernel 600 (used in non-hosted systems) is also shown. Additionally, an operating system 420, with applications 430, is shown with optional couplings to system hardware 100 and VMMs 300-300 n.
To permit computer systems to scale to larger numbers of concurrent threads, systems with multiple CPUs—physical or logical, or a combination—have been developed. One example is a symmetric multi-processor (SMP) system, which is available as an extension of the PC platform and from other vendors. Essentially, an SMP system is a hardware platform that connects multiple processors to a shared main memory and shared I/O devices. Yet another configuration is found in a so-called “multi-core” architecture, in which more than one physical CPU is fabricated on a single chip, with its own set of functional units (such as a floating-point unit and an arithmetic/logic unit ALU), and can execute threads independently; multi-core processors typically share only very limited resources, for example, some cache. Still another technique that provides for simultaneous execution of multiple threads is referred to as “simultaneous multi-threading,” in which more than one logical CPU (hardware thread) operates simultaneously on a single chip, but in which the logical CPUs flexibly share not only one or more caches, but also some functional unit(s) and sometimes also the translation lookaside buffer (TLB).
If VM 200 is properly designed, applications 260 running on VM 200 will function as they would if run on a “real” computer. This occurs even though the applications are running at least partially indirectly, that is via the guest OS 220 and virtual processor(s) (210 a-210 m). Executable files will be accessed by guest OS 220 from virtual disk 240 or virtual memory 230, which will be portions of the actual physical disk 140 or physical memory 130 allocated to VM 200. Applications may be installed within VM 200 in a conventional manner, using guest OS 220. Guest OS 220 retrieves files required for the execution of such installed applications from virtual disk 240 in a conventional manner.
As FIG. 1 illustrates, a virtualized computer system may (and usually will) have more than one VM (200-200 n), each of which may be running on its own VMM (300-300 n). The various virtualized hardware components in VM 200, such as virtual CPU 210, virtual memory 230, virtual disk 240, and virtual device(s) 270, are shown as being part of VM 200 for the sake of conceptual simplicity. In actuality, these “components” are often implemented as software device emulators 330 included in VMM 300. One advantage of such an arrangement is that VMM 300 may (but need not) be set up to expose “generic” devices. Exposing generic devices facilitates, for example, migration of VM 200 from one hardware platform to another.
In addition to the distinction between full and partial virtualization, two configurations of intermediate system-level software layer(s), “hosted” and “non-hosted,” are in general use. In a hosted virtualized computer system, an existing, general-purpose operating system 420 forms a “host” OS that is used to perform certain input/output (I/O) operations, alongside and sometimes at the request and direction of the VMM 300. The optional coupling between OS 420 and VMM 300 provides one conduit for such communication. In a hosted system, optional kernel 600 is not utilized, and VMM 300 is instead coupled directly to system hardware 100. The host OS in OS 420 and VMM 300 are both able to directly access at least some of the same system hardware resources 100, with conflicts being avoided by a context-switching mechanism. The Workstation product of VMware, Inc., of Palo Alto, Calif., is an example of a hosted, virtualized computer system, which is also explained in U.S. Pat. No. 6,496,847 (Bugnion, et al., “System and Method for Virtualizing Computer Systems,” 17 Dec. 2002).
In a non-hosted system, VMM 300 is deployed on top of an optional software layer called a “hypervisor,” or kernel 600. Kernel 600 is constructed specifically to provide efficient support for VM 300. Compared with a hosted system in which VMM 300 runs directly on the hardware platform, use of kernel 600 offers greater modularity. Use of kernel 600 also facilitates provision of services, such as resource management, that extend across multiple VMs. As contrasted with a hosted environment where kernel 600 is not used, a non-hosted environment may offer greater performance because kernel 600 can be co-developed with VMM 300. Co-development enables optimization of the characteristics of a workload consisting primarily of VMs/VMMs. Additionally, in a non-hosted system, operating system 420 does not utilize the optional coupling shown between OS 420 and VMM 300.
As a generalization, some form of “virtualization software” executes between system hardware 100 and one or more VMs 200. The virtualization software uses the resources of the system hardware 100, and emulates virtual system hardware 201, on which guest system software 202 and guest applications 260 appear to execute. Thus, virtualization software typically comprises one or more device emulators 330 that either include or execute in conjunction with some form of system software for accessing and controlling the system hardware 100. As previously described, the virtualization software may provide full virtualization or partial virtualization. In the non-hosted virtual computer system, the virtualization software primarily comprises VMM 300 and may include some portions of kernel 600. Similarly, in the hosted virtual computer system, the virtualization software primarily comprises VMM 300. Various other configurations for virtualization software and system software are also possible.
Independent of virtualizing the entire operating system of a computer is the concept of virtualizing only the files and storage devices for a computer. Only a few years ago many computers were required to have local disk storage. However, today it is also possible to boot a physical computer or a virtual machine from a virtual disk or from an image that is stored on a server. The increased use of physical computers and of virtual machines, which allow easy proliferation of numerous virtual disks, has lead to a dramatic increase in the number of disks in use. Likewise, many companies and individuals use templates, images, or backups that are static and then applied to machines for booting machines or to configuring machines. Additionally, physical and virtual computers may still use local or remote physical disks, or other physical or logical storage elements that are decoupled from the physical computer via a storage area network (SAN) or internet small computer system interface (iSCSI). Thus, the concept of “disks” includes, but is not limited to, real disks, virtual disks, logical disks, suspended disks, disk snapshots, images, templates, storage area networks, local storage, remote storage, and backup storage.
In an environment that allows so many disk configurations to be created so easily, many of the configurations will often go unused or dormant for some extended period of time such as days, weeks, or longer. A “dormant disk” can be defined as a disk that is not in use. Essentially any file that can be booted or booted from can be considered a dormant disk when it is not in use. A dormant disk typically becomes active when it is booted. However, a dormant disk can become active when it or its contents is attached to a computer (real or virtual) and the computer is powered on.
When unused, dormant disks often go out-of-date, because they do not incorporate the latest updates, such as software and virus related revisions and patches. Starting up such a dormant disk without the latest updates risks exposure to viruses and worms. Additionally, starting up such a dormant disk without the latest updates can cause the computer to attempt to use software which is out-of-date. Even if updates are installed immediately after booting the previously dormant disk, there is still a window of risk of virus infection, attack, or software malfunction. That is, the risks associated with out-of-date disks exist until the out-of-date disk is brought up-to-date. Additionally, a rapid increase in the number of dormant disks is occurring due in part to the trend towards separating storage from computing resources, the rise of “disk imaging” software, and the growing popularity of virtual machine technology, all of which contribute to a proliferation of dormant disks. This increase in dormant disks simply expands the previously described risks.
These existing solutions are unable to update a dormant disk since, by definition, no computer has booted from a dormant disk. Instead, these existing “brute-force” methods rely on first booting the dormant disk using a computer to make the disk active. Once the disk is active, the existing scan and/or update processes can then be run. However, booting a disk to perform scans and/or updates creates several problems.
In a method of updating software on a dormant disk, exposed files are accessed. The exposed files are exposed by mounting the dormant disk. The exposed files are scanned to determine the status of software residing on the dormant disk. The scanning is achieved without requiring booting of the dormant disk. It is determined whether an update is available for the software residing on the dormant disk, such that, if an update is available, embodiments of the present invention provide various methods for applying the update to the dormant disk in ways that do not require booting of the dormant disk.
The accompanying figures, which are incorporated in and form a part of this specification, illustrate embodiments of the technology for updating software on dormant disks and, together with the description, serve to explain principles discussed below.
Reference will now be made in detail to embodiments of the present technology for updating software on dormant disks, examples of which are illustrated in the accompanying drawings. While the technology for updating software on dormant disks will be described in conjunction with various embodiments, it will be understood that they are not intended to limit the present invention to these embodiments. On the contrary, the technology for updating software on dormant disks is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope the various embodiments as defined by the appended claims. Furthermore, in the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, the present invention may be practiced without these specific details. In other instances, well known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present embodiments.
Unless specifically stated otherwise as apparent from the following discussions, it is appreciated that throughout the present detailed description, discussions utilizing terms such as “accessing”, “scanning”, “determining”, “applying”, “generating”, “utilizing”, “storing”, “causing”, “coupling”, “employing”, “performing”, “providing”, “interfacing”, “detecting”, “creating”, “coordinating”, “scanning”, “scheduling”, and “updating”, or the like, refer to the actions and processes of a computer system, or similar electronic computing device. The computer system or similar electronic computing device manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission, or display devices. The present invention is also well suited to the use of other computer systems such as, for example, optical and mechanical computers. Additionally, it should be understood that in embodiments of the invention, one or more of the steps can be performed manually.
General Description of Updating Software on Dormant Disks
As an overview, one embodiment of the present invention is directed toward a method of updating software on dormant disks. In one embodiment of this method, a dormant disk is mounted and the files exposed by mounting the disk are accessed. The exposed files on the dormant disk are scanned to determine the status of software residing on the dormant disk. The scanning is done without requiring the booting of the dormant disk. The scanning is performed utilizing either a direct or an indirect scanning approach, as described in embodiments of the present invention. It is determined whether an update is available for the software residing on the dormant disk, such as for software that is out-of-date, infected, in need of installation, or in need of a virus patch. In one embodiment, a notification is generated to indicate that the dormant disk is in need of an update.
With reference now to FIG. 2, a diagram of one embodiment of the present system 2000 for updating software on dormant disks is shown. The following discussion will begin with a description of the physical structure of the present system 2000 for updating software on dormant disks. This discussion will then be followed with a description of the operation of specific components of system 2000. Discussion will then proceed to descriptions of exemplary methods for using system 2000 to scan and update software on a dormant disk.
With respect to the physical structure, system 2000 is comprised of a controller 2005, a utility package 2010, a vulnerabilities database 2045, a direct software repository 2040, a virtual environment 2050, and a bus 2001. Though shown in FIG. 2, direct software repository 2050 and vulnerabilities database 2045 are only necessary in a system 2000 that is configured to utilize a direct scanning and/or updating approach. The direct scanning and/or updating approach will be described in detail below. Similarly, though shown in FIG. 2, virtual environment 2050 is only necessary in a system 2000 that is configured to utilize an indirect scanning and/or updating approach. The indirect scanning and/or updating approach will be described in detail below. Bus 2001 couples controller 2005 to utility package 2010, direct software repository 2040, and virtual environment 2050. Bus 2001 also provides a coupling to various components of a computing environment that system 2000 is configured to couple with, such as: existing infrastructure management 2035, file system interface 2070, and server operating system 2075.
FIG. 3 is a block diagram of an exemplary controller 2005 used in a system 2000 (FIG. 2) for updating software on dormant disks, according to one embodiment of the present 25 invention. In one embodiment, as shown in FIG. 3, controller 2005 is comprised of a control interface 3006, a discoverer 3007, and a scheduler 3008, all of which are coupled to bus 2001. Controller 2005 is a central component of system 2000 (FIG. 2). Controller 2005 is configured to couple to file system interface 2070. Controller 2005 is for coordinating system actions performed on, or in conjunction with, dormant disk 2080 (FIG. 2). Controller 2005 30 coordinates actions such as setup, scheduling, scanning, and updating tasks performed by system 2000.
Exemplary Utility Package
Referring again to FIG. 2, utility package 2010 is coupled to controller 2005 and provides utilities for performing tasks related to a dormant disk, such as dormant disk 2080. In one embodiment of the present invention, utility package 2010 is comprised of a configuration database 2015 utility, a script creator 2020 utility, a software detector 2025 utility, and a disk mount manager 2030 utility. In other embodiments of the present invention, utility package 2010 is comprised of more utilities or less utilities than shown in FIG. 2.
Software detector 2025 detects operating systems by inspecting well-known data blocks and/or files on dormant disk 2080 where this information is stored. For example, a disk containing an operating system from Microsoft Corporation typically has a volume containing a “boot.ini” file, which software detector 2025 interacts with. The “boot.ini” file contains a list of volumes and operating systems. Each stored operating system specifies whether it is the default operating system, the volume on which it resides, and the location of its system folder within that volume. In this example, software detector 2025 gathers detailed information about the operating system by inspecting files within the system folder. For example, software detector 2025 determines the type and version of the operating system from the existence, name, and version of certain known files.
The following discussion sets forth in detail the operation of the present technology for updating software on dormant disks. With reference to FIG. 4, flowchart 4000 illustrates a flow diagram of a method for updating software on dormant computer disks, according to one embodiment of the present invention. Flowchart 4000 includes processes that, in various embodiments, are carried out by a processor under the control of computer-readable and computer-executable instructions. The computer-readable and computer-executable instructions reside, for example, in data storage features such as a portable diskette, a computer usable volatile memory 8008, computer usable non-volatile memory 8010, and/or data storage unit 8012 of FIG. 8. The computer-readable and computer-executable instructions are used to control or operate in conjunction with, for example, processor 8006A and/or processors 8006A, 8006B, and 8006C of FIG. 8. Although specific steps are disclosed in flowchart 4000, such steps are exemplary. That is, embodiments are well suited to performing various other steps or variations of the steps recited in flowchart 4000. It is appreciated that the steps in flowchart 4000 may be performed in an order different than presented, and that not all of the steps in flow chart 4000 may be performed.
Direct Approach Direct Approach Immediate Scan and Update Methods
In many embodiments, scanning and/or updating of dormant disk 2080 is performed immediately upon direction by controller 2005 through the use of the direct approach described below. In the direct approach, scanning, as described at 4010 of flowchart 4000 is performed by software residing in direct software repository 2040.
In 4010 of FIG. 4, embodiments in accordance with the present perform scanning of files on dormant disk 2080 in a specialized manner when utilizing a direct scanning approach. When scanning an active disk, a normal scanner performs scanning operations by issuing any type of system call needed, such as general purpose system calls or file system system calls. However, many general purpose system calls cannot be answered by dormant disk 2080, and thus a direct scanner only makes file system system calls that can easily be redirected to dormant disk 2080. To execute this restricted set of system calls, direct scanner 5010 couples to file system interface 2070, which is exposed by the volume mounting process. Direct scanner 5010 then directly scans the appropriate exposed file(s) on dormant disk 2080 to retrieve the information needed. For instance, to find the version number of a piece of software on an active disk, a normal scanner would simply make a system call, such as API call “GetVersion” to the operating system running on the active disk. However, when interacting with dormant disk 2080 this method of scanning would require booting the dormant disk. In embodiments of the present invention, instead of booting dormant disk 2080 to find a version number of a piece of software, direct scanner 5010 utilizes file system interface 2070 to look up the registry file on dormant disk 2080. Direct scanner 5010 will then issue a command to controller 2005 to mount the registry file. Direct scanner 5010 will then determine the version number of a piece of software on dormant disk 2080 by scanning the mounted registry file. This specialized nature of interaction with dormant disk 2080 allows direct scanner 5010 to achieve scanning software residing on dormant disk 2080 without requiring booting of dormant disk 2080. In other words, the exposed software files on dormant disk 2080 are scanned via the direct approach while dormant disk 2080 remains in a dormant state.
Direct Approach Self-Update Method
In another embodiment of 4020 of FIG. 4, referred to as a self-update method, direct updater 5020 stores an update file on dormant disk 2080. The update file is then installed on dormant disk 2080 at some later time, when dormant disk 2080 is next booted. The self-update method requires very little intrusion onto dormant disk 2080. The self-update method also minimizes exposure of dormant disk 2080 to vulnerability upon booting, because updates begin installing immediately without requiring a connection to the internet. The update file comprises information needed to install an identified update to software residing on dormant disk 2080. The update file is stored on dormant disk 2080 with direction from controller 2005, and the storing is done without requiring booting of dormant disk 2080. In other words, the update file is stored on dormant disk 2080 while dormant disk 2080 remains in a dormant state. Controller 2005 also directs script creator 2020 to create a self executing control script (as previously described). The script is also stored on dormant disk 2080 with direction from controller 2005. The script is also stored on dormant disk 2080 while dormant disk 2080 remains in a dormant state. The script automatically runs the next time dormant disk 2080 is booted. When the script runs, it executes instructions that cause the update file to be installed on dormant disk 2080. In some embodiments, the stored update file is self-executing. In other embodiments, the script utilizes information in the stored update file to perform the required update.
Indirect Approach Indirect Approach Immediate Scan and Update Methods
Referring again to 4005 of FIG. 4, embodiments in accordance with the present invention access exposed files, the files being exposed by mounting of a dormant disk, such as disk 2080. This accessing has been previously described, and is performed in the same manner in the indirect approach, with an exception being that when system 2000 (FIG. 2) is configured for utilizing an indirect approach, virtual environment 2050 is also capable of accessing exposed files on dormant disk 2080. In many embodiments, scanning and/or updating of dormant disk 2080 is performed immediately upon direction by controller 2005 through the use of the indirect approach described below.
Indirect Approach Self-Update Method
According to another embodiment of 4020 of FIG. 4, referred to as a self-update method, virtual environment 2050 receives an update file from legacy updater 7020. The update file comprises information needed to install an identified update to software residing on dormant disk 2080. Virtual environment 2050 is employed to carry out operations, with direction from controller 2005 (FIG. 2), to translate (if necessary) and store the update file on dormant disk 2080. The storing is done without requiring booting of dormant disk 2080. In other words, this update file is stored on dormant disk 2080 while dormant disk 2080 remains in a dormant state. Controller 2005 also directs script creator 2020 to create a self-executing control script (as previously described). The script is also stored on dormant disk 2080 with direction from controller 2005. The script is also stored on dormant disk 2080 while dormant disk 2080 remains in a dormant state. The script automatically runs the next time dormant disk 2080 is booted. When the script runs, it executes instructions that cause the update file to be installed on dormant disk 2080. In some embodiments, the stored update file is self-executing. In other embodiments, the script utilizes information in the stored update file to perform the required update. Thus, the update file is then installed on dormant disk 2080 at some later time, when dormant disk 2080 is next booted. The self-update method requires very little intrusion onto dormant disk 2080. The self-update method also minimizes exposure of dormant disk 2080 to vulnerability upon booting, because updates begin installing immediately without requiring a connection to the internet.
Indirect Approach Operation of an Exemplary Virtual Environment in a System for Updating Software on Dormant Disks
Virtual environment 2050 is central to the indirect approach for scanning and updating software on a dormant disk. A detailed discussion of the operation of virtual environment 2050 within system 2000 is therefore warranted.
Virtual environment 2050 is a program or code module that virtualizes the local or remote operating software interface that is expected by a legacy scanner, legacy updater, or combined legacy scanner/updater. As shown in FIG. 6, virtual environment 2050 is comprised of an operating system interface emulator 6005 and a re-director 6010, which are coupled to one another. Operating system interface emulator 6005 and re-director 6010 are coupled to legacy software repository 2055. Operating system interface emulator 6005 is also coupled to file system interface 2070 via bus 2001. Virtual environment 2050 allows system 2000 to trick legacy scanning and/or legacy updating software into “thinking” that it is communicating with an operating system booted from dormant disk 2080. In reality, the legacy scanning and/or legacy updating software runs on operating system interface emulator 6005, which in turn runs on server operating system 2075 (FIG. 2).
For example, consider what happens when legacy scanner-updater 7005 wishes to call a hypothetical OpenFile procedure on a file with path “/etc/hosts” within a volume of dormant disk 2080 that contains a Unix-family operating system. This path identifies the file hosts in the directory “/etc”. This path would be correct if legacy scanner 7010 were communicating with an active operating system booted from dormant disk 2080. However, since disk 2080 is dormant, its operating system is also dormant, and therefore not active. For purposes of this example, suppose disk mount manager 2030 has mounted the volume of dormant disk 2080 onto mount point “/dormant/100/” in the file name space of server operating system 2075. When operating system interface emulator 6005 of virtual environment 2050 receives the OpenFile (“kW/hosts”) request, it translates it to OpenFile (“/dormant/100/etc/hosts”). Operating system interface emulator 6005 then forwards the translated request to the server operating system 2075 through its file system interface 2070. The net effect of this interposition of virtual environment 2050 is that legacy scanner 7005 is indirectly allowed to open the file it actually desires. Without the path translation, the forwarded OpenFile (“/etc/hosts”) system call would cause legacy scanner-updater 7005 to open a non-existent file, or worse, the “/etc/hosts” file of server operating system 2075.
A legacy scanner 7010 or legacy updater 7020 often calls procedures for obtaining configuration information about an operating system and installed applications. For instance, in the Windows family of operating systems, a legacy scanner 7010 can call “GetVersion( )” to obtain the major and minor version numbers of the operating system. Under normal circumstances, with an active disk, the operating system has its own version numbers cached in memory and simply returns them to the calling program. However, when system 2000 runs legacy scanner 7010 in virtual environment 2050 to scan dormant disk 2080, the primary operating system of the dormant disk 2080 does not exist anywhere in memory.
As previously indicated, certain system calls made by a software tool in legacy software repository 2055 can be forwarded to server operating system 2075 without any translation. For example, a legacy updater 7020 interacting with a Windows-family operating system can call “GetSystemTime” to query the current date. A system call such as this can be safely forwarded, without translation, through virtual environment 2050, and on to server operating system 2075. This is because the concept of current time is universal and is therefore independent of the operating system reporting it. Likewise, other similar system calls can generally be safely forwarded without translation.
For purposes of simplicity, the components and methods utilized in the direct approach and indirect approach have been described separately. However, it is appreciated that numerous combinations of the separately described direct and indirect approaches are anticipated. For instance, one embodiment of the present invention utilizes a direct scanning approach. An indirect updating approach is then utilized to store an update file on a dormant disk. A self executing script is also stored on the disk. The dormant disk then performs a self-update immediately after it is next booted. Thus, such an embodiment exemplifies a combination of direct scanning, indirect updating, and a self-executing script. It should be understood that various other combination of approaches in accordance with the present invention can be utilized.
With reference now to FIG. 8, portions of the present invention are composed of computer-readable and computer-executable instructions that reside, for example, in computer-usable media of a computer system. That is, FIG. 8 illustrates one example of a type of a computer that can be used to implement embodiments of the present invention, which are discussed below. FIG. 8 illustrates an exemplary computer system 8000 that can be implemented from physical components, virtual components, or some combination thereof. It is appreciated that system 8000 of FIG. 8 is exemplary only and that the present invention can operate on or within a number of different computer systems including general purpose networked computer systems, embedded computer systems, routers, switches, server devices, client devices, various intermediate devices/nodes, stand alone computer systems, physical computer systems, virtual computer systems, and the like.
Computer system 8000 of FIG. 8 is well adapted to having peripheral computer readable and usable media 8002 such as, for example, a virtual disk or a storage medium such as a floppy disk, a compact disc and the like coupled thereto. System 8000 of FIG. 8 includes an address/data bus 8004 for communicating information, and a processor 8006A coupled to bus 8004 for processing information and instructions. As depicted in FIG. 8, system 8000 is also well suited to a multiprocessor environment in which a plurality of processors 8006A, 8006B, and 8006C are present. Conversely, system 8000 is also well suited to having a single processor such as, for example, processor 8006A. Processors 8006A, 8006B, and 8006C may be any of various types of microprocessors.
US6289397 * 4 Jun 1999 11 Sep 2001 Teac Corporation Disk drive or like peripheral storage device adapted for firmware upgrading, self-testing, etc.
US6647481 * 31 Ene 2002 11 Nov 2003 Western Digital Ventures, Inc. Method for accessing data storage locations having addresses within a hidden logical address range
US6996817 11 Dic 2002 7 Feb 2006 Valve Corporation Method and system for upgrading and rolling back versions
US7003767 2 Oct 2001 21 Feb 2006 International Business Machines Corp. System and method for remotely updating software applications
US7051327 8 May 2001 23 May 2006 Gateway Inc. System for providing data backup and restore with updated version by creating data package based upon configuration data application data and user response to suggestion
US7155462 1 Feb 2002 26 Dic 2006 Microsoft Corporation Method and apparatus enabling migration of clients to a specific version of a server-hosted application, where multiple software versions of the server-hosted application are installed on a network
US7155710 * 8 Jun 2001 26 Dic 2006 Igt Method and apparatus for gaming device software configuration
US7165158 * 17 Ago 2005 16 Ene 2007 Hitachi, Ltd. System and method for migrating a replication system
US7216343 20 Sep 2002 8 May 2007 International Business Machines Corporation Method and apparatus for automatic updating and testing of software
US7340486 * 10 Oct 2002 4 Mar 2008 Network Appliance, Inc. System and method for file system snapshot of a virtual logical disk
US7401332 9 Ene 2003 15 Jul 2008 International Business Machines Corporation System and apparatus for eliminating user interaction during hardware configuration at system boot
US7516450 23 Sep 2003 7 Abr 2009 Ricoh Company, Ltd. Remote management system, intermediary apparatus therefor, and method of updating software in the intermediary apparatus
US7529903 5 Jul 2005 5 May 2009 International Business Machines Corporation Systems and methods for memory migration
US7552431 31 Ago 2004 23 Jun 2009 Microsoft Corporation Multiple patching in a single installation transaction
US7581217 7 Ene 2005 25 Ago 2009 Microsoft Corporation Dynamic software update
US7840723 * 28 Feb 2005 23 Nov 2010 Symantec Operating Corporation System and method for maintaining and accessing information regarding virtual storage devices
US20040060044 * 20 Sep 2002 25 Mar 2004 International Business Machines Corporation Method and apparatus for automatic updating and testing of software
US20060005189 * 30 Jun 2004 5 Ene 2006 Microsoft Corporation Systems and methods for voluntary migration of a virtual machine between hosts with common storage connectivity
US20070006214 * 20 Jun 2005 4 Ene 2007 Dubal Scott P Updating machines while disconnected from an update source
1 Amendment to Final Rejection Filed on Mar. 4, 2010 for U.S. Appl. No. 11/395,431, filed Mar. 31, 2006.
2 Amendment to Final Rejection Filed on May 18, 2010 for U.S. Appl. No. 11/395,431, filed Mar. 31, 2006.
3 Amendment to Non-Final Rejection Filed on Oct. 1, 2009 for U.S. Appl. No. 11/395,431, filed Mar. 31, 2006.
4 Amendment to Non-Final Rejection Filed on Oct. 22, 2009 for U.S. Appl. No. 11/396,060, filed Mar. 31, 2006.
5 Biveinis et al., "Towards Efficient Main Memory User for Optimum Tree Index update," ACM PVLDB, 2008, pp. 1617-1622.
6 Chlebus et al., "Cooperative Asynchronous Update of Shared Memory," ACM STOC, 2005, pp. 733-739.
7 Dutta et al., "Storm an Approach to Database Storage Management in Clustered Storage Environments," IEEE, CCGrid, 2007, pp. 1-8.
8 Final Rejection Mailed on Feb. 22, 2010 for U.S. Appl. No. 11/396,060, filed Mar. 31, 2006.
9 Final Rejection Mailed on Jan. 6, 2010 for U.S. Appl. No. 11/395,431, filed Mar. 31, 2006.
10 Graefe, "Implementing Sorting in Database Systems," ACM Computing Surveys, 2006, vol. 38, Article 10, pp. 1-37.
11 Non-Final Rejection Mailed on Jul. 20, 2009 for U.S. Appl. No. 11/395,431, filed Mar. 31, 2006.
12 Non-Final Rejection Mailed on Sep. 8, 2009 for U.S. Appl. No. 11/396,060, filed Mar. 31, 2006.
US8819655 * 17 Sep 2007 26 Ago 2014 Symantec Corporation Systems and methods for computer program update protection
US9063810 * 8 Ago 2011 23 Jun 2015 Ricoh Company, Ltd. Information processing apparatus and information processing system
US9319274 * 29 Mar 2012 19 Abr 2016 Emc Corporation Method and system for dynamic provisioning using server dormant mode for virtual server dormancy
US9672027 15 Abr 2015 6 Jun 2017 Ricoh Company, Ltd. Information processing apparatus and information processing system
US20130139142 * 8 Ago 2011 30 May 2013 Ricoh Company, Ltd. Information processing apparatus and information processing system
Clasificación de EE.UU. 717/168, 717/171
Clasificación cooperativa G06F8/61, G06F8/65
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LE, BICH CAU;DEUEL, ROBERT FREDERICK;RAGHURAM, SIRISH;AND OTHERS;SIGNING DATES FROM 20060606 TO 20060614;REEL/FRAME:018102/0104