Automatic assessment of virtual machine computing power

Abstract

A set of virtual machines are deployed on a hypervisor. At each virtual machine, one or more local scans are performed to generate a set of compute resource consumption data. In response to receiving a set of hypervisor resource consumption data, a stability factor is generated. Based on the set of resource consumption data, the set of hypervisor resource consumption data, and the stability factor, a determination is made that a default consumption metric exceeds a threshold. In response to the determination, a custom consumption metric is generated based on at least the set of compute resource consumption data. The custom consumption metric is notified to a user.

Description

BACKGROUND

[0001] The present disclosure relates generally to the field of computing resource consumption, and more specifically to estimating consumption of computing resources.

[0002] Virtual machines and hypervisors are commonly employed in cloud computing environments. Monitoring consumption of computing resources allows a cloud service provider to measure efficiency, and it allows a consumer to judge whether to scale up / down his / her cloud operation. SUMMARY

[0003] Embodiments of the present disclosure include methods, computer program products, and systems for estimating consumption of computing resources.

[0004] A set of virtual machines are deployed on a hypervisor. At each virtual machine, one or more local scans are performed to generate a set of computing resource consumption data. In response to receiving a set of hypervisor resource consumption data, a stability factor is generated. Based on the set of resource consumption data, the set of hypervisor resource consumption data, and the stability factor, it is determined that a default consumption metric exceeds a threshold. In response to the determination, a custom consumption metric is generated based on at least the set of computing resource consumption data. The custom consumption metric is notified to a user.

[0005] The above summary of the invention is not intended to describe each illustrated embodiment or implementation of the present disclosure. BRIEF DESCRIPTION OF DRAWINGS

[0006] The accompanying drawings included in the present disclosure are incorporated into and form part of the specification. They illustrate embodiments of the present disclosure and, together with the specification, serve to explain the principles of the present disclosure. The drawings are only illustrations of typical embodiments and do not limit the present disclosure.

[0007] Figure 1 An example network environment for estimating consumption of computing resources according to embodiments of the present disclosure is illustrated.

[0008] Figure 2 An example method for estimating consumption of computing resources according to embodiments of the present disclosure is illustrated.

[0009] Figure 3 A cloud computing environment according to embodiments of the present disclosure is depicted.

[0010] Figure 4 An abstraction model layer according to embodiments of the present disclosure is depicted.

[0011] Figure 5 A high-level block diagram of an example computer system that can be used for implementing embodiments of the present disclosure is depicted.

[0012] While embodiments described herein are suitable for various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the specific embodiments described are not to be taken in a limiting sense. Rather, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the disclosure. DETAILED DESCRIPTION

[0013] Aspects of the disclosure generally relate to the field of computing resource consumption, and more particularly to estimating consumption of computing resources. While the disclosure is not necessarily limited to such applications, various aspects of the disclosure can be understood with reference to this context.

[0014] Virtual machines and hypervisors are commonly employed in cloud computing environments. Monitoring consumption of computing resources allows a cloud service provider to measure efficiency, and it allows a consumer to judge whether to scale up / down his / her cloud operations.

[0015] When licensing cloud computing resources to a consumer, an enterprise typically uses data collected from a hypervisor from which virtual machines are deployed, often using an application programming interface (API). Data collected in this manner can be aggregated with data collected from scans of individual virtual machines. These aggregated data can include, for example, metrics about processor, graphics processing unit (GPU), memory cache, network bandwidth, power consumption usage, number of computations performed, amount of time an application ran, priority of a particular application and / or virtual machine, encryption usage, encryption type, storage space availability and consumption, etc.

[0016] However, when a virtual machine is first deployed, there can be little, if any, such data, and any data that does exist can be irregular and not representative of normal operation metrics. For example, during installation and testing of an application, computing resource consumption can greatly increase. Or, network bandwidth can greatly decrease before an application is available for public use. In such scenarios, it can be difficult to determine an appropriate licensing fee for use of cloud computing resources related to a particular hypervisor or virtual machine. In some cases, a default computation can be used to determine consumption, and thus a licensing fee, based on expected / estimated usage. This can result in a consumer being over-billed or under-billed.

[0017] Obtaining more accurate estimates of consumed computing resources often requires coordination between teams of professionals, including: 1) the team responsible for deploying virtual machines, 2) the team managing the license metric tool (e.g., IBM License Metric Tool), and 3) the team managing the virtual hosting environment (e.g., VMWARE). The first team is typically directed by the consuming entity, while the second and third teams can or can not be part of the same entity. In some cases, coordinating the three teams across three separate entities can consume a significant number of work hours and time.

[0018] Embodiments of the present disclosure contemplate gathering data from the hypervisor (e.g., hypervisor resource consumption data) once the connection to the client / consumer is functional, combining that data with information gathered from a local scan of the virtual machine (e.g., computing resource consumption data), and adding a stability factor (e.g., reflecting a metric from both historical license capacity consumption and real-time consumption data from the complete infrastructure). If necessary, the default consumption values (e.g., default consumption metrics) that can be higher than expected by the consumer can be corrected and reported to the license administrator, consumer, etc., to generate a more accurate reflection of the overall consumption of the licensed resources.

[0019] In some embodiments, the data gathered from the local scan of the virtual machine can be collected by a monitor and / or stored in a database. In embodiments, this local scan data can be matched with data retrieved from the hypervisor. However, in some embodiments, this matching can be inaccurate or unavailable - in such cases, a default value can be used for consumption reporting, and the data can be flagged. Once sufficient data has been collected to perform the matching, the more accurate information can be used to repeat the consumption calculation, and the consumption report can be updated.

[0020] As an example, assume that a local scan of a collection of virtual machines is performed on a first day, but data from the hypervisor is not obtained or otherwise unavailable from the hypervisor. In this case, a default consumption metric can be introduced to estimate the overall consumption. The delay in obtaining the hypervisor resource consumption data can include firewall misconfiguration, data processing scheduling, errors, human intervention quirks, etc.

[0021] Further assume that on a third day, the hypervisor resource consumption data is obtained. At this point, the estimate of the overall consumption can be rechecked. The local scan of the virtual machines can be used to determine if there are changes or unexpected changes in the local environment.

[0022] In embodiments, along with the local scans, the hypervisor resource consumption data can be used to determine a stability factor for the environment. In this regard, it can be determined whether the actual overall consumption is consistent with the expected / estimated and whether the stability of the environment is relatively consistent (e.g., nominal overall consumption, but with periods of high traffic / consumption can be treated differently than nominal overall consumption with consistent traffic / consumption).

[0023] In some embodiments, if either or both of the overall consumption and / or the stability factor indicates that the default consumption metric falls outside of an acceptable range, then a custom consumption metric can be generated based on the actual overall consumption and the stability factor. In such embodiments, the administrator and / or consumer can be notified of the correction and the rationale for why the custom consumption metric is used.

[0024] Embodiments of the present disclosure can provide a way for cloud software vendors and consumers to protect themselves from unintended / unwanted spikes and valleys at the beginning of the license monitoring period. In this way, both the vendor and consumer’s adverse cost / benefit scenarios can be avoided, further leading to a reduction in the submission of support tickets and negative customer service reports.

[0025] Reference is now made to Figure 1Fig. 1 shows an example network environment 100 for estimating compute resource consumption, in accordance with an embodiment of the present disclosure. The example network environment 100 can include, for example, a licensee device 140, a cloud 110, a hypervisor 120, and a license meter 130. In some embodiments, certain functionalities of the licensee device 140, the hypervisor 120, and the license meter 130 can be implemented at a different location than depicted. According to embodiments, the licensee device 140, the cloud 110, the hypervisor 120, and the license meter 130 can be composed of computer systems (e.g., can contain the same or similar components as computer system 501). The licensee device 140, the cloud 110, the hypervisor 120, and the license meter 130 can be configured to communicate with each other through internal or external network interfaces (not shown). The network interfaces can be, for example, modems, wireless network adapters, Ethernet adapters, etc. The licensee device 140, the cloud 110, the hypervisor 120, and the license meter 130 can further be equipped with displays or monitors (not shown). Additionally, the licensee device 140, the cloud 110, the hypervisor 120, and the license meter 130 can include optional input devices (e.g., keyboards, mice, scanners, or other input devices) and / or any commercially available or custom software (e.g., image processing software, object recognition software, etc.). In some embodiments, the licensee device 140, the cloud 110, the hypervisor 120, and the license meter 130 can include additional servers, desktops, laptops, loT (Internet of Things) devices, or handheld devices.

[0026] The licensee device 140, the cloud 110, the hypervisor 120, and the license meter 130 can also include additional storage (e.g., storage interface 514). The storage can include, for example, virtualized disk drives, physical hard drives, solid state storage drives, or any other suitable storage medium. In some embodiments, workload data and metadata can be stored temporarily or permanently.

[0027] The licensee device 140, the cloud 110, the hypervisor 120, and the license meter 130 can be remote from each other and can communicate through a network (not shown). In embodiments, the cloud 110 can be a central hub from which the licensee device 140, the hypervisor 120, and the license meter 130 can establish communication connections, such as in a client-server networking model. In other embodiments, the license meter 130 can act as such a hub for the hypervisor 120 and the licensee device 140. In some embodiments, the licensee device 140, the cloud 110, the hypervisor 120, and the license meter 130 can be configured in any other suitable network relationship (e.g., in a peer-to-peer configuration or using another network topology).

[0028] In embodiments, connections between components of the networked environment 100 can be implemented using any number of any suitable communication media. For example, a wide area network (WAN), a local area network (LAN), the Internet, or an intranet. In certain embodiments, the licensee device 140, the cloud 110, the hypervisor 120, and the license meter 130 can be local to one another and communicate via any appropriate local communication medium. For example, the licensee device 140, the cloud 110, the hypervisor 120, and the license meter 130 can communicate using a local area network (LAN), one or more hardwired connections, a wireless link, or a router or intranet. In some embodiments, the licensee device 140, the cloud 110, the hypervisor 120, and the license meter 130, as well as any other devices, can be communicatively coupled using a combination of one or more networks and / or one or more local connections.

[0029] In some embodiments, the networked environment 100 can be implemented within, or as part of, a cloud computing environment, as depicted. Consistent with various embodiments, a cloud computing environment can include a network-based distributed data processing system that provides one or more cloud computing services. Further, a cloud computing environment can include a number of computers (e.g., hundreds or thousands of computers or more) arranged within one or more data centers and configured to share resources over a network. Further details regarding cloud computing are provided in Figure 3 and 4 are presented.

[0030] According to embodiments, the licensee device 140 can include, for example, an enterprise server, a client device, or any other suitable device from which a consumer or other user can interact with the license meter 130 and from which such a consumer / user can deploy virtual machines, such as virtual machines 125A-C.

[0031] The cloud 110 can include, for example, the hypervisor 120 and the license meter 130. The hypervisor 120 can include a hardware resources / components layer on which virtual machines (e.g., virtual machines 125A-C) can be established. According to embodiments, the hypervisor 120 can be a type 1 or type 2 hypervisor.

[0032] In some embodiments, the hypervisor 120 can include virtual machines 125A-C and a virtual machine monitor 127. For example, the virtual machines 125A-C can be deployed by an owner of the licensee device 140. The virtual machines 125A-C can be custom designed to serve a particular purpose, or they can be generalized to serve multiple purposes. In some embodiments, the virtual machines 125A-C can represent any number of virtual machines.

[0033] According to embodiments, the virtual machine monitor 127 can perform local scans of the virtual machines 125A-C to generate compute resource consumption data, as described herein. In some embodiments, the virtual machine monitor 127 can also monitor the hypervisor 120 to generate or contribute to hypervisor resource consumption data.

[0034] The local scans of the virtual machines 125A-C can include determining the amount of processor resources used, memory resources used, network traffic bandwidth used, in-memory computations performed, any hardware devices of the hypervisor substrate that can be dedicated to a particular virtual machine, etc.

[0035] The license meter 130 can include a hypervisor monitor 135 and a stability factor generator 137. The hypervisor monitor 135 can retrieve / receive hypervisor resource consumption data from the hypervisor 120, as described herein.

[0036] The stability factor generator 137 can generate a stability factor based on historical and real-time hypervisor resource consumption data. In some embodiments, the stability factor generator can also consider a certain amount of compute resource consumption data from one or more of the virtual machines 125A-C. In some embodiments, the stability factor generator 137 can also consider the overall stability of the cloud 110, historically and in real-time, beyond the hypervisor 120 and the license meter 130.

[0037] In some embodiments, the license meter 130 can employ a default consumption metric in determining overall compute resource consumption, or as discussed herein, it can generate a custom consumption metric when appropriate. In some embodiments, the license meter 130 can be used as a gateway between the hypervisor 120 and the licensee device 140. In other embodiments, the license meter 130 can be incorporated directly on the licensee device 140, for example as a condition of using the hypervisor 120 and / or establishing the virtual machines 125A-C.

[0038] Note that, Figure 1 It is intended to depict the representative major components of an example network environment 100. In some embodiments, however, individual components can have greater or lesser complexity than represented herein. For example, in some embodiments, the cloud 110 can represent multiple distributed cloud computing resources. In other embodiments, the cloud 110 can represent a single computing resource. In still other embodiments, the cloud 110 can represent a combination of multiple distributed cloud computing resources and a single computing resource. In some embodiments, the cloud 110 can represent a combination of cloud computing resources and non-cloud computing resources. In some embodiments, the cloud 110 can represent a combination of cloud computing resources and non-cloud computing resources. Figure 1 In some embodiments, the cloud 110 can include more or less components than those shown in Figure 1 In some embodiments, the cloud 110 can include components other than or in addition to those shown in Figure 1 In some embodiments, the cloud 110 can include more or less components than those shown in

[0039] Reference is now made to Figure 2FIG. 2 illustrates an example method 200 for estimating compute resource consumption according to embodiments of the present disclosure. The example method 200 can begin at 205, where a set of virtual machines are deployed on a hypervisor (e.g., hypervisor 120), as discussed herein.

[0040] At 210, compute resource consumption data is generated. For example, the virtual machine monitor 127 can perform a local scan of the deployed virtual machines (e.g., virtual machines 125A-C) to determine the amount and type of compute resources consumed.

[0041] At 215, a stability factor is generated. The stability factor can take into account the compute resource consumption data generated at 210 as well as hypervisor resource consumption data 240. In generating the stability factor, components of the compute resource consumption data and / or the hypervisor resource consumption data can be weighted. For example, in embodiments where in-memory computing is possible, memory consumption metrics can be weighted, as in-memory computing can reduce traditional processor consumption. In some embodiments, the stability factor can further reflect the amount of scaling up and down performed for a particular virtual machine or group of virtual machines.

[0042] As discussed herein, the hypervisor resource consumption data and the compute resource consumption data can include both historical data and real-time data. In some embodiments, the real-time data can be weighted in comparison to the historical data. According to embodiments, the historical compute resource consumption data and the historical hypervisor resource consumption data can reflect average values, respectively. The average values can be taken over the lifetime of their respective virtual machines and / or hypervisors, or they can be taken over a particular time range (e.g., a time period where the historical average values look similar to current real-time values).

[0043] At 220, it is determined whether the default consumption metric exceeds a threshold. In some embodiments, the default consumption metric can indicate the overall consumption expected from the historical compute resource consumption data and the historical hypervisor resource consumption data. According to embodiments, the threshold can include, for example, a ratio of the stability factor to the default consumption metric.

[0044] If it is determined at 220 that the default consumption metric does not exceed the threshold, it can be assumed that, for example, the default consumption metric reflects the overall consumption, and the default consumption metric can be notified to a user / administrator at 235. The notification can include, for example, a license consumption report.

[0045] However, if it is determined at 220 that the default consumption metric exceeds the threshold, then a custom consumption metric can be generated at 225, as described herein. In some embodiments, the custom consumption metric 225 can weight real-time consumption data collected, for example, from the virtual machine and / or hypervisor more heavily. In some embodiments, the custom consumption metric can reflect an average overall resource consumption of a historical collection of stable computing resource consumption data (e.g., reflecting consumption metrics of similar virtual machines for which the custom consumption metric is generated).

[0046] At 230, the custom consumption metric can be notified to the user and / or administrator. In some embodiments, this can include, for example, a permission consumption report, and can or can not reference the default consumption metric and the reason for using the custom consumption metric.

[0047] It should be appreciated that, although the present disclosure includes detailed descriptions of cloud computing, implementation of the teachings presented herein are not limited to a cloud computing environment. Rather, some embodiments of the present application are capable of implementation in conjunction with any other type of computing environment now known or later developed.

[0048] Cloud computing is a service delivery model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a provider of the service. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0049] The characteristics are as follows:

[0050] Broad network access: capabilities are available over a network and accessed through various standard mechanisms that promote the use of heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0051] Broad network access: capabilities are available over a network and accessed through various standard mechanisms that promote the use of heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).

[0052] Resource pooling: the provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically assigned and reassigned according to demand. There is a sense of location independence in that the consumer generally has no control or knowledge over the exact location of the provided resources but can be able to specify location at a higher level of abstraction (e.g., country, state, or datacenter).

[0053] Fast elasticity: can quickly and elastically provision and de-provision capabilities, in some cases automatically, to quickly match demand. Consumers can have a consistently high quality user experience and can acquire and release capabilities to scale rapidly.

[0054] Measured service: cloud systems automatically control and optimize resource use by leveraging a metering capability at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported providing transparency for both the provider and consumer of the utilized service.

[0055] Service models are as follows:

[0056] Software as a Service (SaaS): the capability provided to the consumer is to use the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based e-mail). The consumer does not manage or control the underlying cloud infrastructure including network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0057] Platform as a Service (PaaS): the capability provided to the consumer is to deploy onto the cloud infrastructure consumer-created or acquired applications created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly application hosting environment configurations.

[0058] Infrastructure as a Service (IaaS): the capability provided to the consumer is to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include an operating system and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).

[0059] Deployment models are as follows:

[0060] Private cloud: the cloud infrastructure is operated solely for the organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0061] Community cloud: the cloud infrastructure is shared by several organizations and supports mission-oriented business objectives by providing a common configuration for a group of consumers. It can be managed by the organizations or a third party and can exist on-premises or off-premises.

[0062] Public cloud: the cloud infrastructure is made available to the general public or a large industry group and is owned by an organization selling cloud services.

[0063] Hybrid cloud: the cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain unique entities but are bound together by technology that enables data and application portability.

[0064] A cloud computing environment is service-oriented, with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure of interconnected nodes, including end points.

[0065] Referring now to the drawing Figure 3 , an illustrative cloud computing environment 50 is depicted. As shown, cloud computing environment 50 includes one or more cloud computing nodes 10 with which a cloud consumer can communicate. Nodes 10 can be a personal computer (PC), a laptop computer, a cell phone, a PDA, a smart phone, a network router, switch or bridge, or any other communication device, server, or node that is capable of communicating and performing calculations. Nodes 10 can communicate with one another. They can be grouped (not shown) physically or virtually, in any fashion, in any number of topologies; and the cloud computing environment 50 can include and / or work in connection with any type of network and / or network addressable connection (for example, using a web browser and web server to communicate with any type of computerized device). Figure 4 The types of computing devices 54A-N shown in

[0066] Referring now to the drawing Figure 4 , a set of functional abstraction layers provided by cloud computing environment 50 (( Figure 3 ) is shown. It should be understood that the components, layers, and functions shown in Figure 4 are intended to be illustrative only and that some embodiments of the present application are not limited to this set of components, layers, and functions. As depicted, the following layers and corresponding functions are provided:

[0067] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include: mainframes 61; RISC (Reduced Instruction Set Computer) architecture based servers 62; servers 63; blade servers 64; storage devices 65; and networks and networking components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0068] Virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 71 ; virtual storage 72; virtual networks 73, including virtual private networks; virtual applications and operating systems 74; and virtual clients 75.

[0069] In one example, management layer 80 can provide the functions described below. Resource provisioning 81 provides dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud computing environment. Metering and Pricing 82 provide cost tracking as resources are utilized within the cloud computing environment, and billing or invoicing for consumption of these resources. In one example, these resources can include application software licenses. Security provides identity verification for cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides access to the cloud computing environment for consumers and system administrators. Service level management 84 provides cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment 85 provide pre-arrangement for, and procurement of, cloud computing resources for future requirement.

[0070] Workloads layer 90 provides examples of functionality for which the cloud computing environment can be utilized. Examples of workloads and functions which can be provided from this layer include: mapping and navigation 91 ; software development and lifecycle management 92; virtual classroom education delivery 93; data analysis processing 94; transaction processing 95; and estimating computing resource consumption 96.

[0071] Referring now to Figure 5 , a high-level block diagram of an example computer system 501 that can be configured to perform various aspects of the present disclosure is shown, including, for example, the method 200 described in Figure 2 According to embodiments of the present disclosure, the example computer system 501 can be used to implement one or more of the methods or modules described herein, as well as any related functionality or operations (e.g., using one or more processor circuits or computer processors of the computer). In some embodiments, the illustrative components of the computer system 501 include one or more CPUs 502, a memory subsystem 504, a terminal interface 512, a storage interface 514, an I / O (input / output) device interface 516, and a network interface 518, all of which can be communicatively coupled, directly or indirectly, for inter-component communication via a memory bus 503, an I / O bus 508, and an I / O bus interface unit 510.

[0072] Computer system 501 may include one or more general-purpose programmable central processing units (CPUs) 502A, 502B, 502C, and 502D, collectively referred to herein as CPU 502. In some embodiments, computer system 501 may include a typical multiple processors of a relatively large system; however, in other embodiments, computer system 501 may alternatively be a single CPU system. Each CPU 502 may execute instructions stored in memory subsystem 504 and may include one or more levels of onboard cache. Memory subsystem 504 may include instructions 506, which, when executed by processor 502, cause processor 502 to perform the above-mentioned... Figure 2 Describe some or all of the features.

[0073] In some embodiments, memory subsystem 504 may include random access semiconductor memory, storage devices, or storage media (volatile or non-volatile) for storing data and programs. In some embodiments, memory subsystem 504 may represent the entire virtual memory of computer system 501 and may also include virtual memory coupled to computer system 501 or other computer systems connected via a network. Memory subsystem 504 may conceptually be a single monolithic entity, but in some embodiments, memory subsystem 504 may be a more complex arrangement, such as a hierarchy of caches and other memory devices. For example, memory may reside in multi-level caches, and these caches may be further functionally partitioned such that one cache holds instructions while another cache holds non-instruction data used by one or more processors. Memory may also be distributed and associated with different CPUs or groups of CPUs, as known in any of the various so-called Non-Uniform Memory Access (NUMA) computer architectures. In some embodiments, main memory or memory subsystem 504 may include elements for controlling and flowing memory used by CPU 502. This may include memory controller 505.

[0074] Although the memory bus 503 is Figure 5The memory bus 503 is shown as providing a direct communication path between the CPU 502, the memory subsystem 504, and the I / O bus interface 510; however, in some embodiments, the memory bus 503 can comprise multiple different buses or communication paths, which can be arranged in any of various forms, such as point-to-point links, multiple levels of buses, parallel and redundant paths, or any other appropriate type of configuration, in various embodiments. Furthermore, while the I / O bus interface 510 and the I / O bus 508 are shown as separate components in FIG. 5, in some embodiments the I / O bus interface 510 and the I / O bus 508 can be integrated as a single component, or the I / O bus 508 can be directly connected to the CPU 502 and the memory subsystem 504. In some embodiments, the I / O bus 508 can be implemented as a point-to-point bus, a shared bus, or some other communication path, and can be implemented as a single bus or as multiple buses.

[0075] In some embodiments, the computer system 501 can be a multi-user large

[0076] Note that while the computer system 501 is shown as having a single CPU 502, multiple CPUs 502 can be present. Similarly, while the computer system 501 is shown as having a single memory subsystem 504, multiple memory subsystems 504 can be present. Figure 5 In some embodiments, the computer system 501 can be a multi-user large Figure 5 In some embodiments, the computer system 501 can be a multi-user large Figure 5 In some embodiments, the computer system 501 can be a multi-user large Figure 5 In some embodiments, the computer system 501 can be a multi-user large

[0077] The present application can be a system, a method, and / or a computer program product at any possible technical detail level of integration. The computer program product can include a computer readable storage medium (or media) having computer readable program instructions thereon for causing a processor to carry out aspects of the present application.

[0078] The computer readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. The computer readable storage medium can 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 the computer readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as punch cards or

[0079] The computer readable program instructions described herein can be downloaded to respective computing / processing devices from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and / or a wireless network. The network can comprise 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 and forwards the computer readable program instructions into the computing / processing device for storage in a computer readable storage medium within the respective computing / processing device.

[0080] Computer readable program instructions for carrying out operations of the present application can be assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or source code or object code written in any combination of one or more programming languages, including 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 can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate array (FPGA), or programmable logic array (PLA) can execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present application.

[0081] Aspects of the present application 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 application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer readable program instructions.

[0082] These computer readable program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / acts specified in the flowchart and / or block diagram block or blocks. These computer readable program instructions can also be stored in a computer readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer readable storage medium having instructions stored therein comprises an article of manufacture including

[0083] The computer readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer implemented process such that the instructions which execute on the computer, other programmable apparatus, or other device implement the functions / acts specified in the flowchart and / or block diagram block or blocks.

[0084] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions indicated in the blocks may occur in a different order than indicated in the figures. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It will also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0085] Various embodiments of the invention have been described for illustrative purposes, but are not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles of the embodiments, their practical application, or technical improvements to technologies found in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for estimating consumption of computing resources, comprising: deploying a set of virtual machines on a hypervisor; performing one or more local scans at each virtual machine to generate a first set of computing resource consumption data; receiving the first set of computing resource consumption data; receiving a first set of hypervisor resource consumption data from the hypervisor; and in response to receiving the first set of computing resource consumption data and the first set of hypervisor resource consumption data: combining the first set of computing resource consumption data with the first set of hypervisor resource consumption data, thereby generating overall consumption data; generating a stability factor, wherein the stability factor is a measure that at least partially reflects: real-time overall consumption data based on real-time computing resource consumption data of the first set of computing resource consumption data and real-time hypervisor resource consumption data of the first set of hypervisor resource consumption data, and historical overall consumption data based on historical computing resource consumption data of the first set of computing resource consumption data and historical hypervisor resource consumption data of the first set of hypervisor resource consumption data, wherein the stability factor at least partially indicates consistency of actual overall consumption data with an expectation; based on one or more of the overall consumption data and the stability factor, determining whether a default consumption metric exceeds a threshold, wherein the default consumption metric estimates the overall consumption data and the threshold at least partially represents a ratio between the stability factor and the default consumption metric; in response to determining that the default consumption metric does not exceed the threshold: notifying a user of the default consumption metric; and in response to determining that the default consumption metric exceeds the threshold: generating a customized consumption metric, wherein the customized consumption metric reflects an average overall resource consumption of a stable historical set of computing resource consumption data; and notifying a user of the customized consumption metric. The default consumption metric reflects an average of the historical computing resource consumption data. Software is provided as a service for generating the customized consumption metric.

4. A computer program product for estimating consumption of computing resources, the computer program product comprising program instructions executable by a device to cause the device to perform the steps of the method according to any one of claims 1-3, respectively.

2. The method of claim 1, wherein, 5. A system for estimating consumption of computing resources, the system comprising:

3. The method of claim 1, wherein, a memory subsystem comprising program instructions thereon; and a processor in communication with the memory subsystem, wherein the program instructions cause the processor to perform the steps of the method according to any one of claims 1-3, respectively. ​ ​ ​ ​

Images