Patent Application
20080104588
Embodiments of the invention relate generally to creation of multiple operating system images for Virtual Machines.
Updates are performed on operating systems so that they are modified to become current. The updates to the operating system will, for example, add new features to, update the versions of, add patches to, or perform other modifications or maintenance to the operating system. However, current operating systems such as, for example, the WINDOWS-based operating systems from MICROSOFT CORPORATION, the LINUX operating system, or the VMWARE SERVER 1.0 from VMWARE, INCORPORATED, permit updates to running systems, but has the risk in that the software to be updated may be in use. Using an OS while it is being updated can cause failures that are critical and difficult to troubleshoot. Furthermore, prior solutions for performing updates such as, for example, ALTERNATE ROOT DISK from IBM CORPORATION, LIVE UPGRADE from SUN MICROSYSTEMS, INCORORATED, and DPS from MICROSOFT CORPORATION do not permit updates to be performed across multiple types of operating systems and do not create a backup of an operating system within a Virtual Machine environment.
Therefore, the current technology is limited in its capabilities and suffers from at least the above constraints and deficiencies.
Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following figures, wherein like reference numerals refer to like parts throughout the various views unless otherwise specified.
In the description herein, numerous specific details are provided, such as examples of components and/or methods, to provide a thorough understanding of embodiments of the invention. One skilled in the relevant art will recognize, however, that an embodiment of the invention can be practiced without one or more of the specific details, or with other apparatus, systems, methods, components, materials, parts, and/or the like. In other instances, well-known structures, materials, or operations are not shown or described in detail to avoid obscuring aspects of embodiments of the invention.
A virtual machine (VM) application 115 runs on the host OS 110. The virtual machine application 115 may be, for example, the HP INTEGRITY VIRTUAL MACHINE which is commercially available from HEWLETT-PACKARD COMPANY, Palo Alto, Calif. The host OS 110 can be, for example, an operating system in the HPUX operating system family which is provided by Hewlett-Packard Company.
When the VM application 115 runs on the host OS 110, the VM application 115 provides one or more Virtual Machines. Additionally, a DRD (Dynamic Root Disk) application 120 can clone an original guest operating system that is running in a Virtual Machine and then perform updates or maintenance on the cloned guest operating system to be booted in a newly-started Virtual Machine, while the original guest operating system concurrently runs in its own Virtual Machine, in accordance with an alternative set of operations. Typically, the VM application 115 will start the new Virtual Machines. The DRD application 120 clones one or more different operating system types that are supported in the Virtual Machines and updates or modifies the cloned operating systems while the cloned operating systems are inactive OS images and before the updated cloned operating systems are changed in their identities and booted in the new Virtual Machines, in accordance with an alternative set of operations. The DRD application 120 can, for example, be a separate software code and/or component, or can be software code and/or component that are integrated within the VM application 115 or host OS 110. Therefore, the VM application 115 or host OS 110 can be modified so that they perform the functions of the DRD application 120 that are discussed in detail below. Those skilled in the art will realize based upon the reading of this disclosure that the features of the DRD application 120 can be implemented in various manners in the apparatus 100.
As known to those skilled in the art, a Virtual Machine describes specific programs that mimic a computer within a computer, or a simulation of a physical device represented by computer software. Virtual Machines permit multiple operating systems and programs to be run by the computer at the same time, and each user appears to have an independent computer with its own input and output devices. A Virtual Machine permits an operating system type to run on a processor that has been designed to run another different operating system type. Virtual Machines have been described in, for example, commonly-owned U.S. patent application Ser. No. 10/175,183, entitled “Multiple Trusted Computing Environments With Verifiable Environment Identities” which is hereby incorporated herein by reference.
The VM application 115 provides one or more Virtual Machines that supports a guest operating system that can be of a different type from the host OS 110. For example, the Virtual Machine 125 supports a guest OS 130 which may be a different type from the host OS 110. For example, the host OS 110 can be an HP-UX family operating system type, while the guest OS 130 can be a different operating system type (e.g., Windows family operating system). The VM application 115 can provide a variable number of Virtual Machines. For example, the VM application also provides another Virtual Machine 135 that supports another guest OS 140. That second guest OS 140 may be of a different type from the host OS 110 and the first guest OS 130 (e.g., the second guest OS 140 may be a LINUX, AIX (Advance Interactive executive or Advanced IBM UNIX), SOLARIS, or another OS type). A Virtual Machine will simulate hardware, so that processes (e.g., applications) can run on a guest OS in the Virtual Machine, even if the guest OS is not designed to be run on the processor 111 in the hardware layer 105. As a result, the Virtual Machines permit the apparatus 100 to concurrently support multiple-different types of operating systems.
A Virtual Machine is allocated a specified amount of memory in the hardware layer 105, a virtual processor having one or more virtual CPUs (or cores), and a set of virtual I/O devices. For example, in
The DRD application 120 runs on the host OS 110. In an embodiment of the invention, the DRD application 120 will clone (copy) a guest OS 130 in order to create a cloned guest OS 145 that can be maintained or updated while the original guest OS 130 continues to run. The DRD application 120 copies the root disks and other data of the guest OS 130 in order to create the cloned guest OS 145. The DRD application 120 will clone the guest OS 130 from data in the memory area 112 which maps the guest OS 130. The DRD application 120 will then map the cloned OS 145 in the memory area 114. As an example, the memory areas 112 and 114 may each be a disk or another suitable type of memory device in the hardware layer 105. The cloned guest OS 145 is an image of the original guest OS 130 when the cloned guest OS 145 is originally created by the DRD application 120, and will vary from the original guest OS 130 when the DRD application 120 subsequently updates the cloned guest OS 145 in accordance with one alternative set of operations. The DRD application 120 clones a guest OS in response to a DRD clone command 147 sent via the user interface 116 from a system administrator or other user. In another alternative set of operations, the updated cloned guest OS 145 is then booted in a new Virtual Machine, then the cloned guest OS 145 is updated by tools typically used to perform software maintenance on original guest OS 130.
In an embodiment of the invention, after the DRD application 120 clones the original guest OS 130, the DRD application 120 will change the identity of the cloned guest OS 145, and the VM application 115 will then boot the cloned guest OS 145 in a new Virtual Machine 150. The DRD application 120 causes the VM application 115 to start the new Virtual Machine 150 which typically will be mapped to the memory device 114. The new Virtual Machine 150 will also have a virtual processor 151 and virtual I/O device 152.
Software maintenance tools for that OS can then be used to performs software maintenance (updates) on the cloned guest OS 145. The routing engine 170 then allows the updated guest OS 145 in the new Virtual Machine 150 to take over the functions of the original guest OS 130. Further details of these steps are discussed further below.
Alternatively, after the DRD application 120 clones the original guest OS 130, the DRD application 120 will instead perform software maintenance (updates) on the cloned guest OS 145 which is currently an inactive operating system image that is a clone of the original guest OS 130. The DRD application 120 will then change the identity of the updated cloned guest OS 145, and the VM application 115 will then boot the updated cloned guest OS 145 in a new Virtual Machine 150. The routing engine 170 then allows the updated guest OS 145 in the new Virtual Machine 150 to take over the functions of the original guest OS 130.
In both alternatives, the DRD application-120 will change the identity 154 of the cloned guest OS 145 so that the identity 154 is different from the identity 160 of the original guest OS 130. For example, the identity 154 includes the Virtual Machine identifier 155 of the Virtual Machine which runs the cloned guest OS 145, the virtual Internet Protocol address 156 of the new Virtual Machine 150, and the guest OS name 157 of the cloned guest OS 145. Note that the identity 160 of the original guest OS 130 also includes a Virtual Machine identifier 161, the virtual Internet Protocol address 162, and guest OS name 163.
In an embodiment of the invention, the contents of cloned guest OS 145 (including the root disks) are modified or updated, without impacting the original guest OS 130 which can continue to run in the original Virtual Machine 125 while the cloned guest OS 145 is concurrently modified or updated. Software for the cloned guest OS 145 is updated by updating or modifying data in the memory area 114 which maps the cloned guest OS 145. In one alternative, the DRD application 120 updates or modifies to the cloned guest OS 145, in response to a DRD run command 165 sent via the user interface 117 from a system administrator or other user. A DRD run command executes a software management command on the software in a cloned (inactive) system image.
An update source 167, which may be a node coupled via a communications network 171 to the apparatus 100, or may be local files in the host OS or a VM, sends the updates 169 that will update or modify the cloned guest OS 145. For example, the update source 167 sends patches, service packs, new software versions, or other types of updates that will update or modify the cloned guest OS 145. These updates 169 will modify the data in the memory area 114 which maps the cloned guest OS 145. The type of updates 169 that modifies or updates the cloned guest OS 145 is dependent on the operating system type of the cloned guest OS 145.
When used to modify the OS on an inactive system image, the DRD application 120 can update the cloned guest OS 145 while the guest OS 130 concurrently runs in the original Virtual Machine 125, and the updates to the cloned guest OS 145 will not impact the concurrently running original guest OS 130.
Alternatively, if the cloned guest OS 145 is updated, after the cloned guest OS 145 is booted in the new Virtual Machine 150, the updates to the cloned guest OS 145 can be done using software maintenance tools for that OS and will also not impact the original guest OS 130 which is concurrently running in the Virtual Machine 125.
With either alternative, once the updates or maintenance that are performed on the cloned guest OS 145 are acceptable to a system administrator, and once the new VM has it's own identity, the routing engine 170 will route all data traffic 172 that is intended for transmission to the original guest OS 130 to the updated guest OS 145. The data traffic 172 can be, for example, requests, function calls, or other types of data transmissions that is to be processed by an operating system.
As an example, the routing engine 170 can have a translation table 174 that permits the routing engine 170 to route all data traffic 172 intended for transmission to the original guest OS 130 to the updated guest OS 145. The routing engine 170 can use other suitable methods for routing data traffic 172 intended for the original guest OS 130 to the updated guest OS 145. The routing engine 170 can, for example, be a separate software code and/or component, or can be software code and/or component that is integrated with the VM application 115, host OS 110, or DRD application 120. Those skilled in the art will realize based upon the reading of this disclosure that the features of the routing engine 170 can be implemented in various manners in the apparatus 100.
The routing engine 170 can also bring offline, disconnect from receiving the traffic 172, and/or delete the original Virtual Machine 125 and original guest OS 130, when the routing engine 170 starts forwarding traffic 172 intended for the original guest OS 130 to the updated guest OS 145. The routing engine 170 can make the modification to the data in the memory area 112 which maps the original Virtual Machine 125 and original guest OS 130, so that the Virtual Machine 125 is brought offline, disconnected from receiving the traffic 172, and/or deleted.
The DRD application 120 can also clone one or more additional guest OS 140 in the Virtual Machine 135. The additional guest OS 140 may be a different operating system type from the guest OS 130 in the Virtual Machine 125. The DRD application 120 will cause the VM application 120 to create or start a new Virtual Machine 175 which will support the cloned guest OS 177 which is the clone of the original guest OS 140. The DRD application 120 can also assign an identity 180 for the cloned guest OS 177. The identity 180 will be different from the identity 182 of the original guest OS 140 in the Virtual Machine 135. Tools used to software maintenance for that OS can update or modify the cloned guest OS 177 in the new Virtual Machine 175 while the original guest OS 140 concurrently runs in the original Virtual Machine 135, as similarly discussed above.
Alternatively, DRD 120 can be used to update the cloned guest OS 177 when the guest OS 177 is inactive, and the updated cloned guest OS 177 is then changed to the identity 180 and is then booted in the new Virtual Machine 175, and the updates to the cloned guest OS 177 will also not impact the original guest OS 140 which is concurrently running in the Virtual Machine 135.
When the cloned guest OS 177 has been updated or modified and the identity changed, the routing engine 170 can then forward data traffic 172 intended for the original guest OS 140 to the updated guest OS 177. The routing engine 170 can also bring offline, disconnect from receiving traffic 172, and/or delete the original Virtual Machine 135 and original guest OS 140 in a manner as similarly discussed above. Therefore, embodiments of the invention permit a system administrator to update or maintain multiple different types of operating systems (e.g., guest OS 130 and guest OS 140 which are different operating system types) by cloning the original operating systems and updating the cloned operating systems, without impacting the original operating systems that can concurrently run in the original Virtual Machines.
These cloned operating system images can be used for maintenance (i.e., updates) and/or safety failover (i.e., if the original guest OS 130 fails, then the routing engine 170 can route the traffic 172 to the cloned guest OS 145 which will take over the functions of the failed guest OS 130). The DRD application 120 advantageously reduces the system down time for information technology systems by allowing system administrators to update and maintain the system (even during peak times) without affecting the running original operating system. Also, embodiments of the invention advantageously allow a system administrator to support, manage, or update different types of operating systems that are supported in the Virtual Machines. In contrast, previous solutions that perform cloning (e.g., IBM Alternate Root Disk, Sun Live Upgrade, Symantec Norton Ghost, and Microsoft DPS) are only used to back up their respective host operating system, and do not have the capability to clone multiple different types of operating system images within a Virtual Machine.
In block 210, the DRD 120 is used to clone an existing guest OS that is running in a first Virtual Machine (VM).
Either block 213 or block 211 is then performed. If block 213 is performed, then the DRD 120 is used to perform software maintenance (i.e., updates) on an inactive operating system image that was created by the clone step in block 210. This inactive operating system image is the clone of the existing guest OS in the first Virtual Machine, and this image is not yet running in a virtual machine. In block 214, the identity of the inactive operating system image is changed, and the image is then booted in a new Virtual Machine.
Alternatively, after performing the steps in block 210, if block 211 is performed, then the identity of the operating system image that was created by the clone step in block 210 is changed, and the image is then booted in a new Virtual Machine. In block 212, software maintenance is performed on the new Virtual Machine. This step involves performing software maintenance on the image that is running in the new Virtual Machine.
After the steps in block 212 (or in block 214) are performed, in block 220, the updated guest OS (i.e., the updated image) in the new Virtual Machine is allowed to take over the functions of the original guest OS that was previously cloned in block 210.
In block 225, the steps are repeated in blocks 210, 213, 214, and 220 (or the steps are repeated in block 210, 211, 212, and 220) for another guest OS that is a different operating system type than the original guest OS type that was running in the first Virtual Machine. Therefore, different operating system types can be cloned and updated in different Virtual Machines.
It is also within the scope of the present invention to implement a program or code that can be stored in a machine-readable or computer-readable medium to permit a computer to perform any of the inventive techniques described above, or a program or code that can be stored in an article of manufacture that includes a computer readable medium on which computer-readable instructions for carrying out embodiments of the inventive techniques are stored. Other variations and modifications of the above-described embodiments and methods are possible in light of the teaching discussed herein.
The above description of illustrated embodiments of the invention, including what is described in the Abstract, is not intended to be exhaustive or to limit the invention to the precise forms disclosed. While specific embodiments of, and examples for, the invention are described herein for illustrative purposes, various equivalent modifications are possible within the scope of the invention, as those skilled in the relevant art will recognize.
These modifications can be made to the invention in light of the above detailed description. The terms used in the following claims should not be construed to limit the invention to the specific embodiments disclosed in the specification and the claims. Rather, the scope of the invention is to be determined entirely by the following claims, which are to be construed in accordance with established doctrines of claim interpretation.
