WO2014045453A1 - Environmental variable storage method, information processing device, and program - Google Patents

Abstract

One or more first processors run a hypervisor and a first and second virtual machine operating on said hypervisor. A second processor does not run the hypervisor or the first and second virtual machines. Of the first processors, the processor running a boot loader for loading an OS on the first virtual machine requests the second virtual machine to save the environmental variable value of the boot loader on a first storage device. When there is no response, the processor running the boot loader requests the second processor to save the environmental variable value on a second storage device. When the second virtual machine reboots after the second processor saves the environmental variable value on the second storage device, the processor, from among the first processors, that began to run the second virtual machine in response to the reboot thereof acquires the environmental variable value from the second storage device or the boot loader and saves the acquired environmental variable value on the first storage device.

Description

Environment variable storage method, information processing apparatus, and program

The present invention relates to a technique for saving the value of an environment variable.

In the computer system, various types of information for indicating the state and environment are used. Various types of information may be defined, for example, in a configuration file (configuration file) or may be defined as environment variables. Various techniques for managing various information while maintaining consistency have also been studied.

For example, a certain system monitoring apparatus monitors and controls the entire computer system by holding the hardware status information of the computer system and the OS software status information of the hardware control instruction by the OS (Operating System) software. When the system monitoring apparatus recognizes changes in the state of the hardware state information and the OS software state information, the system monitoring apparatus stores these pieces of information in the nonvolatile memory as save information.

When the system monitoring device recognizes a restart associated with hot replacement (hot plugging) of the failed system monitoring device, the system monitoring device reads the save information from the nonvolatile memory, and the hardware status information and OS software status before the corresponding device failure Restore information. The system monitoring apparatus recognizes the operating hardware from the save information, and restores the hardware status information generated during the active replacement for the recognized hardware. Further, the system monitoring apparatus recognizes the operating OS software from the save information, and restores the OS software state information generated during the active replacement for the recognized OS software.

Also, an automatic update method for network environment settings as described below has been proposed. This method makes it possible to automatically reflect the network settings changed during the OS operation in the network settings in the absence of the OS depending on the hardware without customizing the core part of the OS. It is a method.

According to this method, the address change detection means peeks at the network packet transmitted to the network adapter. The address change detection means notifies the network information storage means of an event when detecting a change of a network address (for example, an IP (Internet Protocol) address).

The network information storage means acquires the OS network settings and stores the network information. The network information update means compares the network information with the network settings of the extended BIOS (Basic Input Input Output System) and the management controller. If the two are different, the network information updating unit automatically updates the network settings of the extended BIOS and the management controller using the network information.

International Publication No. WO2007 / 085575 Japanese Patent Laid-Open No. 2001-230782

In recent years, the use of virtualization technology using a hypervisor is progressing. However, new issues may arise with virtualization.
Although multiple virtual machines can run on the hypervisor, certain virtual machines may play different roles than other virtual machines, depending on certain architectures. For example, according to a certain architecture, a value of an environment variable of a boot loader for loading an OS into a virtual machine is stored in a storage device via a specific virtual machine.

If the value of the environment variable of the boot loader is not saved properly, there is a risk that it will hinder the next booting of the OS on the virtual machine. On the other hand, the specific virtual machine does not always operate normally. There is also a possibility that a failure occurs in the specific virtual machine.

Therefore, even if the boot loader itself is normal, the value of the environment variable of the boot loader may not be properly saved due to a failure of a specific virtual machine. As a result, a problem may occur that “the failure of a specific virtual machine causes a problem in the future activation of the OS on another virtual machine”.

In one aspect of the present invention, even if a failure occurs in a virtual machine that controls saving of environment variable values of a boot loader among virtual machines that operate on a hypervisor, it is difficult to start an OS of another virtual machine. The purpose is to prevent you from coming.

According to one aspect, an environment variable storage method is provided. For convenience of explanation, the one or more processors for executing the hypervisor and the first and second virtual machines operating on the hypervisor are referred to as “one or more first processors”. A processor that does not execute any of the hypervisor and the first and second virtual machines is referred to as a “second processor”.

In the environment variable storage method, a boot loader for loading an operating system to the first virtual machine out of the one or more first processors is executed on the first virtual machine at a first time point. The first processor issues a first request to the second virtual machine to save the value of the environment variable of the boot loader in the first storage device. If the response to the first request is not returned within the determined time, the processor executing the boot loader sets the value of the environment variable to the second processor to the second value. A second request for saving to the storage device is issued via the hypervisor. Further, the second processor stores the value of the environment variable in the second storage device in response to the second request.

In addition, when the second virtual machine is restarted at a second time after the second processor stores the value of the environment variable in the second storage device, the one or more first virtual machines are restarted. Among the processors of one, the processor that has started execution of the second virtual machine in response to the restart of the second virtual machine at the second time point, from the second storage device or the boot loader, The value of the environment variable is acquired, and the acquired value of the environment variable is stored in the first storage device.

According to the environment variable saving method described above, even if a failure occurs in a virtual machine that controls saving of the environment variable value of the boot loader among virtual machines operating on the hypervisor, the OS of other virtual machines can be started. It won't interfere.

It is a figure explaining various situations regarding preservation | save of the environmental variable of the boot loader for loading OS in a virtual machine. It is a figure explaining that the problem which may arise in a comparative example is solved. It is a hardware block diagram of a computer. It is a figure which illustrates the connection of a computer and another apparatus. It is a block block diagram of the computer of 2nd Embodiment. It is a figure which shows the example of an environment variable table. It is a figure which shows the example of a state list | wrist. It is an operation | movement flowchart of OBP (OpenBoot | PROM) in a guest domain. It is a flowchart of the process which SP (service processor) performs regarding an OBP environment variable. It is a flowchart of the process which a control domain performs regarding an OBP environment variable. It is a flowchart (the 1) of the environment variable update process in 2nd Embodiment. It is a flowchart (the 2) of the environmental variable update process in 2nd Embodiment. It is a block block diagram of the computer of 3rd Embodiment. It is a flowchart of the environmental variable update process in 3rd Embodiment. It is a figure explaining the various situations regarding preservation | save of the environment variable in 4th Embodiment. It is a figure shown by comparing 4th Embodiment and a comparative example. It is a figure which shows the example of an update list. It is a flowchart of the process which SP performs in 4th Embodiment regarding an OBP environment variable. It is a flowchart of the environment variable update process in 4th Embodiment.

Hereinafter, embodiments will be described in detail with reference to the drawings. Specifically, first, the first embodiment will be described with reference to FIGS. 1 to 4 also apply to the second to third embodiments, and FIGS. 3 to 4 also apply to the fourth embodiment.

Thereafter, the second embodiment will be described with reference to FIGS. 5 to 12, and the third embodiment will be described with reference to FIGS. Furthermore, a fourth embodiment will be described with reference to FIGS. Finally, some modifications will be described.

FIG. 1 is a diagram for explaining various situations related to saving environment variables of a boot loader for loading an OS into a virtual machine. As will be described in detail later with reference to FIG. 3, a certain type of computer to which virtualization by the hypervisor is applied has two types of processors having different uses. Specifically, a certain type of computer has the following two types of processors.

One or more processors (hereinafter referred to as “one or more first processors” for the sake of convenience) for executing the hypervisor and a plurality of virtual machines running on the hypervisor (execution) .
Other processors that do not execute the hypervisor and do not execute any virtual machine that operates on the hypervisor (hereinafter referred to as “second processor” for convenience).

There may be a plurality of second processors. However, in the description of FIG. 1, it is assumed that there is one second processor for simplification.

For example, a certain type of computer has one or more CPUs (Central Processing Unit) and a module called “service processor”. Hereinafter, the service processor is abbreviated as “SP”. The SP is a module including another CPU independent of the one or more CPUs and a nonvolatile storage device (for example, a flash memory).

Some SPs monitor voltage and temperature. The SP may have a function of forcibly restarting the entire computer.

For example, in the computer as described above, the one or more CPUs may be the one or more first processors, and the CPU in the SP may be the second processor.

By the way, it is assumed that an OS is installed in each virtual machine on the hypervisor. Each OS is executed on each virtual machine. A hypervisor is also called a “virtual machine monitor”, and a virtual machine operating on the hypervisor is also called a “domain” or a “logical domain”.

In a computer that is not virtualized by the hypervisor, BIOS or the like is used as a broad boot loader for loading and starting the OS. Similarly, in a computer virtualized by a hypervisor, a certain type of boot loader for loading an OS into a virtual machine and starting the OS is used. The boot loader may provide a user interface for performing settings related to virtual hardware.

Also, in a certain kind of virtualization architecture, the environment variable of the boot loader of another virtual machine is managed in a specific virtual machine among a plurality of virtual machines. More specifically, a program module for managing environment variables of boot loaders of other virtual machines may be incorporated in the OS of a specific virtual machine. This type of specific virtual machine is also called a “control domain” (control domain), and a virtual machine other than the specific virtual machine is also called a “guest domain” (guest domain).

FIG. 1 shows a period in which the boot loader 1 of the first virtual machine operates and a period in which the second virtual machine 2 that manages environment variables of the boot loader 1 operates.

Also, as described above, the first virtual machine is executed by any one or more of the first processors, and the second virtual machine is also executed by any one or more of the first processors. Note that one first processor may execute both the first virtual machine and the second virtual machine, and conversely, the first processor and the second processor that execute the first virtual machine. The first processor that executes the virtual machine may be physically different.

On the other hand, the second processor 3 does not execute the hypervisor and does not execute any virtual machine. FIG. 1 also shows a period during which the second processor 3 operates.

Specifically, FIG. 1 shows five situations 4A to 4E. For convenience of explanation, some times are expressed as follows.

The time when the boot loader 1 of the first virtual machine starts operation is expressed as “T_start”.
The time at which the boot loader 1 of the first virtual machine finishes operation (that is, the time at which the OS starts in the first virtual machine) is expressed as “T_end”.
A time when the second virtual machine 2 stops operating for some reason (for example, a time when the second virtual machine 2 shuts down due to an error) is expressed as “T_down”.
Time at which the second virtual machine 2 is restarted (for example, the second virtual machine 2 is restarted according to the manual operation of the administrator, or is automatically controlled by the hypervisor) Is the time when the computer is restarted).

Situations 4A to 4E in FIG. 1 correspond to the following inequalities (A) to (E), respectively.
T_start <T_down <T_end <T_boot (A)
T_start <T_down <T_boot <T_end (B)
T_start <T_end <T_down <T_boot (C)
T_down <T_start <T_boot <T_end (D)
T_down <T_boot <T_start <T_end (E)

For convenience, the following description of FIG. 1 assumes the following.
At least first to third environment variables are defined in the boot loader 1.
At the time indicated by the broken line, the values of the first to third environment variables are “A1”, “B1”, and “C1”, respectively.

While the boot loader 1 is operating (that is, during the period from time T_start to time T_end), any one or more of the first to third environment variables may be updated.

For example, in the situation 4A, the value of the first environment variable is updated to “A2” before the time T_down. Specifically, among the one or more first processors, a processor that executes the boot loader 1 of the first virtual machine on the first virtual machine performs a second operation on the second virtual machine 2. Issue a request to save the value “A2” of the environment variable 1. Then, in response to the request, the value “A2” of the first environment variable is stored.

The value of each environment variable is physically stored in a certain storage device (hereinafter referred to as “first storage device” for convenience) accessible from the second virtual machine 2. The first storage device is a nonvolatile storage device.

Specifically, in the situation 4A, the second virtual machine 2 is operating when the above request for updating the value of the first environment variable to “A2” is issued. Therefore, the processor executing the second virtual machine 2 among the one or more first processors sets the value “A2” of the first environment variable to the first storage device in response to the request. Save and notify the boot loader 1 of the completion of saving. This notification is a response to the request. Specifically, the request and the response may be sent via a hypervisor.

In the situation 4A, the second virtual machine 2 stops operating for some reason at time T_down. Thereafter, the second virtual machine 2 is restarted at time T_boot. On the other hand, even when the second virtual machine 2 is not operating, the boot loader 1 may issue a request for updating the value of the second environment variable to “B2”.

In other words, among the one or more first processors, the processor that is executing the boot loader 1 at a certain time after the time T_down and before the time T_boot gives the second environment variable to the second virtual machine 2. Issue a request to save the value of “B2”. However, the second virtual machine 2 is not operating. Therefore, a response to the request is not returned within a predetermined time.

If no response is returned within a predetermined time, the first processor executing the boot loader 1 sets the second environment variable “B2” to the second value for the second processor 3. Issue a request to save to another storage device. In response to the request, the value “B2” of the second environment variable is stored. The second storage device is a non-volatile storage device accessible from the second processor 3.

Specifically, in the situation 4A, the second processor 3 is operating when the above request for updating the value of the second environment variable to “B2” is issued. Therefore, the second processor 3 stores the value “B2” of the second environment variable in the second storage device in response to the request. The second processor 3 may further notify the boot loader 1 of the completion of saving. This notification is a response to the request. Specifically, the request and the response may be sent via a hypervisor.

In the situation 4A, the OS on the first virtual machine is started from the boot loader 1 at time T_end, and the boot loader 1 stops its operation. Specifically, the OS is started according to the values “A2”, “B2”, and “C1” of the first to third environment variables. That is, the OS is started according to the latest value recognized by the first processor that is executing the boot loader 1 at time T_end.

However, at the time T_end, the latest value “B2” of the second environment variable is not yet reflected in the first storage device. Therefore, the process for reflecting the latest value of the environment variable in the first storage device is performed as follows.

According to the situation 4A, the second virtual machine 2 is restarted at time T_boot after the OS is started from the boot loader 1. Among the one or more first processors, the processor that has started execution of the second virtual machine 2 in response to the restart of the second virtual machine 2 at time T_boot is between time T_down and time T_boot. Try to get the value of a saved environment variable.

Specifically, in the situation 4A, at the time T_boot when the second virtual machine 2 is restarted, the second processor 3 is operating, but the boot loader 1 has already ended. Therefore, only the second storage device holds the latest environment variable value (specifically, the value “B2”) updated during the period when the second virtual machine 2 is not operating. It is.

Therefore, in the situation 4A, the first processor that has started the execution of the second virtual machine 2 in response to the restart of the second virtual machine 2 issues a request to the second processor 3, The value “B2” of the second environment variable stored in the second storage device is acquired. Specifically, the request for the second processor 3 is issued via the hypervisor. Similarly, the value “B2” of the second environment variable is also specifically returned through the hypervisor.

Then, the first processor that has started the execution of the second virtual machine 2 in response to the restart of the second virtual machine 2 sets the second environment variable acquired from the second storage device as described above. The value “B2” is stored in the first storage device. As a result, the update of the environment variable performed while the second virtual machine 2 was not operating is reflected in the first storage device.

The situation 4B is similar to the situation 4A, but is different from the situation 4A in that the boot loader 1 is still operating when the second virtual machine 2 is restarted at the time T_boot. That is, in the situation 4B, at the time T_boot when the second virtual machine 2 is restarted, both the boot loader 1 and the second processor 3 are updated during a period in which the second virtual machine 2 is not operating. The latest environment variable value (specifically, the value “B2”) is recognized. That is, the value “B2” is physically stored in the following two locations at time T_boot.

A memory used by a processor executing the boot loader 1 at time T_boot among one or more first processors.
The second storage device that is accessible from the second processor 3.

In the situation 4B, the first processor that has started the execution of the second virtual machine 2 in response to the restart of the second virtual machine 2 acquires the latest environment variable value from the boot loader 1. Specifically, the first processor that has started the execution of the second virtual machine 2 issues a request for sending the value of the environment variable to the boot loader 1. Then, the first processor that has started the execution of the second virtual machine 2 receives at least the updated value “B2” of the second environment variable from the first processor that is executing the boot loader 1.

The first processor that has started execution of the second virtual machine 2 in response to the restart of the second virtual machine 2 has the value “B2” of the second environment variable acquired from the boot loader 1 as described above. Is stored in the first storage device. As a result, the update of the environment variable performed while the second virtual machine 2 was not operating is reflected in the first storage device.

Note that the values of the first to third environment variables stored in the memory used by the first processor executing the boot loader 1 are all the latest. Therefore, as shown in FIG. 1, the first processor that has started the execution of the second virtual machine 2 may acquire the values of all environment variables from the boot loader 1. It may be stored in the storage device. In the situation 4B, as the second virtual machine 2 is restarted, the three latest values “A2,” “B2,” and “C1” are acquired.

In the situation 4B, the boot loader 1 continues to operate until after the time T_boot. Therefore, after the environment variable on the first storage device is updated to the latest state as described above, the environment variable may be further updated.

For example, in the situation 4B, specifically, the value of the third environment variable is updated to “C2” after the time T_boot. The update of the third environment variable from the value “C1” to the value “C2” is performed in the same manner as the update from the value “A1” to the value “A2” of the first environment variable. Done.

By the way, in the situation 4C, as in the situation 4A and 4B, the first environment variable is changed from the value “A1” to the value “A2” while both the boot loader 1 and the second virtual machine 2 are operating. May be updated. However, in the situation 4C, when the second virtual machine 2 stops operating at the time T_down, the boot loader 1 is not already operating.

Therefore, in the situation 4C, the environment variable is not updated by the boot loader 1 while the second virtual machine 2 is not operating. In other words, according to the situation 4C, when the second virtual machine 2 is restarted at the time T_boot, the values of the environment variables on the first storage device are all the latest. Therefore, in the situation 4C, when the second virtual machine 2 is restarted at time T_boot, the first processor that has started execution of the second virtual machine 2 in response to the restart of the second virtual machine 2 is There is no need to get the value of the environment variable.

By the way, as in the situation 4D, the boot loader 1 may happen to be activated while the second virtual machine 2 is not operating. In this case, the processor that has started execution of the boot loader 1 at time T_start among the one or more first processors requests the second virtual machine 2 to send the values of all the environment variables of the boot loader 1. To do. However, since the second virtual machine 2 is not operating, a response to the request cannot be obtained.

Therefore, the first processor that is executing the boot loader 1 waits for an appropriate time and then requests the second virtual machine 2 to send the values of all the environment variables of the boot loader 1 again. If necessary, the request may be issued more than once.

Then, all the environment variable values are sent from the second virtual machine 2 to the boot loader 1 in response to a request issued from the boot loader 1 after the second virtual machine 2 is restarted at the time T_boot. That is, among the one or more first processors, the processor that has started execution of the second virtual machine 2 in response to the restart of the second virtual machine 2 responds to the request from the boot loader 1 with the first Read all environment variable values from the storage device and return the read values.

As a result, the first processor that is executing the boot loader 1 acquires the value of each environment variable, and can execute an appropriate process using the acquired value as an initial value. For example, in the situation 4D, values “A1”, “B1”, and “C1” are acquired. For example, the first processor that is executing the boot loader 1 may display the acquired three values on the display.

Thereafter, for example, when the operator inputs a command for updating the third environment variable to a value of “C2”, the first processor that is executing the boot loader 1 executes the second virtual machine 2 with respect to the second virtual machine 2. 3 to save the value of the environment variable “C2”. Then, the processor that is executing the second virtual machine 2 among the one or more first processors stores the value “C2” in the first storage device in response to the request. The update from the value “C1” of the third environment variable to the value “C2” is the same method as the update from the value “A1” of the first environment variable to the value “A2” in the situation 4A. Done in

In the situation 4D, the boot loader 1 is started before the second virtual machine 2 is restarted. However, in the first embodiment, as described above, the first processor that is executing the boot loader 1 waits until the initial value of the environment variable is acquired from the second virtual machine 2, and then uses the environment variable. Start processing. Therefore, even if the boot loader 1 is activated before the time T_boot, the environment variable is not updated in response to a request from the boot loader 1 between the time T_down and the time T_boot.

Therefore, in the situation 4D, when the second virtual machine 2 is restarted at the time T_boot, the values of the environment variables on the first storage device are all the latest. Therefore, similarly to the situation 4C, also in the situation 4D, the processor that has started the execution of the second virtual machine 2 in response to the restart of the second virtual machine 2 does not need to acquire the value of the environment variable.

Also, when the boot loader 1 is started after the second virtual machine 2 is restarted as in the situation 4E, the environment variable is updated in response to a request from the boot loader 1 from time T_down to time T_boot. Never happen. Therefore, even in the situation 4E, the processor that has started the execution of the second virtual machine 2 in response to the restart of the second virtual machine 2 does not need to acquire the value of the environment variable.

In situation 4E, the boot loader 1 is started at time T_start after the second virtual machine 2 is restarted. At this time, among the one or more first processors, the processor that has started execution of the boot loader 1 in response to activation of the boot loader 1 sends the values of all the environment variables of the boot loader 1 to the second virtual machine 2. To request.

Unlike the situation 4D, in the situation 4E, the second virtual machine 2 is operating at the time T_start when this request is issued. Therefore, the first processor that is executing the boot loader 1 can obtain the values “A1”, “B1”, and “C1” of the first to third environment variables in response to the request. Similarly to the situation 4D, in the situation 4E, for example, the third environment variable is updated from the value “C1” to the value “C2”, for example, according to the input of the command from the operator. Also good.

As exemplified above, there can be various situations 4A to 4E. According to the first embodiment, in any situation, “the next startup of the OS of the first virtual machine is caused by a failure that occurs in the second virtual machine 2 that controls the saving of environment variables of the boot loader 1. The problem of “being hindered” is avoided.

For example, if the latest value of the environment variable for designating the boot device fails to be stored in the first storage device, the OS of the first virtual machine may be unable to be booted next time. However, according to the first embodiment, even if a failure occurs in the second virtual machine 2, after the second virtual machine 2 is restarted (that is, after the recovery of the second virtual machine 2), the environment variable Is reflected in the first storage device.

Therefore, according to the first embodiment, even if a failure occurs in the second virtual machine 2, there is no problem in the next startup (including restart) of the OS of the first virtual machine. The effects of the first embodiment will be described in detail below with reference to FIG.

FIG. 2 is a diagram for explaining that the problem that may occur in the comparative example is solved. In FIG. 2, the situation 4F according to the comparative example is compared with the situations 4G and 4H according to the first embodiment. In the comparative example shown in the situation 4F, the second processor 3 is not used for saving environment variables of the boot loader 1.

Here, for convenience of explanation, the time at which execution of the boot loader 1 is started again after the OS is started in the first virtual machine at time T_end is expressed as “T_next”. For example, the first virtual machine may be restarted for some reason such as the occurrence of an error. In this case, at time T_next after time T_end, one of the one or more first processors starts executing the boot loader 1 according to a manual operation or automatically controlled by the hypervisor.

For convenience of explanation, the following explanation is assumed in FIG.
At least first to third environment variables are defined in the boot loader 1.
At the time indicated by the broken line, the values of the first to third environment variables are “A3”, “B3”, and “C3”, respectively.

Situation 4F and 4G are both examples of situations where the above inequality (A) holds. More specifically, the inequality (A-2) holds in both situations 4F and 4G. The situation 4H is an example of a situation where the above inequality (B) holds. More specifically, in the situation 4H, the inequality (B-2) is established.

T_start <T_down <T_end <T_boot <T_next (A-2)
T_start <T_down <T_boot <T_end <T_next (B-2)

According to the comparative example, as illustrated in the situation 4F, during the operation of the second virtual machine 2, the value of the first environment variable is normally updated from “A3” to “A4”. However, after the second virtual machine 2 stops operating at time T_down, the processor executing the boot loader 1 stores the value of the second environment variable “B4” in the second virtual machine 2. When requested, the value “B4” is not stored anywhere.

Specifically, in the comparative example, the OS is started on the first virtual machine at time T_end using the values of the first to third environment variables “A4”, “B4”, and “C3”. However, since the value “B4” is not stored in the first storage device, it volatilizes after the OS is started.

Therefore, in the comparative example, when the boot loader 1 is called again on the first virtual machine at the time T_next after the second virtual machine 2 is restarted at the time T_boot, the boot loader 1 obtains the value of the environment variable that is not the latest. Resulting in.

Specifically, among the one or more first processors, the processor that started executing the boot loader 1 at time T_next sends the values of all environment variables of the boot loader 1 to the second virtual machine 2. To request. As a result, the first processor executing the boot loader 1 transfers from the processor executing the second virtual machine 2 at time T_next among the one or more first processors to the first storage device. Get the saved values of the first to third environment variables.

In situation 4F, the following two values are correctly obtained at time T_next.
The value “A4” of the first environment variable updated during the operation of the second virtual machine 2.
The value “C3” of the third environment variable that has not been updated after the time indicated by the broken line.

However, the value “B4” of the second environment variable requested to be updated by the boot loader 1 while the second virtual machine 2 is not operating is not stored in the first storage device in the situation 4F. . That is, the first storage device holds an obsolete value of “B3”. Therefore, the processor that has started execution of the boot loader 1 at time T_next cannot acquire the latest value “B4” of the second environment variable, and acquires the old value “B3”.

Here, it is assumed that the process for changing the value of the second environment variable is not performed after the time T_next. Under this assumption, when the OS is booted from the boot loader 1 at a certain time after the time T_next, the old value “B3” of the second environment variable is used. Then, there is a possibility that the OS of the first virtual machine may become unbootable because the value of the second environment variable is old and inappropriate.

For example, when the second environment variable indicates the OS boot device, the OS may be unable to start. Further, if the value of the environment variable is old, even if the OS can be started, the started OS may not operate as intended by the user. Therefore, even if the OS itself can be started, if the value of the environment variable is old, the OS may be hindered in a broad sense.

As described above, in the comparative example, “if the second virtual machine 2 fails, the update of the environment variable of the boot loader 1 is not reflected in the first storage device, and as a result, the future of the OS of the first virtual machine May cause problems in starting up. " On the other hand, in the first embodiment, such a problem does not occur as shown in the situations 4G and 4H. Specifically, it is as follows.

Situation 4G is similar to Situation 4A. That is, during the operation of the second virtual machine 2, the value of the first environment variable is normally updated from “A3” to “A4”, and the updated value “A4” is the first storage device. Saved in. Also, for the second environment variable requested to be updated by the boot loader 1 while the second virtual machine 2 is not operating, the updated value “B4” is the value after the second virtual machine 2 is restored. It is reflected in the first storage device.

That is, in the situation 4G as well as the situation 4A, the latest value “B4” is temporarily stored in the second storage device in response to a request from the boot loader 1 to the second processor 3. Thereafter, when the second virtual machine 2 recovers at time T_boot, the latest value “B4” is read from the second storage device, and the second virtual machine 2 is being executed from the second processor 3. To the first processor and stored in the first storage device.

Therefore, when the boot loader 1 is called again at time T_next after the time T_boot, the processor that executes the boot loader 1 among the one or more first processors sets the latest value of each environment variable to the second virtual value. It can be obtained from the machine 2. That is, the first processor that has started execution of the boot loader 1 at time T_next can obtain the latest values “A4”, “B4”, and “C3”.

As a result, there is no problem that may occur in the situation 4F when the OS is booted from the boot loader 1 at a certain time after the time T_next. Thus, according to the first embodiment, problems that may occur in the comparative example are solved. That is, according to the first embodiment, even if the second virtual machine 2 temporarily does not operate due to a failure or the like, it will not hinder the future startup of the OS of the first virtual machine.

Also, in the situation 4H, problems that may occur in the situation 4F are avoided. Specifically, it is as follows.

Situation 4H is similar to Situation 4B. That is, during the operation of the second virtual machine 2, the value of the first environment variable is normally updated from “A3” to “A4”, and the updated value “A4” is the first storage device. Saved in. Also, for the second environment variable requested to be updated by the boot loader 1 while the second virtual machine 2 is not operating, the updated value “B4” is the value after the second virtual machine 2 is restored. It is reflected in the first storage device.

That is, in the situation 4H as in the situation 4B, the latest value “B4” is temporarily stored in the second storage device in response to a request from the boot loader 1 to the second processor 3. Thereafter, when the second virtual machine 2 is restored at time T_boot, the boot loader 1 is still operating at this point. Therefore, in the situation 4H, the latest value “B4” is sent from the first processor that is executing the boot loader 1 to the first processor that is executing the second virtual machine 2, and is stored in the first memory. Stored in the device. Of course, one physical processor may accidentally execute both the boot loader 1 and the second virtual machine 2.

Similarly to the situation 4B, in the situation 4H, after the second virtual machine 2 is restarted, the value of the third environment variable is normally updated from “C3” to “C4”, and the updated “C4” Is stored in the first storage device.

Therefore, when the boot loader 1 is called again at time T_next after the time T_boot, the processor that executes the boot loader 1 among the one or more first processors sets the latest value of each environment variable to the second virtual value. It can be obtained from the machine 2. That is, the first processor that is executing the boot loader 1 at time T_next can acquire the latest values “A4”, “B4”, and “C4”.

As a result, there is no problem that may occur in the situation 4F when the OS is booted from the boot loader 1 at a certain time after the time T_next. Thus, according to 1st Embodiment, the problem which may arise in a comparative example does not arise.

Next, a specific example of a computer that performs the processing described with reference to FIGS. 1 and 2 will be described with reference to FIGS.
FIG. 3 is a hardware configuration diagram of the computer. The computer 10 in FIG. 3 includes two system boards 20 and 30. Of course, the number of system boards may be one or three or more. The system boards 20 and 30 are connected to each other via a crossbar switch 40. Hereinafter, the crossbar switch is abbreviated as “XB”.

Further, the computer 10 includes an SP 50 connected to the system board 20 and an SP 60 connected to the system board 30. In the example of FIG. 3, there is one SP for each system board, but one SP may be connected to a plurality of system boards.

The system board 20 includes memories 21a to 21d, CPUs 22a to 22b, and HDDs (Hard Disk Drives) 23a to 23c.
The system board 20 includes an SP I / F 24 that is an interface circuit for connection between the system board 20 and the SP 50 (“I / F” is an abbreviation of interface).

The system board 20 further includes hardware for connection to devices other than the computer 10. In the example of FIG. 3, specifically, the system board 20 includes a LAN (Local Area Network) port 25, a SAS (Serial Attached SCSI), and SCSI (abbreviation for Small Computer System Interface) port 26, and a USB (Universal Serial Bus). It has a port 27.

Further, the system board 20 includes a system controller (hereinafter abbreviated as “SC”) 28 connected to the XB 40. The SC 28 is also connected to each of the memories 21a to 21d, the CPUs 22a to 22b, the HDDs 23a to 23d, and the SP I / F 24.

Each of the memories 21a to 21d may be, for example, a DIMM (Dual Inline Memory Memory Module). In the example of FIG. 3, the system board 20 includes four memories 21a to 21d, but the number of memories is arbitrary.

Each of the CPUs 22a to 22b is a single-core or multi-core processor. In the example of FIG. 3, the system board 20 has two CPUs 22a to 22b, but the number of CPUs is arbitrary.

In the example of FIG. 3, HDDs 23a to 23c are used as nonvolatile storage devices, but one or more SSDs (Solid-State Drives) may be used together with the HDD (or instead of the HDD). In the example of FIG. 3, the system board 20 includes three HDDs 23a to 23c, but the number of HDDs is arbitrary, and the number of SSDs is also arbitrary.

Specifically, the LAN port 25 may be, for example, a Gigabit Ethernet port (“Ethernet” is a registered trademark). Although omitted in FIG. 3, a network processing circuit called “PHY chip” or “MAC chip” corresponding to the LAN port 25 is also provided in the system board 20. The PHY chip is a circuit that performs physical layer processing, and the MAC chip is a circuit that performs processing of a MAC (Media Access Control) sublayer.

Similarly, controller circuits respectively corresponding to the SAS port 26 and the USB port 27 are also provided in the system board 20. These network processing circuit and controller circuit may be connected to the SC 28.

The computer 10 may be connected to the network via the LAN port 25. Further, an external HDD may be connected to the computer 10 via the network and the LAN port 25 together with the HDDs 23a to 23c in the system board 20 (or instead of the HDDs 23a to 23c). Similarly, an external SSD may be connected to the computer 10 via the network and the LAN port 25.

Similarly, one or both of the external HDD and the external SSD may be connected to the computer 10 via the SAS port 26 together with the HDDs 23a to 23c (or instead of the HDDs 23a to 23c). In addition to the HDDs 23a to 23c (or instead of the HDDs 23a to 23c), one or both of the external HDD and the external SSD may be connected to the computer 10 via the USB port 27.

Of course, an interface other than the LAN port 25, the SAS port 26, and the USB port 27 may be used for connection between the computer 10 and another device. For example, the system board 20 may have a host bus adapter for connecting the computer 10 to a Fiber Channel-based SAN (Storage Area Network). Alternatively, one or more of the LAN port 25, the SAS port 26, and the USB port 27 may be omitted.

SC 28 controls communication between modules in the system board 20. The SC 28 also provides an interface function for communication between the system boards 20 and 30 via the XB 40.

The configuration of the system board 30 is the same as that of the system board 20. Specifically, the system board 30 includes memories 31a to 31d, CPUs 32a to 32b, and HDDs 33a to 33c. Further, the system board 30 has an SP I / F 34 that is an interface circuit for connection between the system board 30 and the SP 60. The system board 30 also has a LAN port 35, a SAS port 36, and a USB port 37. The modules in the system board 30 are connected to the SC 38, and the SC 38 is also connected to the XB 40.

Depending on the embodiment, the configurations of the system boards 20 and 30 may be different. For example, the number of CPUs and memories may be different between the system boards 20 and 30.

Further, in the example of FIG. 3, each of the system boards 20 and 30 includes one or more HDDs. However, in some embodiments, the computer 10 may include one or more shared HDDs that are external to the system boards 20 and 30 and connected to the XB 40. Each shared HDD is shared between the system boards 20 and 30. Specifically, each shared HDD is also accessed from the system board 20 via the XB 40 and is also accessed from the system board 30 via the XB 40.

Further, in the example of FIG. 3, each of the system boards 20 and 30 includes hardware elements (for example, a LAN port) for connecting the computer 10 and other devices. However, in some embodiments, hardware elements for connection between the computer 10 and other devices may be shared between the system boards 20 and 30. For example, a LAN interface circuit, a SAS controller, a USB controller, or the like may be provided outside the system boards 20 and 30 and connected to the XB 40.

The SP 50 is connected to the system board 20 via the SP I / F 24 and performs processing such as monitoring of the physical hardware of the system board 20. For example, the SP 50 may monitor voltage and temperature. For example, a signal related to voltage and temperature may be sent from the CPU 22a to the SP 50 via the SC 28 and SP I / F 24, and the SP 50 may monitor the voltage and temperature of the CPU 22a based on the signal.

The SP 50 includes a CPU 51, a nonvolatile memory 52 such as a flash memory, and a memory 53, which are connected to each other via a bus. The memory 53 is specifically a volatile DRAM (Dynamic Random Access Memory). The SP 50 includes a USB port 54, a LAN port 55, and a serial port 56, but one or more of these ports may be omitted. The SP 50 may report the result of monitoring the system board 20 to other devices connected via the USB port 54, the LAN port 55, or the serial port 56.

Similarly, the SP 60 is connected to the system board 30 via the SP I / F 34. The SP 60 includes a CPU 61, a nonvolatile memory 62, and a memory 63 that are connected to each other via a bus. The SP 60 also has a USB port 64, a LAN port 65, and a serial port 66.

In the computer 10 configured as described above, the CPUs 22a to 22b and 32a to 32b are used to execute the hypervisor and the virtual machines on the hypervisor. That is, the specific example of “one or more first processors” described with reference to FIG. 1 is four CPUs 22a to 22b and 32a to 32b in FIG.

Note that the hypervisor may be executed by a certain CPU core, or may be executed by two or more CPU cores. Each virtual machine may also be executed by one CPU core, or may be executed by two or more CPU cores.

At some point, the CPU core assigned to the hypervisor may be assigned to one or a plurality of virtual machines or may not be assigned to any virtual machine. Further, at a certain point in time, the CPU core assigned to the first virtual machine may be assigned to the second virtual machine or may not be assigned to the second virtual machine. In other words, the CPU core assigned to the second virtual machine at a certain point in time may be assigned to the first virtual machine or may not be assigned to the first virtual machine. Good.

As described above, there are various variations in the assignment of CPU cores to the hypervisor and individual virtual machines on the hypervisor. However, ““ one or more first processors ”as a whole executes the hypervisor and a plurality of virtual machines on the hypervisor” is common regardless of variations.

On the other hand, the CPUs 51 and 61 do not execute the hypervisor nor do the virtual machines on the hypervisor. That is, the specific examples of the “second processor” described with reference to FIG. 1 are the CPUs 51 and 61 in FIG.

For example, the CPU 51 may detect an abnormality via the SP I / F 24 when any abnormality (for example, temperature or voltage abnormality) occurs in the physical CPU 22a or 22b. As described above, the CPU 51 may recognize the physical CPUs 22a and 22b and monitor the physical CPUs 22a and 22b. However, the CPU 51 does not need to recognize the virtual machine. The CPU 61 is similar to the CPU 51.

FIG. 4 is a diagram illustrating the connection between the computer and another device. The computer 10 in FIG. 3 may be connected to the input / output device 71. Further, the computer 10 may be connected to the drive device 73 of the storage medium 72.

The input / output device 71 is an input device, an output device, or both. The input device is, for example, a keyboard, a pointing device, a microphone, or a combination thereof. The pointing device may be, for example, a mouse, a track pad, or a touch screen. The output device is, for example, a display, a printer, a speaker, or a combination thereof. The display may be a touch screen.

The storage medium 72 is a computer-readable tangible medium and not a transitory medium such as a signal carrier wave. For example, the storage medium 72 may be an optical disc such as a CD (Compact Disc) or a DVD (Digital Versatile Disc), a magneto-optical disc, a magnetic disc, or a semiconductor memory card.

The computer 10 may be connected to the network 74 via the LAN port 25 or 35. Specifically, the network 74 may be a LAN, a WAN (Wide Area Network), the Internet, or a combination thereof.

Further, a terminal 75 may be connected to the network 74. The terminal 75 may be, for example, a PC (Personal Computer), a tablet terminal, or a smartphone. The computer 10 can receive a command input from the terminal 75 via the network 74. For example, the administrator may input various commands from the terminal 75 such as a command to be given to the boot loader 1 and a command to be given to the hypervisor.

Incidentally, a program (specifically, several programs as described below) for causing the computer 10 to execute the method described with reference to FIG. 1 may be preinstalled in the computer 10.

-Boot loader 1 program.
A program for managing environment variables of the boot loader 1 in the second virtual machine 2 (for example, a program module incorporated in the OS of the second virtual machine 2).
A program for causing the CPU 51 of SP50 and the CPU 61 of SP60 to execute processing related to environment variables.

Specifically, these programs may be preinstalled in any of the HDDs 23a to 23c and 33a to 33c, the nonvolatile memory 52 or 62, or a combination thereof.

Alternatively, these programs may be stored in the storage medium 72 and provided. The computer 10 may read the program from the storage medium 72 set in the drive device 73 and copy the program to any of the HDDs 23a to 23c and 33a to 33c, the nonvolatile memory 52 or 62, or a combination thereof.

Alternatively, these programs may be provided by the program provider 76. Specifically, the program provider 76 is another computer connected to the network 74.

The computer 10 may download the program from the program provider 76 via the network 74. The downloaded program is also stored in an appropriate storage device in the computer 10 (that is, any of the HDDs 23a to 23c and 33a to 33c, the nonvolatile memory 52 or 62, or a combination thereof).

In any case, each of the CPUs 22a, 22b, 32a, 32b as the first processor loads the program into the memory (specifically, any one of the memories 21a-21d, 31a-31d) and executes the program. Further, the CPU 51 as the second processor loads the program into the memory 53 and executes the program. Similarly, the CPU 61 as the second processor also loads the program into the memory 63 and executes the program. As described above, the method described with reference to FIG. 1 is realized by several CPUs that execute programs.

Next, the second embodiment will be described with reference to FIGS. 1 to 4 also applies to the second embodiment, and therefore FIGS. 1 to 4 are also referred to as appropriate below.
FIG. 5 is a block diagram of a computer according to the second embodiment. The computer 100 of FIG. 5 includes one or more physical partitions. In the example of FIG. 5, the computer 100 includes two partitions 110 and 120.

Each partition includes one control domain and one or more guest domains. In the example of FIG. 5, the partition 110 includes a control domain 130, a guest domain 140, and a guest domain 150. Although details of the partition 120 are omitted in FIG. 5, the partition 120 is also similar to the partition 110.

The control domain 130, the guest domain 140, and the guest domain 150 are all specific examples of virtual machines that operate on the hypervisor 160. The control domain 130, the guest domain 140, and the guest domain 150 are all called “logical domains”.

The control domain 130 is a specific example of the second virtual machine 2 described with reference to FIGS. 1 and 2 (that is, a specific virtual machine having a function of managing environment variables of the boot loader 1 of other virtual machines). Guest domains 140 and 150 are both specific examples of the first virtual machine described with reference to FIGS.

In the second embodiment, OBP (OpenBoot PROM; PROM is Programmable Read-Only Memory) is used as a specific example of the boot loader 1 in FIGS. Not only OBP is used in each of the guest domains 140 and 150, but also OBP is used in the control domain 130.

OBP is an implementation example of Open Firmware. Hereinafter, environment variables used in OBP are referred to as “OBP environment variables”.

In FIG. 5, only one hypervisor 160 is shown. However, a separate hypervisor 160 may be executed for each partition.

Specifically, the control domain 130 includes an environment variable storage unit 131, an OBP state management unit 132, a communication unit 133, a setting unit 134, and an update unit 135. The guest domain 140 specifically includes an OS activation unit 141, an environment variable management unit 142, and a communication unit 143. Although details of the guest domain 150 are omitted in FIG. 5, the guest domain 150 is similar to the guest domain 140.

The computer 100 also includes a service processor (SP) 170. The SP 170 includes an environment variable storage unit 171, a storage control unit 172, and a communication unit 173.

The environment variable storage unit 131 stores the OBP environment variable of each guest domain. According to a certain aspect, the environment variable storage unit 131 is an example of a first storage unit that stores the value of the environment variable of the boot loader 1 in accordance with control controlled on the second virtual machine 2.

The OBP state management unit 132 manages information indicating the state of the OBP on each guest domain. Specifically, the OBP state management unit 132 manages information indicating whether or not OBP is being executed on each guest domain.

The communication unit 133 communicates with the guest domain 140, the guest domain 150, and the SP 170 via the hypervisor 160.

The setting unit 134 performs processing for setting the value of the OBP environment variable stored in the environment variable storage unit 131 in each OBP. According to a certain aspect, the setting unit 134 is stored in the first storage unit (for example, the environment variable storage unit 131) in response to a request from the boot loader 1 for setting the environment variable value in the boot loader 1. It is an example of setting means for sending the value of an environment variable to the boot loader 1.

Specifically, the setting unit 134 reads the value of the OBP environment variable of the guest domain 140 stored in the environment variable storage unit 131 and uses the read value via the communication unit 133 and the hypervisor 160. To OBP. Thereby, the setting unit 134 sets the value of the OBP environment variable of the guest domain 140 stored in the environment variable storage unit 131 to the OBP of the guest domain 140. Similarly, the setting unit 134 sets the value of the OBP environment variable of the guest domain 150 to the OBP of the guest domain 150.

Also, the update unit 135 updates the value of the OBP environment variable in response to a request from the OBP. That is, the update unit 135 stores a new value of the OBP environment variable in the environment variable storage unit 131 in response to a request from the OBP.

Specifically, the update unit 135 receives a request from the OBP of the guest domain 140 via the hypervisor 160 and the communication unit 133. Then, the update unit 135 stores the new value of the OBP environment variable of the guest domain 140 in the environment variable storage unit 131 according to the received request.

Similarly, the update unit 135 receives a request from the OBP of the guest domain 150 via the hypervisor 160 and the communication unit 133. Then, the update unit 135 stores the new value of the OBP environment variable of the guest domain 150 in the environment variable storage unit 131 according to the received request.

The OS activation unit 141 activates the OS on the guest domain 140. The environment variable management unit 142 temporarily manages the OBP environment variable of the guest domain 140 while the OBP is being executed on the guest domain 140. Specifically, the OS activation unit 141 activates the OS using the latest value of the OBP environment variable managed by the environment variable management unit 142.

The communication unit 143 communicates with the control domain 130, the guest domain 150, and the SP 170 via the hypervisor 160.

For example, when the OBP is activated on the guest domain 140, the environment variable management unit 142 requests the control domain 130 to send the value of the OBP environment variable for the OBP of the guest domain 140. This request is sent from the environment variable management unit 142 to the control domain 130 via the communication unit 143 and the hypervisor 160. This request is received by the communication unit 133 and output from the communication unit 133 to the setting unit 134.

Then, as described above, the setting unit 134 reads the value of the OBP environment variable from the environment variable storage unit 131, and sends the value of the OBP environment variable via the communication unit 133 and the hypervisor 160. Then, the communication unit 143 of the guest domain 140 receives the value of the OBP environment variable and outputs the received value to the environment variable management unit 142. As described above, the environment variable management unit 142 can acquire the value of the OBP environment variable from the control domain 130 by communication via the communication unit 143.

Also, the environment variable management unit 142 may request the control domain 130 to update the value of the OBP environment variable of the guest domain 140. This request is sent from the environment variable management unit 142 to the control domain 130 via the communication unit 143 and the hypervisor 160. This request is received by the communication unit 133 and is output from the communication unit 133 to the update unit 135.

Then, as described above, the update unit 135 stores the new value of the OBP environment variable in the environment variable storage unit 131. Further, the update unit 135 sends an ACK (acknowledgment) via the communication unit 133 and the hypervisor 160 in order to notify the environment variable management unit 142 of the completion of the storage. Then, the communication unit 143 of the guest domain 140 receives ACK, and outputs the received ACK to the environment variable management unit 142.

As described above, the environment variable management unit 142 can request the control domain 130 to update the value of the OBP environment variable by communication via the communication unit 143. The environment variable management unit 142 determines that “the update of the value of the OBP environment variable has succeeded” when the ACK is received within the determined time. Conversely, when ACK is not received within the determined time, the environment variable management unit 142 determines that “saving of the new value of the OBP environment variable to the environment variable storage unit 131 has failed”.

If the ACK is not received within the determined time, the environment variable management unit 142 requests the SP 170 (more specifically, the storage control unit 172) to store the value of the OBP environment variable of the guest domain 140. This request is sent from the environment variable management unit 142 to the SP 170 via the communication unit 143 and the hypervisor 160. Then, this request is output to the storage control unit 172 via the communication unit 173.

The storage control unit 172 stores the value of the OBP environment variable in the environment variable storage unit 171 in response to the request. Further, in order to notify the environment variable management unit 142 of completion of storage, the storage control unit 172 sends an ACK via the communication unit 173 and the hypervisor 160. Then, the communication unit 143 of the guest domain 140 receives ACK, and outputs the received ACK to the environment variable management unit 142.

As described above, the environment variable management unit 142 can request the SP 170 to save the value of the OBP environment variable by communication via the communication unit 143 during the failure of the control domain 130. Further, when the environment variable management unit 142 receives an ACK from the SP 170 within a predetermined time, the environment variable management unit 142 determines that “the storage of the value of the OBP environment variable in the environment variable storage unit 171 has been successful”.

Conversely, if the ACK is not received within the determined time, the environment variable management unit 142 determines that “saving of the value of the OBP environment variable to the environment variable storage unit 171 has failed”. However, for simplification of description below, it is assumed that “the SP 170 is operating normally when the environment variable management unit 142 requests the SP 170 to save the value of the OBP environment variable”.

Note that this assumption is valid. This is because the probability of simultaneous failure in the control domain 130 and the SP 170 is extremely low and can be ignored. In addition, an embodiment in which appropriate error processing (for example, retry processing) is combined with the second embodiment is also possible so that it can also be applied when failures occur in the control domain 130 and the SP 170 simultaneously. Therefore, in the following, for simplicity of explanation, it is assumed as described above.

According to a certain viewpoint, the environment variable management unit 142 as described above is an example of a request unit that operates as follows.

The requesting unit sends a first request from the boot loader 1 to the hypervisor for requesting the second virtual machine 2 to store the value of the environment variable in the first storage unit (for example, the environment variable storage unit 131). Issued through.
When a response to the first request (for example, ACK) is not returned within a predetermined time, the request unit issues a second request from the boot loader 1 via the hypervisor. Specifically, the requesting unit issues a second request that requests the control unit (for example, the storage control unit 172) to store the value of the environment variable in the second storage unit (for example, the environment variable storage unit 171). Issue.

As described above, the environment variable storage unit 171 of the SP 170 may temporarily store the value of the OBP environment variable of the guest domain 140. Similarly, the environment variable storage unit 171 may temporarily store the value of the OBP environment variable of the guest domain 150.

Also, the storage control unit 172 controls the storage of the value of the OBP environment variable in the environment variable storage unit 171. The communication unit 173 can communicate with any domain via the hypervisor 160.

According to a certain aspect, the storage control unit 172 is an example of a control unit that is accessible from the guest domain 140 and the control domain 130 via the hypervisor 160 and operates independently of the hypervisor 160. is there. The environment variable storage unit 171 is an example of a second storage unit that stores the value of the environment variable in accordance with control by the control unit.

In addition, after the value of the OBP environment variable of the guest domain 140 is stored in the environment variable storage unit 171 as described above, the update unit 135 stores in the environment variable storage unit 171 via the communication unit 133 and the hypervisor 160. The SP 170 may be requested to send the value that has been set. This request is received by the communication unit 173 of the SP 170 and output to the storage control unit 172.

In response to the request, the storage control unit 172 reads the value of the OBP environment variable of the guest domain 140 from the environment variable storage unit 171, and sends the read value via the communication unit 173 and the hypervisor 160. Then, the communication unit 133 of the control domain 130 receives the value of the OBP environment variable, and outputs the received value to the update unit 135.

As described above, the update unit 135 can acquire the value of the OBP environment variable of the guest domain 140 from the SP 170 by communication via the communication unit 133. Similarly, the update unit 135 can acquire the value of the OBP environment variable of the guest domain 150 from the SP 170 by communication via the communication unit 133.

According to a certain aspect, the update unit 135 is an example of an update unit that operates as follows.
The update unit sends the value of the environment variable stored in the second storage unit (for example, the environment variable storage unit 171) in response to the second request issued by the request unit (for example, the environment variable management unit 142). A third request is issued to the control means (for example, the storage control unit 172). Specifically, the update unit issues the third request from the second virtual machine (for example, the control domain 130) via the hypervisor.
The update means receives the value of the environment variable returned in response to the third request.
The update unit stores the received environment variable value in the first storage unit (for example, the environment variable storage unit 131).

Incidentally, while the OBP is operating on the guest domain 140, the environment variable management unit 142 is operating. Therefore, when the OBP is operating on the guest domain 140, the update unit 135 transmits the value of the OBP environment variable recognized by the environment variable management unit 142 via the communication unit 133 and the hypervisor 160. The request may be made to the environment variable management unit 142. This request is received by the communication unit 143 of the guest domain 140 and output to the environment variable management unit 142.

In response to the request, the environment variable management unit 142 sends the value of the OBP environment variable recognized by the environment variable management unit 142 via the communication unit 143 and the hypervisor 160. Specifically, the value of the OBP environment variable recognized by the environment variable management unit 142 is a value temporarily stored in a memory area allocated for the environment variable management unit 142. Then, the communication unit 133 of the control domain 130 receives the value of the OBP environment variable, and outputs the received value to the update unit 135.

As described above, while the OBP is operating on the guest domain 140, the update unit 135 acquires the value of the OBP environment variable of the guest domain 140 from the guest domain 140 by communication via the communication unit 133. be able to. Similarly, the updating unit 135 can acquire the value of the OBP environment variable of the guest domain 150 from the guest domain 150 while the OBP is operating on the guest domain 150.

Subsequently, the relationship between FIG. 3 and FIG. 5 will be described. Specifically, the computer 100 of FIG. 5 may be realized by the computer 10 of FIG.

3) One system board in FIG. 3 corresponds to one partition in FIG. For example, the system board 20 may correspond to the partition 110, and the system board 30 may correspond to the partition 120.

In FIG. 5, only one hypervisor 160 is shown, but an independent hypervisor may be executed for each partition. That is, both of the following two cases are possible.

At least one of the CPUs 22a, 22b, 32a, and 32b in the computer 10 executes a hypervisor that manages both the partitions 110 and 120.
At least one of the CPUs 22 a and 22 b in the system board 20 corresponding to the partition 110 executes a hypervisor that manages the partition 110. Independently, at least one of the CPUs 32 a and 32 b in the system board 30 corresponding to the partition 120 executes a hypervisor that manages the partition 120.

Hereinafter, the case where the system board 20 corresponds to the partition 110 will be described in detail for convenience of explanation.
The control domain 130 in the partition 110 is one of virtual machines on the hypervisor 160. That is, the control domain 130 in the partition 110 is executed by at least one of the CPUs 22a and 22b in the system board 20. Each of the CPUs 22a and 22b may be a single core CPU or a multi-core CPU. Among the cores included in the CPUs 22a and 22b, one or more cores are assigned for execution of the control domain 130. The assignment of the core to the control domain 130 may be determined statically or dynamically by the hypervisor 160.

The environment variable storage unit 131 is realized by an area allocated to the control domain 130 so as to be accessible from the control domain 130 among physical nonvolatile storage devices (that is, HDDs 23a to 23c) in the system board 20. . For example, some of the physical HDDs 23 a to 23 c are allocated to the control domain 130 as virtual disks for the control domain 130. The environment variable storage unit 131 is an area in the virtual disk allocated to the control domain 130. Therefore, physically, the environment variable storage unit 131 is realized by a part of the HDDs 23a to 23c.

The OBP state management unit 132, the communication unit 133, the setting unit 134, and the update unit 135 are executed by a CPU that executes a program module for managing OBP environment variables of other domains ( guest domains 140 and 150 in the example of FIG. 3). Realized. The program module may be incorporated in the OS on the control domain 130. That is, physically, each of the OBP state management unit 132, the communication unit 133, the setting unit 134, and the update unit 135 is realized by at least one of the CPUs 22a and 22b in the system board 20.

For example, when only one core is allocated for execution of the control domain 130 among the cores of the CPUs 22a and 22b, each of the OBP state management unit 132, the communication unit 133, the setting unit 134, and the update unit 135 Realized by one core. When two or more cores are allocated for execution of the control domain 130 among the cores of the CPUs 22a and 22b, each of the OBP state management unit 132, the communication unit 133, the setting unit 134, and the update unit 135 This is realized by at least one of the two or more cores.

More specifically, among the cores of the CPUs 22a and 22b, one or more cores assigned for execution of the control domain 130 use the areas assigned to the control domain 130 of the memories 21a to 21d. Run the program. The OBP state management unit 132, the communication unit 133, the setting unit 134, and the update unit 135 are realized by the one or more cores executing the program.

Also, the guest domain 140 in the partition 110 is one of the virtual machines on the hypervisor 160. That is, the guest domain 140 in the partition 110 is also executed by at least one of the CPUs 22a and 22b in the system board 20. Similarly, the guest domain 150 in the partition 110 is also executed by at least one of the CPUs 22a and 22b.

Each of the OS startup unit 141, the environment variable management unit 142, and the communication unit 143 is realized by a CPU that executes the OBP of the guest domain 140. In other words, the OBP of the guest domain 140 is a boot loader that loads an OS into the guest domain 140, and is an example of the boot loader 1 of FIGS. The CPU that executes the OBP of the guest domain 140 is specifically at least one of the CPUs 22a and 22b.

For example, the allocation of processor resources to each guest domain may be performed as follows.
The system board 20 corresponds to the physical partition 110. Therefore, one or more of the cores included in the CPUs 22a and 22b in the system board 20 are “one or more physical CPU cores that can be used to realize a virtual CPU in a virtual partition corresponding to the guest domain 140”. May be determined. Similarly, one or more of the cores included in the CPUs 22a and 22b are determined as “one or more physical CPU cores that can be used to implement a virtual CPU in a virtual partition corresponding to the guest domain 150”. May be. The “one or more available physical CPU cores” determined as described above are used to execute each guest domain.

More specifically, the processor resource allocation to the guest domain may be a thread unit or process unit allocation. A set of physical CPU cores that can be used to realize a virtual CPU in a virtual partition and a set of physical CPU cores that can be used to realize a virtual CPU in another virtual partition All may be duplicated. For example, when a certain core in the CPU 22 a or 22 b can execute eight threads simultaneously, four threads of the core are allocated to the guest domain 140 and the remaining four threads are allocated to the guest domain 150. Good.

Of course, depending on the virtualization architecture, the guest domain may be allocated in units of physical CPU cores instead of in units of threads as described above. Further, with respect to the control domain, allocation in units of threads or processes may be performed instead of allocation in units of physical CPU cores as described above.

However, in any case, as described below, the components shown in the control domain 130 and the guest domain 140 in FIG. 5 are realized by the hardware elements in FIG.

Physically, the environment variable storage unit 131 is realized by a partial area of the HDDs 23a to 23c in the system board 20.
Physically, each of the OBP state management unit 132, the communication unit 133, the setting unit 134, and the update unit 135 is realized by at least one of the CPUs 22a and 22b in the system board 20. In addition, in order to realize each of the OBP state management unit 132, the communication unit 133, the setting unit 134, and the update unit 135, an area allocated to the control domain 130 in the memories 21a to 21d is also used.
Physically, each of the OS startup unit 141, the environment variable management unit 142, and the communication unit 143 is realized by at least one of the CPUs 22a and 22b in the system board 20. In addition, the areas allocated to the guest domain 140 in the memories 21a to 21d are also used for realizing the OS activation unit 141, the environment variable management unit 142, and the communication unit 143, respectively.

Also, the SP 170 in FIG. 5 may specifically be the SP 50 in FIG. In that case, the environment variable storage unit 171 is realized by the nonvolatile memory 52 in the SP 50. The storage control unit 172 is realized by the CPU 51 in the SP 50. The CPU 51 is a specific example of the second processor 3 shown in FIGS. The communication unit 173 is realized by a communication circuit (not shown in FIG. 3) provided in the SP 50 for communication between the system board 20 and the SP 50, and a CPU 51 that controls the communication circuit.

For the communication between the control domain 130 and the SP 170 performed via the hypervisor 160, the SP I / F 24 is physically used. Similarly, the SP I / F 24 is physically used for communication between the guest domain 140 and the SP 170 performed via the hypervisor 160.

Incidentally, only one SP 170 is shown in FIG. 5, and two SPs 50 and 60 are shown in FIG. Thus, the number of SPs may be one, or two or more.
For example, the SP 60 may be omitted from the computer 10 of FIG. In this case, the SP I / F 34 of the system board 30 is connected to the SP 50. In this case, SP50 corresponds to SP170 in FIG.

Alternatively, FIG. 5 shows only one SP 170 for the plurality of partitions 110 and 120, but the SP corresponding to the partition 110 may be different from the SP corresponding to the partition 120. For example, the SP 50 in FIG. 3 may be used as the SP 170 corresponding to the partition 110, and the SP 60 in FIG. 3 may be used as the SP 170 corresponding to the partition 120.

Next, an example of information used in the second embodiment will be described with reference to FIGS.
FIG. 6 is a diagram illustrating an example of the environment variable table. 6 shows environment variable tables 200-1 to 200-N stored in the environment variable storage unit 131 in the control domain 130, and environment variable tables 210-1 to 210-210 stored in the environment variable storage unit 171 of the SP 170. -N is illustrated. N is the number of guest domains in the partition 110. In the example of FIG. 5, N is 2, but N may be a large value exceeding 1000, for example.

In the following, n is an integer satisfying 1 ≦ n ≦ N. The nth environment variable table 200-n is a table for managing the value of the OBP environment variable of the nth guest domain. Similarly, the nth environment variable table 210-n is a table for temporarily storing the value of the OBP environment variable of the nth guest domain.

Each entry of the environment variable table 200-n includes time information indicating the name of the OBP environment variable of the nth guest domain, the value of the OBP environment variable, and the time when the value is stored in the environment variable table 200-n. including. Each entry of the environment variable table 210-n includes time information indicating the name of the OBP environment variable of the nth guest domain, the value of the OBP environment variable, and the time when the value was stored in the environment variable table 210-n. including.

FIG. 6 specifically shows an example of n = 1. The example of FIG. 6 shows the following.
In the first guest domain OBP, an environment variable named “ENV_VAR_1” is used. This environment variable “ENV_VAR — 1” was updated to a value of “TRUE” at 15: 37: 3 on November 28, 2011. Therefore, the environment variable table 200-1 stores a value “TRUE” together with time information indicating the update time.
In the first guest domain OBP, an environment variable named “ENV_VAR_2” is used. This environment variable “ENV_VAR_2” was updated to a value of “FALSE” on November 28, 2011, at 15:37:15. Therefore, a value “FALSE” is stored in the environment variable table 200-1.
In the first guest domain OBP, an environment variable named “ENV_VAR — 3” is used. This environment variable “ENV_VAR — 3” was updated to a character string “ABC” at 16:37:20 on November 28, 2011. Therefore, the environment variable table 200-1 stores a character string “ABC” together with time information indicating the update time.
In the OBP of the first guest domain, an environment variable named “ENV_VAR_4” is used. This environment variable “ENV_VAR — 4” was updated to a numerical value “1234” at 16:37:30 on November 28, 2011. Therefore, a numerical value “1234” is stored in the environment variable table 200-1 together with time information indicating the update time.
When the update of the environment variable “ENV_VAR_2” was requested from the OBP of the first guest domain to the control domain 130 on December 3, 2011, the control domain 130 was not operating. Therefore, a new value “TRUE” of the environment variable “ENV_VAR_2” is sent to the SP 170 and stored in the environment variable table 210-1 on the environment variable storage unit 171. Specifically, the new value “TRUE” is stored in the environment variable table 210-1 together with time information indicating a storage time of 11:30:45 on December 3, 2011.
When the update of the environment variable “ENV_VAR — 3” was requested from the OBP of the first guest domain to the control domain 130 on December 3, 2011, the control domain 130 was not operating. Therefore, the new value “XYZ” of the environment variable “ENV_VAR — 3” is sent to SP 170 and stored in the environment variable table 210-1 on the environment variable storage unit 171. Specifically, the new value “XYZ” was stored in the environment variable table 210-1 together with time information indicating a storage time of 11:30:47 on December 3, 2011.

FIG. 7 is a diagram showing an example of the state list. Specifically, the status list 220 in FIG. 7 is managed by the OBP status management unit 132 in the control domain 130 and is referred to by the update unit 135.

Also, in order to keep the data in the state list 220 maintained before and after the restart of the control domain 130, the state list 220 is stored in a nonvolatile storage device. The state list 220 is physically one of the areas allocated to the control domain 130 so as to be accessible from the control domain 130 among the physical nonvolatile storage devices (that is, the HDDs 23a to 23c) in the system board 20. Stored in the department.

The state list 220 has N entries corresponding to N guest domains. The nth entry in the state list 220 indicates whether or not the OBP of the nth guest domain can communicate with the control domain 130 via the hypervisor 160 (1 ≦ n ≦ N). Specifically, each entry includes a domain number and a status flag.

The domain number is an example of identification information for identifying the guest domain. The status flag is an example of status information indicating whether or not the OBP of the guest domain identified by the domain number can communicate with the control domain 130 via the hypervisor 160. In other words, the status flag as status information indicates whether or not OBP is being executed on the guest domain identified by the domain number.

Hereinafter, for convenience of explanation, when the value of the status flag is TRUE, it is assumed that the OBP is being executed in the guest domain (thus, communication between the OBP and the control domain 130 is possible). How the value of the status flag is updated will be described later with reference to the flowcharts of FIGS.

Subsequently, the operation of the computer 100 in the second embodiment will be described with reference to the flowcharts of FIGS. When the computer 100 operates according to the flowcharts of FIGS. 8 to 12, the operation sequences such as the situations 4A to 4E, 4G, and 4H illustrated in FIGS.

FIG. 8 is an operational flowchart of OBP in the guest domain. When the OBP is called on the guest domain 140 (in other words, when one of the cores included in the CPUs 22a and 22b starts executing the OBP on the guest domain 140), the process of FIG. Is started. Of course, the processing of FIG. 8 is similarly executed in the guest domain 150.

In step S101, the environment variable management unit 142 notifies the control domain 130 that the OBP has started on the guest domain 140. The notification in step S101 is sent via the communication unit 143 and the hypervisor 160. The operation of the control domain 130 that has received this notification will be described later with reference to FIG.

Next, in step S102, the environment variable management unit 142 requests the control domain 130 to send the values of all environment variables of the OBP in the guest domain 140. The request in step S102 is also sent via the communication unit 143 and the hypervisor 160.

Then, the environment variable management unit 142 waits in step S103 for any of the following events to occur.

An event that the environment variable management unit 142 receives the values of all environment variables of the OBP of the guest domain 140 from the control domain 130 via the hypervisor 160 and the communication unit 143.
An event that a predetermined time has elapsed since the request in step S102.

When the former event occurs, the processing in FIG. 8 proceeds from step S103 to step S106. When the latter event occurs, the processing in FIG. 8 proceeds from step S103 to step S104. The predetermined time is a time obtained by adding an appropriate margin to an average RTT (RoundRTrip Time) required for communication between the guest domain 140 and the control domain 130 when the control domain 130 is operating normally. It is preferable that

In step S104, the environment variable management unit 142 determines whether or not the number of times the environment variable management unit 142 issued the request in step S102 has reached a predetermined number of retries. If the environment variable management unit 142 has already transmitted the request in step S102 for a predetermined number of retries after the start of the process of FIG. 8, the process of FIG. 8 ends abnormally. Conversely, if the number of times the environment variable management unit 142 issued the request in step S102 is less than the predetermined retry count, the process in FIG. 8 proceeds from step S104 to step S105.

In step S105, the environment variable management unit 142 waits for a predetermined waiting time. For example, when the control domain 130 is automatically restarted, the waiting time may be determined based on an average time required for restarting. The waiting time may be further based on the predetermined number of retries. When the determined waiting time has elapsed, the processing in FIG. 8 returns from step S105 to step S102.

According to the above steps S102 to S105, if the value of the OBP environment variable is not received even if the transmission of the request in step S102 is repeated for a predetermined number of retries, the process of FIG. 8 ends abnormally. Conversely, if the value of the OBP environment variable is successfully received within the predetermined number of retries, the process of FIG. 8 proceeds to step S106.

In step S106, the environment variable management unit 142 sets each OBP environment variable to the latest received value.

For example, it is assumed that the guest domain 140 is the nth guest domain. In this case, the latest value of each environment variable stored in the environment variable table 200-n on the environment variable storage unit 131 has already been received by the environment variable management unit 142. Therefore, in step S106, the environment variable management unit 142 uses the value received from the control domain 130 as the initial value of each OBP environment variable.

As described above, the environment variable management unit 142 temporarily manages the OBP environment variable of the guest domain 140 while the OBP is being executed on the guest domain 140 (that is, until the processing of FIG. 8 ends). Specifically, while the OBP is being executed, the environment variable management unit 142 stores the latest environment variables of the OBP in the guest domain 140 on the storage area allocated to the guest domain 140 in the memories 21a to 21d. Holds the value. In step S106, specifically, the environment variable management unit 142 stores the value received from the control domain 130 in the storage area.

Next, in step S107, the OS activation unit 141 determines whether a condition for activating the OS is satisfied. The condition for starting the OS may be appropriately determined according to the OBP specification, or may be a condition in which a plurality of conditions are combined.

For example, the OBP as the boot loader 1 that activates the OS may have a function of checking virtual hardware resources allocated to the guest domain 140. The condition for starting the OS may be a condition that “the virtual hardware resource allocated to the guest domain 140 is determined to be normal as a result of the check”.

Also, for example, when the guest domain 140 is restarted, the guest domain 140 may be restarted by specifying the OBP to be executed in an interactive mode. In this case, the OBP can be accessed from the input / output device 71 or the terminal 75 of FIG. 4 via an appropriate user interface (for example, a command line interface). In this case, the condition for starting the OS may be a condition that “the result of the check indicates that the virtual hardware resource allocated to the guest domain 140 is normal and a predetermined input is given”.

If the conditions for starting the OS are satisfied, the process in FIG. 8 proceeds to step S114. Conversely, when the condition for starting the OS is not satisfied (for example, when a predetermined input has not been given yet), the processing in FIG. 8 proceeds to step S108. Then, depending on the event that occurs, the processing of FIG. 8 proceeds from step S108 to step S109, S110, or S113.

Specifically, when the control domain 130 requests to send all the OBP environment variable values of the guest domain 140, the processing in FIG. 8 proceeds from step S108 to step S109. For example, in the situation 4B of FIG. 1, such a request is issued from the control domain 130 as the second virtual machine 2 to the OBP as the boot loader 1 at time T_boot.

If a save instruction is given for one OBP environment variable of the guest domain 140, the processing in FIG. 8 proceeds from step S108 to step S110. The save instruction is an instruction to update the value of the OBP environment variable and save the updated new value. The save instruction is given from the input / output device 71 or the terminal 75 via the OBP user interface.

For example, the update of the first environment variable “A1” to “A2” in each of the situations 4A to 4C in FIG. 1 is performed based on the save instruction. Similarly, the third environment variable “C1” to “C2” in each of the situations 4B, 4D, and 4E is also updated based on the save instruction.

When another type of event occurs, the process in FIG. 8 proceeds from step S108 to step S113.

In step S109, the environment variable management unit 142 reads the values of all OBP environment variables of the guest domain 140 from the storage area described with reference to step S106. The environment variable management unit 142 notifies the control domain 130 of the values of all the read OBP environment variables via the communication unit 143 and the hypervisor 160.

The operation of the control domain 130 that has received the notification will be described later with reference to FIG. After the notification, the processing in FIG. 8 returns from step S109 to step S107.

In step S110, the environment variable management unit 142 issues a request to the control domain 130 according to the given storage instruction. That is, the environment variable management unit 142 requests the control domain 130 via the communication unit 143 and the hypervisor 160 to store the value of the OBP environment variable. The request specifically includes the name and value of the OBP environment variable.

Note that details of the operation of the control domain 130 that has received the request will be described later with reference to FIG. 10, but if the control domain 130 is operating normally, an ACK is returned for the request. Therefore, the environment variable management unit 142 waits for one of the following events to occur in step S111.

An event that the environment variable management unit 142 has received an ACK from the control domain 130 via the hypervisor 160 and the communication unit 143.
An event that a predetermined time has elapsed since the request in step S110.

When the former event occurs, the processing in FIG. 8 returns from step S111 to step S107. When the latter event occurs, the processing in FIG. 8 proceeds from step S111 to step S112. Note that the predetermined time in step S111 may be the same as or different from the predetermined time in step S103.

In step S112, the environment variable management unit 142 issues a request to the SP 170 in accordance with the given storage instruction. In other words, the environment variable management unit 142 requests the SP 170 via the communication unit 143 and the hypervisor 160 to save the value of the OBP environment variable. The request specifically includes the name and value of the OBP environment variable.

Details of the operation of the SP 170 that has received the request will be described later with reference to FIG. As described with reference to FIG. 5, it is assumed that “the SP 170 is operating normally when the environment variable management unit 142 requests the SP 170 to save the value of the OBP environment variable”. According to this assumption, the environment variable management unit 142 successfully receives an ACK from the SP 170 via the hypervisor 160 and the communication unit 143. Therefore, the process of FIG. 8 returns from step S112 to step S107.

For example, in each of the situations 4A and 4B in FIG. 1, the storage of the value “B2” of the second environment variable in the environment variable storage unit 171 proceeds in the order of steps S110, S111, and S112 in order of FIG. This is realized.

Now, in step S113, appropriate processing according to the type of event is performed. For example, menu selection in the OBP may be performed. Then, the processing in FIG. 8 returns from step S113 to step S107. If no event occurs, the environment variable management unit 142 waits for an event to occur in step S108.

As described above, the processing of steps S108 to S113 is executed as long as the condition for starting the OS is not yet established. When the conditions for starting the OS are satisfied, a notification is sent from the environment variable management unit 142 to the control domain 130 via the communication unit 143 and the hypervisor 160 in step S114. Specifically, the environment variable management unit 142 notifies the control domain 130 that the OBP is finished.

Then, in the next step S115, the OS activation unit 141 activates the OS. The process of FIG. 8 ends in step S115. That is, after the OS is started, the OBP is not operating in the guest domain 140.

FIG. 9 is a flowchart of processing performed by the SP regarding the OBP environment variable. When the computer 100 is turned on, the SP 170 starts the processing of FIG.
In step S201, the SP 170 waits for any of the following events to occur.

An event that the storage control unit 172 has been requested to send an OBP environment variable of any guest domain from the control domain 130 via the hypervisor 160 and the communication unit 173.
An event that the storage control unit 172 has received the value of the OBP environment variable from one of the guest domains via the hypervisor 160 and the communication unit 173.

When the former event occurs, the process in FIG. 9 proceeds to step S202. When the latter event occurs, the process in FIG. 9 proceeds to step S204.
The control domain 130 may request the SP 170 to send the value of the OBP environment variable of the guest domain 140, or may request the SP 170 to send the value of the OBP environment variable of the guest domain 150. obtain. Hereinafter, for the sake of convenience, the operations in steps S202 to S203 when the control domain 130 requests the SP 170 to send the value of the OBP environment variable of the guest domain 140 will be described.

In step S202, the storage control unit 172 reads out each OBP environment variable stored in the environment variable storage unit 171 with respect to the guest domain 140. For example, when the guest domain 140 is the nth guest domain, the storage control unit 172 reads all entries of the environment variable table 210-n from the environment variable storage unit 171. As shown in FIG. 6, each entry includes not only the value of the OBP environment variable but also the name and time information of the OBP environment variable.

The storage control unit 172 notifies the value of each read OBP environment variable to the control domain 130 through the communication unit 173 and the hypervisor 160 together with the read time information (and the name of the OBP environment variable). For example, in the situation 4A in FIG. 1, in step S202, the second processor 3 (specifically, the storage control unit 172 in the SP 170) sets the value “B2” to the second virtual machine 2 (specifically, Notifies the control domain 130).

Note that the environment variable table 210-n may include only one entry, or may include two or more entries. In some cases, there may be no entry in the environment variable table 210-n. If there is no entry in the environment variable table 210-n, the notification in step S202 is, in other words, a notification indicating that the SP 170 does not store the value of the OBP environment variable for the desired guest domain 140. It is.

The operation of the control domain 130 that has received the notification in step S202 will be described later with reference to FIGS. After the notification in step S202, the process in FIG. 9 proceeds to step S203.

In step S203, the storage control unit 172 discards the requested OBP environment variable of the guest domain 140. For example, when the guest domain 140 is the nth guest domain, the storage control unit 172 deletes all entries in the environment variable table 210-n. 9 returns from step S203 to step S201.

Note that the discarding in step S203 is a process for avoiding wasteful use of the storage area of the environment variable storage unit 171. Depending on the embodiment, step S203 may be omitted.

Incidentally, the SP 170 may receive the value of the OBP environment variable from the guest domain 140, or may receive the value of the OBP environment variable from the guest domain 150. Hereinafter, for the sake of convenience, the operations in steps S204 to S205 when the SP 170 receives the value of the OBP environment variable from the guest domain 140 will be described.

In step S204, the storage control unit 172 stores the value of the OBP environment variable received from the guest domain 140 in the environment variable storage unit 171 together with current time information indicating the current time. For example, assume that the guest domain 140 is the nth guest domain. In this case, the storage control unit 172 stores the value of the OBP environment variable received from the guest domain 140 in the environment variable table 210-n in the entry identified by the name of the OBP environment variable along with the current time information.

As described above, the request received from the guest domain 140 includes not only the value of the OBP environment variable but also the name. Therefore, the storage control unit 172 can determine in which entry the value is stored.

In the environment variable table 210-n, an entry corresponding to the OBP environment variable that has received a new value from the guest domain 140 may already exist. Conversely, there may be no entry corresponding to the OBP environment variable.

If the entry already exists, the storage control unit 172 overwrites the existing entry. On the other hand, if there is no entry, the storage control unit 172 creates a new entry to store the received OBP environment variable value, and the received OBP environment variable value and the OBP environment variable value are stored in the new entry. Save the name and current time information.

For example, in any of the situations 4A and 4B in FIG. 1, the storage control unit 172 corresponding to the second processor 3 stores the value “B2” in the environment variable storage unit 171 in step S204.

After step S204, in step S205, the storage control unit 172 transmits ACK to the guest domain 140 via the communication unit 173 and the hypervisor 160. After the transmission of ACK, the process of FIG. 9 returns to step S201. When this ACK is received by the guest domain 140, as described above, the processing in FIG. 8 returns from step S112 to step S107.

FIG. 10 is a flowchart of processing performed by the control domain regarding the OBP environment variable. For example, as a program for causing the computer 10 to execute the processing of FIG. 10 on the control domain 130, a program module for managing OBP environment variables in the OS of the control domain 130 may be used. In this case, when the OS is started from the OBP on the control domain 130, the processing of FIG. 10 is started.

In step S301, the environment variable update process of FIGS. 11 to 12 is performed. Thereafter, the control domain 130 waits for one of the following events to occur in step S302.

-An event that a new guest domain has been added.
-An event that an existing guest domain was deleted.
An event that the OBP state management unit 132 has received a state transition notification from one of the guest domains via the hypervisor 160 and the communication unit 133.
An event that the update unit 135 has received the value of the OBP environment variable from one of the guest domains via the hypervisor 160 and the communication unit 133.
An event that the setting unit 134 is requested to send a value of an OBP environment variable of the guest domain from any guest domain via the hypervisor 160 and the communication unit 133.

Specifically, addition and deletion of guest domains are performed via a user interface (for example, a command line interface) provided by the control domain 130. For example, a guest domain may be added or deleted in response to a user input from the input / output device 71 or the terminal 75. The OBP state management unit 132 can detect an event that a guest domain has been added or deleted.

When a new guest domain is added, the processing in FIG. 10 proceeds from step S302 to step S303. Conversely, when the existing guest domain is deleted, the processing in FIG. 10 proceeds from step S302 to step S305.

Further, the state list 220 of FIG. 7 managed by the OBP state management unit 132 of the control domain 130 is specifically updated based on a state transition notification from each guest domain to the control domain 130. The guest domain notifies the control domain 130 of the state transition of the guest domain itself by sending a state transition notification to the control domain 130.

The state of each domain on the hypervisor 160 transitions from the state where the domain itself is not activated (hereinafter also referred to as “domain off state”) as follows. First, when the domain is activated, OBP starts operating on the domain. Hereinafter, the state in which the OBP is operating is also referred to as an “OBP operating state”. Thereafter, when the OS is started from the OBP, the OBP stops operating. That is, the domain transitions to a state where the OS is operating (hereinafter also referred to as “OS operating state”).

The OS may be automatically restarted on the domain in response to some error, or the OS may be restarted on the domain in response to an explicit input from the user. In either case, the domain temporarily transitions from the OS operating state to the OBP operating state, and again transitions to the OS operating state.

Also, the domain may shut down due to some error, or the domain may be shut down in response to an explicit input from the user. In either case, the domain transitions to the domain off state.

Any guest domain OBP can communicate with the control domain 130 only in the OBP operating state among the domain off state, the OBP operating state, and the OS operating state.

For example, the OS activation unit 141, the environment variable management unit 142, and the communication unit 143 in FIG. 5 are realized by the CPU executing the OBP of the guest domain 140. Therefore, the OS activation unit 141, the environment variable management unit 142, and the communication unit 143 are active when the guest domain 140 is in the OBP operating state. The guest domain 140 can communicate with the control domain 130 when the communication unit 143 is active. However, when the guest domain 140 is in the domain off state or the OS operating state, the OS activation unit 141, the environment variable management unit 142, and the communication unit 143 are not active.

Each guest domain sends a state transition notification to notify the control domain 130 whether or not the control domain 130 and the OBP of the guest domain can communicate. Specifically, there are two types of state transition notifications sent in steps S101 and S114 in FIG. When any type of state transition notification from any guest domain is received by the control domain 130, the processing in FIG. 10 proceeds from step S302 to step S306.

In addition, as shown in step S110 of FIG. 8, the value of the OBP environment variable may be sent from any guest domain. The sent value is received by the update unit 135 of the control domain 130 via the hypervisor 160 and the communication unit 133. In response to reception, the processing in FIG. 10 proceeds from step S302 to step S309.

Then, as shown in step S102 of FIG. 8, any guest domain may request the control domain 130 to send the values of all OBP environment variables of the guest domain. The request is received by the setting unit 134 of the control domain 130 via the hypervisor 160 and the communication unit 133. In response to reception, the processing in FIG. 10 proceeds from step S302 to step S311.

In step S303, the OBP state management unit 132 adds an entry for the added new guest domain to the state list 220 in FIG. Then, the OBP state management unit 132 initializes the value of the state flag to FALSE in the added entry. The OBP state management unit 132 also sets a domain number in the added entry.

When a new guest domain is added, a new domain number is issued by the hypervisor 160 or the control domain 130, and the issued new domain number is assigned to the new guest domain. For example, a module in the control domain 130 for adding and deleting a guest domain may notify the OBP state management unit 132 of a new domain number in accordance with the addition of a new guest domain. Then, the OBP state management unit 132 can set the notified new domain number in the added entry.

Subsequently, in step S304, the setting unit 134 stores the default value of each OBP environment variable of the new guest domain in the environment variable storage unit 131. The default value is determined in advance according to the OBP specification.

Suppose, for example, that the Nth guest domain is newly created. In this case, the setting unit 134 creates the environment variable table 200-N for the new guest domain in the environment variable storage unit 131, and stores the name and default value of each OBP environment variable of the new guest domain in the environment variable table 200-N. Set. The setting unit 134 also sets time information indicating the current time in each entry of the created environment variable table 200-N. Then, the process of FIG. 10 returns from step S304 to step S302.

On the other hand, when the existing guest domain is deleted, information regarding the deleted guest domain is deleted in step S305. Specifically, the OBP state management unit 132 deletes the entry corresponding to the deleted guest domain from the state list 220, and the setting unit 134 stores the OBP environment variable of the deleted guest domain. The table is deleted from the environment variable storage unit 131. Then, the process of FIG. 10 returns from step S305 to step S302.

The module in the control domain 130 for adding and deleting a guest domain notifies the OBP state management unit 132 and the setting unit 134 of the domain number of the deleted guest domain according to the deletion of the existing guest domain. May be. The OBP state management unit 132 and the setting unit 134 can recognize what is to be deleted according to the notified domain number.

In step S306, the OBP state management unit 132 that has received the state transition notification determines the type of state transition notification. When the received state transition notification is a notification of activation of OBP (that is, notification of transition from another state to the OBP operating state), the processing in FIG. 10 proceeds from step S306 to step S307. Conversely, if the received state transition notification is a notification of the end of OBP (that is, notification of transition from the OBP operating state to the OS operating state), the processing in FIG. 10 proceeds from step S306 to step S308.

In step S307, the OBP state management unit 132 sets the state flag of the guest domain that has notified the activation of the OBP to TRUE. For example, when a state transition notification notifying activation of OBP is received from a guest domain having a domain number n, the OBP state management unit 132 sets the value of the state flag associated with the domain number n in the state list 220 as follows: Set to TRUE. Then, the processing in FIG. 10 returns from step S307 to step S302.

On the other hand, in step S308, the OBP state management unit 132 sets the state flag of the guest domain that has notified the end of the OBP to FALSE. For example, when a state transition notification notifying the end of OBP is received from a guest domain with a domain number n, the OBP state management unit 132 sets the value of the state flag associated with the domain number n in the state list 220 as follows: Set to FALSE. Then, the processing in FIG. 10 returns from step S308 to step S302.

In step S309, the updating unit 135 stores the value of the OBP environment variable received from the guest domain in the environment variable storage unit 131 in association with the current time. For convenience of explanation, for example, the following is assumed.

Guest domain 140 is the nth guest domain.
The update unit 135 receives the value “FALSE” as the value of the OBP environment variable named “ENV_VAR_1” from the guest domain 140 via the hypervisor 160 and the communication unit 133.

Under the above assumption, in step S309, the updating unit 135 specifically updates the entry corresponding to the OBP environment variable named “ENV_VAR_1” in the environment variable table 200-n. That is, the updating unit 135 stores the value “FALSE” received from the guest domain 140 in the entry, and stores time information indicating the current time in the entry.

Further, in step S309, the OBP state management unit 132 sets the value of the state flag of the guest domain 140 in the state list 220 to TRUE. Then, when the OBP is activated in the guest domain 140 while the control domain 130 is not operating (that is, when the OBP state management unit 132 cannot receive the notification in step S101 of FIG. 8), the value of the state flag is later Can be corrected.

In the next step S310, the updating unit 135 transmits an ACK to the guest domain that is the transmission source of the value of the OBP environment variable via the communication unit 133 and the hypervisor 160. After the transmission of ACK, the process of FIG. 10 returns to step S302. When the ACK transmitted in step S310 is received by the guest domain, the process in FIG. 8 returns from step S111 to step S107 as described above.

In step S311, the setting unit 134 sends the values of all OBP environment variables of the requesting guest domain to the requesting guest domain via the communication unit 133 and the hypervisor 160. For convenience of explanation, for example, the following is assumed.

Guest domain 140 is the nth guest domain.
The setting unit 134 receives the request in step S102 of FIG. 8 from the guest domain 140 via the hypervisor 160 and the communication unit 133.

Under the assumptions described above, in step S311, the setting unit 134 reads the values of all entries from the environment variable table 200-n, and sets all the read values to the communication unit 133 and the hypervisor. The request is sent to the requesting guest domain 140 via 160.

Further, in step S311, the OBP state management unit 132 sets the value of the state flag of the guest domain 140 in the state list 220 to TRUE. Then, when the OBP is activated in the guest domain 140 while the control domain 130 is not operating (that is, when the OBP state management unit 132 cannot receive the notification in step S101 of FIG. 8), the value of the state flag is later Can be corrected.

After sending the OBP environment variable and updating the status flag, the processing in FIG. 10 returns from step S311 to step S302.

Next, details of the environment variable update process in step S301 in FIG. 10 will be described. 11 to 12 are flowcharts of the environment variable update process in the second embodiment. Similar to the description of FIG. 7, in the description of FIGS. 11 to 12, the number of guest domains is N (1 ≦ N).
In step S401, the update unit 135 initializes the index variable n to 1.

Next, in step S402, the update unit 135 refers to the value of the status flag of the nth guest domain in the status list 220 in the control domain 130. The state list 220 is managed by the OBP state management unit 132 and can also be referred to from the update unit 135.

If the value of the status flag is FALSE, the processing of FIGS. 11 to 12 proceeds to step S403. Conversely, if the value of the status flag is TRUE, the processing in FIGS. 11 to 12 proceeds to step S405.

In step S403, the update unit 135 increments the index variable n by 1.
Then, in the next step S404, the updating unit 135 determines whether or not n> N. In the case of n> N, since the processing for all the guest domains has already been completed, the processing in FIGS. On the other hand, if n ≦ N, there are still guest domains that the update unit 135 has not focused on, so the processing in FIGS. 11 to 12 returns to step S402.

Here, it supplements about the branch in step S402. The branching in step S402 means the following.

When the value of the status flag is FALSE, the latest value of each OBP environment variable of the nth guest domain is stored in the environment variable table 200-n of the environment variable storage unit 131. Therefore, it is not necessary to update the environment variable table 200-n.
When the value of the status flag is TRUE, there is a possibility that the value stored in the environment variable table 200-n of the environment variable storage unit 131 is not the latest. Therefore, the values stored in the environment variable table 200-n are updated as appropriate by the processing from step S405.

The meaning of the branching in step S402 will be described in more detail as follows.
As described above, FIGS. 1 and 2 also apply to the second embodiment. The boot loader 1, the second virtual machine 2, and the second processor 3 in FIGS. 1 and 2 correspond to the OBP of the guest domain 140, the control domain 130, and the storage control unit 172 in the SP 170, respectively.

Specifically, when the OBP of the guest domain 140 continues to operate even after the OS of the control domain 130 stops operating as in the situation 4A and 4B of FIG. 1 (that is, when T_down <T_end), the guest domain 140 The value of the status flag is TRUE. This is because the value of the status flag is set to TRUE in step S307 in FIG. 10 when the notification in step S101 in FIG. 8 is received by the control domain 130, and has not yet been changed to FALSE. .

When the value of the status flag is TRUE in this way, as illustrated in the situations 4A and 4B, after the OS of the control domain 130 has stopped operating last time, the process of FIG. In the meantime, the value of the OBP environment variable may have been changed. That is, there is a possibility that the value of the OBP environment variable is stored in the environment variable storage unit 171 between the time T_down and the time T_boot.

On the other hand, when the OBP of the guest domain 140 finishes operating before the OS of the control domain 130 stops operating (that is, when T_end <T_down), as in the situation 4C of FIG. 1, the status flag of the guest domain 140 The value of is FALSE. This is because the value of the status flag is set to FALSE in step S308 of FIG. 10 when the notification of step S114 of FIG. 8 at time T_end is received by the control domain 130, and has not yet been changed to TRUE. Because.

In the situation 4C, the OBP environment variable of the guest domain 140 after the OS of the control domain 130 stops operating at the previous time T_down and before the current processing of FIG. 10 is started in the control domain 130 at the time T_boot. Will not be changed.

Also, as in the situation 4D of FIG. 1, there is a case where the OBP of the guest domain 140 starts operating while the OS of the control domain 130 is not operating (that is, T_down <T_start <T_boot). Also in this case, the value of the status flag of the guest domain 140 is FALSE. The reason is as follows.

When the OBP of the guest domain 140 finishes operation last time (that is, before the time T_start), the notification of step S114 in FIG. 8 is sent, and as a result, the value of the status flag of the guest domain 140 is set to step S308 in FIG. Is set to FALSE. Thereafter, when the OBP of the guest domain 140 starts operating at time T_start, the notification of step S101 in FIG. 8 is sent from the guest domain 140. However, at this point, the control domain 130 is not operating. Therefore, the state list 220 in the control domain 130 is not updated.

Therefore, when the OS of the control domain 130 is started at time T_boot, the value of the status flag is FALSE although the OBP of the guest domain 140 is actually operating. However, there is no problem even if the value of the status flag is different from the actual status. The reason is as follows.

As can be seen from the situation 4D in FIG. 1 and the description of steps S102 to S105 in FIG. 8, the OBP of the guest domain 140 started while the OS of the control domain 130 is not operating waits for the control domain 130 to recover. Therefore, the OBP environment variable is not updated while the OS of the control domain 130 is not operating. Therefore, the determination that “the value of the status flag is FALSE, so all the values in the environment variable table 200-n are the latest” is correct.

Further, as shown in 4E of FIG. 1, even when the OBP of the guest domain 140 starts operation after the OS of the control domain 130 is restored (that is, when T_boot <T_start), the value of the status flag of the guest domain 140 is FALSE. It is. This is because the value of the status flag is set to FALSE in step S308 of FIG. 10 when the notification of step S114 of FIG. 8 was previously received by the control domain 130 and has not yet been changed to TRUE. .

Even in the situation 4E, after the OS of the control domain 130 stops operating at the previous time T_down and before the processing of FIG. 10 is started in the control domain 130 at the time T_boot, the OBP environment of the guest domain 140 The variable is never changed.

As can be seen from the above description of the situations 4A to 4E and the second embodiment, when the value of the status flag is FALSE, all the values stored in the environment variable table 200-n are the latest. On the other hand, when the value of the status flag is TRUE, the value stored in the environment variable table 200-n may not be the latest.

Therefore, when the value of the status flag is FALSE, the processing of FIGS. 11 to 12 proceeds from step S402 to step S403 in order to pay attention to the next guest domain 140. Conversely, when the value of the status flag is TRUE, the processing in FIGS. 11 to 12 proceeds from step S402 to step S405 in order to keep the environment variable table 200-n in the latest state.

In step S405, the updating unit 135 requests the OBP of the nth guest domain to send the values of all OBP environment variables via the communication unit 133 and the hypervisor 160. If this request is received by the nth guest domain when the nth guest domain is in the OBP operating state, the process of FIG. 8 proceeds from step S108 to step S109, and from the nth guest domain in step S109. The value of all OBP environment variables is sent.

Therefore, the update unit 135 of the control domain 130 waits in step S406 for any of the following events to occur.

An event that the updating unit 135 has received values of all OBP environment variables of the nth guest domain from the nth guest domain via the hypervisor 160 and the communication unit 133.
An event that a predetermined time has elapsed since the transmission of the request in step S405.

When the former event occurs, the processing of FIGS. 11 to 12 proceeds from step S406 to step S407. When the latter event occurs, the processing in FIGS. 11 to 12 proceeds from step S406 to step S408. Note that the predetermined time in step S406 may also be determined based on an average RTT related to communication between the control domain 130 and the guest domain, similarly to the predetermined time in steps S103 and S111 of FIG.

In step S407, the updating unit 135 stores the values of all OBP environment variables received from the nth guest domain in the environment variable storage unit 131. Specifically, the updating unit 135 writes each received value in an entry corresponding to the value in the environment variable table 200-n. In addition, the update unit 135 updates the time information to a value indicating the current time in each entry updated in this way. Then, the processing of FIGS. 11 to 12 proceeds to step S403. For example, in the situation 4B of FIG. 1, the values “A2”, “B2”, and “C1” are stored in the environment variable storage unit 131 in step S407 as described above.

On the other hand, in step S408, the update unit 135 notifies the OBP state management unit 132 that communication with the OBP of the nth guest domain has failed. Then, the OBP state management unit 132 sets the state flag of the nth guest domain in the state list 220 to FALSE.

For example, as in the situation 4A of FIG. 1, the OBP of the nth guest domain that was operating when the control domain 130 was shut down may stop operating while the control domain 130 is shut down. In this case (that is, when T_down <T_end <T_boot), the value of the status flag of the nth guest domain is rewritten from TRUE to FALSE in step S408. As a result, the state flag correctly reflects the state of the nth guest domain.

Next, in step S409, the updating unit 135 requests the SP 170 to send the OBP environment variable of the nth guest domain, if any, via the communication unit 133 and the hypervisor 160. In the following, for simplification of explanation, it is assumed that “SP 170 is operating normally when the request is sent”.

Under such assumption, the request is normally received by the SP 170. Then, when the request is received at SP 170, as described above, the process proceeds from step S201 to step S202 in FIG. In step S202, all the values of the OBP environment variable of the nth guest domain stored in the environment variable storage unit 171 are sent.

Therefore, according to the above assumption, in step S410 following step S409, the updating unit 135 receives a response to the request in step S409 from the SP 170 via the hypervisor 160 and the communication unit 133. Hereinafter, for convenience of explanation, it is assumed that the environment variable storage unit 171 of SP 170 stores the values of J OBP environment variables of the nth guest domain.

Therefore, the updating unit 135 receives the values of J OBP environment variables among a plurality of OBP environment variables defined in the OBP of the nth guest domain in step S410. As is apparent from FIGS. 8 and 9, J = 0 may be possible, J = 1 may be possible, and J ≧ 2 may be possible. For example, in situation 4A of FIG. 1, J = 1 and one value “B2” is received in step S410.

Subsequently, in step S411 in FIG. 12, the update unit 135 initializes the index variable j to 1.

Next, in step S412, the update unit 135 determines whether j> J. When j> J, one of the following two conditions is satisfied.

-J> 0, and the processing for the values of all J OBP environment variables acquired from SP 170 for the nth guest domain has already been completed.
J = 0 (that is, the environment variable storage unit 171 of the SP 170 does not store any OBP environment variable value for the nth guest domain).

Therefore, when j> J, in order to focus on the next guest domain, the processing of FIGS. 11 to 12 proceeds to step S403. On the other hand, if j ≦ J, one or more values of the OBP environment variable not yet noticed by the updating unit 135 remain, so the processing in FIGS. 11 to 12 proceeds to step S413.

In step S413, the updating unit 135 compares the following two times.
The time indicated by the time information received together with the value of the jth OBP environment variable among the values of the J OBP environment variables received from the SP 170. That is, the time when the value of the j-th OBP environment variable is stored in the environment variable storage unit 171 of SP 170 in step S204 of FIG.
The time indicated by the time information stored in the environment variable table 200-n of the environment variable storage unit 131 regarding the j-th OBP environment variable. That is, the time at which a value is stored in the environment variable storage unit 131 of the control domain 130 in the past step S309 regarding the jth OBP environment variable.

If the former time is later than the latter time, the processing in FIGS. 11 to 12 proceeds to step S414. Conversely, if the former time is the same as the latter time, or if the former time is earlier than the latter time, the processing in FIGS. 11 to 12 proceeds to step S415.

By the way, the OBP of the nth guest domain corresponds to the boot loader 1 of FIGS. 1 and 2, the control domain 130 corresponds to the second virtual machine 2 of FIGS. 1 and 2, and SP170 (more specifically, the storage control unit). 172) corresponds to the second processor 3 of FIGS.

For example, in the situation 4A of FIG. 1, the time when the value “B2” is stored in the environment variable storage unit 171 of the SP 170 is greater than the time when the value “B1” is stored in the environment variable storage unit 131 of the control domain 130. It will be later. Therefore, in the situation 4A, the processing of FIGS. 11 to 12 proceeds from step S413 to step S414. Conversely, when the situation changes as follows, the processing in FIGS. 11 to 12 may shift from step S413 to step S415.

As in the situation 4H in FIG. 2, the value of the OBP environment variable “B4” is stored in the environment variable storage unit 171 of the SP 170 while the control domain 130 is shut down due to an error or the like and the control domain 130 is not operating. Is saved.
Thereafter, the control domain 130 is restored. As in the situation 4H, when the control domain 130 is restored, the OBP of the nth guest domain is still operating. Therefore, the processing of FIGS. 11 to 12 proceeds from step S406 to S407. In this case, the SP 170 does not receive the request in step S409, and as a result, step S203 in FIG. 9 is not executed. Therefore, the value “B4” remains in the environment variable storage unit 171 of SP170.
In the situation 4H in FIG. 2, after the control domain 130 is restored, only the third environment variable is updated (that is, the value “C3” is updated to the value “C4”). The environment variable may be updated from the value “B4” to the value “B5”. That is, the update unit 135 of the restored control domain 130 may store a new value “B5” in the environment variable storage unit 131 in step S309 in response to a request from the OBP of the nth guest domain. Then, after the update, the OBP of the nth guest domain may stop operating and the OS may be started in the nth guest domain.
-At some point after that, the OBP of the nth guest domain may start to operate again as in the situation 4H. There is a possibility that the control domain 130 may be shut down again due to an error or the like during the operation of the OBP of the nth guest domain.
Here, it is assumed that the OBP of the nth guest domain has stopped operating before the control domain 130 is restored. Further, it is assumed that the OBP environment variable of the nth guest domain has not been saved in the SP 170 at the time of the second shutdown of the control domain 130.
When the control domain 130 recovers from the shutdown again, the processing in FIGS. 11 to 12 proceeds from step S406 to step S408. Therefore, the value “B4” remaining in the environment variable storage unit 171 of the SP 170 as described above is received by the update unit 135 in step S410. On the other hand, the new value “B5” is stored in the environment variable storage unit 131 of the control domain 130 as described above. Therefore, in this case, the processing of FIGS. 11 to 12 proceeds from step S413 to step S415.

As exemplified above, the processing in FIGS. 11 to 12 proceeds to step S414 or S415 in accordance with the comparison result in step S413.

In step S414, the update unit 135 updates the value stored in the environment variable storage unit 131 to the value of the jth OBP environment variable received from the nth guest domain. For example, when the value of the jth OBP environment variable received from the nth guest domain is specifically the value of the environment variable named “ENV_VAR_3”, the updating unit 135 stores the value in the environment variable table 200-n. The received value is written in the “setting value” field of the entry corresponding to the environment variable named “ENV_VAR — 3”.

Also, the updating unit 135 updates the time information of the entry. Specifically, the update unit 135 updates the time information of the entry to a value indicating the current time. Depending on the embodiment, the updating unit 135 may write the time information received together with the value of the jth OBP environment variable from the nth guest domain in the “time” field of the entry.

After the entry update as described above, the processing of FIGS. 11 to 12 proceeds to step S416.

In step S415, the updating unit 135 discards the value of the jth OBP environment variable received from the nth guest domain. This is because a newer value than the received value is already stored in the environment variable storage unit 131. Then, the processing of FIGS. 11 to 12 proceeds to step S416.

In step S416, the updating unit 135 increments the index variable j by 1. Then, the processing in FIGS. 11 to 12 returns to step S412.

As described above, according to the second embodiment described with reference to FIGS. 5 to 12, even when the update of the OBP environment variable of the guest domain 140 is requested while the control domain 130 does not operate normally for some reason, There will be no hindrance to future booting of the OS of the guest domain 140. This is because if the value of the OBP environment variable is updated on the OBP of the guest domain 140 while the control domain 130 is not operating, the new value is temporarily stored in the SP 170 (more specifically, the environment variable storage unit 171). ). This is because the temporarily stored new value is immediately reflected in the environment variable storage unit 131 of the control domain 130 after the control domain 130 is restored.

The second embodiment is also suitable when the number N of guest domains is large (for example, when N> 1000). This is because the update unit 135 uses the state list 220 to make the determination in step S402.

According to step S402, when it is clear that there is no possibility that “the value of the OBP environment variable of the nth guest domain has been changed while the control domain 130 is not operating”, the reception in step S406 is performed. No waiting time is spent. When the number N of guest domains is large, the reduction in reception waiting time greatly affects the reduction of the time required for the entire processing of FIGS. “The time required for the entire processing in FIGS. 11 to 12 is short” means that “from the time when the control domain 130 is restarted until the normal processing after step S302 in FIG. Means that the time is short. That is, the determination in step S <b> 402 using the state list 220 is useful for reducing the downtime of the control domain 130.

Subsequently, the third embodiment will be described with reference to FIGS. 1 to 4 also applies to the third embodiment, and therefore FIGS. 1 to 4 are also referred to as appropriate below. In addition, the description of the points in common with the second embodiment will be omitted as appropriate.

The third embodiment differs from the second embodiment in that there is only one guest domain in one physical partition. When there is only one guest domain, the effect of the time reduction effect using the state list 220 as in the second embodiment is not so significant. Therefore, in the third embodiment, state management using the state list 220 is omitted.

Specifically, the third embodiment is different from the second embodiment in the following points, but the third embodiment is the same as the second embodiment in other points.

The computer is configured as shown in FIG.
Steps S101 and S114 in FIG. 8 are omitted.
Steps S303 and S306 to S308 in FIG. 10 are also omitted.
Of the processing in step S305 in FIG. 10, deletion of entries from the status list 220 is also omitted.
Of the processes in steps S309 and S311 in FIG. 10, the update of the status flag is also omitted.
As the environment variable update processing in step S301 in FIG. 10, the processing in FIG. 14 is performed instead of the processing in FIGS.

FIG. 13 is a block diagram of a computer according to the third embodiment. The computer 300 of FIG. 13 includes one or more physical partitions. In the example of FIG. 13, the computer 300 includes two partitions 310 and 320.

Each partition includes one control domain and one guest domain. In the example of FIG. 13, the partition 310 includes a control domain 330 and a guest domain 340, and the partition 320 includes a control domain 350 and a guest domain 360.

The control domain 330, the guest domain 340, the control domain 350, and the guest domain 360 are all specific examples of virtual machines that operate on the hypervisor 370. The control domains 330 and 350 are both specific examples of the second virtual machine 2 described with reference to FIGS. Guest domains 340 and 360 are both specific examples of the first virtual machine described with reference to FIGS. Similar to the second embodiment, also in the third embodiment, a specific example of the boot loader 1 in FIGS. 1 and 2 is OBP.

FIG. 13 shows only one hypervisor 370 as in FIG. However, a separate hypervisor 370 may be executed for each partition.

Specifically, the control domain 330 includes an environment variable storage unit 331, a communication unit 332, a setting unit 333, and an update unit 334. The guest domain 340 specifically includes an OS activation unit 341, an environment variable management unit 342, and a communication unit 343.

The environment variable storage unit 331 is the same as the environment variable storage unit 131 of FIG. That is, the environment variable table 200-1 of FIG. 6 is stored in the environment variable storage unit 331 (note that N = 1 in the third embodiment). The communication unit 332 is the same as the communication unit 133, and the setting unit 333 is the same as the setting unit 134.

The update unit 334 is similar to the update unit 135. However, the update unit 334 differs from the update unit 135 in that the process of FIG. 14 is executed instead of the process of FIGS. 11 to 12 in step S301 of FIG. Further, the OBP state management unit 132 of the second embodiment is omitted in the third embodiment.

The OS startup unit 341 is the same as the OS startup unit 141 of FIG. 5, the environment variable management unit 342 is the same as the environment variable management unit 142, and the communication unit 343 is the same as the communication unit 143. In addition, the control domain 350 is similar to the control domain 330, and the guest domain 360 is similar to the guest domain 340.

Furthermore, the computer 300 also includes SP380. The SP 380 includes an environment variable storage unit 381, a storage control unit 382, and a communication unit 383. The environment variable storage unit 381 is the same as the environment variable storage unit 171 of FIG. That is, the environment variable table 210-1 of FIG. 6 is stored in the environment variable storage unit 381 (note that N = 1 in the third embodiment). Further, the storage control unit 382 is the same as the storage control unit 172, and the communication unit 383 is the same as the communication unit 173.

It should be noted that the computer 300 in FIG. 13 may also be realized by the computer 10 in FIG. 3 in a similar manner to the computer 100 in FIG. For example, the system board 20 may correspond to the partition 310, and the system board 30 may correspond to the partition 320. The relationship between FIG. 13 and FIG. 3 is clear from the above description of the relationship between FIG. 5 and FIG. Therefore, detailed description of the relationship between FIG. 13 and FIG. 3 is omitted.

FIG. 14 is a flowchart of the environment variable update process in the third embodiment. Hereinafter, a case where the environment variable update process is executed in the control domain 330 will be specifically described. In the third embodiment, as described above, there is only one guest domain in one physical partition. Therefore, the guest domain in the description of FIG. 14 is the guest domain 340 that is the only guest domain included in the same partition 310 as the control domain 330.

In step S501, the update unit 334 requests the OBP of the guest domain 340 to send the values of all OBP environment variables via the communication unit 332 and the hypervisor 370. If this request is received by the guest domain 340 when the guest domain 340 is in the OBP operating state, the processing in FIG. 8 proceeds from step S108 to step S109, and the values of all OBP environment variables are transferred from the guest domain 340 to step S109. Will be sent.

Therefore, the update unit 334 of the control domain 330 waits in step S502 for any of the following events to occur.

An event that the update unit 334 has received the values of all OBP environment variables of the guest domain 340 from the guest domain 340 via the hypervisor 370 and the communication unit 332.
An event that a predetermined time has elapsed since the transmission of the request in step S501.

When the former event occurs, the processing in FIG. 14 proceeds from step S502 to step S503. When the latter event occurs, the processing in FIG. 14 proceeds from step S502 to step S504. The predetermined time in step S502 may be determined based on, for example, an average RTT related to communication between the control domain 330 and the guest domain 340.

In step S503, the updating unit 334 stores the values of all OBP environment variables received from the guest domain 340 in the environment variable storage unit 331. Specifically, the update unit 334 writes each received value in the entry corresponding to the value in the environment variable table 200-1. In addition, the update unit 334 updates the time information to a value indicating the current time in each entry updated in this way. Then, the process of FIG. 14 is completed. For example, in the situation 4B of FIG. 1, the values “A2”, “B2”, and “C1” are stored in the environment variable storage unit 331 in step S503 as described above.

On the other hand, in step S504, the update unit 334 requests the SP 380 to send the OBP environment variable of the guest domain 340, if any, via the communication unit 332 and the hypervisor 370. In the following, for simplification of explanation, it is assumed that “SP 380 is operating normally at the time when the request is sent”.

Under such assumption, the request is received normally at SP380. When the request is received at SP 380, the process proceeds from step S201 to step S202 in FIG. In step S202, all the values of the OBP environment variable of the guest domain 340 stored in the environment variable storage unit 381 are sent.

Therefore, according to the above assumption, in step S505 following step S504, the update unit 334 receives a response to the request in step S504 from the SP 380 via the hypervisor 370 and the communication unit 332. In the following, for convenience of explanation, it is assumed that the value of J OBP environment variables of the guest domain 340 is stored in the environment variable storage unit 381 of the SP 380.

Therefore, the updating unit 334 receives the value of J OBP environment variables among the plurality of OBP environment variables defined in the OBP of the guest domain 340 in step S505. As is apparent from FIGS. 8 and 9, J = 0 may be possible, J = 1 may be possible, and J ≧ 2 may be possible. For example, in the situation 4A of FIG. 1, J = 1, and one value “B2” is received in step S505.

Subsequently, in step S506, the update unit 334 initializes the index variable j to 1.
Next, in step S507, the update unit 334 determines whether j> J. When j> J, one of the following two conditions is satisfied.

-J> 0, and the processing for the values of all J OBP environment variables acquired from the SP 380 regarding the guest domain 340 has already been completed.
J = 0 (that is, no value of the OBP environment variable for the guest domain 340 is stored in the environment variable storage unit 381 of the SP 380).

Therefore, when j> J, the process of FIG. 14 is completed. On the other hand, if j ≦ J, one or more OBP environment variable values not yet noticed by the updating unit 334 remain, so the processing in FIG. 14 proceeds to step S508.

In step S508, the update unit 334 compares the following two times.
The time indicated by the time information received together with the value of the jth OBP environment variable among the values of the J OBP environment variables received from the SP 380. That is, the time when the value of the j-th OBP environment variable is stored in the environment variable storage unit 381 of SP380 in step S204 of FIG.
The time indicated by the time information stored in the environment variable table 200-1 of the environment variable storage unit 331 for the jth OBP environment variable. That is, the time at which a value is stored in the environment variable storage unit 331 of the control domain 330 in the past step S309 regarding the jth OBP environment variable.

If the former time is later than the latter time, the processing in FIG. 14 proceeds to step S509. Conversely, if the former time is the same as the latter time, or if the former time is earlier than the latter time, the processing in FIG. 14 proceeds to step S510. Note that the comparison in step S508 is similar to the comparison in step S413 in FIG. Therefore, the meaning of the comparison in step S508 is clear from the description of FIG.

In step S509, the update unit 334 updates the value stored in the environment variable storage unit 331 to the value of the jth OBP environment variable received from the guest domain 340. For example, when the value of the j-th OBP environment variable received from the guest domain 340 is specifically the value of the environment variable named “ENV_VAR_3”, the update unit 334 stores the value of the environment variable table 200-1. The received value is written in the “setting value” field of the entry corresponding to the environment variable named “ENV_VAR — 3”.

Also, the update unit 334 updates the time information of the entry. Specifically, the update unit 334 updates the time information of the entry to a value indicating the current time. Depending on the embodiment, the updating unit 334 may write the time information received together with the value of the jth OBP environment variable from the guest domain 340 in the “time” field of the entry.

After the entry update as described above, the processing in FIG. 14 proceeds to step S511.

In step S510, the updating unit 334 discards the value of the jth OBP environment variable received from the guest domain 340. This is because a newer value than the received value is already stored in the environment variable storage unit 331. Then, the process of FIG. 14 proceeds to step S511.

In step S511, the update unit 334 increments the index variable j by 1. Then, the process of FIG. 14 returns to step S507.

As described above, according to the third embodiment described with reference to FIGS. 13 to 14, even when the OBP environment variable of the guest domain 340 is requested to be updated while the control domain 330 does not operate normally for some reason, There will be no trouble in the future activation of the OS of the guest domain 340. This is because if the value of the OBP environment variable is updated on the OBP of the guest domain 340 while the control domain 330 is not operating, the new value is temporarily stored in the SP 380 (more specifically, the environment variable storage unit 381 ). This is because the temporarily stored new value is immediately reflected in the environment variable storage unit 331 of the control domain 330 after the control domain 330 is restored.

Further, the third embodiment is particularly suitable when the number of guest domains is one. Specifically, in the third embodiment, since the OBP state management unit 132 is omitted and some steps in FIGS. 8 and 10 are omitted, there is no load for managing the state list 220. When the number of guest domains is very small, it may be preferable for the performance of the entire computer to eliminate the load for managing the state list 220, rather than the time reduction effect obtained by using the state list 220. . Therefore, especially when there is only one guest domain, it is preferable to omit management of the state list 220 as in the third embodiment.

Note that the embodiment in which the management of the state list 220 is omitted as in the third embodiment can be applied to a case where there are two or more guest domains. That is, when the number of guest domains is relatively small, management of the state list 220 may be omitted. For example, when the number of guest domains is 3, the process of FIG. 14 may be performed for each of the three guest domains.

Subsequently, the fourth embodiment will be described with reference to FIGS. In the fourth embodiment, when the OBP of the guest domain starts operating during the period when the control domain is not operating, the OBP can obtain the value of the OBP environment variable without waiting for the control domain to start. This is an embodiment obtained by modifying the second embodiment. Since the configuration of the computer according to the fourth embodiment is similar to the configuration of the computer according to the second embodiment, the fourth embodiment will be described using the reference numerals in FIG. 5 relating to the second embodiment.

FIG. 15 is a diagram for explaining various situations related to storage of environment variables in the fourth embodiment. The format of FIG. 15 is the same as that of FIG. That is, FIG. 15 shows a period during which the boot loader 1 of the first virtual machine operates, a period during which the second virtual machine 2 that manages environment variables of the boot loader 1 operates, and a period during which the second processor 3 operates. It is shown.

For example, the boot loader 1 is specifically the OBP of the guest domain 140, the second virtual machine 2 is specifically the control domain 130, and the second processor 3 is specifically SP 170 (especially storage Controller 172). Hereinafter, as in the description of FIG. 1, one or more processors for executing the hypervisor and a plurality of virtual machines operating on the hypervisor are referred to as “one or more first processors”. The second processor 3 does not execute the hypervisor and does not execute any virtual machine operating on the hypervisor. That is, the second processor 3 operates independently of the hypervisor. Description of other points in common with FIG. 1 will be omitted as appropriate.

In FIG. 15, situations 4I to 4K correspond to the above inequalities (A) to (C), respectively, situation 4L corresponds to the following inequalities (L), and situations 4M and 4N respectively correspond to the above inequalities (D ) And (E). Along with inequality (L), inequality (A) to (E) are shown again for reference.

T_start <T_down <T_end <T_boot (A) …… Situation 4I
T_start <T_down <T_boot <T_end (B) …… Situation 4J
T_start <T_end <T_down <T_boot (C) …… Situation 4K
T_down <T_start <T_end <T_boot (L) …… Situation 4L
T_down <T_start <T_boot <T_end (D) …… Situation 4M
T_down <T_boot <T_start <T_end (E) …… Situation 4N

In the situation 4I, as in the situation 4A, the value of the first environment variable is updated to “A2” before the time T_down. That is, the value “A2” is normally stored in the first storage device (specifically, the environment variable storage unit 131).

However, unlike the situation 4A, in the situation 4I, when the first processor executing the second virtual machine 2 among the one or more first processors receives the value “A2” from the boot loader 1, The received value “A2” is further sent to the second processor 3. Then, the second processor 3 stores the value “A2” in the second storage device (specifically, the environment variable storage unit 171).

In the situation 4I, as in the situation 4A, the first processor executing the boot loader 1 at a certain time after the time T_down and before the time T_boot stores the value “B2” of the second environment variable. The second virtual machine 2 is requested. However, since the second virtual machine 2 is not operating, a response to the request is not returned within a predetermined time.

In this case, the first processor executing the boot loader 1 requests the second processor 3 to save the value “B2” of the second environment variable in the second storage device. Upon request, the value “B2” is stored in the second storage device.

Then, when the second virtual machine 2 is restarted at time T_boot, the first processor that executes the second virtual machine 2 out of the one or more first processors is connected to the first processor 1 through the second processor 3. Get the value of the third environment variable. In the fourth embodiment, the values of all environment variables of the boot loader 1 are also held in the second storage device accessed from the second processor 3. Therefore, the second processor 3 can return the value of any environment variable at any time upon request.

In the situation 4I, specifically, among the one or more first processors, the first processor that executes the second virtual machine 2 sets values “A2”, “B2”, and “C1”. Obtained from the second processor 3. Of the acquired three values, two values “A2” and “C1” are the same as the values stored in the first storage device accessed from the second virtual machine 2. However, the value “B2” is newer than the value stored in the first storage device. Therefore, the first processor that has started the execution of the second virtual machine 2 in response to the restart of the second virtual machine 2 stores the value “B2” in the first storage device.

The situation 4J is similar to the situation 4I, but is different from the situation 4I in that the boot loader 1 is still operating when the second virtual machine 2 is restarted at the time T_boot. Therefore, in the situation 4J as in the situation 4B, the first processor that has started the execution of the second virtual machine 2 in response to the restart of the second virtual machine 2 obtains the latest environment variable value from the boot loader 1. get. Then, the first processor that executes the second virtual machine 2 stores at least the value “B2” of the second environment variable in the first storage device. As a result, the update of the environment variable performed while the second virtual machine 2 was not operating is reflected in the first storage device.

Also, in the situation 4J as in the situation 4B, the boot loader 1 continues to operate until after the time T_boot. Therefore, after the environment variable on the first storage device is updated to the latest state as described above, the environment variable may be further updated.

For example, the value of the third environment variable may be updated to “C2” after time T_boot. In the update of the third environment variable, the same processing as that performed when the first environment variable is updated from “A1” to “A2” is performed.

Specifically, when the first processor executing the second virtual machine 2 among the one or more first processors receives the value “C2” from the boot loader 1, the received “C2” Is stored in the first storage device. Further, the first processor executing the second virtual machine 2 further sends the received value “C2” to the second processor 3. Then, the second processor 3 stores the value “A2” in the second storage device.

In the situation 4K, as in the situation 4I and 4J, the first environment variable is changed from the value “A1” to the value “A2” while both the boot loader 1 and the second virtual machine 2 are operating. May be updated. However, in the situation 4K, when the second virtual machine 2 stops operating at the time T_down, the boot loader 1 is not already operating.

Therefore, in the situation 4K, the environment variable is not updated by the boot loader 1 while the second virtual machine 2 is not operating. Therefore, in the situation 4K, the first processor that has started the execution of the second virtual machine 2 in response to the restart of the second virtual machine 2 at time T_boot does not need to acquire the value of the environment variable.

By the way, as in the situation 4L, the boot loader 1 may happen to be activated while the second virtual machine 2 is not operating. In this case, the first processor that has started execution of the boot loader 1 among the one or more first processors requests the second virtual machine 2 to send the values of all environment variables of the boot loader 1. However, since the second virtual machine 2 is not operating, a response to the request cannot be obtained.

In this case, the first processor executing the boot loader 1 sends the values of all environment variables of the boot loader 1 instead of waiting for the second virtual machine 2 to start as shown in the situation 4D of FIG. Request to the second processor 3. Then, the second processor 3 sends the values of all environment variables stored in the second storage device to the first processor that is executing the boot loader 1.

Therefore, in the fourth embodiment, the first processor that is executing the boot loader 1 can execute appropriate processing using the values of the environment variables acquired from the second processor 3 as initial values. Further, similarly to the situation 4I, while the second virtual machine 2 is not operating, a new value “B2” is sent from the boot loader 1 to the second processor 3, and the value “B2” is set. It may be stored in the second storage device.

Further, unlike the situation 4D in FIG. 1, in the situation 4L, the first processor that is executing the boot loader 1 does not wait for the second virtual machine 2 to start. Therefore, the first processor may end the execution of the boot loader 1 before starting the second virtual machine 2 at time T_boot. That is, the OS may be activated in the first virtual machine before time T_boot.

When T_end <T_boot is satisfied in this way, when the second virtual machine 2 is restarted at time T_boot, the first processor that executes the second virtual machine 2 among the one or more first processors The values of the first to third environment variables are acquired from the second processor 3. The acquisition of the value of the environment variable from the second processor 3 at the time T_boot in the situation 4L is the same as the acquisition in the situation 4I.

By the way, in the situation 4L, the execution of the boot loader 1 ends before the time T_boot. However, as in the situation 4M, the execution of the boot loader 1 may continue until after the time T_boot. In this case, similarly to the situation 4J, the first processor that has started the execution of the second virtual machine 2 in response to the restart of the second virtual machine 2 receives the value of the latest environment variable from the boot loader 1 (that is, , “A1”, “B2”, and “C1”).

Then, the first processor that executes the second virtual machine 2 stores at least the value “B2” of the second environment variable in the first storage device. As a result, the update of the environment variable performed while the second virtual machine 2 was not operating is reflected in the first storage device.

Furthermore, in the situation 4M, as in the situation 4J, the value of the third environment variable may be updated to “C2”. In this case, the updated value “C2” is not only stored in the first storage device, but is also sent from the second virtual machine 2 to the second processor 3 to be stored in the second storage device. Saved in.

Now, similarly to the situation 4E of FIG. 1, in the situation 4N, the boot loader 1 is started at the time T_start after the second virtual machine 2 is restarted. Therefore, as in the situation 4E, in the situation 4N, there is no environment variable whose value is updated while the second virtual machine 2 is not operating. That is, in the situation 4N, the processor that has started the execution of the second virtual machine 2 in response to the restart of the second virtual machine 2 among the one or more first processors acquires the value of the environment variable. There is no need.

In the situation 4N, as in the situation 4E, the processor that has started execution of the boot loader 1 in response to the boot loader 1 activation among the one or more first processors sets the values of all environment variables of the boot loader 1 Request to the second virtual machine 2 to send. In the situation 4N, the second virtual machine 2 is operating at the time T_start when this request is issued. Therefore, among the one or more first processors, the first processor that is executing the boot loader 1 responds to the request with the values “A1”, “B1”, and “ C1 "can be acquired.

Furthermore, in the situation 4N as well as the situation 4M, the value of the third environment variable may be updated to “C2” thereafter. That is, the value “C2” is not only stored in the first storage device, but is further sent from the second virtual machine 2 to the second processor 3 and stored in the second storage device.

As illustrated above, there can be various situations 4I to 4N. According to the fourth embodiment, in any situation, “the next startup of the OS of the first virtual machine due to a failure that occurs in the second virtual machine 2 that controls the saving of the environment variable of the boot loader 1” The problem of “being hindered” is avoided.

Further, according to the fourth embodiment, the latest value of the environment variable of the boot loader 1 is continuously held in the second storage device accessed from the second processor 3. Therefore, even if the second virtual machine 2 is out of order (that is, even if the second virtual machine 2 is not operating), the first processor that has started to execute the boot loader 1 among the one or more first processors is The initial value of the environment variable can be obtained without waiting for the second virtual machine 2 to start. That is, according to the fourth embodiment, the first processor that has started executing the boot loader 1 can immediately start another process using the environment variable.

FIG. 16 is a diagram showing a comparison between the fourth embodiment and a comparative example. In FIG. 16, the situation 4O according to the comparative example is compared with the situation 4P according to the fourth embodiment, and the situation 4Q according to the comparative example is compared with the situation 4R according to the fourth embodiment. The format of FIG. 16 is the same as that of FIG.

The situation 4O regarding the comparative example is the same as the situation 4F in FIG. Therefore, in the situation 4O, the value “B4” of the second environment variable is not saved, and as a result, the OS of the first virtual machine may be unable to start.

On the other hand, according to the fourth embodiment, even if the second virtual machine 2 fails, it will not hinder the future startup of the OS of the first virtual machine. For example, according to the situation 4P similar to the situation 4I in FIG. 15, the value of the first environment variable is normally updated from “A3” to “A4” during the operation of the second virtual machine 2, The updated value “A4” is stored in both the first storage device and the second storage device. In addition, for the second environment variable requested to be updated by the boot loader 1 while the second virtual machine 2 is not operating, the updated value “B4” is temporarily stored in the second storage device. The data is saved and then reflected in the first storage device after the second virtual machine 2 is restored.

Therefore, when the boot loader 1 is called again at time T_next after the time T_boot, the processor that executes the boot loader 1 among the one or more first processors sets the latest value of each environment variable to the second virtual value. It can be obtained from the machine 2. That is, the first processor that has started execution of the boot loader 1 at time T_next can obtain the latest values “A4”, “B4”, and “C3”. As a result, there is no problem that may occur in the situation 4O when the OS is booted from the boot loader 1 at a certain time after the time T_next.

By the way, situations 4O and 4P are examples of situations in which the inequality (A-2), which will be re-described below, holds.
T_start <T_down <T_end <T_boot <T_next (A-2)

On the other hand, situations 4Q and 4R are examples of situations where the following inequality (D-2) holds.
T_down <T_start <T_boot <T_end <T_next (D-2)

In the situation 4Q according to the comparative example, the second processor 3 is not used for saving the environment variable of the boot loader 1. Therefore, in the situation 4Q, when the boot loader 1 is started when the second virtual machine 2 is not operating, the first processor executing the boot loader 1 among the one or more first processors is the second one. The value of the environment variable cannot be obtained from the virtual machine 2.

In this case, in the comparative example, the first processor that executes the boot loader 1 uses a fixed default value of each environment variable. In FIG. 16, the default values of the first to third environment variables are represented as “A0”, “B0”, and “C0”, respectively.

∙ By using the default value, the situation that "the value of each environment variable is undefined" is avoided. Therefore, the boot loader 1 can be executed. Therefore, in the process of executing the boot loader 1, as shown in FIG. 16, the first processor that executes the boot loader 1 sets a new value “B4” of the second environment variable to the second virtual machine 2. It may be required to save.

However, in the situation 4Q, the second virtual machine 2 is not operating at the time when the request is issued. Therefore, the value “B4” is not stored anywhere.

Also, the execution of the boot loader 1 may continue until after the second virtual machine 2 is started at time T_boot. Then, among the one or more first processors, the first processor that is executing the boot loader 1 at a certain time after the time T_boot updates the third environment variable to the value “C4”. There may be a case where two virtual machines 2 are requested. Since the second virtual machine 2 is operating at the time when the request is issued, the value “C4” is normally stored in the first storage device.

However, in the situation 4Q, when the boot loader 1 finishes the operation at the time T_end in the first virtual machine, there is a possibility that the OS is unable to start on the first virtual machine. This is because in the situation 4Q, the values “A0”, “B4”, and “C4” are stored in the memory used by the first processor that executes the boot loader 1 at the time T_end.

Specifically, the OS activation from the boot loader 1 is attempted using the values “A0”, “B4”, and “C4” stored in the memory. Therefore, if the default value “A0” is inappropriate (even if the two values “B4” and “C4” updated during the operation of the boot loader 1 are appropriate), the OS cannot be started. There is a risk of falling. For example, if the current configuration of the first virtual machine and the default value “A0” are inconsistent, the OS may not be bootable.

Further, even if the OS is successfully started on the first virtual machine according to the values “A0”, “B4”, and “C4”, the next OS startup is not always successful. This is because the value “B4” is not stored in the nonvolatile first storage device.

Among the one or more first processors, the first processor that starts executing the boot loader 1 when the boot loader 1 is called again at time T_next sends the value of each environment variable to the second virtual machine 2. Request that. Of the one or more first processors, the first processor that is executing the second virtual machine 2 at time T_next reads the value of each environment variable from the first storage device in response to the request. However, as described above, the value “B4” is not stored in the first storage device.

Therefore, the values “A3”, “B3”, and “C4” are returned to the first processor that is executing the boot loader 1. As described above, when the old value “B3” is returned instead of the latest value “B4”, the boot loader 1 may fail to start at a certain time after the time T_next.

As described above, in the situation 4Q, there is a possibility that the OS on the first virtual machine may become unbootable due to a failure of the second virtual machine 2. However, in the situation 4R where the inequality (D-2) holds as in the situation 4Q, the problem that occurs in the situation 4Q is avoided.

Because, in the situation 4R, when the boot loader 1 is activated while the second virtual machine 2 is not operating, the first processor that has started executing the boot loader 1 among the one or more first processors is: This is because the latest value of each environment variable is acquired from the second processor 3. Therefore, the problem caused by using the default value as in the situation 4Q does not occur.

In the situation 4R, if a request for updating the value of the second environment variable to “B4” is issued while the second virtual machine 2 is not operating, a new “B4” is created. This value is sent to the second processor 3 and stored in the second storage device.

Furthermore, in the situation 4R, the second virtual machine 2 is started at time T_boot. At this time, the first processor that has started execution of the second virtual machine 2 among the one or more first processors is the first processor that is executing the boot loader 1 at time T_boot among the one or more first processors. The latest value of each environment variable is acquired from one processor. Then, the first processor that executes the second virtual machine 2 replaces the old value “B3” stored in the first storage device with the updated value “B4” based on the acquired value. Rewrite to

Also, the execution of the boot loader 1 may continue until after the second virtual machine 2 is started at time T_boot. Then, among the one or more first processors, the first processor that is executing the boot loader 1 at a certain time after the time T_boot updates the third environment variable to the value “C4”. There may be a case where two virtual machines 2 are requested.

Since the second virtual machine 2 is operating at the time when the request is issued, the value “C4” is normally stored in the first storage device. Further, the value “C4” is sent from the first processor executing the second virtual machine 2 to the second processor 3 and is also stored in the second storage device.

Therefore, when the boot loader 1 is called again at time T_next after time T_end, the processor that executes the boot loader 1 among the one or more first processors sets the latest value of each environment variable to the second virtual value. It can be obtained from the machine 2. That is, the first processor that has started execution of the boot loader 1 at time T_next can obtain the latest values “A3”, “B4”, and “C4”. As a result, there is no problem that may occur in the situation 4Q when the OS is booted from the boot loader 1 at a certain time after the time T_next.

Thus, according to the fourth embodiment, problems that may occur in the comparative example are avoided. Specifically, in the fourth embodiment, the above problem can be avoided by processing using the update list 230 illustrated in FIG. Therefore, the fourth embodiment will be described in more detail according to the following specific assumptions.

The boot loader 1 in FIGS. 15 to 16 is specifically an OBP of the guest domain 140.
The second virtual machine 2 in FIGS. 15 to 16 is specifically the control domain 130.
The second processor 3 in FIGS. 15 to 16 is specifically SP170.

For example, when the SP 170 is realized by the SP 50 in FIG. 3, the update list 230 in FIG. 17 may be stored in the nonvolatile memory 52 or the memory 53. The update list 230 is managed by the storage control unit 172.

The update list 230 has N entries corresponding to N guest domains. The nth entry in the update list 230 indicates whether the value of the environment variable is stored in the environment variable storage unit 171 while the control domain 130 is not operating according to the request from the OBP of the nth guest domain. (1 ≦ n ≦ N). Specifically, each entry includes a domain number and an update flag.

While the control domain 130 is not operating according to the request from the guest domain OBP identified by the domain number, the value of the environment variable is stored in the environment variable storage unit 171 (specifically, the environment variable table 210-n). When saved, the value of the update flag is TRUE. On the contrary, when the control domain 130 is not operating, the OBP of the guest domain identified by the domain number is not requested to store the environment variable value in the environment variable storage unit 171. The value of the flag is FALSE.

Incidentally, in the fourth embodiment, the processes of FIGS. 8 to 12 relating to the second embodiment are modified as follows.

Steps S104 to S105 in FIG. 8 are replaced with processing in which the environment variable management unit 142 requests the SP 170 to send the values of all OBP environment variables. When the environment variable management unit 142 receives the values of all OBP environment variables from the SP 170, the environment variable management unit 142 executes the steps after step S106.
SP 170 operates according to the flowchart of FIG. 18 instead of the flowchart of FIG.
When a new guest domain is added, the setting unit 134 requests the SP 170 via the communication unit 133 and the hypervisor 160 to save the default value of each OBP environment variable of the added guest domain. This request is issued before step S303 in FIG. 10, between steps S303 and S304, or after step S304.
When the update unit 135 receives the value of the OBP environment variable from the guest domain 140, the update unit 135 sends the received value to the SP 170 via the communication unit 133 and the hypervisor 160. For example, the update unit 135 may send the value of the OBP environment variable received from the guest domain 140 to the SP 170 after step S310 in FIG. Of course, the updating unit 135 may send the value of the OBP environment variable to the SP 170 before step S309 or between steps S309 and S310. The updating unit 135 receives ACK from the SP 170 via the hypervisor 160.
As the environment variable update process in step S301 of FIG. 10, the processes of FIGS. 11 to 12 are executed in the second embodiment, but in the fourth embodiment, the process flow shown in FIG. 11 is changed to the process flow shown in FIG. Replaced. Note that steps S411 to S416 in FIG. 12 are common to the second embodiment and the fourth embodiment.

FIG. 18 is a flowchart of processing performed by the SP 170 in the fourth embodiment regarding the OBP environment variable. The difference between FIG. 9 and FIG. 18 is that step S203 is omitted in FIG. 18 and steps S206 to S210 are added. Further, the types of events that the SP 170 waits in step S201 is two types in FIG. 9, but in FIG. 18, there are four types according to the addition of steps S207 to S210.

In the fourth embodiment, since step S203 is omitted, the value of the OBP environment variable stored in the environment variable storage unit 171 is not discarded. That is, the value once stored in the environment variable storage unit 171 may be updated in step S204, but not deleted. Therefore, as shown in the situation 4L in FIG. 15, the situation 4M in FIG. 15, and the situation 4R in FIG. 16, the SP 170 responds to the request from the OBP of the guest domain 140 at all points in time. The value of the OBP environment variable can be returned to the guest domain 140.

Hereinafter, steps S206 to S210 added in FIG. 18 will be described.
For convenience of explanation, the operation in step S206 when the SP 170 receives the value of the OBP environment variable from the guest domain 140 will be described. In this case, after the transmission of the ACK in step S205, the storage control unit 172 sets the update flag of the guest domain 140 to TRUE in step S206. That is, the storage control unit 172 rewrites the update flag to TRUE in the entry corresponding to the guest domain 140 in the update list 230 of FIG. Then, the process of FIG. 18 returns to step S201.

In the fourth embodiment, as shown in FIGS. 15 to 16, the SP 170 may receive the value of one OBP environment variable of an arbitrary guest domain from the control domain 130 via the hypervisor 160. For example, in the situation 4I, the SP 170 receives the value “A2” from the control domain 130. As described above, even when a new guest domain is added, the SP 170 receives the default values of all the OBP environment variables of the added guest domain from the control domain 130 via the hypervisor 160.

For convenience of explanation, the operation in step S207 when the SP 170 receives the values of one or more OBP environment variables of the guest domain 140 from the control domain 130 via the hypervisor 160 will be described. In this case, according to reception of the value of the OBP environment variable, the processing in FIG. 18 proceeds from step S201 to step S207.

Then, in step S207, the storage control unit 172 sends each of the values of one or more OBP environment variables of the guest domain 140 received from the control domain 130 to the environment variable storage unit 171 together with current time information indicating the current time. save. For example, assume that the guest domain 140 is the nth guest domain. In this case, the storage control unit 172 adds each of the received one or more OBP environment variable values to the entry identified by the name of the OBP environment variable in the environment variable table 210-n together with the current time information. save.

Next, in step S208, the storage control unit 172 transmits ACK to the control domain 130 via the communication unit 173 and the hypervisor 160. After the transmission of ACK, the process in FIG. 18 returns to step S201.

As will be described in detail later with reference to FIG. 19, in the fourth embodiment, the SP 170 may receive an inquiry from the control domain 130 for each update flag in the update list 230. When the SP 170 receives an inquiry from the control domain 130 via the hypervisor 160, the processing in FIG. 18 proceeds from step S201 to step S209.

In step S209, the storage control unit 172 refers to the update list 230 and acquires the value of the update flag of each guest domain. Then, the storage control unit 172 notifies the control domain 130 of the update flag value of each guest domain via the communication unit 173 and the hypervisor 160.

Subsequently, in step S210, the storage control unit 172 sets the update flags of all guest domains to FALSE. Then, the process of FIG. 18 returns to step S201.

According to the above step S210, every time the control domain 130 is activated, the update flag values of all guest domains are initialized to FALSE. Therefore, as is clear from step S206, only the value of the update flag of the guest domain that has sent the value of the OBP environment variable to the SP 170 while the control domain 130 is not operating is rewritten to TRUE. Therefore, according to steps S210 and S206, the value of each update flag in the update list 230 is correctly managed.

FIG. 19 is a flowchart of the environment variable update process in the fourth embodiment. The difference between FIG. 11 and FIG. 19 is that steps S401a and S402a are added in FIG. 19, and step S407 in FIG. 11 is replaced with step S407a in FIG. Therefore, it demonstrates centering on step S401a, S402a, and S407a, and abbreviate | omits description about the remaining steps suitably.

When the environment variable update process is started, in step S401a, the update unit 135 acquires the update flag value of each of the N guest domains from the SP 170 via the communication unit 133 and the hypervisor 160. That is, the update unit 135 sends the above-described inquiry described with respect to step S209 in FIG. 18 to the SP 170 via the communication unit 133 and the hypervisor 160. Then, the update unit 135 receives the update flag values of the N guest domains from the SP 170 via the hypervisor 160 and the communication unit 133 as a response to the inquiry.

Next, in step S401, the update unit 135 initializes the index variable n to 1.
In step S <b> 402, the updating unit 135 refers to the value of the status flag of the nth guest domain in the status list 220 in the control domain 130. If the value of the status flag is FALSE, the process in FIG. 19 proceeds to step S402a. Conversely, if the value of the status flag is TRUE, the process of FIG. 19 proceeds to step S405 as in FIG. 11 of the second embodiment.

In step S402a, the update unit 135 refers to the update flag value of the nth guest domain. As described above, the value of the update flag of the nth guest domain has been acquired in step S401a. In other words, the update unit 135 determines in step S402a whether or not the SP 170 has received a request for saving the value of the OBP environment variable from the nth guest domain based on the inquiry in step S401a. recognize.

If the value of the update flag is FALSE (that is, if the update unit 135 recognizes that “the SP 170 has not received the request”), the processing in FIG. 19 proceeds to step S403. Conversely, if the value of the update flag is TRUE (that is, if the update unit 135 recognizes that “the SP 170 has received the request”), the processing in FIG. 19 proceeds to step S405.

Steps S403 to S406 and S408 to S410 in FIG. 19 are the same as those in FIG. Therefore, description of these steps is omitted. Following step S410, step S411 of FIG. 12 is executed. If it is determined in step S412 in FIG. 12 that j> J, the process returns from step S412 to step S403 in FIG.

Incidentally, as described above, step S407 in FIG. 11 is replaced with step S407a in FIG. That is, when the updating unit 135 receives the values of all the OBP environment variables of the nth guest domain from the nth guest domain via the hypervisor 160 and the communication unit 133 as a response to the request in step S405, FIG. The process proceeds to step S407a.

In step S407a, the updating unit 135 stores the values of all OBP environment variables received from the nth guest domain in the environment variable storage unit 131, as in step S407. The update unit 135 updates the time information to a value indicating the current time in each update target entry in the environment variable table 200-n.

For example, in the situation 4J of FIG. 15, the values “A2”, “B2”, and “C1” are stored in the environment variable storage unit 131 in step S407a as described above. In the situation 4M, the values “A1”, “B2”, and “C1” are stored in the environment variable storage unit 131 in step S407a as described above.

Furthermore, in step S407a, the OBP state management unit 132 sets the state flag of the nth guest domain in the state list 220 to TRUE. For example, the update unit 135 may notify the OBP state management unit 132 of successful communication with the OBP of the nth guest domain, and the OBP state management unit 132 sets the state flag to TRUE in response to the notification. May be set. For example, in situation 4M in FIG. 15, the value of the status flag is corrected from FALSE to TRUE in step S407a.

After execution of step S407a, the processing in FIG. 19 proceeds to step S403.

According to the environment variable update process as described above in the fourth embodiment, for each n where 1 ≦ n ≦ N, when at least one of the status flag and the update flag is TRUE, the updating unit 135 is nth in step S405. Request that all OBP environment variables be sent to the guest domain. Conversely, when both the status flag and the update flag have a value of FALSE, the update unit 135 does not request that the value of all OBP environment variables be sent to the nth guest domain, and the OBP of the nth guest domain. There is also no request to the SP 170 to send the value of the environment variable.

Here, it supplements about step S402 and S402a.
When the value of the update flag is TRUE, the latest value of each OBP environment variable of the nth guest domain is not stored in the environment variable table 200-n of the environment variable storage unit 131. Therefore, in this case, the update unit 135 acquires the latest value of the OBP environment variable from the nth guest domain or SP 170, and updates the environment variable table 200-n.

Conversely, when the value of the update flag is FALSE, the latest value of each OBP environment variable of the nth guest domain is stored in the environment variable table 200-n of the environment variable storage unit 131. Therefore, in this case, it is not necessary to update the environment variable table 200-n.

On the other hand, if the OBP is running on the nth guest domain, the latest value of the OBP environment variable can be acquired from the OBP. The value obtained from the OBP is guaranteed to be up-to-date.

In the fourth embodiment, even if it is not necessary to update the environment variable table 200-n, if it is expected that the latest value can be obtained from the OBP, the value of the OBP environment variable from the OBP is updated in step S405. Acquisition is attempted. That is, in the fourth embodiment, even if the value of the update flag is FALSE, step S405 is executed when the value of the status flag is TRUE.

It may seem useless to execute step S405 when the value of the update flag is FALSE, but it is not useless. This is because the execution of step S405 provides an opportunity to correct the value of the status flag.

That is, if the value of the status flag is TRUE and the value of TRUE does not correctly reflect the status of the OBP of the nth guest domain, the value of the status flag is corrected in step S408. For example, in the situation 4I of FIG. 15, the value of the status flag is corrected from TRUE to FALSE in step S408.

If the value of the update flag is TRUE, step S405 is executed regardless of the value of the status flag. Therefore, even when the value of the update flag is TRUE, the value of the state flag is rewritten so as to correctly reflect the state of the OBP of the nth guest domain in step S407a or S408.

The fourth embodiment described above is suitable when the storage capacity of the environment variable storage unit 171 is large. This is because the value of the OBP environment variable is not discarded in the environment variable storage unit 171 in the fourth embodiment.

The present invention is not limited to the above embodiment. For example, the fourth embodiment may be modified so as not to use the state list 220 as in the third embodiment. In this case, the flowchart of FIG. 19 may be specifically modified as follows.

The update unit 135 executes step S402a (after skipping step S402) after step S401.
When the value of the update flag is FALSE, the update unit 135 executes step S403 after step S402a.
When the value of the update flag is TRUE, the update unit 135 executes step S405 after step S402a.

Even if the number N of guest domains is large, the number of guest domains that update the OBP environment variable while the control domain 130 is not operating is not so large. Therefore, a modification of the fourth embodiment that does not use the state list 220 as described above is also possible.

In other words, use of at least one of the state list 220 and the update list 230 can reduce useless waiting time even if there are many guest domains. Therefore, in the embodiment in which the SP 170 does not keep the latest value of the OBP environment variable as in the fourth embodiment but appropriately discards the value as in step S203 in the second embodiment, the state list 220 Instead, the update list 230 may be used. Specifically, the second embodiment may be modified as follows.

Steps S101 and S114 in FIG. 8 are omitted.
Steps S303 and S306 to S308 in FIG. 10 are also omitted.
Of the processing in step S305 in FIG. 10, deletion of entries from the status list 220 is also omitted.
Of the processes in steps S309 and S311 in FIG. 10, the update of the status flag is also omitted.
SP 170 operates according to the flowchart of FIG. 18 instead of FIG.
As the environment variable update process in step S301 of FIG. 10, the process of the modified example of the fourth embodiment (that is, the process modified from the flowchart of FIG. 19 as described above) is executed.

In the various embodiments and modifications described so far, the execution order of the steps may be changed as long as no contradiction occurs. For example, the order of steps S303 and S304 in FIG. 10 may be reversed, step S206 in FIG. 18 may be executed before step S204 or between steps S204 and S205, or steps S401a and S401 in FIG. The order may be reversed. The interchangeable steps may be executed in parallel.

In the second to fourth embodiments, the OBP is given as a specific example of the boot loader 1, but the type of the boot loader 1 is arbitrary depending on the embodiment. Specific implementation of communication via the hypervisor is also arbitrary depending on the embodiment.

Note that communication between virtual machines (that is, between domains) via the hypervisor can be any of the following communication physically. However, in any case, it is clear that the above description regarding each embodiment is valid.

Interthread communication or interprocess communication within one physical processor core.
-Communication between different cores in one physical processor.
Communication between different physical processors (for example, communication between the CPUs 22a and 22b via the SC 28 in FIG. 3).

DESCRIPTION OF SYMBOLS 1 Boot loader of 1st virtual machine 2 2nd virtual machine 3 2nd processor 4A- 4R Status 10, 100, 300 Computer 20, 30 System board 21a-21d, 31a-31d, 53, 63 Memory 22a-22b, 32a-32b, 51, 61 CPU
23a-23c, 33a-33c HDD
24, 34 Service processor interface (SP I / F)
25, 35, 55, 65 LAN port 26, 36 SAS port 27, 37, 54, 64 USB port 28, 38 System controller (SC)
40 Crossbar switch (XB)
50, 60, 170, 380 Service processor (SP)
52, 62 Non-volatile memory 56, 66 Serial port 71 Input / output device 72 Storage medium 73 Drive device 74 Network 75 Terminal 76 Program provider 110, 120, 310, 320 Partition 130, 330, 350 Control domain 131, 171, 331, 381 Environment variable storage unit 132 OBP state management unit 133, 143, 173, 332, 343, 383 Communication unit 134, 333 Setting unit 135, 334 Update unit 140, 150, 340, 360 Guest domain 141, 341 OS activation unit 142, 342 Environment variable management unit 160, 370 Hypervisor 172, 382 Storage control unit 173, 382 Receiving unit 200-1 to 200-N, 210-1 to 210-N Environment variable table 220 Status list 230 New list

Claims (10)

1. Of the one or more first processors for executing the hypervisor and the first and second virtual machines operating on the hypervisor, a boot loader for loading an operating system into the first virtual machine Is executed on the first virtual machine at a first time point, and the second virtual machine is requested to save the value of the environment variable of the boot loader in the first storage device. 1 request,
   If a response to the first request is not returned within a predetermined time, the processor executing the boot loader executes neither the hypervisor nor the first and second virtual machines. Issuing a second request to the processor of the second request for saving the value of the environment variable in a second storage device via the hypervisor;
   The second processor storing the value of the environment variable in the second storage device in response to the second request;
   When the second virtual machine is restarted at a second time after the second processor stores the value of the environment variable in the second storage device, the one or more first Among the processors, the processor that has started the execution of the second virtual machine in response to the restart of the second virtual machine at the second time point receives the environment variable from the second storage device or the boot loader. The value of the environmental variable is acquired, and the acquired value of the environmental variable is stored in the first storage device.
2. The processor that has started execution of the second virtual machine in response to the restart of the second virtual machine at the second time point,
   A third request is issued through the hypervisor to request the second processor to send the value of the environment variable stored in the second storage device, and the value of the environment variable is Obtaining the value of the environment variable by receiving from the second processor via the hypervisor, or
   A fourth request for sending the value of the environment variable to the boot loader is issued through the hypervisor, and the processor executing the boot loader among the one or more first processors The environment variable storage method according to claim 1, wherein the value of the environment variable is acquired by receiving the value of the environment variable in response to a fourth request.
3. In the case where the value of the environment variable is stored in the second storage device in response to the second request, the second variable in response to the restart of the second virtual machine at the second time point. The processor that has started execution of the virtual machine 2
   Issue the fourth request;
   3. The environment according to claim 2, wherein in response to the fourth request, the third request is issued if the value of the environment variable is not returned within a second determined time. Variable storage method.
4. In the case where the value of the environment variable is stored in the second storage device in response to the second request, the second variable in response to the restart of the second virtual machine at the second time point. The processor that has started execution of the virtual machine 2
   Determining whether the boot loader is running on the first virtual machine;
   The environment variable storage method according to claim 2 or 3, wherein the fourth request is issued when it is determined that the boot loader is being executed on the first virtual machine.
5. When the second processor receives the second request, it records that it has received the second request;
   The processor that has started execution of the second virtual machine in response to the restart of the second virtual machine at the second time point indicates that the boot loader is not executing on the first virtual machine. If you decide,
   Whether the second processor has received the second request based on an inquiry to the second processor via the hypervisor as to whether the second processor has received the second request. Recognize whether or not
   The environment variable storage according to claim 4, wherein when the second processor recognizes that the second request has been received, at least one of the third request and the fourth request is issued. Method.
6. Each of the one or more first processors includes:
   When starting execution of the boot loader, issue a start notification to notify the second virtual machine of the start of execution of the boot loader,
   When ending execution of the boot loader, issue an end notification for notifying the second virtual machine of the end of execution of the boot loader,
   When the start notification is received during the execution of the second virtual machine, the status information indicating whether the boot loader is being executed on the first virtual machine is updated according to the start notification,
   If the end notification is received during execution of the second virtual machine, the status information is updated according to the end notification,
   When the execution of the second virtual machine is started in response to the restart of the second virtual machine at the second time point, the first virtual machine is referred to by referring to the state information 6. The environment variable storage method according to claim 4, wherein whether or not the boot loader is being executed is determined.
7. When each of the one or more first processors receives the first request during execution of the second virtual machine, the value of the environment variable is associated with first time information. In the first storage device,
   The second processor is
   When storing the value of the environment variable in the second storage device in response to the second request, the value of the environment variable is associated with second time information;
   When the third request is received, the second time information is also sent together with the value of the environment variable,
   The processor that has started execution of the second virtual machine in response to the restart of the second virtual machine at the second time point issues the third request from the second processor. When receiving the value of the environment variable and the second time information via the hypervisor,
   Comparing the first time indicated by the first time information stored in the first storage device with the second time indicated by the received second time information;
   If the second time is after the first time, the value of the environment variable received from the second processor via the hypervisor is stored in the first storage device. The environment variable storage method according to any one of claims 2 to 6.
8. The value of the environment variable of the boot loader for loading the operating system to the first virtual machine operating on the hypervisor is stored according to the control executed on the second virtual machine operating on the hypervisor. First storage means;
   Control means that is accessible from the first virtual machine and the second virtual machine via the hypervisor, and operates independently of the hypervisor;
   Second storage means for storing the value of the environment variable in accordance with control by the control means;
   A first request for requesting the second virtual machine to store the value of the environment variable in the first storage means is issued from the boot loader via the hypervisor, and a predetermined time A response to the first request is not returned within a second request from the boot loader to request that the control means store the value of the environment variable in the second storage means. Requesting means issued via
   In response to the second request, a third request for the control means to send the value of the environment variable stored in the second storage means is sent from the second virtual machine to the hypervisor. Updating means for receiving the value of the environment variable issued in response to the third request and storing the received value of the environment variable in the first storage means;
   In response to a fourth request from the boot loader to set the value of the environment variable in the boot loader, setting means for sending the value of the environment variable stored in the first storage means to the boot loader. Information processing apparatus provided.
9. One or more first processors for executing a hypervisor and first and second virtual machines running on the hypervisor;
   A second processor that does not execute either the hypervisor or the first and second virtual machines;
   A first storage unit connected to the one or more first processors;
   A second storage unit connected to the second processor,
   Among the one or more first processors, a processor executing a boot loader for loading an operating system on the first virtual machine on the first virtual machine at a first time point.
   Issuing a first request to the second virtual machine to save the value of the environment variable of the boot loader in the first storage unit,
   If a response to the first request is not returned within a predetermined time, a second request is made to ask the second processor to save the value of the environment variable in the second storage unit. Issued through the hypervisor,
   In response to the second request, the second processor stores the value of the environment variable in the second storage unit;
   When the second virtual machine is restarted at a second time after the second processor stores the value of the environment variable in the second storage unit, the one or more first Among the processors, a processor that has started execution of the second virtual machine in response to the restart of the second virtual machine at the second time point,
   Obtaining the value of the environment variable from the second storage unit or the boot loader;
   The information processing apparatus, wherein the acquired value of the environment variable is stored in the first storage unit.
10. Of the first and second virtual machines operating on a hypervisor, a program for causing a first processor that executes the second virtual machine to execute environment variable management processing, the environment variable management Processing
    Whether or not a boot loader for loading an operating system to the first virtual machine is being executed on the first virtual machine at the start of the execution of the environment variable management process by the first processor Judging
    When it is determined that the boot loader is being executed at the start time, the boot loader is requested to send the value of the environment variable of the boot loader via the hypervisor.
    If the value of the environment variable is received from the boot loader, the value of the environment variable received from the boot loader is stored in a first storage device, and the boot loader is determined to be executing at the start time; and If the value of the environment variable is not received from the boot loader within a determined time, a second processor that does not execute either the hypervisor or the first and second virtual machines Requesting via the hypervisor to send the value of the environment variable if the value of the environment variable is stored in the storage device of 2;
    When the value of the environment variable is received from the second processor, the value of the environment variable received from the second processor is stored in the first storage device, and on the first virtual machine In response to a request issued from the boot loader via the hypervisor every time the execution of the boot loader is started, the value of the environment variable stored in the first storage device is changed via the hypervisor. And returning to the boot loader.

Images