DE112015000216T5 - Select a host for a virtual machine using a hardware multithreading parameter - Google Patents

Abstract

A cloud manager monitors available resources on host computer systems, including a number of hardware threads supported by CPUs on the host computer systems. The cloud manager receives a request to deploy a virtual machine (VM) that contains a hardware multithreading parameter that indicates the amount of hardware multithreading that is required on the host computer system. The cloud manager then selects a host computer system for the VM, taking into account the hardware multithreading parameter.

Description

BACKGROUND

Technical prayer

This disclosure generally relates to providing virtual machines to host computer systems, and more particularly to selecting a host for a virtual machine using a hardware multithreading parameter.

Technical background

In a cloud environment, a cloud manager provides virtual machines for host computer systems to create virtual servers. Typically, the cloud manager receives a request indicating what the virtual machine image (image) needs as system resources, such as memory, hard disk, and CPU. The cloud manager then determines available host computer systems on which the required system resources are available, selects one of the available host computer systems, and provides the virtual machine on the selected host computer system.

OpenStack is an open source software for building private and public clouds. In OpenStack, virtual hardware templates, called "flavors", specify the system resources needed for virtual machines. For example, a type in OpenStack can specify a size of memory, a root volume size, and a number of virtual CPUs for a virtual machine. When a virtual machine needs to be provisioned, a call is sent to the cloud manager, with the type indicating the resources needed for the virtual machine. The cloud manager then locates one or more host computer systems that have the resources specified in the type and provides the virtual machine on one of the host computer systems that matches the type.

Hardware multithreading in a host can make it difficult to deploy 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 a host computer system for a virtual machine, and virtual CPUs are assigned to hardware threads regardless of the physical cores. Unless hyperthreading is enabled on the host computer system, selecting a host computer system for a virtual machine only considers physical processor cores, and assigns virtual CPUs only to physical processor cores when deploying a virtual machine (VM) on the selected host computer system is. In modern processor architectures, such as POWER, which contain many hardware threads in each core, the result is a very inefficient use of processor resources.

Providing virtual machines can also be made more difficult if processors contain shared cores. The term "split-core processors" refers to a CPU core that can be divided into multiple sub-cores, each containing multiple hardware threads, where the sub-core appears as a core to a guest operating system. For example, a core that can act as a shared core with 8 hardware threads can be divided into 4 sub-cores, each of which can support 2 hardware threads. Activation of shared cores happens dynamically, which means that the partitioning can be programmatically changed on the host operating system. Well-known cloud managers treat processors with shared cores in no different way than processors without shared cores. As a result, known cloud managers can not realize the benefits of using shared core processors when deploying virtual machines.

SUMMARY

According to a first aspect, there is provided an apparatus comprising: at least one processor; a memory connected to the at least one processor; a cloud manager located in memory and executed by the at least one processor, the cloud manager comprising: a host monitoring mechanism that determines a number of CPUs, which are available on a plurality of host computer systems on which virtual machines could be provided, and which further determines a number of hardware threads supported by each CPU on the plurality of host computer systems; and a host selection mechanism receiving a virtual machine request containing a number of virtual CPUs and a hardware multithreading parameter, wherein the host selection mechanism selects one of the plurality of host computer systems that has a Number of CPUs containing a number of hardware threads that match the VM request.

According to a second aspect, there is provided a computer-implemented method executed by at least one processor to select a host computer system for providing a virtual machine, the method comprising: determining a number of CPUs running on a plurality of host machines; Computer systems on which virtual machines could be deployed; Determining a number of hardware threads supported by each CPU on the plurality of host computer systems; Receiving a virtual machine request (VM request) containing a number of virtual CPUs and a hardware multithreading parameter; and selecting one of the plurality of host computer systems that includes a number of CPUs having a number of hardware threads that conform to the VM request.

The invention can be realized as a computer program.

In accordance with a preferred embodiment, a cloud manager monitors available resources on host computer systems, including a number of hardware threads supported by CPUs on the host computer systems. The cloud manager receives a request to deploy a virtual machine (VM) that contains a hardware multithreading parameter that indicates the amount of hardware multithreading that is required on the host computer system. The cloud manager then selects a host computer system for the VM, taking into account the hardware multithreading parameter.

According to one embodiment, a solution is provided that deals with placing virtual CPUs using a hardware multithreading parameter.

In one embodiment, this disclosure generally relates to providing virtual machines to host computer systems and, more particularly, to providing virtual CPUs to a host computer system using a hardware multithreading parameter.

According to one embodiment, a solution for providing virtual CPUs using a hardware multithreading parameter in shared-core hosts is provided.

In one embodiment, this disclosure generally relates to providing virtual machines to host computer systems, and more particularly, to providing virtual CPUs using a hardware multithreading parameter for a host computer system that includes one or more shared processor cores.

According to one embodiment, there is provided an apparatus comprising: at least one processor; a memory connected to the at least one processor; a cloud manager located in memory and executed by the at least one processor, the cloud manager comprising: a host monitoring mechanism that determines a number of CPUs available on a plurality of host computer systems, on which virtual machines could be provided, and further determines a number of hardware threads supported by each CPU on the plurality of host computer systems; a host selection mechanism that receives a virtual machine (VM) request that includes a number of virtual CPUs and a hardware multithreading parameter, wherein the host selection mechanism selects one of the plurality of host computer systems that has a number of CPUs containing a number of hardware threads that match the VM request; and a virtual CPU placement mechanism (vCPU placement mechanism) that uses the hardware multithreading parameter to place a plurality of virtual CPUs (vCPUs) on the selected host computer system.

According to one embodiment, there is provided 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 a number of CPUs residing on a plurality of CPUs Host computer systems are available on which virtual machines could be provided; Determining a number of hardware threads supported by each CPU on the plurality of host computer systems; Receive a virtual machine request (VM request) containing a number of virtual CPUs and a hardware multithreading parameter; Selecting one of the plurality of host computer systems that includes a number of CPUs having a number of hardware threads that conform to the VM request; and using the hardware multithreading parameter to place the plurality of virtual CPUs on the selected host computer system.

According to one embodiment, there is provided 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 a number of CPUs, a memory size, and a Disk space size available on a plurality of host computer systems on which virtual machines could be deployed; Determining a number of hardware threads supported by each CPU on the plurality of host computer systems; Receiving a virtual machine request (VM request) that includes: a memory requirement indicating a minimum amount of memory for the VM; a disk requirement indicating a minimum disk size for the VM; and a CPU demand indicating a number of virtual CPUs for the VM and a hardware multithreading parameter, wherein a first value of the hardware multithreading parameter indicates that hardware multithreading is disabled, a second value of the hardware multithreading Parameters displays a numeric value for a number of hardware threads, and a third value of the hardware multithreading parameter indicates that the selected host computer system is selected regardless of whether hardware threading is on or off on the selected host computer system ; Selecting one of the plurality of host computer systems that includes a number of CPUs having a number of hardware threads that conform to the VM request; and using the hardware multithreading parameter to place the plurality of vCPUs on the selected host computer system by placing each vCPU in the VM on a different physical core in the selected host computer system when the hardware multithreading parameter indicates that hardware multithreading is turned off and by placing each vCPU in the VM on a different hardware thread in the selected host computer system when the hardware multithreading parameter indicates the number of hardware threads.

According to one embodiment, a method as described in the above paragraph is provided, further comprising changing the size of the VM using the hardware multithreading parameter.

According to one embodiment, there is provided an apparatus comprising: at least one processor; a memory connected to the at least one processor; a cloud manager located in memory and executed by the at least one processor, the cloud manager comprising: a host monitoring mechanism that determines: a number of CPUs available on a plurality of host computer systems on which virtual machines could be deployed; a number of hardware threads supported by each CPU on the plurality of host computer systems; and whether cores shared by each CPU on the plurality of host computer systems are enabled; a host selection mechanism that receives a virtual machine (VM) request that includes a number of virtual CPUs; and includes a hardware multithreading parameter; wherein the host selection mechanism selects one of the plurality of host computer systems that includes a number of CPUs having a number of hardware threads and shared core settings, the number of virtual CPUs, and the hardware multithreading parameter in the VM request correspond.

According to one embodiment, there is provided 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 a plurality of CPUs that are in plurality of host computer systems on which virtual machines could be provided; Determining a number of hardware threads supported by each CPU on the plurality of host computer systems; Determining if each core on the plurality of host computer systems has shared cores enabled, and if so, a number of shared cores per core; Receiving a virtual machine request (VM request) containing a number of virtual CPUs and a hardware multithreading parameter; and selecting one of the plurality of host computer systems that includes a number of CPUs having a number of hardware threads and shared core settings that correspond to the number of virtual CPUs and the hardware multithreading parameter in the VM request.

According to one embodiment, there is provided 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 a number of CPUs, a memory size, and a Disk space size available on a plurality of host computer systems on which virtual machines could be deployed; Determining a number of hardware threads supported by each CPU on the plurality of host computer systems; Determining whether each core on the plurality of host computer systems has shared cores enabled; Obtaining a virtual machine (VM) request that includes: a memory requirement indicating a minimum amount of memory for the VM; a disk requirement indicating a minimum disk size for the VM; and a CPU demand indicating a number of virtual CPUs for the VM and a hardware multithreading parameter, wherein a first value of the hardware multithreading parameter indicates that hardware multithreading is disabled, a second value of the hardware multithreading Parameters displays a numeric value for a number of hardware threads, and a third value of the hardware multithreading parameter indicates that the selected host computer system is independent selecting whether hardware threading is on or off on the selected host computer system; Selecting one of the plurality of host computer systems that includes a number of CPUs having a number of hardware threads and shared core settings that correspond to the number of virtual CPUs and the hardware multithreading parameter in the VM request; and using the hardware multithreading parameter and the split-core settings of the selected host computer system to place the plurality of vCPUs on the selected host computer system by exposing each vCPU in the VM to a different physical core in the selected host computer system. Computer system is placed when the hardware multithreading parameter indicates that hardware multithreading is turned off, and by placing each vCPU in the VM on a different hardware thread in a sub-core in a CPU in the selected host computer system, if the Hardware Multithreading parameter displays the number of hardware threads and indicates that the split cores settings of the selected computer system are enabled.

According to one embodiment, a cloud manager monitors available resources on host computer systems, including a number of hardware threads supported by CPUs on the host computer systems. The cloud manager receives a request to deploy a virtual machine (VM) that contains a hardware multithreading parameter that indicates 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 multithreading parameter. The VM is then placed on the selected host computer system using the hardware multithreading parameter.

In one embodiment, a cloud manager monitors available resources on host computer systems, including a number of hardware threads supported by CPUs on the host computer systems, and whether shared cores are enabled on the CPUs. The cloud manager receives a request to deploy a virtual machine (VM) that contains a hardware multithreading parameter that indicates 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 multithreading parameter, the hardware threads supported by the CPU, and the shared core settings. The VM is then placed on the selected host computer system using the hardware multithreading parameter. The result is a more efficient use of CPU resources in a host for a virtual machine.

The foregoing and other features and advantages will be apparent from the following more particular description, as illustrated in the accompanying drawings.

BRIEF DESCRIPTION OF THE VARIOUS VIEWS IN THE DRAWINGS

Embodiments of the present invention will be described by way of example only and with reference to the following drawings: like terms denote similar elements:

1 Fig. 10 is a block diagram of a cloud computing node according to a preferred embodiment of the present invention;

2 Figure 12 is a block diagram of a cloud computing environment according to a preferred embodiment of the present invention;

3 Fig. 12 is a block diagram of abstraction model layers according to a preferred embodiment of the present invention;

4 Fig. 10 is a block diagram showing some features of a cloud manager according to a preferred embodiment of the present invention;

5 FIG. 10 is a block diagram showing some features of a cloud VM request in accordance with a preferred embodiment of the present invention; FIG.

6 FIG. 10 is a flow chart of a method for a cloud manager to log available resources on candidate host computer systems in accordance with a preferred embodiment of the present invention;

7 FIG. 10 is a flowchart of a method for a cloud manager to provide a VM on a host computer system according to a preferred embodiment of the present invention; FIG.

8th Fig. 12 is a block diagram of a prior art x86 dual core CPU;

9 FIG. 10 is a flowchart of a prior art method for a cloud manager to select a host for a VM request; FIG.

10 Fig. 10 is a block diagram showing how CPU demand is indicated in a prior art cloud VM request;

11 Fig. 12 is a block diagram of a candidate host computer system showing three x86 dual-core processors in accordance with a preferred embodiment of the present invention;

12 FIG. 12 is a block diagram illustrating virtual machines containing vCPUs that, according to a preferred embodiment of the present invention, are suitable for the host in FIG 11 can be assigned;

13 FIG. 10 is a flowchart of a prior art method of placing vCPUs on physical cores in a host computer system; FIG.

14 Fig. 12 is a block diagram showing an architecture of a six-core Power8 CPU showing two of the six cores according to a preferred embodiment of the present invention;

15 FIG. 10 is a flowchart of a method according to a preferred embodiment of the present invention for using a hardware multithreading parameter to select a host and to control placement for vCPUs on the host; FIG.

16 FIG. 10 is an exemplary CPU requirement including a number of vCPUs and a hardware multithreading parameter according to a preferred embodiment of the present invention; FIG.

17 FIG. 10 is a first exemplary CPU requirement including a hardware multithreading parameter in accordance with a preferred embodiment of the present invention; FIG.

18 shows a candidate Power8 host according to a preferred embodiment of the present invention, which meets the CPU needs in 17 equivalent.

19 shows a second exemplary CPU requirement including a hardware multithreading parameter in accordance with a preferred embodiment of the present invention;

20 shows a candidate Power8 host according to a preferred embodiment of the present invention, which meets the CPU needs in 19 equivalent.

21 shows a third exemplary CPU requirement including a hardware multithreading parameter in accordance with a preferred embodiment of the present invention;

22 shows a candidate Power8 host according to a preferred embodiment of the present invention, which meets the CPU needs in 21 equivalent.

23 shows a fourth exemplary CPU requirement including a hardware multithreading parameter in accordance with a preferred embodiment of the present invention;

24 shows a candidate Power8 host according to a preferred embodiment of the present invention, which meets the CPU needs in 23 equivalent.

25 FIG. 10 is a flow chart of a method for selecting a host that meets a CPU requirement that includes a hardware multithreading parameter in accordance with a preferred embodiment of the present invention; FIG.

26 FIG. 10 is a flowchart of a method for placing vCPUs on a selected host computer system using a hardware multithreading parameter; FIG.

27 Figure 4 is a block diagram showing host-level statistics collected for each candidate host in accordance with a preferred embodiment of the present invention; and

28 Figure 13 is a block diagram showing an additional indication that could be realized in an OpenStack type to indicate the hardware multithreading parameter according to a preferred embodiment of the present invention.

29 FIG. 10 is a flow chart of a method for performing a resizing operation on an existing VM that may include a hardware multithreading parameter.

30 Figure 12 is a block diagram showing an architecture of a Power8 CPU with six cores with activated split cores, showing two of the six cores;

31 FIG. 10 is an exemplary CPU requirement including a number of vCPUs and a hardware multithreading parameter; FIG.

32 FIG. 10 is a first exemplary CPU requirement including a hardware multithreading parameter; FIG.

33 shows a candidate Power8 host according to a preferred embodiment of the present invention, which meets the CPU needs in 32 corresponds;

34 shows a second exemplary CPU requirement including a hardware multithreading parameter;

35 shows a candidate Power8 host according to a preferred embodiment of the present invention, which meets the CPU needs in 34 corresponds;

36 shows a third exemplary CPU requirement including a hardware multithreading parameter;

37 shows a candidate Power8 host according to a preferred embodiment of the present invention, which meets the CPU needs in 36 corresponds;

38 shows a fourth exemplary CPU requirement including a hardware multithreading parameter;

39 shows a candidate Power8 host according to a preferred embodiment of the present invention, which meets the CPU needs in 38 corresponds;

40 FIG. 10 is a flow chart of a method for selecting a host that meets a CPU requirement that includes a hardware multithreading parameter that takes into account when a host has shared cores;

41 FIG. 12 is a block diagram showing a filter that may be used to filter out hosts with shared core mode enabled when the hardware multithreading parameter is set to 4 or 8; FIG. and

42 FIG. 10 is a flow diagram of a method for placing vCPUs on a selected host computer system using a hardware multithreading parameter that takes into account when a host has shared cores; FIG.

DETAILED DESCRIPTION

A cloud manager monitors available resources on host computer systems, including a number of hardware threads supported by CPUs on the host computer systems, and whether shared cores are enabled on the CPUs. The cloud manager receives a request to deploy a virtual machine (VM) that contains a hardware multithreading parameter that indicates the amount of hardware multithreading that is required on the host computer system. The cloud manager then selects a host computer system for the VM, taking into account the hardware multithreading parameter, the hardware threads supported by the CPU, and the shared core settings. The VM is then placed on the selected host computer system using the hardware multithreading parameter. The result is a more efficient use of CPU resources in a host for a virtual machine.

It should be understood in advance that although this disclosure includes a detailed description of cloud computing, implementation of the teachings presented herein is not limited to a cloud computing environment. Rather, embodiments of the present invention may be practiced in conjunction with any other type of computing environment that is currently known or will be developed in the future.

Cloud computing is a model for providing services to provide convenient and on-demand network access to a shared reservoir of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services). which can be quickly deployed and released with minimal overhead or minimal interaction with a service provider. This cloud model can contain at least five properties, at least three service models, and at least four deployment models.

The properties are the following:

On-demand self-service: A cloud customer can unilaterally provide data processing capabilities such as server time and network storage as needed, without the need for human interaction with the service provider.

Broad Network Access: Provides capabilities over a network accessed through standard mechanisms that allow the use of heterogeneous thin or thick client platforms (eg, cell phones, notebook computers, and PDAs) support.

Resource Pooling: The vendor's computing resources are bundled to accommodate multiple customers using a multi-user model to service different physical and virtual resources that are dynamically allocated and reassigned according to demand. There is some kind of location independence in that the customer generally has no control or knowledge of the exact location of the resources provided but may be able to locate the site at a higher level of abstraction (eg, country, state, or data processing center ).

Rapid Elasticity: Capabilities can be deployed quickly and elastically, in some cases automatically, to quickly scale up the functionality, and quickly released to rapidly adjust the functionality. The customer often gets the impression that the capabilities available for deployment are unlimited and can be purchased at any time in any quantity.

Measured Service: Cloud systems automatically control and optimize resource usage by using a design capability at a given level of abstraction appropriate to the type of service (eg, storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported so that there is transparency for both the provider and the customer of the service being used.

The service models are the following:

Software as a Service (SaaS): The capability provided to the customer is to use the vendor's applications running on a cloud infrastructure. The applications are accessible from various client devices via a thin client interface, such as via a web browser (eg, e-mail based on the web). The customer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application capabilities, except for the possible exception of limited application custom configuration settings.

Platform as a Service (PaaS): The ability provided to the customer is to provide customer-generated or acquired applications on the cloud infrastructure that are generated using programming languages and programming tools supported by the provider , The customer does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, but has control of the deployed applications and possibly configurations of the application hosting environment.

Infrastructure as a Service (IaaS): The capability provided to the customer is to provide processing, storage, networking, and other basic computing resources, whereby the customer can deploy and run any software that may include operating systems and applications. The customer does not manage or control the underlying cloud infrastructure, but has control of operating systems, storage space, deployed applications, and possibly limited control over selected networking components (such as host firewalls).

The deployment models are:

Private cloud: The cloud infrastructure is operated exclusively for one company. It may be managed by the Company or a third party and may be located on or outside the Company premises.

Community Cloud: The cloud infrastructure is used by multiple companies and supports a specific community of common interests (eg a task, security requirements, policy and regulatory compliance issues). It may be managed by the companies or a third party and may exist on or outside the premises.

Public Cloud: The cloud infrastructure is made available to the general public or a large group in an industry and is owned by a company that sells cloud services.

Hybrid Cloud: The cloud infrastructure is a mix of two or more (private cloud, community cloud, or public cloud) clouds that remain stand-alone entities, but interconnected by a standardized or proprietary technology that enables data and application portability (eg cloud audience distribution (cloud bursting) for load balancing between clouds).

A cloud computing environment is service-oriented, with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that has a network of interconnected nodes.

With reference to 1 There is shown a block diagram of an example of a cloud computing node. A cloud computing node 100 is just one example of a suitable cloud computing node and is not intended to suggest any limitation on the scope or functionality of embodiments of the invention described herein. Regardless, the cloud computing node may 100 and / or perform any of the functionalities set forth hereinabove.

In the cloud computing node 100 is a computer system / server 110 which is operable in conjunction with numerous other general purpose or specialty computing system environments or configurations. Examples of well-known data processing systems, environments, and / or configurations for use in conjunction with the computer system / server 110 include, but are not limited to, personal computer systems, server computer systems, tablet computer systems, thin clients, thick clients, hand or notebook units, multiprocessor systems, microprocessor based systems, Top boxes, consumer electronic consumer programmable units, network PCs, minicomputer systems, mainframe systems, and distributed cloud computing environments, including any of the above-mentioned systems or devices, and the like.

The 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. Program modules may generally have routines, programs, objects, components, logic, and data structures, etc. that perform certain tasks or implement certain abstract data types. The computer system / server 110 can be practiced in distributed cloud computing environments where tasks are performed by remotely located processing units connected over a communications network. In a distributed cloud computing environment, program modules may reside on both local and remote computer system storage media, including main storage units.

As in 1 shown is the computer system / server 110 in the cloud computing node 100 represented in the form of a general-purpose data processing unit. To the components of the computer system / server 110 For example, but not limited to, one or more processors or processing units 120 , a system memory 130 and a bus 122 include various system components including system memory 130 with the processing unit 120 combines.

The bus 122 FIG. 12 illustrates one or more of any of various types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor bus or local bus utilizing any of a variety of bus architectures. By way of example, and not limitation, such architectures include the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MCA) bus, the EISA (Enhanced ISA) bus, the local VESA bus. Bus (VESA = Video Electronics Standards Association) and the PCI bus (PCI = Peripheral Component Interconnect).

The computer system / server 110 typically has a variety of media that can be read by computer systems. Such media may be any available media to which the computer system / server 110 These media include both volatile and non-volatile media, removable media and non-removable media. As an example of an in 1 removable media should be a Digital Video Disc (DVD) 192 serve.

To system memory 130 may be readable media for computer systems in the form of volatile memory or nonvolatile memory such as firmware 132 belong. The firmware 132 provides an interface to the hardware of the computer system / server 110 ready. To system memory 130 can also read computer-readable media in the form of volatile memory such as Random Access Memory (RAM). 134 and / or cache memory 136 belong. The computer system / server 110 may also include other removable / non-removable, volatile / non-volatile computer system storage media. Just as an example, a storage system 140 for reading from and writing to a non-removable non-volatile magnetic medium (not shown and normally referred to as a "hard disk"). Although not shown, a magnetic disk drive for reading from and writing to a removable nonvolatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading or writing to a removable nonvolatile optical disk such as a CD-ROM, DVD-ROM or other optical media. In such cases, each of these units may communicate with the bus through one or more data media interfaces 122 be connected. As further illustrated and described below, the memory 130 at least one program product containing a set (eg, at least one) of program modules configured to perform the functions described in more detail below.

A program / utility 150 containing a lot (at least one) of program modules 152 contains, as an example and not as a limitation in memory 130 and stored in an operating system, in one or more application programs, or in other program modules and program data. Each of the operating systems, one or more application programs, other program modules and program data, or a particular combination thereof may include one implementation of a networking environment. The program modules 152 typically carry out the functions and / or methodologies of embodiments of the invention as described herein.

The computer system / server 110 can also work with one or more external units 190 Exchange data, for example with a keyboard, a pointing device, a display unit 180 , a disk drive, etc .; with one or more devices that allow a user to connect to the computer system / server 110 ; and / or to interact with any devices (such as a network card, modem, etc.) that make it to the computer system / server 110 allow data to be exchanged with one or more other data processing units. Such data exchange can be done via input / output interfaces (I / O interfaces) 170 occur. In addition, the computer system / server 110 via a network adapter 160 exchanging data with one or more networks, for example using a local area network (LAN), a wide area network (WAN) and / or a public network (eg the internet). As shown, the network adapter swaps 160 over the bus 122 Data with the other components of the computer system / server 110 out. It should be understood that although not shown, other hardware and / or software components are associated with the computer system / server 110 could be used. Examples include, but are not limited to, microcode, device drivers, redundant processing units, external disk arrays, redundant array of independent disks (RAID) systems, tape drives, data storage systems, and so on.

With reference to 2 there is an illustrative cloud computing environment 200 displayed. As shown, the cloud computing environment 200 one or more cloud computing nodes 100 on which local computing devices such as a personal digital assistant (PDA) or mobile phone 210A , a desktop computer 210B , a notebook computer 210C and / or an automobile computer system 210N Exchange data used by cloud customers. The knots 100 can exchange data with each other. They may be physically or virtually grouped in one or more networks, such as in a Private Cloud, Community Cloud, Public Cloud or Hybrid Cloud described herein, or in a combination thereof (not shown). This allows the cloud computing environment 200 To provide infrastructure, platforms and / or software as services for which a cloud customer does not need to manage resources on a local computing device. It is understood that the types of data processing units 210A to N, the in 2 are intended to be illustrative, and that the computing nodes 100 and the cloud computing environment 200 communicate with any type of computerized unit through any type of network connection and / or network-addressable connection (eg, using a web browser).

With reference to 3 There's a lot of functional abstraction layers out there through the cloud computing environment 200 in 2 to be provided. In advance, it should be clear that the in 3 shown components, layers and functions are intended for illustration only, and the disclosure and the claims are not limited to these. As shown, the following layers and related features are provided.

A hardware and software layer 310 contains hardware and software components. Examples of hardware components include mainframes, in one example systems of the type ^IBM® System ^z® ; servers based on the reduced instruction set computer (RISC) architecture, in one example IBM ^{System® systems} ; Systems of the type IBM System x; IBM BladeCenter systems; Storage units; Networks and networking components. Examples of software components include network application server software, in one example, application server software IBM WebSphere ^®; and database software, in one example the IBM DB2 ^® database software. IBM, System z, System p, WebSphere, and DB2 are registered trademarks of International Business Machines Corporation in many jurisdictions worldwide.

A virtualization layer 320 provides an absorption layer from which the following examples of virtual entities can be provided: virtual servers; virtual memory; virtual networks, including virtual private networks; virtual applications and operating systems; and virtual clients.

In one example, a management layer 330 provide the functions described below. Resource provisioning provides the dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Billing and pricing provide cost control while leveraging resources within the cloud computing environment, as well as billing and billing for the consumption of those resources. In one example, these resources may include application software licenses. Security provides identity verification to cloud customers and tasks, as well as protection for data and other resources. The user portal provides customers and system administrators with access to the cloud computing environment. Service Level Management provides the allocation and management of cloud computing resources to meet the required quality of service. Service Level Agreement (SLA) planning and fulfillment agreements provide advance planning and sourcing of cloud computing resources expected to meet future requirements based on SLA. A cloud manager 350 is representative of a cloud manager, as described in more detail below. Although the cloud manager 350 in 3 as in the administrative layer 330 can be located, the cloud manager 350 span all levels in 3 are shown.

An operating load layer 340 provides examples of functionalities for which the cloud computing environment can be used. Examples of operating loads and functions that may be provided from this layer include: mapping and navigation; Software development and lifecycle management; Providing training in virtual classrooms; Processing of data analysis; Transaction processing; and mobile desktop.

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

The computer-readable storage medium may be a physical entity that can store and store instructions for use by an instruction execution unit. For example, but not limited to, the computer-readable storage medium may be 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 the computer readable storage medium includes: a portable computer diskette, a hard disk, random access memory (RAM), read only memory (ROM), erasable programmable read only memory (EPROM or flash memory). , a static random access memory (SRAM), a compact disc (CD-ROM) portable read only memory, a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanically coded unit such as punched or raised cards Structures in a groove with instructions recorded thereon or any suitable combination of the foregoing. A computer readable storage medium as used herein is not to be construed as being volatile signals, for example, radio waves or free propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission media (eg, light pulses passing a fiber optic cable) or electrical signals transmitted through a cable.

Computer readable program instructions described herein may be downloaded over a network, for example the Internet, a local area network, a wide area network and / or a wireless network, from a computer readable storage medium to relevant data processing units or to an external computer or external storage unit. The network may include copper transmission cables, fiber optics, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each data processing unit receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective data processing unit.

Computer readable program instructions for performing operations of the present The invention may be assembler instructions, ISA (ISA) instruction set instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, or either source code or object code written in any combination of one or more programming languages. which may include an object-oriented programming language such as Smalltalk, C ++ or the like and conventional procedural programming languages such as the "C" programming language or similar programming languages. The computer readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a stand-alone software package, partially on the user's computer and partially on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a Local Area Network (LAN) or Wide Area Network (WAN), or the connection can be made to an external computer (for example, over the Internet using an Internet Service Provider). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field programmable gate arrays (FPGA), or programmable logic arrays (PLA), may execute the computer readable program instructions by using state information of the computer readable program instructions to personalize the electronic circuit, such that embodiments of the present invention are performed.

Aspects of the present 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 flowcharts and / or block schemes and combinations of blocks in the flowcharts and / or block schemes may be implemented by computer program instructions.

These computer program instructions may be provided to a processor of a general purpose computer, a special purpose computer, or other programmable computing device to generate a machine such that the instructions executed via the processor of the computer or other programmable data processing device provide means to control the information in a block or file. to implement functions / actions specified in the blocks of the flowchart and / or the block schema. These computer program instructions may also be stored in a computer readable medium that may instruct a computer, other programmable computing devices or other entities to function in a particular manner so that the computer readable medium having instructions stored thereon comprises a product containing instructions corresponding to those in a block or in the blocks of the flowcharts and / or the block diagrams specified function / action.

The computer readable program instructions may also be loaded into a computer, other programmable computing devices, or other devices to cause a number of operations to be performed on the computer, other programmable devices, or other devices to facilitate a computer-implemented process so that the instructions executed on the computer, on other programmable devices or units, implement the functions / actions specified in a block or in the blocks of the flowcharts and / or the block diagrams.

The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. Accordingly, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions having one or more executable instructions for implementing the specified logic function (s). In some alternative implementations, the functions specified in the block may be performed in a different order from that shown in the figures. For example, two consecutive blocks may in fact be executed substantially concurrently, or the blocks may sometimes be executed in reverse order depending on the functionality involved. In addition, it should be noted that each block of the illustrated block diagrams and / or flowcharts, as well as combinations of blocks in the illustrated block diagrams and / or flowcharts, are illustrated by dedicated hardware-based systems for performing the specified functions or actions or combinations thereof can be performed for specific purpose hardware and computer instructions.

4 shows a suitable example of the in 3 represented cloud managers 350 , The cloud manager 350 includes a cloud deployment mechanism 410 , which is a resource request interface 420 contains. The resource request interface 420 allows a software unit to use virtual machines from the cloud manager 350 without requesting human intervention. The cloud manager 350 also includes a user interface 430 enabling a user to interact with the cloud manager to perform any suitable functions, including deploying VMs, deleting VMs, performance analysis of the cloud, etc. The difference between the resource request interface 420 and the user interface 430 is that a user is the user interface 430 must manually use to perform functions specified by the user while the resource request interface 420 can be used by a software unit to provide cloud resources through the cloud mechanism 350 without input from a user.

The cloud manager 350 also includes a host monitoring mechanism 440 which monitors available resources on eligible host computer systems so that the cloud manager 350 can compare specified resources for a VM with available resources on a candidate host computer system. A host selection mechanism 450 enables selecting a candidate host computer system based on comparing the specified resources for a requested VM with available resources on eligible host computer systems. A vCPU placement mechanism 460 places vCPUs on a selected host computer system using the hardware multithreading parameter. A VM resizing mechanism 470 allows you to resize existing VMs in a way that uses a hardware multithreading parameter, even if the original VM did not use a hardware multithreading parameter.

5 shows a suitable example of a cloud request 510 using the resource request interface 420 or via the user interface 430 on the cloud delivery mechanism 410 in 4 could be delivered to the provision of a VM by the cloud manager 350 to request. The cloud VM request 510 may include any indication of demand information for needed resources on the VM. Examples of suitable demand information include memory requirements 520 , a plate requirement 530 and a CPU requirement 540 , The storage requirement 520 Specifies the size of the memory required for the VM. The plate requirement 530 Specifies the size of the disk needed for the VM. The CPU requirement 540 indicates the number of virtual CPUs needed for the VM and can also specify a hardware multithreading parameter, as discussed in more detail below. Of course, other demand information could be included in 5 are not shown for a VM, such as network demand and any other suitable needs. In the prior art, OpenStack uses a "flavor" element as a cloud VM request that specifies the minimum resource requirements on a VM.

With reference to 6 is through the host monitoring mechanism 440 in 4 preferably a method 600 performed to monitor available resources on eligible host computer systems. Available resources on eligible host computer systems are determined (step 610 ) and logs (step 620 ). A known possibility for the realization of the method 600 uses a driver that queries a host to determine its available resources.

With reference to 7 begins a procedure 700 by receiving a cloud VM request (step 710 ). The resource requirements information in the cloud VM request is then compared to available resources on eligible host computer systems (step 720 ). It should be noted that the resources available in step 720 could be read from the log in step 620 in 6 was generated. Then, a host is selected that has resources that match the resource requirements information in the cloud VM request (step 730 ). Thereafter, the VM is deployed on the selected host computer system (step 740 ).

Many modern processors (or CPUs) contain multiple processing cores. An example of a multi-core processor is an x86 dual-core CPU 810 , in the 8th is shown. The x86 dual-core CPU 810 contains a first core 820 with two hardware threads 822 and 824 and a second core 840 with two hardware threads 842 and 844 , Having multiple hardware threads on each core can cause problems with deploying a VM to a host computer system. In the current state of the art, the number of hardware threads in a multi-core CPU is usually ignored, taking into account only the physical cores. For example, a prior art method reads 900 in 9 the cloud VM request (step 910 ) and then select one Host, which has a number of physical cores corresponding to the number of vCPUs in the cloud VM request (step 920 ). A prior art CPU requirement 1010 , as in 10 represents the number of virtual CPUs (vCPUs) in a VM and is a good example of the in 5 illustrated CPU requirements 540 , Because the procedure 900 Choosing a host for a VM uses only physical cores, so multiple hardware threads on the cores are not used, which does not leverage available CPU resources. In the prior art, when hyperthreading is enabled on the host, the number of hardware threads is taken into account, and placement of vCPUs on hardware threads is performed without regard to physical cores. This approach can lead to inefficient VMs, as some operating loads benefit from using threads on different cores, while others are better served by threads for the same core.

step 920 in 9 may include any suitable criteria or any suitable heuristics for selecting a host computer system that corresponds to a VM request. For example, the number of physical cores could be increased by a certain over-occupancy ratio of, for example, 2.0. Thus, if three physical cores are available on a host, multiplying the three physical cores with the congestion ratio from 2.0 to a number of available processors of 6, which means that one VM requiring six vCPUs will be on the host but not a VM that requires 7 vCPUs. A simple example illustrates this.

11 FIG. 10 illustrates an exemplary candidate host computer system that includes three x86 dual-core CPUs. It is assumed that VM1 is already running on this host, as in 12 which was provided on the two physical cores in CPU1 and on the first of the two physical cores in CPU2, as indicated by the hatching in these cores in CPU2 12 shown. Further, it is assumed that VM2 shown in FIG 12 , must be provided. The number of available cores is determined, for example, in 11 is nine, that is, the six cores multiplied by the congestion ratio of 2, minus the three cores used by VM1 in the candidate host 1, as in 11 shown. Since VM2 requires two vCPUs and 9 cores are available on eligible host 1, the candidate host 1 is a valid candidate host for VM 2, as in 12 shown.

Note that the actual placement of vCPUs on a candidate host is a step separate from selecting the candidate host for the VM. With reference to 13 begins a procedure 1300 by reading the cloud VM request (step 1310 ). The vCPUs in the cloud VM request are then placed on physical cores (step 1320 ). In 11 For example, the threads T1 of the first and second kernels of the CPU1 and the first kernel of the CPU2 are hatched to indicate that the three vCPUs in VM1, as in FIG 12 were placed on these three corresponding cores. It should be noted, however, that the placement is not static. At different times, a vCPU could be run on any of the hardware threads on any of the active cores. Hyperthreading involves a total of twelve hardware threads in the three dual-core cores. VM1 occupies 3 of these threads and leaves 9 for other VMs. However, the vCPUs are mapped to any of the threads, which may mean that work done in operating system threads that share memory would best be performed in hardware threads of the same vCPU while doing work that runs in operating system threads that are independent, better run in hardware threads in other cores. Therefore, the prior art creates inefficiencies in the way in which candidate hosts are identified for a VM, and in the way VMs are run on a selected host, since the mapping of VMs to candidate hosts currently differentiates between Hardware threads and cores not included on CPUs.

The prior art recognizes either a physical processor core or a hardware thread, but not both as a unit on which a virtual CPU can be deployed. Without hyperthreading has a single dual-core CPU, as in 8th presented, two available CPUs in the form of their two physical cores 820 and 840 where vCPUs can be deployed. With hyperthreading, a single dual-core CPU could support multiple vCPUs; however, whether the vCPUs are executed by hardware threads on the same physical core or on other cores is not deterministic. The disclosure and claims herein provide a finer degree of differentiation by recognizing that vCPUs must be associated with multiple hardware threads, not just a single physical core or a single hardware thread.

The problem of vCPUs associated with either a single hardware thread or core is exacerbated as the number of hardware threads is increased. For the x86 dual-core CPUs, in the 8th and 11 Hyperthreading results in two threads per core. For processors with more hardware threads, the problem becomes even more apparent. For example, includes a Power8 CPU 1410 with 6 cores in 14 is shown, a first core 1420 that has eight hardware threads 1432 . 1434 . 1436 . 1438 . 1442 . 1444 . 1446 and 1448 contains, and a second core 1450 that also has eight hardware threads 1462 . 1464 . 1466 . 1468 . 1472 . 1474 . 1476 and 1478 contains. The four other cores are in 14 not shown, but similar to the two illustrated cores. When a host is selected based on the number of physical cores, as in the procedure 900 in the prior art 9 As shown, many of the hardware threads remain unused. Therefore, the result would be if the two cores 1420 and 1450 two vCPUs would be deployed, as in 14 This implies that seven of the eight hardware threads would be wasted on each core. The net result is that at any given time, only two of the sixteen threads are used for the two cores, which is a waste of fourteen of the sixteen hardware threads. That means using the method 900 According to the prior art, the in 9 only two out of sixteen (12.5%) of the available processing resources can be used on two of the Power8 cores. On the other hand, if many per core hardware threads associate vCPUs with a hardware thread, VMs with operating loads requiring a high degree of concurrency and shared memory become more efficient by placing them on the same physical core as other vCPUs for that VM and not distributed to many physical cores.

To avoid the above-described problem of so many idle threads or vCPUs distributed on physical cores, consider with reference to FIG 14 a new way of identifying eligible hosts and providing VMs hardware threads by using a hardware multithreading parameter in the cloud VM request, based on the principle that one vCPU has multiple hardware threads within a physical core and not just a physical core or a single hardware thread. This is done by using a new parameter in the cloud VM request that involves hardware multithreading. In the specific examples herein, this hardware multithreading parameter is referred to as "SMT" parameter, where "SMT" stands for "Symmetric Multithreading" and is a term well-known in the art for describing hardware multithreading on CPUs , With reference to 15 begins a procedure 1500 by using an SMT parameter in the cloud VM request along with, in one embodiment, information about hosts per number of hardware threads and shared core settings to select a host computer system (step 1510 ). Once the host computer system has been selected, the same SMT parameter can be used in the cloud VM request to make placement decisions for vCPUs when the VM is provisioned on the selected host (step 1520 ). In one embodiment, information about the host in terms of the number of hardware threads per core and shared core settings may also be used to make placement decisions for vCPUs when the VM is deployed on the selected host (step 1520 ).

10 shows a prior art CPU demand 1010 for a cloud VM request, indicating the number of vCPUs 1020 contains that are needed on the VM. A cloud VM request 1610 according to the disclosure and the claims herein, as in 16 shown, contains the number of vCPUs 1620 , but additionally a hardware multithreading parameter (SMT parameter) 1630 , The value of the SMT parameter may be zero, indicating that hardware multithreading is off, or it may be a multiple of the number 2, reflecting the number of hardware threads. Some examples illustrate this. With reference to 17 is a CPU requirement 1610A a suitable example for the CPU requirement 1610 who in 16 and contains 2 vCPUs 1720 and the SMT parameter 1730 with a value of two. For a suitable host, a Power8 CPU 1410 containing 6 nuclei, as in 14 As shown in FIG. 2, the candidate host contains a core with two threads in use, resulting in six unused threads, as in FIG 18 shown.

A second CPU requirement 1610B in 19 is another suitable example for the CPU requirement 1610 who in 16 and contains 2 vCPUs 1920 and the SMT parameter 1930 with a value indicating that hardware multithreading is off. When hardware multithreading is disabled, a host that has a Power8 CPU will be included in a candidate host 1410 containing 6 nuclei, as in 14 the candidate host has two cores with one thread in each core used, resulting in fourteen unused threads in the two cores, as in 20 shown. Note that the net result of the eligible host is for the CPU requirement 1610B in 19 with the SMT parameter switched off the same as with the CPU requirement 1010 According to the prior art, as in 10 shown when hyperthreading is disabled because of CPU demand 1010 the prior art disregards arbitrary hardware multithreading when hyperthreading is disabled. In the prior art, with hyperthreading enabled, it is unpredictable which core hardware threads would process the vCPU. By specifying a value for the hardware multithreading parameter that takes into account hardware multithreading, the number of idle hardware threads on a candidate host can be reduced, and it can be controlled which vCPUs are running on the same core.

The examples in the 16 to 19 show how the hardware multithreading parameter allows more control over how vCPUs are deployed. For example, if a VM with 2 vCPUs executes jobs that operate on the same data, it may be desirable to deploy the 2 vCPUs to two different hardware threads in the same core, as in the example in FIG 17 and 18 because the two threads running on the same core have very powerful access to cache memory available to the core. If a VM with 2 vCPUs runs jobs that are independent of each other, it may be desirable to deploy the 2 vCPUs to two different cores, as in the examples in the 19 and 20 shown.

A third CPU requirement 1610C in 21 is another suitable example for the CPU requirement 1610 who in 16 and contains 8 vCPUs 2120 and at 2130 the SMT parameter with a value of 8. For a candidate host, a Power8 CPU 1410 containing 6 nuclei, as in 14 As shown in FIG. 2, the candidate host contains a core with all eight threads in use, which does not result in unused threads, as in FIG 22 shown.

A fourth CPU requirement 1610D in 23 is another suitable example for the CPU requirement 1610 who in 16 and contains 12 vCPUs 2320 and at 2330 the SMT parameter with a value of 4. For a candidate host, a Power8 CPU 1410 containing 6 nuclei, as in 14 the candidate host contains three cores with four threads used in each core, resulting in twelve unused threads, as in 24 shown. These simple examples show how specifying a hardware multithreading parameter when selecting a host computer system provides control over how the vCPUs are provided to the host computer system.

It should be noted that in the 17 to 24 assume that a vCPU can be deployed to any available thread. The above in terms of the 9 to 12 Explanation discusses an "overbooking ratio" to increase the number of CPUs by a certain amount. A similar overcommitment ratio could be used in selecting a host computer system, as disclosed and claimed herein.

With reference to 25 chooses a procedure 2500 host if a hardware multithreading parameter is specified, as in the 16 . 17 . 19 . 21 and 23 shown. The cloud VM request is read (step 2510 ). If the SMT parameter is OFF (step 2520 = YES), a host is selected on which a number of physical cores corresponding to the number of vCPUs in the cloud VM request are available (step 2530 ). It should be noted that the step 2530 the step 920 in the process 900 in the prior art 9 similar. When the SMT parameter is switched on (step 2520 = NO), a host is selected on which a number of threads per core is available, corresponding to the number in the SMT parameter, and divided by a number of cores corresponding to the number of vCPUs in the cloud VM request by the number of threads specified in the SMT parameter (step 2540 ). This is a concrete way to select a host that has a number of hardware threads equal to the number of vCPUs in the cloud VM request. The procedure 2500 is then completed.

Once a host computer system is selected, the vCPUs for the VM can be placed on the selected host. With reference to 26 begins a procedure 2600 if vCPUs need to be placed on the selected host (step 2610 ). When the SMT parameter is switched off (step 2620 = YES), each vCPU is placed on a different physical core (step 2630 ). When the SMT parameter is switched on (step 2620 = NO) vCPUs can be placed on different hardware threads on the same physical core (step 2640 ). The procedure 2600 is then completed.

In a hardware multithreading parameter in the cloud VM request, not only does the cloud manager need to know the number of physical cores in CPUs in a candidate host, but it also needs to know the number of threads that the CPUs in that one have eligible host will be supported. 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 6 This means that determining the available resources in step 610 not only includes determining available CPU cores, but also whether multiple threads are available on these CPU cores. One way to accomplish this is to step in 610 in 6 as part of the collection of available resources, to capture the maximum SMT setting supported by the host computer system. An example of this is in 27 where max_guest_smt is a value set by the host monitoring mechanism 440 in 4 to indicate whether a host computer system in question supports hardware multithreading. The possible values of max_guest_smt are zero, which indicates that SMT is off on the host computer system, and multiples of 2, indicating the number of hardware threads available on each CPU. If all CPUs in a host computer system are the same type, max_guest_smt is a single value that applies to all CPUs in the host computer system. If the host computer system contains different types of CPUs that contain different numbers of hardware threads, there could be a different max_guest_smt value for each CPU in the host computer system.

OpenStack currently does not provide support for specifying the desired topology of the guest CPU. One way to implement the addition of a hardware multithreading parameter discussed herein is to add an additional indication to an OpenStack type, as in FIG 28 shown. A parameter powerkvm: smt is a new parameter in an OpenStack type that specifies a desired SMT value for a guest VM. Note that the possible values of this parameter are -1, indicating "Do not Care"; zero, indicating that SMT is off; or multiples of 2. By incorporating the ability to gather hardware multithreaded information on eligible hosts in the max_guest_smt setting and the ability to specify a desired level of hardware multithreading in the OpenStack type, the disclosure and claims herein provide greatly improved Ability to select eligible host computer systems to deploy VMs and provide these VMs in a manner that better leverages the hardware multithreading capabilities of the host computer systems, thereby leveraging CPU resources the host computer systems is improved.

The hardware multithreading parameter discussed herein may also be used in a VM resizing operation. Sometimes a VM needs to have more or fewer resources available, so it can be resized to add or reduce resources provided to the VM. A convenient way to resize a VM is to specify an OpenStack type that alters the allocation of resources to the VM. When resizing a VM, the OpenStack type can include the powerkvm: smt parameter discussed above and in 28 is shown. 29 represents a procedure 2900 for changing the size of a VM, preferably by the VM resizing mechanism 470 is carried out in 4 is shown. A type for resizing an existing VM is read (step 2910 ). The guy on the step in 2910 Reference is made to the type with the new (ie, resized) allocation of resources to the VM. If the type does not contain the SMT parameter (step 2920 = NO), the VM's SMT parameter is turned off (step 2930 ). If the type contains the SMT parameter (step 2920 = YES) and the value of the SMT parameter is OFF or "Undetermined" (step 2940 = YES), the VM's SMT parameter is turned off (step 2930 ). If the SMT in the type is a multiple of 2 (step 2940 = NO), the VM's SMT parameter is set to the value of the SMT specified in the type (step 2950 ). The procedure 2900 is then completed. The procedure 2900 allows primarily to "upgrade" existing VMs to use the SMT parameter.

The 6-core Power8 CPU supports split cores, which means that the eight threads in each core can be split into split cores of two threads each if split cores are enabled. A Power8 CPU 3010 with 6 cores and activated split cores is in 30 shown as having a first core 3020 contains, which in four part cores 3022 . 3024 . 3026 and 3028 is divided, and a second core 3050 in four part cores 3052 . 3054 . 3056 and 3058 is divided. The four other cores are in 30 not shown, but similar to the two illustrated cores. Each subkernel contains two hardware threads, as in 30 shown. By dividing each kernel into part kernels, the kernels can be mapped to virtual machines rather than cores, resulting in a significant number of unused hardware threads being saved.

For existing split-core hosts, it would be beneficial for the cloud manager to determine if a host for a VM supports split cores. With reference to 31 is a CPU requirement 3110 a preferred component of a cloud VM request 510 , in the 5 is shown. The CPU requirement 3110 are a number of vCPUs 3120 and a hardware multithreading parameter 3130 at. Below are examples that illustrate how Split cores affect selecting a host and placing vCPUs on that host.

With reference to 32 is a CPU requirement 3110A a suitable example for the CPU requirement 3110 who in 31 and contains 2 vCPUs 3220 and the SMT parameter 3230 with a value of two. For a suitable host, a Power8 CPU 3010 containing 6 nuclei and activated split nuclei, as in 30 As shown in FIG. 2, the candidate host contains a sub-core with two threads in use, resulting in three sub-cores that can be used by other VMs, as in FIG 33 shown.

A second CPU requirement 3110B in 34 is another suitable example for the CPU requirement 3110 who in 31 and contains 2 vCPUs 3420 and at 3430 the SMT parameter with a value OFF. For a eligible host with hardware multithreading disabled, this is a Power8 CPU 3010 containing 6 nuclei and activated split nuclei, as in 30 As shown in FIG. 2, the candidate host contains two sub-kernels with one thread in each used sub-kernel, resulting in an unused thread in each sub-kernel, and two sub-kernels that can be used by other VMs, as in FIG 35 shown.

A third CPU requirement 3110C in 36 is another suitable example for the CPU requirement 3110 who in 31 and contains 8 vCPUs 3620 and at 3630 the SMT parameter with a value of two. For a hardware multithreading parameter value of 2, for a candidate host using a Power8 CPU 3010 containing 6 nuclei and activated split nuclei, as in 30 the candidate host contains four sub-kernels with two threads in each sub-core used, resulting in no unused threads, as in 37 shown. In one particular implementation, all eight vCPUs can be placed on all eight threads (four sub-cores) of the same physical core. Of course, the four subpixels in 37 as an alternative to two or more physical cores.

A fourth CPU requirement 3110D in 38 is another suitable example for the CPU requirement 3110 who in 31 and contains 12 vCPUs 3820 and at 3830 the SMT parameter with a value of two. For a hardware multithreading parameter value of 2, for a candidate host using a Power8 CPU 3010 containing 6 nuclei and activated split nuclei, as in 30 The candidate host contains six sub-cores with two threads in each sub-core used and no unused threads of any cores, as in 39 shown. 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 can be placed on four threads in two sub-cores in a different physical core. Of course, the six subpixels in 39 as an alternative to three or more physical cores.

All CPU requirement examples in the 32 . 34 . 36 and 38 apply to the case where split cores are enabled in the host. If shared cores are disabled on the host, the result is similar to the examples in the above 17 to 24 in detail, except that the hosts would have a setting that split cores are disabled.

The examples in the 32 . 36 and 38 all contain an SMT parameter with a value of two. Because a Power8 subkernel contains two threads, specifying two threads in the SMT parameter provides the most efficient placement of vCPUs on a Power8 CPU. It should be noted, however, that the SMT parameter could be greater than the number of threads on a subkernel. If the SMT parameter at 3630 in 36 For example, if you set the value to four, then hosts with sub-kernels with two threads will not match the request. Therefore, non-shared hosts are not eligible hosts if the SMT setting exceeds the number of threads for a subkernel.

With reference to 40 shows a method 4000 selecting a host computer system using a cloud VM request containing a hardware multithreading parameter that takes into account whether shared cores are enabled on the host computer system. The procedure 4000 is preferably by the host selection mechanism 450 performed in 4 is shown. A cloud VM request is read (step 4010 ). When the SMT is off (step 4020 = YES) and activated shared cores on a candidate host (step 4030 = YES), the candidate host may be selected if it contains a number of sub-kernels equal to the number of vCPUs in the cloud VM request (step 4040 ). When the SMT is off (step 4020 = YES) and disabled split Cores on the eligible host (step 4030 = NO), the candidate host may be selected if it contains a number of physical cores corresponding to the number of vCPUs in the cloud VM request (step 4050 ). When the SMT parameter is switched on (step 4020 = NO) and activated shared cores on the host in question (step 4060 = YES), the candidate host can be selected if the number of hardware threads for the sub-core can match the number of hardware threads specified in the SMT parameter, and the number of sub-cores of the number of vCPUs in the Cloud VM requirement, divided by the number of hardware threads specified in the SMT parameter (step 4070 ). When the SMT parameter is switched on (step 4020 = NO) and disabled shared cores on the host in question (step 4060 = NO), the candidate host can be selected if the number of hardware threads for the core can match the number of hardware threads specified in the SMT parameter and if the number of physical cores in the number of vCPUs in may match the cloud VM requirement divided by the number of hardware threads specified in the SMT parameter (step 4080 ). It should be noted that the procedure 4000 preferably for each candidate host, which may result in a pool of candidate hosts from which one of the hosts may be selected using any suitable criteria or any suitable heuristic. For example, a host with activated shared cores may be selected over a host with shared shared cores disabled if the VM request results in a more efficient use of CPU cores and threads. The procedure 4000 Figure 4 illustrates how a hardware multithreading parameter and information from the host regarding split core settings and hardware threads per core provide better control over selecting a host computer system that results in more efficient placement of vCPUs.

With reference to 41 For example, a PowerKVMSMTFilter filter can be used so that the Cloud Manager filters out hosts that have split-core mode enabled when requesting a VM with SMT = 4 or SMT = 8. This filter can help Cloud Manager speed up the number of eligible hosts for a VM more quickly.

With reference to 42 begins a procedure 4200 when vCPUs need to be placed on a selected host (step 4210 ). The procedure 4200 is preferably by the vCPU placement mechanism 460 performed in 4 is shown. When the SMT is off (step 4220 = YES) and split cores activated on the host (step 4230 = YES), the vCPUs are placed on different subkernels (step 4240 ). When the SMT is off (step 4220 = YES) and split cores disabled on the host (step 4230 = NO), the vCPUs are placed on different physical cores (step 4250 ). When the SMT is on (step 4220 = NO) and split cores activated on the host (step 4260 = YES), the vCPUs are placed on threads of the subkernels (step 4270 ). When the SMT is on (step 4220 = NO) and split cores disabled on the host (step 4260 = NO), the vCPUs are placed on threads of the same physical core (step 4280 ). Note that if the number of vCPUs exceeds the number of threads in a physical core, the vCPUs are placed on a number of cores that provide the required number of hardware threads for all vCPUs. The procedure 4200 illustrates how specifying a hardware multithreading parameter and using information about shared core settings provides better control over the placement of vCPUs on host computer systems.

In order to be able to place VMs in the cloud VM request, taking into account split cores and a hardware multithreading parameter, the cloud manager not only needs to know the number of physical cores in CPUs in a candidate host, but must also know the number of threads supported by the CPUs in the host in question and he needs to know if shared cores are enabled on a candidate host. Referring again to 6 This means that determining the available resources in step 610 not only includes determining available CPU cores, but also whether multiple threads are available on these CPU cores as well as whether cores shared on these cores are enabled. One way to accomplish this is to step in 610 in 6 As part of the collection of available resources, determine if shared cores are enabled on the host computer system in question.

A cloud manager monitors available resources on host computer systems, including a number of hardware threads supported by CPUs on the host computer systems, and in one embodiment, whether shared cores are enabled on the CPUs. The cloud manager receives a request to deploy a virtual machine (VM) that contains a hardware multithreading parameter that indicates the amount of hardware multithreading that is required on the host computer system. In one embodiment, the cloud manager then selects a host computer system for the VM, taking into account the hardware multithreading parameter. In another embodiment, the cloud manager then selects a host computer system for the VM, taking into account the hardware multithreading parameter, the hardware threads supported by the CPU, and the shared core settings. The VM is then placed on the selected host computer system using the hardware multithreading parameter. The result is a more efficient use of CPU resources in a host for a virtual machine.

It will be apparent to those skilled in the art that many variations are possible within the scope of the claims. Therefore, while the disclosure has been shown and described in detail above, it will be understood by those skilled in the art that these and other changes in form and details may be made within the scope without departing from the spirit and scope of the claims.

Claims (28)

Device comprising: at least one processor; a memory connected to the at least one processor; a cloud manager located in memory and executed by the at least one processor, wherein the cloud manager comprises: a host monitoring mechanism that determines a number of CPUs that are available on a plurality of host computer systems on which virtual machines might be provided, and further determines a number of hardware threads that are selected by each CPU on the plurality supported by host computer systems; and a host selection mechanism that receives a virtual machine (VM) request that includes a number of virtual CPUs and a hardware multithreading parameter, wherein the host selection mechanism selects one of the plurality of host computer systems that has a number of CPUs with a number of hardware threads that match the VM request. The device of claim 1 further comprising: a virtual CPU placement mechanism (vCPU Placement Mechanism) that uses the hardware multithreading parameter to place a plurality of virtual CPUs (vCPUs) on the selected host computer system. The apparatus of claim 1, wherein the host monitoring mechanism further determines whether shared cores are enabled for each CPU on the plurality of host computer systems, and wherein the host selection mechanism selects one of the plurality of host computer systems in addition to a number of host computer systems CPUs having a number of hardware threads that conform to the VN request contain shared core settings that correspond to the number of virtual CPUs and the hardware multithreading parameter in the VM request. The apparatus of claim 3, further comprising a virtual CPU placement mechanism (vCPU placement mechanism) that uses the hardware multithreading parameter and shared core settings on the selected host computer system to connect a plurality of virtual CPUs (vCPUs) on the selected one of the plurality of virtual CPUs Host computer system to place. The apparatus of any one of the preceding claims, wherein a first value of the hardware multithreading parameter indicates that hardware multithreading is disabled. The apparatus of claim 5 when dependent on claim 2 or claim 3, wherein if the first value of the hardware multithreading parameter indicates that hardware multithreading is disabled, the vCPU placement mechanism places each vCPU in the VM on a different physical core in the VM selected host computer system. The apparatus of any one of the preceding claims, wherein a second value of the hardware multithreading parameter indicates a numerical value for a number of hardware threads. The apparatus of claim 7 when dependent on claim 2 or 3, wherein if the second value of the hardware multithreading indicates a numerical value for a number of hardware threads, the vCPU placement mechanism inserts each vCPU in the VM on a different hardware thread placed on the selected host computer system. The apparatus of any preceding claim, wherein a third value of the hardware multithreading parameter indicates that the selected host computer system is selected regardless of whether hardware threading is enabled on the selected host computer system. The apparatus of any one of the preceding claims, wherein the VM request further includes a memory requirement and a disk requirement. The apparatus of any one of the preceding claims, wherein the host monitoring mechanism further determines a memory size and a disk space size on each of the plurality of host computer systems. The apparatus of claim 1, wherein when the number of virtual CPUs in the VM request is greater than the value of the hardware multithreading parameter, the host selection mechanism selects one of the plurality of host computer systems that includes a plurality of CPUs each having a plurality of hardware threads. The apparatus of any one of the preceding claims when dependent on claim 2, wherein the cloud manager further comprises a VM resizing mechanism that changes the size of at least one VM using the hardware multithreading parameter. A computer implemented method executed by at least one processor for selecting a host computer system to provide a virtual machine, the method comprising: Determining a number of CPUs available on a plurality of host computer systems on which virtual machines could be deployed; Determining a number of hardware threads supported by each CPU on the plurality of host computer systems; Receiving a virtual machine request (VM request) containing a number of virtual CPUs and a hardware multithreading parameter; and Selecting one of the plurality of host computer systems that includes a number of CPUs having a number of hardware threads that conform to the VM request. The method of claim 14, further comprising: Use the hardware multithreading parameter to place the majority of virtual CPUs on the selected host computer system. The method of claim 14, further comprising: Determining whether each core on the plurality of host computer systems has shared cores enabled, and if so, a number of shared cores per core, and wherein, in addition to selecting one of the plurality of host computer systems that includes a number of CPUs having a number of hardware threads that correspond to the VM request, the selecting step comprises selecting shared core settings corresponding to the number of virtual CPUs and the hardware multithreading parameter in the VM request. The method of claim 16, further comprising using the hardware multithreading parameter and the shared core settings on the selected host computer system to place a plurality of virtual CPUs (vCPUs) on the selected host computer system. The method of any one of claims 14 to 17, wherein a first value of the hardware multithreading parameter indicates that hardware multithreading is disabled. The method of claim 14 when dependent on claim 15 or claim 16, wherein if the first value of the hardware multithreading parameter indicates that hardware multithreading is disabled, each vCPU in the VM is on a different physical core in the selected host computer system is placed. The method of any of claims 14 to 19, wherein a second value of the hardware multithreading parameter indicates a numerical value for a number of hardware threads. The method of claim 20 when dependent on claim 15 or 16, wherein if the second value of the hardware multithreading indicates a numerical value for a number of hardware threads, each vCPU in the VM is on a different hardware thread in the selected host Computer system is placed. The method of any one of claims 14 to 21, wherein a third value of the hardware multithreading parameter indicates that the selected host computer system is selected regardless of whether hardware threading is enabled on the selected host computer system. The method of any one of claims 14 to 22, wherein the VM request further includes a memory requirement and a disk requirement. The method of any one of claims 14 to 23, wherein the host monitoring mechanism further determines a memory size and a disk space size on each of the plurality of host computer systems. The method of claim 14, wherein if the number of virtual CPUs in the VM request is greater than the value of the hardware multithreading parameter, selecting the one of the plurality of host computer systems comprising a plurality of CPUs each having a plurality of hardware Contains threads. The method of any of claims 15 to 25 when dependent on claim 15, further comprising changing the size of the VM using the hardware multithreading parameter. The method of claim 14, further comprising: in addition to the number of CPUs, determining a memory size and a disk space size available on a plurality of host computer systems on which virtual machines could be provided, wherein the virtual machine request (VM request ) further includes: a memory requirement indicating a minimum memory size for the VM; and a disk requirement indicating a minimum disk size for the VM; wherein a first value of the hardware multithreading parameter indicates that hardware multithreading is disabled, a second value of the hardware multithreading parameter indicates a numeric value for a number of hardware threads, and indicates a third value of the hardware multithreading parameter in that the selected host computer system is selected regardless of whether hardware threading is enabled on the selected host computer system. A computer program comprising program code means arranged to perform the method of any of claims 14 to 27 when the program is run on a computer.

Images