Abstract:
A virtual machine (VM) is created using an alternate root disk (DRD) that has complete isolation between the booted system environment (BSE) running on the host operating system and the BSE running on the VM&#39;s operating system. The VM&#39;s root disk and BSE are separately bootable from the host system&#39;s root disk and BSE, thereby allowing for updates and modifications to the VM&#39;s root disk and BSE without interference with the host system&#39;s root disk and BSE regardless of how many times the updating BSE must be rebooted during the updating procedure. At most a single reboot is required in order to transfer the work in progress from the VM to the host system.

Description:
FIELD OF THE INVENTION 
       [0001]    This invention relates to computer systems and more importantly to systems and methods for improving update and reboot operations. 
       DESCRIPTION OF RELATED ART 
       [0002]    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. 
         [0003]    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. 
         [0004]    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. 
         [0005]    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. 
       BRIEF SUMMARY OF THE INVENTION 
       [0006]    An update procedure having a single reboot operation is constructed using a virtual machine (VM) created using another system&#39;s dynamic root disk (DRD), such that there is complete “isolation” between the VM&#39;s BSE and the original system&#39;s BSE. This isolation extends to applications running on the original system&#39;s OS and applications running on the VM&#39;s OS. The VM&#39;s root disk is separately bootable from the original system&#39;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. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0007]    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: 
           [0008]      FIGS. 1A through 1E  show embodiments of a multi-application system having a VM for isolation of applications during the update procedure; 
           [0009]      FIG. 2  shows one embodiment of a method for controlling the illustrative embodiments shown in  FIGS. 1A-1E ; and 
           [0010]      FIG. 3  shows one embodiment of a system having a VM booted from the original root disk. 
       
    
    
     DETAILED DESCRIPTION 
       [0011]      FIG. 1A  shows one embodiment  10  of a multi-application ( 12 - 1  to  12 -N) host system. The host system has a booted system environment (BSE)  11  that is booted from its original root disk (ORD)  15 . A copy of ORD  15  is made and becomes dynamic root disk (DRD)  16 . As will be seen, DRD  16  can be completely updated while BSE  11  (booted from ORD  15 ) is running and serving its normal purposes. BSE  11 , including applications, platforms, partitions and booting from either ORD or DRD is controlled, at least in part, by one or more processors, such as by processor  17 . 
         [0012]      FIG. 1B  shows the establishment of VM  14  booted from dynamic root disk (DRD)  16 , which was copied from the host system&#39;s ORD  15 . Ownership of DRD  16  was transferred from host system  11  to VM  14 , which includes any “personality changes” (e.g. change network identification to that of the VM system) that are needed before the VM system could have been booted from the DRD. The VM&#39;s BSE runs while the host system&#39;s BSE  11  continues to process applications  12 - 1  through  12 -N. At this point any resource (including applications, operating system, or other computer environment elements) running on the VM system can be updated in VM process  14  without affecting host system&#39;s BSE  11  including the running of applications  12 - 1  through  12 -N. All updates are stored on DRD  16  without affecting ORD  15 . Testing and rebooting can occur with respect to VM  14  without affecting the host system&#39;s BSE  11  and there is no cross-linking of applications between BSE  11  and BSE  14 . The applications need not be modified in any manner to have this work. 
         [0013]      FIG. 1C  shows anew set of applications  13 - 1  through  13 -N (corresponding to the applications  12 - 1  through  12 -N) being run within the VM&#39;s BSE  14  after the VM has been updated. This allows the applications to be tested in the updated BSE  14 , before these updates are applied to host system  11 . If any problems are discovered, the VM&#39;s BSE  14  can be further updated. It is also possible, that if the updates are considered unacceptable, the entire VM and its DRD can be destroyed. Again, there is no cross-linking of applications between BSE  11  and BSE  14 . 
         [0014]      FIG. 1D  shows the state of host system  11  after all update and test procedures have occurred but before rebooting from the DRD. Note that VM process  14  has been terminated and ownership of DRD  16  has been transferred back to host system  11 . Ownership transfer of the DRD back to the host system  11  includes any “personality changes” (e.g. change network identification to that of the host system) that are needed before the host system can be booted off the DRD. 
         [0015]      FIG. 1E  shows host system  11  rebooted from DRD  16  instead of from its original root disk  15 . Since the DRD contains the stored version of the updates that were performed as discussed above, host system  11  is updated with only one reboot. Applications  12 - 1  through  12 -N are again running, this time on an updated, BSE  11 . The user can control which boot disk to boot from. The choice could be a part of starting the system or can be made an explicit choice of the user upon startup. Thus, a user when starting the cloning process, can tell the system to do the whole process, including rebooting with the DRD, or the user can tell the system not to reboot from the DRD. There are interfaces that tell the system firmware what disk to boot from. HP-UX, for example, has the “setboot” command, that says: in the future, boot from disk A, and if disk A is unavailable, boot from disk B. The system and method discussed herein could use setboot on HP-UX. There are other approaches on other operating systems. 
         [0016]      FIG. 2  shows one embodiment  20  of a method for controlling the illustrative embodiments shown in  FIGS. 1A through 1E . Process  201  clones the original root disk ( FIG. 1A , image  15 ) of the host system&#39;s booted system environment (BSE)  11  in order to create dynamic root disk (DRD)  16 . Process  202  creates a virtual machine to be run within the host system&#39;s BSE  11 , to be booted from DRD  16 . Process  202  transfers ownership of DRD  16  to VM  14 , making whatever “personality changes” are deemed necessary. Process  203  controls the booting of VM  14  from DRD  16 . 
         [0017]    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. 
         [0018]    Process  205  determines if a reboot is necessary. If it is, the reboot is performed via process  206 . 
         [0019]    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. 
         [0020]    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. 
         [0021]    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. 
         [0022]    Note that while a VM has been shown running within a host system&#39;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&#39;s DRD, the VM is shutdown, the other system boots from the DRD, and is updated with only one reboot. 
         [0023]      FIG. 3  shows one embodiment  30  having host system  31 . Original VM  32  having applications  33 - 1  to  33 -N running therein is booted on host system  31  from original root disk  15  while VM  14 , also booted on host system  31 , is, as discussed above, booted from DRD  16 . Once all of the changes/updates are made to DRD  16  (as discussed above) original VM  32  is booted from DRD  16  instead of from ORD  15 . 
         [0024]    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. 
         [0025]    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.