1. Field of the Invention
The present invention relates to a virtual machine system managed by a host OS that virtually operates on hardware.
2. Description of the Related Art
A virtual machine system 160 shown in
The host OS 162 is an OS that operates as a domain of the virtual machines such as the guest OSs 163, the driver OSs 164 and the like, and that manages the guest OSs 163 and the driver OSs 164 while communicating with the virtual machine monitor 165. The host OS 162 is an OS that is automatically activated at the time of boot of the virtual machine system 160. The host OS 162 manages resources of the entire virtual machine system 160, allocates the resources and controls operations (activation, termination and the like) of the guest OSs 163 and the driver OSs 164. In other words, the host OS 162 is an OS that manages the virtual machine system 160. The host OS 162 can operate also as the driver OS at the same time.
The guest OSs 163 are OSs that do not have an I/O (Input/Output) device as a configuration of the virtual machine, and are conventional OSs to be used by users.
The driver OSs 164 are OSs that control operations of an I/O device 166 as an external recording device such as a hard disk, a Read Only Memory (ROM) and the like, and an I/O device 167 for a connection with the network, while communicating with the guest OSs 163 via the virtual machine monitor 165. The driver OSs 164 actually execute the I/O devices 166 and 167. The guest OSs 163 execute the I/O devices 166 and 167 by issuing requests to the driver OSs 164. The driver OSs 164 can operate also on the host OS 162 and on the guest OSs 163. When the driver OSs 164 operate on the guest OSs 163, the driver OSs 164 serve as driver OSs of the corresponding guest OSs 163.
The virtual machine monitor 165 is a layer for controlling the entire virtual machine system 160, and controls dispatch of the respective OSs, emulation of privileged instructions executed by the respective OSs, and the hardware related to the CPU.
For example, when a user performs an operation to activate the host OS 162, the host OS 162 is activated, and an operation window of the host OS 162 is displayed on a display device 168 connected to the virtual machine system 160. When the user selects the activation of the guest OSs 163 on the operation window of the host OS 162, the guest OSs 163 are activated and the operation window of the guest OSs 163 is displayed on the display device 168. When the user selects the execution of the I/O device 166 on the display window of the guest OSs 163, an execution request of the I/O device 166 is issued from the guest OSs 163 to the virtual machine monitor 165 via a Frontend Driver 169, as shown in
Based on the above virtual machine system 160, various virtual machines are conventionally realized.
For example, there is a technique in which a virtual machine is transferred between the virtual machine systems by including means which assigns common logic names to real machine resources of the respective virtual machines and manages the resources. (See the Patent Document 1, for example)
For example, there is also a technique in which hardware resources are virtually divided into two or more sections, two or more OSs simultaneously operating on the divided virtual hardware are prepared. This makes it possible to read and write a part of memory managed by arbitrary virtual hardware that is among the divided virtual hardware for an OS operating on other virtual hardware, hold it in memory the information for a failure recovery of software operated by an OS on other virtual hardware, and use the information for the failure recovery of the software. (See the Patent Document 2, for example)
However, in a virtual machine system as above, generally, one host OS is provided for a virtual machine system, and one driver OS is provided for an I/O device. Accordingly, communications between a guest OS and an I/O device can not be controlled when a failure occurs in a host OS or in a driver OS. Therefore, there is a problem that the virtual machine system cannot be operated after this type of failure, and the reliability of the virtual machine system is decreased.
As a method for solving this problem, it is possible that a spare host OS or a spare driver OS functioning similarly to the host OS or the driver OS is prepared in advance, and when a failure occurs in the current host OS or the current driver OS, the spare host OS or the spare driver OS takes over the processes and data of the current host OS and the current driver OS.
As a method of preparing the spare host OS or the spare driver OS, there is a method, for example, in which software for realizing the spare host OS or the spare driver OS is prepared in addition to software for realizing the current host OS or the current driver OS, thus the software for realizing the host OS or the driver OS is duplicated. It is also possible, for example, that hardware for realizing the spare host OS or the spare driver OS is prepared, and the hardware for realizing the host OS or the driver OS is duplicated.
As a method in which the spare host OS or the spare driver OS takes over the processes and data of the current host OS and the current driver OS when a failure occurs in the current host OS or in the current driver OS, a technique called fall over can be employed, for example.
By configuring a virtual machine system as above, even when a failure occurs in a current host OS or a current driver OS and communications between a guest OS and an I/O device cannot be controlled, it is possible that a spare host OS or a spare driver OS can take over the processes and data of the current host OS and the current driver OS, accordingly, the communication between the guest OS and the I/O device is not cut so that it is possible to suppress decrease of reliability of the virtual machine system.
Patent Document 1
Japanese Patent Application Publication No. 10-283210
Patent Document 2
Japanese Patent Application Publication No. 2001-101021
However, as stated above, there is a problem that it takes much cost of the virtual machine system to duplicate software and to duplicate hardware in the case that a spare host OS or a spare driver OS is prepared in advance by the duplication of software or by the duplication of hardware such that the spare host OS or the spare driver OS takes over the processes and data of the current host OS and of the current driver OS by fall over.
Further, when the spare host OS or the spare driver OS takes over the processes and data of the current host OS and the current driver OS, if the state of the spare host OS or of the spare driver OS is to be kept as late as possible, it is necessary that the change of state of the current host OS and the current driver OS is reflected on the spare host OS or the spare driver OS in advance. In order to have completed the reflection of the change of state on the spare host OS or on the spare driver OS before performing fall over, it is necessary to always monitor the change of state between the current host OS and the spare host OS or between the current driver OS and the spare driver OS, and to perform synchronization between data. Due to this necessity, the process such as above takes further cost of the virtual machine system.
It is an object of the present invention to provide a virtual machine system to function with a suppressed cost, even when the spare host OS or the spare driver OS is prepared.
In order to achieve the above object, the present invention employs the configurations below.
The present invention provides a virtual machine system managed by a current host OS, virtually operating on hardware, that copies the current host OS to prescribed recording means (for example, a memory device such as RAM provided in the virtual machine system) provided in the virtual machine system when the current host OS is activated. A spare host OS, having the same function as that of the current host OS, is caused to operate on the hardware, and is notified of a request issued to the current host OS to change state. The virtual machine system switches an OS for managing the system from the current host OS to the spare host OS, when the current host OS gets in an erroneous state.
In the above configuration, is it possible to always keep the state of the spare host OS as the same as the state of the current host OS. Accordingly, even when the current host OS gets in an erroneous state, due to a failure occurring in the current host OS, the spare host OS can take over the process and data from the current host OS in the latest state as the host OS for managing the virtual machine system instantaneously. Therefore, the operation of the virtual machine system does not stop even when the current host OS gets in an erroneous state, and thereby being able to suppress the decrease of the reliability of the virtual machine system. Also, it is possible to suppress cost of the virtual machine system because the software or the hardware for providing the spare host is not duplicated and it is not necessary for the current host OS or the spare host OS to always monitor the state of each other, or to perform synchronization between data.
In the present invention, it is also possible to employ the configuration wherein, if a request issued to the current host OS is a request by which a state of the current host OS is changed, the spare host OS is notified of the request.
Thereby, it is possible to reduce the load on the virtual machine system compared to the configuration in which the spare host OS is notified of all the requests issued to the current host OS.
Additionally, the present invention provides a virtual machine system managed by a current host OS, virtually operating on hardware, that copies a current driver OS to prescribed recording means provided in the virtual machine system when the current driver OS for controlling operations of an I/O device provided in the virtual machine system is activated. The system causes a spare driver OS, having the same function as that of the current driver OS, to function on the hardware, notifies the spare driver OS of a request issued from a guest OS virtually operating on the hardware to the I/O device via the current driver OS, and changes a state of the spare driver OS. The system then notifies the spare driver OS of an operation completion notice issued from the I/O device to the guest OS via the current driver OS, changes a state of the spare driver OS. The system notifies, via the spare driver OS, the I/O device of a request issued from the guest OS, and further notifies, via the spare driver OS, the guest OS of the operation completion notice issued from the I/O device, when the current driver OS gets in an erroneous state.
Therefore, it is possible to always keep the state of the spare driver OS the same as the state of the current driver OS. Accordingly, the spare driver OS as a driver OS for controlling the I/O device can instantaneously take over the process and data of the current driver OS in the latest state even when a failure occurs in the current driver OS and the current driver OS gets in an erroneous state. Therefore, it is possible to suppress a decrease in the reliability of the virtual machine system because the communications between the guest OS and the I/O device are not cut even when the current driver OS gets in an erroneous state. Also, it is possible to suppress costs of the virtual machine system because the software or the hardware is not duplicated and it is not necessary for the current host OS or the spare host OS to always monitor the state of each other, or to perform synchronization between data.
In the present invention, it is also possible to employ the configuration in which the request issued from the guest OS to the I/O device via the spare driver OS is discarded, and the operation completion notice issued from the I/O device to the guest OS via the spare driver OS is discarded, when the current driver OS is not in an erroneous state.
In the present invention, it is also possible to employ the configuration in which a request for an answer is issued to the current host OS or the current driver OS and it is determined that the current host OS or the current driver OS is in an erroneous state when the answer corresponding to the request for an answer is not issued from the current host OS or the current driver OS within a prescribed time period.
According to the present invention, it is possible to construct the virtual machine system with a reduced cost even when the spare host OS and the spare driver OS are prepared.
Hereinbelow, the embodiment of the present invention will be explained, by referring to the drawings.
First, the configuration for realizing the duplication of the host OS is explained.
A virtual machine system 10 shown in
The current host OS 11 is activated when a program and data necessary for operating the current host OS 11 are read from a recording unit such as a hard disk or the like, and the read program and data are written to a memory device such as RAM included in the virtual machine system 10.
The spare host OS 12 is activated when the program and data of the current host OS 11 on the above memory device is copied to another memory device by a live migration function or the like after the current host OS 11 is activated. Because of this, for example, when the current host OS 11 is Linux, the spare host OS 12 of the current host OS 11 becomes also Linux.
The virtual machine monitor 13 also usually (when the current host OS 11 is not in an erroneous state) notifies the spare host OS 12 of a request to the current host OS 11 as an interrupt, and switches the OS for managing the virtual machine system 10 from the current host OS 11 to the spare host OS 12 when the current host 11 gets in an erroneous state.
The live migration function is basically a function of copying contents of a memory device 20 used on one virtual machine to a memory device 21 used on another virtual machine, as described above, by which the contents of the memory device 20 can be copied to the memory device 21 even when the virtual machine as the copy source is operating (arrow “A” of
It is also possible that the spare host OS 12 is configured to have a function of copying between memory devices other than the live migration function.
Next, the operation of the virtual machine system 10 is explained wherein the state of the spare host OS 12 is kept the same as the state of the current host OS 11 after the spare host OS 12 is prepared.
First, the current host OS 11 issues a request to the virtual machine monitor 13 (step S1). For example, the current host OS 11 issues a request of activating a new guest OS to the virtual machine monitor 13 by a Hypervisor call instruction.
Next, upon receiving the above request, the virtual machine monitor 13 processes the request (step S2). For example, upon receiving the request of activating a new guest OS 163, the virtual machine monitor 13 performs the process of activating a new guest OS.
Next, the virtual machine monitor 13 determines whether or not the request is the request by which the state of the current host OS 11 is changed (step S3). Examples of the request by which the state of the current host OS 11 is changed include requests by which contents which are to be managed by the current host OS 11 are changed, such as a request of activating a new guest OS, and/or a request of terminating a driver OS and the like. Also, examples of the request by which the state of the current host OS 11 is not changed include the request by which the contents which are to be managed by the current host OS 11 are not changed, such as a request of displaying a list of guest OSs on a display device and the like.
When it is determined that the request is the request by which the state of the current host OS 11 is not changed (No at step S3), the virtual machine system 10 terminates the process of always keeping the sate of the spare host OS 12 the same as the state of the current host OS 11.
When it is determined that the request is the request by which the state of the current host OS 11 is changed (Yes at step S3), the virtual machine monitor 13 notifies the spare OS 12 of the above request as an interrupt (step S4).
When the spare host OS 12 receives the above request of which the host OS 12 is notified as an interrupt, the spare host OS 12 changes the state of the host OS 12 itself based on the request (step S5), and the virtual machine system 10 terminates the process of always keeping the state of the spare host OS 12 the same as the state of the current host OS 11. For example, when receiving the request of activating a new guest OS, the spare host OS 12 adds the new guest OS to the list of the guest OSs which are managed currently.
First, the current host OS 11 and the spare host OS 12 monitor the state of each other at a prescribed time interval (step ST1). Examples of methods of monitoring the state of each other include a method of monitoring each other by communicating between the current host OS 11 and the spare host OS 12 using a LAN (Local Area Network) or the like.
Next, the spare host OS 12 detects an error of the current host OS 11 (step ST2). For example, it is possible to have the configuration in which the spare host OS 12 issues to the current host OS 11 a request for an answer, and if the answer to the request is not issued from the current host OS 11 within a prescribed time period (for example, five seconds or ten seconds), it is determined that the current host OS 11 got in an erroneous state.
Next, when detecting the error of the current host OS 11, the spare host OS 12 issues to the virtual machine monitor 13 a request of switching of the host OSs (step ST3).
Next, when receiving the request of switching the host OSs, the virtual machine monitor 13 issues, to the current host OS 11, a halt request (step ST4). When receiving the halt request, the current host OS 11 performs a halt process.
Next, the virtual machine monitor 13 performs processes of switching the destination of all the requests from the current host OS 11 to the spare host OS 12 (step ST5).
Then, the spare host OS 12 is assigned the role of the current host OS 11, and manages the virtual machine system 10 (step ST6).
In the above configuration, is it possible to always keep the state of the spare host OS 12 the same as the state of the current host OS 11. Accordingly, even when the current host OS 11 gets in an erroneous state due to a failure occurring in the current host OS 11, the spare host OS 12 can take over the process and data from the current host OS 11 in the latest state as the host OS for managing the virtual machine system 10 instantaneously. Thereby, the operation of the virtual machine system 10 does not stop even when the current host OS 11 gets in an erroneous state, such that it is possible to suppress the decrease of the reliability of the virtual machine system 10.
Additionally, compared to the conventional case where spare OSs are prepared in advance by duplication of software or duplication of hardware in order that the spare OS takes over processes and data of the current host OS by the fall over, it is possible to suppress cost of the virtual machine system 10 because the software or the hardware is not duplicated and it is not necessary for the current host OS 11 or the spare host OS 12 to always monitor the state of each other, or to perform synchronization between data.
In the above embodiment, the configuration is employed as shown in the flowchart of
Next, the configuration of realizing the duplication of the driver OS will be explained.
A virtual machine system 50 shown in
When the current driver OS 53's operating program and data are written to a memory device such as RAM or the like, in order to activate the current driver OS 53, the spare driver OS 54 is activated when the current driver OS 53's program and data on the corresponding memory device are copied to a memory device managed by another virtual machine using the live migration function or the like, similarly to the duplicate of the above host OS.
As shown in
Next, the operation of the virtual machine system 50 for maintaining the state of the spare driver OS 54 the same as the current driver OS 53 will be explained.
First, the guest OS 51 issues a request to operate the I/O device 52 to the virtual machine monitor 55 (step STP1).
Next, the virtual machine monitor 55 notifies the current driver OS 53 and the spare driver OS 54 of the above request as an interrupt (step STP2).
Next, the current driver OS 53 and the spare driver OS 54 receive the above request and issue instructions based on the above request to the virtual machine monitor 55 (step STP 3).
Here, the case is explained wherein the request from guest OS 51 is issued for writing prescribed data for the I/O device 52, which is a buffer memory device. As shown in
Next, in
When it is determined that the received instruction is not from the current driver OS 53 (No at step STP4), the virtual machine monitor 55 discards the received instruction as shown in
When it is determined that the received instruction is from the current driver OS 53 (Yes at step STP4), the virtual machine monitor 55 notifies the I/O device 52 of the above instruction as shown in
Next, the virtual machine monitor 55 receives the operation completion notice issued by the I/O device 52 (step STP7).
Next, the virtual machine monitor 55 notifies the current driver OS 53 and the spare driver OS 54 of the above operation completion notice (step STP8).
Next, the current driver OS 53 and the spare driver OS 54 respectively issue the operation completion notice to the virtual machine monitor 55 in order to notify the guest OS 51 (step STP9). For example, the current driver OS 53 and the spare driver OS 54 respectively issue the operation completion notice to the virtual machine monitor 55 by the Hypervisor call instruction.
Next, the virtual machine monitor 55 determines whether or not the received operation completion notice is from the current driver OS 53 (step STP10).
When it is determined that the received operation completion notice is not the notice issued from the current driver OS 53 (No at step STP10), the virtual machine monitor 55 discards the received operation completion notice as shown in
When it is determined that the received operation completion notice is the notice issued from the current driver OS 53 (Yes at step STP10), the virtual machine monitor 55 notifies the guest OS 51 of the received operation completion notice as shown in
Then, the guest OS 51 recognizes that the I/O device 52 has completed the operation (step STP12), and the virtual machine system 50 terminates the process for keeping the state of the spare driver OS 54 the same as the current driver OS 53.
First, the current driver OS 53 and the spare driver OS 54 monitor each other at a prescribed time interval (step STEP1). For example, the above monitoring can be realized by communications between the current driver OS 53 and the spare driver OS 54 using a LAN or the like.
Next, the spare driver OS 54 detects the error in the current driver OS 53 (step STEP2). For example, as shown in
Next, when detecting the error in the current driver OS 53, the spare driver OS 54 issues a request of switching the driver OSs to the virtual machine monitor 55 (step STEP3).
Next, when receiving the request of switching driver Oss, the virtual machine monitor 55 notifies the current driver OS 53 of the halt request (step STEP4). The current driver OS 53 performs a halt process after receiving the halt request.
Next, the virtual machine monitor 55 counterchanges the definition of the master-slave relationship between the current driver OS 53 and the spare driver OS 54 specified by the data 60, notifies the I/O device 52 of the request issued from the guest OS 51 via the spare driver OS 54, and notifies, via the spare driver OS 54, the guest OS 51 of the operation completion notice issued from the I/O device 52 (step STEP5).
Then, the spare driver OS 54 is assigned the role of the current driver OS 53 (step STEP6).
Here, the case is explained, wherein the spare driver OS 54 detects the error in the current driver OS 53, and the virtual machine monitor 55 halts the current driver OS 53, for example. As shown in
Thus, it is possible to always keep the state of the spare driver OS 54 the same as the current driver OS 53. Accordingly, the spare driver OS 54 as a driver OS for controlling the I/O device 52 can instantaneously take over the process and data of the current driver OS 53 in the latest state, even when a failure occurs in the current driver OS 53 and the current driver OS 53 is in an erroneous state. Therefore, it is possible to suppress the reliability decrease of the virtual machine system 50 because communications between the guest OS 51 and the I/O device 52 are not cut even when the current driver OS 53 is in an erroneous state.
It is also possible to suppress cost for the virtual machine system 50, because software or hardware is not duplicated for preparing the spare driver OS 54 and it is not necessary for the current driver OS 53 or the spare driver OS 54 to always monitor change of state of each other, or to perform synchronization between data.
In the above embodiment, the virtual machine system 10 and the virtual machine system 50 are separately explained as the duplication configuration of the host OS and the duplication of the driver OS. However, it is possible to construct the virtual machine system 10 and the virtual machine system 50 in the same virtual machine system.
In the above embodiment, the configuration employed shows the host OS and the driver OS respectively duplicated. However, it is possible to employ respective triplication or further of the host OS and the driver OS.
As shown in
The respective processes performed by the virtual machine system 10 and the virtual machine system 50 are realized when the CPU 140 reads the program and data recorded in the hard disk 142, loads this program and data to the memory device 141, and executes them.
Between the virtual machine system 10 and the virtual machine system 50, the program and data may be exchanged by using the portable recording medium 144. Accordingly, the virtual machine system 10 and the virtual machine system 50 according to the present embodiment can be configured as a computer readable recording medium for causing the computer to execute the respective processes in the above embodiment.
As shown in
Number | Date | Country | Kind |
---|---|---|---|
2006-038557 | Feb 2006 | JP | national |