WO2021096347A1

WO2021096347A1 - Method and system for dynamically managing access priority of virtual machine tenants to service or host

Info

Publication number: WO2021096347A1
Application number: PCT/MY2020/050101
Authority: WO
Inventors: Shahrol Hisham BAHAROM; Sharipah Setapa; Jing Yuan Luke; Hong Hoe ONG
Original assignee: Mimos Berhad
Priority date: 2019-11-15
Filing date: 2020-10-09
Publication date: 2021-05-20

Abstract

The present invention discloses a method and system for dynamically managing access priority of virtual machine, VM, tenants to a service or host. The method comprises the steps of identifying any of the VM tenants having requested for a same service or host thereby assigning the any of the VM tenants to one or more VM tenant groups; establishing a metric hierarchy for the VM tenants and the one or more VM tenant groups thereof; establishing a threshold attribute framework as an alternative determinator to the metric hierarchy thereof; and determining a service priority level for each of the VM tenants and the one or more VM tenant groups based on the metric hierarchy or the threshold attribute framework established thereof. Unlike the conventional, the present invention emphasizes resource allocation to the VM tenants based on predefined criteria and not based on a first come, first served basis.

Description

METHOD AND SYSTEM FOR DYNAMICALLY MANAGING ACCESS PRIORITY OF VIRTUAL MACHINE TENANTS TO SERVICE OR HOST

FIELD OF THE INVENTION

The present invention relates generally to virtual machine tenants. More particularly, the present invention relates to an improved method and system for dynamically managing access priority of virtual machine (VM) tenants to a service or host.

BACKGROUND OF THE INVENTION

Multitenancy ensures optimal performance of resources in a system such as memory, database, application and hardware and also secures each tenant’s personal data. The system is a constantly moving environment where the resources are being simultaneously accessed. Each tenant, e.g. virtual machine (VM) tenant, has different tasks, services and they are isolated from each other while sharing the same resources. In addition to that, each tenant also has different service level agreements (SLA) pertaining to, for example, network connectivity and bandwidth that can cause constraint of the resource distribution capability. Furthermore, each service or host requires different priority criteria when it is assigned to multiple tenants.

One problem associated with the multitenancy is that load received by a multi-tenant server is high. Moreover, the processing time and amount consumed in the multi-tenant server which are occupied by various tenants are not allocated based on the priority of the tenants. It should be acknowledged that some tenants have different criteria, urgency level and specification that require for prioritization to access the resources. The tenants further suffer from the restrictions stated in SLA. SLA may address several areas including the availability of service, hosts or the performance of the service. The problems consequently cause the service or host for eligible tenants cannot be rendered, fulfilled or occupied appropriately in a priority order.

By way of background, United States Patent No. 9,207,976 B2 (hereinafter “the ‘976 patent”) discloses a method, system, and computer program product for placement of a plurality of virtual machines on a hardware resource. According to the ‘976 patent, the method can also include generating a user location vector for each candidate virtual machine from the plurality of candidate virtual machines by aggregating a plurality of user location metrics for each candidate virtual machine. The method, according to the ‘976 patent, can also include ranking, in response to a performance resource demanded by the plurality of candidate virtual machines being at or above a threshold of the performance resource available on the hardware resource, the candidate virtual machines as a function of an aggregate user location vector for each candidate virtual machine. The method can include selecting a subset of the candidate virtual machines for migration based on the ranking.

It would therefore be advantageous to provide a solution that would overcome the deficiencies of the prior art by providing an improved method and system for dynamically managing access priority of VM tenants to the shared resources, e.g. service or host. Although there are methods and systems for the same in the prior art, for many practical purposes, there is still considerable room for improvement.

SUMMARY OF THE INVENTION

The following presents a simplified summary of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.

Accordingly, the present invention provides a method for dynamically managing access priority of virtual machine (VM) tenants to a service or host.

The method of the present invention may be characterized by the steps of identifying any of the VM tenants having requested for a same service or host thereby assigning the any of the VM tenants to one or more VM tenant groups; establishing a metric hierarchy for the VM tenants and the one or more VM tenant groups thereof, wherein the metric hierarchy comprises parameters selected from a group comprising a tenant type determined based on a database capacity, a host memory, a resource network access and a security assigned thereto, a host and a virtual network; establishing a threshold attribute framework as an alternative determinator to the metric hierarchy thereof, wherein the threshold attribute framework comprises attributes selected from a group comprising a cloud service, a database service and a web management; and determining a service priority level for each of the VM tenants and the one or more VM tenant groups based on the metric hierarchy or the threshold attribute framework established thereof.

Preferably, the method of the present invention further comprises the step of collecting historical data associated with the VM tenants, the host, the virtual network and the service or host in prior request to develop a historical profile for each of the VM tenants.

Preferably, the step of establishing a metric hierarchy comprises the step of comparing the tenant type and network resources requested by the VM tenants thereof to establish an inference statement that is incorporated in the metric hierarchy thereof.

Preferably, the tenant type indicates a tenant’s payment type which correspondingly suggests to the database capacity, the host memory, the resource network access and the security.

Preferably, the threshold attribute framework is utilized to prioritize the VM tenants if the metric hierarchy is not available.

In accordance with another aspect, the present invention provides a system for dynamically managing access priority of VM tenants to a service or host.

The system of the present invention may be characterized by a first processing engine configured for identifying any of the VM tenants having requested for a same service or host, wherein the first processing engine assigns the any of the VM tenants to one or more VM tenant groups; a second processing engine configured for establishing a metric hierarchy for the VM tenants and the one or more VM tenant groups thereof, wherein the metric hierarchy comprises parameters selected from a group comprising a tenant type determined based on a database capacity, a host memory, a resource network access and a security assigned thereto, a host and a virtual network; a third processing engine configured for establishing a threshold attribute framework as an alternative determinator to the metric hierarchy thereof, wherein the threshold attribute framework comprises attributes selected from a group comprising a cloud service, a database service and a web management; and a fourth processing engine configured for determining a service priority level for each of the VM tenants and the one or more VM tenant groups based on the metric hierarchy or the threshold attribute framework established thereof.

Preferably, the system of the present invention further comprises a data collection module configured for collecting historical data associated with the VM tenants, the host, the virtual network and the service or host in prior request to develop a historical profile for each of the VM tenants.

Preferably, the second processing engine comprises an inference engine configured for comparing the tenant type and network resources requested by the VM tenants thereof to establish an inference statement for incorporation into the metric hierarchy thereof.

The foregoing and other objects, features, aspects and advantages of the present invention will become better understood from a careful reading of a detailed description provided herein below with appropriate reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

A more complete appreciation of the invention and many of the attendant advantages thereof will be readily as the same becomes better understood by reference to the following detailed description when considered in connection with the accompanying drawings, wherein:

Figure 1 is a flow diagram of a method for dynamically managing access priority of virtual machine (VM) tenants to a service or host according to one embodiment of the present invention;

Figure 2 is a flow diagram of the step of identifying any of the VM tenants having requested for a same service or host thereby assigning the any of the VM tenants to one or more VM tenant groups according to one embodiment of the present invention;

Figure 3 is a flow diagram of the step of establishing a metric hierarchy for the VM tenants and the one or more VM tenant groups according to one embodiment of the present invention;

Figure 4 is a flow diagram of the step of establishing a threshold attribute framework as an alternative determinator to the metric hierarchy according to one embodiment of the present invention;

Figure 5 is a flow diagram of the step of determining a service priority level for each of the VM tenants and the one or more VM tenant groups based on the metric hierarchy or the threshold attribute framework according to one embodiment of the present invention; and

Figure 6 is a flow diagram of the step of collecting historical data associated with the VM tenants, the host, the virtual network and the service or host in prior request to develop a historical profile for each of the VM tenants according to one embodiment of the present invention.

It is noted that the drawings may not be to scale. The drawings are intended to depict only typical aspects of the invention, and therefore should not be considered as limiting the scope of the invention. In the drawings, like numberings represent like elements between the drawings. DETAILED DESCRIPTION OF THE INVENTION

Essentially, the present invention discloses a method and a system for dynamically managing access priority of virtual machine (VM) tenants to a service or host in an environment. In the present invention, principally, the VM tenants will be identified based on their respective metrics collected based on historical data for the same. If a metric indicates that a service level is relatively high for one particular VM tenant, then this VM tenant will be transformed to higher priority. Once the service is completed, the VM tenant will be recycled to a lowest priority making way for other VM tenants in the queue. Unlike the existing VM tenant priority management, the present invention emphasizes resource allocation to each and every VM tenants based on predefined criteria and not based on a first come, first served basis.

More specifically, the present invention proposes separation of each service and VM tenant, listing of all the services based on a frequency of use, creation of a fundamental historical nature of service priority with tenancy, identification of number of VM tenants using the same service, recognition of a service with highest frequency being the top priority, creation of criteria and sub-criteria based on a payment type, inference filter for checking various formats of payment type, scheduling of priority level upon changes in the requirement, creation of overall threshold framework as a precaution in the event that a metric hierarchy is not available (e.g. due to major failure), and creation of behavior characteristic checking including establishment of VM tenant groups of same services.

According to one embodiment of the present invention, the method comprises the step of identifying any of the VM tenants having requested for a same service or host thereby assigning the any of the VM tenants to one or more VM tenant groups (see 100), the step of establishing a metric hierarchy for the VM tenants and the one or more VM tenant groups thereof (see 200), the step of establishing a threshold attribute framework as an alternative determinator to the metric hierarchy thereof (see 300) and the step of determining a service priority level for each of the VM tenants and the one or more VM tenant groups based on the metric hierarchy or the threshold attribute framework established (see 400). A flow diagram depicting the method of the present invention is provided in Figure 1 . The step 100 is preferably an exercise for behavior characteristic checking for each VM tenant prior to grouping into the one or more VM tenant groups. Each task or service require a different priority when it is assigned to an individual VM tenant. Each VM tenant has different tasks and services. Thus, it is essential to identify any similarities between the VM tenants, for instance, in respect of the service or host that they are requesting access into (see 101). Each of the potential VM tenants (those who have the same service or host) will be consolidated for grouping and mapping the same service or host as outlined in step 102. In step 103, each VM tenant with various services or hosts will be captured and tagged. Subsequently, in step 104, the relationship between the VM tenants and the various services will be identified before classifying which service for each VM tenant belongs to (see step 105). The consolidated VM tenants will be assigned to the one or more VM tenant groups thereof in step 106. The VM tenant group will be subjected to a specific cluster to prioritize the same based on tenant priority services. A series of the above-mentioned steps is provided by a flow diagram of Figure 2.

The grouping of VM tenants having the same service or host is essential to the present invention. The one or more VM tenant groups will be compared against the equivalent metric hierarchy for the same. The following is an example of metric hierarchy of one or more VM tenant groups according to one embodiment of the present invention.

Table 1 : Metric Hierarchy of One or More VM Tenant Groups

Each VM tenant which uses the same service with respect to each other will be consolidated and arranged to the one or more VM tenant groups. In each of the VM tenant group, each group member will be filtered as to whether they need to be upgraded the service or not. If not, then, the group members will proceed with any assigned level of service (e.g. priority 1 , priority 2 and priority 3). Level of priority will then be collected based on the VM tenant groups thereof. For instance, if the VM tenant group 1 (e.g. “Group Tenant 1”) is not in priority, then the Group Tenant 1 will be recycled to priority level 2 or 3 depending upon the metric hierarchy of the group.

In the step 200, the metric hierarchy preferably comprises parameters that may be selected from a group comprising a tenant type determined based on a database capacity, a host memory, a resource network access and a security assigned thereto, a host and a virtual network. It is preferred that the tenant type indicates a tenant’s payment type which correspondingly suggests to the database capacity, the host memory, the resource network access and the security. In relation to step 200, the step of establishing a metric hierarchy comprises the step of comparing the tenant type and network resources as requested by the VM tenants thereof to establish an inference statement that is incorporated in the metric hierarchy thereof.

The following is an example of metric hierarchy of VM tenants according to one embodiment of the present invention. Table 2: Metric Hierarchy of VM Tenants

Each level of parameters or metric identities (i.e. host, virtual network, services and database) has a hierarchy when it is compared against the tenant type. Sub-criteria such as expensive will obtain higher priority of the available host. In the event that there is no competition between VM tenants, any available host will be assigned to any VM tenants with the tenant type “free”. If available hosts are not being demanded by other VM tenants which have the tenant’s payment type “high and medium”, then VM tenants which have the tenant’s payment type “free” will be made eligible for the available host if no competition between other tenants with certain limitation on the host memory or performance, storage, network and resource. Table 3 provides an example of tenant’s payment type alongside its criteria.

Table 3: Tenant’s Payment Type

When an available service (service of available host as an example) is available for the tenant type “free”, then the metric hierarchy must follow a strict limitation such as database, host memory or performance and resource network because the metric hierarchy is not bound to the security. However, the security can be incorporated in, for instance, in the event that the VM tenant attempts to access a specific tool (e.g. resource network which is restrictive) but with the tenant type “low”. This is to ensure that only recognized VM tenant with a proper process (take authentication as an example) can access a data/software/tool which is not meant for public purposes.

In the event that there are two or more VM tenants (e.g. VM1 and VM2) having a same priority set therefor, the metric hierarchy will be used to determine which VM tenant is eligible for a level 1 priority. Based from the metric hierarchy provided as an example in Table 1 , VM1 will be assigned to the level 1 priority instead of VM2. This is due to the reason that VM1 is the tenant type “expensive” which carries more weight and priority value compared to VM2 who is the tenant type “medium”.

With reference to Figure 3, the metric hierarchy is established based on specific parameters including the tenant type, the host memory, the resource network access and the services (see step 201). Each parameter or criteria will be categorized, expanded and classified as high, medium or free based on the tenant’s payment type. If there are two different VM tenants requested to be hosted in a same host, then the expanded parameter or criteria which is sub-criteria will be taken into consideration for analysis and negotiation. In one embodiment, VM tenant that pays (i.e. high and expensive) will secure the demanded host. The next in queue will fall on VM tenant who pays lower (i.e. low and medium).

In designing the metric hierarchy, the present invention, through step 202, establishes an inference statement by way of comparing the tenant type and network resources as requested by the VM tenants. A checking as to whether the inference statement established thereof is necessary to be compared will be made in step 203. If the inference statement is compared, then obtains a matching value which indicates reasoning results (see step 204). Following that, in step 205, a prioritization level or priority level will be determined. If the inference statement is not compared, then checks identity of the VM tenants (see 206). Once identified, the metric hierarchy will be updated in step 207. The inference statement is preferably incorporated in the metric hierarchy thereof. The ladder of inference for the tenant’s payment type is preferably employed in the present invention. The following is an example of the inference statement derived thereof.

Table 4: Ladder of Inference for Tenant’s Payment Type

For example, VM1 has a tenant type “expensive” and request a host with high performance. Therefore, an inference statement for VM1 is “expensive” + “high” that indicates serious matter, urgent and priority.

In the step 300, the threshold attribute framework preferably comprises attributes selected from a group comprising a cloud service, a database service and a web management. It is preferred that the threshold attribute framework is utilized to prioritize the VM tenants if the metric hierarchy is not available. If various services or hosts are running and cause a stuck which is unknown or not available, then, the threshold attribute framework will be utilized as a major threshold of the priority level if a downtime occurs. As a result, the priority level will be reset when requirement of priority based on the selected sub-criteria has failed. This serves as an alert for the metric hierarchy as well as to maintain the available link and to avoid congestion. Figure 4 provides a process flow for establishing the threshold attribute framework. The affected service will be identified in step 301. Subsequently, attributes associated with the said service will be identified in step 302. If the downtime occurs, stuck and the metric hierarchy is not available, then these attributes will be adopted as major thresholds of the priority level (see step 303). The thresholds derived from the attributes will be retrieved for use in the threshold attribute framework as outlined in step 304. If there is no downtime, not stuck and the metric hierarchy is available, then proceed with the execution of the metric hierarchy (see step 305).

In the step 400, there will involve change of priority level between the VM tenants which is shown in Figure 5. The service priority level of the VM tenants will be changed and scheduled appropriately (see step 401). The VM tenants will be re arranged according to the established service priority level thereof in step 402. Upon checking in step 403, if there is a same service or host between the VM tenants, then the VM tenant groups will be checked (see step 404) and the same service among the VM tenant groups will be identified (see step 405). In step 406, the service priority level will be matched for each VM tenant group. Finally, in step 407, the service priority level will be scheduled for the VM tenant groups. If there is no same service or host between the VM tenants, then updates the VM tenants to a new service priority level as stated in step 408.

According to one embodiment of the present invention, the method of the present invention further comprises the step of collecting historical data associated with the VM tenants, the host, the virtual network and the service or host in prior request to develop a historical profile for each of the VM tenants. In this regard, all historical data associated with the VM tenants, the host, the virtual network and the services will be gathered and processed. The historical data will be primarily employed as the parameters or metric identity for establishing the metric hierarchy. In step 500, the VM tenants will be categorized based on their tenant types, hosts, virtual networks and services. Subsequently, in step 501 , a metric level for the VM tenants will be established based on the category thereof. In step 502, a hierarchy arrangement providing, for instance, the availability of the VM tenants with the respective categories, will be created. Following that, the step 503 of identifying different or other criteria for the VM tenants for use when they were challenged. Finally, sub-criteria for the VM tenants will be determined in step 504. Each parameter of the VM tenants will be categorized, expanded and classified as high, medium or free based on the tenant’s payment type. Figure 6 is a flow diagram for designing the fundamental history profile according to the present invention.

In accordance with another aspect, the system of the present invention preferably comprises a first processing engine, a second processing engine, a third processing engine and a fourth processing engine. The first processing engine is configured for identifying any of the VM tenants having requested for a same service or host. The first processing engine assigns the any of the VM tenants to the one or more VM tenant groups. The second processing engine is configured for establishing the metric hierarchy for the VM tenants and the one or more VM tenant groups thereof. The second processing engine preferably comprises an inference engine that is configured for comparing the tenant type and network resources requested by the VM tenants thereof to establish the inference statement. The third processing engine is configured for establishing the threshold attribute framework. The fourth processing engine is configured for determining the service priority level for each of the VM tenants and the one or more VM tenant groups based on the metric hierarchy or the threshold attribute framework established thereof.

The system of the present invention further comprises a data collection module. The data collection module is configured for collecting the historical data associated with the VM tenants, the host, the virtual network and the service or host in prior request to develop a historical profile for each of the VM tenants.

Throughout this specification, plural instances may implement components, operations, or structures described as a single instance. Although individual operations of one or more methods are illustrated and described as separate operations, one or more of the individual operations may be performed concurrently, and nothing requires that the operations be performed in the order illustrated. Structures and functionality presented as separate components in example configurations may be implemented as a combined structure or component. Similarly, structures and functionality presented as a single component may be implemented as separate components. These and other variations, modifications, additions, and improvements fall within the scope of the subject matter herein. Although an overview of the inventive subject matter has been described with reference to specific example embodiments, various modifications and changes may be made to these embodiments without departing from the broader scope of embodiments of the present disclosure. Such embodiments of the inventive subject matter may be referred to herein, individually or collectively, by the term “invention” merely for convenience and without intending to voluntarily limit the scope of this application to any single disclosure or inventive concept if more than one is, in fact, disclosed.

The embodiments illustrated herein are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed. Other embodiments may be used and derived therefrom, such that structural and logical substitutions and changes may be made without departing from the scope of this disclosure. The Detailed Description, therefore, is not to be taken in a limiting sense, and the scope of various embodiments is defined only by the appended claims, along with the full range of equivalents to which such claims are entitled.

As used herein, the term “or” may be construed in either an inclusive or exclusive sense. Moreover, plural instances may be provided for resources, operations, or structures described herein as a single instance. Additionally, boundaries between various resources, operations, modules, engines, and data stores are somewhat arbitrary, and particular operations are illustrated in a context of specific illustrative configurations. Other allocations of functionality are envisioned and may fall within a scope of various embodiments of the present disclosure. In general, structures and functionality presented as separate resources in the example configurations may be implemented as a combined structure or resource. Similarly, structures and functionality presented as a single resource may be implemented as separate resources. These and other variations, modifications, additions, and improvements fall within a scope of embodiments of the present disclosure as represented by the appended claims. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.

The foregoing description, for the purpose of explanation, has been described with reference to specific example embodiments. However, the illustrative discussions above are not intended to be exhaustive or to limit the possible example embodiments to the precise forms disclosed. Many modifications and variations are possible in view of the above teachings. The example embodiments were chosen and described in order to best explain the principles involved and their practical applications, to thereby enable others skilled in the art to best utilize the various example embodiments with various modifications as are suited to the particular use contemplated.

It will also be understood that, although the terms “first,” “second,” and so forth may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first contact could be termed a second contact, and, similarly, a second contact could be termed a first contact, without departing from the scope of the present example embodiments. The first contact and the second contact are both contacts, but they are not the same contact.

The terminology used in the description of the example embodiments herein is for the purpose of describing particular example embodiments only and is not intended to be limiting. As used in the description of the example embodiments and the appended examples, the singular forms “a,” “an,” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term “and/or” as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.

As used herein, the term “if” may be construed to mean “when” or “upon” or “in response to determining” or “in response to detecting,” depending on the context. Similarly, the phrase “if it is determined” or “if [a stated condition or event] is detected” may be construed to mean “upon determining” or “in response to determining” or “upon detecting [the stated condition or event]” or “in response to detecting [the stated condition or event],” depending on the context.

Claims

1. A method for dynamically managing access priority of virtual machine, VM, tenants to a service or host, characterized in that, the method comprising the steps of: identifying any of the VM tenants having requested for a same service or host thereby assigning the any of the VM tenants to one or more VM tenant groups (100); establishing a metric hierarchy for the VM tenants and the one or more VM tenant groups thereof (200), wherein the metric hierarchy comprises parameters selected from a group comprising a tenant type determined based on a database capacity, a host memory, a resource network access and a security assigned thereto, a host and a virtual network; establishing a threshold attribute framework as an alternative determinator to the metric hierarchy thereof (300), wherein the threshold attribute framework comprises attributes selected from a group comprising a cloud service, a database service and a web management; and determining a service priority level for each of the VM tenants and the one or more VM tenant groups based on the metric hierarchy or the threshold attribute framework established thereof (400).

2. The method according to Claim 1 further comprises the step of collecting historical data associated with the VM tenants, the host, the virtual network and the service or host in prior request to develop a historical profile for each of the VM tenants.

3. The method according to Claim 1 , wherein the step of establishing a metric hierarchy (200) comprises the step of comparing the tenant type and network resources requested by the VM tenants thereof to establish an inference statement that is incorporated in the metric hierarchy thereof.

4. The method according to Claim 1 , wherein the tenant type indicates a tenant’s payment type which correspondingly suggests to the database capacity, the host memory, the resource network access and the security.

5. The method according to Claim 1 , wherein the threshold attribute framework is utilized to prioritize the VM tenants if the metric hierarchy is not available.

6. A system for dynamically managing access priority of virtual machine, VM, tenants to a service or host, characterized in that, the system comprising: a first processing engine configured for identifying any of the VM tenants having requested for a same service or host, wherein the first processing engine assigns the any of the VM tenants to one or more VM tenant groups; a second processing engine configured for establishing a metric hierarchy for the VM tenants and the one or more VM tenant groups thereof, wherein the metric hierarchy comprises parameters selected from a group comprising a tenant type determined based on a database capacity, a host memory, a resource network access and a security assigned thereto, a host and a virtual network; a third processing engine configured for establishing a threshold attribute framework as an alternative determinator to the metric hierarchy thereof, wherein the threshold attribute framework comprises attributes selected from a group comprising a cloud service, a database service and a web management; and a fourth processing engine configured for determining a service priority level for each of the VM tenants and the one or more VM tenant groups based on the metric hierarchy or the threshold attribute framework established thereof.

7. The system according to Claim 6 further comprises a data collection module configured for collecting historical data associated with the VM tenants, the host, the virtual network and the service or host in prior request to develop a historical profile for each of the VM tenants.

8. The system according to Claim 6, wherein the second processing engine comprises an inference engine configured for comparing the tenant type and network resources requested by the VM tenants thereof to establish an inference statement for incorporation into the metric hierarchy thereof.

9. The system according to Claim 6, wherein the tenant type indicates a tenant’s payment type which correspondingly suggests to the database capacity, the host memory, the resource network access and the security.

10. The system according to Claim 6, wherein the threshold attribute framework is utilized to prioritize the VM tenants if the metric hierarchy is not available.