JP6628742B2 - Method and apparatus for selecting a host for a virtual machine using hardware multithreading parameters - Google Patents

Description

  The present disclosure relates generally to deploying virtual machines on a host computer system, and more particularly, to selecting a host for a virtual machine using hardware multi-threading parameters.

  In a cloud environment, a cloud manager deploys virtual machines to a host computer system to create virtual servers. Typically, the cloud manager receives a request specifying what the virtual machine image is requesting for system resources, such as memory, disk, and CPU. The cloud manager then determines available host computer systems having the requested system resources, selects one of the available host computer systems, and assigns the virtual machine to the selected host computer system. Deploy to

  OpenStack is open source software for building private and public clouds. In OpenStack, a virtual hardware template called "flavor" specifies system resources required for a virtual machine. For example, the flavor in OpenStack can specify the size of memory for the virtual machine, the root disk size, and the number of virtual CPUs. When a virtual machine is required to be deployed, a call is made to the cloud manager with a flavor that specifies the required resources for that virtual machine. The cloud manager then finds one or more host computer systems having the specified resources in the flavor and deploys the virtual machine on one of the host computer systems that fills the flavor.

  Hardware multi-threading within a host can complicate the provisioning of virtual machines to host computer systems. In the prior art, when hyper-threading is enabled on a host computer system, the number of hardware threads is taken into account when selecting a host computer system for a virtual machine, and the virtual CPU allocates physical cores. Assigned to hardware threads without care. If hyperthreading is not enabled on the host computer system, only the physical processor cores are considered when selecting the host computer system for the virtual machine, and the virtual CPU is Are only assigned to physical processor cores when VMs are provisioned. Modern processor architectures such as POWER, which include many hardware threads in each core, result in very inefficient use of processing resources.

  Provisioning a virtual machine can be even more complex when the processor has a split core. A split-core processor refers to a CPU core that can be divided into multiple sub-cores, each of which can include multiple hardware threads, where the sub-core appears as a core to a guest operating system . For example, a split-core capable core having eight hardware threads can be divided into four sub-cores, each capable of supporting two hardware threads. The split core enablement is dynamic, which means that the split can be changed programmatically on the host operating system. Known cloud managers do not treat split-core processors differently than processors without split cores. As a result, known cloud managers fail to realize the benefits of using a split-core processor when provisioning virtual machines.

  It is an object of the present invention to provide a method and apparatus for selecting a host for a virtual machine using hardware multi-threading parameters.

  According to a first aspect, there is provided an apparatus comprising at least one processor, a memory coupled to the at least one processor, and a cloud manager resident in the memory and executed by the at least one processor. The cloud manager determines the number of CPUs available on the plurality of host computer systems on which the virtual machines can be deployed and determines the number of CPUs supported by each CPU on the plurality of host computer systems. A host monitoring mechanism for further determining the number of threads, and a host selecting mechanism for receiving a virtual machine (VM) request including the number of virtual CPUs and hardware multi-threading parameters, the CPU having a number of hardware threads satisfying the VM request Multiple host computers, including Selecting one of the data system, comprising a host selection mechanism.

  According to a second aspect, there is provided a computer-implemented method for selecting a host computer system for deploying a virtual machine, executed by at least one processor, the method comprising deploying a virtual machine. Determining the number of CPUs available on multiple host computer systems, determining the number of hardware threads supported by each CPU on multiple host computer systems, and determining the number of virtual CPUs. Receiving a virtual machine (VM) request including hardware multi-threading parameters and selecting one of a plurality of host computer systems including a number of CPUs having a number of hardware threads that satisfy the VM request. And including.

  The present invention can also be implemented as a computer program.

  According to a preferred embodiment, the cloud manager monitors available resources on the host computer system, including the number of hardware threads supported by the CPU on the host computer system. The cloud manager receives a request for provisioning a virtual machine (VM) that includes hardware multithreading parameters that specify the amount of hardware multithreading required on the host computer system. The cloud manager then selects a host computer system for the VM, taking into account the hardware multi-threading parameters.

  According to one embodiment, there is provided a solution performed with the placement of virtual CPUs using hardware multi-threading parameters.

  In one embodiment, this disclosure relates generally to deploying a virtual machine to a host computer system, and more specifically, deploying a virtual CPU to a host computer system using hardware multithreading parameters. About.

  In one embodiment, a solution is provided for provisioning a virtual CPU with hardware multithreading parameters in a host with a split-core processor.

  According to one embodiment, this disclosure relates generally to deploying virtual machines on a host computer system, and more specifically, using a hardware multi-threading parameter to split a virtual CPU into one or more splits. Deploying on a host computer system that includes a core processor.

  According to one embodiment, there is provided an apparatus comprising at least one processor, memory coupled to the at least one processor, and a cloud manager resident in the memory and executed by the at least one processor. The cloud manager determines the number of CPUs available on the plurality of host computer systems on which the virtual machines can be deployed and determines the number of CPUs supported by each CPU on the plurality of host computer systems. A host monitoring mechanism for further determining the number of threads, and a host selecting mechanism for receiving a virtual machine (VM) request including the number of virtual CPUs and hardware multi-threading parameters, the CPU having a number of hardware threads satisfying the VM request Multiple host con And a virtual CPU (vCPU) that places one or more virtual CPUs (vCPUs) on the selected host computer system using a hardware multithreading parameter to select one of the computer systems. An arrangement mechanism.

  According to one embodiment, there is provided a computer-implemented method for deploying a plurality of virtual CPUs (vCPUs) executed by at least one processor on a host computer system, the method deploying a virtual machine. Determining the number of available CPUs on the plurality of host computer systems, determining the number of hardware threads supported by each CPU on the plurality of host computer systems, and Receiving a virtual machine (VM) request including a number and hardware multithreading parameters, and selecting one of a plurality of host computer systems including a number of CPUs having a number of hardware threads that satisfy the VM request To select multiple vCPUs Includes the use of hardware multithreading parameters for placement on a host computer system, the.

  According to one embodiment, there is provided a computer-implemented method for deploying a plurality of virtual CPUs (vCPUs) on a host computer system, the method being executed by at least one processor, the method comprising deploying a virtual machine. Determining the number of CPUs, the amount of memory, and the amount of disk space available on a plurality of host computer systems, and the hardware supported by each CPU on the plurality of host computer systems. Determining the number of threads and receiving a virtual machine (VM) request, where the VM request specifies a minimum amount of memory for the VM and a minimum amount of disk for the VM. Specifying disk requirements, number of virtual CPUs for VMs, and hardware multithreading A CPU requirement specifying a hardware multithreading parameter, wherein the first value of the hardware multithreading parameter indicates that hardware multithreading is turned off, and the second value of the hardware multithreading parameter. Indicates a numerical value for the number of hardware threads, and the third value of the hardware multi-threading parameter indicates that the selected host computer system has hardware threading on the selected host computer system. Receiving a VM request, indicating that is selected whether it is on or off, and including a number of CPUs having a number of hardware threads that satisfy the VM request. Select one of And using the hardware multi-threading parameter to place the plurality of vCPUs on the selected host computer system, wherein the hardware multi-threading parameter is turned off when hardware multi-threading is turned off. If so, placing each vCPU in the VM on a different physical core in the selected host computer system and the hardware multithreading parameter indicating the number of hardware threads And using each vCPU in the VM by placing it on a different hardware thread in the selected host computer system.

  According to one embodiment, there is provided a method as described in the preceding paragraph, further comprising resizing the VM using hardware multi-threading parameters.

  According to one embodiment, there is provided an apparatus comprising at least one processor, memory coupled to the at least one processor, and a cloud manager resident in the memory and executed by the at least one processor. The cloud manager can determine the number of CPUs available on the multiple host computer systems on which the virtual machines can be deployed, the number of hardware threads supported by each CPU on the multiple host computer systems, A host monitoring mechanism for determining whether a split core is enabled for each CPU on a plurality of host computer systems, and a virtual machine (VM) request including a number of virtual CPUs and hardware multi-threading parameters. Host selection machine to receive Selecting one of the plurality of host computer systems, including the number of virtual CPUs in the VM request and the number of CPUs having the number of hardware threads that satisfy the hardware multithreading parameters and the split core setting. , A host selection mechanism.

  According to one embodiment, there is provided a computer-implemented method for deploying a plurality of virtual CPUs (vCPUs) on a host computer system, the method being executed by at least one processor, the method comprising deploying a virtual machine. Determining the number of CPUs available on the plurality of host computer systems capable of doing so; determining the number of hardware threads supported by each CPU on the plurality of host computer systems; Determine if each CPU on the host computer system has split cores enabled, and if so, determine the number of sub-cores per core; and determine the number of virtual CPUs and hardware Virtual machine (VM) requests containing multi-threading parameters Selecting one of the plurality of host computer systems, including the number of CPUs having a number of virtual threads in the VM request and the number of hardware threads satisfying the hardware multi-threading parameters and the split core setting. To do.

  According to one embodiment, there is provided a computer-implemented method for deploying a plurality of virtual CPUs (vCPUs) on a host computer system, the method being executed by at least one processor, the method comprising deploying a virtual machine. Determining the number of CPUs, the amount of memory, and the amount of disk space available on a plurality of host computer systems, and the hardware supported by each CPU on the plurality of host computer systems. Determining a number of threads, determining whether each CPU on the plurality of host computer systems has an enabled split core, and receiving a virtual machine (VM) request; This VM request specifies the minimum amount of memory for the VM And the disk requirements specifying the minimum amount of disks for the VM, and the CPU requirements specifying the number of virtual CPUs and the hardware multithreading parameters for the VM, where the hardware multithreading parameters The first value indicates that hardware multi-threading is turned off, the second value of the hardware multi-threading parameter indicates a numerical value for the number of hardware threads, and the hardware multi-threading parameter A third value of the VM request indicates that the selected host computer system has been selected on the selected host computer system regardless of whether hardware threading is on or off. And V Selecting one of a plurality of host computer systems, including a number of CPUs having a number of virtual threads and a number of hardware threads that satisfy a hardware multithreading parameter in the request and a split core setting; using the hardware multithreading parameters and the selected host computer system's split core settings to place the vCPU on the selected host computer system, wherein the hardware multithreading parameters are By placing each vCPU in the VM on a different physical core in the selected host computer system, if it indicates that multithreading is turned off, and If the threading parameters indicate that the number of hardware threads and the split-core setting of the selected computer system are enabled, each vCPU in the VM is loaded into the CPU in the selected host computer system. By placing it on a different hardware thread in the sub-core of the.

  According to one embodiment, the cloud manager monitors available resources on the host computer system, including the number of hardware threads supported by the CPU on the host computer system. The cloud manager receives a request for provisioning a virtual machine (VM) that includes hardware multithreading parameters that specify whether hardware multithreading is allowed on the host computer system. The cloud manager then selects a host computer system for the VM, taking into account the hardware multi-threading parameters. The cloud manager then selects a host computer system for the VM, taking into account the hardware multi-threading parameters. The VM is then deployed on the selected host computer system using the hardware multi-threading parameters.

  According to one embodiment, the cloud manager includes the number of hardware threads supported by the CPU on the host computer system, and whether the CPU has split cores enabled, Monitor available resources on the host computer system. The cloud manager receives a request for provisioning a virtual machine (VM) that includes hardware multithreading parameters that specify whether hardware multithreading is allowed on the host computer system. The cloud manager then selects a host computer system for the VM, taking into account hardware multi-threading parameters, hardware threads supported by the CPU, and split core settings. The VM is then deployed on the selected host computer system using the hardware multi-threading parameters. The result is more efficient utilization of CPU resources in the host for virtual machines.

  The above and other features and advantages will be apparent from the following specific details, as illustrated in the accompanying drawings.

  Embodiments of the present invention will be described by way of example only with reference to the following drawings. Like symbols indicate like elements.

FIG. 2 is a block diagram of a cloud computing node according to a preferred embodiment of the present invention. 1 is a block diagram of a cloud computing environment according to a preferred embodiment of the present invention. FIG. 4 is a block diagram of an abstract model layer according to a preferred embodiment of the present invention. FIG. 4 is a block diagram illustrating some features of a cloud manager according to a preferred embodiment of the present invention. FIG. 4 is a block diagram illustrating some features of a cloud VM request according to a preferred embodiment of the present invention. FIG. 4 is a flow diagram of a method for a cloud manager for logging available resources on a potential host computer system according to a preferred embodiment of the present invention. FIG. 4 is a flow diagram of a method for a cloud manager to provision a VM on a host computer system according to a preferred embodiment of the present invention. FIG. 2 is a block diagram of a conventional x86 dual-core CPU. FIG. 3 is a flow diagram of a prior art method for a cloud manager to select a host for a VM request. FIG. 11 is a block diagram showing how CPU requirements are specified in a conventional cloud VM request. FIG. 2 is a block diagram of a potential host computer system showing three x86 dual-core processors according to a preferred embodiment of the present invention. FIG. 12 is a block diagram illustrating a virtual machine including a vCPU that can be assigned to the potential host of FIG. 11 according to a preferred embodiment of the present invention. FIG. 2 is a flow diagram of a prior art method for placing a vCPU on a physical core in a host computer system. FIG. 3 is a block diagram illustrating the architecture of a Power8 6-core CPU, showing two of the six cores, according to a preferred embodiment of the present invention. FIG. 4 is a block diagram of a method for selecting a host and controlling placement for vCPUs on the host using hardware multi-threading parameters according to a preferred embodiment of the present invention. 5 is a sample CPU requirement including vCPU number and hardware multi-threading parameters according to a preferred embodiment of the present invention. 5 is a first sample CPU requirement including hardware multithreading parameters according to a preferred embodiment of the present invention. FIG. 18 illustrates a potential Power8 host meeting the CPU requirements of FIG. 17, according to a preferred embodiment of the present invention. 7 is a second sample CPU requirement including hardware multithreading parameters according to a preferred embodiment of the present invention. FIG. 20 illustrates a potential Power8 host meeting the CPU requirements of FIG. 19, according to a preferred embodiment of the present invention. 9 is a third sample CPU requirement including hardware multi-threading parameters according to a preferred embodiment of the present invention. 31 illustrates a potential Power8 host meeting the CPU requirements of FIG. 31, according to a preferred embodiment of the present invention. 4 is a fourth sample CPU requirement including hardware multi-threading parameters according to a preferred embodiment of the present invention. 23 illustrates a potential Power8 host meeting the CPU requirements of FIG. 23, according to a preferred embodiment of the present invention. FIG. 4 is a flow diagram of a method for selecting a host that satisfies CPU requirements including hardware multithreading parameters according to a preferred embodiment of the present invention. FIG. 4 is a flow diagram of a method for placing a vCPU on a selected host computer system using hardware multi-threading parameters. FIG. 4 is a block diagram illustrating host-level statistics gathered for each potential host, according to a preferred embodiment of the present invention. FIG. 3 is a block diagram illustrating additional specifications that may be implemented within OpenStack flavors to specify hardware multithreading parameters, according to a preferred embodiment of the present invention. FIG. 9 is a flow diagram of a method for performing a resize operation on an existing VM that may include hardware multi-threading parameters. FIG. 3 is a block diagram illustrating the architecture of a Power8 6-core CPU with split core enabled, showing two of the six cores. Sample CPU requirements including vCPU count and hardware multi-threading parameters. 3 is a first sample CPU requirement including hardware multithreading parameters. FIG. 33 illustrates a potential Power8 host meeting the CPU requirements of FIG. 32. 2 is a second sample CPU requirement including hardware multithreading parameters. FIG. 36 illustrates a potential Power8 host meeting the CPU requirements of FIG. 34. 9 is a third sample CPU requirement including hardware multithreading parameters. FIG. 37 illustrates a potential Power8 host meeting the CPU requirements of FIG. 36. 4 is a fourth sample CPU requirement including hardware multi-threading parameters. FIG. 39 illustrates a potential Power8 host meeting the CPU requirements of FIG. 38. FIG. 7 is a flow diagram of a method for selecting a host that satisfies CPU requirements, including hardware multithreading parameters, and taking into account if the host has a split core. FIG. 9 is a block diagram illustrating a filter that can be used to exclude hosts having enabled split core mode when the hardware multithreading parameter is set to 4 or 8. FIG. 4 is a flow diagram of a method for placing a vCPU on a selected host computer system using hardware multi-threading parameters and taking into account where the host has a split core.

  The cloud manager determines the available resources on the host computer system, including the number of hardware threads supported by the CPU on the host computer system and whether the CPU includes split cores enabled. To monitor. The cloud manager may specify whether hardware multithreading is allowed on the host computer system (or, in one embodiment, the amount of hardware multithreading required on the host computer system). Receive a request for provisioning a virtual machine (VM), including multi-threading parameters. The cloud manager then selects a host computer system for the VM, taking into account hardware multi-threading parameters, hardware threads supported by the CPU, and split core settings. The VM is then deployed on the selected host computer system using the hardware multi-threading parameters. The result is more efficient utilization of CPU resources in the host for virtual machines.

  Although this disclosure includes a detailed description of cloud computing, it will be appreciated in advance that the implementation of the teachings described herein is not limited to cloud computing environments. Rather, embodiments of the present invention may be implemented with any other type of computing environment now known or later developed.

  Cloud computing is a configurable computing resource (eg, network, network bandwidth, server, processing, memory) that can be quickly provisioned and released with minimal administrative effort or service provider interaction. , Storage, applications, virtual machines, and services) to provide convenient on-demand network access to a shared pool. The cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

The characteristics are as follows.
On-demand self-service: Cloud consumers can unilaterally provision computing power, such as server time and network storage, as needed, without the need for human interaction with service providers.
Extensive Network Access: Capabilities are available on the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (eg, mobile phones, laptops, and PDAs). You.
Resource pooling: Provider computing resources are pooled for use by multiple consumers using a multi-tenant model, and different physical and virtual resources are dynamically allocated and re-allocated on demand. Assigned. Consumers are generally position independent in that they have no control or knowledge of the exact location of the resources provided, but at a higher level of abstraction (eg, country, state, or data center). May be specified.
Rapid resilience: Capabilities can be provisioned quickly and resiliently, sometimes automatically provisioned, to quickly scale out, and quickly released to scale in quickly. For consumers, the capacity available for provisioning often looks unlimited and can be purchased in any quantity at any time.
Metered services: The cloud system automatically allocates resource usage by leveraging metering capabilities at some level of abstraction appropriate for the type of service (eg, storage, processing, bandwidth, and active user accounts). Control and optimization. Resource usage can be monitored, controlled, and reported to provide transparency to both service providers and consumers of the services used.

The service model is as follows.
Software as a Service (SaaS): The ability provided to the consumer is to use the provider's application, which runs on the cloud infrastructure. Applications are accessible from various client devices through a thin client interface, such as a web browser (eg, web-based email). Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.
Platform as a Service (PaaS): The ability provided to consumers is to deploy consumer-created or acquired applications created using programming languages and tools supported by the provider on the cloud infrastructure. . Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but have control over deployed applications and, in some cases, application hosting environment configuration.
Infrastructure as a Service (IaaS): The ability provided to a consumer is a process, storage, network, and other that allows the consumer to deploy and execute any software that may include an operating system and applications. Is to provision basic computing resources. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating system, storage, deployed applications, and possibly limited control over networking components (eg, host firewalls). Having.

The deployment model is as follows.
Private Cloud: The cloud infrastructure operates for one organization only. It can be managed by the organization or a third party, and can exist on-premises or off-premises.
Community cloud: The cloud infrastructure is shared by several organizations and supports specific communities that share concerns (eg, mission, security requirements, policies, and compliance considerations). It can be managed by those organizations or third parties, and can exist on-premises or off-premises.
Public Cloud: The cloud infrastructure is made available to the general public or large industry groups and is owned by the organization that sells the cloud services.
Hybrid cloud: The cloud infrastructure leaves its own entity, but with standardized or proprietary technologies that enable data and application portability (eg, cloud bursting for load balancing between clouds). A combination of two or more clouds (private, community, or public) tied together.

  Cloud computing environments are service-oriented and focus on statelessness, low connectivity, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

  Referring now to FIG. 1, a block diagram of an example of a cloud computing node is shown. Cloud computing node 100 is merely one example of a suitable cloud computing node and suggests any limitations as to the scope of use or functionality of the embodiments of the invention described herein. It is not intended. In any case, cloud computing node 100 may implement and / or perform any of the functions described above.

  Within the cloud computing node 100 is a computer system / server 110 operable with a number of other general purpose or special purpose computing system environments or configurations. Examples of well-known computing systems, environments, and / or configurations that may be suitable for use with the computer system / server 110 include, but are not limited to, a personal computer system, a server, Computer systems, tablet computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs , Minicomputer systems, mainframe computer systems, and distributed cloud computing environments that include any of the systems or devices described above.

  Computer system / server 110 may be described in the general context of computer system executable instructions, such as program modules, executed by a computer system. Generally, program modules can include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. Computer system / server 110 may execute within a distributed cloud computing environment where tasks are performed by remote processing devices that are linked through a communications network. In a distributed cloud computing environment, program modules may be located in both local and remote computer system storage media including memory storage devices.

  As shown in FIG. 1, the computer system / server 110 in the cloud computing node 100 is shown in the form of a general purpose computing device. The components of the computer system / server 110 include, but are not limited to, one or more processors or processing units 120, a system memory 130, and various system components including the system memory 130. A bus 122 may be included that couples to the processing unit 120.

  Bus 122 may be any type of bus, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures. Represents any one or more of the structures. By way of example, and not limitation, such architectures include the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the Enhanced ISA (EISA) Internal Bus Terminal, and the Video Electronics Corporation's External ASICs. (PCI) bus.

  Computer system / server 110 typically includes a variety of computer system readable media. Such media can be any available media that can be accessed by computer system / server 110 and includes both volatile and nonvolatile media, as well as removable and non-removable media. . In FIG. 1, an example of a removable medium is shown as including a digital video disk (DVD) 192.

  System memory 130 may include a computer system readable medium, such as firmware 132, in the form of volatile or non-volatile memory. Firmware 132 provides an interface to computer system / server 110. System memory 130 may also include computer system readable media in the form of volatile memory, such as random access memory (RAM) 134 and / or cache memory 136. Computer system / server 110 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 140 may be provided for reading from and writing to non-removable, nonvolatile magnetic media (not shown, typically referred to as a “hard drive”). . Although not shown, a magnetic disk drive for reading from and writing to a removable non-volatile magnetic disk (eg, a "floppy disk"), and a CD-ROM, DVD-ROM or other optical medium An optical disk drive for reading from and writing to a removable non-volatile optical disk such as an optical disk drive can be provided. In such an example, each could be connected to bus 122 by one or more data media interfaces. As further shown and described below, memory 130 includes at least one program product having a set of program modules (eg, at least one) configured to perform the functions described in more detail below. Can be included.

  A program / utility 150 having a set of program modules 152 (at least one) may include, by way of example and not limitation, an operating system, one or more application programs, other program modules, and program data, It can be stored in the memory 130. Each of the operating system, one or more application programs, other program modules, and program data, or some combination thereof, may include an implementation of a networking environment. Program module 152 generally performs the functions and / or methods of the embodiments of the present invention described herein.

  Computer system / server 110 may also include one or more external devices 190, such as a keyboard, pointing device, display 180, disk drive, etc., one that allows a user to interact with computer system / server 110. Or any device (eg, network card, modem, etc.) that enables computer system / server 110 to communicate with one or more other computing devices. can do. Such communication can be performed via an input / output (I / O) interface 170. Further still, computer system / server 110 may include one or more networks, such as a local area network (LAN), a universal wide area network (WAN), and / or a public network (eg, the Internet), and a network Communication can occur through the adapter 160. As shown, network adapter 160 communicates with other components of computer system / server 110 via bus 122. Although not shown, it should be understood that other hardware and / or software components can be used with computer system / server 110. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk drive arrays, Redundant Array of Independent Disk (RAID) systems, tape drives, and data archives. Storage systems and the like.

  Referring now to FIG. 2, an exemplary cloud computing environment 200 is shown. As shown, the cloud computing environment 200 includes a cloud consumer, such as, for example, a personal digital assistant (PDA) or cell phone 210A, a desktop computer 210B, a laptop computer 210C, and / or an automotive computer system 210N. It includes one or more cloud computing nodes 100 with which the local computing devices used by can communicate. Nodes 100 can communicate with each other. These can be physically or virtually grouped within one or more networks, such as a private cloud, community cloud, public cloud, or hybrid cloud as described above, or a combination thereof. Yes (not shown). This allows the cloud computing environment 200 to provide infrastructure, platform, and / or software as a service that does not require the cloud consumer to maintain resources on local computing devices. The types of computing devices 210A-N shown in FIG. 2 are intended by way of example only, and the computing node 100 and the cloud computing environment 200 may be any type of network and / or network addressable. It is understood that any type of computerized device can be communicated via a connection (eg, using a web browser).

  Referring now to FIG. 3, a set of functional abstraction layers provided by the cloud computing environment 200 of FIG. 2 is shown. It should be understood that the components, layers, and functions shown in FIG. 3 are intended to be illustrative only and that the disclosure and claims are not limited thereto. As shown, the following layers and corresponding functions are provided.

  The hardware and software layer 310 includes hardware and software components. Examples of hardware components are a mainframe, exemplified by an IBM® System z® system, and a RISC (Reduced Instruction Set Computer) architecture-based, exemplified by an IBM System p® system. Servers, IBM System x systems, IBM BladeCenter systems, storage devices, networks and networking components. Examples of software components include network application server software, such as the IBM WebSphere® application server software, and database software, such as the IBM DB2® database software. IBM, System z, System p, WebSphere, and DB2 are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide.

  The virtualization layer 320 is an abstraction layer that can provide the following examples of virtual entities: virtual servers, virtual storage, virtual networks including virtual private networks, virtual applications and operating systems, and virtual clients. I will provide a.

  In one example, management layer 330 can provide the functions described below. Resource provisioning provides for the dynamic sourcing of computing and other resources utilized to perform tasks within a cloud computing environment. Metering and pricing provides cost tracking when resources are utilized within a cloud computing environment and billing or billing for the consumption of these resources. In one example, these resources can include application software licenses. Security provides identity verification for cloud consumers and tasks, and protection for data and other resources. The user portal provides consumers and system administrators with access to a cloud computing environment. Service level management provides for the allocation and management of cloud computing resources such that required service levels are met. Service Level Agreement (SLA) planning and implementation provides for the pre-positioning and procurement of cloud computing resources whose future needs are anticipated according to the SLA. Cloud manager 350 represents a cloud manager (or shared pool manager), described in more detail below. Although cloud manager 350 is shown in FIG. 3 as residing within management layer 330, cloud manager 350 can span all of the levels shown in FIG. 3, as described below.

  Workload tier 340 provides examples of functions for which a cloud computing environment can be utilized. Examples of workloads and functions that can be provided from this layer include mapping and navigation, software development and lifecycle management, virtual classroom education delivery, data analysis processing, transaction processing, and mobile desktop. Including.

  The invention can be a system, method, and / or computer program product. The computer program product may include one or more computer readable storage media having computer readable program instructions for causing a processor to perform aspects of the present invention.

  The computer readable storage medium may be a tangible device capable of holding and storing instructions for use by the instruction execution device. The computer-readable storage medium can be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the above. Not limited. A non-exhaustive list of more specific examples of computer readable storage media includes portable computer diskettes, hard disks, random access memory (RAM), read only memory (ROM), erasable programmable read only memory ( EPROM or flash memory), static random access memory (SRAM), portable compact disk read only memory (CD-ROM), digital versatile disk (DVD), memory stick, floppy disk, punch card or recorded instructions And mechanically coded devices, such as raised structures in grooves, and any suitable combinations of the above. A computer-readable storage medium, as used herein, is a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (eg, a light pulse through a fiber optic cable), or It should not be interpreted as a transient signal per se, such as an electrical signal transmitted through a wire.

  The computer readable program instructions described herein may be downloaded from a computer readable storage medium to a respective computing / processing device, or may be downloaded, for example, over the Internet, a local area network, a wide area network, and / or a wireless network. Via an external computer or an external storage device. The network may include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer readable program instructions from the network and stores the computer readable program instructions on a computer readable storage medium in the respective computing / processing device. Transfer to

  Computer readable program instructions for performing the operations of the present invention include assembler instructions, instruction set architecture (ISA) instructions, machine language instructions, machine dependent instructions, microcode, firmware instructions, state setting data, or Java, Smalltalk. Source code or object code written in any combination of one or more programming languages, including an object-oriented programming language such as C ++, C ++, and a conventional procedural programming language such as the "C" programming language or a similar programming language It can be either. The computer readable program instructions may be executed entirely on the user's computer, partly on the user's computer, as a stand-alone software package, and partly on the user's computer. It may be performed and run in part on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or wide area network (WAN), or a connection to an external computer (Eg, through the Internet using an Internet service provider). In some embodiments, an electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) includes computer readable program instructions to implement aspects of the present invention. By using the state information to personalize the electronic circuit, computer readable program instructions can be executed.

  Aspects of the invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

  These computer readable program instructions are provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing device to produce a machine, and thereby executed by a computer or other processor of a programmable data processing device. The instructions may create means for implementing the specified function / operation in one or more blocks of the flowcharts and / or block diagrams. These computer program instructions are stored in a computer readable medium capable of directing a computer, programmable data processor, and / or other device to function in a particular manner, whereby A computer-readable medium having stored instructions may include a product that includes instructions that implement aspects of a function / operation specified in one or more blocks of the flowcharts and / or block diagrams.

  Computer readable program instructions are loaded onto a computer, other programmable data processing device or other device, and a series of operating steps are performed on the computer, another programmable data processing device or other device, and the computer implementation , Whereby instructions executed on a computer, other programmable device or other device implement specified functions / acts in one or more blocks of flowcharts and / or block diagrams. It can also be done.

  The flowcharts and block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of the systems, methods, and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of an instruction, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously, depending on the functions involved, or they may sometimes be executed in the reverse order. Each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, can also be implemented by dedicated hardware-based systems that perform the specified functions or operations, or Note also that a combination of dedicated hardware and computer instructions may be implemented.

  FIG. 4 shows one suitable example of the cloud manager 350 shown in FIG. Cloud manager 350 includes a cloud provisioning mechanism 410 that includes a resource request interface 420. The resource request interface 420 allows a software entity to request a virtual machine from the cloud manager 350 without human intervention. The cloud manager 350 also includes a user interface 430 that allows the user to interact with the cloud manager to perform any suitable function, including provisioning VMs, destroying VMs, analyzing cloud performance, and the like. Including. The difference between the resource request interface 420 and the user interface 430 is that the user interface 430 needs to be manually used by a user to perform a function specified by the user, while the resource request interface 420 , A software entity can be used to request provisioning of cloud resources by the cloud mechanism 350 without input from a human user.

  The cloud manager 350 also monitors available resources on the potential host computer system, and the cloud manager 350 determines whether resources specified on the VM and available resources on the potential host computer system are available. And a host monitoring mechanism 440 that allows for a comparison to be made. The host selection mechanism 450 allows for selecting a potential host computer system based on a comparison of the resources specified for the requested VM with the resources available on the potential host computer system. I do. The vCPU placement mechanism 460 places the vCPU on the selected host computer system using the hardware multi-threading parameters. VM resizing mechanism 470 allows existing VMs to be resized in a manner using hardware multi-threading parameters, even when the original VM does not use hardware multi-threading parameters.

  FIG. 5 can be submitted via the resource request interface 420 on the cloud provisioning mechanism 410 of FIG. 4 or via the user interface 430 to request that a VM be provisioned by the cloud manager 350. , Shows one suitable example of a cloud VM request 510. Cloud VM request 510 may include any specification of requirements for resources required on the VM. Examples of suitable requirements include a memory requirement 520, a disk requirement 530, and a CPU requirement 540. The memory requirement 520 specifies the required amount of memory for the VM. Disk requirements 530 specify the amount of disk required for the VM. The CPU requirements 540 specify the number of virtual CPUs required for the VM, and also specify hardware multithreading parameters, as described in more detail below. Of course, other requirements not shown in FIG. 5, such as network requirements and any other suitable requirements, may be specified for the VM. In the prior art, OpenStack uses what is called a "flavor" as a cloud VM request, which specifies the minimum requirements for resources on the VM.

  Referring to FIG. 6, a method 600 is preferably performed by the host monitoring mechanism 440 of FIG. 4 to monitor available resources on a potential host computer system. Available resources on the potential host computer system are determined (step 610) and logged (step 620). One known way to implement the method 600 uses a driver that queries the host for its available resources.

  Referring to FIG. 7, the method 700 begins by receiving a cloud VM request (step 710). Next, the resource requirements in the cloud VM request are compared to available resources on the potential host computer system (step 720). Note that the available resources in step 720 can be read from the log created in step 620 of FIG. Then, a host having resources meeting the resource requirements in the cloud VM request is selected. (Step 730). Next, the VM is deployed on the selected host computer system (step 740).

  Many modern processors (or CPUs) include multiple processing cores. One example of a multi-core processor is the x86 dual-core CPU 810 shown in FIG. The x86 dual-core CPU 810 includes a first core 820 having two hardware threads 822 and 824, and a second core 840 having two hardware threads 842 and 844. The presence of multiple hardware threads on each core can create problems in provisioning VMs to host computer systems. In the prior art, the number of hardware threads in a multi-core CPU is typically ignored, and only physical cores are taken into account. For example, the prior art method 900 of FIG. 9 reads a cloud VM request (step 910) and then selects a host with a number of physical cores that satisfies the number of vCPUs in the cloud VM request (step 920). The prior art CPU requirement 1010 as shown in FIG. 10 specifies the number of virtual CPUs (vCPUs), which is one suitable example for the CPU requirement 540 shown in FIG. Because the method 900 uses only physical cores when selecting a host for a VM, multiple hardware threads on the cores are not fully utilized, thus not utilizing available CPU resources. In other prior art, when host hyper-threading is enabled, the number of hardware threads is taken into account, and the placement of vCPUs on hardware threads is done without regard to the physical core. This approach results in inefficient VMs because some workloads benefit from thread utilization on different cores while other workloads are better served by threads on the same core. become.

  Step 920 of FIG. 9 may include any suitable criteria or heuristics for selecting a host computer system that meets the VM requirements. For example, the number of physical cores can be increased by some overcommit ratio, for example, 2.0. Thus, if a host has three physical cores available, multiplying three physical cores by an overcommit ratio of 2.0 results in six available processors, which requires six vCPUs. VMs can be deployed on that host, which means that VMs that require seven vCPUs cannot be deployed. Illustrate a simple example.

  FIG. 11 illustrates a sample potential host computer system including three dual-core x86 CPUs. This host has already been deployed to the two physical cores in CPU1 and the first of the two physical cores in CPU2, as indicated by the shaded cores in FIG. Assume that we have the VM1 shown in FIG. 12 running above. It is further assumed that the VM 2 shown in FIG. 12 needs to be deployed. The number of available cores is determined, which is, for example, 9 in the example of FIG. 11, ie, 6 cores are multiplied by an overcommit ratio of 2 and from there within the Potential Host 1 shown in FIG. 3 minus the three cores used by VM1. Since VM2 requires two vCPUs and potential host 1 has nine available cores, potential host 1 is a valid potential host for VM2 shown in FIG.

  Note that the actual placement of the vCPU on the potential host is a separate step from the selection of the potential host for the VM. Referring to FIG. 13, the method 1300 begins by reading a cloud VM request (step 1310). Next, the vCPU in the cloud VM request is placed on the physical core (step 1320). In FIG. 11, the first and second cores of the CPU 1 and the thread T1 of the first core of the CPU 2 are shaded, and two vCPUs in the VM 1 shown in FIG. Indicates that it was placed. However, note that the placement is not static. At different times, the vCPU can run on any hardware thread on any active core. With hyperthreading, there are a total of twelve hardware threads in three dual cores assigned. VM1 takes three of these threads, leaving nine for the other VMs. However, a vCPU is assigned to any of the threads, which means that work performed in operating system threads that share memory is best performed in the same vCPU hardware thread. On the other hand, work performed in a separate operating system thread means that it is better performed in hardware threads of different cores. Thus, the prior art identifies potential hosts for VMs because the assignment of VMs to potential hosts does not currently take into account differences between hardware threads and cores on the CPU. This will create inefficiencies in the manner and manner in which the VM runs on the selected host.

  The prior art recognizes either a physical processor core or a hardware thread as an entity on which a virtual CPU can be deployed, but not both. Without hyper-threading, a single dual-core CPU as shown in FIG. 8 would have two available CPUs in the form of its two physical cores 820 and 840, where the vCPU could be deployed. it can. With hyper-threading, a single dual-core CPU can support more vCPUs, but it is determined whether the vCPUs run on the same physical core or on different hardware threads on different cores. Not theoretical. The disclosure and claims herein create a finer level of granularity, where a vCPU is assigned to multiple hardware threads rather than simply being assigned to a single physical core or a single hardware thread. Recognize that it needs to be assigned to

  The problem of assigning a vCPU to either a single hardware thread or a core is exacerbated as the number of hardware threads increases. For the x86 dual-core CPU shown in FIGS. 8 and 11, hyperthreading results in two threads per core. The problem is more pronounced for processors with more hardware threads. For example, a Power8 6-core CPU 1410 shown in FIG. 14 has a first core 1420 including eight hardware threads 1432, 1434, 1436, 1438, 1442, 1444, 1446, and 1448, as well as eight hardware threads. A second core 1450 including 1462, 1464, 1466, 1468, 1472, 1474, 1476 and 1478 is shown. The other four cores are not shown in FIG. 14, but are similar to the two cores shown. If the host is selected based on the number of physical cores, as shown in the prior art method 900 of FIG. 9, many of the hardware threads will not be used. Thus, if two vCPUs are deployed in the two cores 1420 and 1450 shown in FIG. 14, this will result in wasting seven of the eight hardware threads on each core. The net result is that at any given time, only two of the two core's 16 threads are used, which wastes 14 of the 16 hardware threads. This means that using the prior art method 900 shown in FIG. 9, only two (12.5%) of the 16 available processing resources on two Power8 cores are available. Alternatively, if a vCPU is assigned to a hardware thread when there are a large number of hardware threads per core, a VM with a workload that requires a high degree of parallelism and shared memory can Are located on the same physical core as the other vCPUs, resulting in better performance than if distributed over many physical cores.

  To avoid the problem of distributing so many unused threads or vCPUs across physical cores as described above with reference to FIG. 14, a new scheme for identifying potential hosts and deploying VMs is: Based on the principle that vCPUs can be assigned to multiple hardware threads in a physical core instead of just a physical core or a single hardware thread, the hardware multi-threading parameter in the cloud VM request is Used to take hardware threads into account. This is done using new parameters in the cloud VM request related to hardware multi-threading. For the particular example herein, this hardware multi-threading parameter is called the "SMT" parameter, which is a well-known term used in the art to describe hardware multi-threading on a CPU. Represents Symmetric Multithreading. Referring to FIG. 15, a method 1500 begins by using the SMT parameters in a cloud VM request, in one embodiment, with information about the host regarding hardware threads per core and split core configuration, and A computer system is selected (step 1510). Once the host computer system is selected, the same SMT parameters in the cloud VM request can be used to make a placement decision for the vCPU when deploying the VM on the selected host (step 1520). In one embodiment, information about the host regarding hardware threads per core and split core configuration may also be used to make placement decisions for the vCPU when deploying VMs on the selected host. Yes (step 1520).

  FIG. 10 illustrates that prior art CPU requirements 1010 for cloud VM requests include specifying the required number of vCPUs 1020 on the VM. The cloud VM request 1610 shown in FIG. 16 according to the disclosure and claims of this specification includes the number of vCPUs 1620, but additionally includes hardware multithreading (SMT) parameters 1630. The value of the SMT parameter can be zero, indicating that hardware multithreading is turned off, or it can be a power of two, representing the number of hardware threads. Here are some examples. Referring to FIG. 17, a CPU requirement 1610A is one suitable example of the CPU requirement 1610 shown in FIG. 16, and includes two vCPUs 1720 and an SMT parameter 1730 having a value of 2. In the case of a potential host with a Power8 6-core CPU 1410 as shown in FIG. 14, the potential host has two threads used, as shown in FIG. Will have a core.

  The second CPU requirement 1610B in FIG. 19 is another suitable example of the CPU requirement 1610 shown in FIG. 16, in which two vCPUs 1920 and an SMT parameter 1930 having a value indicating that hardware multithreading is turned off. And Since hardware multithreading is off, for a potential host with a Power8 6-core CPU 1410 as shown in FIG. 14, the potential host uses one thread in each core as shown in FIG. As a result, 14 threads in the two cores will have two unused cores. The net result of the potential host for the CPU requirement 1610B of FIG. 19 with the SMT parameter turned off is the same as the prior art CPU requirement 1010 shown in FIG. 10 when hyperthreading is disabled; Note that prior art CPU requirements 1010 do not take into account any hyperthreading when host hyperthreading is disabled. In the prior art, when hyperthreading is enabled, it is not possible to predict which core hardware thread will service the vCPU. By specifying values for hardware multithreading parameters that take hardware multithreading into account, the number of unused hardware threads on potential hosts can be reduced, and which vCPUs are on the same core. Can be controlled by

  The examples of FIGS. 16-19 show how the hardware multithreading parameters give more control over how the vCPUs are deployed. For example, two threads running on the same core will have very high performance access to the cache memory available to that core, so a VM with two vCPUs will operate on the same data When executing two jobs, it may be desirable for the two vCPUs to be deployed on two different hardware threads within the same core, as shown in FIGS. When a VM with two vCPUs executes independent jobs, it may be desirable for the two vCPUs to be deployed on two different cores, as shown in FIGS.

  The third CPU requirement 1610C in FIG. 21 is another suitable example of the CPU requirement 1610 shown in FIG. 16, and includes eight vCPUs 2120 and an SMT parameter 2130 having a value of 8. In the case of a potential host having a Power8 6-core CPU 1410 as shown in FIG. 14, the potential host is used as shown in FIG. 22 where all eight threads are used and as a result there are no unused threads 1 Will have one core.

  The fourth CPU requirement 1610D shown in FIG. 23 is another suitable example of the CPU requirement 1610 shown in FIG. 16, and includes 12 vCPUs 2320 and an SMT parameter 2330 having a value of 4. In the case of a potential host with a Power8 6-core CPU 1410 as shown in FIG. 14, the potential host has four threads used in each core, as shown in FIG. Of the three cores. These simple examples illustrate how specifying hardware multi-threading parameters when selecting a host computer system can be seen in how the vCPU is deployed in the host computer system. Indicates whether to give control.

  Note that the examples shown in FIGS. 17-24 assume that a vCPU can be deployed on each available thread. The discussion above with respect to FIGS. 9-12 discusses an "overcommit ratio" that increases the number of CPUs by a certain amount. Similar overcommit ratios can be applied to selecting a host computer system according to the disclosure and claims herein.

  Referring to FIG. 25, the method 2500 selects a host when hardware multi-threading parameters are specified as shown in FIGS. 16, 17, 19, 21 and 23. The cloud VM request is read (step 2510). If the SMT parameter is OFF (step 2520 = YES), a host having the number of physical cores satisfying the number of vCPUs in the cloud VM request is selected (step 2530). Note that step 2530 is similar to step 920 in prior art method 900 of FIG. If the SMT parameter is ON (step 2520 = NO), the number of threads per core satisfying the number in the SMT parameter and the number obtained by dividing the number of vCPUs in the cloud VM request by the number of threads specified in the SMT parameter are satisfied A host having the number of cores is selected (step 2540). This is one specific method of selecting a host having the number of hardware threads that satisfies the number of vCPUs in the cloud VM request. Method 2500 then ends.

  Once the host computer system is selected, a vCPU for the VM can be placed on the selected host. Referring to FIG. 26, method 2600 begins when a vCPU is required to be located on a selected host (step 2610). If the SMT parameter is off (step 2620 = YES), each vCPU is placed on a different physical core (step 2630). If the SMT parameter is on (step 2620 = NO), the vCPU may be located on a different hardware thread on the same physical core (step 2640). Method 2600 then ends.

  When using hardware multi-threading parameters in the Cloud VM request, the cloud manager not only needs to know the number of physical cores in the CPU in the potential host, but also is supported by the CPU in the potential host You also need to know the number of threads. This is to ensure that a single core of the host can support the specified number of threads for Cloud VM requests. Referring again to FIG. 6, this means that determining available resources in step 610 not only includes determining available CPU cores, but also on which multiple threads are available on those CPU cores. It also includes determining whether or not there is. One way to achieve this is to collect, at step 610 in FIG. 6, the maximum SMT setting supported by the host computer system as part of the available resources. One example of this is shown in FIG. 27, where max_guest_smt indicates the value collected by the host monitor 440 of FIG. 4, indicating whether the potential host computer system supports hardware multi-threading. The possible values for max_guest_smt are zero, indicating that SMT is off on the host computer system, and a power of two number indicating the number of hardware threads available on each CPU. If all CPUs in the host computer system are of the same type, max_guest_smt will be a single value that applies to all of the CPUs in the host computer system. If the host computer system includes different types of CPUs that include different numbers of hardware threads, there may be a different max_guest_smt for each CPU in the host computer system.

  OpenStack does not currently have any existing support to assist guest CPUs in specifying the desired topology. One way to implement the addition of hardware multithreading parameters discussed herein is to add additional specifications to the OpenStack flavor, as shown in FIG. The parameter powerkvm: smt is a new parameter in the OpenStack flavor that specifies the desired SMT value for the guest VM. Note that this parameter can be -1 to indicate "don't care", zero to indicate that SMT is off, or some power of two. By including the ability to gather information about hardware multithreading on potential hosts in the max_guest_smt setting and the ability to specify the desired level of hardware multithreading in the OpenStack flavor, The disclosure and claims greatly improve the selection of potential host computer systems for deploying VMs, and deploying these VMs in a manner that makes better use of the hardware multi-threading capabilities of the host computer system. And provides improved utilization of CPU resources on the host computer system.

  The hardware multi-threading parameters discussed herein can also be used in VM resizing operations. Often, a VM needs to have more or less resources, so it can be resized to add or reduce the resources deployed to the VM. One suitable way to resize a VM is by specifying an OpenStack flavor that changes the resource allocation for the VM. When resizing a VM, the OpenStack flavor may have the powerkvm: smt parameter shown in FIG. 28 above. FIG. 29 illustrates a method 2900 for resizing a VM, which is preferably performed by the VM resizing mechanism shown in FIG. The flavor for the resizing operation of the existing VM is read (step 2910). The flavor referenced in step 2910 is the flavor with the new (ie, resized) allocation of resources for the VM. If the flavor does not include the SMT parameter (step 2920 = NO), the SMT parameter of the VM is set to OFF (step 2930). When the flavor includes the SMT parameter (step 2920 = YES), when the value of the SMT parameter is OFF or “don't care” (step 2940 = YES), the SMT parameter of the VM is set to OFF (step 2930). . If the SMT in the flavor has a power of two value (step 2940 = NO), the SMT parameter of the VM is set to the value of the SMT specified in the flavor (step 2950). The method then ends. Method 2900 enables a scheme that essentially “retrofits” existing VMs to use SMT parameters.

  The Power8 6-core CPU supports sub-cores, which means that when split cores are enabled, the eight threads in each core can be divided into sub-cores of two threads each. The Power86 CPU 3010 with the split core enabled includes a first core 3020 divided into four sub-cores 3022, 3024, 3026, and 3028, and four sub-cores 3052, 3054, 3056, and 3058 in FIG. And a second core 3050 divided into two. The other four cores are not shown in FIG. 30, but are similar to the two cores shown. Each subcore has two hardware threads as shown in FIG. By dividing each core into sub-cores, sub-cores can be assigned to virtual machines instead of cores, thereby saving a significant number of unused hardware threads.

  If a split core host is present, it may be advantageous for the cloud manager to be able to determine whether the host for the VM supports split core. Referring to FIG. 31, the CPU requirement 3110 is preferably a part of the cloud VM request 510 shown in FIG. The CPU requirement 3110 specifies the number of vCPUs 3120 and the hardware multithreading parameters 3130. The examples that follow illustrate how split cores affect the choice of host and the placement of vCPUs on that host.

  Referring to FIG. 32, CPU requirement 3110A is one suitable example of CPU requirement 3110 shown in FIG. 31 and includes two vCPUs 3220 and an SMT parameter 3230 having a value of 2. For a potential host with a Power8 6-core CPU 3010 with split core enabled as shown in FIG. 30, the potential host is, as shown in FIG. 33, one sub-core with two threads used and its The result is to have three subcores that can be used by other VMs.

  The second CPU requirement 3110B in FIG. 34 is another suitable example of the CPU requirement 3110 shown in FIG. 31, and includes two vCPUs 3420 and an SMT parameter 3430 whose value is set to OFF. With hardware multi-threading turned off, for a potential host with a Power86 CPU core 3010 with the split core enabled as shown in FIG. One thread is used per subcore, resulting in one thread in each subcore having two unused subcores and two subcores that can be used by other VMs.

  The third CPU requirement 3110C in FIG. 36 is another suitable example of the CPU requirement 3110 shown in FIG. 31, and includes eight vCPUs 3620 and an SMT parameter 3630 having a value of 2. Since the hardware multithreading parameter has the value 2, for a potential host with a Power86 CPU core 3010 with the split core enabled as shown in FIG. 30, the potential host is shown in FIG. As such, two threads are used for each subcore, resulting in four subcores with no unused threads. In one particular implementation, all eight vCPUs can be placed on eight threads (four sub-cores) of the same physical core. Of course, alternatively, the four sub-cores of FIG. 37 could be located on two or more physical cores.

  The fourth CPU requirement 3110D of FIG. 38 is another suitable example of the CPU requirement 3110 shown in FIG. 31, and includes 12 vCPUs 3820 and an SMT parameter 3830 having a value of 2. Since the hardware multithreading parameter has the value 2, for a potential host with a Power86 CPU core 3010 with the split core enabled as shown in FIG. 30, the potential host is shown in FIG. Thus, two threads were used for each subcore, resulting in six subcores, with no unused threads in any subcore. In one particular implementation, eight of the twelve vCPUs can be placed on all eight threads (four sub-cores) of the same physical core, and the remaining four vCPUs are placed on two different cores in different physical cores. It can be placed on four threads in one sub-core. Of course, alternatively, the six sub-cores of FIG. 39 could be located on three or more physical cores.

  All of the examples of CPU requirements in FIGS. 32, 34, 36, and 38 are for the case where the host has a split core enabled. If the host has a split core disabled, the result is similar to the example shown in FIGS. 17-24 detailed above, except that the host has a setting with the split core disabled. It is.

  The examples of FIGS. 32, 36, and 38 all have an SMT parameter with a value of 2. Since the Power8 sub-core has two threads, specifying two threads in the SMT parameters results in the most efficient placement of vCPUs on Power8 CPUs. Note, however, that the SMT parameter may exceed the number of threads on the sub-core. For example, if the SMT parameter 3630 in FIG. 36 is set to a value of 4, a host having a two-threaded subcore will not satisfy the request. Thus, a host without a split core is not a potential host when the SMT setting exceeds the number of threads for the sub-core.

  Referring to FIG. 40, a method 4000 illustrates a method for a host computer system using a cloud VM request that includes hardware multi-threading parameters that takes into account whether split core is enabled on the host computer system. Indicates a choice. The method 4000 is preferably performed by the host selection mechanism 450 shown in FIG. The cloud VM request is read (Step 4010). When SMT is OFF (step 4020 = YES) and the potential host has split cores enabled (step 4030 = YES), the potential host determines the number of sub-cores that satisfy the number of vCPUs in the cloud VM request. If so, this can be selected (step 4040). When the SMT is OFF (step 4020 = NO) and the potential host has a disabled split core (step 4030 = NO), the potential host is a physical core that satisfies the number of vCPUs in the cloud VM request. This can be selected if it has a number (step 4050). When SMT is ON (step 4020 = NO) and the potential host has split cores enabled (step 4060 = YES), the potential host determines if the number of hardware threads for the sub-core is in the SMT parameter. If the number of hardware threads specified can be satisfied and the number of sub-cores can satisfy the number of vCPUs in the cloud VM request divided by the number of hardware threads specified in the SMT parameters Can be selected (step 4070). When SMT is ON (step 4020 = NO) and the potential host has a disabled split core (step 4060 = NO), the potential host determines if the number of hardware threads for the core is in the SMT parameter. And the number of physical cores can be satisfied by dividing the number of vCPUs in the cloud VM request by the number of hardware threads specified in the SMT parameter. Case can be selected (step 4080). The method 4000 is preferably repeated for each potential host, resulting in a pool of potential hosts from which one can select one of the hosts using any suitable criteria or heuristics. Note that you can. For example, if a VM request would result in more efficient CPU core and thread utilization, select a host with an enabled split core prior to a host with a disabled split core. be able to. Method 4000 describes a method for a host computer system in which hardware multi-threading parameters and information from the host regarding split core settings and hardware threads per core will result in a more efficient placement of vCPUs. To give better control over the choice of.

  Referring to FIG. 41, when a VM with SMT = 4 or SMT = 8 is requested, using the filter PowerKVMMSFilter, the cloud manager filters out hosts with split-core mode enabled. be able to. This filter can assist the cloud manager to more quickly narrow down the number of potential hosts for a VM.

  Referring to FIG. 42, the method 4200 begins when a vCPU is required to be located on a selected host (step 4210). The method 4200 is preferably performed by the vCPU placement mechanism 460 shown in FIG. When SMT is OFF (step 4220 = YES) and the split core is enabled on the host (step 4230 = YES), the vCPU is located on a different sub-core (step 4240). When the SMT is OFF (step 4220 = YES) and the split core is disabled on the host (step 4230 = NO), the vCPU is placed on a different physical core (step 4250). When SMT is ON (step 4220 = NO) and the split core is enabled on the host (step 4260 = YES), the vCPU is placed on the sub-core thread (step 4270). When SMT is ON (step 4220 = NO) and the split core is disabled on the host (step 4260 = NO), the vCPU is placed on a thread of the same physical core (step 4280). . Note that if the number of vCPUs exceeds the number of threads in the physical core, the vCPUs will be placed on as many cores as will provide the required number of hardware threads for all vCPUs. . Method 4200 illustrates how specifying hardware multi-threading parameters and using information about split core settings provides better control over vCPU placement on a host computer system. .

  The cloud manager needs to know the number of physical cores in the CPU in the potential host to allow the VM to be deployed taking into account the split core and hardware multi-threading parameters in the cloud VM request Not only is there a need to know the number of threads supported by the CPU in the potential host, and whether split cores are enabled on the potential host. Referring again to FIG. 6, this means that determining available resources in step 610 not only includes determining available CPU cores, but also on which multiple threads are available on those CPU cores. It is also meant to include determining if there is, and whether split cores are enabled on these cores. One way to achieve this is to collect, in step 610 of FIG. 6, as part of the available resources, whether the split core is enabled on the potential host computer system.

  The cloud manager includes the number of hardware threads supported by the CPU on the host computer system, and in one embodiment, whether the CPU has a split core enabled or not. Monitor the above available resources. The cloud manager receives a request to provision a virtual machine (VM), the request indicating whether hardware multi-threading is allowed on the host computer system (or, in one embodiment, the host Hardware multithreading parameters that specify the amount of hardware multithreading required on the computer system. In one embodiment, the cloud manager then selects a host computer system for the VM, taking into account the hardware multi-threading parameters. In another embodiment, the cloud manager then selects a host computer system for the VM, taking into account hardware multithreading parameters, hardware threads supported by the CPU, and split core settings. I do. The VM is then deployed on the selected host computer system using the hardware multi-threading parameters. The result is more efficient utilization of CPU resources in the host for virtual machines.

  One skilled in the art will recognize that many variations are possible within the scope of the claims. Thus, while the disclosure has been particularly shown and described above, these and other changes in form and detail can be made without departing from the spirit and scope of the appended claims. It will be understood by those skilled in the art.

100: Cloud Computing Node 152: Program Module 200: Cloud Computing Environment

Claims (17)

At least one processor;
Memory coupled to the at least one processor;
A cloud manager resident in the memory and executed by the at least one processor;
An apparatus comprising: wherein the cloud manager comprises:
Determining the number of CPUs available on a plurality of host computer systems where virtual machines can be deployed and further determining the number of hardware threads supported by each CPU on the plurality of host computer systems A host monitoring mechanism,
A host selection mechanism for receiving a virtual machine (VM) request including a number of virtual CPUs and hardware multi-threading parameters, the plurality of hosts including a number of CPUs supporting a number of hardware threads satisfying the VM request. A host selection mechanism for selecting one of the computer systems;
An apparatus comprising:   The apparatus of claim 1, further comprising a virtual CPU (vCPU) placement mechanism that places a plurality of virtual CPUs (vCPUs) on the selected host computer system using the hardware multithreading parameters. The host monitoring mechanism further determines whether a split core is enabled for each CPU on the plurality of host computer systems, wherein the host selection mechanism determines whether a hardware core that satisfies the VM request. Selecting one of the plurality of host computer systems including a number of CPUs supporting the number of threads , as well as a split core setting that satisfies a number of virtual CPUs in the VM request and hardware multithreading parameters. Item 2. The apparatus according to Item 1.   A virtual CPU (vCPU) that places a plurality of virtual CPUs (vCPUs) on the selected host computer system using the hardware multithreading parameters and the split core settings on the selected host computer system The device of claim 3, further comprising a positioning mechanism. If the first value of the hardware multi-threading parameter indicates that hardware multi-threading is turned off, the vCPU placement mechanism may assign each vCPU in the VM to the selected host computer. · placing on a different physical cores in the system, the serial placement of the device in claim 2 or claim 3. If the second value of the hardware multi-threading parameter indicates a numerical value for the number of hardware threads, the vCPU placement mechanism assigns each vCPU in the VM to the selected host computer system. different placed on hardware threads, device mounting serial to claim 2 or claim 3 of. A third value of the hardware multi-threading parameter is determined by the selected host computer system whether hardware threading is on or off on the selected host computer system. indicating that it is selected, according to any one of claims 1 to 6. The VM request further comprises the memory requirements and disk requirements A device according to any one of claims 1 to 7. The host monitoring mechanism, the amount of memory on each of the plurality of host computer systems and further determines the amount of disk space, apparatus according to any one of claims 1 to 8.   If the number of virtual CPUs in the VM request is greater than the value of the hardware multi-threading parameter, the host selection mechanism may include a plurality of hosts, each including a plurality of CPUs having a plurality of hardware threads. The apparatus of claim 1, wherein one of the computer systems is selected. The cloud manager further comprises a VM resizing mechanism for resizing at least one VM using the hardware multithreading parameters, apparatus mounting serial to claim 2. A computer implemented method for selecting a host computer system for deploying a virtual machine, executed by at least one processor, comprising:
Determining the number of CPUs available on a plurality of host computer systems on which a virtual machine can be deployed;
Determining the number of hardware threads supported by each CPU on the plurality of host computer systems;
Receiving a virtual machine (VM) request including the number of virtual CPUs and hardware multithreading parameters;
Selecting one of the plurality of host computer systems including a number of CPUs supporting a number of hardware threads that satisfy the VM request;
Including, methods. Further comprising using the hardware multithreading parameter to place multiple virtual CPU (vCPUs) on the selected host computer system, the method according to claim 12. Determining whether each CPU on the plurality of host computer systems has an enabled split core, and if so, determining the number of sub-cores per core;
The step of selecting may include, in addition to one of the plurality of host computer systems including a number of CPUs supporting the number of hardware threads satisfying the VM request, the number of virtual CPUs in the VM request And selecting a split core setting that satisfies the hardware multithreading parameters;
14. The method according to claim 12 or claim 13 . Using the hardware multi-threading parameters and the split core settings on the selected host computer system to place the plurality of virtual CPUs (vCPUs) on the selected host computer system. 15. The method of claim 14 , further comprising: Determining, in addition to the number of CPUs, the amount of memory and disk space available on a plurality of host computer systems on which virtual machines can be deployed;
Here, the virtual machine (VM) request is:
A memory requirement specifying a minimum amount of memory for the VM;
Disk requirements specifying a minimum amount of disks for the VM;
Including
Here, a first value of the hardware multithreading parameter indicates that hardware multithreading is off, and a second value of the hardware multithreading parameter is a number of hardware threads. And the third value of the hardware multithreading parameter is whether the selected host computer system has hardware threading on or off on the selected host computer system. To indicate that it will be selected,
The method according to claim 12 . A computer program to perform the steps of performing a method according to any one of up to claims 12 claim 16 to the processor, the computer program.

Images