Patent Description:
Application management servers may also serve as deployment engines. That is, once an application has been modeled, the modeling platform provides a means of deploying the application (and all virtual machines modeled therein) to a cloud computing environment. However, once a virtual machine is physically deployed to a cloud, the deployed virtual machine is typically unavailable to the application management server. To facilitiate integration between the modeling/deployment platform and applications deployed in the cloud, it has become useful to logically group and identify one or more of the virtual machines deployed to a cloud infrastructure using a single application identifier. As an example, while a cloud-based application is being deployed, it is convenient to retrieve information for all deployed virtual machines simultaneously using a single identifier, rather than access a multitude (perhaps thousands) of virtual machines individually.

Further, it is also convenient to refer to each individual virtual machine deployed in a cloud by the application management server. This enables an application designer to change an application model of a previously deployed application, and to deploy the changes to the virtual machines already executing in the cloud. In addition, when a virtual machine of the cloud application is scaled up or down by a cloud system administraor (who typically acts independently of an application designer), the virtual machine being scaled is usually deleted and recreated with newly scaled system parameters. Requiring the application management server to track the newly scaled virtual machine would be burdensome. On the other hand, providing the application management server with a means of referring to deployed virtual machines with a more abstract (and independent) identifier alleviates this burden.

<CIT> describes a virtual machine system which has a processor operating as a base machine and a plurality of groups of registers. A status register file is provided to effect selective access to a respective one of a plurality of status registers in the system in accordance with a virtual machine number. <CIT> describes a mechanism for system resource sharing in a multi-tenant platform as a service environment in a cloud computing system. <CIT> describes a method for switching a multi virtual machine including supplying a list for applications installed in several virtual machines to a user. <CIT> describes a system including plural physical machines containing virtual machines with migration being performed between or among the physical machines in a first group of the physical machines. <CIT> describes a method of provisioning composite applications using a plurality of virtual machines including using component identifiers, application identifiers and virtual machine identifiers.

According to the present invention there is provided a method as set forth in claim <NUM>. Also there is provided a medium as in claim <NUM> and a system as in claim <NUM>. Additional features of the invention will be appreciated from the dependent claims and the discussion herein.

One or more embodiments provide two identifiers for a virtual machine that is deployed to a cloud computing envrionment using an application management server. A first identifier identifies the application that the virtual machine is a part of, and which is useful when all virtual machines of the application need to be accessed by the application management server. Further, a second identifier individually identifies the virtual machine, and is useful when only a particular virtual machine, or limited set of deployed virtual machines, needs to be accessed by the application management server.

A method of deploying an application that is executed in a plurality of virtual machines in a cloud computing environment, according to embodiments, includes the steps of generating an application identifier and generating a first virtual machine identifier for a first virtual machine. The method further comprises the steps of instantiating the first virtual machine in the cloud computing environment and generating a second virtual machine identifier for the first virtual machine. The method further comprises the step of creating an association among the application identifier, the first virtual machine identifier, and the second virtual machine identifier.

Further embodiments provide a non-transitory computer-readable medium that includes instructions that, when executed, enable a plurality of host computers to implement one or more aspects of the above method.

Further embodiments also provide a virtualized computing system that is configured to implement one or more aspects of the above method.

<FIG> is a block diagram of components of a virtualized cloud computing environment in which one or more embodiments may be implemented. Virtualized cloud computing environments typically comprise one or more platforms that support the creation, deployment, and management of virtual machine-based cloud applications. One such platform is the vCloud® Automation Center (or vCAC), which is commercially available from VMware, Inc. of Palo Alto, California. <FIG> depicts vCAC <NUM> as an application deployment platform in the cloud computing environment shown. While vCAC <NUM> is illustrated in the environment depicted in <FIG>, it should be noted that any computing platform that supports the creation and deployment of virtualized cloud application is within the scope of the present invention.

As shown in <FIG>, vCAC <NUM> includes two components. First, vCAC includes application management server <NUM>. In one or more embodiments, application management server <NUM> comprises one or more computer-based processes that implement an application provisioning platform that supports the creation and deployment of applications in cloud computing environments. An end user of application management server <NUM> (referred to in <FIG> as management user <NUM>) defines the structure and topology of a cloud-based application. Among the components of a cloud-based application that management user <NUM> creates and interconnects are virtual machines that run the various software components of the cloud-based application. For example, management user <NUM> may wish to define a cloud-based data storage application. In such a case, management user <NUM> accesses application management server <NUM> to model and create the data storage application. As an example, the data storage application in question may be defined as a "three-tiered" application, which includes a component that is responsible for storing data, a component that is responsible for providing data security, and a component for publishing data for viewing in a web-based application. Such an application may be modeled in application management server <NUM> as comprising a separate virtual machine (or virtual server) for each of the aforementioned components. Once management user <NUM> has completed modeling a cloud-based application, application management server <NUM> generates an application blueprint (not shown) for the modeled application. In addition, an application deployment plan (not shown) is saved in application management server <NUM>, where the application deployment plan is executed once the application is selected for deployment to a cloud infrastructure.

<FIG> also depicts vCAC <NUM> as including a component that enables the provisioning of virtualized infrastructure components in a cloud-based computing environment. To accomplish this, IaaS <NUM> is a software component that enables the selection of virtual hardware elements to be deployed along with a cloud-based application. That is, IaaS <NUM> contains templates for various types of virtual devices (such as virtual servers), which may be instantiated in a cloud. For example, IaaS <NUM> may have configured and stored templates for virtual machines with certain processing, memory, and storage capacities. Thus, in a particular embodiment, IaaS <NUM> may have stored therein a template for a first type of virtual server with <NUM> Gigabytes (GB) of random access memory (RAM), and a template for a second type of virtual server with <NUM> GB of RAM.

As shown, IaaS <NUM> communicates directly with application management server <NUM>. When a virtualized application is to be deployed to a cloud, the application typically requires virtual hardware devices (e.g., virtual machines) on which application and system software is to be installed and in which the application executes. In one or more embodiments, application management server <NUM> (under the direction of management user <NUM>) selects virtual machine types from the templates provided by IaaS <NUM>, where each virtual machine defined in the modeling phase of the application corresponds to a type of virtual machine template that is made available by IaaS <NUM>. Thus, using the example of the data storage application mentioned above, management user <NUM> may determine that the data storage application component is to run on a <NUM> GB RAM virtual machine, but that the data security and data publishing components may each run on a <NUM> GB RAM virtual machine. In such a case, when the data storage application is deployed, application management server <NUM> communicates with IaaS <NUM> in order to select the appropriate virtual machine type for each of the virtual machines modeled as part of the virtualized application.

In embodiments, IaaS <NUM> communicates directly with a cloud computing platform (or a cloud "provider"). Cloud computing platforms typically include the computing resources required to support the execution of cloud-based applications. Thus, the infrastructure in a cloud computing platform typically includes virtual and physical computing hardware, along with application and system software. Some cloud infrastructure platforms (i.e. platforms that support multiple cloud-based applications) include mechanisms that allow for the balancing and reallocation of virtual and physical hardware resources based on application demand.

As shown in <FIG>, IaaS <NUM> communicates with VM management server <NUM>, which is an example of system software that implements a cloud-based computing platform. In one embodiment, VM management server <NUM> may comprise the vCenter Server™ and vSphere® program products, which are commercially available from VMware, Inc. In the embodiment shown in <FIG>, VM management server <NUM> comprises one or more computer-based processes that support the instantiation and execution of multiple virtual machines (VMs). Thus, in the figure, VMs <NUM><NUM>-<NUM>n are depicted as instantiated in VM management server <NUM>. Further, each of VMs <NUM><NUM>-<NUM>n is shown as being a part of application <NUM>. Application <NUM> is an example of a "tiered" virtualized application as previously mentioned. Thus, each VM <NUM> in application <NUM> corresponds to a particular component of a corresponding application that is defined in application management server <NUM>. Again referring to the cloud-based data storage application, management user <NUM> defines and models the application using application management server <NUM>, deploys the application using application management server <NUM> in conjunction with IaaS <NUM>, and the application is instantiated in a cloud environment (i.e. VM management server <NUM>) by IaaS <NUM> communicating a deployment request to VM management server <NUM>. It should be noted that the actual instantiation of VMs <NUM> in the cloud is performed by VM management server <NUM> at the request of IaaS <NUM>. Further, it will be described in more detail below how VMs <NUM> are associated as part of a single application <NUM>.

Once a cloud-based application is deployed to VM management server <NUM>, the application may be accessed and used by an application user <NUM>. As shown in <FIG>, application user <NUM> accesses application <NUM> through network <NUM>, which is, in turn, connected to VM management server <NUM>. In embodiments, VM management server <NUM> (the cloud "provider") makes available a particular application deployed therein by accepting web requests for the application over a distinct Uniform Resource Locator (URL).

It should also be noted that, in some embodiments, application management server <NUM> may be configured to communicate directly with certain cloud infrastructures (e.g., public clouds), such as Amazon Web Services or Microsoft. This communication is depicted by the connection between application <NUM> and cloud <NUM>. Thus, in some embodiments, application management server <NUM> may be configured to deploy applications directly to public cloud providers, utilizing the infrastructure services provided by those cloud providers.

Further, although the embodiment of <FIG> depicts vCAC <NUM> and VM management server <NUM> as running on separate host computers (i.e., separate physical servers), it should be noted that some or all of the functionality of VM management server <NUM> may be performed by modules residing on the same host computer as vCAC <NUM>. In such embodiments, these modules are configured to perform certain virtual machine management functions that are typically performed by VM management server <NUM> (e.g., balancing workloads between virtual machines within a cloud computing environment or between several cloud computing environments). Still other embodiments of vCAC <NUM> include modules that are configured to instantiate virtual machines in a cloud computing environment. Indeed, the combined functionality of vCAC <NUM> and VM management server <NUM> (as depicted in <FIG>) may be implemented either in a single host computer or distributed among several host computers.

When a cloud-based application is modeled and deployed to a cloud using application management server <NUM> and IaaS <NUM>, it is desirable for a management user <NUM> connected to application management server <NUM> to be able to access the deployed virtual machines by referring to the deployed virtual machines according to how the virtual machines are identified in application management server <NUM>. For example, during a deployment operation of a cloud-based application comprising <NUM> virtual machines, management user <NUM> may wish to check the status of one or all of the <NUM> virtual machines as the virtual machines are referred to in application management server <NUM>. Thus, in some embodiments, management user <NUM> may transmit a query to IaaS <NUM> and to VM management server <NUM>, requesting a listing of all virtual machines being deployed for a particular application. The response to such an inquiry would be helpful in determining the progress of the deployment of the cloud-based application, and whether any deployment failures have occurred within VM management server <NUM>. In other cases, management user <NUM> may transmit a query to determine the status of one particular virtual machine that is a component of a cloud-based application currently under deployment. The response to such an inquiry would be helpful in determining whether or not the particular virtual machine being queried may be instantiated or may have certain application or system software installed on it.

<FIG> is a block diagram that illustrates the generation and association of identifiers for a virtual machine that is configured within a cloud-based application, according to one or more embodiments. As shown in <FIG>, application management server <NUM> has modeled therein one single VM cloud-based application. The modeling of the application is performed by management user <NUM> accessing application management server <NUM> (as was shown in <FIG>). Among the elements that application management server <NUM> generates and stores when a cloud-based application is modeled and deployed are specific identifiers that pertain to the cloud-based application as a whole, and to individual virtual machines that are included in the cloud-based application. In embodiments, this metadata for the cloud-based application is stored within a data structure, such as table <NUM> illustrated in <FIG>. Alternatively, the metadata is stored in a file system that is accessible to application management server <NUM>.

When management user <NUM> models, saves, and deploys a cloud-based application using application management server <NUM>, application management server <NUM> generates unique identifiers. For the embodiment illustrated in <FIG>, application management server <NUM> generates a unique application ID (referred to in the example depicted in <FIG> as AppID1), which is an identifier for the application as a whole. For example, if management user <NUM> models a database application that is to run and access an Oracle database, then application management server <NUM> generates a single application ID (e.g., AppID1) that corresponds to that database application. Thus, using application management server <NUM>, a management user would be able to refer to or query any element of the database application using the generated application ID.

In addition, when management user <NUM> models, saves, and deploys a cloud-based application using application management server <NUM>, application management server <NUM> generates a unique identifier for each virtual machine that is a component of the cloud-based application. Referring to <FIG>, this unique identifier is identified as VM ID1. In the example illustrated in <FIG>, a single VM ID1 (i.e., VMID1_a) is generated for the cloud-based application identified by AppID1. Thus, the cloud-based application identified by AppID1 is a single-VM application, wherein the single VM defined for the application is identified in application management server <NUM> by VMID1_a. For example, management user <NUM> may model a single-VM cloud-based database application, where the virtual machine is configured to run the Oracle database software as well as user defined application software. The database application as a whole is referred to by its unique application ID (i.e., AppID1), while only the virtual machine that is a part of the database application is referred to by its unique VM ID1 (i.e., VMID1_a). Thus, if management user <NUM> wishes to retrieve (using application management server <NUM>) the status of all components of the application depicted in <FIG> (e.g., the virtual machine and any other virtual hardware elements, such as virtual switches and disks), management user <NUM> formulates and transmits a query from application management server <NUM> to the cloud, referring to AppID1. If management <NUM> user wishes to retrieve (using application management server <NUM>) the deployment status of only the single virtual machine in the application depicted in <FIG>, management user <NUM> formulates and transmits a query from application management server <NUM> to the cloud, referring to VMID1_a.

As shown in <FIG>, application management server <NUM> communicates directly with IaaS <NUM>. IaaS <NUM>, in turn, communicates directly with VM management server <NUM>. As previously mentioned, IaaS <NUM> provides a selection of predefined virtual machine types (or templates) that management user <NUM> may associate with the virtual machines modeled in application management server <NUM>. When management user <NUM> deploys an application, application management server <NUM> transmits a deployment request to IaaS <NUM>. IaaS <NUM>, in embodiments, transmits one or more requests to VM management server <NUM> in order to instantiate the requested virtual machines. Thus, in the example illustrated in <FIG>, application management server <NUM> transmits a request to deploy the cloud-based application having an application ID, AppID1, and associated with a virtual machine having a VM ID1 identifier, VMID1_a, to IaaS <NUM>. In one or more embodiments, IaaS <NUM> receives the deployment request (which includes the application ID and the VM ID1 identifier), and transmits a request to VM management server <NUM> to instantiate the required virtual machine. As shown in <FIG>, IaaS <NUM> stores the application ID, AppID1, and the VM ID1 identifier, VMID1_a, as associated items in a data structure (e.g., table <NUM>). In addition, table <NUM> in IaaS <NUM> includes another column so that AppID1 and VMID1_a can be associated with another yet to be identified VM.

As shown in the lower part of <FIG>, VM management server <NUM> receives virtual machine instantiation requests from IaaS <NUM> and, in response thereto, instantiates virtual machines within the cloud. As shown in the figure, VM <NUM> is instantiated in response to a request received from IaaS <NUM>, which corresponds to the request IaaS <NUM> receives from application management server <NUM>. In the embodiment illustrated, VM <NUM> also contains metadata, which is either stored in virtual memory or on a virtual storage device that is configured as a part of VM <NUM>. The metadata includes AppID1 and VMID1_a, which, as was mentioned previously, are the identifiers generated by application management server <NUM> when a cloud-based application is modeled therein. Additionally, VM <NUM> also includes an additional identifier, VMID2_a. VMID2_a is a unique virtual machine identifier (referred to generally as VM ID2) that is generated by VM management server <NUM> when a virtual machine is instantiated therein. VM ID2 may be stored in the instantiated virtual machine. Alternatively, VM ID2 may be stored external to the virtual machine while being logically associated with the virtual machine. Referring to <FIG>, since VMID2_a is generated independently from AppID1 and VMID1_a, there remains the task to associate the identifiers generated by application management server <NUM> (i.e., AppID1 and VMID1_a) with the identifier generated by VM management server <NUM> (i.e., VMID2_a).

In the embodiment illustrated in <FIG>, once VM management server <NUM> instantiates VM <NUM> and generates VMID2_a, VM management server <NUM> transmits VMID2_a to IaaS <NUM>. When IaaS <NUM> receives VMID2_a from VM management server <NUM>, IaaS <NUM> stores VMID2_a in table <NUM> in a way so as to associate AppID1 and VMID1_a with VMID2_a. This storing of VMID2_a is illustrated conceptually in <FIG> by arrow <NUM> extending from VMID2_a within VM <NUM> to the null data field in table <NUM> within IaaS <NUM>. Once VMID2_a is stored in table <NUM> of IaaS <NUM>, then AppID1 and VMID1_a are associated with VMID2_a. Hence, an association is created between the application configured in application management server <NUM> (i.e., the application with application ID AppID1) and the virtual machine instantiated within VM management server <NUM> (i.e., VM <NUM>). This association is illustrated conceptually by showing VM <NUM> as grouped within application <NUM>. It should be noted that application <NUM> serves as a way of identifying a grouping of virtual machines instantiated in VM management server <NUM> within a single application having a single unique application identifier (e.g., AppID1). Thus, in <FIG>, VM <NUM> is grouped into application <NUM>, which logically corresponds to the application modeled in application management server <NUM> identified by AppID1.

<FIG> is a flow diagram that illustrates a method <NUM> of deploying a multi-VM cloud-based application, according to one or more embodiments. For purposes of illustration, <FIG> is described in conjunction with the block diagram of <FIG>. As shown, method <NUM> begins at step <NUM>, where an application with one or more VMs is modeled. As previously mentioned, this is typically accomplished by a management user using application management server <NUM>. As an example, in <FIG>, application management server <NUM> has modeled therein a cloud-based application having three separate virtual machines. Referring back to the example of the cloud-based data storage application, the first virtual machine may be a storage server, the second virtual machine may be a security server, and the third virtual machine may be a publishing server.

Referring to <FIG>, once the cloud-based application is modeled at step <NUM>, method <NUM> proceeds to step <NUM>. At step <NUM>, application management server <NUM> receives a request to deploy the modeled application to a cloud infrastructure. In response to receiving the deployment request at step <NUM>, application management server <NUM> generates, at step <NUM>, a unique application ID that corresponds to the modeled application. With reference to <FIG>, AppID1 (which is stored in table <NUM> within application management server <NUM>) corresponds to the modeled application.

Once the unique application ID has been generated, method <NUM> proceeds to step <NUM>. At step <NUM>, a unique VM ID1 is generated for a next virtual machine that is modeled within the cloud-based application. In the example depicted in <FIG>, a three-VM cloud based application is modeled in application management server <NUM>. Hence, at step <NUM>, VMID1_a is generated and stored for the first of the three virtual machines.

In the present embodiment, method <NUM> then proceeds to step <NUM>, where the virtual machine whose VM ID1 has been generated at step <NUM> is deployed to (or instantiated in) the cloud. In embodiments, deployment of a VM to the cloud comprises transmitting a deployment request for the VM from application management server <NUM> to IaaS <NUM>. The deployment request includes the generated application ID and VM ID1 (e.g., AppID1 and VMID1_a, from <FIG>). IaaS <NUM> then transmits a further request to the cloud infrastructure (e.g., to VM management server <NUM>) to instantiate a VM corresponding to the deployment request. As shown in <FIG>, IaaS <NUM> receives a deployment request for the first VM modeled in application management server <NUM> (i.e., the VM identified by VMID1_a). IaaS <NUM> stores AppID1 and VMID1_a in table <NUM>, and transmits an instantiation request to VM management server <NUM> corresponding to the VM identified in application management server <NUM> by VMID1_a. VM management server <NUM> then instantiates a first virtual machine (i.e., VM <NUM><NUM>). As shown in <FIG>, VM <NUM><NUM> stores metadata that includes AppID1 and VMID1_a. In addition, as a result of the instantiation of VM <NUM><NUM>, VM management server <NUM> generates VMID2_a, which is stored in (or is logically associated with) VM <NUM><NUM>.

Once the next VM modeled in the application is deployed to the cloud (i.e., instantiated in the cloud), method <NUM> proceeds to step <NUM>. At step <NUM>, the generated VM ID2, which, as previously mentioned, is generated by the cloud (e.g., VM management server <NUM>) when the cloud instantiates a VM, is received by IaaS <NUM> from the cloud. Thus, with reference to <FIG>, at step <NUM>, VM management server <NUM> transmits VMID2_a (which VM management server <NUM> generates at step <NUM>) to IaaS <NUM>.

At step <NUM>, IaaS <NUM> associates VMID2_a received at step <NUM> with application ID AppID1 and VM ID1 VMID1_a, which are generated, respectively, in steps <NUM> and <NUM>. Thus, as shown in <FIG>, IaaS <NUM> receives VMID2_a from VM management server <NUM> and stores it in the entry of table <NUM> that contains AppID1 and VMID1_a. Thus, in this way, an association is established between AppID1 and VMID1_a (which uniquely identify, from the perspective of application management server <NUM>, the first modeled virtual machine) with VM <NUM><NUM> (which is the corresponding virtual machine instantiated within VM management server <NUM>).

At step <NUM>, method <NUM> determines whether there are more VMs modeled as part of the cloud-based application in application management server <NUM>. If there are more VMs, then method <NUM> proceeds back to step <NUM>, where a next VM ID1 is generated for the next VM. Thus, referring to <FIG>, VMID1_b is generated for the second VM. Method <NUM> then proceeds through steps <NUM>-<NUM> to deploy the second VM to the cloud and to associate the deployed second VM with the second VM as modeled in application management server <NUM>. As shown in <FIG>, VM management server <NUM> instantiates VM <NUM><NUM> and generates VMID2_b. AppID1 and VMID1_b are then associated with VMID2_b in the second entry of table <NUM>. It should be noted that method <NUM> proceeds through steps <NUM>-<NUM> in like manner for the third virtual machine modeled in application management server <NUM> (i.e., the virtual machine identified by VMID1_c).

If, at step <NUM>, method <NUM> determines that there are no more VMs modeled as part of the cloud-based application in application management server <NUM>, then all application VMs are deployed and method <NUM> terminates.

As was previously mentioned, it is useful to associate the identifier for a virtual machine as generated by application management server <NUM> (i.e., the Application ID and/or VM ID1) with the identifier generated by VM management server <NUM> for the same virtual machine when the virtual machine is deployed to the cloud (i.e., VM ID2). One benefit is the ability to track the progress of deployment of virtual machines directly from application management server <NUM>. Another benefit is the ability to access an already-deployed virtual machine at a time well after its deployment in order to update or install new software on the virtual machine. However, when a virtual machine is scaled up or scaled down by a system administrator, the association between the Application ID and VM ID1 (as generated by application management server <NUM>) with VM ID2 (as generated by VM management server <NUM>) may be broken.

After a virtual machine is deployed to a cloud infrastructure (such as VM management server <NUM>), a system administrator may perform "scaling" on the virtual machine. Scaling a virtual machine refers to dynamically changing system parameters (such as the amount of available RAM, the number of available CPUs, and the like) of the virtual machine. A virtual machine may be scaled up or down using system administration tools that are operated independently of application management server <NUM>. For example, a system administrator may perform administration tasks on cloud-based virtual machines using the VSphere suite of administration tools, which is commercially available from VMware, Inc. Typically, scaling a cloud-based virtual machine entails allocating a new virtual machine in the cloud with the required scaled up (or scaled down) parameters, copying the runtime state and data of the existing virtual machine to the newly scaled virtual machine, instantiating and starting the newly scaled virtual machine, and destroying (or deallocating) the previously existing virtual machine. In this way, the newly scaled virtual machine replaces the previously existing virtual machine.

However, if the previously existing virtual machine had been deployed to the cloud through application management server <NUM>, then the association between the identifiers generated by application management server <NUM> (Application ID and VM ID1) and the identifier generated by VM management server <NUM> (VM ID2) is broken. The reason for this is due to the fact that when VM management server <NUM> creates the newly scaled virtual machine, a new VM ID2 is generated in the process. It should be noted that the VM ID2 of the previously existing virtual machine is not copied to or associated with the newly scaled virtual machine. In addition, once the newly scaled virtual machine is started, the previously existing virtual machine is destroyed, along with the metadata for that virtual machine. Thus, the VM ID2 of the previously existing virtual machine no longer refers to an existing virtual machine.

Nonetheless, the application ID and VM ID1 of the previously existing virtual machine is stored persistently, in embodiments, in table <NUM> of IaaS <NUM>, as well as in table <NUM> of application management server <NUM>. Thus, application management server <NUM> maintains a unique handle to the applications and corresponding virtual machines that have been previously modeled and deployed. Therefore, it is possible to establish an association between the Application ID and VM ID1 of the virtual machines modeled in application management server <NUM> after such virtual machines are scaled up or down independently of application management server <NUM> (for example, when those virtual machines are newly scaled using VSphere administration tools).

<FIG> is a flow diagram of a method <NUM> of scaling up a virtual machine in a cloud-based computing environment, according to one or more embodiments. <FIG> will be described in conjunction with <FIG>, which is a block diagram that illustrates conceptually the scaling up of a virtual machine in a cloud-based computing environment. As shown in <FIG>, VM <NUM><NUM> is a virtual machine instantiated in VM management server <NUM> as a result of a previous deployment of an application (identified in application management server <NUM> and IaaS <NUM> by application ID AppID1) with one virtual machine (identified in application management server <NUM> and IaaS <NUM> by VM ID1 VMID1_a). At the time VM management server <NUM> instantiates VM <NUM><NUM>, VM management server <NUM> generates VMID2_a and associates this identifier with VM <NUM><NUM>. Method <NUM> begins at step <NUM>, where a request to scale up a virtual machine is received. As shown in <FIG>, scaling request <NUM> is received by VM cloud administrator <NUM>. VM cloud administrator <NUM> may, in embodiments, comprise the vSphere® suite of administration tools available from VMware, Inc. In embodiments, request <NUM> is transmitted to VM cloud administrator <NUM> by a system administrator through, for example, a system console.

Method <NUM> then proceeds to step <NUM>, where, in response to the scaling request, a newly scaled up virtual machine is instantiated in the cloud. This is illustrated in <FIG> by the creation (by VM cloud administrator <NUM> communicating with VM management server <NUM>) of a new virtual machine VM <NUM><NUM>. In embodiments, VM <NUM><NUM> is created with scaled up system parameters in relation to previously instantiated and deployed VM <NUM><NUM>. The dotted outline of VM <NUM><NUM> denotes that VM <NUM><NUM> is newly created. It should be noted that when VM <NUM><NUM> is created, VM management server <NUM> generates VMID2_b, which is different from VMID2_a of VM <NUM><NUM>.

Next, at step <NUM>, the data of VM <NUM><NUM> is copied to VM <NUM><NUM>. As shown in <FIG>, this includes the metadata items AppID1 and VMID1_a. However, VMID2_a is not copied to or associated with VM <NUM><NUM>.

Once the data (and metadata) of VM <NUM><NUM> are copied to VM <NUM><NUM>, method <NUM> proceeds to step <NUM>. At step <NUM>, the application ID and VM ID1 of the previously existing virtual machine are associated with VM ID2 of the newly scaled up VM. With reference to the embodiment illustrated in <FIG>, this association is performed via VM management server <NUM> communicating VMID2_b to IaaS <NUM>. In response, IaaS <NUM> (which, prior to the scaling up of VM <NUM><NUM>, stored AppID1, VMID1_a, and VMID2_a as associated data elements in table <NUM>), stores VMID2_bin the entry of table <NUM> corresponding to AppID1 and VMID1_a. This is shown conceptually in <FIG> by arrow <NUM>. In addition, VM <NUM><NUM> is depicted in <FIG> as being grouped within VM management server <NUM> as part of application <NUM>, which, as previously mentioned, corresponds to the application identified in application management server <NUM> by AppID1.

Once the application ID and VM ID1 of the previously existing virtual machine (e.g., AppID1 and VMlD1_a in <FIG>) is associated with the VM ID2 of the newly scaled virtual machine (e.g., VMID2_b in <FIG>), method <NUM> proceeds to step <NUM>, where the previously existing virtual machine (i.e., VM <NUM><NUM>) is deallocated. After step <NUM>, method <NUM> terminates.

In addition to scaling up (or down) an individual virtual machine within a cloud-based application, cloud-based applications may be "scaled in" or "scaled out. " Scaling in a cloud-based application refers to removing some virtual machines from the application while continuing to execute the application within the cloud. Scaling out a cloud-based application refers to adding virtual machines to the application while the application executes in the cloud. While scaling up and scaling down a virtual machine is typically performed by accessing a system administration tool that is independent of application management server <NUM> (such as VM cloud administrator <NUM>), scaling a cloud-based application either in or out is performed by a management user (such as management user <NUM> of <FIG>) that accesses application management server <NUM>.

<FIG> is a flow diagram that illustrates a method <NUM> for scaling out a virtualized cloud-based application, according to one or more embodiments. <FIG> is described herein in conjunction with <FIG>, which is a block diagram that depicts the scaling out of a single-VM cloud-based application to a dual-VM cloud-based application. Referring to <FIG>, management user <NUM> accesses application management server <NUM>, which has modeled therein a single-VM application previously deployed to VM management server <NUM>. The deployed application is identified by application ID AppID1 and the first VM is identified by VMID1_a. As shown in <FIG>, table <NUM> of IaaS <NUM> associates AppID1 and VMID1_a with VMID2_a, which is the VM ID2 of previously deployed virtual machine VM <NUM><NUM>.

Method <NUM> begins at step <NUM>, where application management server <NUM> receives a request to scale out the application identified in <FIG> by AppID1. In the embodiment illustrated, the scale out request is for the addition of one virtual machine to the cloud-based application. However, any number of virtual machines may be added in a single request. Further, as previously mentioned, such a request is received, in embodiments, from management user <NUM>.

Next, at step <NUM>, application management server <NUM> generates a new VM ID1 for the newly requested virtual machine. As shown in <FIG>, application management server <NUM> generates VMID1_b for the new virtual machine, which corresponds to AppID1. At step <NUM>, the new virtual machine is deployed to the cloud. As was previously mentioned with respect to <FIG>, in one or more embodiments, application management server <NUM> transmits a deployment request for a virtual machine to IaaS <NUM>, which, in turn, transmits a request to VM management server <NUM> (i.e., the cloud infrastructure). Referring to <FIG>, after application management server <NUM> transmits the deployment request for the second virtual machine (i.e., the virtual machine identified by VMID1_b) to IaaS <NUM>, IaaS <NUM> stores AppID1 and VMID1_b as associated data elements in table <NUM>. In addition, IaaS <NUM> transmits a request to VM management server <NUM> to instantiate the new virtual machine the cloud.

In response to the request from IaaS <NUM>, VM management server <NUM> instantiates VM <NUM><NUM>, generating VMID2_b in the process. Note that AppID1 and VMID1_b are included in the metadata of newly instantiated VM <NUM><NUM>.

Once the second virtual machine (i.e., VM <NUM><NUM>) is instantiated in the cloud, method <NUM> proceeds to step <NUM>. At step <NUM>, IaaS <NUM> receives from VM management server <NUM> VMID2_b of newly instantiated VM <NUM><NUM>. Finally, at step <NUM>, IaaS <NUM> associates AppID1 and VMID1_b (which are both generated by application management server <NUM>) with VMID2_b (which is generated by VM management server <NUM>). Referring to <FIG>, IaaS <NUM> makes this association by storing VMID2_b in the entry of table <NUM> that associates AppID1 with VMID1_b. Thus, once the association is made at step <NUM>, management user <NUM> may access VM <NUM><NUM> from application management server <NUM>. This is useful should management user <NUM> wish to install software on VM <NUM><NUM> from application management server <NUM> at a later point in time.

The various embodiments described herein may employ various computer-implemented operations involving data stored in computer systems. For example, these operations may require physical manipulation of physical quantities-usually, though not necessarily, these quantities may take the form of electrical or magnetic signals, where they or representations of them are capable of being stored, transferred, combined, compared, or otherwise manipulated. Further, such manipulations are often referred to in terms, such as producing, yielding, identifying, determining, or comparing. Any operations described herein that form part of one or more embodiments of the disclosure may be useful machine operations. In addition, one or more embodiments of the disclosure also relate to a device or an apparatus for performing these operations. The apparatus may be specially constructed for specific required purposes, or it may be a general purpose computer selectively activated or configured by a computer program stored in the computer. In particular, various general purpose machines may be used with computer programs written in accordance with the teachings herein, or it may be more convenient to construct a more specialized apparatus to perform the required operations.

The various embodiments described herein may be practiced with other computer system configurations including hand-held devices, microprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframe computers, and the like.

One or more embodiments of the present disclosure may be implemented as one or more computer programs or as one or more computer program modules embodied in one or more computer readable media. The term computer readable medium refers to any data storage device that can store data which can thereafter be input to a computer system-computer readable media may be based on any existing or subsequently developed technology for embodying computer programs in a manner that enables them to be read by a computer. Examples of a computer readable medium include a hard drive, network attached storage (NAS), read-only memory, random-access memory (e.g., a flash memory device), a CD (Compact Discs) --CD-ROM, a CD-R, or a CD-RW, a DVD (Digital Versatile Disc), a magnetic tape, and other optical and non-optical data storage devices. The computer readable medium can also be distributed over a network coupled computer system so that the computer readable code is stored and executed in a distributed fashion.

Although one or more embodiments of the present disclosure have been described in some detail for clarity of understanding, it will be apparent that certain changes and modifications may be made within the scope of the claims. Accordingly, the described embodiments are to be considered as illustrative and not restrictive, and the scope of the claims is not to be limited to details given herein, but may be modified within the scope of the claims. In the claims, elements and/or steps do not imply any particular order of operation, unless explicitly stated in the claims.

Claim 1:
A method of deploying, by a virtualised computing system comprising a virtual machine management server (<NUM>) and an application management server (<NUM>), an application (<NUM>) to a cloud computing environment (<NUM>) comprising a plurality of virtual machines (<NUM><NUM>-<NUM>n) managed by the virtual machine management server (<NUM>), the application (<NUM>) being executed using a plurality of the virtual machines (<NUM><NUM>-<NUM>n) including a first virtual machine (<NUM><NUM>), the method comprising:
by the application management server (<NUM>) in which the application (<NUM>) is modeled prior to deployment:
generating a unique application identifier (AppID1) which is an identifier for the application (<NUM>) as a whole;
generating a first unique virtual machine identifier (VMID1) for the first virtual machine (140i) wherein the first unique virtual machine identifier (VMID1) identifies the first virtual machine (<NUM><NUM>) as being a part of the application (<NUM>);
sending instructions to the virtual machine management server (<NUM>) to deploy the application (<NUM>);
by the virtual machine management server (<NUM>):
receiving the instructions to deploy the application (<NUM>);
instantiating the first virtual machine (<NUM><NUM>) within the virtual machine management server (<NUM>);
generating a second unique virtual machine identifier (VMID2) independently from the unique application identifier (AppID1) and the first unique virtual machine identifier (VMID1) when, responsive to a virtual machine instantiation request, the first virtual machine (<NUM><NUM>) is instantiated within the virtual machine management server (<NUM>); and
creating an association among the unique application identifier (AppID1), the first unique virtual machine identifier (VMID1), and the second unique virtual machine identifier (VMID2) thereby creating an association between the application (<NUM>) configured in the application management server (<NUM>) and the first virtual machine (<NUM><NUM>) instantiated within the virtual machine management server (<NUM>);
by the application management server (<NUM>):
accessing the first virtual machine (<NUM><NUM>) by using the second unique virtual machine identifier (VMID2).