KR101884549B1 - Selecting a host for a virtual machine using a hardware multithreading parameter - Google Patents

Abstract

The cloud manager monitors the available resources on the host computer systems, and the host computer systems include a plurality of hardware threads supported by the CPUs on the host computer systems. The cloud manager receives a request to provide a virtual machine (VM) that includes hardware multithreading parameters specifying the amount of hardware multithreading required on the host computer system. The cloud manager then selects one host computer system for the VM in consideration of the hardware multithreading parameters.

Description

Selecting a host for a virtual machine using hardware multithreading parameters {SELECTING A HOST FOR A VIRTUAL MACHINE USING A HARDWARE MULTITHREADING PARAMETER}

[0001] The present application relates generally to the placement of virtual machines on host computer systems, and more particularly to selecting a host for a virtual machine using a hardware multithreading parameter ).

[0002] In a cloud environment, a cloud manager places virtual machines on host computer systems to create virtual servers. Typically, the cloud manager receives a request specifying that the virtual machine image requires for system resources such as memory, disk, and CPU. The cloud manager then determines the available host computer systems that have the requested system resources, selects one of the available host computer systems, and places the virtual machines on the selected host computer system.

[0003] OpenStack is open-source software for building private and public clouds. In the open stack, virtual hardware templates called "flavors" specify the system resources needed for virtual machines. For example, in an open stack, a flavor can specify the size of the memory, the root disk size, and the number of virtual CPUs for the virtual machine. When a virtual machine needs to be deployed, it makes a call to the cloud manager that has a flavor that specifies the resources needed for the virtual machine. The cloud manager then finds one or more host computer systems that have the resources specified in the flavor and places the virtual machine in one of the host computer systems that satisfy the flavor.

[0004] Hardware multithreading within a host can complicate the provisioning of virtual machines to a host computer system. In the prior art, if hyperthreading is enabled on the host computer system, the number of hardware threads is considered when selecting the host computer system for the virtual machine, and the virtual CPUs are correlated to the physical cores And are assigned to hardware threads without any hardware threads. 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 CPUs are only physically present when the VM is provided on the selected host computer system Processor cores. In current processor architectures such as POWER, which includes many hardware threads within each core, this results in very inefficient use of processing resources.

[0005] Providing virtual machines when processors have split cores can be more complicated. Split core processors are CPU cores that are divided into a plurality of subcores, each of which may include multiple hardware threads and function as a core for the guest operating system. For example, one core that may be a split core with eight hardware threads may be divided into four subcores, each of which may support two hardware threads. Enabling the split core is done dynamically, which means that splitting can be changed by the program on the host operating system. Known cloud managers do not treat split core processors quite differently than processors that do not have split cores. Thus, known cloud managers can not realize the benefits of using split core processors when providing virtual machines.

[0006] According to a first embodiment, an apparatus is provided, comprising: at least one processor; A memory coupled to the at least one processor; And a cloud manager residing in the memory and being executed by the at least one processor, the cloud manager comprising: means for determining the number of available CPUs on a plurality of host computer systems on which virtual machines may be located, A host monitor mechanism for determining a number of hardware threads supported by each CPU on the plurality of host computer systems; And a host selection mechanism for receiving a virtual machine (VM) request comprising a plurality of virtual CPUs and a hardware multithreading parameter, the host selection mechanism comprising a plurality of CPUs having a number of hardware threads satisfying the VM request And selecting one of the plurality of host computer systems including the plurality of host computer systems.

[0007] According to a second embodiment, there is provided a computer-implemented method executed by at least one processor for selecting a host computer system for deploying a virtual machine, the method comprising: Determining a number of available CPUs on the plurality of host computer systems; Determining a number of hardware threads supported by each CPU on the plurality of host computer systems; Receiving a virtual machine (VM) request comprising a plurality of virtual CPUs and a hardware multithreading parameter; And selecting one of the plurality of host computer systems comprising a plurality of CPUs having a number of hardware threads to satisfy the VM request.

[0008] The present invention can be implemented as a computer program.

[0009] According to a preferred embodiment, the cloud manager monitors the resources available on the host computer systems, including a plurality of hardware threads supported by the CPUs on the host computer systems. The cloud manager receives a request to provide a virtual machine (VM) that includes hardware multithreading parameters specifying the amount of hardware multithreading required on the host computer system. The cloud manager then selects a host computer system for the VM in consideration of the hardware multithreading parameters.

[00010] In accordance with one embodiment, a solution is provided that handles the deployment of virtual CPUs using hardware multithreading parameters.

[00011] The present application relates generally to the placement of virtual machines on host computer systems, and more particularly to arranging virtual CPUs on a host computer system using hardware multithreading parameters, in accordance with one embodiment Lt; / RTI >

[00012] According to one embodiment, a solution is provided for placing virtual CPUs using hardware multithreading parameters in hosts with split core processors.

[00013] The present application relates generally to the placement of virtual machines on host computer systems, and more particularly, to the use of hardware multi-threading parameters to include one or more split core processors Lt; RTI ID = 0.0 > virtual < / RTI > CPUs.

[00014] According to one embodiment, an apparatus is provided, comprising: at least one processor; A memory coupled to the at least one processor; And a cloud manager residing in the memory and being executed by the at least one processor, the cloud manager comprising: means for determining the number of available CPUs on a plurality of host computer systems on which virtual machines may be located, A host monitor mechanism for determining a number of hardware threads supported by each CPU on the plurality of host computer systems; A host selection mechanism for receiving a virtual machine (VM) request comprising a plurality of virtual CPUs and a hardware multithreading parameter, the host selection mechanism comprising a plurality of CPUs having a number of hardware threads that satisfy the VM request Selecting one of the plurality of host computer systems to perform; And a virtual CPU (vCPU) placement mechanism using the hardware multithreading parameters to place a plurality of virtual CPUs (vCPUs) on the selected host computer system.

[00015] According to one embodiment, a computer-implemented method is provided that is executed by at least one processor for placing a plurality of virtual CPUs (vCPUs) on a host computer system, the method comprising: Determining a number of available CPUs on a plurality of host computer systems that may be deployed; Determining a number of hardware threads supported by each CPU on the plurality of host computer systems; Receiving a virtual machine (VM) request comprising a plurality of virtual CPUs and a hardware multithreading parameter; Selecting one of the plurality of host computer systems including a plurality of CPUs having a number of hardware threads that satisfy the VM request; And using the hardware multithreading parameter to place the plurality of vCPUs on the selected host computer system.

According to one embodiment, a computer-implemented method is provided that is executed by at least one processor for placing a plurality of virtual CPUs (vCPUs) on a host computer system, the method comprising: Determining the amount of memory, the amount of memory, and the amount of disk space available on the plurality of host computer systems on which the virtual machines (VMs) may be located; Determining a number of hardware threads supported by each CPU on the plurality of host computer systems; A memory requirement that specifies a minimum amount of memory for the VM, a disk requirement that specifies a minimum amount of disk for the VM, and a CPU requirement that specifies a number of virtual CPUs and one hardware multi-threading parameter for the VM Wherein a first value of the hardware multithreading parameter indicates that the hardware multithreading is turn off and a second value of the hardware multithreading parameter indicates a number And a third value of the hardware multithreading parameter indicates that the selected host computer system is selected regardless of whether hardware threading is turned off or turned on on the selected host computer system -; Selecting one of the plurality of host computer systems including a plurality of CPUs having a number of hardware threads that satisfy the VM request; And using the hardware multithreading parameter to deploy the plurality of vCPUs on the selected host computer system, the deploying being characterized in that the hardware multithreading parameter indicates that hardware multithreading is turned off When placing the respective vCPUs in the VM on different physical cores in the selected host computer system and when the hardware multithreading parameter indicates the number of hardware threads, on the other hardware threads in the selected host computer system, By placing each vCPU in the VM.

[00017] In accordance with one embodiment, a method is provided that further includes resizing the VM using hardware multithreading parameters in the method described in the paragraph above.

[00018] According to one embodiment, an apparatus is provided, comprising: at least one processor; A memory coupled to the at least one processor; And a cloud manager residing in the memory and being executed by the at least one processor, the cloud manager comprising: a number of CPUs available on a plurality of host computer systems in which virtual machines may be located; A host monitor mechanism to determine the number of hardware threads supported by each CPU on the systems and whether split core is enabled for each CPU on the plurality of host computer systems; And a host selection mechanism for receiving a virtual machine (VM) request comprising a plurality of virtual CPUs and a hardware multithreading parameter, the host selection mechanism comprising a plurality of CPUs having a plurality of hardware threads, And selecting one of the plurality of host computer systems including split core settings to satisfy a hardware multithreading parameter in the VM.

[00019] According to one embodiment, a computer-implemented method is provided for executing by at least one processor to place a plurality of virtual CPUs (vCPUs) on a host computer system, the method comprising: Determining a number of available CPUs on a plurality of host computer systems on which a virtual machine (VM) may be located; Determining a number of hardware threads supported by each CPU on the plurality of host computer systems; Determining if each CPU on the plurality of host computer systems has an enabled split core, if so, determining the number of subcores per core; Receiving a virtual machine (VM) request comprising a plurality of virtual CPUs and a hardware multithreading parameter; And selecting one of the plurality of host computers systems including the plurality of virtual CPUs and the split core settings to satisfy the hardware multi-threading parameters in the VM request .

[00020] According to one embodiment, a computer-implemented method is provided that is executed by at least one processor for placing a plurality of virtual CPUs (vCPUs) on a host computer system, the method comprising: Determining an amount of memory, an amount of memory, and an amount of disk space available on a plurality of host computer systems on which a virtual machine (VM) may be located; Determining a number of hardware threads supported by each CPU on the plurality of host computer systems; Determining if each CPU on the plurality of host computer systems has an enabled split core; A memory requirement that specifies a minimum amount of memory for the VM, a disk requirement that specifies a minimum amount of disk for the VM, and a CPU requirement that specifies a number of virtual CPUs and one hardware multi-threading parameter for the VM Wherein a first value of the hardware multithreading parameter indicates that the hardware multithreading is turn off and a second value of the hardware multithreading parameter indicates a number And a third value of the hardware multithreading parameter indicates that the selected host computer system is selected regardless of whether hardware threading is turned off or turned on on the selected host computer system -; Selecting one of the plurality of CPUs having a plurality of hardware threads and the plurality of host computers systems including split core settings to satisfy the hardware multithreading parameters in the VM request; And using split multi-threading parameters and split core settings of the selected host computer system to place the plurality of vCPUs on the selected host computer system, wherein the deploying comprises placing the hardware multi- Threading is turned off by placing each vCPU in the VM on a different physical core in the selected host computer system and if the hardware multithreading parameter indicates the number of hardware threads and the selection And placing each vCPU in the VM on a different hardware thread in a sub-core of a CPU in the selected host computer system when split core settings of the selected computer system are enabled.

[00021] According to one embodiment, the cloud manager monitors resources available on host computer systems, including multiple hardware threads supported by CPUs on host computer systems. The cloud manager receives a request to provide 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 in consideration of the hardware multithreading parameters. The VM is then placed on the selected host computer system using hardware multithreading parameters.

[00022] According to one embodiment, the cloud manager includes resources available on host computer systems, including a number of hardware threads supported by CPUs on host computer systems, Or not. The cloud manager receives a request to provide 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 multithreading parameters, hardware threads supported by the CPU, and split core settings. The VM is then placed on a selected host computer system using hardware multithreading parameters. The result is more efficient utilization of CPU resources within the host for the virtual machine.

[00023] The foregoing and other features and advantages are apparent from the following detailed description, as illustrated in the accompanying drawings.

[00024] Embodiments of the present invention will be described by way of example and with reference to the accompanying drawings. The same drawing numbers denote the same elements:
[00025] Figure 1 is a block diagram of a cloud computing node in accordance with a preferred embodiment of the present invention;
[00026] Figure 2 is a block diagram of a cloud computing environment in accordance with a preferred embodiment of the present invention;
[00027] Figure 3 is a block diagram of an abstract model layer according to a preferred embodiment of the present invention;
[00028] FIG. 4 is a block diagram illustrating some features of a cloud manager according to a preferred embodiment of the present invention;
[00029] Figure 5 is a block diagram illustrating some aspects of a cloud VM request in accordance with a preferred embodiment of the present invention;
[00030] Figure 6 is a flow chart illustrating a method in accordance with a preferred embodiment of the present invention in which a cloud manager logs available resources on potential host computer systems;
[00031] Figure 7 is a flow chart illustrating a method according to a preferred embodiment of the present invention in which a cloud manager provides VMs on host computer systems;
[00032] Figure 8 is a block diagram of a prior art x86 dual core CPU;
[00033] Figure 9 is a flow diagram of a prior art method by which a cloud manager selects a host for a VM request;
[00034] Figure 10 is a block diagram illustrating how CPU requirements are specified in a prior art Cloud VM request;
[00035] Figure 11 is a block diagram of a potential host computer system showing three x86 dual core processors in accordance with a preferred embodiment of the present invention;
[00036] Figure 12 is a block diagram illustrating virtual machines including vCPUs that may be assigned to the potential host of Figure 11 in accordance with a preferred embodiment of the present invention;
[00037] Figure 13 is a flow diagram of a prior art method of placing vCPUs on physical cores in a host computer system;
[00038] Figure 14 is a block diagram illustrating the architecture of a Power8 6 core CPU, showing two of the six cores, in accordance with a preferred embodiment of the present invention;
[00039] Figure 15 is a flow diagram of a method for selecting a host and using hardware multithreading parameters to control placement for vCPUs on a host in accordance with a preferred embodiment of the present invention;
[00040] Figure 16 is a sample CPU requirement that includes the number of vCPUs and hardware multithreading parameters in accordance with a preferred embodiment of the present invention;
[00041] Figure 17 is a first sample CPU requirement comprising hardware multithreading parameters in accordance with a preferred embodiment of the present invention;
[00042] FIG. 18 illustrates a potential Power 8 host meeting the CPU requirements of FIG. 17 in accordance with a preferred embodiment of the present invention;
[00043] Figure 19 illustrates a second sample CPU requirement comprising hardware multithreading parameters in accordance with a preferred embodiment of the present invention;
[00044] Figure 20 illustrates a potential Power 8 host that meets the CPU requirements of Figure 19 in accordance with a preferred embodiment of the present invention;
[00045] Figure 21 illustrates a third sample CPU requirement comprising hardware multithreading parameters in accordance with a preferred embodiment of the present invention;
[00046] Figure 22 illustrates a potential Power 8 host that meets the CPU requirements in Figure 21 in accordance with a preferred embodiment of the present invention;
[00047] Figure 23 illustrates a fourth sample CPU requirement comprising hardware multithreading parameters in accordance with a preferred embodiment of the present invention;
[00048] FIG. 24 illustrates a potential Power 8 host that meets the CPU requirements of FIG. 23 in accordance with a preferred embodiment of the present invention;
[00049] Figure 25 is a flow diagram of a method for selecting a host that satisfies a CPU requirement that includes a hardware multithreading parameter to select a host in accordance with a preferred embodiment of the present invention;
[00050] Figure 26 is a flow diagram of a method for placing vCPUs on a predetermined host computer system using hardware multithreading parameters;
[00051] Figure 27 is a block diagram illustrating host-level statistics collected for each potential host in accordance with a preferred embodiment of the present invention;
[00052] Figure 28 is a block diagram illustrating an extra specification that may be implemented within an open stack flavor to specify hardware multithreading parameters in accordance with a preferred embodiment of the present invention;
[00053] Figure 29 is a flow diagram of a method for performing a re-verification operation on an existing VM that may include hardware multithreading parameters;
[00054] FIG. 30 is a block diagram illustrating the architecture of a Power8 6-core CPU with an enabled split core showing two of the six cores;
[00055] Figure 31 is a sample CPU requirement that includes the number of vCPUs and hardware multithreading parameters;
[00056] Figure 32 is a first sample CPU requirement that includes a hardware multithreading parameter;
[00057] Figure 33 illustrates a potential Power 8 host that meets the CPU requirements in Figure 32;
[00058] Figure 34 is a second sample CPU requirement that includes hardware multithreading parameters;
[00059] Figure 35 illustrates a potential Power 8 host that meets the CPU requirements in Figure 34;
[00060] Figure 36 is a third sample CPU requirement that includes hardware multithreading parameters;
[00061] Figure 37 illustrates a potential Power 8 host that meets the CPU requirements in Figure 36;
[00062] Figure 38 illustrates a fourth sample CPU requirement that includes a hardware multithreading parameter;
[00063] Figure 39 illustrates a potential Power 8 host that meets the CPU requirements in Figure 38;
[00064] FIG. 40 is a flow diagram of a method of selecting a host when the host has split cores and meets the CPU requirements including hardware multithreading parameters;
[00065] FIG. 41 is a block diagram illustrating a filter that may be used to filter hosts with a split core mode enabled when the hardware multithreading parameter is set to 4 or 8;
[00066] Figure 42 is a flow diagram of a method for placing vCPUs on a predetermined host computer system using hardware multithreading parameters and for when a host has split cores.

The cloud manager monitors the available resources on the host computer systems, including whether the number of hardware threads supported by the CPUs on the host computer systems and whether the CPUs have enabled scrolling (monitor). The cloud manager includes a virtual machine (VM) that includes hardware multithreading parameters that 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) And receives a request to provide the service. The cloud manager then selects the host computer system in consideration of the hardware multithreading parameters, hardware threads supported by the CPU, and split core settings. The VM is then placed on the selected host computer system using the hardware multithreading parameters. As a result, the utilization of CPU resources in the host for the virtual machine becomes more efficient.

[00068] Although the present application may include a detailed description of cloud computing, it should be understood that the implementation described herein is not limited to a cloud computing environment. In fact, embodiments of the present invention may be implemented in any type of computing environment now known or later developed.

[00069] Cloud computing can be deployed with configurable computing resources (eg, networks, network bandwidths, servers, processing, memory, storage, etc.) that can be quickly provisioned or released with minimal management effort or interactivity with a service provider A model of service delivery to enable convenient, on-demand network access to a shared pool of applications, media, applications, virtual machines and services . Such a cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[00070] The characteristics are as follows:

On-demand self-service: A cloud consumer can unilaterally provision computing capabilities, such as server time and network storage media, automatically as needed, without having to talk to a service provider .

Broad network access: A standard mechanism that encourages the use of heterogeneous thin or thick client platforms (eg, mobile phones, portable computers, and PDAs) across networks. Lt; / RTI >

Resource pooling: The provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, and different physical and virtual Resources are dynamically allocated and reallocated. Consumers typically have positional independence in that they do not have control or knowledge of the exact location of the provided resources, but may specify their location at a higher level of abstraction (e.g., country, state, or data center).

Rapid elasticity: Ability to quickly scale out, to rapidly and competently, in some cases automatically provisioned, to rapidly scale, in can be released quickly. The possibilities that can be offered to consumers are often unlimited and seem to be able to buy at any time.

Measured service: The cloud system automatically controls and optimizes resource usage. It is used at some level of service (eg, storage, processing, bandwidth, and active user accounts) abstraction measurement function. Resource usage can be monitored, controlled, and reported, thereby providing transparency to both the provider and the user of the service being used.

[00071] Service Models are as follows:

Software as a Service (SaaS): The services that are provided to consumers are those that enable the provider's applications to run on the cloud infrastructure. Applications are accessible from multiple client devices through a thin client interface, such as a web browser (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including network, server, operating system, storage, or individual application performance. However, limited user-specific application configuration settings are possible as an exception.

Platform as a Service (PaaS): The service provided to the consumer is to deploy consumer-generated or acquired applications created using programming languages and tools supported by the provider to the cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage media. However, you can control for deployed applications and, where possible, for application hosting environment configurations.

Infrastructure as a Service (IaaS): Services provided to consumers provide processing, storage media, networks, and other basic computing resources, where consumers can deploy and run arbitrary software, The software may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but can control for limited control of the operating system, storage media, deployed applications, and possibly selected networking components (e.g., host firewalls).

[00072] Deployment Models are as follows:

Private cloud: A cloud infrastructure operates for an organization, can be managed by the organization or a third party, and can be located on-premises or on-premises. can do.

Community cloud: A cloud infrastructure supports a specific community that is shared by many organizations and shares interests (for example, mission, security requirements, policies, and compliance audits) It can be managed by three parties and can be located on-premises or on-premises.

Public cloud: The cloud infrastructure is available to the general public or large industrial groups and is owned by organizations that sell cloud services.

Hybrid cloud: A cloud infrastructure is a blended configuration of two or more clouds (private, community, or public), which are unique entities, but that enable data and application portability. (For example, cloud bursting for load balancing among the clouds) that allows the user to access the network.

[00073] A cloud computing environment is oriented toward services that focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[00074] Referring now to FIG. 1, an example of a cloud computing node is illustrated. The cloud computing node 100 is only one example of a suitable cloud computing node and is not intended to suggest any limitation as to the scope of use or functionality of the embodiments of the invention described herein. In any event, the cloud computing node 100 is capable of implementing and / or performing all of the functions described above.

[00075] In a cloud computing node 100, a computer system / server 110 is located, which is operable with many 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 computer system / server 110 include, but are not limited to, personal computer systems, server computer systems, tablet computer systems, thin clients, thick clients, handheld or laptop devices, multiprocessor systems, microprocessor-based systems, set-top boxes, Including, but not limited to, set top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments ≪ / RTI > and the like.

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

[00077] As shown in FIG. 1, a computer system / server 110 within a cloud computing node 100 is shown in the form of a general purpose computing device. The components of computer system / server 110 may include one or more processors or processing units 120, system memory 130, and system memory 130, But is not limited to, a bus 122 that couples the components.

[00078] Bus 122 may be implemented in one or more various types of memory devices, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using one of various bus architectures Lt; / RTI > bus structures. By way of example, and not limitation, such architectures include an Industry Standard Architecture (ISA) bus, a Micro Channel Architecture (MCA) bus, an Extended ISA (EISA) bus, a Video Electronics Standards Association (VESA) local bus, and a Peripheral Component Interconnect Bus.

[00079] Computer system / server 110 typically includes a variety of computer system readable media. Such a medium can be any available medium that can be accessed by the computer system / server 110 and includes both volatile and nonvolatile media, both desorption and non-desorption media. An example of a removable medium is shown in FIG. 1 to include a digital video disk (DVD) 192.

The system memory 130 may include computer system readable media in the form of volatile or non-volatile memory, such as firmware 132. The firmware 132 provides an interface to the hardware of the computer system / server 110. The 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. The computer system / server 110 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 140 can read from and write to non-removable, nonvolatile magnetic media (not shown, and typically referred to as a "hard drive "). Although not shown, a magnetic disk drive for reading from and writing to a removable, nonvolatile magnetic disk (e.g., a "floppy disk") and a removable nonvolatile optical disk such as a CD-ROM, DVD-ROM, An optical disk drive for reading and writing to it may be provided. In this case, each may be coupled to bus 122 by one or more data media interfaces. As depicted and described below, the memory 130 may include at least one program product having one set (at least one) of program modules configured to perform the functions described in more detail below.

The program / utility 150, having a set (at least one) of program modules 152 as well as an operating system, one or more application programs, other program modules, and program data, May be stored in memory 130, but is not limited thereto. 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 modules 152 generally implement the functions and / or methods of the embodiments of the present invention as described herein.

The computer system / server 110 may also include one or more external devices 190, such as a keyboard, a pointing device, a display 180, a disk drive, and the like; One or more devices that allow a user to interact with the computer system / server 110; And / or other devices (e.g., network cards, modems, etc.) that allow the computer system / server 110 to communicate with one or more other computing devices. Such communication may occur via input / output (I / O) interfaces 170. The computer system / server 110 also includes a network adapter 160 and one or more networks, such as a local area network (LAN), a general wide area network (WAN), and / or a public network Lt; / RTI > As shown, the network adapter 160 communicates with other components of the computer system / server 110 via the bus 122. Although not shown, it should be understood that other hardware and / or software components may be used with the computer system / server 110. Examples include, but are not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data archive storage systems, etc. .

[00083] Referring now to FIG. 2, an exemplary cloud computing environment 200 is shown. As shown, the cloud computing environment 200 includes one or more cloud computing nodes 100, which may be, for example, a personal digital assistant (PDA) or mobile phone 210A, a desktop computer 210B, A portable computer 210C, and / or an automotive computer system 210N. The nodes 100 may communicate with each other. Which may be physically or virtually grouped (not shown) in one or more networks, such as private, community, public, or hybrid clouds, or combinations thereof, as described herein. This allows the cloud computing environment 200 to provide infrastructure, platforms and / or software as a service so that the cloud consumer does not need to maintain resources on the local computing device. The types of computing devices 210A-N shown in FIG. 2 are for illustrative purposes only and the computing nodes 100 and the cloud computing environment 200 may be any type of network and / or network addressable connection (E.g., using a web browser) to communicate with any type of computerized device.

[00084] 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 illustrated in FIG. 3 are for purposes of illustration only and that the present application and claims are not so limited. As shown, the following layers and corresponding functions are provided.

[00085] The hardware and software layer 310 includes hardware and software components. Examples of hardware components include mainframes, such as IBM ^® System z ^® systems; Reduced Instruction Set Computer (RISC) architecture-based servers, such as IBM System p ^® systems; IBM System x ^® systems; IBM BladeCenter ^® systems; Storage devices; Network and networking components. Examples of software components include network application server software, such as IBM WebSphere ^® application server software; And database software, for example IBM DB2 ^® database software. (IBM, System z, System p, WebSphere, and DB2 are trademarks of International Business Machines Corporation, registered in many countries worldwide.)

[00086] The virtualization layer 320 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers; Virtual storage medium; Virtual networks, including virtual private networks; Virtual applications and operating systems; And virtual clients.

[00087] In one example, the management layer 330 provides the functions described below. Resource provisioning provides dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and Pricing provides cost tracking and billing for the consumption of these resources when resources are used within the cloud computing environment. In one example, these resources may include application software licenses. Security provides identification of cloud consumers and tasks as well as data and other resources. The user portal provides consumers and system administrators with access to the cloud computing environment. Service level management provides cloud computing resource allocation and management to meet required service levels. Service Level Agreement (SLA) planning and fulfillment provides pre-arrangement and procurement of cloud computing resources that meet the anticipated future requirements in line with SLAs. The cloud manager 350 represents the cloud manager described in the following description. Although the cloud manager 350 is shown resident in the management layer 330 in FIG. 3, the cloud manager 350 may span all of the levels shown in FIG.

[00088] The workload layer 340 provides examples of functions for which a cloud computing environment may be utilized. Examples of workloads and functions that can be provided in this layer are: mapping and navigation; Software Development and Lifecycle Management; Delivery of virtual classroom education; Data analysis processing; And transaction processing; And mobile desktop.

[00089] The present invention may be a system, method, and / or computer program product. The computer program product may include a computer readable storage medium having computer readable program instructions for causing a processor to perform the features of the present invention.

[00090] The computer-readable storage medium can be a tangible device that can hold and store instructions for use by the instruction executing device. The computer readable storage medium may be, for example, but is not limited to, 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 foregoing . A non-exhaustive list of more specific examples of computer readable storage media may include: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable and programmable read- (ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, perforation-cards, or instructions may be written to a memory such as a memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read- Mechanically encoded devices, such as elevated structures in the grooves, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium refers to a computer-readable medium having stored thereon an electromagnetic wave that propagates through radio waves or other freely propagating electromagnetic waves, a waveguide or other transmission medium (e.g., optical pulses transmitted through a fiber optic cable) it is not interpreted as transitory signals per se, such as electrical signals transmitted through a wire.

[00091] The computer-readable instructions described herein may be downloaded from a computer-readable storage medium to respective computing / processing devices or may be downloaded to a computer-readable storage medium, such as, for example, a network, such as the Internet, a local area network, a wide area network, and / ) Or to an external computer or external storage device. The network (network) may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and / or edge servers. A network adapter card or network interface in each computing / processing device receives computer-readable program instructions from the network (network) and stores the computer-readable program instructions in a computer-readable storage medium in a respective computing / send.

[00092] Computer-readable program instructions for carrying out the operations of the present invention may be stored in a conventional procedural programming language, such as an object-oriented programming language such as Smalltalk, C ++, or the like, and a "C" (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-of-the-art instructions, Setting data, or source code or object code. 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, partially on the user's computer and partly on the remote computer or entirely on the remote computer or server . In the last case above, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN) (Via the Internet). In some embodiments, electronic circuits including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) Readable program instructions to condition the computer readable program instructions to customize the computer readable program instructions.

BRIEF DESCRIPTION OF THE DRAWINGS [00093] The features of the present invention will now be described with reference to flowchart illustrations and / or block diagrams of methods, devices (systems), and computer program products in accordance with embodiments of the invention. It will be appreciated that each block and sequence of flowchart illustrations and / or block diagrams and / or combinations of blocks within the block diagrams may be implemented by computer readable program instructions.

[00094] These computer-readable program instructions may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to create a machine so that those instructions may be processed by the computer or other programmable data processing May be implemented through a processor of the apparatus to generate means for implementing the functions / operations specified in the blocks or blocks of the flowchart and / or block diagrams. These computer-readable program instructions may also be stored on a computer-readable storage medium, and the computer-readable storage medium, having instructions stored thereon, may direct the computer, the programmable data processing apparatus, and / Blocks may be made to function in a particular manner to include an article of manufacture including instructions that implement the features / acts specified in the blocks or blocks of the block diagrams.

[00095] The computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause a series of computation steps to be performed on the computer, other programmable apparatus, And thus the instructions that execute on the computer, other programmable apparatus, or other apparatus may implement the functions / acts specified in the flowchart and / or block or blocks of the block diagrams.

[00096] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products in accordance with various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a portion of a module, segment, or instruction that includes one or more executable instructions for implementing the specified logical function (s). In some other implementations, the functions referred to in the block may occur differently from the order noted in the figures. For example, two blocks shown in succession may actually be executed substantially concurrently, or the two blocks may sometimes be executed in reverse order, depending on the associated function. Each block of block diagrams and / or example illustrations, and combinations of blocks within the block diagrams and / or the example illustrations, are intended to include specific features or operations that perform the specified functions or operations of the special purpose hardware and computer instructions, It should also be noted that it may be implemented by any applicable hardware-based systems.

[00097] FIG. 4 illustrates one suitable example of the cloud manager 350 shown in FIG. The 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 virtual machines 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 all appropriate functions, such as provisioning of VMs, destruction of VMs, Allows you to interact. The difference between the resource request interface 420 and the user interface 430 is that the user must manually use the user interface 430 to perform the functions specified by the user in the user interface 430, The resource request interface 420 may be used by the software entity to request the provision of cloud resources by the cloud mechanism 350 without input from a human user.

The cloud manager 350 also includes a host monitor mechanism 440 that monitors the resources available on the potential host computer systems so that the cloud manager 350 can determine the resources Lt; RTI ID = 0.0 > available < / RTI > on potential host computer systems. A host selection mechanism 450 allows a potential host computer system to be selected based on comparing the specified resources with the resources available on the potential host computer systems for the requested VM. The vCPU placement mechanism 460 places the vCPUs on a selected host computer system using hardware multithreading parameters. The VM resize mechanism 470 allows the VMs to reschedule existing VMs using hardware multithreading parameters, even though the original VM did not use hardware multithreading parameters.

5 illustrates one suitable example of a cloud VM request 510 that may be used by the cloud providing mechanism 410 of FIGURE 4 to request a VM to be served by the cloud manager 350. [ Via the resource request interface 420 or on the user interface 430. The cloud VM request 510 may include any specification of requirements for the resources required on the VM. Examples of suitable requirements include memory requirements 520, disk requirements 530, and CPU requirements 540. Memory requirement 520 specifies the amount of memory needed for the VM. Disk requirement 530 specifies the amount of disk needed for the VM. CPU requirements 540 specify the number of virtual CPUs needed for the VM, and may also specify a hardware multithreading parameter, discussed in detail below. Of course, other requirements not shown in FIG. 5 may also be specified for the VM, which may include network requirements and other appropriate requirements. 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.

[0002] Referring to FIG. 6, the method 600 is preferably performed by the host monitor mechanism 440 of FIG. 4 to monitor available resources on potential host computer systems. The resources available on the potential host computer systems are determined (step 610) and logged (step 620). One known way of implementing method 600 is to use a driver, which sends a query to the host to determine its available resources.

[000101] Referring to FIG. 7, method 700 begins by receiving a Cloud VM request (step 710). The resource requirements in the cloud VM request are then compared with the resources available on the potential host computer systems (step 720). It is noted that the resources available at step 720 may be read from the log generated at step 620 of FIG. A host with resources that satisfy the resource requirements in the cloud VM request is then selected (step 730). The VM is then placed on the selected host computer system (740).

[0002] 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 pose challenges in providing the VM to the host computer system. In the prior art, the number of hardware threads in a multi-core CPU is typically ignored and only physical cores are considered. For example, the prior art method 900 of FIG. 9 reads (step 910) a cloud VM request and then selects a host having a number of physical cores that satisfy a number of vCPUs in a cloud VM request (step 920 ). The prior art CPU requirement 1010 shown in FIG. 10 specifies the number of virtual CPUs (vCPUs) in the VM and is one suitable example for the CPU requirement 540 shown in FIG. Because the method 900 only uses physical cores when selecting a host for a VM, multiple hardware threads on the cores will be used and thus will not utilize available CPU resources. In another prior art, when hyperthreading of a host is enabled, the number of hardware threads is considered and the placement of vCPUs for hardware threads is performed regardless of the physical cores. This approach makes VMs inefficient because some workloads benefit from using threads on other cores, while other workloads are better served by threads for the same core.

[000103] Step 920 of FIG. 9 may include any suitable criteria or heuristic for selecting a host computer system that satisfies the VM request. For example, the number of physical cores may be increased to an overcommit ratio, such as 2.0. Thus, if the host has three available cores, multiplying the three physical cores by an unreasonable rate of 2.0 results in six available processors, which require that the VMs requiring six vCPUs are deployed on the host , But a VM that requires seven vCPUs can not be deployed. A simple example will be illustrated.

[000104] Figure 11 shows the same host computer system including three dual core x86 CPUs. This host already has VM1 shown in FIG. 12, VM1 is running on this host, and as shown in the shaded areas in the cores of FIG. 12, two physical cores of CPU1 and two physical cores of CPU2 It is assumed that it is disposed in the first core. It is also assumed that the VM2 shown in Fig. 12 needs to be arranged. The number of cores available in the example of FIG. 11 is determined to be 9, i.e., multiplied by an unreasonable rate of two for six cores and minus the three cores used by VM1 in potential host 1 shown in FIG. 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.

[000105] It should be noted that the actual placement of vCPUs on a potential host is a separate step from selecting a potential host for the VM. Referring to FIG. 13, method 1300 begins by reading the Cloud VM request (step 1310). The vCPUs in the cloud VM request are then placed on the physical cores (step 1320). 11, the first and second cores of CPU 1 and the thread T1 of the first core of CPU 2 are shaded, indicating that three vCPUs in VM1 shown in FIG. 12 are located on these three corresponding cores . However, it should be noted that this arrangement is not static. At other times, the vCPU may be running on all hardware threads on all active cores. In hyperthreading, a total of twelve hardware threads are allocated in three dual-cores. VM1 takes 3 of these threads and 9 leaves them for other VMs. However, vCPUs can be allocated to all threads, which means that jobs running on operating system threads that share memory can best run on hardware threads of the same vCPU, but run on independent operating system threads May mean that the work being done must be performed better in the hardware threads of the other cores. Therefore, the prior art incurs inefficiencies in the way in which potential hosts are identified for the VM and in the way in which the VMs are run on the selected host, because the allocation of the VMs to the potential hosts is done by hardware threads And the differences between the cores can not currently be grasped.

[0002] The prior art can recognize either a physical processor core or a hardware thread, but not all of them as an entity to which a virtual CPU can be placed. The single dual core CPU shown in FIG. 8 without hyperthreading has two available CPUs, in the form of two physical cores 820 and 840, where the vCPUs can be deployed. A single dual core CPU with hyperthreading can support more vCPUs; However, it is not determined whether the vCPUs are executed by hardware threads on the same physical core or by hardware threads on other cores. The present application and claims acknowledge and acknowledge that vCPUs need to be assigned to multiple hardware threads, rather than being assigned only to a single physical core or a single hardware thread.

[000107] The problem of assigning vCPUs to a single hardware thread or core is exacerbated when the number of hardware threads is increased. In the x86 dual-core CPUs shown in Figs. 8 and 11, hyperthreading enables two scads per core. On processors with many hardware threads, the problem becomes clearer. For example, a Power8 6 core CPU 1410 is shown in FIG. 14, which includes a first core 1420 that includes eight hardware threads 1432, 1434, 1436, 1438, 1442, 1444, 1446, And a second core 1450 that also includes eight hardware threads 1462, 1464, 1466, 1468, 1472, 1474, 1476, and 1478. Four other cores are not shown in FIG. 14, but are similar to the two cores shown. When the host is selected based on the number of physical cores as shown in the prior art method 900 of FIG. 9, many hardware threads will not be used. Thus, if two vCPUs are placed for the two cores 1420 and 1450 shown in FIG. 14, seven out of eight hardware threads on each core will be wasted. In other words, only 2 of the 16 threads for the two cores are used at a given point in time, resulting in a net result that 14 of the 16 hardware threads are wasted. This means that only two of the 16 available processing resources (12.5%) on the two Power8 cores can be utilized using the prior art method 900 shown in FIG. On the other hand, if vCPUs are allocated to a single hardware thread when there are many hardware threads per core, then VMs with workloads that require high levels of parallelism and shared memory are not distributed across multiple physical cores, The better processing results will be obtained by being located on the same physical core as the other vCPUs.

[000108] In order to avoid the problems of many unused threads or vCPUs distributed over the physical cores as described above with reference to FIG. 14, a new method for identifying potential hosts and deploying VMs is described in the Cloud VM Request Consider hardware threads using hardware multithreading parameters, which are considered based on the principle that a vCPU can be allocated for multiple hardware threads in a single physical core or in a single physical core instead of a single hardware thread. This is done using new parameters in the cloud VM request associated with hardware multithreading. In the specific examples described herein, this hardware multithreading parameter is referred to as the "SMT" parameter, which refers to Symmetric Multithreading, a term also known in the art to describe hardware multithreading on CPUs. Referring to FIG. 15, method 1500, in one embodiment, determines the number of hardware threads per core and the number of SMT parameters in a cloud VM request, along with information on hosts on split core settings, (Step 1510). Once the host computer system is selected, the same SMT parameters in the cloud VM request can be used to make deployment decisions for the vCPUs when placing the VM on the selected host (step 1520). In one embodiment, the number of hardware threads per core and information on the host regarding split core settings may also be used 1520 to make placement decisions for vCPUs when placing VMs on a predetermined host.

[000109] FIG. 10 shows that prior art CPU requirements 1010 for a cloud VM request include specifying the number of vCPUs 1020 required on the VM. The cloud VM request 1610 shown in FIG. 16 in accordance with the present application and claims includes the number of vCPUs 1620, but additionally includes a hardware multithreading (SMT) parameter 1630. The value of the SMT parameter may be zero, indicating that hardware multithreading is a turn off, or it may be a power of 2 number indicating the number of hardware threads. Some examples of this will be illustrated. 17, CPU requirement 1610A is one suitable example for CPU requirement 1610 shown in FIG. 16 and includes 2 vCPUs 1720 and an SMT parameter 1730 with a value of 2 . For a potential host with a Power8 6 core CPU 1410 as shown in FIG. 14, the potential host has one core in which two threads are used, as shown in FIG. 18, Resulting in unused results.

The second CPU requirement 1610B of FIG. 19 is another suitable example for the CPU requirement 1610 shown in FIG. 16, with two vCPUs 1920 and a value indicating that hardware multithreading is turned off SMT < / RTI > For a potential host with a Power8 6-core CPU 1410 shown in FIG. 14, if hardware multi-threading is turned off, the potential host will have two cores in each core where one thread is used, As shown at 20, 14 threads in the two cores result in no use. It should be noted that the net result of the potential host for CPU requirement 1610B in FIG. 19 where the SMT parameter is turned off is the same as CPU requirement 1010 of the prior art shown at 10 when hyperthreading is disabled , Since the prior art CPU requirement 1010 does not take into account hardware multithreading at all when host hyperthreading is disabled. In the prior art, if hyperthreading is enabled, it is not predictable which core's hardware thread will process the vCPU. By specifying a value for a hardware multithreading parameter that considers hardware multithreading, the number of unused hardware threads on a potential host can be reduced and which vCPUs run on the same core can be controlled.

[000111] The examples of FIGS. 16-19 show how hardware multithreading parameters can provide more control over how to place vCPUs. For example, if a VM with two vCPUs is performing operations that operate on the same data, the two vCPUs may be arranged for two different hardware threads in the same core, as shown in the example of FIGS. May be desirable because two threads executing on the same core will have very high performance access to the cache memory available to that core. If the VM with 2 vCPUs are performing independent tasks, the 2 vCPUs may be preferably arranged for two different cores, as shown in the example of Figures 19 and 20.

The third CPU requirement 1610C of FIG. 21 is another suitable example for the CPU requirement 1610 shown in FIG. 16 and includes 8 vCPUs 2120 and an SMT parameter 2130 with a value of 8 . For a potential host having a Power8 6 core CPU 1410 as shown in FIG. 14, the potential host will have one core in which all eight threads are used, and as a result, as shown in FIG. 22, There will be no threads that do not.

[000113] The fourth CPU requirement 1610D of FIG. 23 is another suitable example for the CPU requirement 1610 shown in FIG. 16 and includes 12 vCPUs 2320 and an SMT parameter 2330 with a value of 4 do. For a potential host with a Power8 6 core CPU 1410 as shown in FIG. 14, the potential host will have three cores in which four threads are used in each core, and as a result, Likewise, it will result in 12 unused threads. These simple examples illustrate how specifying a hardware multithreading parameter in selecting a host computer system can provide control over how to place vCPUs in the host computer system.

[000114] It is noted that the examples shown in Figures 17-24 assume that a vCPU can be deployed for each available thread. The above discussion of FIGS. 9-12 relates to an "overcommit ratio" for increasing the number of CPUs by a certain amount, and similar unreasonable ratios can be applied to host computer system selection according to the present application and claims have.

[000115] Referring to FIG. 25, a method 2500 selects a host when a hardware multithreading parameter is specified, as shown in FIGS. 16, 17, 19, 21 and 23. The Cloud VM request is read (step 2510). When the SMT parameter is OFF (step 2520 = YES), a host having a plurality 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 the prior art method 900 of FIG. When the SMT parameter is ON (step 2520 = NO), a number of threads that satisfy the number of SMT parameters and have a number of threads per core and that satisfy the number of vCPUs in the cloud VM request divided by the number of threads specified in the SMT parameter A host with cores is selected (step 2540). This is one particular way to select hosts with multiple hardware threads that satisfy the number of vCPUs in a cloud VM request. The method 2500 then ends.

[000116] Once the host computer system is selected, the vCPUs for the VM may be deployed on the selected host. Referring to FIG. 26, a method 2600 begins when vCPUs need to be deployed to a selected host (2610). When the SMT parameter is off (step 2620 = YES), each vCPU is placed on a different physical core (step 2630). When the SMT parameter is on (step 2620 = NO), the vCPUs may be placed on different hardware threads on the same physical core (step 2640). The method 2600 then ends.

[000117] When there is a hardware multithreading parameter in a cloud VM request, the cloud manager must know not only the number of physical cores in the CPUs in the potential host, but also the number of threads supported by the CPUs in the potential host. This is to ensure that a single core of the host can support the number of threads specified for the cloud VM request. Referring again to FIG. 6, this indicates that determining resources available at step 610 includes not only determining available CPU cores, but also determining whether multiple threads on these CPU cores are also available it means. One way to achieve this is to collect the maximum SMT settings supported by the host computer system as part of the resources available in step 610 of FIG. One example of this is shown in FIG. 27, where max_guest_smt (maximum guest SMT) is the sum of the values collected by the host monitor mechanism 440 of FIG. 4 to indicate whether the potential host computer system supports hardware multithreading . Possible values of max_guest_smt are powers of 2 numbers, 0 indicates that the SMT is turned off on the host computer system, and a power of 2 indicates the number of hardware threads available on each CPU Display. When all CPUs in the host computer system are of the same type, max_guest_smt will be a single value applied to all CPUs in the host computer system. When the host computer system includes different types of CPUs including different numbers of hardware threads, max_guest_smt may have different values for each CPU in the host computer system.

[000118] OpenStack does not have any existing support to help specify the desired topology of the current guest CPU. One way to implement the addition of hardware multithreading parameters discussed herein is to add an additional specification to an OpenStack flavor as shown in FIG. The parameter powerkvm: smt is a new parameter in the open stack flavor that specifies the desired SMT value for the guest VM. Possible values for this parameter are -1, indicating "do not care "; 0, indicating that SMT is off; Or a power of two. By including the ability to collect information about hardware multithreading on potential hosts in the max_guest_smt setting and the ability to specify a desired level of hardware multithreading in an open stack flavor, Provides a much improved method for selecting computer systems that allows potential host computer systems to deploy these VMs in a manner that better exploits the hardware multithreading capabilities of the host computer systems, The utilization of the CPU resources can be improved.

[000119] The hardware multithreading parameters discussed herein may also be used in a VM resizing operation. Sometimes the VM needs to have more or fewer resources, so the VM can be readjusted to add or reduce the resources deployed in the VM. One suitable method for rebalancing a VM is to specify that the open stack flavor should change the resource allocation for the VM. When rebalancing the VM, the open stack flavor may have the powerkvm: smt parameter discussed above, which is shown in FIG. FIG. 29 shows a method 2900 for rebalancing a VM, which is preferably performed by the VM rebalancing mechanism 470 shown in FIG. The flavor is read (step 2910) for the rebalancing operation of the existing VM. The flavor referenced in step 2910 is a flavor with a new (i.e., re-adjusted) allocation of resources for the VM. When the flavor does not contain an SMT parameter (step 2920 = NO), the SMT parameter of the VM is set to OFF (step 2930). If the flavor contains an SMT parameter (step 2920 = YES) and the value of the SMT parameter is OFF or "Don Care" (step 2940 = YES), the SMT parameter of the VM is set to OFF (step 2930) . When the SMT of the flavor has a power of two (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 2900 then ends. The method 2900 makes it possible to reliably " retrofit "existing VMs using SMT parameters.

[000120] A Power8 6-core CPU supports subcores, which means that when the split core is enabled, eight threads in each core are divided into sub-cores of two threads. Split core enabled Power 8 6-core CPU 3010 is shown in FIG. 30, which includes a first core 3020 and a second core 3050, wherein the first core 3020 includes four sub- And the second core 3050 is divided into four subcores 3052, 3054, 3056, and 3058. The subcores 3022, 3024, 3026, Four other cores are not shown in FIG. 30, but are similar to the two cores shown. As shown in Figure 30, each sub-core has two hardware threads. By dividing each core into sub-cores, the sub-cores can be assigned to virtual machines instead of cores, which results in saving a significant number of unused hardware threads.

[000121] When split core hosts are present, the cloud manager is advantageous because the host for the VM can determine whether or not to support split cores. Referring to FIG. 31, CPU requirement 3110 is preferably part of the Cloud VM request 510 shown in FIG. CPU requirement 3110 specifies the number of vCPUs 3120 and the hardware multithreading parameter 3130. The following examples illustrate how split cores affect the selection of a host and the placement of vCPUs on that host.

32, CPU requirement 3110A is one suitable example for CPU requirement 3110 shown in FIG. 31, with 2 vCPUs 3220 and an SMT parameter 3230 with a value of 2, . In a potential host with split core enabled Power8 6 core CPU 3010 as shown in FIG. 30, this potential host may have one sub-core in which two threads are used, As shown, the three sub-cores may be used by other VMs.

The second CPU requirement 3110B in FIG. 34 is another suitable example for the CPU requirement 3110 shown in FIG. 31, and includes two vCPUs 3420 and an SMT parameter 3430 with a value set to OFF. . In a potential host with split core enabled Power8 6-core CPU 3010, as shown in FIG. 30, where hardware multi-threading is turned off, this potential host may use 2 threads 2 in each sub- And as a result, no threads are used in each of the two sub-cores, as shown in Figure 35, and two sub-cores can be used by the other VMs.

The third CPU requirement 3110C in FIG. 36 is another suitable example for the CPU requirement 3110 shown in FIG. 31, with 8 vCPUs 3620 and an SMT parameter 3630 with a value of 2 . In a potential host with split core enabled Power8 6 core CPU 3010 as shown in FIG. 30, where the hardware multithreading has a value of 2, this potential host uses two threads in each sub-core And as a result, as shown in Figure 37, there are no unused threads. In one particular implementation, all eight vCPUs may be located in all eight threads (four subcores) of the same physical core. Of course, in other implementations, the four sub-cores of FIG. 37 may be located on two or more physical cores.

The fourth CPU requirement 3110D of Figure 38 is another suitable example for the CPU requirement 3110 shown in Figure 31 and includes 12 vCPUs 3820 and an SMT parameter 3830 with a value of 2 . In a potential host with split core enabled Power8 6 core CPU 3010 as shown in FIG. 30, where the hardware multithreading has a value of 2, this potential host uses two threads in each sub-core And as a result, as shown in Figure 39, there are no threads that are not used in all the sub-cores. In one particular implementation, eight of the twelve vCPUs may be located on eight threads (four subcores) of the same physical core and the remaining four vCPUs may be arranged on two subcores Can be placed in four threads. Of course, in other implementations, the six subcores of Figure 39 may be located on three or more physical cores.

[000126] All of the examples of CPU requirements of Figures 32, 34, 36 and 38 are for the case when the host has split cores enabled. When the host has split cores disabled, the result is similar to the examples shown in Figs. 17-24 discussed above in detail, except that the hosts have settings in which the split cores are disabled.

[000127] The examples of Figures 32, 36 and 38 all have SMT parameters with a value of 2. Because the Power8 subcore contains two threads, specifying two threads in the SMT parameter allows the most efficient placement of vCPUs on the Power8 CPU. Note, however, that the SMT parameter may be larger than 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, hosts with sub-cores with two threads will not satisfy the request. Therefore, hosts without split cores are not potential hosts when the SMT setting exceeds the number of threads for the sub-core.

[000128] Referring to FIG. 40, a method 4000 illustrates selecting a host computer system using a cloud VM request that includes hardware multithreading parameters that consider whether a split core is enabled on the host computer system. The method 4000 is preferably performed by the host selection mechanism 450 shown in FIG. The Cloud VM request is read in step 4010. If the SMT is OFF (step 4020 = YES) and the potential host has an enabled split core (step 4030 = YES), then the potential host is selected if it has a number of subcores that satisfy the number of vCPUs in the cloud VM request (Step 4040). If the SMT is OFF (step 4020 = YES) and the potential host has a disabled split core (step 4030 = NO), then the potential host has the number of physical cores satisfying the number of vCPUs in the cloud VM request (Step 4050). If the SMT is ON (step 4020 = NO) and the potential host has an enabled split core (step 4060 = YES), then the number of hardware threads for the subcore can satisfy the number of hardware threads specified in the SMT parameter And if the number of subcores can satisfy the number of vCUUs of the cloud VM request divided by the number of hardware threads specified in the SMT parameter, then the potential host may be selected (step 4070). If the SMT is ON (step 4020 = NO) and the potential host has a disabled split core (step 4060 = NO), if the number of hardware threads for the core can satisfy the number of hardware threads specified in the SMT parameter And if the number of physical cores can satisfy the number of vCUUs of the cloud VM request divided by the number of hardware threads specified in the SMT parameter, then that potential host may be selected (step 4080). The method (4000) is preferably repeated for each potential host, each potential host can create a pool of potential hosts from which one of the hosts can be selected using all appropriate criteria or heuristics . For example, a host with enabled split cores may be selected in preference to a host having a split split core when the VM request results in more efficient use of CPU cores and threads. The method 4000 illustrates how the information from the host regarding hardware multi-threading parameters and split core settings and hardware threads per core provides better control in the selection of the host computer system to bring about a more efficient deployment of vCPUs.

[000129] Referring to FIG. 41, the filter PowerKVMSMTFilter is used so that the cloud manager can filter out hosts with an enabled split core mode when a VM with SMT = 4 or SMT = 8 is requested. This filter can help the cloud manager to narrow down the number of potential hosts for the VM more quickly.

[000130] Referring to FIG. 42, method 4200 begins when vCPUs need to be deployed on a predetermined host (step 4210). The method 4200 is preferably performed by the vCPU placement mechanism 460 shown in FIG. When the SMT is OFF (step 4220 = YES) and the split core is enabled on the host (step 4230 = YES), the vCPUs are placed on the other subcores (step 4240). When SMT is OFF (step 4220 = YES) and the split core is disabled on the host (step 4230 = NO), the vCPUs are placed on different physical cores (step 4250). When SMT is ON (step 4220 = NO) and the split core is enabled on the host (step 4260 = YES), the vCPUs are placed on the threads of subcores (step 4270). When the SMT is ON (step 4220 = NO) and the split core is disabled on the host (step 4260 = NO), the vCPUs are placed on the threads 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 may be placed on multiple cores providing the necessary number of hardware threads for all of the vCPUs. Method 4200 illustrates how to specify hardware multithreading parameters and how to use information about split core settings provides better control in placing vCPUs on host computer systems.

[000131] In order to be able to place VMs in consideration of the split core and hardware multithreading parameters in the Cloud VM request, the cloud manager not only has to know the number of physical cores in the CPUs in the potential host, You should also know how many threads are supported by the split core and whether split core is enabled on the potential host. Referring back to Figure 6, it is determined that determining the available resources in step 610 not only determines the available CPU cores, but also if multiple threads on these CPU cores are also available, Lt; RTI ID = 0.0 > enabled. ≪ / RTI > One way to accomplish this is to collect information as to whether the split core is enabled on the potential host computer system as part of the resources available in step 610 of FIG.

[000132] The cloud manager includes resources that are available on host computer systems, including multiple hardware threads supported by CPUs on host computer systems, and in one embodiment the CPUs have split core enabled Or not. The cloud manager provides a virtual machine (VM) that includes hardware multithreading parameters that specify whether hardware multithreading is allowed on the host computer system (in one embodiment, the amount of hardware multithreading required on the host computer system) To receive the request. Then, in one embodiment, the cloud manager selects a host computer system for the VM in consideration of the hardware multithreading parameters. In another embodiment, the cloud manager selects a host computer system for the VM in consideration of hardware multithreading parameters, hardware threads supported by the CPU, and split core settings. The VM is then placed on a selected host computer system using hardware multithreading parameters. As a result, the utilization of CPU resources on the host for the virtual machine becomes more efficient.

[000133] Those skilled in the art will appreciate that many modifications are possible within the scope of the claims. Thus, while this application is particularly shown and described above, those skilled in the art will understand that these and other changes in form and details may be made therein without departing from the spirit and scope of the claims.

Claims (28)

An apparatus for monitoring a host computer system and selecting a host computer system, the apparatus comprising:
At least one processor;
A memory coupled to the at least one processor;
A cloud manager residing in the memory and being executed by the at least one processor, the cloud manager comprising:
A host monitor mechanism and a host selection mechanism,
The host monitor mechanism comprises:
Determining a plurality of CPUs available on a plurality of host computer systems in which virtual machines may be deployed;
Determine a plurality of hardware threads supported by each CPU on the plurality of host computer systems; And
Determine whether a split core is enabled for the CPU to split a core of each CPU on the plurality of host computer systems into multiple subcores,
The host selection mechanism comprises:
Receiving a virtual machine (VM) request comprising a number of virtual CPUs and a hardware multithreading parameter specifying whether hardware multithreading is required;
Selecting one of the plurality of host computer systems comprising a plurality of virtual CPUs in the VM request and a plurality of CPUs having a plurality of hardware threads satisfying the hardware multi-threading parameter and split core settings
Device. The method of claim 1, wherein the cloud manager comprises:
A virtual CPU (vCPU) placement mechanism using the hardware multithreading parameters and split core settings on the selected host computer to place a plurality of virtual CPUs (vCPUs) on the selected host computer system; (vCPU) placement mechanism
Device. delete delete The method of claim 1, wherein the cloud manager comprises:
A virtual CPU (vCPU) placement mechanism using the hardware multithreading parameters and split core settings on the selected host computer to place a plurality of virtual CPUs (vCPUs) on the selected host computer system; (vCPU) placement mechanism,
Wherein the first value of the hardware multithreading parameter indicates that hardware multithreading is turned off and is not required on the selected host computer system
Device. 6. The method of claim 5, wherein when the first value of the hardware multithreading parameter indicates that hardware multithreading is turn off, the vCPU placement mechanism is on a different physical core of the selected host computer system a different physical core) Place each vCPU in the VM request
Device. The method of claim 1, wherein the cloud manager comprises:
A virtual CPU (vCPU) placement mechanism using the hardware multithreading parameters and split core settings on the selected host computer to place a plurality of virtual CPUs (vCPUs) on the selected host computer system; (vCPU) placement mechanism,
Wherein the second value of the hardware multithreading parameter indicates that a hardware multithreading is required on the selected host computer system as a numerical value for a plurality of hardware threads on the selected host computer system
Device. 8. The method of claim 7, wherein when the second value of the hardware multithreading parameter indicates a numerical value for a plurality of hardware threads, the vCPU placement mechanism is operable on a different hardware thread of the selected host computer system To place each vCPU in the VM request
Device. 2. The method of claim 1, wherein the third value of the hardware multithreading parameter is selected such that regardless of whether hardware threading is turned on or turned off on the selected host computer system, Indicating that it has been selected
Device. The method of claim 1, wherein the VM request further comprises memory requirements and disk requirements
Device. 2. The system of claim 1, wherein the host monitor mechanism further determines an amount of memory and an amount of disk space on each of the plurality of host computer systems
Device. 2. The method of claim 1, wherein when the number of virtual CPUs in the VM request is greater than a value of the hardware multithreading parameter, the host selection mechanism determines whether each of the plurality of CPUs comprises a plurality of CPUs having a plurality of hardware threads Selecting one of the host computer systems
Device. 2. The method of claim 1, wherein the cloud manager further comprises a VM resize mechanism to reschedule at least one VM using the hardware multithreading parameter
Device. A computer-implemented method executed by at least one processor to place a plurality of virtual CPUs (vCPUs) on a host computer system, the method comprising:
Determining the number of available CPUs on a plurality of host computer systems in which virtual machines may be deployed;
Determining the number of hardware threads supported by each CPU on the plurality of host computer systems;
The number of vCPUs and the hardware multithreading parameters - The hardware multithreading parameters specify whether hardware multithreading is required and specify a minimum number of hardware threads per core when hardware multithreading is required - Receiving a virtual machine (VM) request that includes;
Selecting one of the plurality of host computer systems including a plurality of CPUs satisfying the hardware multithreading parameter and having a number of hardware threads satisfying a number of vCPUs in the VM request; And
Placing a plurality of vCPUs on the selected host computer system using hardware multithreading parameters,
Computer-implemented method. delete 15. The computer-implemented method of claim 14, wherein the computer-
Further comprising determining if each CPU on the plurality of host computer systems has enabled and enabled a split core and has enabled a number of subcores per core,
And wherein the selecting step comprises, in addition to one of the plurality of host computer systems comprising a plurality of CPUs having a plurality of hardware threads satisfying the VM request, the plurality of vCPUs and the hardware multithreading Selecting the split core settings that satisfy the parameters
Computer-implemented method. 17. The computer-implemented method of claim 16, further comprising using the hardware multi-threading parameter and the split core settings on the selected host computer system to place a plurality of vCPUs on the predetermined host computer system Included
Computer-implemented method. 15. The method of claim 14, wherein the first value of the hardware multithreading parameter indicates that hardware multithreading is turned off and therefore not required on the selected host computer system
Computer-implemented method. 19. The method of claim 18, wherein when the first value of the hardware multithreading parameter indicates that hardware multi-threading is turned off, the computer- Further comprising placing each vCPU in a VM request
Computer-implemented method. 15. The method of claim 14, wherein the second value of the hardware multithreading parameter is a numerical value for a minimum number of hardware threads per core on the selected host computer system that hardware multithreading is required on the selected host computer system. value)
Computer-implemented method. 21. The computer-implemented method of claim 20, wherein when the second value of the hardware multithreading parameter indicates a numerical value for a plurality of hardware threads, the computer- Further comprising placing each vCPU in the VM request on
Computer-implemented method. 15. The method of claim 14, wherein the third value of the hardware multithreading parameter is selected such that regardless of whether hardware threading is turned on or turned off on the selected host computer system, Indicating that it has been selected
Computer-implemented method. 15. The method of claim 14, wherein the VM request further comprises memory requirements and disk requirements
Computer-implemented method. 15. The method of claim 14, wherein the computer-implemented method further comprises determining an amount of memory and an amount of disk space at each of the plurality of host computer systems
Computer-implemented method. 15. The computer-implemented method of claim 14, wherein when the number of vCPUs in the VM request is greater than the value of the hardware multithreading parameter, the computer-implemented method further comprises: Further comprising the step of selecting one of the systems
Computer-implemented method. 15. The computer-implemented method of claim 14, further comprising the step of re-calibrating a VM using the hardware multi-threading parameter
Computer-implemented method. A computer-implemented method executed by at least one processor to place a plurality of virtual CPUs (vCPUs) on a host computer system, the method comprising:
Determining the number of available CPUs, the amount of memory, and the amount of disk space on a plurality of host computer systems in which virtual machines may 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, the VM request comprising a memory requirement specifying a minimum amount of memory for the virtual machine, a disk requirement specifying a minimum amount of disk for the virtual machine, and a virtual CPU Wherein the hardware multithreading parameter specifies that the hardware multithreading is required on the host computer system and that when hardware multithreading is required, Wherein a first value of the hardware multithreading parameter indicates that hardware multithreading is a turn off and a second value of the hardware multithreading parameter indicates that the hardware threads A numerical value for the minimum number, and a value of the hardware multithreading parameter 3 indicates that the host computer system is selected regardless of whether hardware threading is turned on or off on the host computer system;
Selecting one of the plurality of host computer systems comprising a plurality of CPUs satisfying the hardware multithreading parameter and having a plurality of hardware threads satisfying a plurality of vCPUs in the VM request; And
Placing the plurality of vCPUs on the selected host computer system using the hardware multithreading parameter, wherein the placing comprises: determining that the hardware multithreading parameter is hardware multi-threading turned off Placing each vCPU in the VM request on a different physical core in the selected host computer system when displaying, and when the hardware multithreading parameter indicates a numerical value for the number of hardware threads, Placing each vCPU in the VM request on a hardware thread
Computer-implemented method. delete

Images