Virtual machine, virtual machine monitor and computer control method

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based upon and claims the benefit of priority of the prior Japanese Patent Application No. 2010-007426, filed on Jan. 15, 2010, the entire contents of which are incorporated herein by reference.

FIELD

The present invention relates to a technology of managing execution time of a process on a virtual machine.

BACKGROUND

<figref idrefs="DRAWINGS">FIG. 1</figref> illustrates an example of a configuration of a computer system called a virtual machine. Known as one example of the virtual machine is a system in which hardware such as a CPU (Central Processing Unit) and a memory is installed with a computer program called a virtual machine monitor. In the virtual machine, one guest OS or a plurality of guest OSs runs on the virtual machine monitor. Further, an application program runs on the guest OS. The virtual machine is also called a virtual computer, a VM (Virtual Machine), etc.

The virtual machine monitor is a computer program that is also called a VMM (Virtual Machine Monitor) and Hypervisor. The virtual machine monitor controls the whole virtual machine. For example, the virtual machine monitor executes, when the plurality of guest OSs operates, a dispatch process of the guest OS, i.e., a process of determining the guest OS to which the CPU is allocated and starting up the guest OS. Further, the virtual machine monitor performs emulation of a privilege instruction executed by each guest OS. For instance, when the guest OS makes a request for executing the privilege instruction in a user status, the virtual machine monitor executes a process of intercepting the privilege instruction requested for the execution by exception handling and emulating the execution-requested privilege instruction.

Moreover, the virtual machine monitor is started up when the virtual machine is booted, and the virtual machine monitor performs the processes such as starting up and stopping the guest OS and managing and controlling the virtual machine. There is, however, a case in which the virtual machine is managed and controlled via a special guest OS called a host OS. Further, there is a case in which the management and the control of the virtual machine are performed as a function called service control by a computer program different from the virtual machine monitor.

Still further, the virtual machine monitor performs an I/O (input/output) process with a physical device in response to an I/O request given from the guest OS. The I/O process with the physical device is also called a real I/O process. For example, each guest OS requests, through an interface called a Hypervisor call, the virtual machine monitor to execute the I/O process. Then, the virtual machine monitor accesses, via a device driver, the physical device such as a display, an external storage device and a LAN (Local Area Network). Known also is, however, a configuration in which the guest OS called a driver OS (driver domain) dedicated to the execution of the real I/O process or the host OS described above executes the real I/O process.

On the other hand, the guest OS can be exemplified as the OS having no real I/O on the virtual machine. The guest OS provides the application program with virtual resources on the hardware via the virtual machine monitor. Accordingly, in terms of a relation with the application program, the guest OS can be considered to be the normal OS. It should be noted that the guest OS, the host OS and the driver OS on the virtual machine monitor are deemed to be different computers and are therefore each called the virtual machine as the case may be.

In the virtual machine, the application program is executed on the guest OS, while the guest OS is executed on the virtual machine monitor. And, when the application program requests the guest OS to execute the I/O process, the guest OS issues an I/O instruction. The thus-issued I/O instruction is, e.g., intercepted by the virtual machine monitor, and the I/O process with the physical device is performed by the driver of the virtual machine monitor, the guest OS or the host OS. The guest OS, however, hands over the I/O instruction to the virtual machine monitor by issuing the Hypervisor call as the case may be. In any case, the operation of the virtual machine, which ranges from the request for the I/O process of the application program to the I/O process with the physical device, is complicated.

As described above, the virtual machine has a complicated path extending from the I/O process request to the I/O to the actual physical device, and besides the guest OS receives the virtual interrupt via the virtual machine monitor and measures the time. Accordingly, such a problem arises that in the virtual machine, the guest OS is disabled from acquiring performance information such as execution time of the process which involves the I/O process with high accuracy.

[Documents of Related Arts] <ul><li id="ul0001-0001" num="0000"><ul><li id="ul0002-0001" num="0011">[Patent document 1] Japanese Laid-Open Patent Publication No. 2008-225655</li><li id="ul0002-0002" num="0012">[Patent document 2] Japanese Laid-Open Patent Publication No. 2006-059052</li></ul></li></ul>

SUMMARY

One aspect of the disclosed technology can be exemplified as a virtual machine having a computer including a memory, a processor, a timer and an I/O device and a virtual machine monitor deployed on the memory and executed by the processor. The virtual machine monitor controls execution of at least one guest OS (Operating System) on the processor, accepts a process request given to the computer from the guest OS, and hands over an execution result of the computer in response to the process request to the guest OS. For example, the virtual machine monitor may simply make the processor function as a unit to receive, in place of the timer, a timer setting for setting occurrence (generation) of a timer interrupt after a lapse of a setting period in the timer from the guest OS. Further, the virtual machine monitor may also simply make the processor as a timer changing unit. Herein, the timer changing unit changes the timer setting when the guest OS inputs and outputs data to the I/O device via the virtual machine monitor. For instance, the timer changing unit changes the timer setting so that a ratio of I/O wait time recognized by the guest OS to I/O process time other than the I/O wait time becomes approximate to a ratio of the I/O wait time recognized by the virtual machine monitor to the I/O process time. Still further, the virtual machine monitor, when receiving the timer interrupt, may simply make the processor function as a unit to notify the guest OS of the occurrence of the timer interrupt.

The object and advantages of the invention will be realized and attained by means of the elements and combinations particularly pointed out in the claims.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory and are not restrictive of the invention, as claimed.

BRIEF DESCRIPTION OF DRAWING(S)

<figref idrefs="DRAWINGS">FIG. 1</figref> is a diagram illustrating an example of a configuration of a computer system;

<figref idrefs="DRAWINGS">FIG. 2</figref> is a diagram illustrating a configuration of the computer system according to a comparative example;

<figref idrefs="DRAWINGS">FIG. 3</figref> is a diagram illustrating a schedule example of a guest OS according to a comparative example;

<figref idrefs="DRAWINGS">FIG. 4A</figref> is a diagram illustrating an example of process time on a per-status basis on a physical computer;

<figref idrefs="DRAWINGS">FIG. 4B</figref> is a diagram illustrating an example of the process time on the per-status basis on a virtual machine;

<figref idrefs="DRAWINGS">FIG. 4C</figref> is a diagram illustrating time ratios on the per-status basis between the physical computer and the virtual machine;

<figref idrefs="DRAWINGS">FIG. 5</figref> is a diagram illustrating an example of the process time in an I/O process in the virtual machine according to a first working example in comparison with the virtual machine in the comparative example;

<figref idrefs="DRAWINGS">FIG. 6</figref> is a diagram illustrating an example of a configuration of the virtual machine according to the first working example;

<figref idrefs="DRAWINGS">FIG. 7</figref> is a diagram illustrating components related to a process when setting a timer interrupt and after occurrence of the timer interrupt;

<figref idrefs="DRAWINGS">FIG. 8</figref> is a diagram illustrating an example of virtual CPU management data;

<figref idrefs="DRAWINGS">FIG. 9</figref> is a diagram illustrating a type of time measured by the virtual machine;

<figref idrefs="DRAWINGS">FIG. 10</figref> is a diagram illustrating a process of a process scheduler in a physical OS;

<figref idrefs="DRAWINGS">FIG. 11</figref> is a diagram illustrating a virtual CPU status table;

<figref idrefs="DRAWINGS">FIG. 12</figref> is a diagram illustrating a processing flow of a virtual CPU status determining means;

<figref idrefs="DRAWINGS">FIG. 13</figref> is a diagram illustrating a relation between a timer cycle μ set by the guest OS and a virtual timer cycle returned by the virtual machine monitor to the guest OS;

<figref idrefs="DRAWINGS">FIG. 14</figref> is a diagram illustrating a processing flow of a virtual CPU usage statistics calculating unit;

<figref idrefs="DRAWINGS">FIG. 15</figref> is a diagram illustrating a processing flow when a timer modulation unit sets the timer;

<figref idrefs="DRAWINGS">FIG. 16</figref> is a diagram illustrating a processing flow when the timer modulation unit transfers the virtual timer interrupt to the guest OS; and

<figref idrefs="DRAWINGS">FIG. 17</figref> is a diagram illustrating a configuration of the virtual machine including none of the virtual CPU status determining unit.

DESCRIPTION OF EMBODIMENT(S)

A computer system according to one embodiment will hereinafter be described with reference to the drawings. A configuration in the following embodiment is an exemplification, and the computer system is not limited to the configuration in the embodiment.

A computer system <b>300</b> according to a comparative example will hereinafter be described with reference to <figref idrefs="DRAWINGS">FIGS. 2 through 4</figref>. <figref idrefs="DRAWINGS">FIG. 2</figref> illustrates a configuration of the computer system <b>300</b> according to the comparative example. As in <figref idrefs="DRAWINGS">FIG. 2</figref>, the computer system <b>300</b> includes, as pieces of hardware, e.g., a processing device <b>300</b>A including a CPU (Central Processing Unit) and a memory, and a physical disk <b>302</b>. The CPU corresponds to a processor. On the processing device <b>300</b>A, a virtual machine monitor <b>301</b> operates to manage and control the computer system <b>300</b>.

Further, a guest virtual machine <b>310</b>-<b>1</b> including a front-end driver <b>310</b>A-<b>1</b>, a guest OS <b>310</b>B-<b>1</b> and an application program <b>310</b>C-<b>1</b> operates on the virtual machine monitor <b>301</b>. Moreover, a guest virtual machine <b>310</b>-<b>2</b> including a front-end driver <b>310</b>A-<b>2</b>, a guest OS <b>310</b>B-<b>2</b> and an application program <b>310</b>C-<b>2</b> operates on the virtual machine monitor <b>301</b>. Hereinafter, the guest virtual machines <b>310</b>-<b>1</b>, <b>310</b>-<b>2</b> are, as generically termed, the guest virtual machine <b>310</b>. Furthermore, the front-end drivers <b>310</b>A-<b>1</b>, <b>310</b>A-<b>2</b>, the guest OSs <b>310</b>B-<b>1</b>, <b>310</b>B-<b>2</b> and the application programs <b>310</b>C-<b>1</b>, <b>310</b>C-<b>2</b> are, as generically termed, called the front-end driver <b>310</b>A, the guest OS <b>310</b>B and the application program <b>310</b>C, respectively.

As in <figref idrefs="DRAWINGS">FIG. 2</figref>, the virtual machine monitor <b>301</b> includes a back-end driver <b>304</b>, a timer mechanism <b>305</b>, a scheduler <b>306</b> and a real I/O driver <b>307</b>. The back-end driver <b>304</b> functions as an interface with the front-end driver <b>310</b>A connected to the guest OS <b>310</b>B. For example, the back-end driver <b>304</b> shares an unillustrated shared memory with the front-end driver <b>310</b>A, thus transferring and receiving the data therebetween.

On the computer system <b>300</b>, the virtual machine monitor <b>301</b> schedules the processes of the guest virtual machine <b>310</b>. To be specific, the virtual machine monitor <b>301</b>, after saving register value of the guest virtual machine <b>310</b> into a predetermined memory area, switches over the virtual machine <b>310</b> to which the CPU is allocated. When switching over the guest virtual machine, for instance, the CPU is released from the guest virtual machine <b>310</b>-<b>1</b>, and, instead, the CPU is allocated to the guest virtual machine <b>310</b>-<b>2</b>. More specifically, the CPU is released from the guest OS <b>310</b>B-<b>1</b> and the CPU is allocated to the guest virtual machine <b>310</b>B-<b>2</b>. Allocation of the CPU to the guest OS <b>310</b>B is performed by the scheduler <b>306</b>. Note that the scheduler <b>306</b> is also called a virtual CPU scheduler. Further, a computer program execution environment as viewed from the guest OS <b>310</b>B, for instance, a resource containing a register set is called a virtual CPU.

The scheduler <b>306</b> executes a dispatch process of allocating the CPU to the guest OS <b>310</b>B. For example, the scheduler <b>306</b> sequentially starts up the guest OSs <b>310</b>B-<b>1</b> and <b>310</b>B-<b>2</b> on a time-sharing basis. Moreover, the scheduler <b>306</b>, when the guest OS <b>310</b>B-<b>1</b> is now being started up, saves the present register set into the predetermined memory area. Then, the scheduler <b>306</b> stops the guest OS <b>310</b>B-<b>1</b>. Furthermore, the scheduler <b>306</b> takes over the saving content of the register set of the guest OS <b>310</b>B-<b>2</b>, of which the process is now being interrupted, to the guest OS <b>310</b>B-<b>2</b>. Then, the scheduler <b>306</b> starts up the guest OS <b>310</b>B-<b>2</b>.

The timer mechanism <b>305</b> sets an address of an interrupt processing program in an interrupt vector of the built-in CPU of the processing device <b>300</b>A, and sets the timer interrupt in the register by specifying a predetermined time. Then, the timer interrupt occurs in the CPU after an elapse of the predetermined time, the CPU starts up a process of the interrupt processing program set in the predetermined address on a memory space, which corresponds to the occurred timer interrupt. The virtual machine monitor <b>301</b> recognizes the elapse of the predetermined time from the process of the interrupt processing program. The virtual machine monitor <b>301</b> measures the time by repeatedly receiving the timer interrupt on the basis of the interrupt processing program. Note that the interrupt processing program is also called a handler and a callback function as well.

An I/O instruction to the physical device such as the physical disk <b>302</b> is, e.g., processed as follows. The application program <b>310</b>C running on the guest OS <b>310</b>B invokes the I/O instruction of the guest OS <b>310</b>B by use of a system call. Then, the guest OS <b>310</b>B sets an I/O request in the shared memory via the front-end driver <b>310</b>A, and requests the virtual machine monitor <b>301</b> to execute the process through a function called a Hypervisor call. Thereupon, the back-end driver <b>304</b> reads the I/O request set in the shared memory and hands over this request to the virtual machine monitor <b>301</b>. The virtual machine monitor <b>301</b>, according to the thus handed-over I/O request, starts up the device driver which accesses the physical device and executes the I/O process.

In the I/O process, the device driver executes a data transfer instruction, whereby the data in a buffer area reserved in the predetermined memory area is handed over to an unillustrated I/O controller. The data to be handed over contains a command given to the I/O controller and the I/O data that is input or output. After issuing the data transfer instruction, the scheduler <b>306</b> makes the guest virtual machine <b>310</b> go to an I/O waiting status. As a result, the operation of the guest virtual machine <b>310</b> the status of which is changed to the I/O waiting status is temporarily interrupted. Then, the scheduler <b>306</b>, while the operation of the guest virtual machine <b>310</b> in the I/O waiting status remains interrupted, allocates the CPU, which has so far been allocated to the guest virtual machine with its operation kept interrupting, to another guest virtual machine <b>310</b>. Note that the I/O controller notifies the CPU through the interrupt that the I/O process of the physical device is completed.

The guest OS <b>310</b>B requests the virtual machine monitor <b>301</b> to execute the I/O process through the Hypervisor call, however, the following procedures can be also used instead. For example, when the guest OS <b>310</b>B invokes the system call of the I/O request in a user status, the CPU detects a privilege instruction violation. Next, the CPU transfers the control to the virtual machine monitor <b>301</b>, and the virtual machine monitor <b>301</b> may emulate the I/O process from the system call.

The virtual machine monitor <b>301</b> starts up a plurality of guest virtual machine <b>310</b>-<b>1</b>, <b>310</b>-<b>2</b>, e.g., on the time-sharing basis. It should be noted that the driver OS and the host OS may be loaded with the back-end driver and may execute the real I/O control. The guest virtual machine <b>310</b> will hereinafter be also simply termed the virtual machine <b>310</b>.

<figref idrefs="DRAWINGS">FIG. 3</figref> illustrates a scheduling example of the guest OS <b>310</b>B in the computer system <b>300</b>. In <figref idrefs="DRAWINGS">FIG. 3</figref>, a guest <b>1</b> represents the guest OS <b>310</b>B-<b>1</b>, and a guest <b>2</b> represents the guest OS <b>310</b>B-<b>2</b>. In the computer system <b>300</b>, the CPU of the processing device <b>300</b>A is allocated to the guest <b>1</b> and the guest <b>2</b> alternately, e.g., on the time-sharing basis, thereby operating the plurality of guest OSs <b>310</b>B. A period of allocation time per allocation, which is time-shared, can be defined fixedly within the virtual machine monitor <b>301</b>. Further, the allocation time can be set based on a system parameter etc.

Moreover, if the guest OS <b>310</b>B is unable to completely consume the given time for the reason such as a low load of the guest OS <b>310</b>B, the scheduler <b>306</b> deprives the guest OS with the low load, e.g., the guest OS <b>310</b>B-<b>1</b> of a right-of-use of the CPU but allocates the CPU to another guest OS, e.g., the guest OS <b>310</b>B-<b>2</b>, thus operating the guest OS <b>310</b>B-<b>2</b>. The CPU resources can be effectively utilized owing to the management of the CPU allocation to the guest OS <b>310</b>B as in <figref idrefs="DRAWINGS">FIG. 3</figref>.

The guest OS <b>310</b>B continues to collect various items of statistical information by use of the timer mechanism via the virtual machine monitor <b>301</b>. The statistical information contains, for instance, user time which indicates a period of time when each process running on the guest OS <b>310</b>B operates in the user status, system time (sys time) indicating a period of time of operating in a kernel status on the extension of this process, I/O waiting time (iowait time) indicating a period of time required for the I/O wait, and so on. The statistical information is useful for performance tuning etc. of the application program and middleware.

In the computer system <b>300</b> including the virtual machines, the virtual machine monitor <b>301</b> processes the I/O request of the guest OS <b>310</b>B in a way that converts the I/O request into the real I/O process with respect to the physical device by use of the back-end driver <b>304</b> and the front-end driver <b>310</b>A. In the computer system <b>300</b> or by using the emulation of the I/O instruction by the virtual machine monitor <b>301</b>, the virtual machine monitor <b>301</b> processes the I/O request of the guest OS <b>310</b>B in a way that converts the I/O request into the real I/O process with respect to the physical device.

<figref idrefs="DRAWINGS">FIGS. 4A-4C</figref> illustrate the I/O process in the computer system <b>300</b> including the virtual machine <b>310</b> in comparison with a normal computer including none of the virtual machine. The normal computer, which does not include the virtual machine, will hereinafter be called a physical computer. The physical computer includes a physical CPU. Further, the OS running on the physical computer is called a physical OS.

<figref idrefs="DRAWINGS">FIG. 4A</figref> illustrates an example of the time recognized by the physical OS in the I/O process of the physical computer. In <figref idrefs="DRAWINGS">FIG. 4A</figref>, an “APPLICATION” line indicates that the physical CPU executes the application program. The application program will hereinafter be simply termed the application. During the execution of the application, the process executed by the physical CPU is in the user status. Furthermore, in <figref idrefs="DRAWINGS">FIG. 4A</figref>, a “KERNEL” line indicates that the process executed by the physical CPU is in the kernel status. The user status and the kernel status will be described in a first working example which will be discussed later on. Further, in <figref idrefs="DRAWINGS">FIG. 4A</figref>, a “PHYSICAL DEVICE” line indicates the process of the physical device.

In the example of <figref idrefs="DRAWINGS">FIG. 4A</figref>, during the execution of the application, i.e., during the process by the physical CPU is in the user status (user-A<b>1</b>), the I/O request occurs for the application and a process in the kernel status (sys-A<b>1</b>) is performed. Then, in the process in the kernel status (sys-A<b>1</b>), an I/O issue with respect to the physical device is made, and the real I/O process with respect to the physical device is performed. Subsequently, the process in the kernel status comes to the I/O wait (iowait-A). In <figref idrefs="DRAWINGS">FIG. 4A</figref>, the process in the kernel status (sys-A<b>1</b>) is started in response to the I/O request given from the application, and the process in the kernel status (sys-A<b>1</b>) comes to the I/O wait due to the I/O issue with respect to the physical device. During the I/O wait (iowait-A), the process in the kernel status of the physical OS is deprived of the right-of-use of the CPU. Incidentally, in <figref idrefs="DRAWINGS">FIG. 4A</figref>, an interval at which the process in the kernel status is the I/O wait is indicated by a blank interval in the line of the kernel corresponding to “iowait-A” in the line of the physical device, however, the blank interval in the line of the kernel corresponding to “iowait-A<b>1</b>” is also referred to as “iowait-A<b>1</b>.”

Then, after an I/O completion with respect to the physical device, a process in the kernel status (sys-A<b>2</b>) is performed. Moreover, upon finishing the process in the kernel status (sys-A<b>2</b>), a process in the user status (user-A<b>2</b>) is performed. An assumption in <figref idrefs="DRAWINGS">FIG. 4A</figref> is that periods of time of the process in the kernel status (sys-A<b>1</b>), the I/O wait (iowait-A) with respect to the physical device and the process in the kernel status (sys-A<b>2</b>) are TSA<b>1</b>, TWA and TSA<b>2</b>, respectively.

<figref idrefs="DRAWINGS">FIG. 4B</figref> illustrates an example of the time recognized by the guest OS <b>310</b>B in the I/O process of the virtual machine monitor <b>301</b> and the time recognized by the virtual machine monitor <b>301</b>. In the example of <figref idrefs="DRAWINGS">FIG. 4B</figref>, in the virtual machine monitor <b>301</b>, the application is executed in the user status on the guest OS <b>310</b>B. During the execution of the application in the user status (user-B<b>1</b>), the I/O request occurs from the application, and a process in the kernel status (sys-B<b>11</b>) of the guest OS <b>310</b>B is carried out. The process in the kernel status (sys-B<b>11</b>) includes, e.g., the process of the front-end driver <b>310</b>A.

Then, in the process in the kernel status (sys-B<b>11</b>), the request for the I/O process with the virtual device is made. The I/O process with the virtual device is converted into the process by the real I/O driver of the physical device on the virtual machine monitor <b>301</b>, and a process by the real I/O driver (sys-B<b>21</b>) is performed. Then, the I/O issue is done for the physical device in the process by the real I/O driver (sys-B<b>21</b>), and the process by the real I/O driver (sys-B<b>21</b>) comes to the I/O wait (iowait-B<b>2</b>) with respect to the physical device. In <figref idrefs="DRAWINGS">FIG. 4B</figref>, the process in the kernel status (sys-A<b>1</b>) of the guest OS <b>310</b>B is started in response to the I/O request given from the application. Then, in the process of the real I/O driver (sys-B<b>21</b>), into which the I/O process with the virtual device is converted, the I/O issue is done for the physical device. In the case of <figref idrefs="DRAWINGS">FIG. 4B</figref>, the process in the kernel status of the guest OS <b>310</b>B extends from the I/O request given from the application to the request for the I/O process with the virtual device, and it corresponds to the process in the kernel status in the case of the physical OS in <figref idrefs="DRAWINGS">FIG. 4A</figref>. Accordingly, the process of the sys-A<b>1</b> in <figref idrefs="DRAWINGS">FIG. 4A</figref> is hatched in the same way as the process of sys-B<b>11</b> is hatched.

Then, upon the completion of the I/O process with the physical device, the control returns to the process by the real I/O driver (sys-B<b>22</b>). Further, with the termination of the process by the real I/O driver (sys-B<b>22</b>), the process in the kernel status (sys-B<b>12</b>) of the guest OS <b>310</b>B is performed. The process of sys-B<b>12</b> contains, similarly to the process of sys-B<b>11</b>, the process by the front-end driver <b>310</b>A.

Then, further, with the termination of the process in the kernel status (sys-B<b>12</b>) of the guest OS <b>310</b>B, the control gets back to the process of the application in the user status (user-B<b>2</b>). The process in the kernel status (sys-B<b>12</b>) of the guest OS <b>310</b>B in <figref idrefs="DRAWINGS">FIG. 4B</figref> corresponds to the process in the kernel status (sys-A<b>2</b>) in <figref idrefs="DRAWINGS">FIG. 4A</figref>. Therefore, the process of the sys-A<b>2</b> in <figref idrefs="DRAWINGS">FIG. 4A</figref> is hatched in the same way as the process of sys-B<b>12</b> is hatched.

Then, as in <figref idrefs="DRAWINGS">FIG. 4B</figref>, the guest OS <b>310</b>B recognizes, in the process taking the kernel status (sys-B<b>11</b>), a period of time till a virtual I/O process (iowait-B<b>1</b>) with the virtual device is finished since this process has been started up, as the time of the I/O wait (iowait time) with respect to the virtual device.

An assumption in <figref idrefs="DRAWINGS">FIG. 4B</figref> is that periods of processing time of the process in the kernel status (sys-B<b>11</b>) of the guest OS <b>310</b>B, the I/O wait (iowait-B<b>1</b>) with respect to the virtual device and the process in the kernel status (sys-B<b>12</b>) are TSB<b>11</b>, TWB<b>1</b> and TSB<b>12</b>, respectively.

Further, it is also assumed in <figref idrefs="DRAWINGS">FIG. 4B</figref> that periods of the time of the process of the real I/O driver (sys-B<b>21</b>), the time of the I/O wait (iowait-B<b>2</b>) of the physical device and the processing time of the process of the real I/O driver (sys-B<b>22</b>) in the virtual machine monitor <b>301</b> are TSB<b>21</b>, TWB<b>2</b> and TSB<b>22</b>, respectively.

As described above, the process in the kernel status (sys-B<b>11</b>) of the guest OS <b>310</b>B is kept in the I/O waiting status during the execution of the process (iowait-B<b>1</b>) for the virtual device. The process in the kernel status (sys-B<b>11</b>) of the guest OS <b>310</b>B is kept to be the I/O wait, during which (the interval at which the virtual device is in iowait-B<b>1</b>) the guest OS <b>310</b>B is deprived of the right-of-use of the CPU on the basis of the scheduling by the scheduler <b>306</b>.

Herein, in the processing time of the guest OS <b>310</b>B, a period of time till the process in the kernel status is deprived of the right-of-use of the CPU (the time of TSB<b>11</b> based on the process of sys-B<b>11</b>), is calculated as the system time (sys time) of the guest OS <b>310</b>. Note that a period of time after the I/O wait (the interval at which the virtual device is in iowait-B<b>1</b>) till the status of the guest OS <b>310</b>B returns to the user status from the kernel status (the time of TSB<b>12</b> based on the process of sys-B<b>12</b>) is also calculated as the system time (sys time) of the guest OS <b>310</b>.

On the other hand, during the process in the kernel status (sys-B<b>11</b>) of the guest OS <b>310</b>B is kept to be the I/O wait (iowait-B<b>1</b>) with respect to the virtual device, in the virtual machine monitor <b>301</b>, the process by the real I/O driver (sys-B<b>21</b>) is performed and the I/O issue is done to the physical device from the process of the real I/O driver (sys-B<b>21</b>). Then, after the I/O issue to the physical device, the process of the real I/O driver (sys-B<b>21</b>) comes to the I/O wait.

However, as for the statistical information of the guest OS <b>310</b>B, the period of time (TSB<b>21</b> and TSB<b>22</b>) while the real I/O driver of the virtual machine monitor <b>301</b> performs the processes (sys-B<b>21</b> and sys-B<b>22</b>) is calculated as the I/O wait time (iowait time). Namely, in the guest OS <b>310</b>B, the time TWB<b>1</b> of the I/O wait (iowait-B<b>1</b>) with the virtual device turns out to be a period of time obtained by adding the time TSB<b>21</b> and time TSB<b>22</b> of the processes (sys-B<b>21</b> and sys-B<b>22</b>) of the real I/O driver before and after the I/O wait in addition to the time TWB<b>2</b> of the I/O wait (iowait-B<b>2</b>) with the physical device.

A comparison between the processing time as viewed from the physical OS in the case of <figref idrefs="DRAWINGS">FIG. 4A</figref> and the processing time as viewed from the virtual OS <b>310</b>B in <figref idrefs="DRAWINGS">FIG. 4B</figref>, is made as follows. In the physical OS, the processing time after the I/O request has been given from the application includes the time TSA<b>1</b> of the process (sys-A<b>1</b>) till the I/O issue in the kernel status is done in the physical OS, the wait time (the time corresponding to the interval of iowait-A<b>1</b>) TWA till the I/O completion is made since the I/O issue has been done and the time TSA<b>2</b> of the process (sys-A<b>2</b>) till I/O reception is made since the I/O completion has been performed.

On the other hand, in the case of the virtual machine system <b>300</b> in <figref idrefs="DRAWINGS">FIG. 4B</figref>, the time TSB<b>21</b> of the process (sys-B<b>21</b>) by the real I/O driver corresponds to the time TSA<b>1</b> in <figref idrefs="DRAWINGS">FIG. 4A</figref>. Similarly, the time TSB<b>22</b> in <figref idrefs="DRAWINGS">FIG. 4B</figref> corresponds to the time TSA<b>2</b> in <figref idrefs="DRAWINGS">FIG. 4A</figref>. Then, the time TWB<b>2</b> of the I/O wait (iowait-B<b>2</b>) with the physical device corresponds to the time TWA in <figref idrefs="DRAWINGS">FIG. 4A</figref>. Accordingly, a relation between the time TSB<b>21</b>+TSB<b>22</b> of the processes (sys-B<b>21</b>,sys-B<b>22</b>) of the real I/O driver in the virtual machine monitor <b>301</b> and the time TWB<b>2</b> of the I/O wait (iowait-B<b>2</b>) with the physical device, substantially corresponds to the case of the physical OS. To be specific, the relation between the time TSA<b>1</b>+TSA<b>2</b> of the processes (sys-A<b>1</b>, sys-A<b>2</b>) in the kernel status in the case of the physical OS and the time TWA of the I/O wait (iowait-A<b>1</b>) with the physical device, corresponds to the relation between the time TSB<b>21</b>+TSB<b>22</b> and the time TWB<b>2</b> in the virtual machine monitor <b>301</b>.

However, the relation between of the time related to the I/O process as viewed from the guest OS <b>310</b>B in <figref idrefs="DRAWINGS">FIG. 4B</figref> does not necessarily correspond to the relation of the time related to the I/O process as viewed from the physical OS in <figref idrefs="DRAWINGS">FIG. 4A</figref>. Namely, as in <figref idrefs="DRAWINGS">FIG. 4B</figref>, in the guest OS <b>310</b>B, the time TWB<b>1</b> of the I/O wait (iowait-B<b>1</b>) with the virtual device includes the time TSB<b>21</b>+TSB<b>22</b> of the processes (sys-B<b>21</b>,sys-B<b>22</b>) of the real I/O driver and the time TWB<b>2</b> of the I/O wait (iowait-B<b>2</b>) with the physical device. Hence, the time TWB<b>1</b> of the I/O wait (iowait-B<b>1</b>) with the virtual device is longer by the time TSB<b>21</b>+TSB<b>22</b> of the processes (sys-B<b>21</b>,sys-B<b>22</b>) of the real I/O driver than the time TWB<b>2</b> of the I/O wait (iowait-B<b>2</b>) with the physical device.

As a result, the relation between the time TSB<b>11</b>+TSB<b>12</b> of the processes (sys-B<b>11</b>, sysB<b>12</b>) in the kernel status as viewed from the guest OS <b>310</b>B and the time TWB<b>1</b> of the I/O (iowait-B<b>1</b>) with the virtual device is different from the relation between the time TSA<b>1</b>+TSA<b>2</b> and the time TWA in the virtual machine monitor <b>301</b> corresponding to the physical OS running on the physical computer.

As in <figref idrefs="DRAWINGS">FIG. 4B</figref>, the I/O wait time TWB<b>1</b> as viewed from the guest OS <b>310</b>B is the time including the system time TSB<b>21</b>+TSB<b>22</b> for which the virtual machine monitor <b>301</b> operates in the kernel status and the I/O wait time TWB<b>2</b> of the virtual machine monitor <b>301</b>. Accordingly, the I/O wait time TWB<b>1</b> required for the I/O wait in the virtual machine <b>310</b> as viewed from the guest OS <b>310</b>B is measured as a longer period of time than the I/O wait time TWB<b>2</b> required for the I/O wait of the real I/O driver executed by the virtual machine monitor.

<figref idrefs="DRAWINGS">FIG. 4C</figref> illustrates a comparative relation between the processing time in the kernel status and the I/O wait time with respect to the physical OS on the physical computer and the guest OS <b>310</b>B on the virtual machine <b>310</b>. As in <figref idrefs="DRAWINGS">FIG. 4C</figref>, the time TSB<b>11</b>+TSB<b>12</b> of the processes (sys-B<b>11</b>, sysB<b>12</b>) in the line attached with a character string “CASE OF GUEST OS” is shorter than the time TSA<b>1</b>+TSA<b>2</b> of the processes (sys-A<b>1</b>,sys-A<b>2</b>) in the line attached with a character string such as “CASE OF PHYSICAL OS.” On the other hand, the time TWB<b>1</b> of iowait-B<b>1</b> in the line attached with the character string “CASE OF GUEST OS” is longer than the time TWA of iowait-A in the line attached with the character string such as “CASE OF PHYSICAL OS.” Therefore, the statistical information of the guest OS <b>310</b>B decreases in reliability by way of a key to performance tuning.

<figref idrefs="DRAWINGS">FIG. 4B</figref> illustrates a process in the case of having one guest OS <b>310</b>B. Plural guest OSs <b>310</b>B operate, in which case a more complicated situation related to the statistical information occurs. Because of the situation as illustrated in <figref idrefs="DRAWINGS">FIGS. 4A-4C</figref>, in the case of conducting the performance tuning of the application program <b>310</b>C on the guest OS <b>310</b>B or the middleware on the guest OS <b>310</b>B, the statistical information viewed from the guest OS <b>310</b>B hard to be reliable. Such being the case, it is also considered that the statistical information collected by the virtual machine monitor <b>301</b> is utilized in place of the statistical information viewed from the guest OS <b>310</b>B. Normally, however, the statistical information of the virtual machine monitor <b>301</b> is not disclosed to the users of the guest OS <b>310</b>B in terms of the security and access authority.

The computer system according to the embodiment is provided with a mechanism for correcting the timer mechanism so that the statistical information collected by the guest OS is equalized to the statistical information viewed from the physical computer without adding any modification to the guest OS. The computer system according to the embodiment provides the more effective statistical information than by the computer system <b>300</b> according to the comparative example in terms of the performance tuning of the application program and the middleware owing to the mechanism for correcting the timer mechanism.

FIRST WORKING EXAMPLE

The computer system (which will hereinafter be referred to as a virtual system) according to a first working example will hereinafter be described with reference to <figref idrefs="DRAWINGS">FIGS. 5 through 16</figref>. <figref idrefs="DRAWINGS">FIG. 5</figref> illustrates an example of how the processing time of the I/O process in the virtual system according to the first working example is managed in comparison with the computer system <b>300</b> in the comparative example. In <figref idrefs="DRAWINGS">FIG. 5</figref>, an example of the processing time in the I/O process of the computer system <b>300</b> according to the comparative example is given in an upper stage designated by a symbol C<b>1</b>, while an example of the processing time in the I/O process of the virtual system according to the first working example is given in a lower stage designated by symbols C<b>2</b> and C<b>3</b>. Broken lines extending in the vertical direction in <figref idrefs="DRAWINGS">FIG. 5</figref> represent time delimiters detected by the timer. The time delimiters of the timer in the guest OS <b>310</b>B are identical with the time delimiters of the timer in the virtual machine monitor <b>301</b> which manages the guest OS <b>310</b>B, and hence the time delimiters of the timer in the virtual machine monitor <b>301</b> are omitted in C<b>1</b> of <figref idrefs="DRAWINGS">FIG. 5</figref>. Further, the processes denoted by user-B<b>1</b>, user-B<b>2</b>, sys-B<b>11</b>, iowait-B<b>1</b>, sys-B<b>12</b>, sys-B<b>21</b>, iowait-B<b>2</b> and sys-B<b>22</b> are the same as those in the case of <figref idrefs="DRAWINGS">FIG. 4B</figref>. In the first working example, however, the virtual machine monitor adjusts the time when the virtual machine monitor notifies the guest OS of the timer interrupt. The time adjustment might lead to occurrence of such a state that a discrepancy occurs between the time delimiters of the timer in the guest OS and the time delimiters of the timer in the virtual machine monitor. Such being the case, in <figref idrefs="DRAWINGS">FIG. 5</figref>, C<b>2</b> indicates the time delimiters of the timer in the guest OS according to the first working example, and C<b>3</b> indicates the time delimiters of the timer in the virtual machine monitor according to the first working example. Herein, the time delimiters of the timer in the guest OS are shown as just the time of the timer interrupt observed by the guest OS. Further, the time delimiters of the timer in the virtual machine monitor are shown as just the time of the timer interrupt observed by the virtual machine monitor.

The time of the timer interrupt observed by the guest OS in the first working example is depicted by the broken line extending in the vertical direction within a range defined by arrows of C<b>21</b> in the field of the symbol C<b>2</b>. Note that in the field of the symbol C<b>2</b>, the broken line existing more upward than the range defined by the arrows of C<b>21</b> is a line for reference serving to represent a relation with the timer interrupt time in the C<b>1</b> field. Moreover, the time of the timer interrupt observed by the virtual machine monitor is indicated by the broken line extending in the vertical direction in the field of the symbol C<b>3</b>. Hereafter, the timer started by the guest OS of the virtual machine <b>310</b> is called a virtual timer, while the timer started by the virtual machine monitor is called a real timer.

In the first working example, the timing adjustment of the timer interrupt by the virtual machine monitor improves the reliability on the statistical information collected in the guest OS without changing the timer mechanism of the guest OS and without adding any modification to the guest OS. This being the case, the virtual machine monitor adjusts the timing of notifying the guest OS of the timer interrupt so that the relation between the system time viewed from the guest OS and the I/O wait time with respect to the virtual device is equalized to the relation between the system time in the physical computer and the I/O wait time with respect to the physical device. Namely, in the first working example, the timing of the timer interrupt by the virtual timer is adjusted in such a way that a timer interrupt occurrence count of the virtual timer in the guest OS is kept coincident with a timer interrupt occurrence count of the real timer in the virtual machine monitor. R<b>1</b> is a ratio of the timer interrupt occurrence count in the time TSB<b>11</b>+TSB<b>12</b> of the processes (sys-B<b>11</b>, sys-B<b>12</b>) in the kernel status of the guest OS to the timer interrupt occurrence count in the I/O wait (iowait-B<b>1</b>) time (TWB<b>1</b>) with respect to the virtual device. Further, R<b>2</b> is a ratio of the timer interrupt occurrence count in the time TSB<b>21</b>+TSB<b>22</b> of the processes (sys-B<b>21</b>, sys-B<b>22</b>) in the kernel status of the virtual machine monitor to the timer interrupt occurrence count in the I/O wait (iowait-B<b>2</b>) time TWB<b>2</b> with respect to the physical device. In the first working example illustrated in <figref idrefs="DRAWINGS">FIG. 5</figref>, the interrupt occurrence timing of the virtual timer is modified so that R<b>1</b> approximates R<b>2</b>.

Hereinafter, a ratio of each of the occurrence counts in the time in the kernel status and the time in the I/O wait status to the total occurrence count in the periods of time in a combined mode of the kernel status and the I/O waiting status, is called a timer density. In the first working example illustrated in <figref idrefs="DRAWINGS">FIG. 5</figref>, the timer density of the virtual timer is modified as follows. Note that the total occurrence count of the timer interrupt in the periods of time in the combined mode of the kernel status and the I/O wait status, is called a total count of the timer interrupt which accompanies the I/O process. <ul><li id="ul0003-0001" num="0077">(a) The number of broken lines of C<b>1</b> is kept coincident with the number of broken lines of C<b>2</b>. Then;</li><li id="ul0003-0002" num="0078">(b) the timer density within the period of the processes (sys-B<b>11</b>, sys-B<b>12</b>) in the kernel status of the guest OS as indicated by the arrows C<b>21</b> and the timer density within the period of the processes (sys-B<b>21</b>, sys-B<b>22</b>) in the kernel status of the virtual machine monitor in the field of C<b>3</b>, are so modified as to be approximate to each other to the greatest possible degree. Besides;</li><li id="ul0003-0003" num="0079">(c) the timer density within the period of the I/O wait (iowait-B<b>1</b>) with the virtual device in the field of C<b>2</b> and the timer density within the period of the I/O wait (iowait-B<b>2</b>) with the physical device in the field of C<b>3</b>, are so modified as to be approximate to each other to the greatest possible degree.</li></ul>

Through the processes described above, the timer interrupt timing is adjusted in such a direction as to set the timer densities by the process (sys-B<b>11</b>, sys-B<b>12</b>) in the kernel status of the guest OS and the process (sys-B<b>21</b>, sys-B<b>22</b>) in the kernel status of the virtual machine monitor in common. Moreover, the timer interrupt timing is adjusted in such a direction as to set the timer densities in the period of the I/O wait (iowait-B<b>1</b>) with the virtual device and the period of the I/O wait (iowait-B<b>2</b>) with the physical device in common. As a result, the ratio R<b>1</b> is made approximate to the ratio R<b>2</b>.

For example, in the virtual machine monitor <b>301</b> according to a comparative example in the field of C<b>1</b>, the timer interrupt occurrence count comes to 24 altogether in the periods of the processes sys-B<b>11</b>, iowait-B<b>1</b> and sys-B<b>12</b>. More specifically, the time interrupt occurs twice, twenty times and twice in the respective periods of the processes sys-B<b>11</b>, iowait-B<b>1</b> and sys-B<b>12</b>. Speaking of a timer frequency ratio, the timer interrupt occurs at the ratio such as 1:10:1. Accordingly, the timer density is on the order of 1/12 in each of the processes sys-B<b>11</b> and sys-B<b>12</b> in the kernel status. Further, the timer density in the I/O wait (iowait-B<b>1</b>) with the virtual device is on the order of 11/12.

On the other hand, in the first working example, as given in the field of C<b>3</b>, the timer interrupt occurrence count comes to 21 altogether in the periods of the processes sys-B<b>21</b>, iowait-B<b>2</b> and sys-B<b>22</b>. To be more specific, the timer interrupt occurs seven times, seven times and seven times in the respective periods of the processes sys-B<b>21</b>, iowait-B<b>2</b> and sys-B<b>22</b>. Speaking of the timer frequency ratio, the timer interrupt occurs at the ratio such as 1:1:1. Accordingly, the timer density is on the order of ⅓ in each of the processes sys-B<b>21</b> and sys-B<b>22</b> in the kernel status. Moreover, the timer density in the I/O wait (iowait-B<b>2</b>) with respect to the physical device is on the order of ⅓.

In short, the ratio of the timer interrupt occurrence count in the kernel status to the timer interrupt occurrence count in the I/O waiting status of the guest OS according to the comparative example is not coincident with the ratio in the case of the virtual machine monitor in the first working example or in the case of the physical OS in the physical computer. It should be noted that the ratio of the timer interrupt occurrence count in the kernel status to the count in the I/O waiting status of the virtual machine monitor according to the first working example may be considered to be the same as the ratio in the case of the physical OS in the physical computer.

Such being the case, in the field of C<b>2</b> according to the first working example, the timing when the virtual machine monitor notifies the guest OS of the virtual timer interrupt is adjusted so that the virtual timer interrupt occurs eight times, eight times and eight times in the respective processes, i.e., in terms of the timer density, the virtual timer interrupt occurs at a ratio such as 1/3:1/3:1/3 to the greatest possible degree. As a result of the timing adjustment, as obvious from the comparison between C<b>2</b> and C<b>3</b> in <figref idrefs="DRAWINGS">FIG. 5</figref>, the timer densities become common within the period of sys-B<b>11</b> and within the period of sys-B<b>21</b> in the field C<b>2</b>. Further, the timer densities become common within the period of iowait-B<b>1</b> in the field C<b>2</b> and within the period of iowait-B<b>2</b> in the field C<b>3</b>. Moreover, the timer densities become common within the period of sys-B<b>12</b> in the field C<b>2</b> and within the period of sys-B<b>22</b> in the field C<b>3</b>.

According to <figref idrefs="DRAWINGS">FIG. 5</figref>, in the fields of C<b>1</b> and C<b>2</b>, the total timer interrupt count accompanying one single I/O process is the same (common), and hence there is no error in timer between the guest OS <b>310</b>B of the virtual machine <b>310</b> according to the comparative example and the guest OS according to the first working example.

On the other hand, due to the adjustment of the virtual timer interrupt timing, the occurrence of a deviation in timing between the virtual timer of the guest OS according to the first working example and the physical timer of the virtual machine monitor, is seen between the processes sys-B<b>11</b>, iowait-B<b>1</b>, sys-B<b>12</b> in the guest OS as shown in C<b>2</b> and the processes sys-B<b>11</b>, iowait-B<b>1</b>, sys-B<b>12</b> of the virtual machine monitor as shown in C<b>3</b>. Accordingly, the timing deviation observed by the guest OS according to the first working example is limited to within the range in which to operate in the kernel status. The OS is designed to operate in several milliseconds in the kernel status. Hence, there is a low possibility that the timing deviation observed by the guest OS might affect the time information detected by the application program.

&lt;Configuration of Virtual System&gt;

<figref idrefs="DRAWINGS">FIG. 6</figref> illustrates an example of a configuration of a virtual system <b>11</b> as the computer system according to the first working example. The virtual system <b>11</b> in <figref idrefs="DRAWINGS">FIG. 6</figref> includes a physical CPU, a memory and a timer. Further, the memory retains computer programs including a virtual machine monitor <b>1</b> and a guest OS <b>10</b>B. Hereinafter, the physical CPU is simply referred to as the CPU. It should be noted that in the first working example, the whole computer system including the hardware such as the physical CPU, the memory and the timer, the virtual machine monitor and the guest OS executed on the virtual machine monitor, is termed a virtual system <b>11</b>.

As in <figref idrefs="DRAWINGS">FIG. 6</figref>, the virtual machine monitor <b>1</b> has a virtual CPU scheduler <b>2</b>, a virtual CPU status determining unit <b>3</b>, a physical CPU usage statistics calculating unit <b>4</b>, a virtual CPU usage statistics calculating unit <b>5</b> and a timer modulation unit <b>6</b>. The physical CPU of the virtual system <b>11</b> executes the computer program as the virtual machine monitor <b>1</b> including the virtual CPU scheduler <b>2</b>, the virtual CPU status determining unit <b>3</b>, the physical CPU usage statistics calculating unit <b>4</b>, the virtual CPU usage statistics calculating unit <b>5</b> and the timer modulating unit <b>6</b>. Further, the virtual system <b>11</b> includes, on the memory, virtual CPU management data <b>7</b> managed by the virtual machine monitor <b>1</b>. On the other hand, the guest OS <b>10</b>B has a timer process setting unit <b>8</b>. The physical CPU of the virtual system <b>11</b> executes the computer program as the guest OS <b>10</b>B including the timer process setting unit <b>8</b>.

&lt;Process Scheduler and Virtual CPU Scheduler&gt;

In the first working example, the virtual machine monitor <b>1</b> handles a plurality of virtual CPUs and allocates the physical CPU to the virtual CPU. The virtual CPU is defined as a concept embracing a processing status and a resource in the physical CPU in the case of allocating the physical CPU to the guest OS. Namely, the virtual CPU can be also considered to be the concept corresponding to each individual process in a multi-process environment realized by the physical OS which directly operates on the conventional physical computer. Alternatively, when viewed from the guest OS, the virtual CPU can be handled as each individual CPU in a multi-processor system.

Note that in the computer system including the virtual machine, for example, such a scheme is considered that the single guest OS separately uses the plurality of virtual CPUs, however, what is considered in the first working example is a case where one virtual CPU is prepared per guest OS.

A process of allocating the physical CPU to the virtual CPU which is requested by the guest OS to execute the process, is called “dispatch.” Therefore, in order not to interfere with each other even when successively switching over the virtual CPUs, the virtual machine monitor <b>1</b>, after temporarily saving an execution context such as register values into a predetermined memory area when switching over the virtual CPU, stops the in-execution virtual CPU. Then, the virtual machine monitor <b>1</b> restores again the execution context of the in-stop virtual CPU, and resumes the execution of the in-stop virtual CPU. This execution context is contained in the virtual CPU management data <b>7</b>. The virtual machine monitor <b>1</b> stores the execution context of each of the plural virtual CPUs, thereby repeating the execution process, the saving process, the stop process and the resumption process. The virtual CPU scheduler <b>2</b> determines time and a sequence for allocating the virtual CPUs to the physical CPUs according to a predetermined rule.

<figref idrefs="DRAWINGS">FIG. 10</figref> illustrates a process of the virtual CPU scheduler <b>2</b> together with a process scheduler in the physical OS. The process with the physical OS is similar in a certain aspect to a role of the virtual CPU in the virtual machine monitor <b>1</b>. This being the case, in <figref idrefs="DRAWINGS">FIG. 10</figref>, the process of the process scheduler and the process of the virtual CPU scheduler <b>2</b> are depicted en bloc in one drawing. The following discussion will be focused mainly on the process with the physical OS, however, the virtual CPU in the virtual machine monitor <b>1</b> also takes the same status as the status of the process with the physical CPU.

The process scheduler has a FIFO (First In First Out) and sequentially dispatches the wait-for-allocation processes on the FIFO to the CPUs. The schedule status of the process is classified into an active status, a queued status and an unqueued status. The active status is a status of the process to which the CPU has already been allocated. The active status can be also said to be a status of the process that is in the execution by the CPU. The queued status connotes a status in which the process is in a wait-for-allocation status of the CPU on the FIFO. In the active status or the queued status, the process managed by the physical OS or the virtual CPU managed by the virtual machine monitor <b>1</b> is classified into the user status (user) or the kernel status (sys).

Furthermore, the unqueued status denotes neither a status in which the process is not in the execution by the CPU nor the wait-for-allocation status of the CPU but is a status of the process not existing on the FIFO. The process in the unqueued status is in the I/O wait status (iowait) of waiting the completion of the I/O process or in an idle status (idle) where nothing is done.

The physical OS can distinguish the idle process and the I/O wait process in the processes taking the unqueued status, which are not connected to the FIFO, from the management information per process. Similarly, the virtual machine monitor <b>1</b> can distinguish the virtual CPUs in the idle status and in the I/O wait status in the virtual CPUs taking the unqueued status, which are not connected to the FIFO, from the management information per virtual CPU.

&lt;Calculation of Statistical Information&gt;

As described above, the virtual system <b>11</b> classifies the process of the physical computer or the virtual CPU of the virtual system <b>1</b> into the four statuses such as the user status (user), the kernel status (sys), the I/O wait status (iowait) and the idle status (idle). These statuses are determined based on the mode and the schedule status of the CPU. The mode of the CPU is defined as a concept which specifies, for giving a distinction between the instructions executable by the CPU, a status set in the CPU or whether or not the privilege is given or an execution level. For example, the user mode is a mode having no privilege or a mode having the lowest privilege. In the first working example, the terminology “status” is used with respect to the process (or the virtual CPU) in distinction from the mode of the CPU. Such being the case, in the first working example, when the CPU which is in the execution of the process (or the real CPU allocated with the virtual CPU) is in the user node, it is said that the process (or the virtual CPU) is in the user status.

Moreover, the kernel mode is a mode having the privilege or a mode having the higher privilege than the user mode. The kernel mode may be called a privilege mode. In the case of saying the privilege mode, however, though other is a case of including modes having different levels into which the CPU's status is subdivided, there is no distinction between these modes in the first working example. According to the first working example, when the CPU which is in the execution of the process (or the real CPU allocated with the virtual CPU) is in the kernel mode or the variety of privilege modes, the process (or the virtual CPU) is said to be in the kernel status.

When the control is transferred to the guest OS <b>10</b>B from the application program due to, e.g., the system call etc., the virtual CPU becomes the kernel status. In the kernel status, the virtual CPU usage statistics calculating unit <b>5</b> totalizes and accumulates the elapsed time given from the timer as the system time (sys time).

In the kernel status, after transferring the data input and output to the I/O controller of the physical device from, e.g., the device driver, the virtual CPU (process) is linked to the queue and the execution of the virtual CPU (process) is temporarily stopped, at which time the virtual CPU (process) comes to the I/O wait status. In the I/O wait status, the virtual CPU usage statistics calculating unit <b>5</b> totalizes and accumulates the elapsed time given from the timer as the I/O wait time (iowait time).

If neither in the in-execution status of the user process nor in the in-execution status of the system call nor in the I/O wait status, the virtual CPU (process) becomes the idle status (idle). In the idle status, the virtual CPU usage statistics calculating unit <b>5</b> totalizes and accumulates the elapse time given from the timer as the idle time (idle time).

The virtual machine monitor <b>1</b>, the guest OS or the physical OS distinguishes between the I/O wait time and the idle time, corresponding to a cause of why the process scheduler or the virtual CPU scheduler <b>2</b> sets the process or the virtual CPU in the unqueued status which will be described later on. For instance, in the physical computer, the device driver executed by the physical OS transfers the I/O request to the unillustrated I/O controller in response to a data transfer instruction and temporarily stops the process, in which case the processing time measured in the temporarily-stopped status of the process becomes the I/O wait time. Moreover, if the process comes to the unqueued status due to a cause other than the I/O request, the processing time becomes the idle time.

<figref idrefs="DRAWINGS">FIG. 9</figref> illustrates a type of the time measured by the virtual machine <b>10</b>. Each period of time is the time based on the CPU cycle and is measured based on, e.g., the occurrence of the timer interrupt as one unit. The user time is the time when executing the application program or an accumulated total of time thereof. The system time (sys time) is the time when executing codes of a kernel program or an accumulated total of time thereof. The I/O wait time (iowait time) is the time when executing neither the application program nor the kernel program as well as being the standby time till the process of the device is completed, or an accumulated total of time thereof. The idle time (idle time) is the time when executing neither the application program nor the kernel program as well as being the non-standby time till the process of the physical device is completed, or an accumulated total of time thereof.

The physical CPU usage statistics calculating unit <b>4</b> totalizes the periods of elapse time in a way that categorizes the elapsed time into the user time, the sys time, the iowait time and the idle time in accordance with the user status, the sys status, the iowait status and the idle status of the process that is in the execution by the physical CPU. Note that in <figref idrefs="DRAWINGS">FIG. 6</figref>, the physical CPU usage statistics calculating unit <b>4</b> exists within the virtual machine monitor <b>1</b>.

The virtual CPU usage statistics calculating unit <b>5</b> also totalizes the elapsed time in the same way as the physical CPU usage statistics calculating unit <b>4</b> does, however, a different point is that the elapsed time in the virtual CPU is totalized corresponding to the status of the virtual CPU.

As already stated, the virtual CPU can be said to be the computer resource when executing the guest OS on the physical CPU and the execution environment including the register set. To the virtual CPU, the physical CPU is allocated by the virtual CPU scheduler <b>2</b> of the virtual machine monitor <b>1</b>. Then, the execution environment such as the register set of the virtual CPU is handed over to the guest OS <b>10</b>B, whereby the guest OS <b>10</b>B is started up. The startup of the guest OS <b>10</b>B triggers a start of the process of the virtual CPU. The virtual CPU status determining unit <b>3</b> determines the status, i.e., user, sys, iowait or idle, of the virtual CPU by use of various items of data (refer to &lt;Management Data and Data Structure&gt;) retained within the virtual machine monitor <b>1</b>.

The virtual CPU usage statistics calculating unit <b>5</b> identifies the status of the virtual CPU according to the determination of the virtual CPU status determining unit <b>3</b> and totalizes, for a predetermined period, the user time, the system time (sys time), the I/O wait time (iowait time) and the idle time, thereby calculating an accumulated value of each length of time.

&lt;Management Data and Data Structure&gt;

<figref idrefs="DRAWINGS">FIG. 8</figref> illustrates an example of the virtual CPU management data <b>7</b>. The execution context is the data representing the status of each individual virtual CPU. The execution context is exemplified such as the register values. When switching over the guest OS, the execution context at the OS execution time, which has so far been executed before the switchover, is saved into the memory. On the other hand, the registers are set based on the execution context remaining saved in the memory for the guest OS that is executed after the switchover, and the guest OS executed after the switchover is started up.

An exit flag is a flag used for the virtual CPU to determine whether the status is the user status (user) or the kernel status (sys). The guest OS <b>10</b>B executes the privilege instruction, and, before the process is shifted to the virtual machine monitor <b>1</b>, the virtual machine monitor <b>1</b> sets “1” in the exit flag with respect to the virtual CPU that is in the execution of the guest OS <b>10</b>B. Reversely, when the process returns to the guest OS <b>10</b>B from the virtual machine monitor <b>1</b>, the virtual machine monitor <b>1</b> sets “0” in the exit flag. The virtual system <b>11</b> uses the exit flag as one determining element for the virtual CPU status determining unit <b>3</b>.

A wait-for-completion I/O count indicates the number of the not-yet-completed I/O processes in the I/O request issued by the guest OS <b>10</b>B. The wait-for-completion I/O count is calculated, e.g., in the following procedures. When the control is transferred to the virtual machine monitor <b>1</b> as triggered by the I/O request given from the guest OS <b>10</b>B, the virtual machine monitor <b>1</b> adds “1” to the wait-for-completion I/O count. Then, on the occasion of sending an I/O response back to the guest OS <b>10</b>B upon the completion of the physical I/O, the virtual machine monitor <b>1</b> subtracts “1” from the wait-for-completion I/O count. The wait-for-completion I/O count also becomes the determination element of the virtual CPU status determining unit <b>3</b>.

In the first working example, the virtual machine monitor <b>1</b> calculates the wait-for-completion I/O count per guest OS <b>10</b>B. In the first working example, however, the thus-calculated wait-for-completion I/O count per guest OS <b>10</b>B is retained in the virtual CPU management data <b>7</b> in the way of being identifiable by the virtual CPU which executes the guest OS <b>10</b>B. A premise in the first working example is that one guest OS <b>10</b>B is to be executed by one virtual CPU, and hence the virtual CPU status determining unit <b>3</b> can, if the virtual CPU can be specified, acquire the wait-for-completion I/O count in the virtual CPU.

<figref idrefs="DRAWINGS">FIG. 11</figref> illustrates a virtual CPU status table used for the virtual machine monitor <b>1</b> to identify the status (user, sys, iowait, idle) of the virtual CPU. The virtual CPU status table is contained in the virtual CPU management data <b>7</b> in <figref idrefs="DRAWINGS">FIG. 6</figref>.

The virtual CPU status table in <figref idrefs="DRAWINGS">FIG. 11</figref> contains “execution status” in the first column, “exit flag” in the second column and “wait-for-completion I/O count” in the third column. The execution status connotes any one of the statuses, i.e., the active status, the queued status and the unqueued status of the process explained in <figref idrefs="DRAWINGS">FIG. 10</figref>. The virtual machine monitor <b>1</b> queries the virtual CPU scheduler <b>2</b> about the execution status of the virtual CPU. On the other hand, as already described in <figref idrefs="DRAWINGS">FIG. 8</figref>, the exit flag and the wait-for-completion I/O count are retained in the virtual CPU management data <b>7</b>.

Accordingly, if the execution status of the virtual CPU is the active status or the queued status, the virtual machine monitor <b>1</b> can identify the status of the virtual CPU with user or sys from the value of the exit flag.

If the virtual CPU is in the unqueued status, however, the virtual machine monitor <b>1</b> is hard to determine which status, idle or iowait, the process (virtual CPU) takes. The virtual machine monitor <b>1</b> acts as a proxy in the input and output given from the guest OS <b>10</b>B, which does not, however, mean that the virtual machine monitor <b>1</b> manages the I/O request count and a process completion count in the guest OS <b>10</b>B. Therefore, in the first working example, the information representing the wait-for-completion I/O count is provided in the virtual CPU management data <b>7</b>. Then, the virtual machine monitor <b>1</b> increments or decrements the wait-for-completion I/O count when the I/O request is given from each guest OS <b>10</b>B and when completing the real I/O for the input and output, and retains the incremented or decremented wait-for-completion I/O count per guest OS <b>10</b>B. Then, when the virtual CPU is in the unqueued status, the virtual machine monitor <b>1</b>, if the wait-for-completion I/O count is larger than “0”, identifies the status of the virtual CPU with iowait. Further, when the virtual CPU is in the unqueued status, the virtual machine monitor <b>1</b>, if the wait-for-completion I/O count is “0”, identifies the status of the virtual CPU with idle. The assumption in the first working example is that one guest OS is executed by one virtual CPU, and hence the virtual machine monitor <b>1</b> retains the wait-for-completion I/O count per virtual CPU. Accordingly, the virtual machine monitor <b>1</b> can identify the status of the virtual CPU from the wait-for-completion I/O count per virtual CPU.

Incidentally, to add a few more words, if one guest OS <b>10</b>B is executed by a plurality of virtual CPUs, the process may simply be changed as follows. To be specific, if one guest OS <b>10</b>B is executed by the plurality of virtual CPUs, the guest OS <b>10</b>B is associated with a specified virtual CPU called a virtual primary CPU. The guest OS <b>10</b>B is, when booted for the first time, started up by, at first, the virtual primary CPU and is thereafter executed by one other virtual CPU as the case may be. This being the case, the wait-for-completion I/O count may simply be retained in the virtual CPU management data <b>7</b>. Accordingly, the virtual CPU status determining unit <b>3</b> can, if capable of specifying the virtual primary CPU, acquire the wait-for-completion I/O count in the guest OS <b>10</b>B executed by the virtual primary CPU. Namely, the wait-for-completion I/O count of the plurality of virtual CPUs as a whole is deemed to be the wait-for-completion I/O count of the individual virtual CPUs by holding the totalized wait-for-completion I/O count of the plurality of virtual CPUs by way of the information of the virtual primary CPU, and approximately each individual virtual CPU may identify the status with iowait or idle.

&lt;Description of Timer Process&gt;

A timer process in the virtual machine will hereinafter be described. The timer process of the guest OS <b>10</b>B is basically the same as the timer process of the physical computer. In the timer process, to begin with, a callback function is registered in the timer, and, when a specified period of time elapses, the timer interrupt occurs. As triggered by this timer interrupt, the physical OS, after canceling the callback function from the timer, invokes the callback function. As for the callback function, after performing a predetermined process that should be cyclically done with the timer interrupt, the callback function is again registered in the timer. With this process, it follows that the callback function is cyclically invoked. The callback function is also called a handler or an interrupt processing program. Specific implementation of the timer is different depending on the physical OS.

The following is a different point of the timer process of the guest OS <b>10</b>B from the timer process of the physical computer. A timer registration process involves the privilege instruction. Therefore, when executing the process of registering the callback function in the timer, the control is temporarily transferred to the virtual machine monitor <b>1</b> from the guest OS <b>10</b>B. The virtual machine monitor <b>1</b>, after the elapse of the time specified by the guest OS <b>10</b>B, generates the virtual timer interrupt to the guest OS <b>10</b>B, and further wakes up the virtual CPU. The phrase “wakes up the virtual CPU” refers to “allocates the physical CPU to the virtual CPU after restoring the execution context of the guest OS <b>10</b>B that is executed by the virtual CPU.” The virtual machine monitor <b>1</b>, however, sets the occurrence of the timer interrupt in the execution context handed over to the guest OS <b>10</b>B. Thereupon, after waking up the virtual CPU, the guest OS <b>10</b>B receives the virtual timer interrupt. Based on the method described so far, the virtual machine monitor <b>1</b> virtually acts as the proxy to execute the timer process started up from the guest OS <b>10</b>B. In the first working example, the virtual machine monitor <b>1</b> includes the timer modulation unit <b>6</b> and executes the timer adjusting process illustrated in <figref idrefs="DRAWINGS">FIG. 5</figref> by properly modifying the time specified by the virtual machine <b>10</b>.

<figref idrefs="DRAWINGS">FIG. 7</figref> illustrates components related to the processes when setting the timer interrupt and after the occurrence of the timer interrupt. It is assumed that the virtual system <b>11</b> includes one physical CPU. The guest OS <b>10</b>B is executed on one physical CPU. The guest OS <b>10</b>B sets the timer interrupt in the hardware timer at a first timer interval (arrow A<b>1</b>). In the physical computer other than the virtual system <b>11</b>, the timer interrupt is set in a hardware timer ATM via a route depicted by dotted line AB<b>2</b> in <figref idrefs="DRAWINGS">FIG. 7</figref>.

The setting of the timer interrupt is of the privilege instruction, and hence, in the case of the virtual system <b>11</b>, an exception occurs in the physical CPU. With the exception, the control is transferred to the virtual machine monitor <b>1</b> from the guest OS <b>10</b>B. The virtual machine monitor <b>1</b>, to which the control is transferred from the guest OS <b>10</b>B, intercepts the setting request of the timer interrupt from the guest OS <b>10</b>B (arrow A<b>2</b>). The term “intercept” refers to receiving, in place of the hardware timer ATM, such timer setting that the guest OS <b>10</b>B sets the occurrence of the timer interrupt after the elapse of a setting period in the hardware timer ATM. In the virtual machine <b>10</b> according to the first working example, the virtual machine monitor <b>1</b> intercepts the timer setting through the exception handling. As a result of the intercept, the guest OS <b>10</b>B does not set the timer interrupt in the hardware timer. Note that the physical CPU executes the computer program deployed on the memory as a unit that receives the timer setting in place of the hardware timer ATM.

The virtual machine monitor <b>1</b>, which has intercepted the timer setting by the guest OS <b>10</b>B, sets the timer interrupt in the hardware timer ATM at a second timer interval modulated as a substitute for the first timer interval set by the guest OS <b>10</b>B (arrow A<b>3</b>). On the occasion of setting the timer interrupt, the virtual machine monitor <b>1</b> sets an address of a guest timer activating handler AAH in an interrupt vector AIV<b>1</b> that is processed when the timer interrupt is occurred. The timer handler is defined as a function that is started up when the timer interrupt is occurred. In <figref idrefs="DRAWINGS">FIG. 7</figref>, the guest timer activating handler AAH is also started up when the timer interrupt is occurred and notifies the guest OS <b>10</b>B of the timer interrupt.

Upon the occurrence of the timer interrupt, an interrupt flag is set in a timer interrupt register AIR<b>1</b> (A<b>4</b>), and the guest timer activating handler AAH is started up based on the address set in the interrupt vector AIV<b>1</b> associated with the timer interrupt.

The started-up guest timer activating handler AAH sets the interrupt flag in a timer interrupt register AIR<b>2</b> in an execution context AC containing the content of the register set of the guest OS <b>10</b>B, and transmits a virtual interrupt to the guest OS <b>10</b>B (arrow A<b>5</b>).

When the guest OS <b>10</b>B receives the virtual interrupt, the control is transferred to the timer handler ATH (with its address) set in the interrupt vector ATV<b>2</b>, and the timer process is executed. After the process of the timer handler ATH, the control is shifted to the normal process of the guest OS <b>10</b>B (arrow A<b>6</b>). With the configuration described above, the virtual machine monitor <b>1</b> sets the timer interrupt in the hardware timer ATM at the second timer interval modulated in place of the first timer interval set by the guest OS <b>10</b>B. Then, the virtual machine monitor <b>1</b> notifies, in place of the hardware timer ATM, the guest OS <b>10</b>B of the virtual timer interrupt.

&lt;Timer Modulating Unit&gt;

A method of how the timer modulating unit <b>6</b> adjusts the timer cycle specified by the guest OS <b>10</b>B will hereinafter be described. <figref idrefs="DRAWINGS">FIG. 12</figref> illustrates a relation between a timer cycle μ set by the guest OS <b>10</b>B and virtual timer cycles μ_sysand μ_iowhich are returned by the virtual machine monitor <b>1</b> (VMM) to the guest OS <b>10</b>B.

In the period indicated by t_sysand the period indicated by T_sysin <figref idrefs="DRAWINGS">FIG. 12</figref>, a relation between the timer cycle μ set by the guest OS <b>10</b>B and the virtual timer cycle μ_sysreturned by the virtual machine monitor <b>1</b> to the guest OS <b>10</b>B, is expressed in the following formula 1. <br />μ_sys<i>=μ·t</i>_sys<i>/T</i>_sys  Formula 1

In the formula 1, t_syscorresponds to a period (e.g., TSB<b>11</b>+TSB<b>12</b> in <figref idrefs="DRAWINGS">FIG. 4B</figref>) during the execution of the kernel program recognized by the guest OS <b>10</b>B in the single I/O (which is the process ranging from the I/O request to the I/O reception in <figref idrefs="DRAWINGS">FIGS. 4 and 5</figref>). Further, T_syscorresponds to a period (e.g., TSB<b>21</b>+TSB<b>22</b> in <figref idrefs="DRAWINGS">FIG. 4B</figref>) during the execution of the kernel program recognized by the virtual machine monitor <b>1</b> in the single I/O. Actually, t_syscan be obtained as an accumulated value into which to accumulate, for a predetermined period, the execution time of the kernel program that is calculated by the virtual CPU usage statistics calculating unit <b>5</b>. Herein, the “accumulated value” is meant to be a total value collected for the predetermined period. An average value obtained in the predetermined period throughout may, however, be used as the accumulated value. As a substitute for the accumulated value of the execution time calculated by the virtual CPU usage statistics calculating unit <b>5</b>, however, there may be used the execution time, during the predetermined period, of the kernel program contained in the usage statistics calculated in the past by the guest OS <b>10</b>B. As a matter of course, the usage statistics calculated in the past by the guest OS <b>10</b>B may involve employing the usage statistics in a non-modulation status of the virtual timer cycle μ_sysbased on the formula 1. The period t_syscorresponds to a reference value of the processing time in the privilege status recognized by the guest OS.

Further, T_syscan be obtained as the accumulated value into which to accumulate the execution time of the kernel program that is calculated by the physical CPU usage statistics calculating unit <b>4</b>. The period t_syscorresponds to the reference value of the processing time in the privilege mode recognized by the virtual machine monitor <b>1</b>.

As a timer cycle which replaces the timer cycle μ set by the guest OS <b>10</b>B, a timer cycle μ_sysmodulated so that an occurrence frequency of the virtual timer interrupt generated in the period t_sysgets coincident with an occurrence frequency of the physical timer interrupt generated in the period T_sys, is determined by the formula 1. According to the formula 1, it follows that the timer cycle is modulated at a ratio such as t_sys/T_sys.

To transform the formula 1, a relation is established such as t_sys/μ_sys=T_sys/μ, whereby the virtual timer is modulated in such a direction that the occurrence count of the timer interrupt generated at the interval μ_sysrecognized by the guest OS <b>10</b>B within the accumulation time t_sysbecomes coincident with the occurrence count of the timer interrupt generated at the interval μ recognized by the virtual machine monitor <b>1</b> in the accumulation time T_sys. Namely, the timer density of the virtual timer in the period t_sysis common to the timer density of the physical timer in the period T_sys.

On the other hand, in the period indicated by t_ioand the period indicated by T_ioin <figref idrefs="DRAWINGS">FIG. 12</figref>, a relation between the timer cycle μ set by the guest OS <b>10</b>B and the virtual timer cycle μ_ioreturned by the virtual machine monitor <b>1</b> to the guest OS <b>10</b>B, is expressed in the following formula 2. <br />μ_io<i>=μ·t</i>_io<i>/T</i>_io  Formula 2

In the formula 2, t_iocorresponds to the I/O wait period (e.g., TWB<b>1</b> in <figref idrefs="DRAWINGS">FIG. 4B</figref>) with respect to the virtual device recognized by the guest OS <b>10</b>B in the single I/O (which is the process ranging from the I/O request to the I/O reception in <figref idrefs="DRAWINGS">FIGS. 4 and 5</figref>). Further, T_iocorresponds to an I/O wait period (e.g., TWB<b>2</b><figref idrefs="DRAWINGS">FIG. 4B</figref>) with respect to the physical device recognized by the virtual machine monitor <b>1</b> in the single I/O. Actually, t_iocan be obtained as an accumulated value of the I/O wait time calculated by the virtual CPU usage statistics calculating unit <b>5</b>. In place of the accumulated value t_iocalculated by the virtual CPU usage statistics calculating unit <b>5</b>, there may be used the I/O wait time during the predetermined period contained in the usage statistics calculated by the guest OS <b>10</b>B. As a matter of course, the usage statistics calculated in the past by the guest OS <b>10</b>B may involve employing the usage statistics in the non-modulation status of the virtual timer cycle μ_iobased on the formula 2. The period t_iocorresponds to a reference value of the I/O wait time recognized by the guest OS. Moreover, T_iois the accumulated value of the I/O wait time during the predetermined period calculated by the physical CPU usage statistics calculating unit <b>4</b>. The period T_iocorresponds to the reference value of the I/O wait time recognized by the virtual machine monitor.

As a timer cycle which replaces the timer cycle μ set by the guest OS <b>10</b>B, a timer cycle μ_iomodulated so that the occurrence frequency of the virtual timer interrupt generated in the period t_iogets coincident with the occurrence frequency of the physical timer interrupt generated in the period T_io, is determined by the formula 2.

To transform the formula 2, a relation is established such as t_io/μ_io=T_io/μ, whereby the occurrence count of the timer interrupt generated at the interval μ_iorecognized by the guest OS <b>10</b>B within the accumulation time t_iobecomes coincident with the occurrence count of the timer interrupt generated at the interval μ recognized by the virtual machine monitor <b>1</b> in the accumulation time T_io. Therefore, the timer is modulated in such a direction that the occurrence count of the timer interrupt in the I/O wait time recognized by the guest OS <b>10</b>B becomes coincident with the occurrence count of the timer interrupt in the I/O wait time recognized by the virtual machine monitor <b>1</b>. Namely, the timer density of the virtual timer in the period tio is common to the timer density of the physical timer in the period T_io.

Further, there is established a relation such as t_sys/μ_sys+t_io/μ_io=(T_sys+T_io)/μ, and hence the total interrupt count in the kernel status and in the I/O wait status, which is recognized by the guest OS <b>10</b>B, coincides with the total interrupt count recognized by the virtual machine monitor <b>1</b>.

<figref idrefs="DRAWINGS">FIG. 13</figref> illustrates a processing flow of the virtual CPU status determining unit <b>3</b>. The virtual CPU status determining unit <b>3</b> manages and refers to the virtual CPU status table in <figref idrefs="DRAWINGS">FIG. 11</figref>, thus determining the status of the virtual CPU. For example, the virtual CPU status determining unit <b>3</b>, in response to the request given from the virtual CPU usage statistics calculating unit <b>5</b>, determines the status of each virtual CPU.

The physical CPU serving as the virtual CPU status determining unit <b>3</b> executes the computer program. In the first working example, however, the discussion will proceed on the assumption that the virtual CPU status determining unit <b>3</b> performs the process in <figref idrefs="DRAWINGS">FIG. 13</figref>. In the process of <figref idrefs="DRAWINGS">FIG. 13</figref>, the virtual CPU status determining unit <b>3</b> queries the virtual CPU scheduler <b>2</b> about the schedule status of each virtual CPU (F<b>1</b>). Then, the virtual CPU status determining unit <b>3</b> determines, based on a response given from the virtual CPU scheduler <b>2</b>, which status, the active status or the queued status or alternatively neither the active status nor the queued status, each virtual CPU takes (F<b>2</b>).

If the virtual CPU is in the active status or the queued status (F<b>2</b>; YES), the virtual CPU status determining unit <b>3</b> acquires the exit flag from the virtual CPU management table (F<b>3</b>). Then, the virtual CPU status determining unit <b>3</b> advances the control to F<b>5</b>. Whereas if the virtual CPU is in neither the active status nor the queued status, i.e., the virtual CPU is in the unqueued status (F<b>2</b>; NO), the virtual CPU status determining unit <b>3</b> advances the control to F<b>4</b>. In this case, the virtual CPU status determining unit <b>3</b> acquires the wait-for-completion I/O count from the virtual CPU management data (F<b>4</b>).

Then, the virtual CPU status determining unit <b>3</b> determines the status of the virtual CPU, which is, i.e., any one of user, sys, iowait and idle, by referring to the virtual CPU status table in a way that uses the exit flag acquired in F<b>3</b> or the wait-for-completion I/O flag acquired in F<b>4</b>, and outputs the result of the determination to the virtual CPU usage statistics calculating unit <b>5</b> (F<b>5</b>).

For instance, if the virtual CPU is in the active status or the queued status and if the value of exit flag is “0”, the virtual CPU status determining unit <b>3</b> outputs the user status (user). Moreover, if the virtual CPU is in the active status or the queued status and if the value of Exit flag is “1”, the virtual CPU status determining unit <b>3</b> outputs the kernel status (sys). If the virtual CPU is in neither the active status nor the queued status (unqueued) and if the wait-for-completion I/O count is equal to or smaller than “0”, the virtual CPU status determining unit <b>3</b> outputs the idle. If the virtual CPU is in neither the active status nor the queued status (unqueued) and if the wait-for-completion I/O count is equal to or larger than “1”, the virtual CPU status determining unit <b>3</b> outputs the I/O wait (iowait).

As described above, the virtual CPU status determining unit <b>3</b> distinguishes between user, sys, iowait and idle, and therefore, if the virtual machine monitor <b>1</b> periodically monitors, e.g., the status of the virtual CPU, the virtual CPU usage statistical information can be calculated.

<figref idrefs="DRAWINGS">FIG. 14</figref> illustrates a processing flow of the virtual CPU usage statistics calculating unit <b>5</b>. The physical CPU serving as the virtual CPU usage statistics calculating unit <b>5</b> executes the computer program contained in the virtual machine monitor <b>1</b>. The following discussion will proceed on the assumption that the virtual CPU usage statistics calculating unit <b>5</b> executes the process in <figref idrefs="DRAWINGS">FIG. 14</figref>. The process in <figref idrefs="DRAWINGS">FIG. 14</figref> is started up when the virtual CPU scheduler <b>2</b> switches over the status of each virtual CPU to the active status or the queued status or the unqueued status or when the wait-for-completion I/O count changes.

Note that the process in <figref idrefs="DRAWINGS">FIG. 14</figref> may be started up at a predetermined time interval. If the process in <figref idrefs="DRAWINGS">FIG. 14</figref> is started up at the predetermined time interval, for example, as compared with the period for which the status (user, sys, iowait, idle) of the virtual CPU changes, the process in <figref idrefs="DRAWINGS">FIG. 14</figref> may be started up at a short time interval that is allowable as an error.

The virtual CPU usage statistics calculating unit <b>5</b>, to begin with, determines the present status, i.e., “user, sys, iowait and idle” of the virtual CPU (F<b>21</b>). The present status of the virtual CPU is determined in the process of the virtual CPU status determining unit <b>3</b> in <figref idrefs="DRAWINGS">FIG. 13</figref>.

Next, the virtual CPU usage statistics calculating unit <b>5</b> subtracts the process end time of the last time from the present time, and obtains the elapsed time from the end of the process of the past time (F<b>22</b>). The present time is the present time recognized by the virtual machine monitor <b>1</b> when executing the process in F<b>22</b>.

Next, the virtual CPU usage statistics calculating unit <b>5</b> determines whether the present status, obtained in F<b>11</b>, of the virtual CPU is the kernel status (sys) or not (F<b>23</b>). If the present status of the virtual CPU is the kernel status (sys) (F<b>23</b>; YES), the virtual CPU usage statistics calculating unit <b>5</b> adds the elapsed time calculated in F<b>22</b> to the accumulated value t_sysof the sys time (F<b>24</b>). Then, the virtual CPU usage statistics calculating unit <b>5</b> shifts the control to F<b>27</b>.

Whereas if the present status of the virtual CPU is not the kernel status (sys) (F<b>23</b>; NO), the virtual CPU usage statistics calculating unit <b>5</b> determines whether or not the present status, obtained in F<b>21</b>, of the virtual CPU is the I/O wait (iowait) status (F<b>25</b>). If the present status of the virtual CPU is the I/O wait (iowait) status (F<b>25</b>; YES), the virtual CPU usage statistics calculating unit <b>5</b> adds the elapsed time calculated in F<b>21</b> to the accumulated value t_ioof the iowait time (F<b>26</b>). Then, the virtual CPU usage statistics calculating unit <b>5</b> shifts the control to F<b>27</b>.

Next, the virtual CPU usage statistics calculating unit <b>5</b> records the present time as the end time in a static memory, e.g., the shared memory (F<b>27</b>). Then, the virtual CPU usage statistics calculating unit <b>5</b> finishes the process.

Note that in the process of <figref idrefs="DRAWINGS">FIG. 14</figref>, though omitted, it is feasible to similarly calculate the user time when the virtual CPU is kept in the user status or the idle time when the virtual CPU is kept in the idle status.

Further, the process of the physical CPU usage statistics calculating unit <b>4</b> is, except the point that the process is executed by the virtual machine monitor <b>1</b>, the same as the process executed by the conventional physical OS. Namely, the virtual machine monitor <b>1</b> is capable of handling the process on the Hypervisor similarly to the process of the physical OS in the physical computer. Accordingly, the physical CPU usage statistics calculating unit <b>4</b> can determine whether the status of the process on the Hypervisor is the user status (user), the kernel status (sys), the wait-for-completion I/O status (iowait) or the idle status (idle). It is to be noted that the case in which the status of the process on the Hypervisor is the kernel status can be exemplified by a case in which the process (sys-B<b>21</b>, sys-B<b>22</b>) of the real I/O driver in <figref idrefs="DRAWINGS">FIG. 4B</figref> is in the execution. Accordingly, for instance, the physical CPU usage statistics calculating unit <b>4</b> may, if in the execution of the process of the real I/O driver illustrated in <figref idrefs="DRAWINGS">FIG. 4B</figref>, determine that the status of the process on the Hypervisor is the kernel status. Then, the physical CPU usage statistics calculating unit <b>4</b> sets the execution time (sys time) in the kernel status in the predetermined accumulated period to the accumulated value T_sys. Further, the physical CPU usage statistics calculating unit <b>4</b> sets the I/O wait time (iowait time) in the predetermined accumulated period to the accumulated value T_io.

<figref idrefs="DRAWINGS">FIGS. 15 and 16</figref> illustrate a processing flow of the timer modulation unit <b>6</b>. The physical CPU serving as the timer modulation unit <b>6</b> executes the computer program contained in the virtual machine monitor <b>1</b>. The following discussion will be made on the assumption that the timer modulation unit <b>6</b> executes the processes in <figref idrefs="DRAWINGS">FIGS. 15 and 16</figref>. The timer modulation unit <b>6</b> modulates the virtual timer interrupt occurrence time transferred to the guest OS <b>10</b>B in accordance with the formulae 1 and 2. The timer cycle μ is the cycle specified by the guest OS <b>10</b>B, and hence the timer modulation unit <b>6</b> calculates the timer cycle modulated corresponding to the result of the virtual CPU status determining unit <b>3</b>. <figref idrefs="DRAWINGS">FIG. 15</figref> depicts the process when setting the timer, and <figref idrefs="DRAWINGS">FIG. 16</figref> illustrates the process when transferring, after the occurrence of the timer interrupt, the virtual timer interrupt to the guest OS <b>10</b>B. A program for executing the process in <figref idrefs="DRAWINGS">FIG. 16</figref> is called a guest timer activating handler. The physical CPU serving as a unit for notifying the guest OS of the occurrence of the timer interrupt executes the process in <figref idrefs="DRAWINGS">FIG. 16</figref> according to the computer program deployed on the memory.

When the guest OS <b>10</b>B sets the timer interrupt, the setting of the timer interrupt is of the privilege instruction, and consequently an exception occurs in the physical CPU. The virtual machine monitor <b>1</b> intercepts, through the exception generated in the CPU, the setting of the timer interrupt set by the guest OS <b>10</b>B, and starts up the process of the timer modulation unit <b>6</b> in <figref idrefs="DRAWINGS">FIG. 14</figref>. The CPU intercepts, based on the computer program deployed on the memory, the setting of the timer interrupt (arrow B<b>1</b> in <figref idrefs="DRAWINGS">FIG. 6</figref>).

The timer modulation unit <b>6</b> queries the virtual CPU status determining unit <b>3</b> about the status of the virtual CPU, thus acquiring the status of the virtual CPU (F<b>31</b>). Then, the timer modulation unit <b>6</b> determines the status of the in-execution virtual CPU (F<b>32</b>).

If the status of the virtual CPU is the kernel status (sys), the timer modulation unit <b>6</b> calculates the post-modulating timer interval μ_sysaccording to the formula 1. Note that the timer interval μ set by the guest OS <b>10</b>B can be acquired when intercepting the timer interrupt set by the guest OS <b>10</b>B. Then, the timer modulation unit <b>6</b> sets, in place of the timer interval μ set by the guest OS <b>10</b>B, the timer interrupt in the hardware timer, in which μ_sysis the post-modulating timer interval. Moreover, the timer modulation unit <b>6</b> sets the guest timer activating handler for waking up the guest OS <b>10</b>B as the timer handler which accepts the set timer interrupt (F<b>33</b>).

If the status of the virtual CPU is the user status (user) or the idle status (idle), the timer modulation unit <b>6</b> sets, without modulating the timer interval, the timer interrupt at the timer interval μ set by the guest OS <b>10</b>B (F<b>34</b>). Moreover, the timer modulation unit <b>6</b> sets the guest timer activating handler for waking up the guest OS <b>10</b>B as the timer handler which accepts the set timer interrupt. Namely, in the modulation method in the first working example, the timer interval is not modulated in the user time and the idle time.

If the status of the virtual CPU is the I/O wait status (iowait), the post-modulating timer interval μ_iois calculated according to the formula 2. Then, the timer modulation unit <b>6</b> sets, as the substitute for the timer interval μ set by the guest OS <b>10</b>B, sets the timer interrupt, in which μ_iois the post-modulating timer interval. Moreover, the timer modulation unit <b>6</b> sets the guest timer activating handler for waking up the guest OS <b>10</b>B as the timer handler which accepts the set timer interrupt (F<b>35</b>).

Upon the occurrence of the timer interrupt set according to the process in <figref idrefs="DRAWINGS">FIG. 15</figref>, the guest timer activating handler is started up, and the process in <figref idrefs="DRAWINGS">FIG. 16</figref> is executed. The guest timer activating handler, at first, cancels the startup setting of the guest timer activating handler when the timer interrupt is generated. Namely, the setting of the guest timer activating handler is cleared from the timer interrupt vector with respect to the timer interrupt (F<b>41</b>).

Next, the guest timer activating handler sets the interrupt flag in the timer interrupt register AIR<b>2</b> in the execution context of the virtual CPU (see <figref idrefs="DRAWINGS">FIG. 7</figref>). Then, the guest timer activating handler starts up the guest OS <b>10</b>B.

The started-up guest OS <b>10</b>B sets the variety of register values contained in the context in the register of the CPU, and thus starts the process. Thereupon, it appears to the virtual CPU that the timer interrupt is generated. Namely, the guest timer activating handler notifies the virtual CPU of the virtual timer interrupt (F<b>42</b>). As described above, in the guest OS <b>10</b>B, the timer handler is started up with the virtual timer interrupt. Accordingly, the guest OS <b>10</b>B is actually notified of the interrupt at the timer interval μ_sysor μ_ioand, nevertheless, behaves as if notified of the interrupt at the timer interval μ.

As discussed above, according to the virtual system <b>11</b> in the first working example, the virtual CPU usage statistics calculating unit <b>5</b> calculates the accumulated value t_sysof the execution time in the kernel status and the accumulated value tio of the execution time in the I/O wait status in the virtual machine <b>10</b>. Moreover, the physical CPU usage statistics calculating unit <b>4</b> calculates the accumulated value T_sysof the execution time in the kernel status and the accumulated value T_ioof the execution time in the I/O wait status in the physical CPU included in the virtual system <b>11</b>. Then, the timer modulation unit <b>6</b> intercepts the setting of the timer interrupt by the guest OS <b>10</b>B, then changes the timer interval according to the formulae 1 and 2, and sets the timer interrupt in the actual physical CPU. Furthermore, the timer modulation unit <b>6</b> sets the guest timer activating handler in <figref idrefs="DRAWINGS">FIG. 16</figref> as the timer handler.

Accordingly, when in the kernel status and the I/O wait status, the timer interval is changed based on the formula 1 or 2, and the virtual timer interrupt occurs in the guest OS <b>10</b>B at the thus-changed timer interval. Namely, as shown in the fields C<b>2</b> and C<b>3</b> in <figref idrefs="DRAWINGS">FIG. 5</figref>, the timer interrupt occurrence count in the kernel status and the I/O wait status is retained as the total count in the single I/O process of the guest OS <b>10</b>B. Then, the ratio of the timer interrupt occurrence count in the kernel status to the timer interrupt occurrence count in the I/O wait status with respect to the virtual CPU in the guest OS <b>10</b>B, is adjusted in the status of retaining the timer interrupt occurrence count as the total count. Namely, the timer interval is changed so that the ratio of the timer interrupt occurrence count in the kernel status to the timer interrupt occurrence count in the I/O wait status with respect to the virtual CPU in the guest OS <b>10</b>B coincides with the ratio of the timer interrupt occurrence count in the kernel status to the timer interrupt occurrence count in the I/O wait status with respect to the process with the physical CPU.

Therefore, in the virtual OS, the statistical information on the kernel execution time and the I/O wait execution time when executing the I/O process get approximate to the statistical information under the condition similar to the case of being measured by the actual physical computer. Namely, as illustrated in <figref idrefs="DRAWINGS">FIG. 5</figref>, when the guest OS <b>10</b>B inputs and outputs the data to the I/O device via the virtual machine monitor <b>1</b>, the ratio of the I/O wait time recognized by the guest OS <b>10</b>B to the processing time other than the I/O wait time becomes approximate to the ratio of the I/O wait time recognized by the virtual machine monitor <b>1</b> to the processing time other than the I/O wait time.

By the way, the first working example has discussed so far the case of using one virtual CPU. The first working example can be also applied as it is to the case of using the plurality of virtual CPUs. The reason why so is that there is no necessity for modulating the user time and the idle time while only the sys time and iowait time are modulated. The user time does not originally need modulating, while the idle time is another item of value which has no concern therewith in the virtual CPU usage statistics, and it is therefore sufficient to modulate only the sys time and iowait time. As exemplified in the first working example, the case in which the virtual machine monitor <b>1</b> calculates the physical CPU usage statistical information with respect to the whole physical system, involves using such a primary approximate method of performing the modulation so as to equalize the ratio of the sys time to the iowait time in the virtual CPU usage statistical information of all of the virtual machines.

Further, the accumulated values t_ioand t_sysexemplified in the first working example are the estimated values of the iowait time and the sys time observed actually by the guest OS <b>10</b>B in a way that uses as a key the wait-for-completion I/O count that is newly provided by the virtual machine monitor <b>1</b>, and the estimation thereof is also done otherwise.

The following are plural other methods of increasing accuracy of the approximation to the iowait time and the sys time and estimating the iowait time and the sys time of the guest OS <b>10</b>B.

FIRST MODIFIED EXAMPLE

The physical CPU usage statistical information may be calculated per virtual CPU by way of a policy of carrying out the timer modulation with the high accuracy. Namely, the virtual machine monitor <b>1</b> manages the individual virtual CPUs in a way that identifies each virtual CPU, and hence an available scheme is that the virtual machine monitor <b>1</b> hands over the information for identifying the target virtual CPU which calculates the usage statistical information to the physical CPU usage statistics calculating unit <b>4</b> by which the physical CPU usage statistical information is calculated for each individual virtual CPU. For attaining this scheme, T_sysand T_ioare prepared corresponding to the (number of) different entries distinguished by the information for identifying the individual virtual CPUs and are thus accumulated. Then, the timer modulation unit <b>6</b> illustrated in <figref idrefs="DRAWINGS">FIG. 14</figref> refers to T_sysand T_iodefined as the statistical information of the virtual CPU concerned on the basis of the information for identifying the modulation target virtual CPU, and calculates μ_sysand μ according to the formulae 1 and 2.

The method of calculating the physical CPU usage statistical information on a per-virtual CPU basis is suited to a case of giving a different type of load per physical CPU. For example, the case is exemplified such that a certain guest OS frequently accesses the disc, while other guest OSs frequently access the network, and on these occasions each guest OS uses the predetermined physical CPU.

Further, the virtual machine monitor <b>1</b> manages the individual physical devices in a way that identifies each physical device, and hence the available scheme is that the virtual machine monitor <b>1</b> hands over the information for identifying the target physical device which calculates the usage statistical information to the physical CPU usage statistics calculating unit <b>4</b> by which the physical CPU usage statistical information is calculated for each individual physical device. For attaining this scheme, T_sysand T_ioare prepared corresponding to the number of different entries distinguished by the information for identifying the individual physical devices and are thus accumulated. Then, the timer modulation unit <b>6</b> illustrated in <figref idrefs="DRAWINGS">FIG. 14</figref> refers to T_sysand T_iodefined as the statistical information concerned on the basis of the information for identifying the now-in-execution I/O process target physical device, and calculates μ_sysand μ_ioaccording to the formulae 1 and 2.

The process of calculating T_sysand T_ioper individual physical device is suited to the case of handling the plurality of physical devices having different characteristics. The physical device is exemplified such as a USB (Universal Serial Bus) device, a SAN (Storage Area Network) disk and an IDE (Integrated Drive Electronics) disk.

SECOND MODIFIED EXAMPLE

<figref idrefs="DRAWINGS">FIG. 17</figref> illustrates a configuration of the virtual machine including none of the virtual CPU status determining unit <b>3</b>. Note that the same components in <figref idrefs="DRAWINGS">FIG. 17</figref> as those in <figref idrefs="DRAWINGS">FIG. 6</figref> are marked with the same numerals and symbols, and their explanations are omitted.

In the configuration of <figref idrefs="DRAWINGS">FIG. 17</figref>, the guest OS <b>10</b>B makes an explicit entry in the virtual CPU management data <b>7</b> about which item, user or sys or idle or iowait, the virtual CPU usage statistics calculating unit <b>5</b> should calculate the data. To be specific, the guest OS <b>10</b>B, before executing the process of prompting the issue of the privilege instruction such as the system call, explicitly shows that the process is in the user status to the status flag on the shared memory. Moreover, the guest OS <b>10</b>B, till the privilege instruction is completed after executing the process of prompting the issue of the privilege instruction such as the system call, explicitly shows that the process is in the kernel status to the status flag on the shared memory. Furthermore, the guest OS <b>10</b>B, till the I/O process is completed after executing the I/O request, explicitly shows that the process is in the I/O wait status to the status flag on the shared memory. On the other hand, the virtual CPU usage statistics calculating unit <b>5</b>, if the information of being the I/O wait time is not explicitly indicated in the flag of the shared memory, accumulates the elapse time in the idle time. In order for the guest OS <b>10</b>B to explicitly show user, sys, iowait described above, though the guest OS <b>10</b>B needs modifying slightly, there is no necessity for making a change in the timer process itself. In this case, the virtual CPU status determining unit <b>3</b> can be omitted. Further, the guest OS <b>10</b>B indicates user, sys, iowait recognized by the guest OS <b>10</b>B itself to the virtual CPU usage statistics calculating unit <b>5</b>, and it is therefore feasible to totalize and accumulate the user time, the sys time and iowait time with the high accuracy.

Note that for simplicity, the guest OS <b>10</b>B may totalize and accumulate the user time, the sys time and iowait time. Then, the virtual machine monitor <b>1</b> may read the user time, the sys time and iowait time that are totalized and accumulated by the guest OS <b>10</b>B. The virtual CPU usage statistics calculating unit <b>5</b> receives, from the guest OS <b>10</b>B, the user time, the sys time and iowait time recognized by the guest OS <b>10</b>B, thereby enabling the statistical information to be acquired more precisely. Accordingly, t_sysand t_iogiven in the formulae 1 and 2 can be exactly acquired.

Moreover, the modulation ratio t_io/T_ioof the I/O time and the modulation ratio t_sys/T_sysof the kernel time may involve using values which are obtained empirically and experimentally beforehand. Specifically, the same operation system is operated on each of the guest OS <b>10</b>B on the virtual system <b>11</b> and the physical OS on the physical system <b>300</b>, at which time the I/O time and the kernel time are measured as t_io, t_sysand T_io, T_sys, respectively. The calculations in the formulae 1 and 2 are made by use of the I/O time modulation ratio and the kernel time modulation ratio, which are calculated by employing these values.

&lt;&lt;Computer-Readable Medium&gt;&gt;

The program for adding one of the above-mentioned functions to the computer, another machine or device (hereinafter, the computer etc.) can be recorded into the computer and the like readable medium. And, it is possible to perform the function thereof by making the computer and the like read the program from the computer etc-readable medium and execute the program.

Herein, the computer etc-readable medium connotes a recording medium capable of accumulating information such as the program and the data by electrical, magnetic, optical, chemical, physical, or mechanical action, and retaining the information in a readable-by-computer status. Moreover, in the computer etc-readable mediums, the attachable/detachable computer etc-readable medium can be exemplified by a flexible disk, a magneto optical disk, a CD-ROM, a CR-R/W, a DVD, a blu-ray disc, a DAT, an 8 mm tape, a memory card such as a flash memory. Furthermore, the computer etc-readable mediums fixedly installed in the computer etc. can be exemplified by a hard disk, a ROM (Read Only Memory).

All examples and conditional language recited herein are intended for pedagogical purposes to aid the reader in understanding the invention and the concepts contributed by the inventor to furthering the art, and are to be construed as being without limitation to such specifically recited examples and conditions, nor does the organization of such examples in the specification relate to a showing of the superiority and inferiority of the invention. Although the embodiment(s) of the present invention has (have) been described in detail, it should be understood that the various changes, substitutions, and alterations could be made hereto without departing from the spirit and scope of the invention.