WO2015122007A1 - 計算機、及び、ハイパバイザによる資源スケジューリング方法 - Google Patents
計算機、及び、ハイパバイザによる資源スケジューリング方法 Download PDFInfo
- Publication number
- WO2015122007A1 WO2015122007A1 PCT/JP2014/053613 JP2014053613W WO2015122007A1 WO 2015122007 A1 WO2015122007 A1 WO 2015122007A1 JP 2014053613 W JP2014053613 W JP 2014053613W WO 2015122007 A1 WO2015122007 A1 WO 2015122007A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- hypervisor
- guest
- request
- cpu
- physical
- Prior art date
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0712—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a virtual computing platform, e.g. logically partitioned systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/14—Error detection or correction of the data by redundancy in operation
- G06F11/1479—Generic software techniques for error detection or fault masking
- G06F11/1482—Generic software techniques for error detection or fault masking by means of middleware or OS functionality
- G06F11/1484—Generic software techniques for error detection or fault masking by means of middleware or OS functionality involving virtual machines
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
- G06F9/5011—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resources being hardware resources other than CPUs, Servers and Terminals
- G06F9/5022—Mechanisms to release resources
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
- G06F9/5061—Partitioning or combining of resources
- G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45579—I/O management, e.g. providing access to device drivers or storage
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45583—Memory management, e.g. access or allocation
Definitions
- the present invention generally relates to resource scheduling by a hypervisor.
- a computer that operates a plurality of guest OSes using a hypervisor is known.
- the dynamic resource scheduling function in the hypervisor is used, and the resource amount allocated to each guest OS is adjusted according to the load.
- resources physical memory and physical CPU (Central Processing Unit) are common.
- CPU Central Processing Unit
- a hypervisor is a mechanism with many functions (typically a computer program, but a hardware circuit in which a computer program is implemented) and therefore increases the availability of the hypervisor to a level applicable to mission critical applications. It ’s difficult. Therefore, a hypervisor cannot generally be installed in a mission critical computer.
- Non-Patent Document 1 As a resource scheduling method by a hypervisor, a method described in Non-Patent Document 1 is known. According to this method, a CPU scheduler (an example of a resource scheduler) included in the hypervisor performs the same operation as a CPU scheduler of an OS (Operating System).
- OS Operating System
- the hypervisor provides a virtual execution environment (virtual computer), and handles the processing of the guest OS operating on the virtual CPU of each virtual computer as a process. Then, the CPU scheduler determines which guest OS (process) is scheduled on the physical CPU. Further, the hypervisor also executes execution context switching processing (resource dispatch / preemption processing) on the physical CPU.
- a simple hypervisor is operated on the computer.
- the hypervisor has a function of emulating a plurality of resources including one or more physical memories and a plurality of physical CPUs, and a function of resource scheduling (deciding resources to be allocated or collected for each guest OS). And an agent function for performing resource allocation or resource recovery for the guest OS on behalf of the hypervisor.
- a first guest OS for example, a guest OS that wants to guarantee operation continuation even in the event of a hypervisor failure
- a second guest OS guest OS other than the first guest OS Operate.
- Resource scheduling is performed by the hypervisor, and resource allocation or collection for the first guest OS is performed by the simple hypervisor on behalf of the hypervisor.
- kkk table information may be described by the expression “kkk table”, but the information may be expressed by a data structure other than the table. In order to show that it does not depend on the data structure, the “kkk table” can be called “kkk information”.
- the process may be described using “program” as the subject, but the program is executed by the physical CPU, so that the determined process can be appropriately performed with storage resources (for example, memory) and Since the communication is performed using a communication interface device (for example, a communication port), the subject of processing may be a physical CPU. On the contrary, it can be interpreted that the process in which the physical CPU is the subject is performed by executing one or more programs. Further, the physical CPU may include a hardware circuit that performs part or all of the processing performed by the processor, or may mean each core of the multi-core processor.
- the computer program may be installed on each computer from a program source.
- the program source may be, for example, a program distribution server or a storage medium.
- FIG. 1 shows an outline of the embodiment.
- the computer 201 has a plurality of resources (physical resources) including a plurality of physical CPUs (111) and physical memories (112) and (113).
- the physical memory (112) is an example of a first physical memory area
- the physical memory (113) is an example of a second physical memory area.
- the physical memories (112) and (113) may be a plurality of memory areas secured from the memory area of the integrated physical memory.
- a hypervisor agent (102) exists in addition to the hypervisor (101), and a virtual computer environment is provided.
- the hypervisor agent (102) is an example of a simple hypervisor.
- the first guest OS (103) runs on the virtual machine provided by the hypervisor agent (102), and the second guest OS (104) runs on the virtual machine provided by the hypervisor (101).
- Resource scheduling for dynamically allocating or collecting resources is performed for each of the first guest OS (103) and the second guest OS (104).
- the resource used for the operation of the hypervisor agent (102) may be only a resource that can be used by the first guest OS (103) (not used by the hypervisor (101)) among a plurality of resources.
- the hypervisor agent (102) represents a correspondence between a logical address specified by the guest OS (guest physical page number in this embodiment) and a physical address corresponding to the logical address (host physical page number in this embodiment).
- Memory virtualization can be performed by updating the address translation table (134). Thereby, it is possible to control the memory area (page) accessible by the first guest OS (103).
- the address conversion table (134) may be, for example, an EPT (extended page table) or a DWAR (DMA (Direct Memory Access) Remapping) table.
- the resource scheduling is determined by the hypervisor (101), but the resource allocation or resource recovery for the first guest OS (103) is executed by the hypervisor agent (102) on behalf of the hypervisor.
- the hypervisor (101) issues a resource dispatch / preemption (allocation / collection) request by writing to a nonvolatile area (nonvolatile storage area) (114).
- the hypervisor agent (102) reads the request from the non-volatile area (114), and executes processing according to the request.
- a volatile storage area may be employed instead of the nonvolatile area (114).
- the non-volatile area (114) may exist outside the computer (201) (see FIG. 2).
- the request is a CPU dispatch request
- the physical CPU context to be dispatched is switched from the hypervisor (101) to the hypervisor agent (102), and the hypervisor agent (102) operates on the physical CPU. Further, the hypervisor agent (102) notifies the first guest OS (103) that the physical CPU is available. As a result, the first guest OS (103) can start operating on the physical CPU.
- the hypervisor agent (102) If the request is a physical CPU preemption request, the hypervisor agent (102) notifies the first guest OS (103) that the physical CPU has become unusable. As a result, the first guest OS (103) does not operate on the physical CPU. Further, the context of the physical CPU to be preempted is switched from the hypervisor agent (102) to the hypervisor (101).
- the address translation table (134) is updated so that the first guest OS (103) can or cannot access the specified memory area. Processing is executed. At this time, the hypervisor agent (102) notifies the first guest OS (103) that the first guest OS (103) can or cannot access the memory area. recognize.
- the physical CPU is not virtualized but the physical memory (112 and 113) is virtualized. That is, the first guest OS (103) performs exclusive execution while directly updating the register (115) on the physical CPU (111). However, the first guest OS (103) accesses the physical memory (112 and 113) via the address conversion table (134). At this time, the address space of the physical memory is converted, and the presence of a part of the physical memory (area) cannot be recognized from the first guest OS (103).
- the hypervisor (101) has a CPU scheduler (121) and a memory scheduler (122). These schedulers determine allocation of the physical CPU (111) and the physical memory (112 and 113) to the first guest OS (103) and the second guest OS (104).
- the hypervisor agent (102) includes a CPU dispatch agent (126), a memory dispatch agent (125), and a stateless CPU emulator 124.
- the scheduler does not directly perform dispatch processing of the physical CPU (111) and physical memory (112 and 113) to the first guest OS, but issues a resource dispatch / preemption request via the nonvolatile area (114).
- the CPU dispatch agent (126) and the memory dispatch agent (125) of the hypervisor agent (102) perform CPU / memory dispatch processing.
- the first guest OS (103) has a guest CPU scheduler (129), a guest memory scheduler (128), and a privileged instruction execution unit (127).
- the hypervisor agent (102) It cooperates with the CPU scheduler (129) and the memory scheduler (128).
- the first guest OS (103) is directly executed on the physical CPU (111).
- the hypervisor agent (102) includes the stateless CPU emulator (124) described above in order to guarantee direct execution.
- the stateless CPU emulator (124) executes a process of updating the register (115) on the physical CPU (111) according to the trapped privileged instruction.
- the hypervisor (101) and the second guest OS (104) are restarted.
- the hypervisor agent (102) and the first guest OS (103) are protected by a physical memory protection area (112), that is, the hypervisor (101) and the second guest OS (104). Is placed in a non-writable area.
- the hypervisor (101) and the second guest OS (104) cannot destroy the data and code in this area.
- the hypervisor (101) has a restart control (123).
- the nonvolatile area (114) stores a request log table (131), a CPU allocation state table (132), and a memory allocation state table (133), but the restart control (131) is stored in the nonvolatile area (114).
- the information (131) to (133) is referred to.
- the restart control (123) waits until the processing of the request being issued registered in the request log table (131) is completely completed.
- the restart control (123) uses only the CPU / memory that can be used by the hypervisor (101) and the second guest OS (104) according to the allocation state of the CPU / memory. Do.
- Dispatch of resources used by the first guest OS (103) is performed by the hypervisor agent (102) on behalf of the hypervisor (101). Also, it is the hypervisor agent (102), not the hypervisor (101) that performs CPU emulation through the execution of the first guest OS (103). That is, even if a failure occurs in the hypervisor (101), the first guest OS (103) and the hypervisor agent (102) can continue to operate.
- the function provided by the hypervisor agent (102) is less than that of the hypervisor (101) (for example, much less). Therefore, even if a failure occurs in the hypervisor (101), the operation of the first guest OS (103) is continued. It is not difficult to do.
- request log table (131), the CPU allocation state table (132), and the memory allocation state table (133) are stored in the nonvolatile area (114) and can be referred to even after the hypervisor (101) is restarted. Even after the hypervisor failure, only the second guest OS (104) and the hypervisor (101) can be restarted and the processing can be continued.
- FIG. 2 shows the hardware configuration of the computer 201.
- Programs such as the first guest OS (103), the hypervisor agent (102), the second guest OS (104), and the hypervisor (101) are arranged on the physical memory (112 and 113) of the computer (201).
- the physical memories (112 and 113) are communicably connected to a plurality of physical CPUs (111) via the CPU bus (202). At least one of the plurality of physical CPUs (111) reads and executes the above-described program.
- the address translation table (134) is arranged on the physical memory (112 and 113), and is used for address translation control in memory access when the first guest OS (103) or the second guest OS (104) is executed.
- the request log table (131), the CPU allocation state table (132), and the memory allocation state table (133) are arranged in the nonvolatile area (114).
- the computer (102) has an I / O (Input / Output) controller (203), and the nonvolatile area (114) is physically connected via the I / O controller (203) and the I / O cable (204). It can be accessed from a program executed on the CPU (111). For example, when performing read processing, the program issues an I / O request to the I / O controller (203). The I / O controller (203) reads the data on the nonvolatile area (114) via the I / O cable (204), and reads the read data into the physical memory (112 and 113) via the CPU bus (202). Write to. The program operating on the physical CPU (111) acquires the written data via the CPU bus (202).
- the I / O cable (204) may be a cable in a communication network.
- FIG. 3 shows the structure of the request log table (131).
- the request log table (131) includes resource dispatch / preemption requests issued by the CPU scheduler (121) and the memory scheduler (122), and the processing status by the CPU dispatch agent (126) and the memory agent (125) of the request. It is a table for managing logs. This table has fields of resource type (301), number (302), old state (303), new state (304), guest physical number (305), and processing state (306) for each request. One column corresponds to one request log.
- the resource type (301) indicates whether the dispatch / preemption target is a CPU or a memory.
- the number (302) represents the number (identification number) of the resource to be dispatched / preempted.
- the number (302) represents the number of the physical CPU to be dispatched.
- the host physical page number of the memory area (page) to be dispatched and the number for identifying the page are displayed. To express.
- the old state (303) and the new state (304) represent the guest OS numbers that can use the target resource before and after the dispatch / preemption process.
- at least one value of the old state (303) and the new state (304) may be a value “F” indicating a free state.
- the guest physical number (305) is not a resource dispatch / preemption request by the hypervisor (101), but is used only in a special case where the hypervisor (101) requests the hypervisor agent (102) to set the address translation table (134).
- the address conversion table (134) is shared by the hypervisor (101) and the hypervisor agent (102).
- the address translation table (134) is arranged in the physical memory (protection area) (112).
- an address change request in which information necessary for setting (for example, the number (302) and the new state (304)) is designated is sent to the memory dispatch agent ( 125).
- the processing status (306) represents the processing status of the dispatch / preemption processing according to the request.
- the CPU scheduler (121) or the memory scheduler (122) issues a request, it updates the processing state (306) corresponding to the request to “processing”. Further, when the CPU dispatch agent (126) and the memory dispatch agent (125) complete the processing according to the request, the processing state (306) corresponding to the request is updated to “completed”.
- the guest physical number (205) field is not used.
- the memory dispatch / preemption request includes a dispatch request for allocating a memory area (page) to the first guest OS (103), a preemption request for collecting the memory area from the first guest OS (103), and a hypervisor.
- the guest physical number (305) field is not used.
- the fields of number (302) and guest physical number (305) are not used (recovery of any one page currently used by the first guest OS (103) may be requested).
- the field of the old state (303) is not used (because the owner of the resource is not changed before and after the request).
- FIG. 4 shows the configuration of the CPU allocation state table (132).
- the CPU allocation state table (132) has a field of a CPU number (401) and a field of an allocation destination (402) for each physical CPU.
- the CPU number (401) represents the number (identification number) of the physical CPU (111)
- the assignment destination (402) represents the number (identification number) of the guest OS to which the corresponding physical CPU (111) is assigned.
- the value of the assigned destination (402) may be a value “F” that means an empty state.
- the value of the assignment destination (402) may be the value “#” meaning that the process is in progress.
- FIG. 5 shows the configuration of the memory allocation state table (133).
- the memory allocation state table (133) has a host physical page number (501) field, a guest physical page number (502) field, and an allocation destination (503) field for each page.
- the host physical page number (501) represents a page number (identification number) and corresponds to a physical address.
- the guest physical page number (502) represents a page number recognized by the guest OS and corresponds to a logical address.
- the allocation destination (503) represents the number of the guest OS to which the page is allocated. For an empty page that has no guest OS to be allocated, the guest physical page number (502) and the allocation destination (503) may each be a value “F” indicating an empty state. Further, for the page being dispatched / preempted, the guest physical page number (502) and the allocation destination (503) may each be the value “#” meaning that processing is in progress.
- FIG. 6 shows the first context storage area (601).
- the first context storage area (601) may be a partial area of the physical memory (113). When the CPU scheduler (121) performs CPU dispatch / preemption processing, the first context storage area (601) is used. The CPU scheduler (121) uses the first context storage area (601) to save and restore the execution context of the hypervisor agent (102).
- FIG. 7 shows the second context storage area (701).
- the second context storage area (701) may be a partial area of the physical memory (112).
- the CPU dispatch agent (126) saves the execution context of the hypervisor (101) in this data structure before issuing the CPU dispatch request.
- the execution context of the hypervisor (101) is recovered from the second context storage area (701).
- FIG. 8 shows the arrangement of the code area and the stack area.
- the code area and stack area are used during dispatch / preemption processing of the physical CPU (111).
- the CPU dispatch / preemption request is issued by the CPU scheduler (121).
- a code for performing the processing is arranged in the CPU scheduler code area (1) (813).
- the stack used when performing the processing is arranged in the CPU scheduler stack area (815). These areas are on the physical memory (113).
- the dispatch request of the physical CPU (111) is issued by issuing a trap instruction.
- the jump destination at this time is registered in the interrupt handler table (801) managed by the hypervisor (101), and the jump to the CPU dispatch agent (126) is realized by the table (801).
- the code of processing performed by the CPU dispatch agent (126) is arranged in the CPU dispatch agent code area (812). At this time, stack switching occurs simultaneously, and a new stack is placed in the CPU dispatch agent stack area (811). These areas are arranged in the physical memory (protection area) (112).
- the CPU preemption request issuance is performed by an interrupt notification to the physical CPU (111) to be preempted.
- the interrupt handler table (801) is referred to, jumped, and switched as described above, and the CPU dispatch agent (126) is activated.
- FIG. 9 shows the configuration of the address conversion table (134).
- the address conversion table (134) includes, for each entry (record), a field for storing a value (V) (901) indicating whether the entry is valid or invalid, and a guest OS number indicating the number of the guest OS to which the page is allocated.
- V value
- a field of (902) a field of a guest physical page number (903) representing a page number designated by the guest OS, and a field of a host physical page number (904) associated with the guest physical page number.
- FIG. 10 shows the configuration of the CPU usage history management table (1001).
- the CPU usage history management table (1001) is a table managed by the CPU scheduler (121), and is arranged in the physical memory 113, for example.
- the CPU history management table (1001) has a guest OS number (1011), a minimum CPU amount (1012), a maximum CPU amount (1013), and an assigned CPU total (1014) for each guest OS.
- the guest OS number (1011) represents the guest OS number
- the minimum CPU amount (1012) represents the lower limit value of the CPU amount allocated to the guest OS
- the maximum CPU amount (1013) is allocated to the guest OS.
- the upper limit value of the assigned CPU amount is indicated, and the assigned CPU cumulative (1014) indicates the accumulated value of the assigned CPU amount.
- the CPU amount may be the number of physical CPUs, for example.
- the combination of the minimum CPU amount (1012) and the maximum CPU amount (1013) represents a range of CPU amount allocated to the guest OS.
- FIG. 11 shows the configuration of the memory usage history management table (1101).
- the memory usage history management table (1101) is a table managed by the memory scheduler (122), and is arranged in the physical memory 113, for example.
- the memory usage history management table (1101) has fields for each guest OS: a guest OS number (1111), a minimum memory amount (1112), a maximum memory amount (1113), and an allocated memory total (1114).
- the guest OS number (1111) represents the guest OS number
- the minimum memory amount (1112) represents the lower limit value of the memory amount allocated to the guest OS
- the maximum memory amount (1113) allocated to the guest OS The upper limit value of the allocated memory amount is represented
- the allocated memory cumulative (1114) represents the cumulative value of the allocated memory amount.
- the memory amount may be, for example, the number of pages or the total capacity of pages.
- the combination of the minimum memory amount (1112) and the maximum memory amount (1113) represents a range of the amount of memory allocated to the guest OS.
- the CPU history management table (1001) and the memory history management table (1101) are each stored in the non-volatile area (114).
- Tables (1001) / (1101) represent the maximum / minimum resource amount that can be allocated to each guest OS of the CPU / memory, and the total amount (total) of the allocated resources.
- the CPU scheduler (121) / memory scheduler (122) performs resource scheduling
- the CPU scheduler (121) / memory scheduler (122) refers to the maximum / minimum resource amount registered in the table (1001) / (1101) and performs scheduling exceeding / below it. If you are trying to do so, stop the assignment.
- the allocated resource amount (cumulative total) is managed for each guest OS, charging according to the resource utilization record is possible.
- FIG. 12 shows an operation flow by the periodic activation of the CPU scheduler (121).
- the CPU scheduler (121) updates the CPU usage history management table (1001). Specifically, for example, the CPU scheduler (121) refers to the CPU allocation state table (132) and calculates the number of allocated CPUs for each guest OS. Then, for each guest OS, the CPU scheduler (121) adds the calculated allocated CPU count to the allocated CPU cumulative (1014) of the CPU usage history management table (1001). By this processing, the cumulative value of CPU usage results can be managed, and charging according to the cumulative value can be performed.
- a target guest OS that is a guest OS to which resources are dispatched or preempted is referred to as a “first guest OS”.
- the CPU scheduler (121) determines a scheduling target CPU (physical CPU to be dispatched or preempted) for the first guest OS. In this determination, the CPU scheduler (121) determines the CPU amount range (minimum CPU amount (1012) and maximum CPU amount (1013)) for the first guest OS (103) from the CPU usage history management table (1001). Specified). Then, when the amount of the CPU to be scheduled is added or reduced to the CPU allocation (1014) corresponding to the first guest OS (103), the upper limit of the specified CPU amount range is exceeded or the specified CPU amount range is exceeded. When falling below the lower limit, the CPU scheduler (121) stops the allocation.
- the CPU amount range minimum CPU amount (1012) and maximum CPU amount (1013)
- the CPU scheduler (121) displays the scheduling state (combination of the first guest OS (103) and the physical CPU after scheduling) determined in step 1202 and the CPU allocation state table (132). By comparing, it is determined whether there is a change in assignment (whether there is a change in the combination of the first guest OS and the physical CPU).
- the CPU scheduler (121) updates the CPU allocation state table (132) in step 1205, specifically, for example, the allocation destination (402) corresponding to the first guest OS (103). Is updated to “#”.
- the CPU scheduler (121) updates the request log table (131). Specifically, for example, the CPU scheduler (121) sets “CPU” as the resource type (301) and the number of the scheduling target CPU (111) for the first guest OS (103) as the number (302). Is set as the old state (303) and the new state (304), and the number of the guest OS that should occupy the physical CPU (111) before and after the scheduling is executed, and “processing” is set as the processing state (306). Set.
- step 1207 the CPU scheduler (121) determines whether the request that needs to be issued to the CPU dispatch agent (126) is dispatch or preemption. If the request is a dispatch request, the process proceeds to step 1209. If the request is a preemption request, the process proceeds to step 1208.
- step 1208 the CPU scheduler (121) issues an interrupt notification to the scheduling target CPU (111).
- the first guest OS (103) and the hypervisor agent (102) operating on the scheduling target CPU (111) interrupt the operation, and thereafter, the control is transferred to the CPU dispatch agent (130).
- the stack is also changed, and an operation using the CPU dispatch agent stack area (811) as a stack is performed. Then, the process proceeds to Step 1212.
- the CPU scheduler (121) performs cache / TLB (Translation Lookaside Buffer) flush processing, specifically, cache / TLB flush (cache and data in the TLB are stored in a predetermined storage location (for example, a non-volatile area).
- 114) issue a privileged instruction instructing the process to be discharged).
- the privileged instruction is received by the current physical CPU (111) (physical CPU (111) executing the hypervisor 101), and the physical CPU (111) performs cache / TLB flushing.
- the cache and TLB here may be an area in the physical memory 113.
- the CPU scheduler (121) saves the execution context to the first context saving area (601).
- the execution context stores, for example, the value of the register (115) of the current physical CPU (111) (physical CPU (111) that executes the hypervisor 101).
- step 1211 the CPU scheduler (121) issues a trap instruction.
- the CPU dispatch agent (130) starts operating on the physical CPU (111) being executed.
- the used stack area is also changed, and the subsequent processing of the CPU dispatch agent (130) operates while using the stack of the CPU dispatcher agent stack area (811).
- step 1212 the CPU scheduler (121) completes the process.
- FIG. 13 shows an operation flow of the CPU scheduler (121) started in response to a trap return from the CPU dispatch agent (126).
- step 1301 the CPU scheduler (1301) issues an hlt instruction.
- the CPU scheduler (1301) waits until an interrupt notification is issued by restart control (123) described later by issuing this hlt instruction.
- the hypervisor (101) may be restarted due to a failure of the hypervisor (101) while the CPU dispatcher agent (126) is performing the dispatch / preemption processing for the physical CPU (111).
- the context saved in step 1210 is also invalidated. By performing this waiting before the context recovery, the use of the invalid context can be avoided and the operation can be continued after the hypervisor (101) is restarted.
- step 1302 the CPU scheduler (121) recovers the context from the hypervisor context storage area (301).
- each value of the context in the area (301) is loaded into the register (115) of the physical CPU (111) (physical CPU (111) executing the hypervisor 101).
- the physical CPU is exclusively used by the hypervisor (101) and the second guest OS (104) and operates.
- step 1303 the CPU scheduler (121) completes the process.
- the CPU dispatch agent (126) detects a dispatch request by periodically referring to the request log table (131) (in the case of dispatch) or receives an interrupt notification from the CPU scheduler (129). If (preempt), start the operation. When the CPU dispatch request is detected, the operation flow shown in FIG. 14 is performed. When the CPU preemption request is detected, the operation flow shown in FIG. 15 is performed.
- FIG. 14 shows an operation flow of the CPU dispatch agent (126) and the guest CPU scheduler (129) that have detected a CPU dispatch request.
- the CPU dispatch agent (126) recovers the context from the second context storage area (701). Specifically, for example, the CPU dispatch agent (126) loads each value of the context in the second context storage area (701) into the register (115) of the physical CPU (111).
- the physical CPU (111) is a physical CPU (111) that executes the hypervisor agent (102), in other words, a physical CPU (111) that executes the first guest OS 103.
- the CPU dispatch agent (126) transmits a CPU update request, which is a request for updating the CPU configuration information, to the guest CPU scheduler (129) of the first guest OS (103).
- the guest OS scheduler (129) receives the CPU update request.
- the guest OS scheduler (129) is notified of the number of the physical CPU (111) to be dispatched.
- the CPU update request may include the number of the physical CPU (111) to be dispatched, or the number of the physical CPU (111) to be dispatched is the guest OS scheduler along with the request. (129) may be notified.
- step 1404 the guest CPU scheduler (129) adds the notified physical CPU number to the scheduling target CPU list of the first guest OS (103). Thereafter, the first guest OS (103) can use the physical CPU (111).
- step 1405 the guest CPU scheduler (129) transmits CPU update completion to the CPU dispatch agent (126).
- step 1406 the CPU dispatch agent (126) receives the completion.
- step 1407 the CPU dispatch agent (126) updates the request log table (131), specifically, for example, sets the value of the processing state (306) corresponding to the detected CPU dispatch request to “completed”. Update.
- step 1408 the CPU dispatch agent (126) completes the processing.
- FIG. 15 shows an operation flow of the CPU dispatch agent (126) and the guest CPU scheduler (129) that detected the CPU preemption request.
- step 1501 the CPU dispatch agent (126) transmits a CPU update request to the guest CPU scheduler (129) of the first guest OS (103).
- step 1502 the guest CPU scheduler (129) receives a CPU update request. At this time, the number of the physical CPU (111) to be preempted is notified to the guest CPU scheduler (129) by the same method as in FIG.
- step 1503 the guest CPU scheduler (129) deletes the notified physical CPU number from the scheduling target CPU list of the first guest OS (103). Thereafter, the physical CPU (111) cannot use the first guest OS (103).
- step 1504 the guest CPU scheduler (129) transmits CPU update completion to the CPU dispatch agent (126).
- step 1505 the CPU dispatch agent (126) receives the completion.
- step 1506 the CPU dispatch agent (126) updates the request log table (131), specifically, for example, sets the value of the processing state (206) corresponding to the detected CPU preemption request to “completed”. Update.
- the CPU dispatch agent (126) saves the context in the second context saving area (701). Specifically, for example, the CPU dispatch agent (126) stores the context including the value recorded in the register (115) of the physical CPU (111) in the second context storage area (701).
- the physical CPU (111) is a physical CPU (111) that executes the hypervisor agent (102), in other words, a physical CPU (111) that executes the first guest OS 103.
- step 1508 the CPU dispatch agent (126) issues a trap return command (see FIG. 8). By issuing this trap return instruction, the stack is switched, and the CPU scheduler (121) that operates thereafter operates using the CPU scheduler stack area (815).
- step 1509 the operation is completed.
- FIG. 16 shows an operation flow of the memory scheduler (122).
- the memory scheduler operates periodically.
- the memory scheduler (122) updates the memory usage history management table (1101). Specifically, for example, the memory scheduler (122) refers to the memory allocation state table (133), and calculates an allocated memory amount for each guest OS. Then, the memory scheduler (122) adds the calculated allocated memory amount to the allocated memory total (1114) of the memory history management table (1101) for each guest OS. By this process, the accumulated value of the memory use results can be managed, and charging according to the accumulated value can be performed.
- the memory scheduler (122) determines a scheduling target memory area (a memory area (page) to be dispatched or preempted) for the first guest OS.
- the memory scheduler (122) for the first guest OS (103), from the memory usage history management table (1101), the memory amount range (minimum memory amount (1111) and maximum memory amount (1112)). Specified).
- the amount of the memory area to be scheduled is added to or reduced from the allocated memory total (1114) corresponding to the first guest OS (103), the upper limit of the specified memory amount range is exceeded, or the specified memory amount range If the value falls below the lower limit, the memory scheduler (122) stops the allocation.
- step 1603 the memory scheduler (122) checks whether there is a change in the memory allocation amount to the first guest OS.
- step 1604 the memory scheduler (122) completes the process.
- the memory scheduler (122) updates the memory allocation state table (133).
- the memory scheduler (122) determines a memory area (physical page) to be allocated if the issued request requires memory dispatch to the first guest OS (103) (increase in the allocated memory amount).
- the physical page is a physical page that has no allocation destination and is empty, or a preemptible page among physical pages allocated to the second guest OS (104). Then, for the physical page, the guest physical page number (502) and the allocation destination (503) are respectively updated to “#” in the memory allocation state table (133).
- the request to be issued is a preemption request or an address change request to the first guest OS, the update process in this step is not performed.
- the memory scheduler (122) performs registration processing in the request log table (131). Specifically, for example, the memory scheduler (122) updates the resource type (301) and processing state (306) corresponding to the request to “memory” and “processing”, respectively. If the request is a memory dispatch request to the first guest OS (103), the number (302) is the target physical page number, and the old state (303) and the new state (304) are respectively This is the guest OS number to which the physical page is assigned before and after the dispatch process. If the request is a memory preemption request to the first guest OS (103), the old state (303) and the new state (304) are the guest OS numbers to which the physical page is allocated before and after the dispatch process, respectively. is there.
- step 1607 the process is completed.
- FIG. 17 shows an operation flow of the memory dispatch agent (125) and the guest memory scheduler (128).
- step 1701 the memory dispatch agent (125) extracts a request whose resource type (301) is “memory” and whose processing state (306) is “processing” from the request log table (131).
- the memory dispatch agent (125) determines the extracted request (column). If the number (302), the old state (303), and the new state (304) are all set, the request is a memory dispatch request, and the old state (303) and the new state (304) are set, but the number If (302) is not set, the request is a memory preemption request, and if the number (302) and the new state (304) are set, but the old state (303) is not set, the request is an address change. Determined as a request. If the request is a memory dispatch / preemption request, the process proceeds to step 1703, and if the request is an address change request, the process proceeds to step 1708.
- the memory dispatch agent (125) transmits a memory update request, which is a request for updating the memory configuration information, to the guest memory scheduler (128) of the first guest OS.
- step 1704 the guest memory scheduler (128) receives the request.
- the guest memory scheduler (128) adds / deletes a page number to / from a physical page list that is a list of guest physical page numbers that can be used by the first guest OS. .
- the guest memory scheduler (128) determines a guest physical page number to be added / deleted. If the request is a memory dispatch request, the guest memory scheduler (128) determines a guest physical page number to be added to the list. If the request is a memory preemption request, the guest memory scheduler (128) determines the guest physical page number to be deleted from the list.
- step 1706 the guest memory scheduler (128) transmits completion of memory update to the memory dispatch agent (125).
- the guest physical page number determined in step 1705 is notified to the memory dispatch agent (125).
- the guest physical page number may be included in the completion (response) or may be notified separately from the completion (response).
- step 1707 the memory dispatch agent (125) receives the completion and the guest physical page number.
- the memory dispatch agent (125) updates the address conversion table (134).
- the memory dispatch agent (125) indicates the guest OS number indicated by the new state (304) corresponding to the request, the guest physical page number received in step 1707, and the number corresponding to the request ( 302) is registered as the guest OS number (902), guest physical page number (903), and host physical page number (904) of the address translation table (134), and these are registered.
- the value of V (901) in the entry is updated to “1” (valid).
- the memory dispatch agent (125) uses the guest OS number (902) and the guest OS number represented by the new state (304) corresponding to the request and the guest physical page number received in step 1707 and The entry having the guest physical page number (903) is searched from the address conversion table (134), and the value of V (901) of the found entry is updated to “0” (invalid). Further, the memory dispatch agent (125) sets the guest physical page number (502) and the allocation destination (503) (see FIG. 5) corresponding to the host physical page number (904) in the found entry to “#”, respectively. Update.
- the memory dispatch agent (125) When the request is an address change request, the memory dispatch agent (125) indicates the guest OS number indicated by the new state (304) corresponding to the request, the guest physical page number indicated by the guest physical page number (305) corresponding to the request, The host physical page number (603) represented by the number (302) corresponding to the request is registered as the guest OS number (902), guest physical page number (903), and host physical page number (904) of the address translation table (134). Then, the value of V (901) in the entry in which those values are registered is updated to “1” (valid).
- the memory dispatch agent (125) issues a privileged instruction to instruct cache / TLB purge processing, specifically, cache / TLB purge (deletion of data in the cache and TLB).
- the privileged instruction is received by the physical CPU (111) (physical CPU (111) executing the visor agent 10), and the physical CPU (111) purges the cache / TLB.
- the cache and TLB here may be an area in the physical memory 112 (protection area).
- the memory dispatch agent (125) updates the request log table (131). Specifically, for example, the memory dispatch agent (125) updates the value of the processing state (306) corresponding to the request to “completed”. Further, the memory dispatch agent (125) updates the value of the guest physical page number (305) to the value received in step 1706. If the request is a memory preemption request, the value of the host physical page number (904) read in step 1708 is registered as the corresponding number (302).
- step 1711 the process is completed.
- FIG. 18 shows an operation flow of the privileged instruction execution unit (127) and the stateless CPU emulator (124).
- step 1801 the privileged instruction execution unit (127) executes the privileged instruction.
- a trap is generated on the physical CPU (111), and control is transferred to the stateless CPU emulator (124).
- a vendor's physical CPU has both a memory emulation function and a CPU emulation function, but these functions are both enabled or disabled, and only one function is enabled. Some things cannot be enabled.
- the memory emulation function of the physical CPU is called (validated) as means for realizing memory virtualization in this embodiment, but only the memory emulation function cannot be validated. Is also effective. This is an example in which a privileged instruction (a trap accompanying execution) occurs.
- step 1802 the stateless CPU emulator (124) reads the instruction being executed.
- step 1803 the stateless CPU emulator (124) determines the physical memory (112) or physical CPU (111) (physical CPU (111) executing the first guest OS 103) according to the instruction read above.
- the register (115) is updated.
- step 1804 the stateless CPU emulator (124) issues a trap return command and returns control to the privileged command execution unit (127).
- step 1805 the privileged instruction execution unit (127) continues the process, and the process is completed in step 1806.
- FIG. 19 shows a flow of periodic operation of the restart control (123).
- step 1901 the restart control (123) searches the request log table (131) for an entry whose processing state (306) is “complete”.
- step 1902 the restart control (123) determines whether or not the above entry has been found. If there is such an entry, the process proceeds to step 1903; otherwise, the process proceeds to step 1906.
- the restart control (123) updates the CPU allocation state table (132) and the memory allocation state table (133). Specifically, for example, when the entry found in step 1901 is an entry corresponding to the CPU dispatch / preemption request, the restart control (123) determines the assignment destination (402) corresponding to the entry number (302). The value is updated to the value represented by the new state (304) of the entry. For example, when the entry found in step 1901 is an entry corresponding to the memory dispatch request, the restart control (123) sets the value of the assignment destination (502) in the entry corresponding to the entry number (302). , The entry is updated to the value represented by the new state (304).
- the restart control (123) updates the value of the guest physical page number (502) in the entry corresponding to the entry number (302) to the value represented by the guest physical number (305) of the entry. Further, for example, when the entry found in step 1901 is an entry corresponding to the memory preemption request, the restart control (123) determines that the guest physical page number (502) in the entry corresponding to the entry number (302) and The value of the assignment destination (503) is updated to “F”. Further, for example, the restart control (123) does not have to do anything when the entry found in step 1901 corresponds to the address update request. After the update process, the restart control (123) deletes the entry (found entry) in the request log table (131).
- step 1904 the restart control (123) determines whether or not the entry found in step 1901 includes a CPU preemption completion request. If it is included, the process proceeds to step 1905; otherwise, the process proceeds to step 1906.
- step 1905 the restart control (123) transmits an interrupt to the target physical CPU (111). By this interrupt transmission, the operation of the CPU scheduler (121) stopped in step 1301 can be safely restarted.
- step 1906 the process is completed.
- FIG. 20 shows an operation flow of the restart control (123) after the hypervisor is restarted due to a failure.
- step 2001 the restart control (123) waits until the processing state becomes “complete” if there is an entry whose processing state (306) is “processing” in the request log table (131).
- step 2002 the restart control (123) determines whether or not the waiting time is timed out. If time is out, the process proceeds to step 2003; otherwise, the process proceeds to step 2004.
- the restart control (123) cancels the request in which a timeout has occurred. Specifically, for example, when the timed-out request is a CPU dispatch / preemption request, the restart control (123) identifies the number (302) in the target entry corresponding to the timed-out request, and identifies the identified number (302 ) Is updated to the value of the old state (303) in the target entry. When the timed-out request is a memory dispatch request, the restart control (123) identifies the number (302) in the target entry corresponding to the timed-out request, and the guest physical page corresponding to the identified number (302) The values of the number (502) and the assignment destination (503) are updated to “F”, respectively.
- the restart control (123) does not have to do anything.
- the restart control (123) deletes the entry corresponding to the timed-out request from the request log table (131).
- step 2004, the restart control (123) performs a CPU / memory allocation state update process.
- this update process as in step 1903, the CPU allocation status table (132) and the memory allocation status table (132) according to the registered contents of the entry whose processing status (306) in the request log table (131) is “complete”. 133) is updated.
- the restart control (123) determines the CPU / memory that can be used by the hypervisor (101) and the second guest OS (104), and this available CPU. / Using only the memory (in other words, without using the resources used by the hypervisor agent (102) and the first guest OS (103)), the hypervisor (101) and the second guest OS (104) An initialization process (boot process) is executed. As a result, the hypervisor 101) and the second guest OS (104) can be restarted without affecting the hypervisor agent (102) and the first guest OS (103).
- step 2006 the restart control (123) performs the initialization process of the first context storage area (601). This initialization ensures that the context recovery process in step 1302 is performed safely.
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Software Systems (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Quality & Reliability (AREA)
- Mathematical Physics (AREA)
- Memory System Of A Hierarchy Structure (AREA)
- Debugging And Monitoring (AREA)
- Hardware Redundancy (AREA)
- Multi Processors (AREA)
Abstract
Description
Claims (15)
- 1以上の物理メモリと複数の物理CPU(Central Processing Unit)とを含んだ複数の資源を有し、
前記複数の物理CPUが、ハイパバイザ、簡易ハイパバイザ、第1のゲストOS(Operating System)、及び第2のゲストOSを実行し、
前記複数の資源において、前記ハイパバイザに使用される資源と、前記簡易ハイパバイザに使用される資源は、異なっており、
前記1以上の物理メモリが、前記ハイパバイザに使用されない第1の物理メモリ領域と前記ハイパバイザに使用される第2の物理メモリ領域とを有し、
前記第1のゲストOSは、前記第1の物理メモリ領域を基に、前記簡易ハイパバイザ上で実行され、
前記第2のゲストOSは、前記第2の物理メモリ領域を基に、前記ハイパバイザ上で実行され、
前記ハイパバイザは、前記複数の資源を複数の仮想資源に仮想化する機能であるエミュレート機能と、前記第1及び第2のゲストOSの各々について動的に割り当てる又は回収する資源を決定する機能である資源スケジューリング機能とを有し、
前記簡易ハイパバイザは、前記ハイパバイザの前記資源スケジューリング機能に従い前記第1のゲストOSに対する資源割当て又は資源回収を前記ハイパバイザに代わって行う機能であるスケジューリングエージェント機能を有し、
前記ハイパバイザは、資源の割当て又は回収に関する要求を発行し、前記簡易ハイパバイザが、前記要求を取得し、前記要求に従い処理を実行する、
計算機。 - 前記要求は、記憶領域に書き込まれ、
前記簡易ハイパバイザが、前記要求を前記記憶領域から取得する、
請求項1記載の計算機。 - 前記ハイパバイザを実行する第1の物理CPUとは別の第2の物理CPUが前記簡易ハイパバイザを実行し、
前記要求の発行は、トラップ命令の発行、又は、前記第2の物理CPUに対する割込みの通知である、
請求項2記載の計算機。 - 前記記憶領域は、要求ログ情報を記憶する不揮発領域であり、
前記要求は、ログとして前記要求ログ情報に追加され、
前記簡易ハイパバイザが、前記要求ログ情報内の前記ログを、前記要求に従う処理の実行に基づき更新する、
請求項2記載の計算機。 - 前記要求が、CPU割当て要求の場合、前記簡易ハイパバイザが、割当て対象の物理CPU上で動作を開始し、前記第1のゲストOSに、前記割当て対象の移りCPUが利用可能になったことを通知し、
前記要求が、CPU回収要求の場合、前記簡易ハイパバイザが、前記第1のゲストOSに割り当てられている物理CPUのうち回収対象の物理CPUを前記第1のゲストOSに通知し、前記回収対象の物理CPU上での動作を停止する、
請求項1記載の計算機。 - 前記CPU割当て要求の発行は、トラップ命令の発行であり、
前記CPU回収要求の発行は、前記利用不可能にある物理CPUに対する割込み通知である、
請求項5記載の計算機。 - 前記要求が、メモリ割当て要求の場合、前記簡易ハイパバイザが、前記1以上の物理メモリのうちの割当て対象のメモリ領域を、前記第1のゲストOSからアクセス可能となるよう、前記第1のゲストOSから指定される論理アドレスであるゲストアドレスと、前記1以上の物理メモリにおけるメモリ領域の物理アドレスであるホストアドレスとの対応付けを表すアドレス変換情報を更新し、前記割当て対象のメモリ領域が利用可能になったことを前記第1のゲストOSに通知し、
前記要求が、メモリ回収要求の場合、前記簡易ハイパバイザが、前記第1のゲストOSに割り当てられているメモリ領域のうち利用不可能なメモリ領域を前記第1のゲストOSに通知し、前記利用不可能なメモリ領域を前記第1のゲストOSからアクセス不可能となるよう前記アドレス変換テーブルを更新する、
請求項1記載の計算機。 - 前記要求ログ情報内の各ログは、そのログに対応した要求に従う処理の進捗状況を含み、
前記不揮発領域は、更に、前記複数の資源の割当て状態を表す割当て状態情報を記憶し、
前記ハイパバイザは、再起動した場合、前記不揮発領域内の前記要求ログ情報及び前記割当て状態情報を参照し、処理中の要求については処理が完了するまで待ち、前記要求ログ情報を基に前記割当て状態情報を更新し、更新後の割当て状態情報を基に、前記複数の資源のうち前記第1のゲストOSに割り当てられていない資源を用いて、前記ハイパバイザ及び前記第2のゲストOSの初期化を実行する、
請求項4記載の計算機。 - 前記第1のゲストOS、前記簡易ハイパバイザ、及び、前記第1のゲストOSから指定される論理アドレスであるゲストアドレスと前記1以上の物理メモリにおけるメモリ領域の物理アドレスであるホストアドレスとの対応付けを表すアドレス変換情報は、前記第1のメモリ領域に配置され、
前記第1のメモリ領域は、前記ハイパバイザ及び前記第2のゲストOSから書き込み不可能な領域である、
請求項1記載の計算機。 - 前記簡易ハイパバイザが、前記第1のゲストOSから特権命令が発行された場合、前記特権命令に基づきレジスタの値を更新することを前記ハイパバイザに代わって実行する、
請求項1記載の計算機。 - 前記ハイパバイザが、各ゲストOSについて、
使用可能な資源量の範囲を特定し、
発行対象の要求に従う資源割当て又は資源回収が実行されると、割り当てられている資源量が前記特定した範囲外の資源量となる場合、前記要求の発行を中止する、
請求項1記載の計算機。 - 前記ハイパバイザが、各ゲストOSについて、割り当てられている資源の量である割当て資源量を管理し、
前記ハイパバイザが、各ゲストOSついて、資源割当て又は資源回収に伴い、前記割当て資源量を更新する、
請求項1記載の計算機。 - 前記ハイパバイザが、前記第2のゲストOSからアクセス可能なメモリ領域を制御するためのアドレス設定要求を発行し、
前記簡易ハイパバイザが、前記アドレス変更要求に従い前記アドレス変換情報を更新する、
請求項9記載の計算機。 - 前記要求ログ情報内の各ログは、そのログに対応した要求に従う処理の進捗状況を含み、
前記要求が、CPU回収要求の場合、前記簡易ハイパバイザが、前記第1のゲストOSに割り当てられている物理CPUのうち回収対象の物理CPUを前記第1のゲストOSに通知し、前記回収対象の物理CPU上での動作を停止し、
前記ハイパバイザが、
前記CPU回収要求に従い前記簡易ハイパバイザが動作を停止した後、割込み通知を待ち、
前記CPU回収要求に対応した処理の進捗情報を前記要求ログ情報から特定し、
前記特定した進捗状況が完了を表している場合、前記回収対象の物理CPUに対して割込み通知を行う、
請求項4記載の計算機。 - 1以上の物理メモリと複数の物理CPU(Central Processing Unit)とを含んだ複数の資源を有する計算機においてハイパバイザにより資源スケジューリングを行う資源スケジューリング方法であって、
前記1以上の物理メモリに、前記ハイパバイザに使用されない第1の物理メモリ領域と、前記ハイパバイザに使用される第2の物理メモリ領域とを設け、前記複数の資源のうちの、前記ハイパバイザに使用される資源とは異なる資源を用いて、簡易ハイパバイザを実行し、
前記簡易ハイパバイザ上で、前記第1の物理メモリ領域を基に、第1のゲストOS(Operating System)を実行し、前記ハイパバイザ上で、前記第2の物理メモリ領域を基に、第2のゲストOSを実行し、前記ハイパバイザは、前記複数の資源を複数の仮想資源に仮想化する機能であるエミュレート機能と、前記第1及び第2のゲストOSの各々について動的に割り当てる又は回収する資源を決定する機能である資源スケジューリング機能とを有し、前記簡易ハイパバイザは、前記ハイパバイザの前記資源スケジューリング機能に従い前記第1のゲストOSに対する資源割当て又は資源回収を前記ハイパバイザに代わって行う機能であるスケジューリングエージェント機能を有し、
前記ハイパバイザにより、資源の割当て又は回収に関する要求を発行し、
前記簡易ハイパバイザにより、前記要求を取得し、前記要求に従い処理を実行する、
資源スケジューリング方法。
Priority Applications (6)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201480072730.0A CN105900066B (zh) | 2014-02-17 | 2014-02-17 | 计算机以及基于管理程序的资源调度方法 |
US15/035,490 US10162663B2 (en) | 2014-02-17 | 2014-02-17 | Computer and hypervisor-based resource scheduling method |
PCT/JP2014/053613 WO2015122007A1 (ja) | 2014-02-17 | 2014-02-17 | 計算機、及び、ハイパバイザによる資源スケジューリング方法 |
JP2015562672A JP6198858B2 (ja) | 2014-02-17 | 2014-02-17 | 計算機、及び、ハイパバイザによる資源スケジューリング方法 |
DE112014005348.1T DE112014005348T5 (de) | 2014-02-17 | 2014-02-17 | Computer und Hypervisor-basiertes Betriebsmittelplanungsverfahren |
GB1608554.0A GB2537760A (en) | 2014-02-17 | 2014-02-17 | Computer, and resource scheduling method using hypervisor |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/JP2014/053613 WO2015122007A1 (ja) | 2014-02-17 | 2014-02-17 | 計算機、及び、ハイパバイザによる資源スケジューリング方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2015122007A1 true WO2015122007A1 (ja) | 2015-08-20 |
Family
ID=53799770
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/JP2014/053613 WO2015122007A1 (ja) | 2014-02-17 | 2014-02-17 | 計算機、及び、ハイパバイザによる資源スケジューリング方法 |
Country Status (6)
Country | Link |
---|---|
US (1) | US10162663B2 (ja) |
JP (1) | JP6198858B2 (ja) |
CN (1) | CN105900066B (ja) |
DE (1) | DE112014005348T5 (ja) |
GB (1) | GB2537760A (ja) |
WO (1) | WO2015122007A1 (ja) |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP6515771B2 (ja) * | 2015-10-07 | 2019-05-22 | 富士通コネクテッドテクノロジーズ株式会社 | 並列処理装置及び並列処理方法 |
CN110838938B (zh) * | 2019-10-11 | 2021-09-07 | 成都飞机工业(集团)有限责任公司 | 一种基于工控网的dnc数据存储服务器调度方法 |
US11593170B2 (en) | 2020-03-25 | 2023-02-28 | Red Hat, Inc. | Flexible reverse ballooning for nested virtual machines |
US20220321567A1 (en) * | 2021-03-31 | 2022-10-06 | Netapp, Inc. | Context Tracking Across a Data Management Platform |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008293117A (ja) * | 2007-05-22 | 2008-12-04 | Hitachi Ltd | 仮想計算機の性能監視方法及びその方法を用いた装置 |
JP2009048607A (ja) * | 2007-08-20 | 2009-03-05 | Hitachi Ltd | 視覚化および地理的分散データセンタ用記憶装置およびサーバプロビジョニング |
JP2010033404A (ja) * | 2008-07-30 | 2010-02-12 | Hitachi Ltd | 仮想計算機システムおよび仮想計算機システムの制御方法 |
JP2013041445A (ja) * | 2011-08-17 | 2013-02-28 | Fujitsu Ltd | 情報処理装置、情報処理方法及び情報処理プログラム |
JP2013509626A (ja) * | 2009-10-30 | 2013-03-14 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 仮想コンピューティング環境における障害管理のための方法、システム、およびコンピュータ・プログラム |
Family Cites Families (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPH10187638A (ja) * | 1996-10-28 | 1998-07-21 | Mitsubishi Electric Corp | クラスタ制御システム |
US7886293B2 (en) * | 2004-07-07 | 2011-02-08 | Intel Corporation | Optimizing system behavior in a virtual machine environment |
US7814495B1 (en) * | 2006-03-31 | 2010-10-12 | V Mware, Inc. | On-line replacement and changing of virtualization software |
US7673113B2 (en) * | 2006-12-29 | 2010-03-02 | Intel Corporation | Method for dynamic load balancing on partitioned systems |
US7979869B2 (en) * | 2007-09-28 | 2011-07-12 | Oracle America, Inc. | Method and system for performing I/O operations using a hypervisor |
US7743375B2 (en) * | 2008-06-27 | 2010-06-22 | International Business Machines Corporation | Information handling system including dynamically merged physical partitions |
JP5232602B2 (ja) * | 2008-10-30 | 2013-07-10 | 株式会社日立製作所 | ストレージ装置、及びストレージコントローラ内部ネットワークのデータ経路フェイルオーバー方法 |
US8635057B2 (en) * | 2009-03-30 | 2014-01-21 | Microsoft Corporation | Enlightenment for low overhead hardware access |
US20110113426A1 (en) * | 2009-11-09 | 2011-05-12 | Hsiang-Tsung Kung | Apparatuses for switching the running of a virtual machine between multiple computer devices belonging to the same computer platform and the associated switching methods |
JP5493125B2 (ja) * | 2010-02-05 | 2014-05-14 | 株式会社日立製作所 | 仮想化方法及び計算機 |
JP5463267B2 (ja) * | 2010-11-19 | 2014-04-09 | 株式会社日立製作所 | 仮想計算機システムおよび仮想計算機の移行方法 |
CN102770846B (zh) * | 2010-12-21 | 2016-08-31 | 松下电器(美国)知识产权公司 | 虚拟计算机系统控制装置及虚拟计算机系统控制方法 |
WO2013024510A2 (en) * | 2011-08-16 | 2013-02-21 | Hitachi, Ltd. | Storage control apparatus |
US9075642B1 (en) * | 2011-09-30 | 2015-07-07 | Emc Corporation | Controlling access to resources using independent and nested hypervisors in a storage system environment |
WO2013121531A1 (ja) * | 2012-02-15 | 2013-08-22 | 株式会社日立製作所 | 仮想計算機システム及び仮想計算機の障害予兆回復方法 |
KR101471879B1 (ko) * | 2012-10-31 | 2014-12-11 | 삼성에스디에스 주식회사 | 하이퍼바이저 기반 서버 이중화 시스템, 그 방법 및 서버 이중화 컴퓨터 프로그램이 기록된 기록매체 |
US9229752B2 (en) * | 2013-03-12 | 2016-01-05 | International Business Machines Corporation | Systems and methods to offload hardware support using a hypervisor subpartition |
US9606818B2 (en) * | 2013-03-14 | 2017-03-28 | Qualcomm Incorporated | Systems and methods of executing multiple hypervisors using multiple sets of processors |
JP5941868B2 (ja) * | 2013-04-18 | 2016-06-29 | 株式会社日立製作所 | 仮想計算機システムおよび仮想計算機におけるi/o実施方法 |
GB2518894A (en) * | 2013-10-07 | 2015-04-08 | Ibm | A method and a system for operating programs on a computer cluster |
-
2014
- 2014-02-17 US US15/035,490 patent/US10162663B2/en active Active
- 2014-02-17 WO PCT/JP2014/053613 patent/WO2015122007A1/ja active Application Filing
- 2014-02-17 CN CN201480072730.0A patent/CN105900066B/zh active Active
- 2014-02-17 DE DE112014005348.1T patent/DE112014005348T5/de not_active Withdrawn
- 2014-02-17 GB GB1608554.0A patent/GB2537760A/en not_active Withdrawn
- 2014-02-17 JP JP2015562672A patent/JP6198858B2/ja not_active Expired - Fee Related
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2008293117A (ja) * | 2007-05-22 | 2008-12-04 | Hitachi Ltd | 仮想計算機の性能監視方法及びその方法を用いた装置 |
JP2009048607A (ja) * | 2007-08-20 | 2009-03-05 | Hitachi Ltd | 視覚化および地理的分散データセンタ用記憶装置およびサーバプロビジョニング |
JP2010033404A (ja) * | 2008-07-30 | 2010-02-12 | Hitachi Ltd | 仮想計算機システムおよび仮想計算機システムの制御方法 |
JP2013509626A (ja) * | 2009-10-30 | 2013-03-14 | インターナショナル・ビジネス・マシーンズ・コーポレーション | 仮想コンピューティング環境における障害管理のための方法、システム、およびコンピュータ・プログラム |
JP2013041445A (ja) * | 2011-08-17 | 2013-02-28 | Fujitsu Ltd | 情報処理装置、情報処理方法及び情報処理プログラム |
Also Published As
Publication number | Publication date |
---|---|
US10162663B2 (en) | 2018-12-25 |
GB2537760A (en) | 2016-10-26 |
DE112014005348T5 (de) | 2016-08-11 |
JPWO2015122007A1 (ja) | 2017-03-30 |
GB201608554D0 (en) | 2016-06-29 |
US20160378533A1 (en) | 2016-12-29 |
JP6198858B2 (ja) | 2017-09-20 |
CN105900066A (zh) | 2016-08-24 |
CN105900066B (zh) | 2018-05-11 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11995462B2 (en) | Techniques for virtual machine transfer and resource management | |
US9250943B2 (en) | Providing memory condition information to guest applications | |
EP2313832B1 (en) | Direct memory access filter for virtualized operating systems | |
US9304794B2 (en) | Virtual machine control method and virtual machine system using prefetch information | |
JP4668166B2 (ja) | ゲストがメモリ変換されたデバイスにアクセスする方法及び装置 | |
EP2588957B1 (en) | Cooperative memory resource management via application-level balloon | |
JP3546678B2 (ja) | マルチos構成方法 | |
US20040205755A1 (en) | Operating systems | |
US10162657B2 (en) | Device and method for address translation setting in nested virtualization environment | |
US10289564B2 (en) | Computer and memory region management method | |
US20110197190A1 (en) | Virtualization method and virtual machine | |
JP6198858B2 (ja) | 計算機、及び、ハイパバイザによる資源スケジューリング方法 | |
US10248454B2 (en) | Information processing system and apparatus for migrating operating system | |
JP5819350B2 (ja) | 計算機システム及び起動方法 | |
US20150302222A1 (en) | Computing machine, access management method, and access management program | |
US20200218459A1 (en) | Memory-mapped storage i/o |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 14882521 Country of ref document: EP Kind code of ref document: A1 |
|
ENP | Entry into the national phase |
Ref document number: 2015562672 Country of ref document: JP Kind code of ref document: A |
|
WWE | Wipo information: entry into national phase |
Ref document number: 15035490 Country of ref document: US |
|
ENP | Entry into the national phase |
Ref document number: 201608554 Country of ref document: GB Kind code of ref document: A Free format text: PCT FILING DATE = 20140217 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 112014005348 Country of ref document: DE |
|
122 | Ep: pct application non-entry in european phase |
Ref document number: 14882521 Country of ref document: EP Kind code of ref document: A1 |
|
ENPC | Correction to former announcement of entry into national phase, pct application did not enter into the national phase |
Ref country code: GB |