JP2006039763A - Guest OS debugging support method and virtual machine manager - Google Patents

Abstract

An unprecedented excellent debugging environment for a guest OS is realized, and it is possible to provide support for more effective debugging.
A VMM (virtual machine manager) constructs a second virtual machine execution environment different from the first virtual machine execution environment in which the first guest OS operates (S2). The VMM copies the first guest OS to the second virtual machine execution environment by including the execution state of the first guest OS and the state of the memory used by the first guest OS. A second guest OS, which is a copy of one guest OS, is generated in the second virtual machine execution environment (S3). At this time, the VMM stops the second guest OS generated in the second virtual machine execution environment and saves the state of the second guest OS.
[Selection] Figure 3

Description

  The present invention relates to a guest OS debugging support method and a virtual machine manager suitable for supporting debugging of a guest OS executed in a virtual machine system.

  In recent years, in a computer system such as a personal computer, an application (application program) for realizing a virtual machine system (hereinafter referred to as a VM system) has been used. Such an application is called a VM (Virtual Machine) application.

  A computer system (real computer system) is generally configured by hardware (HW) such as a real processor, various I / O devices (input / output devices), and a memory (not shown). On the hardware configuration of this computer system, an OS called a host OS operates. Various applications are executed on the host OS. One of these applications is the VM application. By executing this VM application, a virtual machine manager (hereinafter referred to as VMM) for managing the VM system is realized. The VMM realizes a virtual HW including a virtual processor, a virtual I / O device, and a virtual memory device. The VMM emulates these virtual processors, virtual I / O devices, and virtual memory devices to realize a virtual machine execution environment. In this virtual machine execution environment, an OS called a guest OS operates.

  As described above, the VMM can construct a virtual computer execution environment (virtual computer execution environment) in a general computer system and execute the guest OS therein. Here, the VMM is implemented as one application (VM application) that operates on the OS. In addition, a configuration is also known in which a VMM is implemented as a VMM mechanism (virtual computer support mechanism as a HW) on a real HW of a computer system. This VM mechanism also virtualizes real processors and real I / O devices and provides them as functions to each guest OS. On the VM mechanism, a virtual machine execution environment is constructed by the VM mechanism.

In the above-described VM system, the guest OS usually behaves as if it operates on the real HW of the computer. As a result, if there is a problem with the guest OS, the guest OS panics (crashes). As described above, when the guest OS panics (crashes), that is, when a failure occurs in the guest OS, the guest OS is stopped in the conventional VM system. In this case, the VMM generally saves the operating state when the guest OS in which the failure has occurred, that is, the execution image of the guest OS, as a dump in an external storage device (see, for example, Patent Document 1). In this Patent Document 1, it is proposed that another guest OS in a standby state takes over execution of a service provided by a guest OS in which a failure has occurred using an execution image stored in an external storage device. ing.
JP-A-9-288590 (paragraph 0012, paragraphs 0021 to 0030)

  As described above, when a guest OS operating in a conventional VM system (virtual computer system) has some trouble and the guest OS is stopped, an execution image of the guest OS at that time is dumped as an external storage device. It is common to be saved to. Thus, it is conceivable to debug the guest OS using a dump saved in the external storage device. It is also possible to debug a guest OS by simulating a guest OS failure, intentionally stopping the guest OS, and saving the execution image of the guest OS at that time as a dump in an external storage device. It is done.

  However, both are static debugs of the guest OS in a stopped state, and cannot be effective debugs. Moreover, when the guest OS is stopped and the service provided by the guest OS is handed over to another guest OS that is in a standby state, the takeover generally takes a certain amount of time. Even) service is interrupted.

  The present invention has been made in consideration of the above circumstances, and an object of the present invention is to provide a guest OS debugging support method capable of realizing a superior debugging environment for a guest OS that can be debugged more effectively. To provide a virtual machine manager.

  According to one aspect of the present invention, a guest OS debugging support method for supporting debugging of a guest OS operating in a virtual machine execution environment provided by a virtual machine manager (VMM) is provided. The method includes the step of the virtual machine manager constructing a second virtual machine execution environment different from the first virtual machine execution environment in which the first guest OS operates, and the virtual machine manager includes the first virtual machine execution environment By copying the guest OS to the second virtual machine execution environment, including the execution state of the first guest OS and the state of the memory used by the first guest OS, the first guest OS Generating a second guest OS that is a copy of the second virtual machine execution environment in the second virtual machine execution environment, and stopping the second guest OS generated in the second virtual machine execution environment Storing the state of the guest OS.

  In such a configuration, the first guest OS operating in the first virtual machine execution environment includes the execution state of the first guest OS and the state of the memory used by the first guest OS. The virtual machine manager copies it to the second virtual machine execution environment. As a result, a second guest OS that is a copy of the first guest OS is generated in the second virtual machine execution environment. The second guest OS generated in the second virtual machine execution environment is stopped by the virtual machine manager. Thereby, the state at the time of copying of the first guest OS is saved as the state of the second guest OS.

  As described above, in the above-described configuration, since the state at the time of copying the first guest OS is saved as the state of the second guest OS using the function of the virtual machine manager, the second guest OS is saved. By setting the OS as a debugging target, an environment (debug environment) for debugging the first guest OS can be realized without stopping the first guest OS.

  Here, if the first guest OS is not executed before the second guest OS (a copy of the first guest OS) is generated, the state of the first guest OS at that time is set to the second guest OS. Can be reliably saved as a guest OS. Also, if the first guest OS is made executable after the second guest OS is generated, the first guest OS itself debugs the state at the time of copying the first guest OS by the debugger ( Analysis). Of course, a guest OS other than the first guest OS in the operating state can debug (analyze) the state at the time of copying the first guest OS.

  Here, the generation of the second guest OS (a copy of the first guest OS) may be configured to be performed by the virtual machine manager in response to a request from the first guest OS. It is also possible to adopt a configuration performed in the above. Further, in order for the virtual machine manager to autonomously generate the second guest OS (a copy of the first guest OS), the virtual machine manager monitors the first guest OS, and the first guest OS It is good to detect abnormalities. That is, when the virtual machine manager detects an abnormality in the first guest OS, a second guest OS (a copy of the first guest OS) may be generated.

  In addition, the generation of the second guest OS (a copy of the first guest OS) is performed at a predetermined time interval until an abnormality of the first guest OS is detected. It is also possible to adopt a configuration in which the second virtual computer execution environment to be executed is switched while being switched within a range of a certain number of second virtual computer execution environments. In this configuration, since the states of the first guest OSs of multiple generations can be saved at all times, when an abnormality occurs in the first guest OS, the first guest OSs of the multiple generations immediately before the occurrence of the abnormality are stored. By setting the state as a debug (analysis) target, it is possible to pursue not only the state at the time of occurrence of an abnormality (problem) but also the cause by going back in time. This is an advantage that cannot be obtained with a conventional debugger (debug environment), and the user can effectively pursue the cause of the problem by using this environment.

  According to the present invention, the state of the guest OS (first guest OS) operating in the virtual machine execution environment (first virtual machine execution environment) is supported with the support of the virtual machine manager (VMM). Since it can be saved as a guest OS (second guest OS) on another new virtual machine execution environment (second virtual machine execution environment), the saved guest OS (second guest OS) Can be realized without stopping the original guest OS (first guest OS) (that is, stopping the service). Even if the external storage device for dumping cannot be used, instead of taking a dump by constructing a new second virtual machine execution environment and storing a copy of the first guest OS there Can be an important clue to problem analysis. In addition, by leaving a virtual machine execution environment in which the state of the guest OSs of several generations before the problem occurs is saved, it becomes possible not only to find the state at the time of the problem but also to investigate the cause by going back in time.

Hereinafter, an embodiment of the present invention will be described with reference to the drawings.
FIG. 1 is a block diagram showing the configuration of a computer system 1 that implements a virtual computer system according to an embodiment of the present invention. The computer system 1 includes hardware (HW) 10 that constitutes a real computer. As is well known, the HW 10 includes a real processor 11, various I / O devices (input / output devices) 12, and a memory (not shown). On the HW 10, an OS 20 called a host OS operates. Various applications including a virtual machine application (VM application) 30 are executed on the OS (host OS) 20.

  By executing the VM application 30, a virtual machine manager (hereinafter referred to as VMM) 31 is realized. The VMM 31 constructs an environment (virtual machine execution environment) of a virtual machine system (VM system). FIG. 1 shows an example in which two virtual machine execution environments 32-1 (VM # 1) and 32-2 (VM # 2) are constructed. The virtual machine execution environment 32-i (i = 1, 2) includes a virtual HW environment (virtual HW device) 33-i and a guest OS execution environment 34-i. The virtual HW environment 33-i includes a virtual processor 331-i, a virtual I / O device 332-i, and a virtual memory device (not shown). The VMM 31 logically emulates the virtual processor 331-i, the virtual I / O device 332-i, and the virtual memory device in the virtual HW environment 33-i to generate a virtual computer execution environment 32-i (VM # i) is realized. The VMM 31 loads the guest OS execution environment 34-i in the virtual machine execution environment 32-i (VM # i) with the OS operating in the guest OS execution environment 34-i as the guest OS 340-i (#i). . The VMM 31 expands the code of the guest OS 340-i (#i) in a virtual memory device included in the virtual HW environment 34-i, and executes the execution code in the form of emulation of the virtual processor 331-i. As a result, the VMM 31 advances the processing of the guest OS 340-i (#i). An I / O request from the guest OS 340-i (#i) is processed by the VMM 31 emulating the virtual I / O device 332-i. The guest OS 340-i (#i) has a copy request function for requesting the VMM 31 to copy (duplicate) its own state. The VMM 31 has a guest OS copy function that generates a copy of the guest OS 340-i (#i) in response to a copy request from the guest OS 340-i (#i).

Next, copy processing for supporting debugging of the guest OS in the present embodiment will be described with reference to a diagram showing an outline of the operation in FIG. 2 and a flowchart in FIG.
First, as shown in FIG. 2, it is assumed that the guest OS 340-1 (# 1) is running on the virtual machine execution environment 32-1 (VM # 1). At the same time, it is assumed that the guest OS 340-2 (# 2) is running on the virtual machine execution environment 32-2 (VM # 2). The guest OSs # 1 (340-1) and # 2 (340-2) include a copy request unit 341 that requests the VMM 31 to copy (copy) its own state. The VMM 31 includes a guest OS copy unit 311 that generates a copy of the guest OS # i (guest OS # 1 ′) in response to a copy request from the copy request unit 341 of the guest OS # i (340-i). Yes. The guest OS copy unit 311 includes a guest OS start / stop unit 311a. The guest OS start / stop unit 311a has a function for setting the guest OS # i to a state where it is not executed (stopped state) and a function for setting the guest OS # i which is not executed (stopped state) to be executable. Have. The guest OS start / stop unit 311a may be provided independently of the guest OS copy unit 311.

  Now, with the guest OSs # 1 and # 2 running on the VMs # 1 and # 2, respectively, the copy request unit 341 of the guest OS # 1 sends the VMM 31 as indicated by the arrow 21 in FIG. Assume that a copy request for requesting a copy (duplication) of the state of the guest OS # 1 itself is sent.

As described above, the copy request is sent from the copy request unit 341 of the guest OS # 1, for example, in the following two cases:
(1) When guest OS # 1 itself senses an abnormal condition inside it, and it becomes necessary to analyze its current condition
(2) Like the UNIX (registered trademark) OS, the internal status is inconsistent and the system is called panic, and the process cannot be continued. This is a case where it is necessary to prepare for the analysis.

  For example, in a general-purpose OS, when an abnormality is detected internally, a function “assert ()” is called (case (1)). For example, when a debugger is connected to the OS, this function can transfer control to the debugger and analyze the status of the corresponding OS. In some implementations, the function “panic ()” described below is called when the debugger cannot be used.

  On the other hand, when a contradiction occurs in the OS and the process cannot be continued, a function called “panic ()” is called (case (2)). This function allows an error to be displayed on the terminal to notify the user of the occurrence of a serious error. This function also allows a memory dump to be recorded in an external storage device. Thereafter, the system can be stopped or the OS can be rebooted.

  In this embodiment, the copy request unit 341 of the guest OS # 1 can send a copy request to the VMM 31 when the state corresponds to the above-described case (1) or (2). Here, it is assumed that, as a result of the guest OS # 1 being in the state corresponding to case (1), a copy request is sent from the copy request unit 341 of the guest OS # 1 to the VMM 31. When the VMM 31 receives the copy request, it performs the processing shown in the flowchart of FIG. 3 as follows.

  First, the guest OS copy unit 311 of the VMM 31 uses the guest OS start / stop unit 311a to make the copy request source guest OS # 1 unexecutable (stopped), and the internal state of the guest OS # 1 changes. (Step S1). Next, the guest OS copy unit 311 newly constructs a virtual machine execution environment 32-3 (VM # 3) in the virtual machine system using the virtual machine execution environment construction function (step S2). It is possible to make the means (virtual machine execution environment construction unit) having this virtual machine execution environment construction function independent from the guest OS copy unit 311.

  Next, the guest OS copy unit 311 enters the state of the copy request source guest OS # 1 that is not executed (stopped) in the new virtual machine execution environment 32-3 (VM # 3) (execution of the guest OS # 1) The state and the state of all memories used by the guest OS # 1) are copied (step S3). That is, the guest OS copy unit 311 constructs a virtual machine execution environment 32-3 (VM # 3) as shown by an arrow 22 in FIG. Copy the state of # 1 (340-1). As a result, a guest OS # 1 '(340-3) having the same structure as the copy request source guest OS # 1 (340-1) is generated in the virtual machine execution environment 32-3 (VM # 3).

  When the guest OS copy unit 311 of the VMM 31 performs the copy in step S3, that is, generates the guest OS # 1 ′ that is a copy of the guest OS # 1, the guest OS start / stop unit 311a is used to generate the guest OS # 1. 1 'is set to the stop state. After executing step S3, the guest OS copy unit 311 uses the guest OS start / stop unit 311a to make the copy request source guest OS # 1 executable and ends the process (step S4).

  As described above, in this embodiment, in response to a copy request from the guest OS # 1 to the VMM 31, the guest OS copy unit 311 of the VMM 31 causes the guest OS # 1 ′ having the completely same structure as the guest OS # 1 to be a virtual machine. It is generated in the execution environment 32-3 (VM # 1), and the guest OS # 1 ′ is set in a stopped state. This guest OS # 1 'has exactly the same memory data and execution state as the copy requesting guest OS # 1 requested to copy. Therefore, by analyzing this guest OS # 1 ', the state of the guest OS # 1 at that moment can be examined in detail.

  In the present embodiment, the guest OS # 1 is set to a state in which it is not temporarily executed only at the time of copying, but is set to an executable state when the copying is completed. Therefore, the guest OS # 1 can resume the process immediately after the copy is completed. Therefore, in this embodiment, the guest OS # 1 is a copy of the guest OS # 1 by sending a copy request to the VMM 31 at the moment when the situation desired to be analyzed occurs, for example, while continuing the service. The guest OS # 1 ′ is constructed by the VMM 31, the state of the guest OS # 1 at that moment is saved, and the guest OS # 1 ′ can be analyzed (debugged) at an arbitrary time point thereafter. In this case, the critical moment can be debugged without stopping the guest OS # 1. As shown by the arrow 23 in FIG. 2, the debugging for the guest OS # 1 ′ can be performed by the guest OS # 1 itself or by a guest OS other than the guest OS # 1, for example, the arrow 24 in FIG. As shown, guest OS # 2 can also do. Here, the guest OS # 1 ′ is a copy of the guest OS # 1. Therefore, in the present embodiment, the state of the guest OS # 1 at the moment of analysis can be analyzed without stopping the operation of the guest OS # 1.

  Even when a copy request from the guest OS # 1 to the VMM 31 is sent in a state corresponding to the above case (2), the virtual machine execution environment 32-3 is generated by the procedure shown in the flowchart of FIG. Thus, the state when the guest OS # 1 panics in the environment 32-3 is stored as the guest OS # 1 ′. Even in this case, the guest OS # 1 ′ can be debugged from the guest OS # 2. Further, if the guest OS # 1 is rebooted after the copying is completed, the guest OS # 1 ′ can be debugged from the guest OS # 1 after the reboot. In this embodiment, for example, even when a large capacity external device is not connected and a dump cannot be left in an embedded system, the panic state can be saved as the guest OS # 1 ′ using the memory. Then, by analyzing the guest OS # 1 ′ at an arbitrary time point thereafter, the guest OS # 1 can be analyzed equivalently.

  In the above embodiment, it is assumed that a copy request is sent from the guest OS # 1. However, it goes without saying that the same operation is performed when a copy request is sent from a guest OS other than the guest OS # 1, such as the guest OS # 2.

[First Modification]
In the above embodiment, when the guest OS # 1 enters a state corresponding to the case (1) or (2), the copy process by the VMM31 is performed in response to a copy request sent from the guest OS # 1 to the VMM31. Is executed. However, it is also possible to adopt a configuration in which the VMM 31 itself detects the above state and the VMM 31 autonomously performs a copy process.

  Therefore, even if a copy request is not sent from the guest OS # 1, the VMM 31 can autonomously perform copy processing when the guest OS # 1 is abnormal. This will be described with reference to the drawings.

  FIG. 4 is a diagram corresponding to FIG. In FIG. 4, elements equivalent to those in FIG. As shown in FIG. 4, a guest OS response monitoring unit 312 is added to the VMM 31 to monitor whether an arbitrary guest OS # i (340-i) is operating normally. On the other hand, in response to the guest OSs # 1 (340-1) and # 2 (340-2), response units 342 are provided instead of the copy request unit 341 (see FIG. 2).

  The response unit 342 is configured to notify the VMM 31 of a response at least once within a predetermined period. The guest OS response monitoring unit 312 monitors the response from the response unit 342 of each guest OS #i, and when the response is notified at least once within a predetermined period, “the guest OS #i is operating normally. Recognizes. The response unit 342 is realized, for example, when the guest OS # i calls a special VMM call for calling the VMM 31 within a predetermined time. This special VMM call is, for example, an interface provided by the VMM 31 that can be used by the guest OS # i, which is prepared for the guest OS # i to use the service of the VMM31. In addition to this, a shared variable (a memory area that can be referred to by both the guest OS # i and the VMM 31) between the VMM 31 and the guest OS # i is provided, and the response unit 342 of the guest OS # i increments the value at a constant cycle. And may be changed. In this case, the guest OS response monitoring unit 312 of the VMM 31 determines that the VMM 31 is “guest OS # i response” due to a change in the value of the shared variable, and when the value of the shared variable has not been updated for a certain time or more. It can be determined that the guest OS # i is abnormal.

Next, a copy process for supporting debugging of the guest OS in the first modification will be described with reference to the flowchart of FIG. 5 in addition to FIG.
The guest OS response monitoring unit 312 of the VMM 31 monitors whether there is a response within a certain period from the guest OSs to be monitored, for example, the response units 342 of the guest OSs # 1 and # 2 (step S11). If a guest OS # i that does not respond within a certain period is detected, the guest OS response monitoring unit 312 of the VMM 31 determines an abnormality of the guest OS # i. Here, it is assumed that the guest OS # 1 is determined to be abnormal. In this case, the guest OS response monitoring unit 312 notifies the guest OS copy unit 311 of the abnormality of the guest OS # 1 as indicated by the arrow 41 in FIG.

  Then, similarly to step S1, the guest OS copy unit 311 uses the guest OS start / stop unit 311a to put the guest OS # 1 into a state where it is not executed (stopped state) (step S12). Next, the guest OS copy unit 311 constructs a new virtual machine execution environment VM # 3 in the virtual machine system, similarly to step S2 (step S13). Then, the guest OS copy unit 311 copies the state of the guest OS # 1 in the stopped state to the virtual machine execution environment VM # 3 as in step S3 (step S14). That is, the guest OS copy unit 311 constructs a virtual machine execution environment 32-3 (VM # 3) as shown by an arrow 42 in FIG. Copy the state of # 1. In step S14, the guest OS start / stop unit 311a in the guest OS copy unit 311 puts the copy of the guest OS # 1, that is, the guest OS # 1 'into a stopped state. When the guest OS start / stop unit 311a stops the copy of the guest OS # 1 (guest OS # 1 ′), as shown by an arrow 43 in FIG. 4, the guest OS # 1 (that is, the guest OS response monitoring unit) The guest OS # 1) determined to be abnormal by 312 is forcibly rebooted (step S15).

  As described above, according to the first modification, the guest OS # 1 hangs due to a problem inside the guest OS # 1, and the response unit 342 of the guest OS # 1 responds to the VMM 31 within a certain period. Is detected, the guest OS response monitoring unit 312 of the VMM 31 detects the abnormal state. Then, the state of the guest OS # 1 is copied and stored as a copy of the guest OS # 1 (guest OS # 1 ') in the VM # 3 newly constructed by the guest OS copy unit 311 of the VMM31. On the other hand, the guest OS # 1 is forcibly rebooted by the VMM 31. As a result, the guest OS # 1 can resume necessary processing such as service again after rebooting. Further, the guest OS # 1 can be analyzed with a debugger or a dedicated tool in a state where the stored copy of the guest OS # 1 is a target. That is, the guest OS # 1 can analyze the problem of the guest OS # 1 while continuing the service of the guest OS # 1. Also in the first modification, as in the above embodiment, in a system that does not have a mechanism for leaving a dump, the problem occurs while the state in which the problem has occurred is stored in memory as a copy of the guest OS # 1. The guest OS # 1 can be rebooted. That is, information for problem analysis can be left simultaneously with the continuation of the service of guest OS # 1. The analysis may be performed by the guest OS # 1 itself after rebooting as indicated by an arrow 44 in FIG. 4 or an OS other than the guest OS # 1, for example, as indicated by an arrow 45 in FIG. It is also possible for OS # 2.

  In the first modified example, it is assumed that an abnormality of the guest OS # 1 is detected. However, it goes without saying that the same operation is performed when an abnormality of a guest OS other than the guest OS # 1, such as the guest OS # 2, is detected.

[Second Modification]
In the first modification of the above embodiment, the guest OS response monitoring unit 312 of the VMM 31 monitors the response from the response unit 342 of the guest OS #i, and an abnormality of the guest OS #i is detected from the monitoring result. In this case, a configuration is employed in which the guest OS copy unit 311 of the VMM 31 generates a copy of the guest OS # i. However, regardless of the state of the guest OS # i, it is also possible to generate a copy of the guest OS # i in chronological order at regular intervals and save the latest fixed number of copies.

  Therefore, a second modification of the above embodiment in which a copy of the guest OS # i is generated at regular intervals and the latest fixed number of copies is stored in the virtual machine execution environment will be described with reference to the drawings. I will explain.

  FIG. 6 is a diagram corresponding to FIG. In FIG. 6, elements equivalent to those in FIG. FIG. 6 shows guest OS # 1 (k-1) and guest OS # 1 as three guest OSs 340-4, 340-5 and 340-6, which are copies of guest OS 340-1 (guest OS # 1). The state where (k) and guest OS # 1 (k + 1) are generated by the guest OS copy unit 311 of the VMM 31 is shown. Here, k−1, k, k + 1 (k is an integer of 1 or more) represents a copy generation. That is, FIG. 6 shows three guests, which are copies of the guest OS # 1, in the order of time points t (k−1), t (k), and t (k + 1), as indicated by arrows 61, 62, and 63. A state in which OS # 1 (k-1), guest OS # 1 (k), and guest OS # 1 (k + 1) are generated is shown.

  There are limited system resources such as memory that can be used to store a copy of guest OS # 1. For this reason, the number of storable guest OS # 1 copies allowed for the system is limited. In the example of FIG. 6, there are three storable guest OS # 1 copies. Therefore, at the next time point t (k + 2), the guest OS # 1 (k-1) which is the oldest copy at that time is deleted, and the guest OS # 1 (k + 2) is created instead.

  In FIG. 6, the virtual machine execution environment in which three guest OS # 1 (k−1), guest OS # 1 (k), and guest OS # 1 (k + 1), which are copies of guest OS # 1, are generated. The guest OS # 2 is omitted.

  Next, copying of the guest OS in the second modification will be described with reference to the flowchart of FIG. 7 in addition to FIG. Here, in order to simplify the description, it is assumed that only the guest OS # 1 is to be copied.

  The guest OS copy unit 311 of the VMM 31 determines whether the guest OS # 1 to be copied is abnormal at regular intervals (steps S21 and S22). A method for determining whether the guest OS # 1 is abnormal will be described later. If the guest OS # 1 is not abnormal, the guest OS copy unit 311 determines whether a copy of the guest OS # 1 has already been stored in the memory for three generations (step S23). If a copy of guest OS # 1 has not yet been saved for three generations, the guest OS copy unit 311 executes guest OS # 1 through steps S25 to S27 similar to steps S1 to S3 in the above embodiment. After the status is not changed (stopped), a copy of the guest OS # 1 is generated in the virtual machine execution environment, and the copy is put in the stopped state. Then, the guest OS copy unit 311 makes the guest OS # 1 executable (step S28).

  The guest OS copy unit 311 keeps the copy of the guest OS # 1 for three generations already (step S23), unless the guest OS # 1 becomes abnormal (step S22), at regular intervals (step S21). ), Steps S25 to S28 are repeated. Then, as shown in FIG. 6, a copy of the guest OS # 1 is generated for three generations of the guest OS # 1 (k-1), the guest OS # 1 (k), and the guest OS # 1 (k + 1), and the memory Shall be stored in In this state, when the guest OS # 1 (k + 2) that is the next copy of the guest OS # 1 needs to be generated, the guest OS copy unit 311 first has the oldest guest OS # 1 (k−1) at that time. ) Is deleted (step S24). Thereafter, the guest OS copy unit 311 generates guest OS # 1 (k + 2), which is the latest copy of guest OS # 1, through steps S25 to S27.

In this way, as long as the guest OS # 1 is normal (step S22), the latest three generation copies of the guest OS # 1 are always left. Here, consider a case where the processing of the guest OS # 1 is stopped due to an abnormality such as a panic. The guest OS copy unit 311 needs to detect the occurrence of an abnormality in the guest OS # 1. As a method for the guest OS copy unit 311 to detect an abnormality in the guest OS # 1, for example, the following method, that is,
(1) A method in which the guest OS # 1 calls a special VMM call when an abnormality occurs and notifies the VMM 31 of the abnormality occurrence
(2) A method of determining an abnormality of the guest OS # 1 (using the response unit 342 in the guest OS # 1 and the guest OS response monitoring unit 312 in the VMM31) applied in the first modified example. Is applicable.

  When the guest OS copy unit 311 detects an abnormality in the guest OS # 1 (step S22), the guest OS copy unit 311 does not make a new copy of the guest OS # 1 thereafter. As a result, the guest OS # 1 can be analyzed by using the three-generation copy of the guest OS # 1 that is already stored when the abnormality of the guest OS # 1 is detected. If the guest OS # 1 abnormality is detected after the guest OS # 1 (k + 1) is generated and stored, the time t (k−1) immediately before the guest OS # 1 abnormality is detected. ), T (k), and t (k + 1) are stored in guest OS # 1 (k-1), guest OS # 1 (k), and guest OS # 1 (k + 1), respectively. ing. The user uses a debugger or an analyzer for these three copies of the guest OS # 1 in the same manner as in the first modification, and the guest OS # 1 such as the guest OS # 1 or guest OS # 2. A guest OS other than 1 can analyze the problem of the guest OS # 1. As the number of guest OS copies that can be saved at a time increases, the state at the point in time that comes back from the time of the problem can be observed, so it is possible to obtain a clue to know what happened when. There is sex. This is an advantage not found in conventional debugging techniques.

  It is also possible to reproduce what happens by advancing the state of the stored guest OS # 1 with a debugger (eg, step execution). In this case, for example, in order to examine the situation from the guest OS # 1 (k + 1) to the occurrence of the problem, a new copy of the guest OS # 1 (k + 1) is made in advance, and the guest OS # 1 (k + 1) of the new copy is created. ) Should be advanced. In this way, it is possible to proceed with analysis from the context at the time of guest OS # 1 (k + 1) any number of times.

[Third Modification]
Next, in addition to generating a copy of the guest OS # 1 in chronological order and storing a fixed number, the I / O (input / output) history for each guest OS is also stored. A third modification will be described with reference to the drawings.

  FIG. 8 is a diagram corresponding to FIG. In FIG. 8, elements equivalent to those in FIG. In FIG. 8, in addition to the state where three guest OS # 1 (k-1), guest OS # 1 (k), and guest OS # 1 (k + 1), which are copies of guest OS # 1, are generated, In the VMM 31, there are an I / O history buffer 313 and three I / O history buffers 313 (k−1), 313 (k), and 313 (k + 1) that are copies of the I / O history buffer 313. It is shown. In FIG. 8, as in FIG. 6, the virtual machine execution environment in which the guest OS # 1 (k−1), guest OS # 1 (k), and guest OS # 1 (k + 1) are generated, and the guest OS # 2 is omitted.

  The I / O history buffer 313 is used to record an I / O history (I / O history) for each fixed period in the guest OS # 1. Here, as shown by an arrow 71 in FIG. 7, when an I / O event of the guest OS # 1 occurs, that is, the VMM 31 performs virtual I / O device 332-1 for I / O of the guest OS # 1. , The virtual I / O device 332-1 records the I / O history (log) of the guest OS # 1 in the I / O history buffer 313 as indicated by the arrow 72 in FIG. Is done. The I / O history buffer 313 is arranged on the memory. That is, the I / O history is recorded as a data string on the memory.

In the I / O history buffer 313, for example, the following format (log record)
"I / O event occurrence time, I / O device type, event type, input / output data"
Then, an I / O log is recorded. “Event type” includes “interrupt occurrence” and “DMA start / completion”. In this embodiment, when an I / O event involving data input / output occurs, the data is recorded as much as possible. Here, input / output data of a certain size or less is recorded. In the I / O history buffer 313, the above log records are recorded in chronological order.

  The guest OS copy unit 311 performs the same procedure as in the second modified example, and at the time points t (k−1), t (k), and t (k + 1), the arrows 73-1 and 73-2 in FIG. As shown in FIG. 73-3, when the guest OS # 1 (k-1), the guest OS # 1 (k), and the guest OS # 1 (k + 1), which are copies of the guest OS # 1, are generated in order, 7, I / O history buffers 313 (k−1), 313 (k) and 313 (k + 1), which are copies of the I / O history buffer 313, as indicated by arrows 74-1, 74-2 and 74-3. ). Here, the I / O history buffer 313 is cleared each time a copy of the I / O history buffer 313 is generated. Therefore, for example, the I / O history buffer 313 (k) stores the time t (k), that is, the guest OS # 1 (from the time when the time point t (k-1), that is, the guest OS # 1 (k-1) is generated. The I / O history of the guest OS # 1 generated up to the generation of k) is recorded. Similarly, in the I / O history buffer 313 (k + 1), the generation of the time point t (k + 1), that is, the guest OS # 1 (k + 1) from the time point t (k), that is, the generation time of the guest OS # 1 (k). The I / O history of guest OS # 1 that has occurred up to that time is recorded. The I / O history buffers 313, 313 (k-1), 313 (k), and 313 (k + 1) can be referred to by the user by inquiring the VMM 31 from the guest OS, for example, the guest OS # 1 debugger. It is like that.

  Next, debugging of the guest OS # 1 performed using a copy of the I / O history buffer 313 in addition to the copy of the guest OS # 1 will be described. For example, if a bug exists in the driver, the state may become abnormal with the I / O processing. Now, as indicated by an arrow 75 in FIG. 7, guest OS # 1 (k-1) and guest OS # 1 (k) (that is, two copy images (k-1) and (k) of guest OS # 1) Is analyzed by the debugger of guest OS # 1, and it is assumed that the guest OS # 1 (k) has already confirmed the effect of the bug. Further, it is assumed that the guest OS # 1 (k-1) has not yet seen the effect of the bug. In this case, there is a bug between guest OS # 1 (k-1) and guest OS # 1 (k), that is, between two copy images (k-1) and (k) of guest OS # 1. Conceivable.

  Therefore, there are cases where it is desired to know an I / O event that has occurred between the copy images (k-1) and (k) of the guest OS # 1. In this case, as indicated by an arrow 76 in FIG. 7, it is possible to confirm what I / O event has occurred by referring to the I / O history buffer 313 (k) by the debugger of the guest OS # 1. it can. That is, the I / O history buffer 313 (k) can be used as information for analysis of the guest OS # 1.

  Further, if the debugger of guest OS # 1 proceeds from the guest OS # 1 (k-1) state gradually by, for example, step execution, and examines the change in state, observe the moment of occurrence of the bug. May be able to. However, for that purpose, all events related to the guest OS # 1 that occurred between the time of generation of the guest OS (k-1) and the time of generation of the guest OS # 1 (k), including I / O. Must be reproducible. Regarding the processing of the processor, since the virtual processor 331-1 provided by the VMM 31 only executes the instruction sequence, there is no problem in reproducing the processing. On the other hand, regarding I / O, the virtual I / O device 332-1 needs to generate an I / O event.

  Therefore, in the third modification, the virtual I / O device 332-1 refers to the I / O history buffer, and the I / O event recorded therein is converted into the I / O event. It is configured to reproduce at the time recorded in the history buffer. In this way, the state of the guest OS # 1 including I / O can be reproduced, and the state of the guest OS # 1 can be reproduced in more detail.

For example, when the guest OS # 1 (k-1) is targeted for debugging and the state change of the guest OS # 1 is examined while the state is advanced, the virtual I / O as shown by the arrow 77 in FIG. The device 332-1 refers to the I / O history buffer 313 (k), and faithfully reproduces the I / O event when reproducing the process of the guest OS # 1. The reason for referring to the I / O history buffer 313 (k) is that the I / O history buffer 313 (k) has the following guest OS # 1 (k) from the time when the guest OS # 1 (k-1) is generated. This is because the I / O history of the guest OS # 1 that has occurred until the time of generation is recorded.
As described above, in the third modified example, the situation up to the occurrence of an abnormality including I / O can be reproduced, so that the analysis of the problem can be further facilitated.

  In the above embodiment, it is assumed that the VMM 31 is mounted as one application (VM application) that operates on the OS 20. However, the present invention is similarly applicable when a VMM (Virtual Machine Manager) is implemented as a VMM mechanism on a real HW of a computer system.

  Note that the present invention is not limited to the above-described embodiment and its modifications, and can be embodied by modifying the components without departing from the scope of the invention in the implementation stage. In addition, various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the embodiment and the modifications thereof. For example, you may delete a some component from all the components shown by embodiment or its modification. Furthermore, you may combine suitably the component covering different embodiment (modification).

1 is a block diagram showing a configuration of a computer system 1 that implements a virtual computer system according to an embodiment of the present invention. FIG. 3 is a diagram showing an overview of copy processing for supporting debugging of a guest OS in the embodiment. 9 is a flowchart showing a copy processing procedure in the embodiment. The figure which shows the outline | summary of the copy process in the 1st modification of the embodiment. 9 is a flowchart showing a copy processing procedure in the first modification. The figure which shows the outline | summary of the copy process in the 2nd modification of the embodiment. 14 is a flowchart showing a copy processing procedure in the second modification. The figure which shows the outline | summary of the copy process in the 3rd modification of the embodiment.

Explanation of symbols

  DESCRIPTION OF SYMBOLS 1 ... Computer system, 30 ... VM application, 31 ... VMM (virtual computer manager), 32-1, 32-2, 32-3 ... Virtual computer execution environment, 33-1, 33-2 ... Virtual HW (hardware) Environment, 311 ... guest OS copy unit, 311a ... guest OS start / stop unit, 312 ... guest OS response monitoring unit, 313 ... I / O history buffer, 313 (k-1), 313 (k), 313 (k + 1) ... I / O history buffer (copy of I / O history buffer 313), 332-1, 332-2 ... Virtual I / O devices, 340-1, 340-2 ... Guest OS, 340-3, 340-4, 340-5, 340-6 ... guest OS (copy of guest OS # 1), 341 ... copy request part, 342 ... response part.

Claims (12)

A guest OS debugging support method for supporting debugging of a guest OS operating in a virtual machine execution environment provided by a virtual machine manager,
The virtual machine manager constructing a second virtual machine execution environment different from the first virtual machine execution environment in which the first guest OS operates;
The virtual machine manager copies the first guest OS to the second virtual machine execution environment including the execution state of the first guest OS and the state of the memory used by the first guest OS. Generating a second guest OS that is a copy of the first guest OS in the second virtual machine execution environment;
And a step of stopping the second guest OS generated in the second virtual machine execution environment and saving the state of the second guest OS.   The virtual machine manager further includes a step of causing the virtual machine manager to not execute the first guest OS before generating the second guest OS that is a copy of the first guest OS. Item 1. A guest OS debugging support method according to Item 1. After the second guest OS is generated, the virtual machine manager further includes a step of making the first guest OS executable.
3. The guest OS debugging support method according to claim 2, wherein the step of generating the second guest OS is executed in response to a request from the first guest OS. The virtual machine manager further includes a step of rebooting the first guest OS after generating the second guest OS,
3. The guest OS debugging according to claim 2, wherein the step of generating the second guest OS is executed in response to a request from the first guest OS when an abnormality occurs in the first guest OS. Support method. The virtual machine manager detecting an abnormality in the first guest OS;
The virtual machine manager forcibly rebooting the first guest OS after generating the second guest OS;
3. The guest OS debugging support method according to claim 2, wherein the step of generating the second guest OS is executed in response to detection of an abnormality in the first guest OS. After the second guest OS is generated, the virtual machine manager makes the first guest OS executable;
The second guest OS operating in the first guest OS in the executable state or in another virtual machine execution environment different from the first virtual machine execution environment is in the stopped state. The guest OS debugging support method according to claim 2, further comprising: debugging the guest OS. After the second guest OS is generated, the virtual machine manager makes the first guest OS executable;
The virtual machine manager further detecting an abnormality of the first guest OS,
The step of generating the second guest OS is the second guest OS that becomes a copy destination of the first guest OS at a predetermined time interval until an abnormality of the first guest OS is detected. The guest OS debugging support method according to claim 2, wherein the virtual machine execution environment is switched within a range of a predetermined number of second virtual machine execution environments.   The method further includes the step of generating, as a debug target, a third guest OS, which is a copy, from the second guest OS, which is a copy of the first guest OS, generated in the second virtual machine execution environment. The guest OS debugging support method according to claim 7, wherein: A history of the input / output processing of the first guest OS that has occurred between the generation time of the second guest OS and the generation time of the next second guest OS is stored in the input / output history buffer by the virtual input / output device. Recording step;
The method further comprises: when the second guest OS, which is a copy of the first guest OS, is generated, collecting and storing a copy of the input / output history buffer at that time. Item 8. A guest OS debugging support method according to Item 7.   The method further comprises a step of reproducing an input / output occurrence event of the first guest OS based on an input / output history of the first guest OS recorded in a copy of the input / output history buffer. The guest OS debugging support method according to claim 9. In the virtual machine manager that builds the virtual machine execution environment in which the guest OS runs,
Virtual machine execution environment construction means for constructing a second virtual machine execution environment different from the first virtual machine execution environment as a copy destination of the first guest OS operating in the first virtual machine execution environment;
By copying the first guest OS including the execution state of the first guest OS and the state of the memory used by the first guest OS to the second virtual machine execution environment, Guest OS copy means for generating a second guest OS, which is a copy of one guest OS, in the second virtual machine execution environment;
And a guest OS stop unit that stops the second guest OS generated in the second virtual machine execution environment by the guest OS copy unit and saves the state of the second guest OS. A featured virtual machine manager. The guest OS stop unit disables the first guest OS before the second guest OS that is a copy of the first guest OS is generated by the guest OS copy unit.
The virtual machine manager further includes guest OS booting means for making the first guest OS executable after the second guest OS is generated by the guest OS copy means. 11. A virtual machine manager according to 11.

Images