Patent Application
20080126792
This invention relates to computer systems and more importantly to systems and methods for improving update and reboot operations.
In computer systems, users have an interest in being able to update a system in order to add features, resources or simply to update versions. In most cases, it is desired to perform such updating while the system is running, perhaps with only one reboot, regardless of the complexity of the updating required. However, many update procedures requires several reboot operations, which are time consuming and disruptive when other applications are also being processed concurrently on the computer, especially when the computer or services running on it have high availability requirements.
As presently configured, computer systems have several key components. Among these are a root disk (a.k.a. root file system, root image, or simply, root), on which is stored the non-volatile copy of the operating system (OS). A root disk may by a physical disk, a logical volume, area on a storage area network, etc. The root disk can be part or all of the non-volatile storage of a computer. Computer systems also have a booted system environment (BSE), which includes a running copy of the OS and a set of processes, among which are the application processes. When a system boots up, the OS is started by running the copy stored on the root disk. When the system is updated, those updates are installed on the root disk, such that any time the system boots from the root disk, all installed updates are used.
Computer systems can have alternate copies of their root disk. Each dynamic root disk (DRD, a.k.a. alternate root disk or ARD) is independent of all other root disks, including the currently booted root disk, and each root disk may contain a different OS than on the other root disk. If two root disks initially have identical copies of an OS, changes can be made to one root disk, such that the system will behave differently if booted off one root disk vs. another.
A virtual machine (VM) is a computer system that has no physical hardware. A normal computer system has one or more physical processors, physical memory, one or more physical disks, etc. A VM is a procedure (within the BSE of a host system) that emulates the hardware capabilities of a normal system, including providing virtual processor(s), memory and disk(s) (e.g. one or more root disks). Within the VM is another BSE, which runs on the virtual hardware, including its own root disk. As far as an application process is concerned, there is no difference between being run on a virtual system or a physical system.
An update procedure having a single reboot operation is constructed using a virtual machine (VM) created using another system's dynamic root disk (DRD), such that there is complete “isolation” between the VM's BSE and the original system's BSE. This isolation extends to applications running on the original system's OS and applications running on the VM's OS. The VM's root disk is separately bootable from the original system's root disk, thereby allowing for updates and modifications to one root disk without interference with the other root disk. Regardless of how many times the updating system must be rebooted during an update procedure, the other system need not reboot (the only exception is if the rebooting system is a host to the other, virtual system). After updating one system, that system can be shut down and the root disk transferred to the other system (i.e. the other system boots from the DRD that was updated). At most a single reboot is required in order to change which root disk (and thus OS) a system boots from.
For a more complete understanding of the present invention, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
Process 204 modifies the system resources in VM 14 which are stored on DRD 16. These resources, for example, are the file system and the kernel and are modified or updated as desired.
Process 205 determines if a reboot is necessary. If it is, the reboot is performed via process 206.
Process 207 determines if further modifications are necessary. If they are, they are made via process 204 and processes 204, 205, 206, and 207 continue until there are no further reboots or no further modifications.
Process 208 then tests the updated versions or the added resources and process 209 then determines if the test is satisfactory. If it is not, then process 210 controls the necessary corrections and again processes 205, 206, 207, 208 and 209 determine if the update has been satisfactorily fixed.
When the update is deemed okay for general use (i.e. process 209 determines that the test was satisfactory), process 211 begins to merge the updated system back into the original system by shutting down VM 14 and transferring ownership of DRD 16 to the host system (again making whatever “personality changes” are deemed necessary). Process 212 will shutdown all of the applications on host system 11. Process 213 reboots host system 11 from the DRD. During this reboot process, the host system BSE 11 becomes based upon the updates stored on DRD 16. Process 214 then starts all applications on the updated host system BSE and the merge is complete.
Note that while a VM has been shown running within a host system's BSE, the concepts discussed can be applied to situations where the VM is not running within the host system to update. Thus, any system (physical or virtual) can have its root disk cloned to an DRD. A VM (hosted anywhere that can access the DRD) can boot off the DRD, and perform all of the updating steps. Once done, the VM can shutdown, and the original system booted from the DRD being updated with only one reboot. In addition, since some administrators “update” their system by re-installing the OS (i.e. from scratch), a VM can install an OS from scratch. The VM is used to perform whatever level of customization is desired, and then the root disk is converted into another system's DRD, the VM is shutdown, the other system boots from the DRD, and is updated with only one reboot.
In addition, the VM does not have to be on the same system as the system running the ORD, as long as the bootable image is accessible to another system. One example would be in a SAN boot environment or in any shared disk image. Using this approach the ORD can be cloned and the DRD booted on a different system. When the updates are complete, the VM is shut down and the original system is rebooted on the updated boot image.
While the discuss herein is focused on reducing reboots, there are other benefits to running the DRD in a VM. For example, no matter what changes are made, the running system is not “broken”. This could include things such as kernel tunables, shared libraries, restarting of shared processes/services, etc.
