JP2017199044A - Virtual computer system, scheduling method, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To quickly process requests with a large number of stay or requests with a long stay period in a virtual computer system.SOLUTION: A virtual computer system comprises: a guest OS 20; and a hypervisor 30. The guest OS comprises: a storage part for storing received requests; and a request part 22 for issuing a hypervisor call including an identifier of a virtual CPU to the hypervisor. The hypervisor comprises a change part 32 for changing an execution time of a physical CPU allocated to a thread which executes the virtual CPU corresponding to the identifier. When the number of unprocessed requests stored in the storage part exceeds a predetermined number, or the stay period of the unprocessed requests stored in the storage part exceeds a predetermined period, the request part issues the hypervisor call including the identifier of the virtual CPU which executes an application for processing the unprocessed requests.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a virtual machine system, a scheduling method, and a program, and more particularly to a virtual machine system including a virtual machine built on a physical machine, a scheduling method in the virtual machine system, and a program.

  The virtual computer system is a system in which a plurality of virtual computers are constructed on one physical computer. In the virtual machine system, an OS called a “guest OS (Operating System)” operates on each virtual machine. On the other hand, an OS operating on a physical computer is referred to as a “virtual machine monitor (VMM)”.

  The guest OS manages applications that run on the guest OS in the same way as a normal OS. On the other hand, the VMM manages the virtual machine as its own application. A resource that the guest OS gives to an application under management is called a “virtual CPU (Central Processing Unit)”. A virtual CPU is a pseudo CPU created by a software program and operates as a thread on a physical computer. On the other hand, the resource that the VMM gives to the virtual machine is called “physical CPU”.

  In the virtual machine system, there is a problem that an application on the guest OS does not operate normally due to temporal “deviation” between the scheduling by the VMM and the scheduling by the guest OS. In order to operate the application, a virtual CPU must be allocated to the guest OS and a physical CPU must be allocated to the VMM. The guest OS scheduler to which the virtual CPU is assigned and the VMM scheduler to which the physical CPU is assigned do not know when the other party assigns the CPU to the application.

  Therefore, even if the guest OS assigns a virtual CPU to an application, the VMM may not assign a physical CPU to the virtual machine. In this case, the application cannot be executed. Conversely, even if the VMM assigns a physical CPU to a virtual machine, the guest OS may not assign a virtual CPU to an application. In this case, the CPU time of the allocated physical CPU is wasted.

  A technique for solving such a problem is described in Patent Document 1 as an example. FIG. 16 is a block diagram illustrating the configuration of the virtual machine system described in Patent Document 1.

  Referring to FIG. 16, the virtual machine system 1 includes a physical machine 2. The physical computer 2 includes a virtual computer 5, a VMM 3, and hardware 4. The virtual machine 5 includes a guest OS 6. The VMM 3 includes a guest OS interface unit 7, a guest OS dependency creation module 8, a guest OS dependency table 9, a dispatcher 10, a CPU allocation table 11, and a guest OS scheduler 12. The hardware 4 includes a CPU 13. Furthermore, the guest OS scheduler 12 includes a CPU allocation table management unit 14, a determination unit 15, a server guest OS schedule unit 16, a client guest OS search unit 17, and a client guest OS schedule unit 18.

  The virtual machine system shown in FIG. 16 operates as follows. That is, the guest OS interface unit 7 of the VMM 3 is configured such that when an arbitrary guest OS that functions as a client of the guest OS 6 requests processing from another guest OS that functions as a server, the guest OS that is the processing request source is the client. And includes an interface for notifying the VMM 3 of the server / client relationship in which the guest OS requested to be processed is a server. The guest OS scheduler 12 of the VMM 3 adjusts the time for allocating the CPU to the guest OS 6 based on the server / client relationship notified by this interface.

JP 2010-218151 A

  The entire disclosure of the above patent document is incorporated herein by reference. The following analysis was made by the present inventors.

  According to the virtual machine system described in Patent Literature 1, it is not considered on which virtual CPU of the virtual machine the application is operating, and the application may not operate.

  The reason is that the physical CPU time to be allocated is adjusted for the guest OS. As described in the background art, an application can be executed by simultaneously assigning a virtual CPU and a physical CPU. The guest OS does not necessarily have one virtual CPU. Further, the number of physical CPUs of the VMM is not limited to one. In other words, if there is a virtual CPU assigned to the application by the guest OS, and the physical CPU is not assigned to a thread that embodies the assigned virtual CPU on the VMM, the application does not operate.

  In the virtual machine system described in Patent Document 1, a percentage of the physical CPU usage rate is given to the guest OS, and it is possible to determine which virtual CPU (thread) can be assigned a physical CPU. Can not. As an example, it is assumed that a certain virtual machine holds four virtual CPUs 1 to 4. Also, threads on the VMM that embody the virtual CPUs 1 to 4 are referred to as threads 1 to 4, respectively. Here, it is assumed that the virtual CPU 1 is assigned to the application. At this time, the thread to which the VMM should allocate a physical CPU is thread 1. However, in the virtual machine system described in Patent Document 1, the VMM does not have a function of allocating a physical CPU to the thread 1 when the virtual CPU 1 is allocated to an application.

  Further, in the virtual machine system described in Patent Document 1, there is a possibility that extra physical CPU time is allocated because the staying amount of requests is not taken into consideration.

  This is because the allocated physical CPU time is not used unless there is a request exchanged between the client and the server. In Patent Document 1, each of a virtual machine serving as a client and a virtual machine serving as a server registers a relationship with the VMM. That is, the client designates a virtual machine that becomes a server, and the server designates a virtual machine that becomes a client. Thereby, the relationship between the client and the server is built in the VMM, and the physical CPU time required for each virtual machine is adjusted. However, it is not considered whether the client and server actually exchange requests. Therefore, even when the client and the server are not transmitting / receiving a request, there is a possibility that physical CPU time is allocated.

  Therefore, in the virtual machine system, it is a problem to quickly process a request with a large number of stays or a request with a long stay period. An object of the present invention is to provide a virtual machine system, a scheduling method, and a program that contribute to solving such a problem.

  A virtual machine system according to a first aspect of the present invention includes a guest OS (Operating System) and a hypervisor, and the guest OS stores a storage unit that stores received requests and an identifier of a virtual CPU (Central Processing Unit). A change unit that changes the execution time of a physical CPU allocated to a thread that realizes a virtual CPU corresponding to the identifier. The request unit has a predetermined residence time of the unprocessed requests accumulated in the storage unit when the number of unprocessed requests accumulated in the storage unit exceeds a predetermined number. A hypervisor call including an identifier of a virtual CPU that executes an application that processes the unprocessed request Issue.

  The scheduling method according to the second aspect of the present invention includes a step in which a guest OS (Operating System) accumulates received requests in a storage unit and a hypervisor call including a virtual CPU (Central Processing Unit) identifier. And the step of changing the execution time of the physical CPU allocated to the thread that realizes the virtual CPU corresponding to the identifier, wherein the guest OS is configured to store the storage unit When the number of unprocessed requests accumulated in the storage unit exceeds a predetermined number, or when the retention period of the unprocessed requests accumulated in the storage unit exceeds a predetermined period, the unprocessed requests are A hypervisor call including an identifier of a virtual CPU that executes an application to be processed is issued.

  A program according to a third aspect of the present invention is a program that causes a guest OS (Operating System) to store a received request in a storage unit and a hypervisor call including a virtual CPU (Central Processing Unit) identifier to the hypervisor. Processing executed by the hypervisor, and processing for changing the execution time of the physical CPU assigned to the thread that realizes the virtual CPU corresponding to the identifier is executed by the computer and stored in the storage unit. When the number of unprocessed requests exceeds a predetermined number, or when the retention period of unprocessed requests accumulated in the storage unit exceeds a predetermined period, the application that processes the unprocessed requests A process in which the guest OS issues a hypervisor call including an identifier of a virtual CPU that executes To be executed in. The program can also be provided as a program product recorded on a non-transitory computer-readable storage medium.

  According to the virtual computer system, the scheduling method, and the program according to the present invention, it is possible to quickly process a request with a large number of stays or a request with a long stay period in the virtual machine system.

It is a block diagram which illustrates the composition of the virtual machine system concerning one embodiment. It is a block diagram which illustrates the composition of the virtual machine system concerning a 1st embodiment. It is a figure which illustrates the structure of the stay request memory | storage part in 1st Embodiment. It is a figure explaining the data structure of the SIP (Session Initiation Protocol) request in a 1st embodiment. It is a figure explaining the structure of the scheduling queue in 1st Embodiment. It is a flowchart which illustrates operation | movement of the virtual machine system which concerns on 1st Embodiment. It is a block diagram which illustrates the composition of the virtual machine system concerning a 2nd embodiment. It is a flowchart which illustrates operation | movement of the virtual machine system which concerns on 2nd Embodiment. It is a block diagram which illustrates the composition of the virtual machine system concerning a 3rd embodiment. It is a block diagram which illustrates the composition of the virtual machine system concerning a 4th embodiment. It is a figure which illustrates the data structure of the priority table in 4th Embodiment. It is a figure which illustrates the example of priority creation in 4th Embodiment. It is a figure which illustrates the data structure of the stay request memory | storage part after the priority addition in 4th Embodiment. It is a flowchart which illustrates operation | movement of the virtual computer system which concerns on 4th Embodiment. It is a block diagram which illustrates the composition of the virtual machine system concerning a 5th embodiment. 2 is a block diagram illustrating a configuration of a virtual computer system described in Patent Document 1. FIG.

  First, an overview of a virtual machine system according to an embodiment will be described. Note that the reference numerals of the drawings attached to this summary are merely examples for facilitating understanding, and are not intended to limit the present invention to the illustrated embodiment.

  FIG. 1 is a block diagram illustrating a configuration of a virtual machine system according to an embodiment. Referring to FIG. 1, the virtual machine system includes a guest OS (Operating System) 20 and a hypervisor 30, and the guest OS 20 issues a hypervisor call including an identifier of a virtual CPU (Central Processing Unit) to the hypervisor 30. The hypervisor 30 has a changing unit 32 that changes the execution time of the physical CPU assigned to the thread that realizes the virtual CPU corresponding to the identifier.

  According to such a virtual machine system, it is possible to appropriately allocate the execution time of a physical CPU to a thread that realizes a virtual CPU that executes an application. This is because the guest OS 20 issues a hypervisor call by designating a virtual CPU on which an application for processing a request arriving at a virtual machine running the guest OS 20 is executed, and the hypervisor is a thread that realizes the designated virtual CPU. This is because the execution time of the physical CPU can be changed.

  Referring to FIG. 2, the guest OS 100 includes a first queue (scheduling queue 170) that holds an application that processes an accepted request and an identifier of a virtual CPU that executes the application, and the request unit 120 includes: By referring to the first queue (170), the identifier of the virtual CPU that executes the application may be specified, and a hypervisor call including the identifier of the specified virtual CPU may be issued.

  Further, the guest OS 100 includes a storage unit (the stay request storage unit 150) that stores the received requests, and the request unit 120 has the number of unprocessed requests stored in the storage unit (150) exceeding a predetermined number. Or when the retention period of unprocessed requests accumulated in the storage unit (150) exceeds a predetermined period, the hypervisor call including the identifier of the virtual CPU that executes the application that processes the unprocessed requests May be issued.

  According to such a virtual computer system, depending on the number of staying requests or the staying period of requests, a physical CPU is preferentially assigned to a thread corresponding to a virtual CPU that executes an application that processes the request. Execution time can be assigned. Therefore, it is possible to quickly process a staying request or a request having a long staying period.

  Referring to FIG. 7, the hypervisor 200 includes a second queue (scheduling queue 240) that holds the threads classified according to priority and the physical CPU that executes the threads according to the priority in association with each other. The changing unit (execution time changing unit 220) extends the execution time of the thread when the thread that realizes the virtual CPU corresponding to the identifier is being executed on the physical CPU, and otherwise, The priority in the second queue (240) and / or the order of the thread in the second queue (240) may be changed.

  According to such a virtual machine system, for a virtual CPU that executes a specific application, if the application is running on a physical CPU, the execution time is extended. Execution can be started on the physical CPU immediately after completion.

  Referring to FIG. 10, the guest OS 100 includes a priority calculation unit 180 that calculates the priority of an accepted request, and the request unit 120 stores unprocessed requests accumulated in the storage unit (the stay request storage unit 150). When the priority exceeds a predetermined priority, a hypervisor call including an identifier of a virtual CPU that executes an application that processes an unprocessed request may be issued.

  According to such a virtual machine system, it is possible to preferentially allocate the execution time of a physical CPU to a thread that realizes a virtual CPU that executes an application that processes a request with high priority.

  Referring to FIG. 9, the hypervisor 200 includes a warning unit (limit load warning unit 270) that outputs a warning when the frequency of hypervisor calls issued by the request unit (request unit 120) exceeds a predetermined frequency. You may have.

  According to such a virtual machine system, when the number of hypervisor calls per unit time exceeds a threshold, an alarm is issued to the user, thereby exceeding the processing capacity for the virtual machine on which the guest OS runs. The user can be notified that the request has arrived.

<Embodiment 1>
Next, the virtual machine system according to the first embodiment will be described in detail with reference to the drawings. FIG. 2 is a block diagram illustrating the configuration of the virtual machine system of this embodiment.

  Referring to FIG. 2, the virtual computer system of the present embodiment includes a virtual machine 300 and a hypervisor 200. The virtual machine 300 includes a guest OS (Operating System) 100. The guest OS 100 includes a UDP (User Datagram Protocol) packet transmission / reception unit 110, a SIP (Session Initiation Protocol) processing amplification determination unit 140, a thread activation unit 160, a retention amount acquisition unit 130, a retention request storage unit 150, a request unit 120, and A scheduling queue 170 is provided. The hypervisor 200 includes a receiving unit 210, an execution time changing unit 220, a scheduler 230, and a scheduling queue 240.

  The UDP packet transmission / reception unit 110 transmits / receives a UDP packet within the guest OS 100. When the arrived UDP packet is a SIP request, the UDP packet transmission / reception unit 110 creates a stay request identifier 151 from the SIP request and stores the stay request identifier 151 in the stay request storage unit 150. The UDP packet transmitting / receiving unit 110 executes the SIP processing amplification determination unit 140 after storing the stay request identifier 151. Further, when the UDP packet transmitting / receiving unit 110 encapsulates the SIP request in a UDP packet and transmits it to another physical computer, since the SIP request has been processed, the stay request identifier 151 matches from the stay request storage unit 150. Delete the entry.

  The SIP processing amplification determination unit 140 acquires the request retention amount calculated by the retention amount acquisition unit 130 and determines whether to issue a scheduling policy change request to the hypervisor 200. The SIP processing amplification determination unit 140 issues a scheduling policy change request when the number of staying requests exceeds a predetermined number. Here, it is assumed that the predetermined number is set in advance by the user. Further, the SIP processing amplification determination unit 140 issues a scheduling policy change request when the stay period of a stay request exceeds a predetermined period. The predetermined period is set in advance by the user.

  However, when T1 which is the SIP default timeout time is used as the predetermined period, setting by the user is not required. Here, T1 is the time when retransmission of the SIP request is started, and the default value is 500 ms. The value of T1 can be changed, and the current value of T1 is stored in the setting file of the SIP server (application on the virtual machine 300). The SIP process amplification determination unit 140 confirms the current value of T1 in advance from the setting file of the SIP server before starting the process.

  The thread activation unit 160 activates a thread. The application includes a plurality of threads. Specifically, when a UDP packet arrives, the thread activation unit 160 activates a thread that processes the UDP packet.

  The stay amount acquisition unit 130 counts the number of stay requests stored in the stay request storage unit 150 and notifies the SIP processing amplification determination unit 140 of the count. In addition, the stay amount acquisition unit 130 updates the period during which the stay request stored in the stay request storage unit 150 stays in the guest OS 100. The stay amount acquisition unit 130 is periodically started by a timer or the like, and increments the stay period 152 of the stay request stored in the stay request storage unit 150.

  The stay request storage unit 150 stores information regarding requests currently staying on the virtual machine 300. FIG. 3 illustrates the contents of the table held by the stay request storage unit 150. The stay request storage unit 150 holds the stay request identifier 151 and the stay period 152 in association with each other. When the UDP packet including the SIP request arrives, the UDP packet transmission / reception unit 110 generates a stay request identifier 151.

  FIG. 4 illustrates the data structure of a SIP request. The UDP packet transmission / reception unit 110 generates a stay request identifier 151 using “Call-ID” and “CSeq” shown in FIG. As an example, the UDP packet transmission / reception unit 110 sets Call-ID and CSeq connected by an underbar as a stay request identifier 151 (FIG. 3). However, it is only necessary that the identifier can be expressed uniquely using Call-ID and CSeq. Therefore, the stay request identifier 151 is not limited to the aspect shown in FIG. Further, when the UDP packet transmission / reception unit 110 transmits a processed SIP request to the request request source, the UDP packet transmission / reception unit 110 deletes the entry having the same retention request identifier 151 from the retention request storage unit 150.

  The request unit 120 requests the hypervisor 200 to extend the execution time given to the thread that implements the virtual CPU. The request unit 120 does not know the thread number that is paired with the virtual CPU number when issuing the scheduling policy change request. Therefore, the request unit 120 issues a hypervisor call with the virtual CPU number as an argument. The hypervisor 200 holds a table that is a pair of a virtual CPU number and a thread number. The hypervisor call is provided in hardware used for the virtual machine 300 to voluntarily request “some processing” from the hypervisor 200, similar to a system call of a general OS. It is a function. In the present embodiment, the virtual machine 300 requests the hypervisor 200 to change the scheduling policy as an example of “some processing”.

  The scheduling queue 170 is a data structure that manages CPU allocation of applications executed on the virtual machine 300. FIG. 5 illustrates the data structure of the scheduling queue 170. A scheduling queue 170 is created for each CPU included in the computer.

  Note that the data structure of the scheduling queue 170 of the virtual machine 300 and the data structure of the scheduling 240 of the hypervisor 200 are the same. However, when FIG. 5 is regarded as the scheduling queue 170 on the guest OS 100, the CPU of FIG. 5 represents a virtual CPU. On the other hand, when FIG. 5 is regarded as the scheduling queue 240 on the hypervisor 200, the CPU of FIG. 5 represents a physical CPU.

  In the scheduling queue 170, an application waiting for execution (“Process” in FIG. 5) is registered. The scheduler 230 selects an application to be executed next from the scheduling queue 170. In the scheduling queue 170 illustrated in FIG. 5, the queue is divided for each priority 153. If the priority 153 having a small number is set as the high priority, the scheduler 230 first selects Process A. In the present embodiment, the request unit 120 uses the scheduling queue 170 to confirm in which virtual CPU the SIP application that processes the arrived SIP request is scheduled to be executed. In FIG. 5, the SIP application (“SIP Process” in FIG. 5) is registered in CPU # 1. At this time, if it is determined that the change request is issued, the SIP processing amplification determination unit 140 executes the request unit 120 with the CPU # 1 as an argument.

  The accepting unit 210 accepts the scheduling policy change request sent from the request unit 120. The accepting unit 210 converts the sent virtual CPU number into a thread number and executes the execution time changing unit 220 in order to extend the CPU time given to the thread having the thread number.

  The execution time changing unit 220 extends the CPU time given to the thread. The scheduler 230 provided in the guest OS 100 or the hypervisor 200 executes the thread selected from the scheduling queue 170 on the CPU. The scheduler 230 gives execution time to the thread at the start of execution of the thread. Until the given execution time elapses, the thread proceeds with its own processing using the CPU. When the execution time given by the scheduler 230 elapses, the scheduler 230 selects the next thread from the scheduling queue 170 and gives the CPU time. The thread that has consumed the given execution time is stored in the scheduling queue 170 by the scheduler 230. The scheduler 230 manages the execution time. The execution time changing unit 220 extends the execution time when a thread on the hypervisor 200 that implements the virtual CPU is being executed.

  The scheduler 230 appropriately executes threads registered in the scheduling queue 240 on the CPU. When executing a thread, execution time is assigned to the thread as described above. The thread can proceed with processing for a given execution time. The scheduler 230 manages the execution time of the currently executing thread. The execution time changing unit 220 changes the execution time managed by the scheduler 230.

  When the SIP request is sent based on the above configuration, the virtual computer system according to the present embodiment confirms the request amount that has already stayed, and if the staying request exceeds a certain threshold, Extends the physical CPU time allocated to the virtual CPU that is processing the SIP request. Thereby, sufficient physical CPU time for request processing is obtained.

  Next, the operation of the virtual machine system (FIG. 2) of this embodiment will be described in detail with reference to the flowchart of FIG.

  First, the UDP packet transmitting / receiving unit 110 receives a UDP packet (step S1). Next, the UDP packet transmitting / receiving unit 110 extracts the SIP header from the UDP packet (step S2). The UDP packet transmission / reception unit 110 creates a stay request identifier 151 when extracting the SIP header.

  Next, the SIP processing amplification determination unit 140 refers to the stay request storage unit 150 and checks the current request stay amount (step S3). The SIP processing amplification determination unit 140 obtains the request retention amount by counting the number of entries in the retention request storage unit 150 via the retention amount acquisition unit 130.

  When the SIP processing amplification determination unit 140 determines that the request retention amount exceeds the threshold (Yes in Step S4), the request unit 120 acquires the virtual CPU number on which the SIP server is executed (Step S5), and A hypervisor call is issued with the virtual CPU number as an argument (step S6).

  The accepting unit 210 receives the hypervisor call and extends the execution time of the thread corresponding to the virtual CPU included in the hypervisor call (step S7).

  Next, the SIP processing amplification determination unit 140 registers the SIP request that has arrived at the stay request storage unit 150. Specifically, the SIP processing amplification determination unit 140 creates an entry that is a set of the stay request identifier 151 and the stay period 152 created first, and adds the entry to the stay request storage unit 150 (step S8). At the time of entry addition, the residence period 152 is set to zero. The staying amount acquisition unit 130 periodically increments the staying period 152.

  On the other hand, when the request staying amount is equal to or less than the threshold (No in Step S4), only Step S8 is executed and the process is terminated.

  In the virtual machine system of this embodiment, when a SIP packet arrives, it is possible to request an additional physical CPU time from the hypervisor after confirming the amount of requests remaining in the virtual machine.

  In particular, according to the present embodiment, a virtual CPU that requires a physical CPU can be specified and a physical CPU can be assigned. The reason is that the scheduling queue on the virtual machine is confirmed and the hypervisor is informed on which virtual CPU an incoming request is executed.

  Further, according to the present embodiment, a physical CPU for request processing can be sufficiently allocated to a request staying in a server (corresponding to an application in the background art). The reason is that the number of requests arriving at the server and the number of requests sent back to the client after processing on the server are monitored, the difference is stored as a stay request, and the staying request exceeds a certain threshold This is because the physical CPU time allocated to the virtual CPU that is processing the SIP request is extended.

<Embodiment 2>
Next, a virtual computer system according to the second embodiment will be described in detail with reference to the drawings.

  FIG. 7 is a block diagram illustrating the configuration of the virtual machine system according to this embodiment. Referring to FIG. 7, the virtual machine system according to the present embodiment further includes an execution priority changing unit 250 and an execution queue rearranging unit 260 on the hypervisor 200 of the virtual machine system (FIG. 2) according to the first embodiment. It has.

  Each of these units operates as follows.

  The execution priority changing unit 250 changes the priority 153 of the thread registered in the scheduling queue 240. Referring to FIG. 5, the scheduling queue 240 holds an array divided for each priority 153, and an application that requests CPU time (denoted as Process in FIG. 5) is registered in the array. Yes.

  Here, “changing the execution priority” means that an application is moved from one priority 153 array to another priority 153 array. In FIG. 5, the SIP Process is registered in the priority 2 array. When the execution priority of the SIP Process is changed, for example, the SIP Process is registered in an array of priority 0. The execution priority changing unit 250 changes the priority 153 of the application to, for example, the highest priority 153 (priority 0 in the case of FIG. 5). However, the execution priority changing unit 250 may accept designation of the priority of the change destination from the user.

  The execution queue rearrangement unit 260 changes the order of threads in the array of threads registered in the scheduling queue 240. Referring to FIG. 5, the scheduling queue 240 divides and holds the thread array for each priority 153. In the array, an application requesting CPU time (“Process” in FIG. 5) is registered.

  “Reordering the execution queue” means rearranging the order of the threads included in the array divided for each priority 153. In FIG. 5, SIP Process is arranged behind Process D. At this time, when executing the application with the priority 2, the scheduler 230 first selects Process D as the application. The execution queue rearrangement unit 260 arranges the target application at the top of the array. In the case of the scheduling queue 240 illustrated in FIG. 5, the execution queue rearrangement unit 260 changes the order of SIP Process and Process D.

  Next, the operation of the virtual machine system (FIG. 7) of this embodiment will be described in detail with reference to the flowchart of FIG.

  The operation illustrated in the flowchart of FIG. 8 is started after the reception unit 210 receives a request from the virtual machine 300. In the first embodiment, after receiving the request, the execution time changing unit 220 changes the execution time of the thread corresponding to the sent virtual CPU. On the other hand, in this embodiment, even when the corresponding thread is waiting to be executed and is registered in the scheduling queue 240, it is possible to assign an execution time to the SIP server immediately after the currently executing application is terminated. Become.

  First, the request unit 120 issues a hypervisor call (Step S6).

  Next, the accepting unit 210 confirms whether a thread corresponding to the virtual CPU notified in the hypervisor call is being executed (step S9). If the thread is being executed (Yes in step S10), the execution time changing unit 220 extends the execution time of the thread corresponding to the transmitted virtual CPU (step S7).

  On the other hand, when the thread is not being executed (No in step S10), the execution priority changing unit 250 increases the priority 153 of the thread (step S11). Next, the execution queue rearrangement unit 260 changes the order of the run queue in which the thread is stored (step S12).

  Steps S11 and S12 will be described with reference to FIG. If the application is a SIP Process, the execution priority changing unit 250 changes the SIP Process registration destination array to a zero priority array, and then the execution queue rearranging unit 260 sets the Process A in the priority 0 array. Move the SIP Process forward.

  Next, the effect of this embodiment will be described. In this embodiment, even when the CPU time is not given to the target SIP server and it is registered in the scheduling queue 240, the execution priority changing unit 250 and the execution queue rearranging unit 260 are used in combination. As a result, the execution time can be allocated to the SIP server immediately after the currently executing application is terminated.

<Embodiment 3>
Next, a virtual computer system according to a third embodiment will be described in detail with reference to the drawings.

  FIG. 9 is a block diagram illustrating the configuration of the virtual machine system according to this embodiment. Referring to FIG. 9, this embodiment further includes a limit load warning unit 270 and an execution history storage unit 280 on the hypervisor 200 of the virtual computer system (FIG. 2) of the first embodiment.

  Each of these units operates as follows.

  The execution history storage unit 280 stores how many times the scheduling policy change request sent from the virtual machine 300 is sent per unit time.

  The limit load warning unit 270 confirms the execution history storage unit 280 and issues an alarm to the user when the scheduling policy change request per unit time exceeds the threshold. The alarm may be a voice or a display on a GUI (Graphical User Interface). However, the mode of the alarm issued by the limit load warning unit 270 is not limited to these.

  Next, the effect of this embodiment will be described. In the present embodiment, the limit load warning unit 270 checks the execution history storage unit 280, and issues an alarm to the user when the scheduling policy change request per unit time exceeds the threshold. Therefore, it is possible to notify the user that an amount of requests that cannot be processed on the virtual machine 300 remains.

<Embodiment 4>
Next, a virtual machine system according to a fourth embodiment will be described in detail with reference to the drawings.

  FIG. 10 is a block diagram illustrating the configuration of the virtual machine system according to this embodiment. Referring to FIG. 10, the virtual machine system of this embodiment further includes a priority calculator 180 and a priority table 190 on the virtual machine 300 of the virtual machine system (FIG. 2) of the first embodiment. Yes.

  Each of these units operates as follows.

  The priority calculation unit 180 uses the priority table 190 to store the information on the request source (From entry) and the request destination (To entry) described in the received SIP (Session Initiation Protocol) request. Convert to The priority calculation unit 180 records the converted priority 192 as an additional entry in the stay request storage unit 150.

  The priority table 190 is a table that summarizes the relationship between the request source (From entry) and the request destination (To entry) information and the priority 192. FIG. 11 illustrates the contents of the priority table 190. Referring to FIG. 11, the priority table 190 holds a telephone number 191 and a priority 192 in association with each other. The telephone number 191 indicates a From entry or To entry in SIP. For example, when “110” is entered in the From entry, the priority 192 is 1. On the other hand, in the case of a normal number (such as a user ID), the priority 192 is 60.

  A procedure for creating the priority 192 from SIP will be described with reference to FIG. The priority calculation unit 180 refers to the SIP protocol in the left column of FIG. 12 and confirms the From entry and To entry. In the left column of FIG. 12, the From entry is “0901234567”, while the To entry is “110”. The telephone numbers described in the From entry and To entry correspond to the telephone number 191 in the priority table 190 (FIG. 11). The right column of FIG. 12 shows an example of creating the priority 192 by the priority calculation unit 180.

  First, the priority calculation unit 180 converts each of the From entry and the To entry into the priority 192 using the priority table 190. The From entry “0901234567” has “090” in the third digit from the left. A telephone number 191 beginning with “090,080,070” is a mobile telephone number in Japan. Therefore, the priority of the telephone number of the From entry is 50 from the priority table 190. On the other hand, the priority of the telephone number “110” of the To entry is 1 from the priority table 190. The priority calculation unit 180 sends the priority “51” obtained by adding the priorities “50” and “1” to the stay request storage unit 150.

  Here, as an example, a method of creating a priority by addition is shown. However, the priority calculation unit 180 may use another method using the From entry and To entry and the priority table 190. For example, the priority calculation unit 180 may generate the priority of the SIP session by multiplying the priority of the From entry and the priority of the To entry. Further, the priority calculation unit 180 may use the higher priority of the priority of the From entry and the To entry as the priority of the SIP session.

  FIG. 13 shows a state when the priority 192 is added to the table held by the stay request storage unit 150.

  Next, the operation of the virtual computer system (FIG. 10) of this embodiment will be described in detail with reference to the flowchart of FIG.

  First, the UDP (User Datagram Protocol) packet transmission / reception unit 110 receives a UDP packet (step S1). Next, the UDP packet transmitting / receiving unit 110 extracts the SIP header from the UDP packet (step S2). Further, the UDP packet transmission / reception unit 110 creates a stay request identifier 151 when extracting the SIP header.

  Next, the priority calculation unit 180 calculates the priority 192 of the request (step S13). The calculation method of the priority 192 by the priority calculation unit 180 is as described above with reference to the priority table 190.

  Next, the request unit 120 confirms the priority 192 of the arrived request (step S14). When there is a request with high priority (Yes in step S15), the request unit 120 acquires a virtual CPU number on which the SIP server is executed (step S5), and uses the virtual CPU number as an argument as a hypervisor call (Hypervisor call). ) Is issued (step S6).

  The accepting unit 210 receives the hypervisor call and extends the execution time of the thread corresponding to the transmitted virtual CPU using the execution time changing unit 220 (step S7).

  Next, the SIP processing amplification determination unit 140 registers the SIP request that has arrived at the stay request storage unit 150. Specifically, the SIP processing amplification determination unit 140 creates an entry that is a set of the stay request identifier 151 and the stay period 152 created first, and adds the entry to the stay request storage unit 150 (step S8). At this time, the residence period 152 is set to zero. The staying amount acquisition unit 130 periodically increments the staying period 152.

  On the other hand, when there is no high priority request (No in step S15), only step S8 is executed and the process is terminated.

  In the virtual machine system of this embodiment, when a high priority SIP request exists, the thread execution time is extended. Thereby, the CPU time can be allocated to the SIP server regardless of the number of staying requests and the staying period.

<Embodiment 5>
Next, a virtual machine system according to a fifth embodiment will be described with reference to the drawings. This embodiment corresponds to a specific implementation example of the virtual machine system according to the first embodiment.

  FIG. 15 is a block diagram illustrating the configuration of the virtual machine system of this embodiment. Referring to FIG. 15, in the present embodiment, Linux (registered trademark) 400 is used as the guest OS 100 executed on the virtual machine 300, and KVM 500 is used as the hypervisor 200. In the reception process of the UDP packet transmission / reception unit 110, the sock_def_readable function 410 in the Linux kernel is used. Further, a try_to_wake_up function 460 is used as the thread activation unit 160. Further, the PVOP_VCALL3 function 420 is used as a hypervisor call issued by the request unit 120. Further, run_queue 470 is used as the scheduling queue 170.

  A schedule function 530 is used as the scheduler 230 in the KVM 500. Further, run_queue 540 is used as the scheduling queue 240.

  Usually, the sock_def_readable 410 is a function that is executed after the Linux 400 finishes the UDP packet processing and before the data in the packet is passed to the user program. Sock_def_readable 410 executes a try_to_wake_up function 460 after executing its own process, and starts an application that processes a UDP packet. In the present embodiment, when the sock_def_readable function 410 executes the SIP processing amplification determination unit before executing the try_to_wake_up function 460 and extends the given CPU time, the hypervisor call is issued using the PVOP_VCALL3 function 420. To work. Accordingly, the virtual computer system according to the first embodiment can be realized based on Linux 400 and KVM 500.

  The virtual computer system, the scheduling method, and the program according to the present invention can be applied to applications such as stabilization of the quality of telephone services in the field of NFV (Network Functions Virtualization) that provides telephone services by virtual machines as an example. it can.

In the present invention, the following modes are possible.
[Form 1]
The virtual computer system according to the first aspect is as described above.
[Form 2]
The guest OS includes a first queue that holds an application that processes an accepted request and an identifier of a virtual CPU that executes the application,
The request unit refers to the first queue, identifies an identifier of a virtual CPU that executes the application, and issues a hypervisor call including the identified virtual CPU identifier.
The virtual computer system according to aspect 1.
[Form 3]
The guest OS includes a storage unit that accumulates received requests,
The request unit is configured such that when the number of unprocessed requests accumulated in the storage unit exceeds a predetermined number, or the retention period of unprocessed requests accumulated in the storage unit exceeds a predetermined period A hypervisor call including an identifier of a virtual CPU that executes an application that processes the unprocessed request,
The virtual computer system according to mode 1 or 2.
[Form 4]
The hypervisor includes a second queue that holds a thread classified according to priority and a physical CPU that executes the thread according to the priority in association with each other.
The change unit extends the execution time of the thread when the thread that realizes the virtual CPU corresponding to the identifier is being executed on the physical CPU; otherwise, the change unit in the second queue of the thread Changing the priority and / or the order of the thread in the second queue;
The virtual machine system according to any one of forms 1 to 3.
[Form 5]
The guest OS includes a priority calculation unit that calculates the priority of the received request,
The request unit includes a hypervisor call including an identifier of a virtual CPU that executes an application that processes the unprocessed request when the priority of the unprocessed request accumulated in the storage unit exceeds a predetermined priority. Issue,
The virtual machine system according to any one of forms 1 to 4.
[Form 6]
The hypervisor includes a warning unit that outputs a warning when the frequency of a hypervisor call issued by the request unit exceeds a predetermined frequency.
The virtual machine system according to any one of forms 1 to 5.
[Form 7]
The scheduling method according to the second aspect is as described above.
[Form 8]
The guest OS associating an application that processes the received request with an identifier of a virtual CPU that executes the application in a first queue;
Referring to the first queue, identifying an identifier of a virtual CPU that executes the application, and issuing a hypervisor call including the identified identifier of the virtual CPU.
The scheduling method according to the seventh aspect.
[Form 9]
The guest OS storing the accepted requests in a storage unit;
When the number of unprocessed requests accumulated in the storage unit exceeds a predetermined number, or when the retention period of unprocessed requests accumulated in the storage unit exceeds a predetermined period, the unprocessed requests Issuing a hypervisor call including an identifier of a virtual CPU executing an application that processes the request;
9. The scheduling method according to aspect 7 or 8.
[Mode 10]
The hypervisor associating a thread classified by priority with a physical CPU that executes the thread according to the priority in a second queue;
If the thread that realizes the virtual CPU corresponding to the identifier is executing on the physical CPU, the execution time of the thread is extended; otherwise, the priority of the thread in the second queue, and / or Or changing the order of the threads in the second queue.
The scheduling method according to any one of Forms 7 to 9.
[Form 11]
The guest OS calculating the priority of the accepted request;
Issuing a hypervisor call including an identifier of a virtual CPU executing an application that processes the unprocessed request when the priority of the unprocessed request accumulated in the storage unit exceeds a predetermined priority; ,including,
11. The scheduling method according to any one of forms 7 to 10.
[Form 12]
The hypervisor includes outputting a warning when the frequency of hypervisor calls issued by the guest OS exceeds a predetermined frequency;
The scheduling method according to any one of forms 7 to 11.
[Form 13]
The program according to the third aspect is as described above.
[Form 14]
A process in which the guest OS associates an application that processes the received request with an identifier of a virtual CPU that executes the application and stores the associated information in a first queue;
Referring to the first queue, identifying an identifier of a virtual CPU that executes the application, and causing the computer to execute a process of issuing a hypervisor call including the identified identifier of the virtual CPU.
The program according to Form 13.
[Form 15]
A process in which the guest OS accumulates received requests in a storage unit;
When the number of unprocessed requests accumulated in the storage unit exceeds a predetermined number, or when the retention period of unprocessed requests accumulated in the storage unit exceeds a predetermined period, the unprocessed requests Causing the computer to execute a process of issuing a hypervisor call including an identifier of a virtual CPU that executes an application that processes the request.
The program according to Form 13 or 14.
[Form 16]
A process in which the hypervisor associates a thread classified by priority with a physical CPU that executes the thread in accordance with the priority and stores the thread in a second queue;
If the thread that realizes the virtual CPU corresponding to the identifier is executing on the physical CPU, the execution time of the thread is extended; otherwise, the priority of the thread in the second queue, and / or Or causing the computer to execute a process of changing the order of the thread in the second queue.
The program according to any one of forms 13 to 15.
[Form 17]
A process in which the guest OS calculates the priority of the received request;
A process of issuing a hypervisor call including an identifier of a virtual CPU that executes an application that processes the unprocessed request when the priority of the unprocessed request accumulated in the storage unit exceeds a predetermined priority; , Causing the computer to execute
The program according to any one of forms 13 to 16.
[Form 18]
The hypervisor causes the computer to execute a process of outputting a warning when the frequency of hypervisor calls issued by the guest OS exceeds a predetermined frequency;
The program according to any one of forms 13 to 17.

  It should be noted that the entire disclosure of the above patent document is incorporated herein by reference. Within the scope of the entire disclosure (including claims) of the present invention, the embodiment can be changed and adjusted based on the basic technical concept. Further, various combinations or selections of various disclosed elements (including each element of each claim, each element of each embodiment, each element of each drawing, etc.) are possible within the framework of the entire disclosure of the present invention. is there. That is, the present invention of course includes various variations and modifications that could be made by those skilled in the art according to the entire disclosure including the claims and the technical idea. In particular, with respect to the numerical ranges described in this document, any numerical value or small range included in the range should be construed as being specifically described even if there is no specific description.

1 Virtual computer system 2 Physical computer 3 VMM
4 Hardware 5 Virtual machine 6 Guest OS
7 Guest OS interface 8 Guest OS dependency creation module 9 Guest OS dependency table 10 Dispatcher 11 CPU allocation table 13 CPU
12 Guest OS Scheduler 14 CPU Allocation Table Management Unit 15 Determination Unit 16 Server Guest OS Schedule Unit 17 Client Guest OS Search Unit 18 Client Guest OS Schedule Unit 20 Guest OS
22 Request unit 30 Hypervisor 32 Change unit 100 Guest OS
110 UDP packet transmission / reception unit 120 Request unit 130 Residence amount acquisition unit 140 SIP processing amplification determination unit 150 Residence request storage unit 151 Residence request identifier 152 Residence period 153 Priority 160 Thread activation unit 170 Scheduling queue 180 Priority calculation unit 190 Priority table 191 Telephone number 192 Priority 200 Hypervisor 210 Reception unit 220 Execution time change unit 230 Scheduler 240 Scheduling queue 250 Execution priority change unit 260 Execution queue rearrangement unit 270 Limit load warning unit 280 Execution history storage unit 300 Virtual machine 400 Linux
410 sock_def_readable
420 PVOP_VCALL3
460 try_to_wake_up
470 run_queue
500 KVM
530 schedule
540 run_queue

Claims (8)

It has a guest OS (Operating System) and a hypervisor.
The guest OS includes a storage unit that accumulates received requests;
A request unit that issues a hypervisor call including an identifier of a virtual CPU (Central Processing Unit) to the hypervisor;
The hypervisor has a changing unit that changes an execution time of a physical CPU assigned to a thread that realizes a virtual CPU corresponding to the identifier,
The request unit is configured such that when the number of unprocessed requests accumulated in the storage unit exceeds a predetermined number, or the retention period of unprocessed requests accumulated in the storage unit exceeds a predetermined period A hypervisor call including an identifier of a virtual CPU that executes an application that processes the unprocessed request,
A virtual computer system characterized by that. The guest OS includes a first queue that holds an application that processes an accepted request and an identifier of a virtual CPU that executes the application,
The request unit refers to the first queue, identifies an identifier of a virtual CPU that executes the application, and issues a hypervisor call including the identified virtual CPU identifier.
The virtual computer system according to claim 1. The hypervisor includes a second queue that holds a thread classified according to priority and a physical CPU that executes the thread according to the priority in association with each other.
The change unit extends the execution time of the thread when the thread that realizes the virtual CPU corresponding to the identifier is being executed on the physical CPU; otherwise, the change unit in the second queue of the thread Changing the priority and / or the order of the thread in the second queue;
The virtual machine system according to claim 1 or 2. The guest OS includes a priority calculation unit that calculates the priority of the received request,
The request unit includes a hypervisor call including an identifier of a virtual CPU that executes an application that processes the unprocessed request when the priority of the unprocessed request accumulated in the storage unit exceeds a predetermined priority. Issue,
The virtual machine system according to any one of claims 1 to 3. The hypervisor includes a warning unit that outputs a warning when the frequency of a hypervisor call issued by the request unit exceeds a predetermined frequency.
The virtual machine system according to any one of claims 1 to 4. A step in which a guest OS (Operating System) stores received requests in a storage unit;
Issuing a hypervisor call including a virtual CPU (Central Processing Unit) identifier to the hypervisor;
The hypervisor changing the execution time of a physical CPU assigned to a thread that realizes a virtual CPU corresponding to the identifier; and
In the guest OS, when the number of unprocessed requests accumulated in the storage unit exceeds a predetermined number, or the retention period of unprocessed requests accumulated in the storage unit exceeds a predetermined period A hypervisor call including an identifier of a virtual CPU that executes an application that processes the unprocessed request,
A scheduling method characterized by the above. The guest OS associating an application that processes the received request with an identifier of a virtual CPU that executes the application in a first queue;
Referring to the first queue, identifying an identifier of a virtual CPU that executes the application, and issuing a hypervisor call including the identified identifier of the virtual CPU.
The scheduling method according to claim 6. A process in which a guest OS (Operating System) stores received requests in a storage unit;
Processing to issue a hypervisor call including a virtual CPU (Central Processing Unit) identifier to the hypervisor;
The hypervisor causes a computer to execute a process of changing an execution time of a physical CPU assigned to a thread that realizes a virtual CPU corresponding to the identifier,
When the number of unprocessed requests accumulated in the storage unit exceeds a predetermined number, or when the retention period of unprocessed requests accumulated in the storage unit exceeds a predetermined period, the unprocessed requests Causing the guest OS to execute a process in which the guest OS issues a hypervisor call including an identifier of a virtual CPU that executes an application that processes the request;
A program characterized by that.

Images