Rebooting a hypervisor without disrupting or moving an associated guest operating system

N/A

Aspects of the invention are generally related to data storage, and more particularly to program code such as a hypervisor which supports virtual hosts associated with a data storage subsystem. Enterprise and service provider data storage systems are used to maintain relatively large data sets. A simple data storage subsystem includes a storage array and one or more hosts. Applications Read and Write data by sending JO requests to hosts. The hosts translate the JO requests from a format characterized by designators used by applications, e.g., filename, into a format characterized by designators used by the storage array, e.g., LUN, cylinder and track, in order to prompt a Read or Write in accordance with the JO requests. Clusters of data storage subsystems can be organized into a data center. Groups of data centers can be organized into a single enterprise or service provider data storage system.

It is known to implement multiple virtual hosts on a single physical hardware platform such as a line card or server. A computer program such as a hypervisor manages sharing of the resources of the hardware platform among the virtual hosts. In particular, the hypervisor manages operation of guest operating systems which are associated with the virtual hosts by sharing processing and memory resources such that, from the perspective of each guest operating system, the resources appear to be dedicated to that guest operating system. Consequently, individual hardware platforms need not be dedicated to individual hosts, and a variety of virtual hosts may be supported by a physical host device.

One drawback to virtual hosts is that a hypervisor reboot can be particularly disruptive. Unlike a reboot of a non-virtualized physical host device, reboot of a virtualized host platform tends to disrupt multiple guest operating systems. In the case of a planned reboot, storage administrators typically shut down the guest operating systems or migrate those guest operating systems to another hypervisor located on another server before rebooting the hypervisor, e.g., before upgrading the hypervisor code. Consequently, the advantages of supporting multiple virtual hosts on a single hardware platform lead to disadvantages when a reboot is performed.

In accordance with an aspect of the invention, a method comprises: on a hardware platform in which a plurality of guest operating systems and a plurality of containers are implemented, each container being associated with one the guest operating systems and managing access of the associated guest operating system to processing resources and volatile memory of the hardware platform, performing a reboot by suspending operation of ones of the guest operating systems, rebooting ones of the containers while preserving at least some contents of the volatile memory, and resuming operation of the suspended guest operating systems.

In accordance with another aspect of the invention, a computer program stored on a non-transitory computer-readable medium comprises: on a hardware platform in which a plurality of guest operating systems and a plurality of containers are implemented, each container being associated with one the guest operating systems and including logic which manages access of the associated guest operating system to processing resources and volatile memory of the hardware platform, logic which performs a reboot by suspending operation of ones of the guest operating systems, logic which reboots ones of the containers while preserving at least some contents of the volatile memory, and logic which resumes operation of the suspended guest operating systems.

In accordance with another aspect of the invention, an apparatus comprises: on a hardware platform in which a plurality of guest operating systems and a plurality of containers are implemented, each container being associated with one the guest operating systems and including logic stored in volatile memory which manages access of the associated guest operating system to processing resources and the volatile memory of the hardware platform, reboot logic stored in non-transitory computer-readable memory which performs a reboot by suspending operation of ones of the guest operating systems, reboots ones of the containers while preserving at least some contents of the volatile memory, and resumes operation of the suspended guest operating systems.

Advantages associated with aspects of the invention include a non-disruptive, non-migratory hypervisor reboot which is transparent to the associated guest operating systems. Suspending execution of the guest operating system and maintaining at least some of the contents of the volatile memory at the same addresses helps to enable the reboot to be performed without disrupting or migrating the guest operating system. For example, state information associated with the guest operating system may be maintained. Further, that state information is present at the same address following reboot so the guest operating system can quickly resume operation after the reboot. Consequently, if the reboot process can be completed within a brief period of time, e.g., on the order of milliseconds, it will be transparent to the guest operating system.

Another advantage is a non-disruptive, non-migratory hypervisor reboot which includes relocating some or all of the contents of the volatile memory to different addresses. An abstraction layer can be created between the suspended guest operating system and the volatile memory such that an address translation associates the original addresses with new addresses. Hence, from the perspective of the guest operating system, the contents of the volatile memory will not have changed after resumption of execution even though those contents will actually have been relocated in association with the reboot.

Other features and advantages will become apparent in view of the figures and detailed description.

FIG. 1 illustrates a non-disruptive, non-migratory hypervisor reboot.

FIG. 2 illustrates a data storage subsystem in a simplified network environment.

FIG. 3 illustrates a non-disruptive, non-migratory hypervisor reboot in greater detail.

FIG. 4 illustrates aspects of loading updated hypervisor code in greater detail.

Various aspects of the invention may be implemented partially or completely in software using computer program code. The computer program code is stored on non-transitory computer-readable memory and utilized by processing hardware to implement instructions corresponding to certain steps. The program code may be provided as a computer program product or be integrated into network storage equipment. All of the illustrated devices may include processing hardware and non-transitory storage media capable of storing and implementing computer program code.

Referring to FIGS. 1 and 2 , a non-disruptive, non-migratory hypervisor reboot can be performed in accordance with an aspect illustrated with reference to a simplified network environment in which applications running on devices such as user terminals 100 1 through 100 n (including but not limited to personal computing devices of any kind) and servers 102 1 through 102 n (including but not limited to computing devices of any kind which perform tasks for other devices) utilize data maintained by a data storage subsystem 106 via a network 104 . The data storage subsystem 106 , e.g., the Symmetrix system of EMC corporation, may include a storage array 108 and one or more physical host devices 110 (only one shown for simplicity), e.g., line cards. The storage array 108 includes physical storage devices which may be organized as a RAID group characterized by striping, parity, or both. Various abstraction layers 112 may be presented between the hosts 110 and the storage array 108 . For example, data storage space on physical devices may be organized into virtual volumes. Moreover, the storage array may be tiered, thinly provisioned, and otherwise organized in accordance with any of a wide variety of techniques.

Each physical host device 110 includes volatile memory resources 114 and processing resources 116 . Examples of volatile memory resources 114 include but are not limited to random access memory (RAM), such as dynamic RAM (DRAM).

Examples of processing resources 116 include but are not limited to physical processors and individual cores thereof. Hypervisor code, which may be maintained in the volatile memory, manages sharing of the volatile memory resources and processing resources between multiple guest operating systems 118 1 - 118 n . In particular, a set of corresponding container instances 120 1 - 120 n is provided, one container per guest operating system, where the set of containers comprise the hypervisor. Each container manages, for its associated guest operating system, access to the volatile memory resources and processing resources. Each guest operating system may be allocated an amount of space in the volatile memory 114 , e.g., a segment defined by a range of addresses. Execution of threads associated with different guest operating systems is performed by the processing resources 116 in accordance with scheduling algorithms. From the perspective of an individual container, a non-disruptive, non-migratory hypervisor reboot can be made transparent to the associated guest operating system via the steps of suspending execution of the guest operating system 122 , rebooting the container 124 , and then resuming execution of the guest operating system 126 .

FIG. 3 illustrates aspects of the non-disruptive, non-migratory hypervisor reboot in greater detail. Commencing from normal operation 300 in which the storage subsystem is online and the guest operating systems are running in the associated containers, the reboot procedure is prompted when the storage subsystem receives a communication 130 ( FIG. 2 ) including a request to reboot the hypervisor/container without disrupting the guest operating system as shown in step 302 . The communication may be sent from a remote management station 132 ( FIG. 2 ) via the network. In response to the request each container stops giving CPU cycles (access to the processing resources) to the associated guest operating system as indicated in step 134 in order to suspend operation of the associated guest operating system. The container then loads or reloads itself while preserving the contents of the volatile memory in place as indicated in step 136 . More particularly, upgraded code, which may be included in the communication, may be copied over the existing code, or the existing code may be reloaded at the same memory space. In either case the contents of the volatile memory are maintained, i.e., at the same addresses, although it will be appreciated that upgraded code may occupy a substantially similar address space as the existing code due, for example, to differences in size between the existing and upgraded code. However, state information associated with the guest operating system is maintained in place. The container then resumes operation, including giving CPU cycles to the guest operating system, as indicated by step 138 .

Maintaining some or all of the contents of the volatile memory at the same addresses helps to enable the reboot to be performed without disrupting or migrating the guest operating system. For example, maintaining state information associated with the guest operating system at the same address following reboot helps enable the guest operating system to resume normal operation. Consequently, if the reboot process can be completed within a brief period of time, e.g., on the order of milliseconds, it will be transparent to the guest operating system.

It is also possible to relocate some or all of the contents of the volatile memory to different addresses without disrupting or migrating the guest operating system. For example, an abstraction layer 140 ( FIG. 2 ) can be created between the guest operating system and the volatile memory such that an address translation associates the original addresses with new addresses as indicated in step 136 . For example, page tables or an equivalent technique might be utilized. Hence, from the perspective of the guest operating system the contents of the volatile memory will not have changed even though those contents will actually have been relocated in association with the reboot.

FIG. 4 illustrates further aspects of a hypervisor update. Suspending the guest operating system in preparation for the update includes quiescing all threads and disabling interrupts as indicated by steps 400 and 402 . In particular, threads associated with various different guest operating systems are quiesced. Unzipper boot code provided by the remote management station is loaded into a segment of memory as indicated by step 404 . Unzipper boot then loads the new code over the existing code in memory as indicated by step 406 . The unzipper boot jumps to the newly loaded code, e.g., sets a pointer to begin operation, as indicated by step 408 . The new hypervisor code, including the new containers, then resumes executing using the preserved contents of volatile memory as indicated by step 410 , thereby avoiding disruption and migration of the associated guest operating system.

While the invention is described through the above exemplary embodiments, it will be understood by those of ordinary skill in the art that a wide variety of modifications to and variations of the illustrated embodiments may be made without departing from the inventive concepts herein disclosed. Moreover, while the embodiments are described in connection with various illustrative structures, one skilled in the art will recognize that the system may be embodied using a wide variety of specific structures. Moreover, various features, aspects and embodiments may be combined in any of various ways without departing from the inventive concepts herein disclosed. Accordingly, the invention should not be viewed as limited except by the scope and spirit of the appended claims.