WO2013030976A1 - 情報処理装置及び方法、プログラム - Google Patents

情報処理装置及び方法、プログラム Download PDF

Info

Publication number
WO2013030976A1
WO2013030976A1 PCT/JP2011/069755 JP2011069755W WO2013030976A1 WO 2013030976 A1 WO2013030976 A1 WO 2013030976A1 JP 2011069755 W JP2011069755 W JP 2011069755W WO 2013030976 A1 WO2013030976 A1 WO 2013030976A1
Authority
WO
WIPO (PCT)
Prior art keywords
diagnosis
hardware
diagnosed
module
logical domain
Prior art date
Application number
PCT/JP2011/069755
Other languages
English (en)
French (fr)
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 JP2013530954A priority Critical patent/JP5716830B2/ja
Priority to PCT/JP2011/069755 priority patent/WO2013030976A1/ja
Publication of WO2013030976A1 publication Critical patent/WO2013030976A1/ja
Priority to US14/171,822 priority patent/US20140149795A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0712—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a virtual computing platform, e.g. logically partitioned systems
    • 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
    • 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
    • G06F2009/45579—I/O management, e.g. providing access to device drivers or storage

Definitions

  • This technology relates to hardware resource management technology in a virtualized environment.
  • POST Power On Self Test
  • OS Operating System
  • hardware such as a processor and a memory
  • POST Power On Self Test
  • the hardware diagnosis can be performed in detail.
  • the contents of the diagnosis of the hardware diagnosis performed by the OS after the OS is started are limited due to restrictions on access to the hardware.
  • the OS may not operate normally.
  • the service processor performs failure diagnosis on the standby processor that is on standby.
  • the OS disconnects the active operation processor from the computer system and waits, and the spare processor on which the failure diagnosis has been performed is incorporated into the computer system and operated.
  • the system (subsystem) in which the service processor is installed goes down, the operation processor installed in the operating system (main system) cannot be diagnosed. .
  • the occurrence rate of failures in the subsystem to increase.
  • the virtual machine control unit performs tests for creation, deletion, suspension, and restart of a virtual machine. Further, the virtual machine control unit holds information on the shared device shared by the virtual machines, so that each virtual machine can perform operation verification while checking the shared state of the shared apparatus. However, with such a technique, it is not possible to diagnose the hardware assigned to each virtual machine.
  • an object of the present technology in one aspect, is to provide a technology for enabling appropriate hardware diagnosis during system operation.
  • An information processing apparatus includes a memory, a logical domain that executes an operating system and provides a predetermined function as a computer, and a processing apparatus that executes processing of a hypervisor that manages the logical domain; Have And a memory in the memory used by the operating system in the diagnosis processing when the operating system detects a hardware to be diagnosed and a hardware to be diagnosed by the detection module.
  • a hardware that should be diagnosed by the first instruction module and the detection module that instructs the operating system kernel to overlook the error that has occurred in the memory area is allocated to the hypervisor
  • it has a second instruction module that is used in diagnosis and instructs to overlook an error occurring in a memory area in the memory and outputs a diagnosis request including designation of hardware to be diagnosed.
  • the hypervisor receives a diagnostic request
  • the diagnostic module uses the diagnostic module to perform a diagnosis.
  • the hypervisor receives a diagnostic request
  • the diagnostic module receives a diagnostic request.
  • FIG. 1 is a diagram for explaining a problem in performing diagnosis of hardware resources.
  • FIG. 2 is a diagram for explaining a problem when performing hardware resource diagnosis.
  • FIG. 3A is a diagram illustrating a hardware configuration of the information processing apparatus according to the first embodiment.
  • FIG. 3B is a diagram illustrating a configuration of the main system in the first embodiment.
  • FIG. 4 is a diagram illustrating an example of data stored in the diagnosis definition storage unit according to the first embodiment.
  • FIG. 5 is a diagram illustrating an example of data stored in the management table storage unit.
  • FIG. 6 is a diagram illustrating an example of data stored in the allocation table storage unit.
  • FIG. 7 is a diagram showing a main processing flow in the first embodiment.
  • FIG. 8 is a diagram showing a main processing flow in the first embodiment.
  • FIG. 8 is a diagram showing a main processing flow in the first embodiment.
  • FIG. 9 is a diagram illustrating a processing flow of diagnostic processing in the first embodiment.
  • FIG. 10 is a diagram illustrating an outline of the hardware resource diagnosis method according to the first embodiment.
  • FIG. 11 is a diagram illustrating an example of data stored in the diagnosis definition storage unit according to the second embodiment.
  • FIG. 12 is a diagram illustrating a main processing flow in the second embodiment.
  • FIG. 13 is a diagram illustrating a processing flow of diagnostic processing according to the second embodiment.
  • FIG. 14 is a diagram illustrating an example of data stored in the management table storage unit.
  • the information processing apparatus in FIG. 1 includes a main system and a subsystem.
  • the main system is a system for executing business processing
  • the main system includes a program such as a logical domain 1, a logical domain 2, and a hypervisor that manages each logical domain.
  • Each program included in the main system is executed by a processor included in a hardware resource.
  • the subsystem is a system for operating and managing the main system.
  • the POST execution module is software for executing POST.
  • the hypervisor is firmware for starting a logical domain.
  • Open firmware (also called open boot) is software for starting up the OS.
  • the diagnosis of hardware resources in such an information processing apparatus is performed, for example, as shown in FIG. Specifically, when the information processing apparatus is first turned on, the subsystem is activated, and an instruction to activate the main system is issued from the subsystem. Then, the main system starts to be activated, and a hardware resource diagnosis (POST) is performed by the POST execution module.
  • POST hardware resource diagnosis
  • the hypervisor When POST is performed, the hypervisor is activated and the hypervisor activates the logical domain. Then, the open firmware starts OS pre-processing, and further starts the OS. Then, activation of the logical domain is completed, and business processing is performed in the logical domain.
  • FIG. 3A shows a hardware configuration of information processing apparatus 1000 according to the present embodiment.
  • the information processing apparatus 1000 includes a hardware resource 1 and includes a main system for executing business processing and a subsystem for operating and managing the main system using the hardware resource 1.
  • the hardware resource 1 includes hardware resources such as a processor, a memory, and a PCI (Peripheral Component Interconnect).
  • the number of hardware resources is one or more, but the number of hardware resources to be diagnosed is two or more. Note that the subsystem does not perform main processing in the present embodiment, and therefore detailed description of the subsystem is omitted.
  • Fig. 3B shows the configuration of the main system.
  • the main system includes a logical domain 11, a logical domain 12, a hypervisor 13, and a POST execution module 14.
  • the logical domains 11 and 12 are systems that are virtually realized by the hypervisor 13.
  • the logical domain 11 includes open firmware 1101 and an OS 1102.
  • the OS 1102 includes a kernel 1103, a management module 1104, a diagnosis definition table 1109, a management table 1110, and an allocation table 1111.
  • the management module 1104 includes a detection module 1105, a first instruction module 1106, a second instruction module 1107, and a notification module 1108.
  • the open firmware 1101, the OS 1102, the kernel 1103, and each module when executed by a processor included in the hardware resource 1, for example, realizes the functions described below.
  • the open firmware 1101 performs processing for starting the OS 1102.
  • the kernel 1103 performs well-known processing performed by a general OS kernel, such as resource management in the information processing apparatus 1000 and provision of interprocess communication.
  • the detection module 1105 performs processing for detecting hardware resources to be diagnosed using data stored in the diagnosis definition table 1109 and the management table 1110.
  • the first instruction module 1106 performs processing for outputting a mask instruction to be described later to the kernel 1103.
  • the second instruction module 1107 performs a process of outputting a mask instruction to be described later to the hypervisor 113.
  • the notification module 1108 performs a process for presenting a hardware resource abnormality to a user (for example, an administrator of the information processing apparatus 1000).
  • the logical domain 12 includes open firmware 121 and an OS 122 including a kernel 123. Since these functions are the same as the functions of the open firmware 1101 and the OS 1102 in the logical domain 11, the description thereof is omitted.
  • FIG. 3B two logical domains are shown, but the number of logical domains is not limited. In this embodiment, it is assumed that there is no other logical domain having the same function as the logical domain 11. In other words, diagnosis is centrally managed in the logical domain 11.
  • the hypervisor 13 includes a management module 130 including a setting module 131 and a diagnostic module 132, and an allocation table 133.
  • a management module 130 including a setting module 131 and a diagnostic module 132, and an allocation table 133.
  • the setting module 131 performs settings for the hypervisor 13 to overlook errors that have occurred in a predetermined memory area.
  • the diagnosis module 132 performs a diagnosis for detecting a hardware resource failure.
  • FIG. 4 shows an example of data stored in the diagnosis definition table 1109.
  • data for specifying whether or not to perform diagnosis data for specifying a diagnosis target, and data for specifying a diagnosis interval are stored. These data are data designated by the user of the information processing apparatus 1000.
  • FIG. 5 shows an example of data stored in the management table 1110.
  • the number assigned to the hardware resource, the hardware resource name, the data of the last diagnosis time, the diagnosis result, and the data indicating whether or not to perform additional diagnosis are stored. It has become. If the hardware resource is normal, the diagnosis result is “OK”, and if the hardware resource is faulty, the diagnosis result is “NG”. If the diagnosis is to be performed again, the additional diagnosis is “OK”. If the diagnosis is not to be performed again, the additional diagnosis is “NG”.
  • FIG. 6 shows an example of data stored in the allocation table 1111.
  • allocation destination information and hardware resource names are stored.
  • the allocation table is a table for managing the allocation of hardware resources included in the information processing apparatus 1000, and the contents are updated when the allocation is changed.
  • the allocation table 133 also stores the same data as the allocation table 1111.
  • the detection module 1105 in the logical domain 11 detects a hardware resource (hereinafter referred to as a target resource) to be diagnosed (FIG. 7: Step S1).
  • a hardware resource hereinafter referred to as a target resource
  • the diagnosis is performed for a predetermined time or more after the last diagnosis. Detect unused hardware resources. However, hardware resources in which “NG” is stored in the additional diagnosis column are not detected.
  • the first instruction module 1106 secures a memory area used by the OS 1102 in the process for diagnosing the target resource (step S3). Then, the first instruction module 1106 outputs to the kernel 1103 a mask instruction including the address of the memory area secured in step S3 and the designation of the target resource detected in step S1 (here, the hardware resource name) ( Step S5).
  • the kernel 1103 receives a mask instruction from the first instruction module 1106 (step S7). In addition, the kernel 1103 performs setting for the OS 1102 to overlook an error that has occurred in the notified memory area (step S9).
  • the second instruction module 1107 outputs a mask instruction to the hypervisor 13 (step S11).
  • the hypervisor 13 receives a mask instruction from the second instruction module 1107 (step S13). Then, the setting module 131 in the hypervisor 13 performs setting to overlook errors that have occurred in the memory area for the diagnostic module 132 (that is, the memory area in which the program for realizing the diagnostic module 132 is arranged) ( Step S15). The processing shifts to the processing in FIG. 8 via terminals A and B.
  • the second instruction module 1107 outputs a diagnosis request including the designation of the target resource detected in step S1 to the hypervisor 13 (FIG. 8: step S17).
  • the diagnostic module 132 in the hypervisor 13 receives a diagnostic request from the second instruction module 1107 (step S19). Then, the diagnosis module 132 performs a diagnosis process (step S21). The diagnosis process will be described in detail with reference to FIG.
  • the diagnosis module 132 determines whether the target resource has been allocated to any logical domain by searching the allocation table 133 with the target resource name specified in the diagnosis request (FIG. 9: Step S41). . If it is not assigned to any logical domain (step S41: No route), there is no problem even if the target resource is diagnosed, so the diagnostic module 132 diagnoses the target resource (step S43). Then, the process returns to the original process.
  • the diagnosis module 132 performs diagnosis for the target resource by accessing a register of the target resource, for example, using a special authority related to diagnosis of the hardware resource.
  • step S41 when the target resource is allocated to any logical domain (step S41: Yes route), the diagnostic module 132 determines whether there is an unallocated hardware resource in the allocation table 133 (step S45). When it is determined that there is an unallocated hardware resource (step S45: Yes route), the diagnosis module 132 performs a diagnosis on the unallocated resource (step S47).
  • diagnosis module 132 determines whether the diagnosis result indicates “normal” (step S49). If the diagnosis result does not indicate “normal” (step S49: No route), if the unallocated resource is allocated to the logical domain, a problem may occur in the logical domain, and the process returns to step S45.
  • step S49 Yes route
  • the diagnosis module 132 allocates the unallocated resource to the logical domain instead of the target resource (step S51). Then, the diagnosis module 132 performs diagnosis for the target resource released from the allocation (step S53). Then, the process returns to the original process.
  • step S45 No route
  • the target resource cannot be released from allocation and cannot be diagnosed, so the process returns to the original process.
  • the target resource can be diagnosed without affecting the operating logical domain.
  • the unallocated hardware resources are normal and assigned to the logical domain, it is possible to prevent the logical domain from malfunctioning. Furthermore, since the target resource is not allocated again after the target resource is released from the allocation and diagnosed, the hardware resource allocated to the logical domain is switched. As a result, it is possible to suppress a bias in use such that specific hardware resources continue to be assigned to the logical domain.
  • diagnosis module 132 outputs the diagnosis result to the management module 1104 in the OS 1102 (step S23).
  • the notification module 1108 in the management module 1104 receives the diagnosis result from the diagnosis module 132 (step S25). Then, the notification module 1108 updates the data stored in the management table 1110 (Step S27). When the diagnosis result indicates “normal”, “OK” is stored in the diagnosis result and additional diagnosis column, and when the diagnosis result does not indicate “normal”, the diagnosis result and additional diagnosis are stored. “NG” is stored in the column of. If the diagnosis is not performed, that is, if the route is routed through No route in step S45, “NG” is stored in the additional diagnosis column.
  • the notification module 1108 When the diagnosis result does not indicate “normal”, the notification module 1108 generates data for allowing the user to recognize the occurrence of the failure, and displays the generated data on a display unit (not shown). As a result, the user is notified (step S29). Further, the notification module 1108 registers the name of the hardware resource in which the failure has occurred and the date and time of occurrence in the event log table (not shown).
  • the OS 1102 and the hypervisor 13 are not adversely affected (for example, panicked) due to an error occurring in a predetermined memory area during diagnosis of hardware resources. Therefore, even when the logical domain is in operation, appropriate hardware diagnosis can be performed using the privilege of the hypervisor 13, and the failure detection can be prevented from being delayed. That is, it becomes possible to detect a hardware resource failure at an early stage and realize stable operation of the main system.
  • FIG. 10 shows an outline of the hardware resource diagnosis method according to the first embodiment. According to the first embodiment, it is possible to perform periodic diagnosis on each hardware resource during operation of the logical domain. In other words, the hardware resource can be diagnosed without resetting the main system or the logical domain.
  • the second embodiment is different from the first embodiment in that the target resource can be forcibly diagnosed even when the target resource has been allocated and there is no unallocated hardware resource. Is different.
  • FIG. 11 shows an example of data stored in the diagnosis definition table 1109.
  • data for specifying whether or not to perform diagnosis data for specifying a diagnosis target, data for specifying a diagnosis interval, and whether or not to enable forced diagnosis And data for designating are stored.
  • the detection module 1105 in the logical domain 11 detects a hardware resource (hereinafter referred to as a target resource) to be diagnosed (FIG. 12: Step S61).
  • the detection method is as described in the description of step S1.
  • the detection module 1105 determines whether there are unallocated hardware resources in the allocation table 1111 (step S63). If it is determined that there is an unallocated hardware resource (step S63: Yes route), the target resource can be diagnosed without determining whether or not forced diagnosis is possible, and the process proceeds to step S69. .
  • step S63 determines whether forced diagnosis is enabled in the diagnosis definition table 1109 (step S65). If it is determined that the forced diagnosis is not valid (step S65: No route), the diagnosis cannot be performed on the target resource, and the process ends (step S67).
  • step S65 Yes route
  • the diagnosis can be performed by regarding the allocated hardware resource as an unallocated hardware resource. Therefore, the first instruction module 1106 secures a memory area used by the OS 1102 in the process for diagnosing the target resource (step S69). Then, the first instruction module 1106 outputs a mask instruction including the address of the memory area secured in step S3 to the kernel 1103 (step S71).
  • the kernel 1103 receives the mask instruction from the first instruction module 1106 (step S73). In addition, the kernel 1103 performs setting for the OS 1102 to overlook an error that has occurred in the notified memory area (step S75).
  • the second instruction module 1107 outputs a mask instruction to the hypervisor 13 (step S77).
  • the hypervisor 13 receives a mask instruction from the second instruction module 1107 (step S79). Then, the setting module 131 in the hypervisor 13 performs setting to overlook errors that have occurred in the memory area for the diagnostic module 132 (that is, the memory area in which the program for realizing the diagnostic module 132 is arranged) ( Step S81). Then, the processing shifts to the processing in FIG. 8 through terminals A and B.
  • the diagnosis module 132 in the hypervisor 13 can be forced to perform diagnosis.
  • the diagnostic processing in the second embodiment is different from the diagnostic processing in the first embodiment. Therefore, the diagnosis process in the second embodiment will be described with reference to FIG.
  • the diagnostic module 132 searches the allocation table 133 with the target resource name specified in the diagnostic request to determine whether the target resource has been allocated to any logical domain (FIG. 13: Step S91). . If it is not assigned to any logical domain (step S91: No route), there is no problem even if the target resource is diagnosed, so the diagnostic module 132 diagnoses the target resource (step S93). Then, the process returns to the original process.
  • the diagnosis module 132 performs diagnosis for the target resource by accessing a register of the target resource, for example, using a special authority related to the diagnosis of the hardware resource.
  • step S91 when the target resource is allocated to any logical domain (step S91: Yes route), the diagnosis module 132 determines whether there is an unallocated hardware resource in the allocation table 133 (step S95). When it is determined that there is an unallocated hardware resource (step S95: Yes route), the diagnosis module 132 performs diagnosis on the unallocated resource (step S97).
  • diagnosis module 132 determines whether the diagnosis result indicates “normal” (step S99). If the diagnosis result does not indicate “normal” (step S99: No route), if the unallocated resource is allocated to the logical domain, a problem may occur in the logical domain, and the process returns to step S95.
  • step S99 Yes route
  • the diagnosis module 132 allocates the unallocated resource to the logical domain instead of the target resource (step S101). Then, the diagnosis module 132 performs diagnosis for the target resource released from the allocation (step S103). Then, the process returns to the original process.
  • step S95 when it is determined that there is no unassigned hardware resource (step S95: No route), the diagnosis module 132 determines whether the forced diagnosis is enabled in the diagnosis definition table 1109 (step S105). If the forced diagnosis is not valid (step S105: No route), the target resource cannot be released from the allocation and the diagnosis cannot be performed, and the process returns to the original process.
  • step S105 when the forced diagnosis is valid (step S105: Yes route), the diagnosis module 132 identifies one hardware resource that has been allocated in the allocation table 133 (step S107), and Diagnosis is performed (step S97).
  • the processing after step S99 is as described above.
  • the present technology has been described above, but the present technology is not limited to this.
  • the configuration of the information processing apparatus 1000 described above does not necessarily correspond to the actual program module configuration.
  • the processing order can be changed if the processing result does not change. Further, it may be executed in parallel.
  • the last diagnosis time is managed, but as shown in FIG. 14, the time elapsed since the last diagnosis (that is, the operation time) is managed. You may make it do. In such a case, by making a diagnosis when the operating time exceeds the diagnosis interval, it is possible to perform a regular diagnosis on the hardware resource.
  • the diagnosis module 132 in the hypervisor 13 is notified whether the forced diagnosis is valid. You may make it do. In this way, the diagnosis module 132 does not need to determine whether the forced diagnosis is valid in step S105.
  • the target resource when the target resource has already been assigned to one of the logical domains, another hardware resource is assigned instead of the target resource, and then the target resource is diagnosed. Then, after completion of diagnosis for the target resource, the target resource is not reassigned to the logical domain. However, if the target resource is not out of order, it may be reassigned to the logical domain.
  • step S17 the designation of the target resource is notified from the second instruction module 1107 to the hypervisor 13.
  • the kernel 1103 that has received the mask instruction designates the target resource to the hypervisor 13. You may make it notify.
  • the information processing apparatus includes (A) a memory, (B) a logical domain that executes an operating system and provides a predetermined function as a computer, and a processing apparatus that executes processing of a hypervisor that manages the logical domain ( For example, a processor.
  • a processing apparatus that executes processing of a hypervisor that manages the logical domain
  • the detection module detects the hardware.
  • the hardware to be used is detected, a memory area in the memory used by the operating system in the diagnosis process is secured, and an error occurring in the memory area is overlooked to the operating system kernel.
  • the processing device described above is realized by, for example, a processor and a program executed by the processor.
  • the diagnosis module described above is executed in the processing device (b2-21), if the hardware to be diagnosed is assigned to any logical domain, the hardware of the information processing device Of these, hardware that is not assigned to any logical domain may be assigned instead of the hardware that is to be diagnosed, and then the hardware that is to be diagnosed may be diagnosed. In this way, even when the hardware to be diagnosed is assigned to the logical domain, the diagnosis can be performed while the operation of the logical domain is continued. In addition, it is possible to prevent uneven use of hardware such that specific hardware continues to be assigned to a logical domain.
  • the diagnosis module described above is executed in the processing device (b2-22), the diagnosis is performed on hardware that is not assigned to any logical domain among the hardware of the information processing device.
  • the hardware may be assigned instead of the hardware to be diagnosed. In this way, it is possible to prevent the occurrence of problems caused by allocating faulty hardware to a logical domain.
  • the hardware to be diagnosed is assigned to any logical domain and is assigned to any logical domain. If there is no hardware, read the definition data defining the diagnostic method from the table, determine whether forced diagnosis is specified, and if it is determined that forced diagnosis is specified, it is already assigned to one of the logical domains. May be assigned instead of the hardware to be diagnosed. In this way, even when there is little surplus hardware, the diagnosis can be performed reliably.
  • the diagnosis result may be output to the operating system.
  • the operating system is executed on the processing device (b1-3)
  • the diagnosis result indicates that the hardware on which the diagnosis has been performed has failed
  • the failure is assigned to the logical domain. You may make it further have a notification module which produces
  • the detection module described above (b1-11) detects hardware that has not been diagnosed for a predetermined time or more from among the hardware of the information processing apparatus when executed by the processing device. Also good. Thereby, a periodic diagnosis can be performed.
  • the hardware of the information processing device has not been diagnosed for a predetermined time and is normal in the previous diagnosis. Hardware that has been diagnosed as such may be detected. As a result, it is possible to eliminate the waste of performing the diagnosis again on the hardware diagnosed as having a failure in the previous diagnosis.
  • the operating system included in any one of the logical domains realized by the hypervisor may have a detection module, a first instruction module, and a second instruction module. This makes it possible to properly manage hardware diagnosis.
  • the information processing method includes (C) a step of detecting hardware to be diagnosed, and (D) a memory used in a diagnosis process by an operating system included in a logical domain that is a virtually realized system. A step of instructing the operating system kernel to overlook errors occurring in the memory area, and (E) a memory used in diagnosis for the hypervisor for realizing the logical domain Instructing to overlook errors occurring in the region and outputting a diagnosis request including designation of hardware to be diagnosed.
  • the information processing method includes (F) designation of hardware to be diagnosed and instructed to overlook an error that has occurred in a memory area used in hardware diagnosis. Settings for ignoring errors that occur in the memory area used by the hypervisor for realizing a logical domain when a diagnostic request is received from an operating system included in the logical domain that is a virtually realized system And (G) performing a diagnosis on hardware to be diagnosed.
  • a program for causing a computer to perform the processing according to the above method can be created.
  • the program can be a computer-readable storage medium such as a flexible disk, a CD-ROM, a magneto-optical disk, a semiconductor memory, or a hard disk. It is stored in a storage device.
  • the intermediate processing result is temporarily stored in a storage device such as a main memory.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Software Systems (AREA)
  • General Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • Computer Hardware Design (AREA)
  • Mathematical Physics (AREA)
  • For Increasing The Reliability Of Semiconductor Memories (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

　本情報処理装置は、メモリと、オペレーティングシステム（ＯＳ）を実行し、計算機として所定の機能を提供する論理ドメインと前記論理ドメインの管理を行うハイパバイザとの処理を実行する処理装置とを有する。そして、上記ＯＳが、診断を行うべきハードウェアを検出し、診断のための処理においてＯＳが利用するメモリ領域を確保し、ＯＳカーネルに対して、当該メモリ領域で発生したエラーを看過するように指示する。また、上記ＯＳは、ハイパバイザに対して、診断において利用するメモリ領域で発生したエラーを看過するように指示し且つ診断を行うべきハードウェアの指定を含む診断要求を出力する。そして、上記ハイパバイザが、診断要求を受信した場合、診断部が診断において利用するメモリ領域で発生したエラーを看過するための設定を行い、また診断を行うべきハードウェアに対して診断を行う。

Description

情報処理装置及び方法、プログラム
　本技術は、仮想化環境におけるハードウェアリソースの管理技術に関する。
　コンピュータに電源が投入されると、ＯＳ（Operating System）が起動する前にＰＯＳＴ（Power On Self Test）が行われ、例えばプロセッサやメモリといったハードウェアの診断が行われる。ＰＯＳＴは、ハードウェアの診断に関する特別な権限を有するファームウェアにより、ハードウェアを占有して行われる診断であるため、ハードウェアの診断を詳細に行うことができる。これに対し、ＯＳの起動後ＯＳによって行われるハードウェア診断は、ハードウェアへのアクセスの制限等のため、診断の内容が限定されている。また、もしシステムの稼働中にＯＳによって無理にハードウェア診断を行うと、ＯＳが正常に動作しなくなることがある。
　従来、ハードウェアの診断に関して、以下のような従来技術が存在する。具体的には、サービスプロセッサが、待機中である予備プロセッサに対して故障診断を行う。そして、故障診断の結果が正常である場合に、ＯＳが、稼働中の運用プロセッサをコンピュータシステムから切り離して待機させると共に、故障診断が行われた予備プロセッサを、コンピュータシステムに組み込んで稼働させるようにする。しかし、この技術では、サービスプロセッサを搭載しているシステム（サブシステム）がダウンした場合、稼働中のシステム（メインシステム）に搭載されている運用プロセッサに対しては、診断を行うことができなくなる。近年では、部品数が増えたこと等に伴って、サブシステムにおける故障の発生率が増加する傾向にあるため、このような技術では問題がある。
　また、装置の動作検証に関して、以下のような技術が存在する。具体的には、仮想計算機制御部が、仮想計算機の創成、削除、中断及び再開の試験を行う。また、仮想計算機が共有する共有装置の情報を仮想計算機制御部が保持することにより、各仮想計算機が共有装置の共有状態を確認しながら動作検証を行えるようにする。しかし、このような技術では、各仮想計算機に割り当てられているハードウェアについては診断を行うことができない。
特開２００６－２５２４２９号公報 特開平８－３０５５９６号公報
　従って、本技術の目的は、一側面において、システムの稼働中に適切なハードウェア診断を行えるようにするための技術を提供することである。
　本技術の一側面に係る情報処理装置は、メモリと、オペレーティングシステムを実行し、計算機として所定の機能を提供する論理ドメインと、前記論理ドメインの管理を行うハイパバイザとの処理を実行する処理装置とを有する。そして、上記オペレーティングシステムが、診断を行うべきハードウェアを検出する検出モジュールと、検出モジュールにより診断を行うべきハードウェアが検出された場合、診断のための処理においてオペレーティングシステムが利用する、メモリにおけるメモリ領域を確保し、オペレーティングシステムのカーネルに対して、当該メモリ領域で発生したエラーを看過するように指示する第１指示モジュールと、検出モジュールにより診断を行うべきハードウェアが検出された場合、ハイパバイザに対して、診断において利用する、メモリにおけるメモリ領域で発生したエラーを看過するように指示し且つ診断を行うべきハードウェアの指定を含む診断要求を出力する第２指示モジュールとを有する。そして、上記ハイパバイザが、診断要求を受信した場合、診断モジュールが診断において利用する、メモリにおけるメモリ領域で発生したエラーを看過するための設定を行う設定モジュールと、診断要求を受信した場合、診断を行うべきハードウェアに対して診断を行う診断モジュールとを有する。
図１は、ハードウェアリソースの診断を行う際の問題点を説明するための図である。 図２は、ハードウェアリソースの診断を行う際の問題点を説明するための図である。 図３Ａは、第１の実施の形態における情報処理装置のハードウェア構成を示す図である。 図３Ｂは、第１の実施の形態におけるメインシステムの構成を示す図である。 図４は、第１の実施の形態に係る診断定義格納部に格納されているデータの一例を示す図である。 図５は、管理テーブル格納部に格納されているデータの一例を示す図である。 図６は、割当テーブル格納部に格納されているデータの一例を示す図である。 図７は、第１の実施の形態におけるメインの処理フローを示す図である。 図８は、第１の実施の形態におけるメインの処理フローを示す図である。 図９は、第１の実施の形態における診断処理の処理フローを示す図である。 図１０は、第１の実施の形態に係るハードウェアリソースの診断方法の概要を示す図である。 図１１は、第２の実施の形態に係る診断定義格納部に格納されているデータの一例を示す図である。 図１２は、第２の実施の形態におけるメインの処理フローを示す図である。 図１３は、第２の実施の形態における診断処理の処理フローを示す図である。 図１４は、管理テーブル格納部に格納されているデータの一例を示す図である。
　例えば図１に示すような情報処理装置においてハードウェアリソースの診断を行うことを考える。図１の情報処理装置は、メインシステムと、サブシステムとを含む。ここで、メインシステムは業務処理を実行するためのシステムであり、メインシステムは論理ドメイン１、論理ドメイン２及び各論理ドメインの管理を行うハイパバイザ等のプログラムを含む。メインシステムに含まれる各プログラムは、ハードウェアリソースに含まれるプロセッサにより実行される。サブシステムは、メインシステムを運用及び管理するためのシステムである。ＰＯＳＴ実行モジュールは、ＰＯＳＴを実行するためのソフトウェアである。ハイパバイザ（hypervisor）は、論理ドメインを起動するためのファームウェアである。オープンファームウェア（オープンブートとも呼ばれる）は、ＯＳを起動するためのソフトウェアである。
　このような情報処理装置におけるハードウェアリソースの診断は、例えば図２に示すようにして行われる。具体的には、まず情報処理装置に電源を投入すると、サブシステムが起動し、当該サブシステムからメインシステムの起動指示が出される。そして、メインシステムが起動を開始し、ＰＯＳＴ実行モジュールによるハードウェアリソースの診断（ＰＯＳＴ）が行われる。
　なお、ＰＯＳＴが行われると、ハイパバイザが起動し、当該ハイパバイザが論理ドメインを起動する。すると、オープンファームウェアがＯＳ起動の前処理を開始し、さらにＯＳを起動する。そして、論理ドメインの起動が完了し、論理ドメインにおいて業務処理が行われる。
　ここで、論理ドメインの稼動中に、論理ドメインをリセットする旨の指示がユーザからあった場合には、指示に係る論理ドメインのみが再起動される。ところが、論理ドメインをリセットしただけでは、メインシステム自体がリセットされるわけではないため、ＰＯＳＴが行われない。そこで、ＰＯＳＴを行うためにメインシステムを再起動することが考えられるが、このようにすると全ての論理ドメインを再起動することになる。
　しかし、各論理ドメインでは別々の業務処理が行われているため、複数の論理ドメインを同時に再起動することができるようなタイミングは限られてしまうことが多い。そのため、実際にはメインシステムの再起動をすることができず、ハードウェアリソースの故障の検出が遅れてしまうことがある。
　そこで、以下システム稼働中にも適切にハードウェアの診断を行う２つの実施の形態を具体的に説明する。
［実施の形態１］
　本実施の形態における情報処理装置１０００のハードウェア構成を図３Ａに示す。図３Ａの例では、情報処理装置１０００は、ハードウェアリソース１を有し、ハードウェアリソース１により、業務処理を実行するためのメインシステムと、メインシステムを運用及び管理するためのサブシステムとを実行する。ハードウェアリソース１は、例えばプロセッサ、メモリ、ＰＣＩ（Peripheral Component Interconnect）等のハードウェアリソースを含む。各ハードウェアリソースの数は１又は複数であるが、診断が行われるハードウェアリソースについては、数は２以上である。なお、サブシステムは、本実施の形態における主要な処理を行うわけではないので、サブシステムについての詳細な説明は省略する。
　図３Ｂに、メインシステムの構成を示す。メインシステムは、論理ドメイン１１と、論理ドメイン１２と、ハイパバイザ１３と、ＰＯＳＴ実行モジュール１４とを含む。論理ドメイン１１及び１２は、ハイパバイザ１３により仮想的に実現されたシステムである。
　論理ドメイン１１は、オープンファームウェア１１０１と、ＯＳ１１０２とを含む。また、ＯＳ１１０２は、カーネル１１０３と、管理モジュール１１０４と、診断定義テーブル１１０９と、管理テーブル１１１０と、割当テーブル１１１１とを含む。また、管理モジュール１１０４は、検出モジュール１１０５と、第１指示モジュール１１０６と、第２指示モジュール１１０７と、通知モジュール１１０８とを含む。
　なお、オープンファームウェア１１０１、ＯＳ１１０２、カーネル１１０３及び各モジュールは、例えばハードウェアリソース１に含まれるプロセッサに実行されると、以下で説明する機能を実現する。
　オープンファームウェア１１０１は、ＯＳ１１０２を起動するための処理を行う。カーネル１１０３は、例えば情報処理装置１０００におけるリソースの管理やプロセス間通信の提供等、一般的なＯＳのカーネルが行う周知の処理を行う。検出モジュール１１０５は、診断定義テーブル１１０９及び管理テーブル１１１０に格納されているデータを用いて、診断を行うべきハードウェアリソースを検出する処理を行う。第１指示モジュール１１０６は、カーネル１１０３に対して後述のマスク指示を出力する処理等を行う。第２指示モジュール１１０７は、ハイパバイザ１１３に対して後述のマスク指示を出力する処理等を行う。通知モジュール１１０８は、ハードウェアリソースの異常をユーザ（例えば情報処理装置１０００の管理者）に提示するための処理等を行う。
　論理ドメイン１２は、オープンファームウェア１２１と、カーネル１２３を含むＯＳ１２２とを含む。これらの機能は、論理ドメイン１１におけるオープンファームウェア１１０１及びＯＳ１１０２の機能と同じであるので、説明を省略する。
　なお、図３Ｂでは論理ドメインを２つ示しているが、論理ドメインの数に限定は無い。また、本実施の形態では、論理ドメイン１１と同様の機能を有する論理ドメインは他には無いとする。すなわち、論理ドメイン１１において一元的に診断を管理している。
　ハイパバイザ１３は、設定モジュール１３１及び診断モジュール１３２を含む管理モジュール１３０と、割当テーブル１３３とを含む。ハイパバイザ１３及び当該ハイパバイザ１３に含まれる各モジュールは、例えばハードウェアリソース１に含まれるプロセッサに実行されると、以下で説明する機能を実現する。
　設定モジュール１３１は、所定のメモリ領域で発生したエラーをハイパバイザ１３が看過するための設定等を行う。診断モジュール１３２は、ハードウェアリソースの故障を検出するための診断を行う。
　図４に、診断定義テーブル１１０９に格納されているデータの一例を示す。図４の例では、診断を実施するか否かを指定するためのデータと、診断対象を指定するためのデータと、診断間隔を指定するためのデータとが格納されている。これらのデータは、情報処理装置１０００のユーザによって指定されたデータである。
　図５に、管理テーブル１１１０に格納されているデータの一例を示す。図５の例では、ハードウェアリソースに付与された番号と、ハードウェアリソース名と、最終診断時刻のデータと、診断結果と、追加診断をするか否かを示すデータとが格納されるようになっている。ハードウェアリソースが正常であれば診断結果は「ＯＫ」となり、ハードウェアリソースが故障していれば診断結果が「ＮＧ」となる。また、再度診断を行うべきであれば追加診断は「ＯＫ」となり、再度診断を行うべきでなければ追加診断は「ＮＧ」となる。
　図６に、割当テーブル１１１１に格納されているデータの一例を示す。図６の例では、割り当て先の情報と、ハードウェアリソース名とが格納されるようになっている。割当テーブルは、情報処理装置１０００が有するハードウェアリソースの割り当てを管理するためのテーブルであり、割り当てが変更された場合には内容が更新される。なお、割当テーブル１３３にも、割当テーブル１１１１と同じデータが格納されている。
　次に、第１の実施の形態における情報処理装置１０００の処理内容について説明する。まず、論理ドメイン１１における検出モジュール１１０５は、診断を行うべきハードウェアリソース（以下、対象リソースと呼ぶ）を検出する（図７：ステップＳ１）。ステップＳ１においては、管理テーブル１１１０に格納されている最終診断時刻のデータと、診断定義テーブル１１０９に格納されている診断間隔のデータとを用いて、最後に診断を行ってから所定時間以上診断が行われていないハードウェアリソースを検出する。但し、追加診断の欄に「ＮＧ」が格納されているハードウェアリソースは検出されない。
　そして、第１指示モジュール１１０６は、対象リソースに対する診断のための処理においてＯＳ１１０２が利用するメモリ領域を確保する（ステップＳ３）。そして、第１指示モジュール１１０６は、ステップＳ３において確保されたメモリ領域のアドレス及びステップＳ１において検出された対象リソースの指定（ここでは、ハードウェアリソース名）を含むマスク指示をカーネル１１０３に出力する（ステップＳ５）。
　カーネル１１０３は、第１指示モジュール１１０６からマスク指示を受信する（ステップＳ７）。また、カーネル１１０３は、通知されたメモリ領域上で発生したエラーをＯＳ１１０２が看過するための設定を行う（ステップＳ９）。
　また、第２指示モジュール１１０７は、マスク指示をハイパバイザ１３に出力する（ステップＳ１１）。
　ハイパバイザ１３は、第２指示モジュール１１０７からマスク指示を受信する（ステップＳ１３）。そして、ハイパバイザ１３における設定モジュール１３１は、診断モジュール１３２のためのメモリ領域（すなわち、診断モジュール１３２を実現するためのプログラムが配置されるメモリ領域）で発生したエラーを看過するための設定を行う（ステップＳ１５）。処理は端子Ａ及びＢを介して図８の処理に移行する。
　図８の処理の説明に移行して、第２指示モジュール１１０７は、ステップＳ１において検出された対象リソースの指定を含む診断要求をハイパバイザ１３に出力する（図８：ステップＳ１７）。
　ハイパバイザ１３における診断モジュール１３２は、第２指示モジュール１１０７から診断要求を受信する（ステップＳ１９）。そして、診断モジュール１３２は、診断処理を実施する（ステップＳ２１）。診断処理については、図９を用いて詳細に説明する。
　まず、診断モジュール１３２は、診断要求において指定されている対象リソース名で割当テーブル１３３を検索することにより、対象リソースがいずれかの論理ドメインに割り当て済みであるか判断する（図９：ステップＳ４１）。いずれの論理ドメインにも割り当てられていない場合（ステップＳ４１：Ｎｏルート）、対象リソースに対する診断を行っても問題は無いため、診断モジュール１３２は対象リソースに対する診断を行う（ステップＳ４３）。そして元の処理に戻る。
　なお、本実施の形態においては、診断モジュール１３２はハードウェアリソースの診断に関する特別な権限を利用して、例えば対象リソースのレジスタにアクセスすることにより、対象リソースに対する診断を行う。
　一方、対象リソースがいずれかの論理ドメインに割り当てられている場合（ステップＳ４１：Ｙｅｓルート）、診断モジュール１３２は、割当テーブル１３３において未割り当てのハードウェアリソースが有るか判断する（ステップＳ４５）。未割り当てのハードウェアリソースが有ると判断された場合（ステップＳ４５：Ｙｅｓルート）、診断モジュール１３２は、当該未割り当てのリソースに対して診断を行う（ステップＳ４７）。
　そして、診断モジュール１３２は、診断結果が「正常」を示しているか判断する（ステップＳ４９）。診断結果が「正常」を示していない場合（ステップＳ４９：Ｎｏルート）、当該未割り当てリソースを論理ドメインに割り当てると論理ドメインに不具合が生じる可能性があるので、ステップＳ４５に戻る。
　一方、診断結果が「正常」を示している場合（ステップＳ４９：Ｙｅｓルート）、診断モジュール１３２は、当該未割り当てリソースを対象リソースの代わりに論理ドメインに割り当てる（ステップＳ５１）。そして、診断モジュール１３２は、割り当てから解放された対象リソースに対する診断を行う（ステップＳ５３）。そして元の処理に戻る。
　一方、未割り当てのハードウェアリソースが無いと判断された場合（ステップＳ４５：Ｎｏルート）、対象リソースを割り当てから解放することができず、診断を行うことができないため、元の処理に戻る。
　このようにすれば、対象リソースが割り当て済みであったとしても、稼働中の論理ドメインに影響を与えることなく、対象リソースの診断を行うことができるようになる。
　また、未割り当てのハードウェアリソースが正常であることを確認したうえで論理ドメインに割り当てるので、論理ドメインに不具合が発生することを防止できる。さらに、対象リソースを割り当てから解放して診断を行った後、対象リソースを再度割り当てることをしていないので、論理ドメインに割り当てられるハードウェアリソースが入れ替わることになる。これにより、特定のハードウェアリソースが論理ドメインに割り当てられ続けるような、使用の偏りを抑制することができるようになる。
　図８の説明に戻り、診断モジュール１３２は、診断結果をＯＳ１１０２における管理モジュール１１０４に出力する（ステップＳ２３）。
　管理モジュール１１０４における通知モジュール１１０８は、診断結果を診断モジュール１３２から受信する（ステップＳ２５）。そして、通知モジュール１１０８は、管理テーブル１１１０に格納されているデータを更新する（ステップＳ２７）。なお、診断結果が「正常」を示している場合には、診断結果及び追加診断の欄に「ＯＫ」を格納し、診断結果が「正常」を示していない場合には、診断結果及び追加診断の欄に「ＮＧ」を格納する。また、診断が行われていない、すなわちステップＳ４５のＮｏルートを経由している場合には、追加診断の欄に「ＮＧ」を格納する。
　そして、通知モジュール１１０８は、診断結果が「正常」を示していない場合には、故障の発生をユーザに認識させるためのデータを生成し、生成したデータを表示部（図示せず）に表示させることにより、ユーザに対する通知を行う（ステップＳ２９）。また、通知モジュール１１０８は、イベントログテーブル（図示せず）に、故障が発生したハードウェアリソースの名前と発生日時とを登録しておく。
　以上のような処理を実施することにより、ハードウェアリソースの診断中に所定のメモリ領域で発生したエラーによって、ＯＳ１１０２及びハイパバイザ１３が悪影響（例えばパニック状態に陥る等）を受けることなくなる。よって、論理ドメインの稼働中であっても、ハイパバイザ１３の特権を利用して適切なハードウェア診断を行うことができ、故障の検出が遅れてしまうことを防ぐことができるようになる。すなわち、早期にハードウェアリソースの故障を検出し、メインシステムの安定稼働を実現できるようになる。
　ここで、第１の実施の形態に係るハードウェアリソースの診断方法の概要を図１０に示す。第１の実施の形態によれば、論理ドメインの稼働中に各ハードウェアリソースに対して定期的な診断を行うことができるようになる。すなわち、メインシステム又は論理ドメインをリセットしなくても、ハードウェアリソースに対する診断を行うことができるようになっている。
［実施の形態２］
　次に、第２の実施の形態について説明する。第２の実施の形態は、対象リソースが割り当て済みであり且つ未割り当てのハードウェアリソースが無い場合であっても、対象リソースに対して強制的に診断を行える点で第１の実施の形態とは異なっている。
　第２の実施の形態における情報処理装置１０００の構成について、第１の実施の形態との相違点を説明する。
　図１１に、診断定義テーブル１１０９に格納されているデータの一例を示す。図１１の例では、診断を実施するか否かを指定するためのデータと、診断対象を指定するためのデータと、診断間隔を指定するためのデータと、強制診断を有効にするか否かを指定するためのデータとが格納されている。
　その他の部分については、第１の実施の形態と同様である。
　次に、第２の実施の形態における情報処理装置１０００の処理内容について説明する。まず、論理ドメイン１１における検出モジュール１１０５は、診断を行うべきハードウェアリソース（以下、対象リソースと呼ぶ）を検出する（図１２：ステップＳ６１）。検出の方法については、ステップＳ１の説明で述べたとおりである。
　そして、検出モジュール１１０５は、割当テーブル１１１１において未割り当てのハードウェアリソースが有るか判断する（ステップＳ６３）。未割り当てのハードウェアリソースが有ると判断された場合（ステップＳ６３：Ｙｅｓルート）、強制診断の可否について判断するまでもなく、対象リソースに対する診断を行うことができるので、ステップＳ６９の処理に移行する。
　一方、未割り当てのハードウェアリソースが無いと判断された場合（ステップＳ６３：Ｎｏルート）、検出モジュール１１０５は、診断定義テーブル１１０９において強制診断が有効になっているか判断する（ステップＳ６５）。強制診断が有効ではないと判断された場合（ステップＳ６５：Ｎｏルート）、対象リソースに対する診断を行うことはできないので、処理を終了する（ステップＳ６７）。
　一方、強制診断が有効であると判断された場合（ステップＳ６５：Ｙｅｓルート）、割り当て済みであるハードウェアリソースを未割り当てのハードウェアリソースであるとみなして診断を行うことができる。よって、第１指示モジュール１１０６は、対象リソースに対する診断のための処理においてＯＳ１１０２が利用するメモリ領域を確保する（ステップＳ６９）。そして、第１指示モジュール１１０６は、ステップＳ３において確保されたメモリ領域のアドレスを含むマスク指示をカーネル１１０３に出力する（ステップＳ７１）。
　カーネル１１０３は、第１指示モジュール１１０６からマスク指示を受信する（ステップＳ７３）。また、カーネル１１０３は、通知されたメモリ領域上で発生したエラーをＯＳ１１０２が看過するための設定を行う（ステップＳ７５）。
　また、第２指示モジュール１１０７は、マスク指示をハイパバイザ１３に出力する（ステップＳ７７）。
　ハイパバイザ１３は、第２指示モジュール１１０７からマスク指示を受信する（ステップＳ７９）。そして、ハイパバイザ１３における設定モジュール１３１は、診断モジュール１３２のためのメモリ領域（すなわち、診断モジュール１３２を実現するためのプログラムが配置されるメモリ領域）で発生したエラーを看過するための設定を行う（ステップＳ８１）。そして処理は端子Ａ及びＢを介して図８の処理に移行する。
　このような処理を実施することにより、ハイパバイザ１３における診断モジュール１３２に強制診断を行わせることができるようになる。
　また、第２の実施の形態における診断処理は、第１の実施の形態における診断処理とは異なっている。そこで、第２の実施の形態における診断処理について図１３を用いて説明する。
　まず、診断モジュール１３２は、診断要求において指定されている対象リソース名で割当テーブル１３３を検索することにより、対象リソースがいずれかの論理ドメインに割り当て済みであるか判断する（図１３：ステップＳ９１）。いずれの論理ドメインにも割り当てられていない場合（ステップＳ９１：Ｎｏルート）、対象リソースに対する診断を行っても問題は無いため、診断モジュール１３２は対象リソースに対する診断を行う（ステップＳ９３）。そして元の処理に戻る。
　なお、第１の形態と同様に、診断モジュール１３２はハードウェアリソースの診断に関する特別な権限を利用して、例えば対象リソースのレジスタにアクセスすることにより、対象リソースに対する診断を行う。
　一方、対象リソースがいずれかの論理ドメインに割り当てられている場合（ステップＳ９１：Ｙｅｓルート）、診断モジュール１３２は、割当テーブル１３３において未割り当てのハードウェアリソースが有るか判断する（ステップＳ９５）。未割り当てのハードウェアリソースが有ると判断された場合（ステップＳ９５：Ｙｅｓルート）、診断モジュール１３２は、当該未割り当てのリソースに対して診断を行う（ステップＳ９７）。
　そして、診断モジュール１３２は、診断結果が「正常」を示しているか判断する（ステップＳ９９）。診断結果が「正常」を示していない場合（ステップＳ９９：Ｎｏルート）、当該未割り当てリソースを論理ドメインに割り当てると論理ドメインに不具合が生じる可能性があるので、ステップＳ９５に戻る。
　一方、診断結果が「正常」を示している場合（ステップＳ９９：Ｙｅｓルート）、診断モジュール１３２は、当該未割り当てリソースを対象リソースの代わりに論理ドメインに割り当てる（ステップＳ１０１）。そして、診断モジュール１３２は、割り当てから解放された対象リソースに対する診断を行う（ステップＳ１０３）。そして元の処理に戻る。
　一方、未割り当てのハードウェアリソースが無いと判断された場合（ステップＳ９５：Ｎｏルート）、診断モジュール１３２は、診断定義テーブル１１０９において強制診断が有効になっているか判断する（ステップＳ１０５）。強制診断が有効ではない場合（ステップＳ１０５：Ｎｏルート）、対象リソースを割り当てから解放できず、診断を行うことができないため、元の処理に戻る。
　一方、強制診断が有効である場合（ステップＳ１０５：Ｙｅｓルート）、診断モジュール１３２は、割当テーブル１３３において割り当て済みであるハードウェアリソースを１つ特定し（ステップＳ１０７）、当該ハードウェアリソースに対して診断を行う（ステップＳ９７）。ステップＳ９９以降の処理は上で述べたとおりである。
　このような処理を実施すれば、対象リソースが論理ドメインに割り当て済みであり且つ未割り当てのハードウェアリソースが無いような場合、すなわち余剰のハードウェアリソースが少ないような場合においても、確実に診断を行うことができるようになる。
　以上本技術の一実施の形態を説明したが、本技術はこれに限定されるものではない。例えば、上で説明した情報処理装置１０００の構成は必ずしも実際のプログラムモジュール構成に対応するものではない。
　また、上で説明した処理フローは、処理結果が変わらなければ処理の順番を入れ替えることも可能である。さらに、並列に実行させるようにしても良い。
　なお、図５に示した管理テーブルにおいては、最終診断時刻を管理するような例を示したが、図１４に示すように、最後に診断を行ってから経過した時間（すなわち稼働時間）を管理するようにしてもよい。このような場合には、稼働時間が診断間隔を超えた場合に診断を行うようにすることで、ハードウェアリソースに対する定期的な診断を行えるようになる。
　また、第２の実施の形態では、ＯＳ１１０２における検出モジュール１１０５がステップＳ６５において強制診断が有効であるかを確認した際に、強制診断が有効であるか否かをハイパバイザ１３における診断モジュール１３２に通知するようにしてもよい。このようにすれば、診断モジュール１３２がステップＳ１０５において強制診断が有効であるかを判断しなくても済む。
　また、上で述べた例では、対象リソースがいずれかの論理ドメインに割り当て済みである場合に、他のハードウェアリソースを対象リソースの代わりに割り当てた後、対象リソースに対する診断を行っている。そして、対象リソースに対する診断の終了後に、対象リソースを論理ドメインに再度割り当てるようにはしていなかったが、対象リソースが故障していないのであれば、論理ドメインに再度割り当てるようにしてもよい。
　また、ステップＳ１７においては、第２指示モジュール１１０７からハイパバイザ１３に対して対象リソースの指定を通知するようにしているが、マスク指示を受信したカーネル１１０３が、ハイパバイザ１３に対して対象リソースの指定を通知するようにしてもよい。
　以上述べた本実施の形態をまとめると以下のようになる。
　本情報処理装置は、（Ａ）メモリと、（Ｂ）オペレーティングシステムを実行し、計算機として所定の機能を提供する論理ドメインと、前記論理ドメインの管理を行うハイパバイザとの処理を実行する処理装置（例えばプロセッサ）とを有する。そして、上記オペレーティングシステムが、（ｂ１－１）処理装置に実行されるときには、診断を行うべきハードウェアを検出する検出モジュールと、（ｂ１－２）処理装置に実行されるときには、検出モジュールにより診断を行うべきハードウェアが検出された場合、診断のための処理においてオペレーティングシステムが利用する、メモリにおけるメモリ領域を確保し、オペレーティングシステムのカーネルに対して、当該メモリ領域で発生したエラーを看過するように指示する第１指示モジュールと、（ｂ１－３）処理装置に実行されるときには、検出モジュールにより診断を行うべきハードウェアが検出された場合、ハイパバイザに対して、診断において利用する、メモリにおけるメモリ領域で発生したエラーを看過するように指示し且つ診断を行うべきハードウェアの指定を含む診断要求を出力する第２指示モジュールとを有する。そして、上記ハイパバイザが、（ｂ２－１）処理装置に実行されるときには、診断要求を受信した場合、診断モジュールが診断において利用する、メモリにおけるメモリ領域で発生したエラーを看過するための設定を行う設定モジュールと、（ｂ２－２）処理装置に実行されるときには、診断要求を受信した場合、診断を行うべきハードウェアに対して診断を行う診断モジュールとを有する。
　このような構成であれば、論理ドメインの稼動中であっても、オペレーティングシステム及びハイパバイザの処理に対して悪影響を及ぼすことなく、ハイパバイザによる適切なハードウェア診断を行えるようになる。なお、上で述べた処理装置は、例えばプロセッサと当該プロセッサにより実行されるプログラムとにより実現される。
　また、上で述べた診断モジュールが、（ｂ２－２１）処理装置に実行されるときには、診断を行うべきハードウェアがいずれかの論理ドメインに割り当てられている場合、情報処理装置が有するハードウェアのうちいずれの論理ドメインにも割り当てられていないハードウェアを、診断を行うべきハードウェアの代わりに割り当てた後、診断を行うべきハードウェアに対して診断を行うようにしてもよい。このようにすれば、診断を行うべきハードウェアが論理ドメインに割り当てられている場合であっても、論理ドメインの稼動を継続しつつ診断を行うことができるようになる。また、特定のハードウェアが論理ドメインに割り当てられ続けるような、ハードウェアの使用の偏りを防ぐことができるようになる。
　また、上で述べた診断モジュールが、（ｂ２－２２）処理装置に実行されるときには、情報処理装置が有するハードウェアのうちいずれの論理ドメインにも割り当てられていないハードウェアに対して診断を行い、当該診断の結果が正常である場合に、当該ハードウェアを診断を行うべきハードウェアの代わりに割り当てるようにしてもよい。このようにすれば、故障しているハードウェアを論理ドメインに割り当ててしまうことによる不具合の発生を防ぐことができる。
　また、上で述べた診断モジュールが、（ｂ２－２３）処理装置に実行されるときには、診断を行うべきハードウェアがいずれかの論理ドメインに割り当てられており且ついずれの論理ドメインにも割り当てられていないハードウェアが無い場合、診断方法を定義する定義データをテーブルから読み出し、強制診断が指定されているか判断し、強制診断が指定されていると判断した場合、既にいずれかの論理ドメインに割り当てられているハードウェアを、診断を行うべきハードウェアの代わりに割り当てるようにしてもよい。このようにすれば、余剰のハードウェアが少ないような場合においても、確実に診断を行うことができるようになる。
　また、上で述べた診断モジュールが、（ｂ２－２４）処理装置に実行されるときには、診断の結果をオペレーティングシステムに出力するようにしてもよい。そして、オペレーティングシステムが、（ｂ１－３）処理装置に実行されるときには、診断の結果が、診断が行われたハードウェアが故障していることを示している場合、当該故障を前記論理ドメインのユーザに通知するためのデータを生成する通知モジュールをさらに有するようにしてもよい。このようにすれば、ユーザが故障に対する対処を行うことができるようになる。
　また、上で述べた検出モジュールは、（ｂ１－１１）処理装置に実行されるときには、情報処理装置が有するハードウェアのうち、所定時間以上診断が行なわれていないハードウェアを検出するようにしてもよい。これにより、定期的な診断が行えるようになる。
　また、上で述べた検出モジュールは、（ｂ１－１２）処理装置に実行されるときには、情報処理装置が有するハードウェアのうち、所定時間以上診断が行なわれておらず且つ前回診断において正常であると診断されたハードウェアを検出するようにしてもよい。これにより、前回診断において故障があると診断されたハードウェアに対して再度診断を行ってしまう無駄を解消することができるようになる。
　また、ハイパバイザにより実現された論理ドメインのうちいずれか１つの論理ドメインに含まれるオペレーティングシステムが、検出モジュール、第１指示モジュール及び第２指示モジュールを有するようにしてもよい。これにより、ハードウェア診断を適切に管理できるようになる。
　本情報処理方法は、（Ｃ）診断を行うべきハードウェアを検出するステップと、（Ｄ）仮想的に実現されたシステムである論理ドメインに含まれるオペレーティングシステムが診断のための処理において利用するメモリ領域を確保し、オペレーティングシステムのカーネルに対して、当該メモリ領域で発生したエラーを看過するように指示するステップと、（Ｅ）論理ドメインを実現するためのハイパバイザに対して、診断において利用するメモリ領域で発生したエラーを看過するように指示し且つ診断を行うべきハードウェアの指定を含む診断要求を出力するステップとを含む。
　このようにすれば、論理ドメインの稼働中にハードウェアの診断を行ったとしても、オペレーティングシステム及びハイパバイザの処理に悪影響を及ぼすことがなくなる。
　本実施の形態の第２の態様に係る情報処理方法は、（Ｆ）ハードウェアの診断において利用するメモリ領域で発生したエラーを看過するように指示し且つ診断を行うべきハードウェアの指定を含む診断要求を、仮想的に実現されたシステムである論理ドメインに含まれるオペレーティングシステムから受信した場合、論理ドメインを実現するためのハイパバイザが診断において利用するメモリ領域で発生したエラーを看過するための設定を行うステップと、（Ｇ）診断を行うべきハードウェアに対して診断を行うステップとを含む。
　このようにすれば、ハイパバイザの処理に悪影響を及ぼすことなく、ハイパバイザによる適切なハードウェア診断を行えるようになる。
　なお、上記方法による処理をコンピュータに行わせるためのプログラムを作成することができ、当該プログラムは、例えばフレキシブルディスク、ＣＤ－ＲＯＭ、光磁気ディスク、半導体メモリ、ハードディスク等のコンピュータ読み取り可能な記憶媒体又は記憶装置に格納される。尚、中間的な処理結果はメインメモリ等の記憶装置に一時保管される。

Claims (11)

  1. 　メモリと、
    　オペレーティングシステムを実行し、計算機として所定の機能を提供する論理ドメインと、前記論理ドメインの管理を行うハイパバイザとの処理を実行する処理装置と、
    　を有し、
    　前記オペレーティングシステムが、
    　診断を行うべきハードウェアを検出する検出モジュールと、
    　前記検出モジュールにより前記診断を行うべきハードウェアが検出された場合、前記診断のための処理において前記オペレーティングシステムが利用する、前記メモリにおけるメモリ領域を確保し、前記オペレーティングシステムのカーネルに対して、当該メモリ領域で発生したエラーを看過するように指示する第１指示モジュールと、
    　前記検出モジュールにより前記診断を行うべきハードウェアが検出された場合、前記ハイパバイザに対して、前記診断において利用するメモリ領域で発生したエラーを看過するように指示し且つ前記診断を行うべきハードウェアの指定を含む診断要求を出力する第２指示モジュールと、
    　を有し、
    　前記ハイパバイザが、
    　前記診断要求を受信した場合、前記診断モジュールが前記診断において利用するメモリ領域で発生したエラーを看過するための設定を行う設定モジュールと、
    　前記診断要求を受信した場合、前記診断を行うべきハードウェアに対して前記診断を行う診断モジュールと、
    　を有する
    　情報処理装置。
  2. 　前記診断モジュールが、
    　前記診断を行うべきハードウェアがいずれかの論理ドメインに割り当てられている場合、前記情報処理装置が有するハードウェアのうちいずれの論理ドメインにも割り当てられていないハードウェアを、前記診断を行うべきハードウェアの代わりに割り当てた後、前記診断を行うべきハードウェアに対して前記診断を行う
    　請求項１記載の情報処理装置。
  3. 　前記診断モジュールが、
    　前記情報処理装置が有するハードウェアのうちいずれの論理ドメインにも割り当てられていないハードウェアに対して診断を行い、当該診断の結果が正常である場合に、当該ハードウェアを前記診断を行うべきハードウェアの代わりに割り当てる
    　請求項２記載の情報処理装置。
  4. 　前記診断モジュールが、
    　前記診断を行うべきハードウェアがいずれかの論理ドメインに割り当てられており且ついずれの論理ドメインにも割り当てられていないハードウェアが無い場合、診断方法を定義する定義データをテーブルから読み出し、強制診断が指定されているか判断し、
    　前記強制診断が指定されていると判断した場合、既にいずれかの論理ドメインに割り当てられているハードウェアを、前記診断を行うべきハードウェアの代わりに割り当てる
    　請求項１記載の情報処理装置。
  5. 　前記診断モジュールが、
    　前記診断の結果を前記オペレーティングシステムに出力し、
    　前記オペレーティングシステムが、
    　前記診断の結果が、前記診断が行われたハードウェアが故障していることを示している場合、当該故障を前記論理ドメインのユーザに通知するためのデータを生成する通知モジュール
    　をさらに有する
    　請求項１乃至４のいずれか１つ記載の情報処理装置。
  6. 　前記検出モジュールは、前記情報処理装置が有するハードウェアのうち、所定時間以上診断が行なわれていないハードウェアを検出する
    　請求項１乃至５のいずれか１つ記載の情報処理装置。
  7. 　前記検出モジュールは、前記情報処理装置が有するハードウェアのうち、所定時間以上診断が行なわれておらず且つ前回診断において正常であると診断されたハードウェアを検出する
    　請求項１乃至５のいずれか１つ記載の情報処理装置。
  8. 　前記ハイパバイザにより実現された論理ドメインのうちいずれか１つの論理ドメインに含まれるオペレーティングシステムが、前記検出モジュール、前記第１指示モジュール及び前記第２指示モジュールを有する
    　請求項１記載の情報処理装置。
  9. 　診断を行うべきハードウェアを検出し、
    　仮想的に実現されたシステムである論理ドメインに含まれるオペレーティングシステムが前記診断のための処理において利用するメモリ領域を確保し、前記オペレーティングシステムのカーネルに対して、当該メモリ領域で発生したエラーを看過するように指示し、
    　前記論理ドメインの管理を行うハイパバイザに対して、前記診断において利用するメモリ領域で発生したエラーを看過するように指示し且つ前記診断を行うべきハードウェアの指定を含む診断要求を出力する
    　処理を、コンピュータに実行させるためのプログラム。
  10. 　ハードウェアの診断において利用するメモリ領域で発生したエラーを看過するように指示し且つ前記診断を行うべきハードウェアの指定を含む診断要求を、仮想的に実現されたシステムである論理ドメインに含まれるオペレーティングシステムから受信した場合、前記論理ドメインの管理を行うハイパバイザが前記診断において利用するメモリ領域で発生したエラーを看過するための設定を行い、
    　前記診断を行うべきハードウェアに対して前記診断を行う
    　処理を、コンピュータに実行させるためのプログラム。
  11. 　診断を行うべきハードウェアを検出し、
    　仮想的に実現されたシステムである論理ドメインに含まれるオペレーティングシステムが前記診断のための処理において利用するメモリ領域を確保し、前記オペレーティングシステムのカーネルに対して、当該メモリ領域で発生したエラーを看過するように指示し、
    　前記論理ドメインの管理を行うハイパバイザが前記診断において利用するメモリ領域で発生したエラーを看過するための設定を行い、
    　前記診断を行うべきハードウェアに対して前記診断を行う
    　処理を、コンピュータが実行する情報処理方法。
PCT/JP2011/069755 2011-08-31 2011-08-31 情報処理装置及び方法、プログラム WO2013030976A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2013530954A JP5716830B2 (ja) 2011-08-31 2011-08-31 情報処理装置及び方法、プログラム
PCT/JP2011/069755 WO2013030976A1 (ja) 2011-08-31 2011-08-31 情報処理装置及び方法、プログラム
US14/171,822 US20140149795A1 (en) 2011-08-31 2014-02-04 Information processing apparatus and method relating to hardware diagnosis

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2011/069755 WO2013030976A1 (ja) 2011-08-31 2011-08-31 情報処理装置及び方法、プログラム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US14/171,822 Continuation US20140149795A1 (en) 2011-08-31 2014-02-04 Information processing apparatus and method relating to hardware diagnosis

Publications (1)

Publication Number Publication Date
WO2013030976A1 true WO2013030976A1 (ja) 2013-03-07

Family

ID=47755526

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2011/069755 WO2013030976A1 (ja) 2011-08-31 2011-08-31 情報処理装置及び方法、プログラム

Country Status (3)

Country Link
US (1) US20140149795A1 (ja)
JP (1) JP5716830B2 (ja)
WO (1) WO2013030976A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014203181A (ja) * 2013-04-03 2014-10-27 三菱電機株式会社 障害診断装置およびプログラム

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5786955B2 (ja) * 2011-11-28 2015-09-30 富士通株式会社 メモリ縮退方法及び情報処理装置
JP6033183B2 (ja) * 2013-07-31 2016-11-30 京セラドキュメントソリューションズ株式会社 画像形成装置、及び画像形成装置の起動方法
CN114911655A (zh) * 2017-12-19 2022-08-16 超聚变数字技术有限公司 一种自检方法和服务器
US11714736B2 (en) * 2020-07-30 2023-08-01 Micron Technology, Inc. Relative humidity sensor

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03252829A (ja) * 1990-03-02 1991-11-12 Fujitsu Ltd 仮想計算機のテスト方式
JP2002268912A (ja) * 2001-03-09 2002-09-20 Toshiba Corp ディジタル形保護制御装置およびプログラム
JP2009259108A (ja) * 2008-04-18 2009-11-05 Toshiba Corp 情報処理装置および情報処理装置の制御方法
WO2010061446A1 (ja) * 2008-11-27 2010-06-03 富士通株式会社 情報処理装置，処理部切換方法及び処理部切換プログラム

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH08305596A (ja) * 1995-04-28 1996-11-22 Fujitsu Ltd 仮想計算機システムおよびその試験方法
JP2006252429A (ja) * 2005-03-14 2006-09-21 Nec Corp コンピュータシステム、コンピュータシステムの診断方法およびコンピュータシステムの制御プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH03252829A (ja) * 1990-03-02 1991-11-12 Fujitsu Ltd 仮想計算機のテスト方式
JP2002268912A (ja) * 2001-03-09 2002-09-20 Toshiba Corp ディジタル形保護制御装置およびプログラム
JP2009259108A (ja) * 2008-04-18 2009-11-05 Toshiba Corp 情報処理装置および情報処理装置の制御方法
WO2010061446A1 (ja) * 2008-11-27 2010-06-03 富士通株式会社 情報処理装置，処理部切換方法及び処理部切換プログラム

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014203181A (ja) * 2013-04-03 2014-10-27 三菱電機株式会社 障害診断装置およびプログラム

Also Published As

Publication number Publication date
JPWO2013030976A1 (ja) 2015-03-23
JP5716830B2 (ja) 2015-05-13
US20140149795A1 (en) 2014-05-29

Similar Documents

Publication Publication Date Title
JP6530774B2 (ja) ハードウェア障害回復システム
JP5828348B2 (ja) 試験サーバ、情報処理システム、試験プログラムおよび試験方法
US8135985B2 (en) High availability support for virtual machines
US8713350B2 (en) Handling errors in a data processing system
US7574627B2 (en) Memory dump method, memory dump program and computer system
US8839032B2 (en) Managing errors in a data processing system
US9489274B2 (en) System and method for performing efficient failover and virtual machine (VM) migration in virtual desktop infrastructure (VDI)
JP4448878B2 (ja) 障害回復環境の設定方法
US7007192B2 (en) Information processing system, and method and program for controlling the same
US8219851B2 (en) System RAS protection for UMA style memory
US8782469B2 (en) Request processing system provided with multi-core processor
WO2006082657A1 (ja) マルチｃｐｕコンピュータおよびシステム再起動方法
US7984219B2 (en) Enhanced CPU RASUM feature in ISS servers
JP5716830B2 (ja) 情報処理装置及び方法、プログラム
JP2008140198A (ja) フェイルオーバ方法、およびその計算機システム。
WO2013188332A1 (en) Software handling of hardware error handling in hypervisor-based systems
KR20090081405A (ko) 파티션 유닛을 교체하는 방법 및 컴퓨터 판독가능 매체
JP2007133544A (ja) 障害情報解析方法及びその実施装置
US20050204199A1 (en) Automatic crash recovery in computer operating systems
US9250942B2 (en) Hardware emulation using on-the-fly virtualization
US11263083B1 (en) Method and apparatus for selective boot-up in computing devices
JP5842683B2 (ja) 情報処理装置、メモリダンププログラム及びメモリダンプ方法
KR20210155751A (ko) 스토리지 장치들의 충돌 복구에 대한 시스템, 방법 및 장치
JP2012181737A (ja) 計算機システム
JP6627366B2 (ja) 情報処理システム、情報処理方法およびプログラム

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: 11871768

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2013530954

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11871768

Country of ref document: EP

Kind code of ref document: A1