Management of multiple software images with relocation of boot blocks

A method, system and computer program product for managing multiple software images in a data processing entity. At least part of the memory blocks of each of the software images is stored into a corresponding image portion of a mass memory. A current software image stored in a current image is selected. The memory blocks stored in boot locations of the current software image are relocated to a relocation portion of the mass memory. The boot blocks of the current software image are copied into the corresponding boot location. The data processing entity is booted from the boot blocks of the current software image in the corresponding boot locations and each request to access a selected memory block of the current software image by the access function is served.

PRIORITY

The present application claims priority to European Patent Application No. 10194866.9, filed on 14 Dec. 2010, and all the benefits accruing therefrom under 35 U.S.C. §119, the contents of which in its entirety are herein incorporated by reference.

BACKGROUND

The present invention relates to data processing, and more particularly, to the management of software images.

Generally speaking, a software image is a structure that includes software modules residing on a computer (for example, its operating system, application programs, and/or data).

In some cases, it may be desirable to have multiple operating systems available on the same computer. For example, this may be useful to run programs that require different operating systems, or to test new operating systems or new versions thereof.

For this purpose, it is possible to exploit a multi-boot technique. The multi-boot technique allows installing multiple operating systems on the computer, with the possibility of choosing which one to boot when the computer is started. The desired result is achieved by splitting a hard disk of the computer into multiple partitions, each one defining a logical disk storing a corresponding operating system. The computer boots from a primary partition, which includes a boot loader that allows selecting the actual operating system to be started. Alternatively, it is possible to provide a boot partition with a primary boot loader that is simply used to select the desired operating system; the primary boot loader then invokes a secondary boot loader of the selected operating system for its starting.

However, the multi-boot technique is quite rigid, since the partitions of the hard disk are to be defined in advance. In any case, once the selected operating system has been started it has the entire control of the whole hard disk; therefore, the selected operating system may access the other partitions as well (with the risk of damaging them).

Alternatively, the same result may also be achieved by exploiting a virtualization technique. In this case, a hypervisor is installed on the computer. The hypervisor implements a virtualization layer, which emulates multiple virtual machines each one consisting of an abstract environment giving the appearance of a physical computer (which the virtual machine has sole control of). In this way, it is possible to have different operating systems running independently (even at the same time) on corresponding virtual machines.

However, the virtualization technique requires the installation of a complex infrastructure to manage the virtual machines. Moreover, this involves a performance degradation of the computer (since the operating systems do not run natively on the computer any longer).

U.S. Patent Application No. 2009/0193245, the entire disclosure of which is herein incorporated by reference in its entirety, also discloses a method for converting a multi-boot computer into virtual machines. For this purpose, a boot record of the computer is configured to load a hosting operating system that manages the virtual machines. The virtual machines are generated from the corresponding boot images by a converter, which detects and applies the same configurations, and resolves any conflict that may be caused by the concurrent run of the virtual machines. As above, this requires the installation of a virtualization layer (implemented by the hosting operating system); moreover, the operating systems again run in a virtualized environment (provided by the hosting operating system) with corresponding performance degradation.

Another common need is that of making backup copies of the software image of a computer. For example, this may be useful to restore the content of the computer in case of a malfunction.

For this purpose, it is possible to take a snapshot of the software image (i.e., a backup copy thereof in a consistent state at a particular point of time) and the snapshot may be saved onto a backup disk or a backup server. In this way, it is possible to restore the snapshot by re-installing it onto the computer from the backup disk or the back server. However, the process of restoring the snapshot is very slow. In addition, the use of the backup server involves a high consumption of network resources, and moreover, a network connection with the backup server is required to restore the snapshot from it. Alternatively, it is possible to boot the computer remotely from the snapshot on the backup server. However, in this case the computer has to be always connected to the backup server for its operation. In any case, the operation of the computer over the network will result in a degradation of its performance.

SUMMARY

According to exemplary embodiments, a method, apparatus, and computer program product are provided for managing multiple software images in a data processing entity that includes a mass memory with a plurality of memory locations, each of the memory locations having a corresponding memory address within the mass memory, each of the software images including a plurality of memory blocks, each of the memory blocks having a corresponding image address within the software image, which include storing at least part of the memory blocks of each of the software images into a corresponding image portion of the mass memory, each of the memory blocks being stored into the memory location having the memory address equal to the corresponding image address plus an offset of the image portion within the mass memory, selecting a current software image stored in a current image, relocating the memory blocks stored in boot locations of the current software image to a relocation portion of the mass memory, the boot locations of the current software image being the memory locations having the memory addresses equal to the image addresses of boot blocks of the current software image including the memory blocks thereof required to boot the data processing entity up to load an access function adapted to access the current software image, copying the boot blocks of the current software image into the corresponding boot locations, booting the data processing entity from the boot blocks of the current software image in the corresponding boot locations thereby loading the access function, and serving each request to access a selected memory block of the current software image by the access function, the access function accessing the selected memory block in the memory location having the memory address equal to the corresponding image address plus the offset of the current image portion.

DETAILED DESCRIPTION

With reference in particular toFIG. 1, there is shown a schematic block diagram of a data processing system (or simply “system”)100in accordance with an embodiment of the present invention. The system100has a distributed architecture, which is based on a network105(e.g., local area network or “LAN”). Multiple computers are connected one to another through the network105. Particularly, a server computer110controls the deployment of software images onto client computers115. Only two client computers115are shown in the figure for the sake of simplicity. Each software image is a structure that includes one or more software modules (for example, operating systems, application programs, and/or data).

A generic (server or client) computer of the system100is formed by several units that are connected in parallel to a system bus120(with a structure that is suitably scaled according to the actual function of the computer in the system100). In detail, one or more microprocessors (μP)125control operation of the computer. A random access memory (RAM)130is used as a working memory by the microprocessors125, and a read only memory (ROM)135stores basic code of the computer. Several peripheral units are clustered around a local bus140(by means of respective interfaces). Particularly, a mass memory includes one or more hard-disks145and drives150for reading optical disks155, (for example, digital video discs or “DVDs” and compact discs or “CDs”). Moreover, the computer includes input units160(for example, a keyboard and a mouse) and output units165(for example, a monitor and a printer). An adapter170is used to connect the computer to the network105. A bridge unit175interfaces the system bus120with the local bus140. Each microprocessor125and the bridge unit175can operate as master agent requesting an access to the system bus120for transmitting information. An arbiter180manages the granting of the access with mutual exclusion to the system bus120.

A collaboration diagram representing the roles of the main software components that may be used to implement a deployment process according to an embodiment of the invention is shown inFIG. 2A-FIG.2K. Particularly, the figures describe the static structure of the system (by means of the corresponding components, denoted as a whole with the reference200) and its dynamic behavior (by means of a series of exchanged messages, each one representing a corresponding action, denoted with progressive sequence numbers proceeded by the symbol “A”).

Starting withFIG. 2A, the server computer110(with its working memory and mass memory, denoted with the references130sand145s, respectively) runs a deployment manager205, for example, the IBM® Tivoli® Provisioning Manager for Images of the IBM® Tivoli® Provisioning Manager for OS Deployment. (IBM and Tivoli are trademarks of International Business Machines Corporation registered in many jurisdictions worldwide.) The deployment manager205is used to automate the deployment of software images210i(with i=1 . . . N) onto the client computers of the system. The software images210iare stored in a corresponding repository. Each software image210iincludes a set of memory blocks, which have corresponding addresses within the software image210i(referred to as image addresses). The memory blocks may include any kind of information (for example, one or more sectors, files, libraries, directories, combinations or portions thereof, either relating to the operating system or the application programs).

Particularly, whenever a new software image210i(for example, the software image2101) is to be deployed onto a specific client computer115(with its working memory and mass memory, denoted with the references130cand145c, respectively), an operator212of the system selects the client computer115and new software image210, through the deployment manager205. The selection is performed, for example, by connecting with a browser running on another client computer, not shown in the figure (action “A201.Select”). In response thereto, the deployment manager205turns on the client computer115. As a consequence, assuming that the client computer115does not have any functioning operating system, it boots over the network (not shown in the figure). Particularly, a boot loader stored in a firmware of the client computer115that is executed when it is turned on, for example, the basic input/output system (BIOS), does not find any bootable device, and then launches a network boot loader, for example, the preboot execution environment (PXE) embedded in its network adapter. The network boot loader exploits a dynamic address service, for example, based on the dynamic host configuration protocol (DHCP), to obtain a dynamic address for the client computer115from the server computer110(acting as a DHCP server). The server computer110also provides an address of a network bootstrap program that is downloaded into a RAM disk of the client computer115, i.e., a portion of its working memory130cthat is treated as a mass memory, and then launched. The network bootstrap program, for example, the Microsoft Windows Preinstallation Environment, provides a minimal operating system215, which includes a deployment agent220for interacting with the deployment manager205(action “A202.Network boot”). (Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both.)

The deployment agent220initializes the mass memory145cby logically splitting it into a plurality of image portions225j(with j=0 . . . M, for example, M=2-10) and a service portion230. The image portions225j(each one for storing a software image) are all the same size (at least equal to the biggest software image that may be installed thereon) and are arranged in succession from the beginning of the mass memory145c. The service portion230(for storing service information) is smaller and is arranged at the end of the mass memory145c. Particularly, the service portion230stores an image table235, which includes status information of the image portions225j. For example, for each image portion225jthe image table235includes a record with a flag indicating its availability, i.e., free or used (all being de-asserted at the beginning to indicate that all the image portions225jare free), and an offset indicating its position within the mass memory145cfrom the beginning thereof (being calculated according to the size of the image portions225j). The service portion230also stores an offset index240, which indicates the offset of the image portion225jthat is currently active (action “A203.Initialize”).

The deployment agent220then downloads a set of boot blocks of the new software image2101from the server computer110. For this purpose, the deployment agent220acts as a remote access initiator that interacts with a remote access server245of the server computer110, for example, based on the Internet small computer system interface (iSCSI) protocol. The boot blocks include the memory blocks that are needed to start a boot sequence of the new software image2101up to load the deployment agent220. For example, in Microsoft Windows the boot blocks include (in addition to the deployment agent220) a master boot record (MBR), a boot sector, a bootmgr.exe file, a boot\bcd file, a system registry, a winload.exe file, and driver files specified in the system registry (action “A204.Download”).

At this point, the deployment agent220identifies the initial image portion2251as free to receive the new software image2101(since it is the first one with the corresponding flag de-asserted in the image table235). As a consequence, the deployment agent220accordingly updates the image table235(by asserting the flag of the image portion2251to indicate that is used) and the offset index240(by setting it to the offset of the new image portion2251as indicated in the image table235, zero in this case, to indicate that it is the current one). The deployment agent220saves the image addresses of the boot blocks into the record associated with the current image portion2251in the image table235. The deployment agent220also creates a location map, not shown in the figure, in the current image portion2251(at its end, after a portion thereof reserved for storing the new software image2101). For each memory block of the software image2101, the location map includes a flag indicating its availability in the mass memory145c, all being de-asserted at the beginning to indicate that no memory block is available yet in the mass memory145c(action “A212.Configure”—with the actions corresponding to the skipped sequence numbers that will be described in the following). The deployment agent220then stores the boot blocks of the new software image2101into the current image portion2251, i.e., into the memory locations of the mass memory145chaving their addresses in the mass memory145c(referred to as memory addresses) equal to the corresponding image addresses plus the offset of the current image portion2251, where they are shown in light shading and denoted with the reference2501. At the same time, the corresponding flags in the location table are asserted (to indicate that the boot blocks are now available in the mass memory145c). Since in this case the offset of the current image portion2251is zero, the boot blocks2501are arranged in the mass memory145cexactly where they are expected to be found during the boot sequence (action “A213.Store”). At this point, the deployment agent220turns off and then turns on the client computer115.

Therefore, as shown inFIG. 2B, the client computer115boots normally from the mass memory145c. Indeed, the boot loader of the client computer115that is executed at its turn on now identifies the mass memory145cas a bootable device, so that it boots locally from its boot blocks2501. In this way, a portion of an actual operating system of the new software image2101corresponding to the boot blocks2501(denoted with the reference2551) and the deployment agent220are loaded into the working memory130c. For example, in Microsoft Windows the BIOS loads the MBR, the MBR loads the boot sector, the boot sector finds and starts the bootmgr.exe file, the bootmgr.exe finds and reads the boot\bcd file to determine the memory location of and then loads the system registry, the winload.exe file, and the driver files specified in the system registry, and the winload.exe starts the deployment agent220. When the size of the new software image2101is different (i.e., lower) than the size of the current image portion2251, the deployment agent220also resizes it so as to occupy the entire current image portion2251. This operation is very fast, since it only requires updating a file system structure, not shown in the figure, of the operating system2551(action “A214.Local boot”). Every request of accessing a selected memory block of the new software image2101during operation of the client computer115is now served by a streaming driver of the deployment agent220(which overrides a standard file-system driver, not shown in the figure, of the operating system2551).

Particularly, the file system driver receives a request for accessing (i.e., read) the selected memory block, for example, from an application program, not shown in the figure (action “A215.Access request”). The request is passed to the deployment agent220, which verifies whether the selected memory block is available in the current image portion2251(as indicated in its location map). When the selected memory block is not available in the current image portion2251(i.e., its flag in the location map is de-asserted), the deployment agent220passes the request to a remote access driver, not shown in the figure, of the operating system2551(acting as an iSCSI initiator in the example at issue). The remote access driver downloads the selected memory block from the software image2101(on the server computer110) through the remote access server245. The remote access driver then returns the selected memory block to the deployment agent220(action “A216a.Download”). The deployment agent220stores the selected memory block into the current image portion2251(through a physical disk driver, not shown in the figure, of the operating system255). Particularly, the selected memory block is stored into the memory location having the memory address equal to its image address plus the offset of the current image portion2251(which offset, zero in this case, is extracted from the offset table240). Moreover, the deployment agent220updates the location map accordingly, so as to indicate the availability of the selected memory block, i.e., by asserting the corresponding flag (action “A217.Store”). At this point, the deployment agent220returns the selected memory block to the file system driver, which in turn returns it to the application program (action “A218.Return”).

Conversely, as shown inFIG. 2C, if the selected memory block is already available in the current image portion2251(i.e., its flag in the location map is asserted), the deployment agent220passes the request to the physical disk driver. The physical disk driver directly retrieves the selected memory block from the current image portion2251, i.e., from the memory location having the memory address equal to its image address plus the offset of the current image portion2251(zero in this case). The physical disk driver then returns the selected memory block to the deployment agent220(action “A216b.Retrieve”). In this case as well, the deployment agent220returns the selected memory block to the file-system driver, which in turn returns it to the application program (same action “A218.Return”).

The above described streaming technique makes the client computer115ready to use in a very short time, just after the boot blocks of the new software image2101have been stored into the mass memory145c, even if the deployment process is still in progress (for example, after 1-2 minutes for a typical size of the boot blocks of 10-200 Megabytes). The operation of the client computer115is then entirely normal (with its booting directly from the mass memory145cas usual), irrespectively of the availability or not of the other memory blocks of the software image2101in the mass memory145c. This occurs with only a slight degradation of performance of the client computer115when it accesses memory blocks that are still to be downloaded from the server computer110. Moreover, the time required to have the client computer115ready to use is independent of the size of the new software image2101. The usage of the network also decreases over time (for example, with a logarithmic law), since more and more memory blocks will be already available on the client computer115once they have been accessed once. In this respect, it should be noted that this streaming technique has nothing to do with the ones that are known in the art for providing software images on demand. Indeed, in the known streaming techniques, memory blocks of the software images are downloaded onto the client computer only for their immediate use. However, these memory blocks are not stored permanently on the client computer (i.e., they disappear after they have been used, and in any case after the client computer is turned off), so that they have to be downloaded again for any next use thereof. As a consequence, the client computer can never be disconnected from the server computer. Indeed, even when the memory blocks are pre-fetched, they remain on the client computer only until their (possible) next use. Likewise, even when a local cache for the memory blocks is implemented, only few memory blocks remain in the local cache for their re-use (in any case, with the least recently used memory blocks in the local cache that are ultimately evicted for storing new memory blocks).

With reference now toFIG. 2D, if the selected memory block has been requested for writing, the deployment agent220passes the request to the physical disk driver. The physical disk driver directly updates the selected memory block in the current image portion2251, i.e., at the memory location having the memory address equal to its image address plus the offset of the current image portion2251(zero in this case), where it is always available after the reading thereof (action “A219.Update”). Therefore, the current image portion2251can be updated normally (as if the new software image2101was already completely deployed onto the client computer115) even when the deployment process is still in progress.

In a completely asynchronous way, the deployment agent220periodically verifies (for example, every 10-100 milliseconds) a workload of the server computer110, of the client computer115and/or of the network connecting them. If the workload is lower than a predefined threshold (indicating that the corresponding resources are under exploited at the moment, for example, because no action is performed on the server computer110and/or on the client computer115, and traffic in the network is low), the deployment agent220downloads a new memory block that is still not available in the current image portion2251(for example, the first one whose flag in the location map is de-asserted) by repeating the same operations described above (action “A220.Download”). As above, the deployment agent220stores this new memory block into the current image portion2251(through the physical disk driver), i.e., into the memory location having the memory address equal to its image address plus the offset of the current image portion2251(zero in this case). Moreover, the deployment agent220updates the location map accordingly, so as to indicate the availability of the new memory block (action “A221.Store”).

In this way, as shown inFIG. 2E, it is possible to ensure that all the memory blocks of the new software image2101will be downloaded at the end (even if they are never used).

At any time, the operator212may also select another new software image210, (for example, the software image2102) to be deployed onto the same client computer115through the deployment manager205(action “A205.Select”). In response thereto, as above the deployment agent220downloads the boot blocks of the new software image2102from the server computer110through the remote access server245(action “A206.Download”).

Moving toFIG. 2F, the deployment agent220relocates the memory blocks of the initial image portion2251that are stored in boot locations of the new software image2102(i.e., in the memory locations having their memory addresses equal to the image addresses of the boot blocks of the new software image2102). Particularly, these memory blocks are moved to the service portion230(to a dedicated relocation portion thereof), where they are referred to as relocated memory blocks2602(action “A210.Relocate”). The deployment agent220then stores the boot blocks of the new software image2102into their boot locations, where they are shown in dark shading and denoted with the reference2502. In this way, the boot blocks2502are again arranged in the mass memory145cexactly where they are expected to be found during the boot sequence. Nevertheless, this does not cause any loss of information in the initial image portion2251, since the corresponding memory blocks that are overridden are saved in the service portion230(action “A211.Store”).

The deployment process then continues exactly as above. Particularly, the deployment agent220identifies an image portion225ithat is free to receive the new software image2102(i.e., the image portion2252in the example a tissue). As a consequence, the deployment agent220accordingly updates the image table235(by asserting the flag of the image portion2252to indicate that is used) and the offset index240(by setting it to the offset of the image portion2252to indicate that it is the current one). Moreover, the deployment agent220saves the image addresses of the boot blocks2502into the record associated with the current image portion2252in the image table235. The deployment agent220also creates the corresponding location map (not shown in the figure) in the current image portion2252(same action “A212.Configure”). The deployment agent220then stores the boot blocks of the new software image2102into the current image portion2252, i.e., into the memory locations of the mass memory145chaving the memory addresses equal to their image addresses plus the offset of the current image portion2252, where they are shown in light shading (same action “A213.Store”). At this point, the deployment agent220turns off and then turns on the client computer115.

Therefore, as shown inFIG. 2G, the boot loader of the client computer115now boots from its boot blocks2502. In this way, a portion of an operating system of the new software image2102corresponding to the boot blocks2502(denoted with the reference2552) and the deployment agent220are loaded into the working memory130c(same action “A14.Local boot”). Every request of accessing a selected memory block of the software image2102during operation of the client computer115is again served by the streaming driver of the deployment agent220.

Particularly, in response to a request for accessing (in read) a selected memory block of the new software image2102(same action “A215.Access request”), if the selected memory block is not available in the current image portion2252it is downloaded from the software image2102on the server computer110(same action “A216a.Download”), stored into the current image portion2252(same action “A217.Store”), and then returned (same action “A218.Return”).

Conversely, as shown inFIG. 2H, if the selected memory block is already available in the current image portion2252, it is directly retrieved (same action “A216b.Retrieve”), and then returned (same action “A218.Return”).

With reference now toFIG. 2I, if the selected memory block has been requested for writing, it is updated in the current image portion2252(same action “A219.Update”). When the workload is low, a new memory block that is still not available in the current image portion2252is downloaded (same action “A220.Download”), and stored into the current image portion2252(same action “A221.Store”).

With reference now toFIG. 2J(showing the software image2102completely downloaded), at any time the operator212may select another new software image210, (for example, the software image2103) to be deployed onto the same client computer115through the deployment manager205(action “A207.Select”). In response thereto, as above the deployment agent220downloads the boot blocks of the new software image2103from the server computer110through the remote access server245(action “A208.Download”). At this point, the deployment agent220restores the relocated memory blocks2602from the service portion230to the initial image portion2251, i.e., into the boot locations of the current image portion2252(as indicated in the corresponding record of the image table235). This operation does not cause any loss of information in the boot blocks2502of the current image portion2252that are overridden, since their up-to-date values (as possibly updated during the operation of the client computer115as explained above) are stored in the current image portion2252(action “A209.Restore”).

The deployment process then continues as above. Particularly, as shown inFIG. 2K, the deployment agent220relocates the memory blocks of the initial image portion2251that are stored in the boot locations of the new software image2103to the service portion230, where they are denoted with the reference2603(same action “A210.Relocate”). At this point, the deployment agent220stores the boot blocks of the new software image2103into their boot locations—where they are shown in dark shading and denoted with the reference2503(same action “A211.Store”). The deployment agent220then identifies an image portion225ithat is free to receive the software image2102(i.e., the image portion2253). As a consequence, the deployment agent220accordingly updates the image table235(by asserting the flag of the image portion2253to indicate that is used) and the offset index240(by setting it to the offset of the image portion2253to indicate that it is the current one). Moreover, the deployment agent220saves the image addresses of the boot blocks2503into the record associated with the current image portion2253in the image table235. The deployment agent220also creates the corresponding location map (not shown in the figure) in the current image portion2253(same action “A212.Configure”). The deployment agent220then stores the boot blocks of the new software image2103into the current image portion2253—where they are shown in light shading (same action “A213.Store”). At this point, the deployment agent220turns off and then turns on the client computer115so as to boot it from its boot blocks2503, thereby loading a portion of an operating system of the software image2103corresponding to the boot blocks2503and the deployment agent, which will serve every request of accessing any selected memory block of the new software image2103, into the working memory130c(same action “A14.Local boot”).

In any case, once the deployment of one or more software images onto the client computer has been completed, it can work autonomously without any need of the server computer any longer. However, the same streaming technique that has been used during the deployment processes can also be exploited to create snapshots of the client computer (each one being formed by a consistent backup copy of a software image thereof at a particular point of time).

Particularly,FIG. 3A-FIG.3E show a collaboration diagram representing the roles of the main software components (denoted as a whole with the reference300) that may be used to implement a snapshot process according to an embodiment of the invention.

Starting fromFIG. 3A, consider, for example, a situation of the client computer115where two software images are stored in the image portions2251and2252. The image portion2252is the current one, with its boot blocks2502that are also stored in their boot locations in the initial image portion2251(with the corresponding relocated memory blocks2602of the initial image portion2251saved in the service portion230). A user of the client computer115may submit a command for creating a new snapshot of a source software image in a corresponding source image portion225i, for example, the source image portion2251storing the source software image2101(action “A301.Create”). In response thereto, the deployment agent220at first identifies a target image portion225ithat is free to receive the source software image2101(for example, the image portion2253in the example at issue). The deployment agent220then copies the whole source software image2101into the target image portion2253. More specifically, for every current memory block (with a corresponding current image address) of the source software image2101, if the source image portion2251is the initial one (as in this case) the deployment agent220verifies whether the current memory block has been relocated to the service portion230(i.e., the current image address is equal to the image address of one of the boot locations of the current software image portion2252, as indicated in its record in the image table235). If so, the corresponding relocated memory block2602is copied into the target image portion2253, in the memory location having the memory address equal to the current image address plus the offset of the target image portion2253. Conversely (i.e., when the current memory block has not been relocated, or always when the source image portion is not the initial one), the current memory block is copied from the source image portion2251to the target image portion2253, i.e., from the memory location having the memory address equal to the current image address plus the offset of the source image portion2252to the memory location having the memory address equal to the current image address plus the offset of the target image portion2253(action “A302.Copy”). Once the whole source software image2101has been copied into the target image portion2253, the deployment agent220accordingly updates the image table235by asserting the flag of the target image portion2253to indicate that is used, and saving the same image addresses of the boot blocks of the source software image2101(action “A303.Update”). Therefore, the operation of creating a snapshot of a software image is quite slow (with its length that is proportional to the size of the source software image to be copied).

Moving toFIG. 3B, the user of the client computer115may also submit a command for deleting an obsolete software image (in a corresponding obsolete image portion225i) to the deployment agent220. In order to ensure continuity of operation of the client computer115after the deletion of the obsolete software image, the obsolete image portion225ishould be different from the current image portion2252, for example, the image portion2251(action “A304.Delete”). In response thereto, the deployment agent220simply updates the image table235by asserting the flag of the obsolete image portion2251to indicate that it is free (action “A304.Update”). Therefore, the operation of deleting a software image is very fast (since it does not require any actual action on its memory blocks). Moreover, this operation does not cause any problem even when the image portion to be deleted is the initial one (since the boot blocks of the current image portion2252stored therein are unaffected).

With reference now toFIG. 3C, the user of the client computer115may instead submit a command for switching from the current software image2252to another (previous) software image portion225i, for example, the software image portion2253(action “A305.Switch”). In response thereto, as above, the deployment agent220restores the relocated memory blocks2602from the service portion230to the initial image portion2251, i.e., at the boot locations of the current image portion2252(action “A306.Restore”).

Moving toFIG. 3D, the deployment agent220relocates the memory blocks of the initial image portion2251that are stored in the boot locations of the previous software image2103to the service portion230, where they are denoted with the reference2603(action “A307.Relocate”). The deployment agent220then copies the boot blocks of the previous software image2103into their boot locations, where they are shown in light shading and denoted with the reference2503(action “A308.Copy”). The deployment agent220can now update the offset index240, by setting it to the offset of the previous image portion2253to indicate that it is now the current one (action “309.Update”). At this point, the deployment agent220turns off and then turns on the client computer115so as to boot it from its boot blocks2503, thereby loading a portion of an operating system of the previous software image2103, corresponding to the boot blocks2503, and the deployment agent into the working memory130c(action “A310.Re-boot”).

Considering nowFIG. 3E, every request of accessing a selected memory block of the current software image2103during operation of the client computer115is again served by the streaming driver of the deployment agent220(which overrides a standard file-system driver, not shown in the figure, of the operating system2553).

Particularly, the file-system driver receives a request for accessing (either in read or in write) the selected memory block—for example, from an application program not shown in the figure (action “A311.Access request”). The request is passed to the deployment agent220, which directly accesses (through a physical disk driver, not shown in the figure, of the operating system2553) the selected memory block in the current image portion2253, i.e., in the memory location having the memory address equal to the image address of the selected memory block plus the offset of the current image portion2253(action “A311.Access”).

The above-described technique allows managing multiple software images on the client computer in a very easy way. Moreover, the different software images are completely segregated from one another and each software image can only access the corresponding image portion (so as to prevent any risk of damaging the other image portions).

This result is achieved without requiring any virtualization infrastructure; therefore, the performance of the client computer is not adversely affected. Indeed, in this case only the software images (i.e., the mass memory where they are stored) are virtualized; conversely, the operating systems continue running natively on the client computer.

Particularly, this allows restoring a snapshot very fast (since it is already available on the client computer); moreover, the desired result may be achieved without requiring any network connection.

Moving toFIG. 4, there is shown a collaboration diagram representing the roles of the main software components (denoted as a whole with the reference400) that may be used to implement a preparation process of a generic software image to be used in the solution according to an embodiment of the invention. Particularly, this preparation process is aimed at identifying the boot blocks of the software image (to be used during the deployment process or the snapshot process described above).

For this purpose, the client computer115includes a repository of master software images (or simply master images)405. Each master image405provides a basic version of a corresponding software image (for example, created by capturing the content of a hard-disk of a donor client computer wherein it was previously installed), where specific contents relating to any configuration of the donor client computer (for example, drivers and registry settings) have been removed. The client computer115also includes a repository of models410; each model410instead includes contents specific for a corresponding configuration of the client computers.

The operator212selects a software image (including a selected master image405and a selected model410) for a specific type of client computers (represented by a corresponding auxiliary client computer115) through the deployment manager205(action “A401.Select”). In response thereto, the deployment manager205wakes up the deployment agent220on the auxiliary client computer115, by passing an identifier of the selected software image (action “A402.Wake-up”). As a consequence, the deployment agent220mounts the selected software image as a remote disk (i.e., by acting as an iSCSI initiator in the example at issue) for accessing it remotely through the remote access server245. As a result, a temporary software image (or simply “temporary image”)415for exclusive access by the auxiliary client computer is created. The temporary image415is simply defined by an index structure pointing to the memory blocks of the selected master image405and of the selected model410, i.e., without making any copy thereof. The temporary image415is mounted with a block-tracing function enabled, so as to trace the image address of any memory block of the temporary image415that is accessed (action “A403.Mount”).

At this point, the deployment agent220simulates the boot sequence of the auxiliary client computer115on the temporary image415(up to the loading of the deployment agent). For example, in Microsoft Windows the deployment agent220reads the MBR, the boot sector, the bootmgr.exe file, the boot\bcd file, the system registry, the winload.exe file, the driver files specified in the system registry, and the deployment agent (action “A404.Simulated boot”). Once the simulated boot sequence has been completed, the deployment agent220unmounts the temporary image415(action “A405.Unmount”). The deployment agent220then commits the temporary image415to the deployment manager205(action “A406.Commit”). In response thereto, the deployment manager205builds a new software image (or simply new image)420from the temporary image415(simply defined by its index structure). Moreover, the new image420is associated with the list of the memory blocks that have been accessed during the simulated boot procedure, which memory blocks define the corresponding boot blocks (action “A407.Build”).

It will be understood by one skilled in the art that many logical and/or physical modifications and alterations may be made to the embodiments described herein. More specifically, although the embodiments have been described with a certain degree of particularity, it should be understood that various omissions, substitutions and changes in the form and details as well as other embodiments are possible (for example, with respect to numerical values and compositions). Particularly, different embodiments of the invention may even be practiced without the specific details set forth in the preceding description to provide a more thorough understanding thereof; conversely, well-known features may have been omitted or simplified in order not to obscure the description with unnecessary particulars. Moreover, it is expressly intended that specific elements and/or method steps described in connection with any embodiment of the disclosed solution may be incorporated in any other embodiment as a matter of general design choice.

For example, similar considerations apply if the same solution is implemented with an equivalent method (by using similar steps with the same function of more steps or portions thereof, removing some steps being non-essential, or adding further optional steps). Moreover, the steps may be performed in a different order, concurrently or in an interleaved way (at least in part).

The software images may include any software program (for example, only the operating system without any application programs). Moreover, even if the proposed technique has been specifically designed for use on physical computers, its application on virtual machines as well is not excluded. In addition, any equivalent structure may be used to provide the access function. In any case, the same technique may also be applied to any other operating system with whatever boot sequence. For example, in the Linux operating system, the boot blocks will include (in addition to the deployment agent) the MBR including the grand unified bootloader (GRBU) and the /boot directory including the kernel and the initial RAM disk (initrd) file system. (Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both.) In this case, during the boot sequence the BIOS loads the MBR including the GRBU, the GRBU finds the /boot directory and loads the kernel and the initrd file system, the GRBU boots on the kernel, the kernel starts the initrd file system, and the initrd file system starts the deployment agent.

The step of restoring the relocated memory blocks when the client computer is switched to another software image is not strictly necessary. For example, it is also possible to relocate the memory blocks in the boot locations of all the software images different from the initial one into the relocation portion, and then restore all of them at the same time only when the client computer is switched to the initial software image (thereby making the switching operation faster, but at the cost of a waste of mass memory space).

In any case, the boot locations may be arranged in any position within the mass memory.

The image portions may be managed in an equivalent way; for example, it is possible to have image portions with different size (even defined dynamically when they are created).

Moreover, equivalent structures may be used to manage the status information of the image portions (for example, with each image partition that directly includes an indicator of its availability).

Even though in the preceding description reference has been made to a snapshot process implemented on the client computer when one or more software images are completely installed (so that no network connection is needed), the same technique may also be applied to software images that are only partially stored on the mass memory of the client computer (with the deployment of a software image that re-starts when the client computer is reverted to it).

In an alternative implementation, the deployment agent manages the current image portion by letting the corresponding operating system believe that its size is equal to the one of the current software image (without any re-sizing thereof, but with a corresponding waste of mass memory space).

The software images may be deployed with the above-described streaming technique from any external source (for example, a removable storage device). In addition, any equivalent structure may be used to manage the availability of the memory blocks in the mass memory (for example, by breaking the location map into chunks to allow their loading into the working memory of the client computer). Alternatively, it is also possible to maintain the streaming process always active, even after the software image has been completely downloaded (for example, for downloading up-to-date versions of the memory blocks in response to a reset of the corresponding flags in the location map).

In any case, the proposed technique is completely independent of how the software images have been deployed onto the client computer (for example, even manually without any server computer).

The possibility of copying the boot blocks only into their boot locations during the deployment of the corresponding software image (with their saving into its image portion only when the client computer switches to another software image) is not excluded.

Alternatively, it is possible to manage the writing of the memory blocks directly by the physical disk driver (without any passage through the deployment agent).

The workload may be monitored with any other frequency or only during specific periods (for example, at night); similar considerations apply if the workload is monitored only for the client computer, the server computer, the network, or any combination thereof. Moreover, the threshold value for the workload may be defined in any other way (for example, by weighting its contributions with different weights). Similar considerations apply if two or more memory blocks are downloaded at the same time when the workload falls below the threshold value. In any case, this feature may be omitted when the streaming process remains always active.

The software images may also be prepared in a different way (for example, by actually booting the auxiliary client computer and tracing the memory blocks that are accessed during the booting sequence to identify its boot blocks).

Similar considerations apply if the programs (which may be used to implement each embodiment of the invention) are structured in a different way, or if additional modules or functions are provided. Likewise, the memory structures may be of other types, or may be replaced with equivalent entities (not necessarily consisting of physical storage media). The program may take any form suitable to be used by any data-processing system or in connection therewith (for example, within a virtual machine); particularly, the program may be in the form of external or resident software, firmware, or microcode (either in object code or in source code—for example, to be compiled or interpreted). Moreover, it is possible to provide the program as an article of manufacture implemented on any computer-usable medium; the medium can be any element suitable to contain, store, communicate, propagate, or transfer the program. For example, the medium may be of the electronic, magnetic, optical, electromagnetic, infrared, or semiconductor type; examples of such medium are fixed disks (where the program can be pre-loaded), removable disks, tapes, cards, wires, fibers, wireless connections, networks, broadcast waves, and the like. In any case, the solution according to an embodiment of the present invention lends itself to be implemented even with a hardware structure (for example, integrated in a chip of semiconductor material), or with a combination of software and hardware suitably programmed on otherwise configured.

Alternatively, the system has a different structure or includes equivalent components, or it has other operative characteristics. In any case, every component thereof may be separated into more elements, or two or more components may be combined together into a single element; moreover, each component may be replicated to support the execution of the corresponding operations in parallel. It is also pointed out that any interaction between different components generally does not need to be continuous (unless specified otherwise), and it may be either direct or indirect through one or more intermediaries. Particularly, the system may be based on a different architecture (for example, wide area, global, cellular or satellite network), and exploiting any type of (wired and/or wireless) connections. In any case, each computer may have another structure or may include similar elements (such as cache memories temporarily storing the programs or parts thereof); moreover, it is possible to replace the computer with any code execution entity (such as a PDA, a mobile phone, and the like), or with a combination of multiple entities.

The invention may be embodied in a computer program product including a non-transitory computer readable medium embodying a computer program, the computer program including code means directly loadable into a working memory of a data-processing system thereby configuring the data-processing system to perform the same method.