JPH0926889A - Virtual machine system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To change the setting of the assigning amount of the processor for each VM from guests OS working on virtual machines(VM), in the virtual machine system composed of plural virtual machines and a virtual computer control program(VMCP) controlling these VM. SOLUTION: When the OS on a VM designates a specified VM and issues a processor assignment amount changing instruction, the control is passed to a VMCP 1 and the VMCP 1 changes the processor assigning amount of the VM which is set to a VM control table and is designated to a designated value. Subsequently, the VMCP 1 performs the scheduling in which processor time is assigned to the VM in accordance with the changed processor assigning amount.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a virtual computer system, and more particularly to a virtual computer system for controlling allocation scheduling of processor time allocated to each virtual machine (VM).

[0002]

2. Description of the Related Art A virtual computer system is composed of a plurality of virtual computers (VM) and a virtual computer control program (VMCP) for controlling these VMs. One operating system (OS) operates in each VM. VM
The CP and the OS of each VM are loaded and executed on the main memory of one real computer. One of the functions of the VMCP is scheduling of processor time allocation as a hardware resource for each VM. As a processor allocation method for VMs, there are an exclusive allocation method in which a processor is used exclusively by a specific VM and a shared allocation method in which a plurality of VMs share a processor.

In the shared allocation system of processors, each VM is
Is defined in advance, and the VMCP allocates the processor time to each VM that shares the processor time according to the processor allocation.

[0004]

When changing the definition value of the above-mentioned processor quota, the operator must change the VMC.
A command to P must be issued to change. For this reason, for example, when it is desired to change the processor allocation amount to the VM in the daytime and the nighttime, or in the hot standby system, the standby system and the active system are immediately switched after the system is switched from the active system to the standby system in an emergency. When it is desired to change the processor allocation amount, there is a problem that operator intervention is required, an operator error is likely to occur, an emergency response is delayed, and the system cannot be automatically operated.

An object of the present invention is to provide a virtual computer system that automatically changes the processor allocation amount according to changes in external conditions.

[0006]

According to the present invention, an OS issues a command to change a processor allocation amount by designating a specific VM according to a change in an external condition, and a VMCP designated V is designated.
The virtual machine system is characterized by changing the processor allocation amount of M.

[0007]

According to the operation schedule or the emergency situation, the processor quota of the related VM can be changed without operator intervention. Further, by comparing the definition value of the processor allocation amount and the actual processor usage time, the definition value of the processor allocation amount can be changed according to the excess or deficiency of the processor usage time.

[0008]

An embodiment of the present invention will be described below with reference to the drawings.

The hardware of the virtual machine system includes at least one instruction processor (IP), a main memory,
It is composed of an input / output control device and an input / output device. When the computer has a plurality of IPs, the plurality of IPs share a common main memory and operate in the form of so-called tightly coupled multiprocessors. The virtual machine system is composed of a plurality of virtual machines (VM) and a virtual machine control program (VMCP) that controls these VMs. Each VM
Then one operating system (OS) and this O
The processing program controlled by S operates. VM
The OS operating on the above is called a guest OS. VMCP,
The guest OS and the processing program are stored in the main storage device and executed by IP. Since the processor used by each VM is logical, I as a real processor
It is called a virtual IP to distinguish it from P. Each VM uses at least one virtual IP, and multiple VMs when the VM operates in a multiprocessor environment.
The VMCP temporarily assigns the real IP to the virtual IP set for each VM.

FIG. 1 is a diagram showing the functional configuration of the virtual computer system of this embodiment. In the figure, the dotted arrows indicate the direction of control, and the solid arrows indicate the passing of information. VM
CP1 performs scheduling for assigning an IP to each VM2. In order to distinguish each VM2, VM2-1, 2-2,
The numbers are attached like ... The guest OS and its processing program operate in each VM 2. The VM control table 3 is a table for managing each VM 2,
The M control tables 3-1, 3-2, ...
2-1, 2-2, ... The virtual IP management table 4 is a table for managing the allocation of the real IP to each virtual IP, and the virtual IP management tables 4-1, 4-2, ... Corresponding to the virtual IPs 1, 2 ,. The code is attached like. The operation schedule 5 is a file that stores information about the operation schedule of the VM. The operation schedule 5 is stored in the main storage device or the external storage device.

The VMCP 1 uses the VM control table 3 and the virtual IP management table 4 to perform scheduling for assigning an IP to each VM 2. When a processing program such as a computer operating program on the VM refers to the operation schedule 5 and changes the operation schedule, it issues a command to the guest OS. When the guest OS issues a processor quota change command, control is transferred to VMCP1 and VM
The CP 1 changes the processor allocation amount of the VM control table 3 corresponding to the VM, and thereafter schedules the VM according to the changed processor allocation amount.

FIG. 2A is a diagram showing an example of a data format of items related to the present invention in the VM control table 3 corresponding to each VM. The virtual IP number 31 is the number of the virtual IP set for this VM. The processor quota 33 defines the quota per IP unit to be assigned to this VM, and the quota is set by the number of time slices as a unit. The time slice is usually about 10 ms to 25 ms.

FIG. 2B is a diagram showing an example of the data format of items related to the present invention in the virtual IP management table 4 corresponding to each virtual IP. Processor allocation attribute 41
Is an identifier indicating whether the virtual IP is allocated to occupy the real IP or to be shared with another virtual IP. When the VM sets a plurality of virtual IPs, the processor allocation attributes 41 are all the same. The time slice allocation number 42 is a counter used for control when the VMCP 1 allocates a time slice to this virtual IP. The processor usage time 43 stores the cumulative value of the times when the virtual IP uses the real IP. The real IP number 44 is the real I assigned exclusively or temporarily to this virtual IP.
It is the P number. The VM control table 3 and the virtual IP management table 4 are set in the area of the VMCP 1 on the main storage device.

VMCP1 has a processor allocation attribute 41
For a virtual IP that sets a shared identifier in
VM control table 3 in which virtual IP number 31 of P is set
The value of the processor allocation amount 33 is set to the time slice allocation number 42. Next, the VMCP 1 allocates the first time slice of the real IP to the first virtual IP whose time slice allocation number 42 is 1 or more, and subtracts 1 from the time slice allocation number 42 of this virtual IP when the time slice expires.
The next time slice of the real IP is allocated to the next virtual IP whose time slice allocation number 42 is 1 or more, and when the time slice expires, the time slice allocation number 42 of the virtual IP.
Subtract 1 from. In this way, time slices are sequentially allocated to each virtual IP in a round-robin manner, and when the number of time slice allocations 42 of all virtual IPs becomes 0, the value of the processor allocation amount 33 is set again as described above. The slice allocation number 42 is set and the scheduling of processor time allocation to each VM by the time slice is repeated. VMCP1 is actually a virtual IP
Is counted, and the value is added to the processor usage time 43 for this virtual IP. If the processor is not used such as waiting for I / O before the VM runs out of the allocated time slice, the VMCP 1 terminates the time slice and allocates the next time slice to the next virtual IP. Therefore, the virtual IP processor usage time 43 set for each VM does not always accurately reflect the value defined in the processor allocation amount 33.

FIG. 3 is a diagram showing a processor quota change instruction 61 issued by the guest OS and the data format of its parameter area.

FIG. 3A shows the format of the instruction.
The processor quota change instruction 61 includes an instruction code, designation of the base register (B1) and displacement (D
It consists of the designation of 1). A request type code 63 and a parameter area address 64 are set in the operand area 62 obtained from B1 and D1. The request type code 63 designates the function requested by the instruction, and includes (1) a request for changing the processor quota 33, (2) a processor quota 3
There are three types of notification request of 3 and (3) notification request of the processor usage time 43. The parameter area address 64 specifies the start addresses of the parameter areas 65 and 70. The operand area 62 and the parameter areas 65 and 70 are set in the area of the guest OS on the main storage device.

In FIG. 3B, the request type code 63 is (1).
Parameter area 65 in case of request for changing processor quota 33 or (2) request for notifying processor quota 33
FIG. 3 is a diagram showing a data format of the data. The parameter area length 66 stores the area length of the parameter area 65. VMID67
Is the identification code of the target VM. Completion code 68
Sets the completion code when the instruction execution is completed. The processor allocation amount 69 stores the newly requested processor allocation amount when the request type code 63 is (1) a change request for the processor allocation amount 33, and is stored when the request type code 63 is (2) a notification request for the processor allocation amount 33. The processor allocation amount 33 of the VM is stored. Parameter area length 66, VMI
D67 and (1) the processor allocation amount 69 in the case of the request to change the processor allocation amount 33 is set by the guest OS. In the case of the notification request of the completion code 68 and (2) processor quota 33, the processor quota 69 is V
It is set by MCP1.

FIG. 3C is a diagram showing the data format of the parameter area 70 when the request type code 63 is (3) notification request of the processor usage time 43. The parameter area length 66 stores the area length of the parameter area 70. The VMID 67 and the completion code 68 are the same as those in the parameter area 65. The virtual IP number 31 and the processor usage time 43 are respectively the virtual IP number and the usage time of the real IP set for this VM. The parameter area length 66 and the VMID 67 are set by the guest OS. The completion code 68, the virtual IP number 31, and the processor usage time 43 are set by the VMCP 1.

FIG. 4 shows a processor quota change instruction 61.
6 is a flowchart showing a flow of processing of VMCP 1 that performs processing of FIG. When the guest OS issues the processor quota change instruction 61, the IP hardware detects that the instruction is a VM-related instruction and passes control to the VMCP 1. VM
The CP1 accesses the parameter areas 65 and 70 from the parameter area address 64 in the operand area 62 of the instruction and acquires the parameters (step 11). Then V
The identification code of the target VM is obtained from the MID 67, the VM control table 3 of the designated VM is referenced, the virtual IP management table 4 is referenced from the set virtual IP number 31, and the processor allocation attribute 41 is referenced. To do. If the processor allocation attribute 41 is shared (shared in step 12), the request type code is judged from the request type code 63 (step 13). If the request type code is a request for changing the processor quota 33, the processor quota 69 set in the parameter area 65 is set to the processor quota 33 of the designated VM (step 14). If the request type code is a notification request of the processor quota 33, the processor quota 33 of the specified VM is set to the processor quota 6 of the parameter area 65 of the guest OS.
9 (step 15). If the request type code is a notification request of the processor usage time 43, the specified V
The virtual IP number 31 set in the VM control table 3 of M and the corresponding processor usage time 43 are stored in the parameter area 70 (step 16). Step 14,
When the processing of 15 or 16 is finished, the VMCP 1 stores a normal code in the completion code 68 (step 17),
The process ends. If the processor allocation attribute 41 is occupied (step 12 occupied), the error end code is stored in the completion code 68 (step 18), and the process ends.

The process of the guest OS and the process program under the control of the guest OS will be described below as to how the above-mentioned processor quota changing instruction is used. Guest OS
Issues a processor quota notification request, it is possible to know the processor quota 33 of an arbitrary VM. Next, when the guest OS issues a processor usage time notification request, it is possible to know the actual processor usage time of the virtual IP set for the specified VM. The operation program under the control of this guest OS can calculate the processor usage time of each VM from the processor allocation amount of each VM and the elapsed time. By comparing the calculated processor usage time of each VM with the actual processor usage time, it is possible to determine whether the setting of the processor quota 33 of each VM is appropriate. If the processor quota 33 needs to be changed, a processor quota change request can be issued via the guest OS to change the processor quota 33 of the target VM. Further, by storing the actual processor usage time of each VM in the storage device, statistical information about the operation of the VM can be obtained. In addition, when changing the VM operating status between daytime and nighttime,
The object can be achieved by changing the processor allocation amount for the associated VM when the operation program reaches a predetermined time according to the operation schedule 5. For example, the processor quota of VM2-1 is increased and the processor quota of VM2-2 is decreased. Further, for example, VM2-1 is the active system, VM2-
In the hot standby system with 2 as the standby system,
When the system is switched from the active system to the standby system due to a hardware failure or software bug, the processor quotas of VM2-1 and VM2-2 are changed immediately after the system is switched, and many time slices are allocated to VM2-2. VM scheduling can be done to allocate It should be noted that even in the hot standby system in which the VMCP of the same version and the VM to be controlled are set in each of the two sets of real computers and the VM on one computer is the active system and the VM on the other computer is the standby system You can change the processor quota. In order for the VM on one computer and the VM on the other computer to communicate with each other, it is necessary that both computers are connected via a communication path or an external storage device.

According to this embodiment, the processor allocation amount of each VM can be changed at a target time according to the operation schedule of the computer without operator intervention. Further, in the hot standby system, the processor allocation amount of each VM can be changed immediately when the active VM is switched to the standby VM.

[0022]

According to the present invention, the processor quota of the related VM can be changed according to the change of the external condition without operator intervention, and the set value of the processor quota is compared with the actual processor usage time. By doing so, the processor allocation amount can be automatically adjusted.

[Brief description of drawings]

FIG. 1 is a diagram showing a configuration of a virtual computer system according to an embodiment.

FIG. 2 is a diagram showing a data format of a VM control table 3 and a virtual IP management table 4 according to the embodiment.

FIG. 3 is a diagram showing a data format of a processor quota change instruction and its parameter area according to the embodiment.

FIG. 4 is a VM that processes a processor quota change instruction.
It is a flow chart which shows a flow of processing of CP1.

[Explanation of symbols]

1: VMCP, 2: VM, 33: processor allocation amount,
61: Processor quota change instruction, 69: Processor quota

Claims (1)

[Claims] 1. A plurality of virtual machines (VMs) are set, and an operating system (OS) operating on each VM,
In a virtual machine system having a virtual machine control unit (VMCP) for scheduling allocation of processor time to each VM according to a processor quota set for each VM, the OS sets a specific VM according to a change in external conditions. A virtual machine system comprising means for issuing a command for designating and changing the processor allocation amount, and the VMCP having means for changing the processor allocation amount of a specified VM.