WO2014045453A1 - Procédé de mémorisation des variables d'environnement, dispositif et programme de traitement d'informations - Google Patents

Procédé de mémorisation des variables d'environnement, dispositif et programme de traitement d'informations Download PDF

Info

Publication number
WO2014045453A1
WO2014045453A1 PCT/JP2012/074448 JP2012074448W WO2014045453A1 WO 2014045453 A1 WO2014045453 A1 WO 2014045453A1 JP 2012074448 W JP2012074448 W JP 2012074448W WO 2014045453 A1 WO2014045453 A1 WO 2014045453A1
Authority
WO
WIPO (PCT)
Prior art keywords
environment variable
value
virtual machine
request
processor
Prior art date
Application number
PCT/JP2012/074448
Other languages
English (en)
Japanese (ja)
Inventor
左尾将隆
嶋谷恵治
遠藤新
Original Assignee
富士通株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 富士通株式会社 filed Critical 富士通株式会社
Priority to PCT/JP2012/074448 priority Critical patent/WO2014045453A1/fr
Publication of WO2014045453A1 publication Critical patent/WO2014045453A1/fr

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects

Definitions

  • the present invention relates to a technique for saving the value of an environment variable.
  • 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.
  • configuration file configuration file
  • environment variables Various techniques for managing various information while maintaining consistency have also been studied.
  • 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.
  • OS Operating System
  • 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.
  • the system monitoring device 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.
  • 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.
  • the extended BIOS Basic Input Input Output System
  • 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.
  • the specific virtual machine does not always operate normally. There is also a possibility that a failure occurs in the specific virtual machine.
  • the value of the environment variable of the boot loader may not be properly saved due to a failure of a specific virtual machine.
  • 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”.
  • an environment variable storage method is provided.
  • 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”.
  • 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.
  • the processor 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.
  • 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.
  • the OS of other virtual machines can be started. It won't interfere.
  • OBP OpenBoot
  • FIGS. 1 to 4 also apply to the second to third embodiments
  • FIGS. 3 to 4 also apply to the fourth embodiment.
  • 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.
  • a certain type of computer to which virtualization by the hypervisor is applied has two types of processors having different uses.
  • a certain type of computer has the following two types of processors.
  • One or more processors for the sake of convenience
  • processors 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).
  • a certain type of computer has one or more CPUs (Central Processing Unit) and a module called “service processor”.
  • 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).
  • SPs monitor voltage and temperature.
  • the SP may have a function of forcibly restarting the entire computer.
  • the one or more CPUs may be the one or more first processors, and the CPU in the SP may be the second processor.
  • 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”.
  • BIOS 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.
  • BIOS 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.
  • 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.
  • the first virtual machine is executed by any one or more of the first processors
  • the second virtual machine is also executed by any one or more of the first processors.
  • 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.
  • FIG. 1 also shows a period during which the second processor 3 operates.
  • FIG. 1 shows five situations 4A to 4E.
  • 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 is expressed as “T_end”.
  • a time when the second virtual machine 2 stops operating for some reason is expressed as “T_down”.
  • Time at which the second virtual machine 2 is restarted is expressed (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)
  • FIG. 1 assumes the following description of FIG. 1 assumes the following.
  • At least first to third environment variables are defined in the boot loader 1.
  • the values of the first to third environment variables are “A1”, “B1”, and “C1”, respectively.
  • any one or more of the first to third environment variables may be updated.
  • the value of the first environment variable is updated to “A2” before the time T_down.
  • 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.
  • 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.
  • the boot loader 1 may issue a request for updating the value of the second environment variable to “B2”.
  • 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.
  • 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.
  • 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.
  • the request and the response may be sent via a hypervisor.
  • 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.
  • the process for reflecting the latest value of the environment variable in the first storage device is performed as follows.
  • the second virtual machine 2 is restarted at time T_boot after the OS is started from the boot loader 1.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the second storage device that is accessible from the second processor 3.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the boot loader 1 is not already operating.
  • the environment variable is not updated by the boot loader 1 while the second virtual machine 2 is not operating.
  • 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.
  • the boot loader 1 may happen to be activated while the second virtual machine 2 is not operating.
  • 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.
  • the second virtual machine 2 since the second virtual machine 2 is not operating, a response to the request cannot be obtained.
  • 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.
  • 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.
  • 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.
  • 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
  • the boot loader 1 is started before the second virtual machine 2 is restarted.
  • 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.
  • the environment variable is updated in response to a request from the boot loader 1 from time T_down to time T_boot. None 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.
  • the boot loader 1 is started at time T_start after the second virtual machine 2 is restarted.
  • 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.
  • 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.
  • 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.
  • any situation 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.
  • the OS of the first virtual machine may be unable to be booted next time.
  • the environment variable Is reflected in the first storage device 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.
  • FIG. 2 is a diagram for explaining that the problem that may occur in the comparative example is solved.
  • the situation 4F according to the comparative example is compared with the situations 4G and 4H according to the first embodiment.
  • the second processor 3 is not used for saving environment variables of the boot loader 1.
  • 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”.
  • the first virtual machine may be restarted for some reason such as the occurrence of an error.
  • 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.
  • 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.
  • the value of the first environment variable is normally updated from “A3” to “A4”.
  • the processor executing the boot loader 1 stores the value of the second environment variable “B4” in the second virtual machine 2.
  • the value “B4” is not stored anywhere.
  • 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”.
  • the value “B4” is not stored in the first storage device, it volatilizes after the OS is started.
  • the boot loader 1 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.
  • 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.
  • 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.
  • 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”.
  • the OS 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.
  • 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.
  • 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.
  • 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”.
  • 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.
  • 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.
  • 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.
  • 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”.
  • 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.
  • the crossbar switch is abbreviated as “XB”.
  • the computer 10 includes an SP 50 connected to the system board 20 and an SP 60 connected to the system board 30.
  • an SP 50 connected to the system board 20
  • an SP 60 connected to the system board 30.
  • 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.
  • 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.
  • system board 20 includes a system controller (hereinafter abbreviated as “SC”) 28 connected to the XB 40.
  • 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).
  • 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.
  • the system board 20 has two CPUs 22a to 22b, but the number of CPUs is arbitrary.
  • 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).
  • 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.
  • 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
  • the MAC chip is a circuit that performs processing of a MAC (Media Access Control) sublayer.
  • 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.
  • 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).
  • one or both of the external HDD and the external SSD may be connected to the computer 10 via the USB port 27.
  • 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.
  • the system board 20 may have a host bus adapter for connecting the computer 10 to a Fiber Channel-based SAN (Storage Area Network).
  • a Fiber Channel-based SAN Storage Area Network
  • 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.
  • the system board 30 includes memories 31a to 31d, CPUs 32a to 32b, and HDDs 33a to 33c.
  • 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.
  • the configurations of the system boards 20 and 30 may be different.
  • the number of CPUs and memories may be different between the system boards 20 and 30.
  • each of the system boards 20 and 30 includes one or more HDDs.
  • 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.
  • each of the system boards 20 and 30 includes hardware elements (for example, a LAN port) for connecting the computer 10 and other devices.
  • hardware elements for connection between the computer 10 and other devices may be shared between the system boards 20 and 30.
  • 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.
  • the SP 50 may monitor voltage and temperature.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the network 74 may be a LAN, a WAN (Wide Area Network), the Internet, or a combination thereof.
  • 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.
  • 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.
  • a program for causing the computer 10 to execute the method described with reference to FIG. 1 may be preinstalled in the computer 10.
  • 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).
  • 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.
  • 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.
  • these programs may be provided by the program provider 76.
  • 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).
  • 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.
  • the CPU 51 as the second processor loads the program into the memory 53 and executes the program.
  • the CPU 61 as the second processor also loads the program into the memory 63 and executes the program.
  • the method described with reference to FIG. 1 is realized by several CPUs that execute programs.
  • 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.
  • the computer 100 includes two partitions 110 and 120.
  • Each partition includes one control domain and one or more guest domains.
  • the partition 110 includes a control domain 130, a guest domain 140, and a guest domain 150.
  • 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.
  • OBP OpenBoot PROM; PROM is Programmable Read-Only Memory
  • 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.
  • environment variables used in OBP are referred to as “OBP environment variables”.
  • hypervisor 160 In FIG. 5, only one hypervisor 160 is shown. However, a separate hypervisor 160 may be executed for each partition.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • ACK acknowledgenowledgment
  • 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”.
  • 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.
  • 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”.
  • 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”.
  • 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.
  • the request unit issues a second request from the boot loader 1 via the hypervisor.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • FIG. 5 the computer 100 of FIG. 5 may be realized by the computer 10 of FIG.
  • FIG. 3 One system board in FIG. 3 corresponds to one partition in FIG.
  • the system board 20 may correspond to the partition 110
  • the system board 30 may correspond to the partition 120.
  • 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.
  • 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.
  • 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.
  • 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. .
  • HDDs 23a to 23c physical nonvolatile storage devices
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • control domain 130 and the guest domain 140 in FIG. 5 are realized by the hardware elements in FIG.
  • the environment variable storage unit 131 is realized by a partial area of the HDDs 23a to 23c in the system board 20.
  • 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.
  • an area allocated to the control domain 130 in the memories 21a to 21d is also used.
  • 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.
  • 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.
  • the SP 170 in FIG. 5 may specifically be the SP 50 in FIG.
  • 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.
  • 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.
  • the number of SPs may be one, or two or more.
  • the SP 60 may be omitted from the computer 10 of FIG.
  • the SP I / F 34 of the system board 30 is connected to the SP 50.
  • SP50 corresponds to SP170 in FIG.
  • 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.
  • the SP 50 in FIG. 3 may be used as the SP 170 corresponding to the partition 110
  • the SP 60 in FIG. 3 may be used as the SP 170 corresponding to the partition 120.
  • 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.
  • 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.
  • 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.
  • the example of FIG. 6 shows the following.
  • 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.
  • an environment variable named “ENV_VAR_2” is used in the first guest domain OBP.
  • 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.
  • an environment variable named “ENV_VAR — 3” is used in the first guest domain OBP.
  • 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.
  • an environment variable named “ENV_VAR_4” is used in the OBP of the first guest domain.
  • 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.
  • 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.
  • 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).
  • 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.
  • FIG. 8 is an operational flowchart of OBP in the guest domain.
  • 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.
  • 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.
  • 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.
  • step S103 the environment variable management unit 142 waits in step S103 for any of the following events to occur.
  • 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
  • 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.
  • step S105 the environment variable management unit 142 waits for a predetermined waiting time.
  • 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.
  • step 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.
  • step S106 the environment variable management unit 142 sets each OBP environment variable to the latest received value.
  • the guest domain 140 is the nth guest domain.
  • 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.
  • 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.
  • 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.
  • 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”.
  • the guest domain 140 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.
  • 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).
  • 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”.
  • step S114 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.
  • step S108 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.
  • 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.
  • step S108 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.
  • 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.
  • the third environment variable “C1” to “C2” in each of the situations 4B, 4D, and 4E is also updated based on the save instruction.
  • step S108 When another type of event occurs, the process in FIG. 8 proceeds from step S108 to step S113.
  • 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.
  • 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.
  • 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.
  • step S111 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.
  • step S111 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.
  • step S112 the environment variable management unit 142 issues a request to the SP 170 in accordance with the given storage instruction.
  • 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.
  • 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.
  • 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.
  • steps S108 to S113 are executed as long as the condition for starting the OS is not yet established.
  • 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.
  • the environment variable management unit 142 notifies the control domain 130 that the OBP is finished.
  • 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.
  • the SP 170 starts the processing of FIG.
  • step S201 the SP 170 waits for any of the following events to occur.
  • step S202 When the former event occurs, the process in FIG. 9 proceeds to step S202.
  • 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.
  • 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.
  • 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).
  • 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.
  • step S202 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.
  • 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.
  • step S203 is a process for avoiding wasteful use of the storage area of the environment variable storage unit 171.
  • step S203 may be omitted.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • step S205 the storage control unit 172 transmits ACK to the guest domain 140 via the communication unit 173 and the hypervisor 160.
  • the process of FIG. 9 returns to step S201.
  • 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.
  • 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.
  • 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 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.
  • addition and deletion of guest domains are performed via a user interface (for example, a command line interface) provided by the control domain 130.
  • 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.
  • step S302 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.
  • 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.
  • domain off state the state in which the OBP is operating.
  • OBP operating state the state in which the OBP is operating
  • OS operating state the OS is started from the OBP
  • OS operating state a state where the OS is operating
  • 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.
  • 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.
  • 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.
  • 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.
  • state transition notifications sent in steps S101 and S114 in FIG.
  • the processing in FIG. 10 proceeds from step S302 to step S306.
  • 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.
  • the processing in FIG. 10 proceeds from step S302 to step S309.
  • 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.
  • the processing in FIG. 10 proceeds from step S302 to step S311.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • step S305 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.
  • step S306 the OBP state management unit 132 that has received the state transition notification determines the type of state transition notification.
  • the processing in FIG. 10 proceeds from step S306 to step S307.
  • the processing in FIG. 10 proceeds from step S306 to step S308.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • step S302 the process of FIG. 10 returns to step S302.
  • the process in FIG. 8 returns from step S111 to step S107 as described above.
  • 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.
  • 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.
  • 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.
  • 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.
  • step S311 After sending the OBP environment variable and updating the status flag, the processing in FIG. 10 returns from step S311 to step S302.
  • step S301 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).
  • the update unit 135 initializes the index variable n to 1.
  • 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.
  • step S403 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.
  • 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.
  • step S402 means the following.
  • 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.
  • 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.
  • 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.
  • the guest domain 140 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. .
  • 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.
  • 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.
  • 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.
  • step S114 in FIG. 8 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.
  • the value of the status flag is FALSE although the OBP of the guest domain 140 is actually operating.
  • the value of the status flag is different from the actual status. The reason is as follows.
  • 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.
  • the value of the status flag of the guest domain 140 is FALSE. It 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. .
  • step S402 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.
  • step S405 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.
  • 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.
  • the update unit 135 of the control domain 130 waits in step S406 for any of the following events to occur.
  • step S406 the processing of FIGS. 11 to 12 proceeds from step S406 to step S407.
  • step S408 the processing in FIGS. 11 to 12 proceeds from step S406 to step S408.
  • 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.
  • 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.
  • 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.
  • 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.
  • the value of the status flag of the nth guest domain is rewritten from TRUE to FALSE in step S408.
  • the state flag correctly reflects the state of the nth guest domain.
  • 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.
  • 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.
  • SP 170 is operating normally when the request is sent”.
  • 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.
  • step S410 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.
  • the environment variable storage unit 171 of SP 170 stores the values of J OBP environment variables of the nth guest domain.
  • 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.
  • J ⁇ 2 may be possible.
  • step S411 in FIG. 12 the update unit 135 initializes the index variable j to 1.
  • step S412 the update unit 135 determines whether j> J. When j> J, one of the following two conditions is satisfied.
  • 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).
  • step S413 the updating unit 135 compares the following two times.
  • 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.
  • step S414 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.
  • 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
  • SP170 (more specifically, the storage control unit). 172) corresponds to the second processor 3 of FIGS.
  • 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.
  • 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.
  • 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.
  • step S406 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.
  • step S414 or S415 the processing in FIGS. 11 to 12 proceeds to step S414 or S415 in accordance with the comparison result in step S413.
  • 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.
  • 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”.
  • 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.
  • step S416 After the entry update as described above, the processing of FIGS. 11 to 12 proceeds to step S416.
  • 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.
  • 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.
  • 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.
  • step S406 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.
  • 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.
  • FIGS. 1 to 4 also applies to the third embodiment, and therefore FIGS. 1 to 4 are also referred to as appropriate below.
  • 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.
  • 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.
  • 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.
  • the computer 300 includes two partitions 310 and 320.
  • Each partition includes one control domain and one guest domain.
  • the partition 310 includes a control domain 330 and a guest domain 340
  • 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.
  • 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.
  • 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 communication unit 332 is the same as the communication unit 133
  • 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.
  • the control domain 350 is similar to the control domain 330, and the guest domain 360 is similar to the guest domain 340.
  • 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 storage control unit 382 is the same as the storage control unit 172
  • the communication unit 383 is the same as the communication unit 173.
  • 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.
  • the system board 20 may correspond to the partition 310
  • the system board 30 may correspond to the partition 320.
  • FIG. 14 is a flowchart of the environment variable update process in the third embodiment.
  • the environment variable update process is executed in the control domain 330 .
  • 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.
  • 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.
  • the update unit 334 of the control domain 330 waits in step S502 for any of the following events to occur.
  • step S502 the processing in FIG. 14 proceeds from step S502 to step S503.
  • 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.
  • 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.
  • 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.
  • 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.
  • SP 380 is operating normally at the time when the request is sent”.
  • 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.
  • step S505 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.
  • 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.
  • 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.
  • J ⁇ 2 may be possible.
  • step S506 the update unit 334 initializes the index variable j to 1.
  • step S507 the update unit 334 determines whether j> J. When j> J, one of the following two conditions is satisfied.
  • 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).
  • step S508 the update unit 334 compares the following two times.
  • 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.
  • step S509 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.
  • 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.
  • 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”.
  • 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.
  • step S511 After the entry update as described above, the processing in FIG. 14 proceeds to step S511.
  • 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.
  • step S511 the update unit 334 increments the index variable j by 1. Then, the process of FIG. 14 returns to step S507.
  • 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.
  • 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.
  • the fourth embodiment will be described with reference to FIGS.
  • 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.
  • the boot loader 1 is specifically the OBP of the guest domain 140
  • the second virtual machine 2 is specifically the control domain 130
  • the second processor 3 is specifically SP 170 (especially storage Controller 172).
  • 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.
  • 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).
  • inequality (L) inequality (A) to (E) are shown again for reference.
  • 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).
  • 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).
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the value of the third environment variable may be updated to “C2” after time T_boot.
  • the same processing as that performed when the first environment variable is updated from “A1” to “A2” is performed.
  • 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.
  • 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.
  • the boot loader 1 is not already operating.
  • 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.
  • the boot loader 1 may happen to be activated while the second virtual machine 2 is not operating.
  • 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.
  • the second virtual machine 2 since the second virtual machine 2 is not operating, a response to the request cannot be obtained.
  • 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.
  • 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.
  • 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.
  • T_end ⁇ T_boot 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.
  • the execution of the boot loader 1 ends before the time T_boot.
  • the execution of the boot loader 1 may continue until after the time T_boot.
  • 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”).
  • 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.
  • the update of the environment variable performed while the second virtual machine 2 was not operating is reflected in the first storage device.
  • the value of the third environment variable may be updated to “C2”.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the situation 4O according to the comparative example is compared with the situation 4P according to the fourth embodiment
  • 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.
  • 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.
  • 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.
  • 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.
  • situations 4O and 4P are examples of situations in which the inequality (A-2), which will be re-described below, holds.
  • situations 4Q and 4R are examples of situations where the following inequality (D-2) holds.
  • 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.
  • the first processor that executes the boot loader 1 uses a fixed default value of each environment variable.
  • the default values of the first to third environment variables are represented as “A0”, “B0”, and “C0”, respectively.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the value “B4” is not stored in the first storage device.
  • the values “A3”, “B3”, and “C4” are returned to the first processor that is executing the boot loader 1.
  • the boot loader 1 may fail to start at a certain time after the time T_next.
  • 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.
  • the second virtual machine 2 is started at time T_boot.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • each entry includes a domain number and an update flag.
  • the value of the environment variable is stored in the environment variable storage unit 171 (specifically, the environment variable table 210-n).
  • the value of the update flag is TRUE.
  • 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.
  • 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.
  • 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.
  • 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.
  • the update unit 135 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.
  • 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.
  • step S203 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.
  • step S206 when the SP 170 receives the value of the OBP environment variable from the guest domain 140 will be described.
  • 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.
  • 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.
  • the SP 170 receives the value “A2” from the control domain 130.
  • 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.
  • 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.
  • the processing in FIG. 18 proceeds from step S201 to step S207.
  • 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.
  • 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.
  • 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.
  • the SP 170 may receive an inquiry from the control domain 130 for each update flag in the update list 230.
  • the processing in FIG. 18 proceeds from step S201 to step S209.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • step S401 the update unit 135 initializes the index variable n to 1.
  • 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.
  • 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.
  • step S403 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.
  • 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.
  • 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.
  • 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.
  • the values “A2”, “B2”, and “C1” are stored in the environment variable storage unit 131 in step S407a as described above.
  • the values “A1”, “B2”, and “C1” are stored in the environment variable storage unit 131 in step S407a as described above.
  • the OBP state management unit 132 sets the state flag of the nth guest domain in the state list 220 to TRUE.
  • 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.
  • the value of the status flag is corrected from FALSE to TRUE in step S407a.
  • step S407a After execution of step S407a, the processing in FIG. 19 proceeds to step S403.
  • the updating unit 135 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.
  • step S402 and S402a it supplements about step S402 and S402a.
  • 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.
  • 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.
  • 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.
  • step S405. 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.
  • step S405 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.
  • 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.
  • 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.
  • the fourth embodiment may be modified so as not to use the state list 220 as in the third embodiment.
  • 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.
  • the update unit 135 executes step S403 after step S402a.
  • the update unit 135 executes step S405 after step S402a.
  • 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.
  • 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.
  • deletion of entries from the status list 220 is also omitted.
  • the update of the status flag is also omitted.
  • SP 170 operates according to the flowchart of FIG. 18 instead of FIG.
  • the process of the modified example of the fourth embodiment that is, the process modified from the flowchart of FIG. 19 as described above
  • the execution order of the steps may be changed as long as no contradiction occurs.
  • 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.
  • 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.
  • Interthread communication or interprocess communication within one physical processor core 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).

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Stored Programmes (AREA)

Abstract

Un ou plusieurs premiers ordinateurs exécutent un hyperviseur et des première et seconde machines virtuelles fonctionnant sur ledit hyperviseur. Un second ordinateur n'exécute ni l'hyperviseur, ni les première et seconde machines virtuelles. Parmi les premiers ordinateurs, l'ordinateur exécutant un chargeur d'amorçage conçu pour charger un système d'exploitation sur la première machine virtuelle demande à la seconde machine virtuelle de sauvegarder la valeur des variables d'environnement du chargeur d'amorçage sur un premier dispositif de mémoire. En l'absence de réponse, l'ordinateur exécutant le chargeur d'amorçage demande au second ordinateur de sauvegarder la valeur des variables d'environnement sur un second dispositif de mémoire. Quand la seconde machine virtuelle se réamorce après que le second ordinateur a sauvegardé la valeur des variables d'environnement sur le second dispositif de mémoire, l'ordinateur, parmi les premiers ordinateurs, qui a commencé à exécuter la seconde machine virtuelle en réponse à son réamorçage obtient la valeur des variables d'environnement à partir du second dispositif de mémoire ou du chargeur d'amorçage et sauvegarde sur le premier dispositif de mémoire la valeur acquise des variables d'environnement.
PCT/JP2012/074448 2012-09-24 2012-09-24 Procédé de mémorisation des variables d'environnement, dispositif et programme de traitement d'informations WO2014045453A1 (fr)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/074448 WO2014045453A1 (fr) 2012-09-24 2012-09-24 Procédé de mémorisation des variables d'environnement, dispositif et programme de traitement d'informations

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/074448 WO2014045453A1 (fr) 2012-09-24 2012-09-24 Procédé de mémorisation des variables d'environnement, dispositif et programme de traitement d'informations

Publications (1)

Publication Number Publication Date
WO2014045453A1 true WO2014045453A1 (fr) 2014-03-27

Family

ID=50340800

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/074448 WO2014045453A1 (fr) 2012-09-24 2012-09-24 Procédé de mémorisation des variables d'environnement, dispositif et programme de traitement d'informations

Country Status (1)

Country Link
WO (1) WO2014045453A1 (fr)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001230782A (ja) * 2000-02-16 2001-08-24 Nec Corp ネットワーク環境設定の自動更新方法及びシステム並びに記録媒体
WO2007088575A1 (fr) * 2006-01-31 2007-08-09 Fujitsu Limited Procede de controle de dispositif de surveillance de systeme, programme et systeme informatique
WO2008126145A1 (fr) * 2007-03-30 2008-10-23 Fujitsu Limited Procédé de définition pour un adaptateur réseau virtuel dans un environnement de système d'exploitation virtuel d'un système informatique et système informatique
JP2009054035A (ja) * 2007-08-28 2009-03-12 Nec Computertechno Ltd サーバシステム、パーティション起動制御装置、パーティション起動制御方法
WO2009093333A1 (fr) * 2008-01-25 2009-07-30 Fujitsu Limited Dispositif de traitement d'informations, système de traitement d'informations, programme informatique, et procédé de traitement d'informations

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001230782A (ja) * 2000-02-16 2001-08-24 Nec Corp ネットワーク環境設定の自動更新方法及びシステム並びに記録媒体
WO2007088575A1 (fr) * 2006-01-31 2007-08-09 Fujitsu Limited Procede de controle de dispositif de surveillance de systeme, programme et systeme informatique
WO2008126145A1 (fr) * 2007-03-30 2008-10-23 Fujitsu Limited Procédé de définition pour un adaptateur réseau virtuel dans un environnement de système d'exploitation virtuel d'un système informatique et système informatique
JP2009054035A (ja) * 2007-08-28 2009-03-12 Nec Computertechno Ltd サーバシステム、パーティション起動制御装置、パーティション起動制御方法
WO2009093333A1 (fr) * 2008-01-25 2009-07-30 Fujitsu Limited Dispositif de traitement d'informations, système de traitement d'informations, programme informatique, et procédé de traitement d'informations

Similar Documents

Publication Publication Date Title
JP4842210B2 (ja) フェイルオーバ方法、計算機システム、管理サーバ及び予備サーバの設定方法
JP4467624B2 (ja) ソフトウェアアップデート管理プログラム、ソフトウェアアップデート管理装置、およびソフトウェアアップデート管理方法
JP5113700B2 (ja) ファームウェア更新装置及び方法
US10303459B2 (en) Electronic system with update control mechanism and method of operation thereof
US8612803B2 (en) Information processing apparatus and driver execution control method
US8788636B2 (en) Boot controlling method of managed computer
WO2013103023A1 (fr) Dispositif de traitement d'informations, procédé de traitement d'informations et programme informatique
US8219851B2 (en) System RAS protection for UMA style memory
JP2019016135A (ja) 情報処理システム、情報処理システムの制御プログラム及び情報処理システムの制御方法
JP2016508647A (ja) マルチコアアーキテクチャでのリソース分離を支援するための方法およびシステム
US10809997B2 (en) Information processing apparatus and program update control method
JP2009140194A (ja) 障害回復環境の設定方法
US9571584B2 (en) Method for resuming process and information processing system
US9459884B2 (en) Self-healing using an alternate boot partition
WO2015074235A1 (fr) Procédé de migration de données de mémoire, ordinateur et appareil
US20200326956A1 (en) Computing nodes performing automatic remote boot operations
US9235426B2 (en) Multicore processor system, computer product, and notification method for updating operating system
JP2007133544A (ja) 障害情報解析方法及びその実施装置
JP4322240B2 (ja) 再起動方法、システム及びプログラム
JP6515462B2 (ja) 情報処理装置、情報処理装置の設定方法及び設定プログラム
WO2024124912A1 (fr) Procédé et appareil de synchronisation de données pour micrologiciel redondant, et support d'enregistrement lisible non volatil
JPWO2004081791A1 (ja) 仮想計算機システム、仮想計算機システムにおけるファームウェアアップデート方法
RU2600101C1 (ru) Управляющий модуль узла и способ обновления встроенного программного обеспечения для этого управляющего модуля
KR102123701B1 (ko) 네트워크 부트 시스템
US10193752B2 (en) Storage system upgrade

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12885090

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12885090

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP