JP4999670B2 - Computer equipment - Google Patents

Description

  The present invention relates to a fault monitoring technique in a computer, and more particularly to a fault monitoring technique in a virtual machine.

Since the fault monitoring system in a computer has a one-to-one correspondence between a physical computer and an OS (Operating System), a fault monitoring agent deployed on each OS notifies the fault monitoring tool. Can do.
On the other hand, in the virtual machine environment, when a fault notification is made from each guest OS deployed on the virtual machine, problems such as a notice of a hardware fault of the physical machine from each guest OS occur.
For this reason, Patent Document 1 discloses a technology that can aggregate notifications from a single physical computer by performing aggregation using a specific integrated management agent.
In addition, testing for hardware failures and unexpected behaviors in computers is performed by artificially generating hardware failures by changing the actual hardware response using a device or software, as described in Patent Document 2. Based on the result, the business program is notified, and the operation for switching to the operation in which the failure has occurred can be confirmed.
JP 2002-229806 A JP 2002-351755 A

Since the virtual computer environment is an environment in which a plurality of OSs are virtually operated independently, a physical computer environment that has been deployed at a plurality of bases can be deployed on a single physical computer. . For this reason, each guest OS deployed on the virtual machine environment may be connected to an individual network.
For this reason, communication between guest OSs deployed on the same physical computer or between a guest OS and a host OS is not always performed, so there are physical and virtual communication paths on the network. It may not have been done.

  Further, there is a possibility that the guest OS may be added, and there is a problem that it is necessary to set information for communication to the host OS for collecting failure information every time the guest OS is added.

Furthermore, when a conventional computer system test method is executed on a virtual machine, it is necessary to collect each failure occurrence instruction and failure detection result on each network.
However, in the virtual machine environment, the host OS that has received a failure from the hardware detects the failure on the guest OS when processing the data on the host OS or by emulating and notifying the guest OS. There is a problem that it is difficult to know where the fault is actually detected by what means.
When a hardware failure occurs, depending on the type and location of the error, it is not detected on the host OS, but is detected as an error in response to a request from the guest OS or detected on the host OS. Because there is something that can be judged as a failure, it is not known by what means the failure is detected. For example, when a disk failure occurs, the guest OS is stopped when it is completely stopped. On the other hand, when a failure occurs in some area and the area is accessed, if it can be recognized as an error as a result of the access, it is detected by the guest OS. As described above, there are both cases where a hardware failure is detected by the host OS and cases where the hardware failure is detected by the guest OS.
This is not limited to the detection of a pseudo failure by a test, and the same applies to the detection of an actual failure.

Also, what I / O (Input / Output) is processed on the host OS and what I / O is emulated differs depending on the virtualization implementation method, so it is difficult to deal with them individually. is there.
In addition, since the information for identifying the guest OS is information uniquely owned by the virtual machine management mechanism (for example, domain ID (Identification Data)), the identification information such as the host name or IP (Internet Protocol) address is used to identify the guest OS. There is also a problem that it cannot be specified.

  One of the main objects of the present invention is to solve the above-described problems, and an object of the present invention is to provide a failure management method in which failure information from the guest OS is aggregated by the host OS.

  Another object of the present invention is to provide a test system that can cause a virtual failure to occur on a specific guest OS based on a user instruction.

The computer apparatus according to the present invention is:
A computer apparatus equipped with a virtual machine management mechanism for realizing a virtual machine, a host OS and one or more guest OSs operating on the virtual machine management mechanism, and having a storage area allocated to each guest OS,
Communication address information for notifying the communication address of the host OS is transmitted as a destination address of failure information for notifying a failure detected in each guest OS, and the host OS communication address is set. A first fault monitoring control unit for receiving fault information for notifying a fault;
The communication address information is received from the first failure monitoring control unit, the communication address of the host OS indicated in the received communication address information is stored in a storage area allocated to the corresponding guest OS, and the corresponding guest OS Failure information for notifying the detected failure when a failure is detected in the server, the communication address of the host OS stored in the storage area as a destination address, and the generated failure information as the first failure monitoring It has one or more 2nd failure monitoring control parts transmitted to a control part, It is characterized by the above-mentioned.

  According to the present invention, the first failure monitoring control unit transmits information on the communication address of the host OS to the second failure monitoring control unit corresponding to each guest OS, and the second failure monitoring corresponding to each guest OS. The control unit generates failure information for notifying a failure, and transmits the generated failure information to the first failure monitoring control unit based on the communication address of the host OS. It can be integrated into the fault monitoring control unit.

Embodiment 1 FIG.
In the present embodiment, in order for the host OS to collect information on the occurrence of a failure from the guest OS, it is possible to check the network configuration and to notify the guest OS of the information on the host OS that is the notification destination. A failure management method that aggregates information and makes it possible to grasp where and by what means a failure that can be detected in either the host OS or the guest OS will be described.

FIG. 1 is a configuration diagram for explaining a failure management method in a virtual machine environment according to the present embodiment.
As shown in the figure, the present embodiment includes a failure monitoring apparatus 1 and physical computers 2-1 to 2-n. The failure monitoring apparatus 1 and the host computers of the physical computers 2-1 to 2 -n are connected via the communication line 3, and the guest OS is assumed to be a virtual computer system connected via the communication line 4.
The physical computers 2-1 to 2-n are examples of computer devices.

  The failure monitoring device 1 is a terminal device into which a commercially available device installed in each system or a failure monitoring tool manufactured by the system is installed.

The physical computers 2-1 to 2-n are computers on which the virtual computer management mechanism 20 is mounted, and the host OS 22 and one or more guest OSs operate on the virtual computer management mechanism 20.
The host OS 22 emulates I / O of each guest OS.
The guest OS 23 executes application programs and the like.
The host OS 22 and guest OS 23 are connected by a virtual network 21.
The virtual machine management mechanism 20 is also called a virtual machine monitor.

  The communication lines 3 and 4 are networks such as an intranet and a LAN (Local Area Network), for example, and are mutually independent networks and cannot perform mutual communication.

On the host OS 22, a host failure monitoring control agent 221 that monitors an event that occurs when a failure occurs and acquires information is installed.
On the guest OS 23, a guest failure monitoring control agent 231 that monitors an event that occurs due to a failure and acquires information is installed.

In the host failure monitoring control agent 221, the IP address (communication address) of the host OS 22 is set.
The host failure monitoring and control agent 221 uses the IP address information of the host OS 22 as a destination address of failure information for notifying each guest OS 23 operating on the same virtual machine management mechanism 20 of a failure detected by each guest OS. The failure information is transmitted from each guest OS 23 operating on the same virtual machine management mechanism 20.
The host failure monitoring control agent 221 is an example of a first failure monitoring control unit.

The guest failure monitoring control agent 231 receives the IP address information of the host OS 22 from the host failure monitoring control agent 221, generates failure information for notifying the detected failure when the failure is detected, and sets the IP address of the host OS 22 The generated failure information is transmitted to the host failure monitoring control agent 221 as the destination address.
Further, the physical computer 2 has a physical storage area (not shown) of a memory allocated to the guest OS, and the guest fault monitoring control agent 231 receives the host OS IP address information and receives the host OS 22. Are stored in a storage area of a memory allocated to itself (guest OS). The guest fault monitoring control agent 231 recognizes the emulated virtual memory (file) as its own physical memory, and the guest fault monitoring control agent 231 stores the host OS in the storage area of the virtual memory allocated to itself. The IP address of the host OS 22 can be stored in the storage area of the physical memory allocated to itself via the host OS 22 and the virtual machine management mechanism 20.
Also, when transmitting failure information, the host OS 22 and the virtual machine management mechanism 20 are used to read the physical address of the host OS by reading the host OS IP address from the virtual memory storage area allocated to itself. The IP address of the host OS 22 can be read from the storage area of the memory.
The guest failure monitoring control agent 231 is an example of a second failure monitoring control unit.

With such a mechanism, each physical computer 2 collects the failure information transmission destinations of the guest failure monitoring control agents 231 in the host failure monitoring control agent 221.
The host failure monitoring control agent 221 adds the identification information of the host OS 22 to the failure information received from each guest failure monitoring control agent 231, and sends the failure information to which the identification information of the host OS 22 is added to the failure monitoring device 1. To send.

In the host failure monitoring control agent 221, 2211 is an IP notification unit that searches for the IP address of the guest OS 23 and notifies the guest OS 23 of the IP address information of the host OS 22.
Reference numeral 2212 denotes an information reception unit that receives failure occurrence information from the failure detection unit 2213 or the guest failure monitoring control agent 231.
Reference numeral 2213 denotes a failure detection unit that monitors an operation that occurs based on a failure that has occurred in the host OS 22 or the guest OS 23 and detects the occurrence of the failure.
A failure report unit 2214 converts the failure information of the guest OS from the information reception unit 2212 and the failure information of the host OS from the failure detection unit 2213 into information that can be analyzed by the failure monitoring apparatus 1 and performs notification.

In the guest failure monitoring control agent 231, 2311 is an IP receiving unit that receives the IP address information of the host OS 22 and enables the host OS 22 to report failure information based on the information.
Reference numeral 2312 denotes an information reception unit that receives failure occurrence information from the failure detection unit 2313.
Reference numeral 2313 denotes a failure detection unit that monitors an operation that occurs based on a failure that has occurred in the host OS 22 or the guest OS 23 and detects the occurrence of the failure.
A failure report unit 2314 notifies the host failure monitoring control agent 221 of failure information collected by the failure detection unit 2313.

2 and 3 are flowcharts showing processing operations of the failure management method in the virtual machine environment according to the first embodiment.
First, the operation of the host failure monitoring control agent 221 on the host OS 22 will be described with reference to FIG.

When the host failure monitoring control agent 221 is activated, the IP notification unit 2211 acquires the MAC (Media Access Control) address of the guest OS 23 from the information of the guest OS 23 provided by the virtual machine management mechanism 20, and an arp (Address Resolution Protocol) command. Etc., and an address list that can be taken by the network interface (Interface) of the host OS 22 is generated, network access is performed using ICMP (Internet Control Message Protocol) commands such as ping, and node arrival is confirmed. The correspondence information between the MAC address and the IP address is acquired (ST101).
That is, the host failure monitoring control agent 221 acquires the IP address of each guest OS 23 based on the association information between the domain ID of each guest OS 23 and the MAC address of each guest OS 23 provided from the virtual machine management mechanism 20. Information on the IP address of the host OS 22 is transmitted to each guest OS 23 using the acquired IP address of each guest OS 23.
For example, when the virtual machine management mechanism 20 is configured in accordance with Xen (registered trademark), the IP notification unit 2211 receives the MAC address information, the IP address, and the MAC address obtained as a result of the xm command prepared in Xen. Based on address correspondence information (output of the arp command), the correspondence is examined and derived.
In the case of Xen, the virtual machine management mechanism 20 manages the host OS and guest OS based on the concept of domain, and it is necessary to use identification information such as a domain name and a domain ID to identify a specific guest OS. . This information is managed inside the virtual machine management mechanism 20.
FIG. 16A shows an output example of the xm command, and FIG. 16B shows an output example of the arp command.
In the example of FIG. 16A, “mac 00: 16: 3e: 31: 4c: 2f” is shown as the MAC address of the guest OS of the domain ID: 1 (domid 1). In the example of FIG. The MAC address “00: 16: 3E: 31: 4C: 2F” and the IP address “192.168.1.100” are shown in the third line, and from these, the IP notification unit 2211 has the domain ID: 1. It detects that the IP address of the guest OS is “192.168.1.100”.

Next, the IP notification unit 2211 determines whether or not the corresponding IP address has been acquired from the correspondence information between the MAC address and the IP address and the MAC address information of the guest OS provided by the virtual machine management mechanism 20 (ST102). .
If the corresponding IP address can be acquired, the process proceeds to ST103. If not acquired, the process proceeds to ST107.

When the corresponding IP address can be acquired (YES in ST102), the IP notification unit 2211 notifies the guest OS 23 of the IP address of the host OS 22 using the acquired IP address information (ST103).
That is, the IP notification unit 2211 adds the acquired IP address of the guest OS 23 as a destination, and transmits a packet that notifies the IP address of the host OS 22 to the guest OS 23.

Next, the information reception unit 2212 waits for reception of failure information from the failure report unit 2314 of the guest failure monitoring control agent 231 or failure information from the failure detection unit 2213 (ST104).
Upon receiving the information, the failure report unit 2214 converts the information into information that can be analyzed by the failure monitoring tool of the failure monitoring apparatus 1 (ST105).
When the information conversion is completed, the failure report unit 2214 transmits the failure information to the failure monitoring tool of the failure monitoring apparatus 1 and waits for a failure notification to ST104 (ST106).

  If the corresponding IP address cannot be acquired (NO in ST102), it is determined that there is no network that can communicate between the host OS 22 and the guest OS 23, and the failure report unit 2214 informs the operator of the failure monitoring apparatus 1 Notify (output a message notifying that the network between the guest OS 23 and the host OS 22 is not set), and end (ST107).

  Next, the operation of the guest failure monitoring control agent 231 on the guest OS 23 will be described with reference to FIG.

When the guest failure monitoring control agent 231 is activated, the IP reception unit 2311 waits for reception of the IP address information of the host OS 22 from the host failure monitoring control agent 221. When the guest failure monitoring control agent 231 is received, the IP address information of the host OS 22 is sent to the failure reporting unit 2314. Notification is made (ST201).
The failure report unit 2314 performs the process of storing in the storage area of the virtual memory allocated to itself (guest OS 23), and thereby sets the IP address of the host OS 22 to itself through mediation between the virtual machine management mechanism 20 and the host OS 22. Store in the storage area of the allocated physical memory.

The information receiving unit 2312 receives the failure information acquired by the failure detecting unit 2313 (ST202).
Upon receiving the failure information, the failure report unit 2314 notifies the failure information to the host failure monitoring control agent 221 (ST203).
At this time, the IP address of the host OS 22 received from the host fault monitoring control agent 221 is added as a destination address to the fault information, and the fault reporting unit 2314 transmits the fault information to the host fault monitoring control agent 221.
The failure report unit 2314 reads the IP address of the host OS 22 from the storage area of the virtual memory allocated to itself (guest OS 23), thereby intermediating the virtual machine management mechanism 20 and the host OS 22 to The IP address is read from the storage area of the physical memory allocated to itself, and the IP address of the host OS 22 is added to the failure information.

For example, as shown in FIG. 17, a case is assumed where various servers that originally existed in different bases are aggregated.
FIG. 17 originally shows that the server A and the server B exist at the base 1 and the server A and the server B exist at the base 2, but these are reconstructed by a virtual machine and the physical computer 1 A guest OS equivalent to the server A of the base 1 and a guest OS equivalent to the server A of the base 2 are arranged, and a guest OS equivalent to the server B of the base 1 and a guest equivalent to the server B of the base 2 are placed on the physical computer 2 The state where OS is arranged is shown.
The host OS on the physical computer 1 and the guest OS (base 1 server A) are connected by a virtual network. Further, the host OS on the physical computer 1 and the guest OS (base 2 server A) are connected by a virtual network. However, since the guest OS (base 1 server A) and guest OS (base 2 server A) on the physical computer 1 are in different bases, they exist on the same physical computer. Not connected to each other.
The same applies to the physical computer 2.
On the other hand, the guest OS (base 1 server A) on the physical computer 1 and the guest OS (base 1 server B) on the physical computer 2 were originally located at the same base, so they are connected by a virtual network. Similarly, the guest OS (base 2 server A) on the physical computer 2 and the guest OS (base 2 server B) on the physical computer 2 were originally located at the same base, so they are connected by a virtual network.

In such a configuration, in this embodiment, the host OS of the physical computer 1 notifies the guest OS (base 1 server A) and the guest OS (base 2 server A) on the same physical computer 1 of the IP address, Fault information is received from the guest OS (base 1 server A) and the guest OS (base 2 server A), the fault information is aggregated, and the fault monitoring apparatus 1 is notified of the fault information.
Similarly, the host OS of the physical computer 2 notifies the guest OS (base 1 server B) and guest OS (base 2 server B) on the same physical computer 2 of the IP address, and the guest OS (base 1 server B). ) And the guest OS (base 2 server B), collect the failure information, and notify the failure monitoring apparatus 1 of the failure information.
For this reason, the failure monitoring apparatus 1 can collect failure information of all guest OSes regardless of the configuration of the physical computer and the configuration of the virtual network between the OSs.

As described above, according to the first embodiment, the guest OS is added due to the configuration that automatically corresponds to the configuration of the guest OS at the time of start-up and automatically passes the IP address information for communication. Even in this case, it is possible to automatically send and receive information.
Further, when the IP address information of the guest OS cannot be acquired on the host OS, it is possible to determine in advance that the network configuration that can be directly connected is not performed. It is possible to monitor faults after rebuilding the system.
In addition, since failure information can be aggregated on the host OS, even when the host OS and guest OS, or when the guest OS is connected to a network in a separate segment, failure indications and failures Information collection can be managed by a single failure monitoring tool.
In addition, since the occurrence and monitoring of the failure are performed in the host OS and the guest OS, the failure can be monitored without depending on the mounting method of the virtual machine management mechanism.

In this embodiment, a physical computer equipped with a virtual machine environment
A host fault monitoring and control agent is provided on the host OS, and a guest fault monitoring and control agent is provided on the guest OS.
The host failure monitoring control agent is
An IP notification unit that acquires an IP address based on MAC address information obtained from the domain ID information of the guest OS, performs communication using the acquired IP address, and notifies the IP address of the host OS;
An information receiving unit for receiving failure occurrence information from the guest failure monitoring control agent;
A fault detection unit that monitors the operation of the host OS or hardware and detects the occurrence of a fault;
A failure reporting unit for notifying a failure monitoring tool or the like of the detected failure information acquired by the failure detection unit or the information receiving unit;
The guest fault monitoring control agent is
An IP receiver that obtains the IP address information of the host OS and makes it available for notification of fault information;
A fault detection unit that monitors the operation of the guest OS and detects a fault occurrence;
A failure report unit for notifying the host failure control agent of the failure information acquired by the failure detection unit;
In the virtual machine environment, the failure notification destination of the guest failure monitoring control agent is automatically set to the host OS so that it can be notified so that only the host OS failure monitoring control agent can notify the failure monitoring tool. Thus, a fault management method in a virtual machine environment that notifies fault information in units of physical machines has been described.

In this embodiment, the host failure monitoring control agent acquires an IP address based on the MAC address information obtained from the domain ID information of the guest OS, performs communication using the acquired IP address, An IP notification unit for notifying the IP address of the host OS;
An IP receiver that obtains the IP address information of the host OS in the guest fault monitoring control agent and makes it available for notification of fault information;
A failure test system in a virtual machine environment that can detect a deficiency in automatic setting and network setting when a guest OS is added has been described.

Embodiment 2. FIG.
In the second embodiment, a mode in which host OS information is added to failure information will be described.
The operation of adding the host OS information to the failure information when the failure information is sent from the guest failure monitoring control agent 231 will be described with reference to FIGS. 4, 5, and 6.
FIG. 4 is an operation flow of the host OS according to the present embodiment.
FIG. 5 is an example of failure information when a failure is detected by the guest OS 23.
FIG. 6 is an example of failure information notified from the host OS 22 to the failure monitoring control manager 5.

In FIG. 4, ST101 to ST104 and ST107 are the same as those described in the first embodiment.
The guest failure monitoring control agent 231 transmits a message that detects a failure such as the example of FIG. 5 to the host OS 22. Only the information that can be acquired on the guest OS 23 is described as the failure information at this time, and information regarding the host OS 22 is not described.
When receiving the information, the information reception unit 2212 of the host OS 22 determines whether the failure information is from the failure detection unit 2213 or the failure information from the guest OS 23 (ST301).
In the case of failure information from the failure detection unit 2213, the process proceeds to ST105. In the case of failure information from the guest OS, the process moves to ST302.

In the case of failure information coming from the guest OS, the information receiving unit 2212 assigns host OS identification information (host name in this example) as in the example of FIG. 6 (ST302).
Subsequent ST105 and ST106 are the same as those described in the first embodiment.

As described above, according to the second embodiment, the identification information of the OS in which the failure is detected and the identification information of the host OS are set in the failure information. In addition, it is possible to grasp on which OS on the physical computer the information has been detected, and it is possible to easily grasp the behavior when a failure occurs.
In addition, since the host OS identification information is set on the host OS, the guest OS can set the host OS identification information in the failure information without knowing the host OS information. The guest fault monitoring control agent on the OS can operate independently.

  As described above, according to the present embodiment, when the information received by the information receiving unit on the host OS is failure information from the guest OS failure monitoring control agent, the host OS identification information is added to the received failure information. The fault management method in the virtual machine to be assigned has been described.

Embodiment 3 FIG.
In the third embodiment, a failure detection mode will be described.
7 and 8 are flowcharts showing processing operations of the failure management method in the virtual machine environment according to the third embodiment.
First, the operation of the failure detection unit 2213 on the host OS 22 will be described with reference to FIG.

The failure detection unit 2213 notifies the failure monitoring apparatus 1 that it is operating (ST401).
That is, the failure detection unit 2213 of the host failure monitoring control agent 221 transmits an operation notification (heartbeat) for notifying that the host OS 22 is operating to the failure monitoring apparatus at regular intervals.

In addition, the failure detection unit 2213 monitors the log, checks the content of the log generated after the previous check portion of the log file to be monitored, and logs the log of the specified keyword (for example, a character string such as ERROR). The presence or absence of occurrence is checked (ST402).
If no log of the specified keyword has occurred, the process moves to ST403. If it has occurred, the process moves to ST406.
Log monitoring in the host OS detects the failure of the host OS, the failure of the virtual machine management mechanism, and the hardware failure detected by the host OS by monitoring the log output by the host OS and the log output by the virtual machine management mechanism. The purpose is to do.

Next, the failure detection unit 2213 monitors the process, and checks the presence / absence of the process to be monitored by a ps command or the like (ST403).
If all the processes to be monitored are running, the process moves to ST404. If even one process to be monitored is not operating, the process moves to ST407.

Next, the failure detection unit 2213 checks the operation status of the HW by accessing the monitoring target HW (physical hardware) or accessing operation information monitored by the HW itself, such as IPMI (Intelligent Platform Management Interface). A check is made (ST404).
If the HW is operating normally, the process moves to ST405. If not operating normally, the process moves to ST408.

Next, the failure detection unit 2213 receives an operation notification from the guest OS 23 and checks whether or not operation notifications have been received from all the guest OSs 23 (ST405).
If all operation notifications have been received, the process moves to ST401. If there is a guest OS 23 for which an operation notification has not been transmitted, the process moves to ST409.

  In ST402, when the log of the specified keyword exists in the log file (YES in ST402), the failure detection unit 2213 sets the host OS information in the notification source identification information of the failure information, and the notification source host The host OS information is also set in the identification information, the detection time is set as the date and time information, the log monitoring is set as the monitoring target identification information, the detected log file name is set as the individual monitoring target information, and the problem is determined. Fault information in which the log contents are set in a message is generated and notified to the fault receiver. If there are a plurality of fault information, fault information is generated one by one and notified to the fault receiver (ST406).

  In ST403, when the process to be monitored is not operating (YES in ST403), the failure detection unit 2213 sets the host OS information in the notification source identification information of the failure information, and also in the notification source host identification information. Set the host OS information, set the detected time as date and time information, set process monitoring as monitoring target identification information, set nothing in the monitoring target individual information, and set the name of the process that is not running in the message The failure information is generated and notified to the failure receiver. If there are a plurality of pieces, failure information is generated one by one and notified to the failure receiving unit (ST407).

  In ST404, if there is a problem with the HW (YES in ST405), failure detection section 2213 sets the host OS information in the notification source identification information of the failure information, and also sets the host OS information in the notification source host identification information. Set the detected time as date and time information, set HW monitoring as monitoring target identification information, set the identification information of the hardware that had the problem in the monitoring target individual information, and describe the content of the problem in the message The set failure information is generated and notified to the failure receiving unit. When there are a plurality of pieces, failure information is generated one by one and notified to the failure receiving unit (ST408).

  In ST405, when a periodic operation notification from the guest OS has not been transmitted (YES in ST405), the failure detection unit 2213 sets the host OS information in the notification source identification information of the failure information, The host OS information is also set in the notification source host identification information, the detected time is set as the date and time information, the heartbeat monitoring is set as the monitoring target identification information, nothing is set in the monitoring target individual information, and the notification is made. Failure information in which guest OS information that has not been transmitted is set in a message is generated and notified to the failure receiving unit. If there are a plurality of fault information, fault information is generated one by one and notified to the fault receiver (ST409).

  The failure detection unit 2213 periodically repeats the above processing, and outputs a log output by the host OS 22, a log output by the virtual machine management mechanism 20, an operation status of a process in the host OS 22, an operation status of each guest OS 23, a physical hardware At least one of the operating status of the hardware is monitored at regular intervals, and when a failure is detected in any one of them, failure information for notifying the detected failure is generated, and the identification information of the host OS is added to the generated failure information Then, the failure information to which the identification information of the host OS is added is transmitted to the failure monitoring apparatus 1.

  Next, the operation of the failure detection unit 2313 on the guest OS 23 will be described with reference to FIG.

The failure detection unit 2313 notifies the host failure monitoring control agent 221 that it is operating (ST501).
Specifically, the failure detection unit 2313 transmits an operation notification (heartbeat) for notifying that the guest OS 23 is operating to the host failure monitoring control agent 221 at regular intervals.

Next, the failure detection unit 2313 monitors the log, checks the content of the log generated after the previous check portion of the log file to be monitored, and logs the specified keyword (for example, a character string such as ERROR). Is checked (ST502).
If no log for the specified keyword has occurred, the process moves to ST503. If it has occurred, the process moves to ST504.
The log monitoring in the guest OS 23 is intended to detect a failure of the application program by monitoring the log output by the application program operating on the guest OS 23, and by monitoring the log output by the guest OS 23. The purpose is to detect a failure of the guest OS 23 and a hardware failure detected by the guest OS.

Next, the failure detection unit 2313 monitors the process on the guest OS and the process of the application program running on the guest OS, and checks the presence / absence of the process to be monitored using a ps command or the like (ST503).
If all the monitoring target processes are operating, the process proceeds to ST401. If even one process to be monitored is not operating, the process moves to ST505.

  In ST502, when a log of the specified keyword exists in the log file (YES in ST502), the failure detection unit 2313 sets the information of the guest OS (self) in the notification source identification information of the failure information. Nothing is set in the notification source host identification information, the time detected as the date / time information is set, the log monitoring is set as the monitoring target identification information, the log file name detected as the monitoring target individual information is set, Fault information in which the content of the log determined to be a problem is set in a message is generated and notified to the fault receiver. If there are a plurality of pieces, failure information is generated one by one and notified to the failure receiving unit (ST504).

  In ST503, when the process to be monitored is not operating, the failure detection unit 2313 sets the information of the guest OS (self) in the notification source identification information of the failure information, and the notification source host identification information Nothing is set, the detected time is set as date and time information, process monitoring is set as monitoring target identification information, nothing is set in monitoring target individual information, and the name of the process that is not running is set in the message Fault information is generated and notified to the fault receiver. When there are a plurality of pieces, failure information is generated one by one and notified to the failure receiving unit (ST505).

  The failure detection unit 2313 periodically repeats the above-described process to output a log output by the corresponding guest OS, a log output by an application program operating on the corresponding guest OS, an operation status of the process in the corresponding guest OS, Monitor at least one of the operating statuses of processes in application programs running on the corresponding guest OS at regular intervals, and generate and generate failure information to notify the detected failure when any failure is detected The failure information is transmitted to the host failure monitoring control agent 221.

  As described above, in this embodiment, failure detection is performed by log monitoring, process monitoring, HW monitoring, and heartbeat monitoring, so that a failure of an application running on the guest OS can be monitored. Can be detected by log monitoring and heartbeat monitoring, the failure of the guest failure monitoring control agent can be detected by heartbeat monitoring, and the failure of the virtual machine management mechanism is It becomes possible to detect by heartbeat monitoring, and HW failures can be detected by HW monitoring or heartbeat monitoring, so that it is possible to detect failures of all the elements constituting the physical computer.

  In this embodiment, a failure in a virtual machine that makes it possible to grasp that the host OS is operating by notifying a failure monitoring tool or the like that the failure detection unit on the host OS is operating periodically. The management method was explained.

  Further, in this embodiment, it is possible to grasp that the guest OS is operating by notifying the failure detection unit on the host OS that the failure detection unit on the guest OS is regularly operating. The fault management method in the virtual machine to explain was explained.

  In the present embodiment, the failure detection unit on the host OS can periodically monitor the logs output from the OS and the virtual machine management mechanism to grasp the operating status of the host OS and the virtual machine management mechanism. The fault management method in the virtual machine is explained.

  In the present embodiment, the failure detection unit on the guest OS regularly monitors the logs output by the OS and applications, so that the failure in the virtual machine enables the operating status of the guest OS and applications to be grasped. The management method was explained.

  Further, in the present embodiment, the failure management method in the virtual machine has been described in which the operation status of the host OS can be grasped by monitoring the operation / non-operation of the process by the failure detection unit on the host OS.

  Further, in the present embodiment, the failure management method in the virtual machine has been described in which the operation status of the guest OS can be grasped by monitoring the operation / non-operation of the process by the failure detection unit on the guest OS.

  Further, in the present embodiment, the failure management method in the virtual machine has been described in which the failure detection unit can grasp the operation status of the hardware by periodically accessing the hardware.

Embodiment 4 FIG.
In this embodiment, a virtual fault is identified by automatically converting host name and IP address information recognized by the user into identification information such as a domain ID that the virtual machine management mechanism recognizes the guest OS. A test system that can be generated for the guest OS will be described.
In addition, the host OS collects fault setting instructions and results, and detects faults due to pseudo-faults that are detected by either the host OS or guest OS. Explains the test system that enables management of failure occurrence and confirmation without depending on the network environment of the guest OS and the location of the failure due to the virtualization implementation method by making it possible to grasp by what means it was detected To do.

FIG. 9 is a configuration diagram of the test system in the virtual machine environment according to the present embodiment.
As shown in the figure, the virtual machine environment test system includes a failure monitoring apparatus 1 including a failure monitoring control manager 5 and physical computers 2-1 to 2-n. The fault monitoring control manager 5 and the host OS of the physical computers 2-1 to 2-n are connected via the communication line 3, and the guest OS is connected via the communication line 4.

The fault monitoring control manager 5 generates display information in response to a screen display request such as a browser, fault information from the physical computers 2-1 to 2-n, an information receiving unit 51 that receives operation information, and a screen display request. Display unit 52, simulated fault occurrence control unit 53 that instructs the physical computers 2-1 to 2-n to issue a fault, and fault information and operation information collected from the physical computers 2-1 to 2-n. It is comprised from the operation information storage part 54 which implements | stores.
That is, the failure monitoring apparatus 1 transmits a simulated failure occurrence request for requesting the occurrence of a simulated failure to the physical computers 2-1 to 2-n, and the detection status of the simulated failure in the physical computers 2-1 to 2-n. To monitor.

The physical computers 2-1 to 2-n are computers equipped with the virtual computer management mechanism 20, and are equipped with a host OS 22 and a guest OS 23 that emulate I / O of each guest OS, and the host OS 22, The virtual network 21 is connected to the guest OS 23.
The communication lines 3 and 4 are networks such as an intranet and a LAN (Local Area Network), for example, and are mutually independent networks and cannot perform mutual communication.

  On the host OS 22, a host failure monitoring control agent 221 that monitors a failure occurrence instruction for a module or device that generates a pseudo failure and an event that occurs when the failure occurs and acquires information, and on the host OS A failure generation module 222 that generates a possible pseudo failure is mounted.

  On the guest OS 23, a guest fault monitoring control agent 231 that monitors a fault occurrence instruction for a module or device that generates a pseudo fault or an event that occurs when a fault occurs and acquires information, and a guest OS A failure generation module 232 that generates a possible pseudo failure is mounted.

The host failure monitoring control agent 221 receives the simulated failure occurrence request transmitted from the failure monitoring device 1, analyzes the content of the received simulated failure occurrence request, and determines the failure occurrence module of any OS based on the analysis result. It notifies to generate the simulated fault requested by the simulated fault occurrence request.
In other words, in the present embodiment, the reception of the pseudo failure occurrence request from the failure monitoring apparatus 1 is collected in the host failure monitoring control agent 221.

  The host failure monitoring control agent 221 is a simulated failure occurrence request including the communication address of the simulated failure target guest OS that is the target of the simulated failure, and the failure occurrence module of the host OS and the virtual machine management mechanism 20 cooperate. When receiving a simulated fault occurrence request that requests the occurrence of a simulated fault to be generated, the domain ID of the simulated fault target guest OS is acquired from the communication address of the simulated fault target guest OS, and the acquired pseudo fault target guest OS Is notified to the virtual machine management mechanism 20.

  Furthermore, the host failure monitoring control agent 221 is a simulated failure occurrence request including the IP address of the simulated failure target guest OS, and requests the occurrence of a simulated failure of the physical hardware allocated to the simulated failure target guest OS. When the virtual failure occurrence request is received, the domain ID of the simulated failure target guest OS is acquired from the IP address of the simulated failure target guest OS, and the acquired domain ID of the simulated failure target guest OS is notified to the virtual machine management mechanism 20 To do.

  Further, the failure occurrence module 222 of the host OS 22 generates at least one of a simulated failure of the host OS, a simulated failure of the virtual machine management mechanism 20, and a simulated failure of physical hardware not assigned to any guest OS 23.

  Further, when the host failure monitoring control agent 221 detects a pseudo failure generated by the failure occurrence module 222 of the host OS 22, the host failure monitoring control agent 221 generates failure information for notifying the detected pseudo failure, and the generated failure information of the host OS 22 is generated. The identification information is added, and the failure information to which the identification information of the host OS 22 is added is transmitted to the failure monitoring apparatus 1.

  The failure occurrence module 232 of each guest OS 23 generates at least one of a simulated failure of the corresponding guest OS 23 and a simulated failure of an application program operating on the corresponding guest OS 23.

  In addition, each guest fault monitoring control agent 231 generates fault information for notifying the detected pseudo fault when the fault fault generated by the fault occurrence module 232 of each guest OS 23 is detected, and the generated fault information is hosted. The failure information received from each guest failure monitoring control agent 231 is sent to the failure monitoring control agent 221, and the host failure monitoring control agent 221 adds the identification information of the host OS 22 to the failure information received from each guest failure monitoring control agent 231. Fault information is transmitted to the fault monitoring apparatus 1.

In the host failure monitoring control agent 221, 2211 is an IP notification unit that searches for the IP address of the guest OS 23 and notifies the guest OS 23 of the IP address information of the host OS 22.
Reference numeral 2212 denotes an information reception unit that receives failure occurrence information from the failure detection unit 2213 or the guest failure monitoring control agent 231 or a pseudo failure occurrence request from the failure monitoring control manager 5.
Reference numeral 2213 denotes a failure detection unit that monitors an operation that occurs based on a failure that has occurred in the host OS 22 or the guest OS 23 and detects the occurrence of the failure.
A failure report unit 2214 notifies the failure monitoring control manager 5 of failure information of the guest OS from the information reception unit 2212 and failure information of the host OS from the failure detection unit 2213.
2281 is a domain ID for converting the host name and IP address information for identifying the guest OS 23 into a domain ID that can be identified by the virtual machine management mechanism 20 when the failure monitoring control manager 5 is a pseudo failure occurrence instruction to the guest OS 23. It is a conversion unit.
2282, when the failure occurrence instruction from the failure monitoring control manager 5 is a failure generated by the failure occurrence module 222 on the host OS 22, the failure occurrence instruction is given to the failure occurrence module 222, and the failure occurrence on the guest OS 23 occurs. In the case of a failure that occurs in the module 232, the simulated failure control unit instructs the guest failure monitoring control agent 231 to generate a failure.

In the guest failure monitoring control agent 231, 2311 is an IP reception unit that receives the IP address information of the host OS and enables the host OS 22 to report the failure information based on the information.
Reference numeral 2312 denotes an information reception unit that receives failure occurrence information from the failure detection unit 2313 or a pseudo failure occurrence request from the host failure monitoring control agent 221.
Reference numeral 2313 denotes a failure detection unit that monitors an operation that occurs based on a failure that has occurred in the host OS 22 or the guest OS 23 and detects the occurrence of the failure.
A failure report unit 2314 notifies the host failure monitoring control agent 221 of failure information collected by the failure detection unit 2313.
Reference numeral 2381 denotes a simulated fault control unit that gives a fault occurrence instruction to the fault occurrence module 232.

10 and 11 are flowcharts showing processing operations of the test system in the virtual machine environment according to the fourth embodiment.
First, the operation of the host failure monitoring control agent 221 on the host OS 22 will be described with reference to FIG.

When the host failure monitoring control agent 221 is activated, the IP notification unit 2211 acquires the MAC address of the guest OS from the guest OS information provided by the virtual machine management mechanism 20, and uses the arp command or the network I / F that the host OS 22 has. A list of addresses that can be taken in is generated, network access is performed by ping or the like, and correspondence information between the MAC address and the IP address is acquired (ST101).
Next, the IP notification unit 2211 determines whether or not the corresponding IP address has been acquired from the correspondence information between the MAC address and the IP address and the MAC address information of the guest OS provided by the virtual machine management mechanism 20 (ST102). . If the corresponding IP address can be acquired, the process proceeds to ST103. If not acquired, the process proceeds to ST107.
When the corresponding IP address can be acquired (YES in ST102), the IP notification unit 2211 notifies the guest OS 23 using the IP address information acquired from the IP address of the host OS 22 (ST103).

Next, the information reception unit 2212 waits for reception of failure information from the failure report unit 2313 of the guest failure monitoring control agent 231, failure information from the failure detection unit 2214, or a pseudo failure occurrence request from the failure monitoring control manager 5. (ST104).
When receiving the information, information receiving section 2212 determines whether it is fault information or a pseudo fault occurrence request from fault monitoring control manager (ST601).
In the case of failure information, the process moves to ST301. In the case of a pseudo failure occurrence request, the process moves to ST602.

When the received information is a simulated failure occurrence request (YES in ST601), the simulated failure control unit 2282 is set for the failure occurrence module 222 on the host OS 22 or the failure occurrence module 232 on the guest OS 23. It is determined whether to set (ST602).
If it is set for the failure occurrence module 222 on the host OS 22 (YES in ST602), the process proceeds to ST603. If it is set for the failure occurrence module 232 on the guest OS 23 (NO in ST602), the process proceeds to ST606.

Next, the simulated failure control unit 2282 is assigned to a specific guest OS 23 (simulated failure target guest OS) in the case of a simulated failure occurrence request set for the failure occurrence module 222 on the host OS 22 (YES in ST602). It is determined whether the problem is related to a hardware failure such as a disk, or a failure related to hardware to which resources are not allocated, such as a fan or a power supply (ST603). A hardware simulated failure such as a disk allocated to a specific guest OS 23 (a simulated failure target guest OS) is a simulated failure generated by the failure generation module 222 of the host OS 22 and the virtual machine management mechanism 20 in cooperation. .
If the failure is related to the hardware assigned to the specific guest OS 23, the process moves to ST604. If it is related to a failure in hardware to which resources are not allocated, the process moves to ST605.

The domain ID conversion unit 2281 acquires MAC address information by an arp command or the like based on the host name or IP address information that specifies the guest OS 23 (pseudo failure target guest OS) specified in the simulated failure occurrence request, and the virtual machine The domain ID corresponding to the MAC address is acquired from the information of the guest OS 23 provided by the management mechanism 20 (ST604).
For example, the domain ID conversion unit 2281 uses the xm command output and the arp command output shown in the first embodiment, and reverses the domain of the pseudo-failure target guest OS in the procedure reverse to the procedure described in the first embodiment. Get an ID.

  Then, the simulated fault control unit 2282 instructs the fault occurrence module 222 to generate a simulated fault (ST605).

  If the setting is made for the failure occurrence module 232 on the guest OS 23 (NO in ST602), the simulated failure control unit 2282 instructs the failure occurrence to the guest failure monitoring control agent 231 of the simulated failure target guest OS 23. Is transmitted (ST606).

In ST601, when receiving the information (NO in ST601), the information reception unit 2212 determines whether the failure information is from the failure detection unit 2213 or the failure information from the guest OS 23 (ST301).
In the case of failure information from the failure detection unit 2213, the process moves to ST607. In the case of failure information from the guest OS, the process moves to ST302.

In the case of failure information coming from the guest OS (NO in ST301), the information receiving unit 2212 gives host OS identification information (host name in this example) as in the example of FIG. 6 (ST302).
If the received information is failure information from the failure detection unit 2213 or failure information from the guest failure monitoring control agent 231, the failure reporting unit 2214 transmits the received failure information to the failure monitoring control manager 5 (ST607). .

  If the corresponding IP address cannot be obtained in ST102 (NO in ST102), it is determined that there is no network that can communicate between the host OS 22 and the guest OS 23, and the failure report unit 2214 monitors the failure. The operator of the control manager 5 is notified (outputs a message notifying that the network between the guest OS 23 and the host OS 22 is not set), and the process ends (ST107).

  Next, the operation of the guest failure monitoring control agent 231 on the guest OS 23 will be described with reference to FIG.

  When the guest failure monitoring control agent 231 is activated, the IP reception unit 2311 waits for reception of the IP address information of the host OS 22 from the host failure monitoring control agent 221. When the guest failure monitoring control agent 231 is received, the IP address information of the host OS 22 is sent to the failure reporting unit 2314. Notification is made (ST201).

The information receiving unit 2312 receives the failure occurrence information acquired by the failure detection unit 2313 or the pseudo failure occurrence instruction from the host failure monitoring control agent (ST202).
Upon receiving the information, information receiving section 2312 determines whether the information is a simulated fault occurrence request or fault information reception (ST601).
In the case of a simulated fault occurrence request, the process moves to ST602. If the failure information is received, the process proceeds to ST203.

If the received information is a simulated fault occurrence request (YES in ST601), the simulated fault control unit 2381 implements the specified fault occurrence setting for the fault occurrence module 232 (ST602).
On the other hand, when failure information is received (NO in ST601), the failure report unit 2314 notifies the failure information to the host failure monitoring control agent 221 (ST203).

  If the fault occurrence module 222 or the fault occurrence module 232 generates a pseudo fault, the fault detection unit 2213 or the fault detection unit 2313 performs the procedure described in the third embodiment (the procedure illustrated in FIG. 7 or FIG. 8). ) Is detected, and failure information for reporting the simulated failure detected by the failure report unit 2214 or the failure report unit 2314 is generated.

As described above, according to the fourth embodiment, the pseudo-failure occurrence instruction and the failure information can be aggregated on the host OS. Even when connected to the network, it is possible to manage failure instruction and failure information collection with a single failure monitoring control manager.
In addition, since the failure and monitoring of the host OS and guest OS are performed, the test can be performed and confirmed without depending on the mounting method of the virtual machine management mechanism.
In addition, a configuration in which the virtual machine management mechanism recognizes the domain ID based on the host name or IP address of the guest OS specified on the host OS causes a pseudo failure on the guest OS on the host OS. Can be performed.
In addition, by making it possible to perform a hardware failure test by generating a simulated failure, a system running a hardware failure test on a physical computer, which was difficult to verify with a physical computer, can be virtualized. It can be implemented by installing it on a computer environment.

As described above, in the present embodiment, in a failure test system for performing a simulation of a failure on a physical computer equipped with a virtual computer environment and performing an operation verification when the failure occurs,
A fault monitoring control manager, a host fault monitoring control agent on the host OS, and a guest fault monitoring control agent on the guest OS,
The host failure monitoring control agent is
An information receiving unit for receiving a failure occurrence instruction from the failure monitoring control manager and receiving failure occurrence information from the guest failure monitoring control agent;
When the information acquired by the information receiving unit is a pseudo hardware failure occurrence instruction for the guest OS, the host name or IP address information for identifying the guest OS is converted into guest OS identification information that can be recognized by the virtual machine management mechanism A domain ID conversion unit,
A pseudo-fault control unit that issues a fault occurrence instruction to a fault occurrence module that generates a pseudo hardware fault based on the domain ID acquired by the domain ID conversion unit;
A fault detection unit that monitors an operation that occurs based on the fault set by the pseudo fault control unit and detects a fault occurrence;
A failure report unit for notifying the failure monitoring control manager of the detected failure information acquired by the failure detection unit or the information receiving unit;
The guest fault monitoring control agent is
An information receiving unit for receiving a failure occurrence instruction from the host failure monitoring control agent;
A simulated fault control unit that issues a fault occurrence instruction to a fault occurrence module that generates a pseudo fault based on information acquired by the information receiving unit;
A fault detection unit that monitors an operation that occurs based on the pseudo fault set in the pseudo fault control unit of the pseudo fault control unit or the host fault monitoring control agent, and detects a fault occurrence;
A failure report unit for notifying the host failure control agent of the failure information acquired by the failure detection unit;
By converting the IP address that identifies the guest OS into domain ID information that is identified by the virtualization management function and making it possible to set a pseudo fault, a pseudo fault occurs when there is a hardware access from the guest OS The fault test system in the virtual machine environment that made it possible was explained.

  Further, in the present embodiment, the failure test system in the virtual machine environment that enables the simulated failure control unit on the host OS to set the simulated host OS failure has been described.

  In the present embodiment, the fault test system in the virtual machine environment has been described that enables the pseudo fault control unit on the host OS to set the fault of the virtual virtual machine management mechanism.

  Further, in the present embodiment, the failure test system in the virtual machine environment has been described in which the simulated guest OS failure can be set by the simulated failure control unit on the guest OS.

  In the present embodiment, the failure test system in the virtual machine environment that enables the simulated failure control unit on the guest OS to set the simulated application failure has been described.

Embodiment 5 FIG.
In the fifth embodiment, the operation of the failure monitoring control manager 1 will be described.
FIG. 12 is an example of a screen displaying a host list.
FIG. 13 is an example of a screen for executing a simulated fault occurrence request.
FIG. 14 is an example of a screen displaying failure information occurring on each host.
FIG. 15 is a diagram illustrating an operation flow of the failure monitoring control manager 1.

The information receiving unit 51 waits for a display request from a user, a simulated fault occurrence request, or fault information or operation information from the physical computers 2-1 to 2-n by a browser or the like (ST801).
When the information is received, it is determined whether the information is a display request from the user, a pseudo failure occurrence request, or failure information or operation information from the physical computers 2-1 to 2-n (ST802).
In the case of a display request, the process moves to ST803. Otherwise, the process moves to ST805.

If the request is a display request from the user (YES in ST802), the display unit 52 generates display data based on the configuration information and failure information stored in the DB (Data Base).
In the case of a host list display request, the display unit 52 generates data for displaying the screen shown in FIG.
Further, in the case of a screen display request for making a simulated fault occurrence request, the display unit 52 generates data for displaying the screen shown in FIG.
Further, in the case of the request for displaying the failure occurrence status, the display unit 52 generates data for displaying the screen shown in FIG. 14 (ST803).
Then, display unit 12 returns the generated display data to the requesting browser or the like (ST804).

  If the display request is not a request in ST802 (NO in ST802), information receiving section 11 determines whether the received information is a pseudo-failure occurrence request, fault information, or operation information (ST805). In the case of a simulated fault occurrence request, the process moves to ST806. Otherwise, the process moves to ST807.

When a simulated fault occurrence request is received from the operator (YES in ST805), the simulated fault occurrence control unit 13 notifies the fault occurrence instruction to the host fault monitoring control agent 221 of the host OS 22 instructed (ST806).
On the other hand, when failure information or operation information is received from the host OS 22 of the physical computer 2 (NO in ST805), the operation information storage unit 14 stores the received data in the DB and receives a failure occurrence status display request. The contents can be displayed (ST807).

  As described above, the behavior of the host OS and guest OS on each physical computer when a failure occurs can be confirmed by configuring the failure monitoring control manager to centrally manage the pseudo failure occurrence instruction and the confirmation of the failure occurrence status. This makes it possible to proceed with the test smoothly.

In the description of the fault management method in the virtual machine environment, the host OS and guest OS are described. However, this is the case where a virtual machine management mechanism that does not explicitly use the host OS such as Xen is used. In this case, the failure management method described in this specification can be realized by regarding the Domain-0 that manages each domain as the host OS and configuring the other Domain-U as the guest OS.
Further, even in an environment where no OS such as special Domain-0 or host OS exists, the failure management method described in this specification can be realized by defining a representative virtual OS.

As described above, in the present embodiment, in the failure test system for performing a simulation of a failure on a physical computer equipped with a virtual computer environment and performing an operation verification when the failure occurs,
The fault monitoring control manager
A simulated fault occurrence control unit that instructs the host fault monitoring control agent to generate a simulated fault;
It has been described that an operation information collecting unit that collects operation information from the host failure monitoring control agent and displays the result is provided.

Finally, a hardware configuration example of the failure monitoring apparatus 1 and the physical computer 2 described in the first to fifth embodiments will be described.
FIG. 18 is a diagram illustrating an example of hardware resources of the failure monitoring apparatus 1 and the physical computer 2 described in the first to fifth embodiments.
The configuration in FIG. 18 is merely an example of the hardware configuration of the failure monitoring device 1 and the physical computer 2, and the hardware configuration of the failure monitoring device 1 and the physical computer 2 is limited to the configuration described in FIG. Alternatively, other configurations may be used.

In FIG. 18, the fault monitoring apparatus 1 and the physical computer 2 include a CPU 911 (also referred to as a central processing unit, a central processing unit, a processing unit, an arithmetic unit, a microprocessor, a microcomputer, and a processor) that executes a program.
The CPU 911 is connected to, for example, a ROM (Read Only Memory) 913, a RAM (Random Access Memory) 914, a communication board 915, a display device 901, a keyboard 902, a mouse 903, and a magnetic disk device 920 via a bus 912. Control hardware devices.
Further, the CPU 911 may be connected to an FDD 904 (Flexible Disk Drive), a compact disk device 905 (CDD), a printer device 906, and a scanner device 907. Further, instead of the magnetic disk device 920, a storage device such as an optical disk device or a memory card (registered trademark) read / write device may be used.
The RAM 914 is an example of a volatile memory. The storage media of the ROM 913, the FDD 904, the CDD 905, and the magnetic disk device 920 are an example of a nonvolatile memory. These are examples of the storage device.
A communication board 915, a keyboard 902, a mouse 903, a scanner device 907, an FDD 904, and the like are examples of input devices.
The communication board 915, the display device 901, the printer device 906, and the like are examples of output devices.

  The communication board 915 is connected to a network as shown in FIG. For example, the communication board 915 may be connected to a LAN (local area network), the Internet, a WAN (wide area network), or the like.

In FIG. 18, the contents of the magnetic disk device 920 show an example of a program for realizing the physical computer 2.
18 stores a virtual machine management mechanism 921 (virtual machine monitor), a host OS 922, a program group 923, and a file group 924.
The programs in the program group 923 are executed by the CPU 911, the virtual machine management mechanism 921, and the host OS 922.
In some cases, the virtual machine management mechanism 921 itself includes the function of the host OS 922, or the virtual machine management mechanism 921 exists in the host OS 922.
In the magnetic disk device 920 of the failure monitoring apparatus 1, for example, a normal OS and a window system are stored instead of the virtual machine management mechanism 921 and the host OS 922.

The ROM 913 stores a BIOS (Basic Input Output System) program, and the magnetic disk device 920 stores a boot program.
When the physical computer 2 is started, the BIOS program in the ROM 913 and the boot program for the magnetic disk device 920 are executed, and the virtual computer management mechanism 921 and the host OS 922 (OS in the fault monitoring device 1) are started by the BIOS program and the boot program. .

In the case of the physical computer 2, the program group 923 includes the guest OS shown in Embodiments 1 to 5 and programs that realize these internal elements. Specifically, the program group 923 stores a program for executing the function described as “˜unit” in the description of the first to fifth embodiments.
An application program executed by the guest OS is also stored.
In the failure monitoring apparatus 1, the program group 923 stores application programs such as a failure monitoring control manager.
The program is read and executed by the CPU 911.

In the case of the physical computer 2, the file group 924 includes various files for emulating hardware, for example.
Further, the file group 924 includes “determination of”, “calculation of”, “comparison of”, “conversion of”, “acquisition of”, “ Information, data, signal values, variable values, and parameters indicating the results of the processing described as “setting of”, “registration of”, “selection of”, etc. are stored in “~ file” or “˜database”. It is stored as each item.
The “˜file” and “˜database” are stored in a recording medium such as a disk or a memory. Information, data, signal values, variable values, and parameters stored in a storage medium such as a disk or memory are read out to the main memory or cache memory by the CPU 911 via a read / write circuit, and extracted, searched, referenced, compared, and calculated. Used for CPU operations such as calculation, processing, editing, output, printing, and display.
Information, data, signal values, variable values, and parameters are stored in the main memory, registers, cache memory, and buffers during the CPU operations of extraction, search, reference, comparison, calculation, processing, editing, output, printing, and display. It is temporarily stored in a memory or the like.
In addition, the arrows in the flowcharts described in the first to fifth embodiments mainly indicate input / output of data and signals. The data and signal values are the RAM 914 memory, the FDD 904 flexible disk, the CDD 905 compact disk, and the magnetic field. Recording is performed on a recording medium such as a magnetic disk of the disk device 920, other optical disks, mini disks, DVDs, and the like. Data and signals are transmitted online via a bus 912, signal lines, cables, or other transmission media.

  In addition, what is described as “˜unit” in the description of the first to fifth embodiments may be “˜circuit”, “˜device”, “˜device”, and “˜step”, It may be “˜procedure” or “˜processing”. That is, what is described as “˜unit” may be realized by firmware stored in the ROM 913. Alternatively, it may be implemented only by software, or only by hardware such as elements, devices, substrates, and wirings, by a combination of software and hardware, or by a combination of firmware. Firmware and software are stored as programs in a recording medium such as a magnetic disk, a flexible disk, an optical disk, a compact disk, a mini disk, and a DVD. The program is read by the CPU 911 and executed by the CPU 911. That is, the program causes the computer to function as “to part” in the first to fifth embodiments. Alternatively, the computer executes the procedure and method of “to part” in the first to fifth embodiments.

  As described above, the failure monitoring apparatus 1 and the physical computer 2 described in the first to fifth embodiments are output devices such as a CPU as a processing device, a memory as a storage device, a magnetic disk, a keyboard as an input device, a mouse, a communication board, and the like. The computer includes a display device, a communication board, and the like, and implements the functions indicated as “˜unit” using the processing device, the storage device, the input device, and the output device as described above.

FIG. 3 is a diagram illustrating an example of a system configuration according to the first embodiment. FIG. 3 is a flowchart showing an operation example of a host OS according to the first embodiment. FIG. 4 is a flowchart showing an example of operation of a guest OS according to the first embodiment. FIG. 9 is a flowchart showing an operation example of a host OS according to the second embodiment. FIG. 10 is a diagram illustrating an example of failure information transmitted from the guest OS to the host OS according to the second embodiment. FIG. 10 is a diagram illustrating an example of failure information transmitted from the host OS to the failure monitoring apparatus according to the second embodiment. FIG. 9 is a flowchart showing an operation example of a host OS according to the third embodiment. FIG. 9 is a flowchart showing an operation example of a guest OS according to the third embodiment. FIG. 10 is a diagram illustrating an example of a system configuration according to a fourth embodiment. FIG. 9 is a flowchart showing an operation example of a host OS according to the fourth embodiment. FIG. 10 is a flowchart showing an operation example of a guest OS according to the fourth embodiment. FIG. 10 is a diagram showing an example of a screen displaying a host list according to the fifth embodiment. FIG. 20 is a diagram showing an example of a screen for executing a simulated fault occurrence request according to the fifth embodiment. FIG. 10 is a diagram showing an example of a screen displaying failure information according to the fifth embodiment. FIG. 10 is a flowchart showing an operation example of a failure monitoring control manager according to the fifth embodiment. FIG. 6 is a diagram illustrating an output example of an xm command and an output example of an arp command according to the first embodiment. FIG. 3 is a diagram illustrating an example of server integration by the virtual machine according to the first embodiment. The figure which shows the hardware structural example of the failure monitoring apparatus which concerns on Embodiment 1-5, and a physical computer.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 Fault monitoring device, 2 Physical computer, 3 Communication line, 4 Communication line, 5 Fault monitoring control manager, 20 Virtual computer management mechanism, 21 Virtual network, 22 Host OS, 23 Guest OS, 51 Information receiving part, 52 Display part, 53 Pseudo fault occurrence control unit, 54 operation information storage unit, 221 host fault monitoring control agent, 222 fault occurrence module, 231 guest fault monitoring control agent, 232 fault occurrence module, 2211 IP notification unit, 2212 information receiving unit, 2213 fault detection Unit, 2214 fault report unit, 2281 domain ID conversion unit, 2282 simulated fault control unit, 2311 IP reception unit, 2312 information reception unit, 2313 fault detection unit, 2314 fault report unit, 2381 pseudo fault control unit.

Claims (17)

A computer apparatus having a virtual machine management mechanism for realizing a virtual machine, a host OS (Operating System) and at least one guest OS operating on the virtual machine management mechanism, and having a storage area allocated to each guest OS Because
Communication address information for notifying the communication address of the host OS is transmitted as a destination address of failure information for notifying a failure detected in each guest OS, and the host OS communication address is set. A first fault monitoring control unit for receiving fault information for notifying a fault;
The communication address information is received from the first failure monitoring control unit, the communication address of the host OS indicated in the received communication address information is stored in a storage area allocated to the corresponding guest OS, and the corresponding guest OS Failure information for notifying the detected failure when a failure is detected in the server, the communication address of the host OS stored in the storage area as a destination address, and the generated failure information as the first failure monitoring possess a second failure monitoring control unit one or more to be transmitted to the control unit,
The first fault monitoring and control unit
Based on the association information between the domain ID (Identification Data) of each guest OS provided by the virtual machine management mechanism and the MAC (Media Access Control) address of each guest OS, the IP (Internet Protocol) address of each guest OS is set. A computer characterized in that, using the acquired IP address of each guest OS, communication address information for notifying the IP address of the host OS is transmitted to a second failure monitoring control unit corresponding to each guest OS. apparatus. The first fault monitoring and control unit
2. The message according to claim 1 , wherein, when an IP address of any guest OS cannot be acquired, a message notifying that a network between the guest OS and the host OS is not set is output. Computer equipment. A virtual machine management mechanism that implements a virtual machine is mounted, and a host OS (Operating System) and one or more guest OSs operate on the virtual machine management mechanism, and a pseudo-failure occurrence request that requests the occurrence of a pseudo-failure is issued. A computer device connected to a fault monitoring device for transmission ,
A failure occurrence module of the host OS that generates a simulated failure in the host OS;
A guest OS failure module that generates a simulated failure in each guest OS;
The simulated fault occurrence request transmitted from the fault monitoring device is received, the content of the received simulated fault occurrence request is analyzed, and a request for a simulated fault occurrence request is issued to the fault occurrence module of any OS based on the analysis result. And a first failure monitoring control unit for notifying the occurrence of a simulated failure . The computer device is:
A storage area allocated to each guest OS;
The first fault monitoring and control unit
Communication address information for notifying the communication address of the host OS is transmitted as a destination address of failure information for notifying a failure detected in each guest OS, and the host OS communication address is set. Receive failure information to notify the failure,
The computer apparatus further includes:
The communication address information is received from the first failure monitoring control unit, the communication address of the host OS indicated in the received communication address information is stored in a storage area allocated to the corresponding guest OS, and the corresponding guest OS Failure information for notifying the detected failure when a failure is detected in the server, the communication address of the host OS stored in the storage area as a destination address, and the generated failure information as the first failure monitoring The computer apparatus according to claim 3, further comprising one or more second failure monitoring control units that transmit to the control unit. The computer device is:
5. The computer apparatus according to claim 3, wherein reception of pseudo fault occurrence requests from the fault monitoring apparatus is concentrated in a first fault monitoring control unit. The first fault monitoring and control unit
Generation of a pseudo failure that includes a communication address of a pseudo-failure target guest OS that is a target of the pseudo-failure, and is generated in cooperation between the failure generation module of the host OS and the virtual machine management mechanism Is received from the communication address of the simulated fault target guest OS, the domain ID of the simulated fault target guest OS is acquired, and the acquired domain ID of the simulated fault target guest OS is The computer apparatus according to claim 3 , wherein the computer management mechanism is notified. The first fault monitoring and control unit
When a pseudo failure occurrence request that includes the IP address of the simulated failure target guest OS and that requests the occurrence of a pseudo failure of the physical hardware assigned to the simulated failure target guest OS is received In addition, the domain ID of the simulated failure target guest OS is acquired from the IP address of the simulated failure target guest OS, and the acquired domain ID of the simulated failure target guest OS is notified to the virtual machine management mechanism. The computer apparatus according to claim 6 . The host OS failure occurrence module is:
4. The virtual machine management mechanism according to claim 3 , wherein at least one of a simulated failure of the host OS, a simulated failure of the virtual machine management mechanism, and a simulated failure of physical hardware not assigned to any guest OS is generated. Computer equipment. The first fault monitoring and control unit
When a pseudo fault generated by the fault occurrence module of the host OS is detected, fault information for notifying the detected pseudo fault is generated, identification information of the host OS is added to the generated fault information, and 4. The computer apparatus according to claim 3 , wherein the fault information to which the identification information of the host OS is added is transmitted to the fault monitoring apparatus. The failure occurrence module of each guest OS is
The computer apparatus according to claim 3 , wherein at least one of a pseudo failure of a corresponding guest OS and a pseudo failure of an application program operating on the corresponding guest OS is generated. The second fault monitoring controller
When a simulated fault generated by the corresponding guest OS fault occurrence module is detected, fault information for notifying the detected pseudo fault is generated, and the generated fault information is sent to the first fault monitoring controller. Send
The first fault monitoring and control unit
The host OS identification information is added to the fault information received from the second fault monitoring control unit, and the fault information with the host OS identification information added is transmitted to the fault monitoring apparatus. The computer apparatus according to claim 4 . The computer device is:
Computer apparatus according to claim 1 or 4, characterized in that it aggregates the destination of the fault information by the second fault monitor control unit to the first failure monitoring control unit. The computer device is:
Connected to a fault monitoring device that monitors faults,
The first fault monitoring and control unit
The host OS identification information is added to the fault information received from the second fault monitoring control unit, and the fault information with the host OS identification information added is transmitted to the fault monitoring apparatus. The computer apparatus according to claim 1 or 4 . The first fault monitoring and control unit
Monitor at least one of the log output by the host OS, the log output by the virtual machine management mechanism, the process operating status of the host OS, the operating status of each guest OS, and the operating status of physical hardware at regular intervals. Then, failure information for notifying a failure in any one of them is generated, the identification information of the host OS is added to the generated failure information, and the failure information to which the identification information of the host OS is added is sent to the failure monitoring apparatus. The computer apparatus according to claim 13 , which transmits the computer apparatus. The first fault monitoring and control unit
The computer apparatus according to claim 13 or 14 , wherein an operation notification for notifying that the host OS is operating is transmitted to the failure monitoring apparatus at regular intervals. The second fault monitoring controller
The log output by the corresponding guest OS, the log output by the application program operating on the corresponding guest OS, the process operating status of the corresponding guest OS, and the process operating status of the application program operating on the corresponding guest OS monitoring at least one of every predetermined period and generates the fault information for notifying a failure in either the generated fault information claim 1 or and transmitting to the first failure monitoring control unit 4. The computer apparatus according to 4 . The second fault monitoring controller
The guest OS to run notification for notifying that running at constant intervals, computing device according to claim 1 or 4, characterized in that transmitted to the first failure monitoring control unit.

Images