Real-time feedback associated with configuring virtual infrastructure objects using tags

An example method may include receiving a first GUI selection of a first management server corresponding to a first cluster of virtual infrastructure objects, receiving a second GUI selection of one or more first virtual infrastructure object tags to be assigned to at least one virtual infrastructure object from the first cluster of virtual infrastructure objects after a creation process of a first policy, wherein the first policy is configured to regulate the at least one virtual infrastructure object from the first cluster of virtual infrastructure objects with the one or more first virtual infrastructure object tags, receiving first real-time feedback associated with the first cluster of virtual infrastructure objects and the one or more first virtual infrastructure object tags from the first management server, and displaying a object count in a first GUI element supported by the configuration client.

BACKGROUND

When creating a group of virtual machines, a common set of virtual machine configurations or services may be deployed to each of the virtual machines in a virtual machine group. However, in some special scenarios, having the same set of virtual machine services for all the virtual machines in the virtual machine group may not be ideal, as some of the virtual machines may need to have specific services deployed (e.g., services to reduce the workload of the virtual machine group) while the other virtual machines may require just certain common services.

In addition, as more and more virtual machines and management servers are deployed, monitoring and configuring all these virtual machines and management servers becomes increasingly difficult and burdensome.

DETAILED DESCRIPTION

FIG.1illustrates a block diagram of an example virtualized computing environment that can be utilized to configure virtual infrastructure objects with tags, according to one or more embodiments of the present disclosure. For clarity, subsequent discussions mainly focus one example of virtual infrastructure objects (e.g., virtual machines or VMs) and their underlying physical resources (e.g., hosts). The methods and systems described below are applicable to other virtual infrastructure objects, such as datastores, and their underlying physical resources, such as disks. Tags assigned to virtual infrastructure objects are referred to as virtual infrastructure object tags.

A virtual machine (VM) configuration client may interact with multiple VM management servers to configure one or more VMs in multiple VM clouds/clusters. To illustrate, VM configuration client110may interact with VM management servers120and122to configure the VMs in VM clouds/clusters140and150. VM configuration client110may support a graphic user interface (GUI), which allows a user (e.g., an administrator) to initiate the creating and configuring of the VMs in particular clouds/clusters by selecting a VM management server and transmitting one or more client instructions to the selected VM management server. For example, VM configuration client110may select VM management server120and transmit client instructions111to VM management server120to interact with VMs130in VM cloud/cluster140. With the selected VM management server120, VM configuration client110may also display up-to-date information on its GUI based on real-time feedback113that it receives from VM management server120. On the other hand, if VM configuration client110selects VM management server122, then it can transmit client instructions115to VM management server122to interact with the VMs in VM cloud/cluster150and display up-to-date information on its GUI based on real-time feedback117that it receives from VM management server122.

In some embodiments, VM configuration client110may be a client software application installed on a client computer (e.g., a personal computer or workstation). VM configuration client110may also be a web-based application operating in a browser environment. VM configuration client110may interact with VM management server120and VM management server122via Transmission Control Protocol/Internet Protocol (TCP/IP), Hypertext Transfer Protocol (HTTP), or any other feasible network communication means. Alternatively, VM configuration client110may be implemented as a software/hardware module executing directly on VM management server120. In some embodiments, VM management server120may be implemented using a VMWARE® vSphere ESXi server, and VM configuration client110may be implemented using a VMWARE® vSphere client.

In some embodiments, VM management server120may be configured to manage VM cloud/cluster140, which includes, among other components, one or more VMs (e.g., VMs130), one or more VM groups (e.g., VM group143), and/or one or more hosts (not explicitly shown inFIG.1). VM cloud/cluster140may support a network-based computing architecture that provides a shared pool of computing resources (e.g., networks, data storages, applications, and services) on demand. VM management server120may implement VM cloud/cluster140based on a virtualized infrastructure, in order to provide provisioning, pooling, high-availability, and automation to these computing resources. Specifically, VM management server120may configure these computing resources using one or more VMs130. VM management server122and VM cloud/cluster150may also be set up in the above discussed manner similar to VM management server120and VM cloud/cluster140, respectively.

In some embodiments, a VM, such as VM130, may be an abstraction of an actual physical computer system. The physical computer system may be based on (e.g., installed on) a physical hardware platform, such as134, which may be referred to as a “host”, a “physical host”, or a “host component” of VM130. VM management server120may include a “hypervisor” to construct virtual hardware platform133based on physical hardware platform134. Virtual hardware platform133may be referred to as a “guest component” of VM130. Thus, physical hardware platform134may include the underlying hardware resources (e.g., processing power, memory, disk and network I/O (input/output)) for virtual hardware platform133, thereby allowing VM130to function as if it were a physical machine.

In some embodiments, physical hardware platform134(e.g., an x86 architecture platform) may be configured with, without limitation, one or more physical Central Processing Unit (CPU), physical memory, physical storage (e.g., hard drive), physical Network Interface Card (NIC), and/or additional electronic circuit components (all of which are not shown inFIG.1). The physical CPU may be a general-purpose or specialized computing processor having electronic circuitry to perform arithmetical, logical, and input/output operations for physical hardware platform134. The physical CPU may be configured to support functions of VM130and/or VM management server120. The physical memory may be hardware storage devices having integrated circuits for storing information used in VM management server120and VMs130. The physical memory may be volatile memory (e.g., dynamic random-access memory (DRAM) or CPU cache memory) or non-volatile memory (e.g., hard drive or flash memory). In some embodiments, the physical memory may be non-transitory computer-readable storage medium, containing a set of instructions which, when executed by the physical CPU, cause the physical CPU to perform methods of creating and configuring VMs130. The NIC may be network communication hardware for transmitting messages in VM cloud/cluster140.

In some embodiments, virtual hardware platform133may be configured with one or more “virtual hardware components”, which are supported by the physical hardware components in physical hardware platform134. In other words, the virtual hardware components, which may include, without limitation, one or more virtual CPUs, virtual memory, virtual storage, virtual NIC, may be configured to emulate the physical hardware components in physical hardware platform134. After VM130is created, guest operating system (OS)132may be installed in VM130to execute and support applications and services such as VM services131. OS132may be a WINDOWS®, UNIX®, LINUX®, or iOS® operating system. VM services131may include any network, storage, image, or application services that can be executed on VM130based on OS132. After VM130is created, it may be used to provide various cloud services in VM cloud/cluster140.

In some embodiments, VM management server120may include VM manager121to manage the creating and configuring of VM cloud/cluster140, as well as the VMs130and VM groups143and145in VM cloud/cluster140. A “VM group” may include multiple hosts and the associated VMs130with shared resources and shared management interfaces. For example, VM cloud/cluster140may be a VMWARE® Distributed Resource Scheduler (DRS) cluster. VM manager121may provide centralized management capabilities, such as VM creation, VM configuration, VM updates, VM cloning, VM high-availability, VM resource distributions, etc. In some embodiments, VM manager121may be a VMWARE® vCenter server.

In some embodiments, VM management server120may include policy manager123for the creating and applying of policies to one or more VMs and VM groups in VM cloud/cluster140. A “policy” may refer to a configuration mechanism to specify how VMs130and hosts in a resource pool (e.g., VM group) should be configured. In some instances, a policy may be an affinity policy, which may correspond to one or more restrictions to be applied to VMs130and hosts during installation and configuration. Further, an affinity policy may be a “positive-affinity” or an “anti-affinity” policy. A positive-affinity policy may dictate that a certain VM130should be installed on a particular host, or multiple VMs130should be installed on a common host. An anti-affinity policy may indicate that multiple VMs130should NOT share a common host and should each be installed onto a different host.

For example, VM group143may be configured with positive-affinity policies. In this case, VM manager121may create and configure the VMs in VM group143together on common or dedicated hosts. VM group145may be configured with anti-affinity policies. In this case, VM manager121may create and configure each of the VMs in VM group145onto a corresponding host that is not shared by any other VMs in VM group145. Thus, the positive-affinity policies and anti-affinity policies may cause VM manager121to keep VMs130either together or separated, in order to reduce traffic across the networks or keep the virtual workload balanced in VM cloud/cluster140.

In some embodiments, policy manager123may apply one or more VM-Host affinity policies to VM group143. A “VM-Host affinity policy” may describe a relationship between a category of VMs and a category of hosts. To place VMs or hosts in categories, they can be assigned with tags (e.g., tags147), and the tags are then grouped in categories. Throughout this document, categories of objects (e.g., VMs, hosts) are used interchangeably with categories of the tags assigned to these objects.

For example, VM-Host affinity policies may be applicable to some VMs and hosts when host-based licensing requires VMs that are running certain applications to be placed on hosts that are licensed to run those applications. VM-Host affinity policies may also be useful when VMs with workload-specific configurations require placement on hosts that have certain characteristics. Based on a VM-Host affinity policy, VM manager121may deploy those VMs on hosts both of which are covered by the policy.

In some embodiments, policy manager123may apply one or more VM-VM affinity policies to VM group143. A “VM-VM affinity policy” may describe a relationship between members of a category of VMs. In other words, a VM-VM affinity policy may establish an affinity relationship between VMs in a given category. VM-VM affinity policies may be applicable to two or more VMs in a category that can benefit from locality of data reference or where placement on the same host can simplify auditing. Policy manager123may create a VM-VM affinity policy to deploy all VMs in the category covered by the policy on the same host.

In some embodiments, policy manager123may apply one or more VM-Host anti-affinity policies to VM group145. A “VM-Host anti-affinity policy”, which describes a relationship between a category of VMs and a category of hosts, may be used to avoid placing VMs that have specific host requirements (such as a GPU or other specific hardware devices, or capabilities such as IOPS control), on hosts that can't support those requirements. Based on a VM-Host anti-affinity policy, VM manager121and policy manager123may deploy VMs on hosts according to the policy, and may prevent/block those deployments that may violate this policy.

In some embodiments, policy manager123may apply one or more VM-VM anti-affinity policies to VM group145. A “VM-VM anti-affinity policy”, which describes a relationship among a category of VMs, may discourage placement of VMs in the same category on the same host. VM manager121and policy manager123may place VMs running critical workloads on separate hosts, so that the failure of one host does not affect other VMs in the category.

In some embodiments, VM management server120may further include tag manager125to use tags for configuring one or more VMs and VM groups in VM cloud/cluster140. A “tag” may be a label that can be applied to objects (e.g., VMs, hosts, VM groups, policies, etc.) in VM cloud/cluster140, in order to make it easier to categorize, sort, and search for these objects. Alternatively, a tag may store the common metadata (e.g., physical location, hardware configuration, etc.) of the objects. Further, a “VM tag” may be a label that can be assigned to multiple VMs, each of which shares a common characteristic among themselves. A VM tag is one example of a virtual infrastructure object tag. A “host tag” may be assigned to a set of hosts that can be grouped together.

In some embodiments, a tag category may be used to group multiple tags together, or to define how tags can be applied to objects. For example, when multiple policies, VMs, and hosts share a common tag, this common tag is used to group such entities. Further, a “VM tag category” may group a set of VM tags, and a “host tag category” may group a set of host-related tags such as VM-host affinity tags.

In some embodiments, based on client instructions111from VM configuration client110, VM manager121may interact with tag manager125to create or delete tags from entities. Further, when client instructions111are to delete a tag, tag manager125may interact with policy manager123to remove all policies that are associated with the to-be-deleted tag.

In some embodiments, a user may interact with VM configuration client110to perform various VM configuration operations such as VM creation, policy creation, and tag deletions, etc. VM configuration client110may transmit user initiated operations as one or more client instructions111to VM management server120. VM manager121, policy manager123, and tag manager125may perform their respective operations based on the received client instructions111, and may transmit feedback113back to VM configuration client110.

In some embodiments, the GUI of the VM configuration client110may receive a command from the user to assign one or more tags to an already existing VM. These one or more tags may already be associated with one or more policies. In order to allow the user to receive real-time feedback, VM configuration client110may request (via client instructions111) VM management server120to provide information related to tags and their respective associated policies, and return such information as real-time feedback113to VM configuration client110. VM configuration client110may display the real-time feedback on its GUI.

In some embodiments, before a user may delete a tag via the GUI of the VM configuration client110, the tag may already be associated with one or more policies. In order to allow the user to receive real-time feedback, VM configuration client110may request (via client instructions111) VM management server120to provide information related to the tag and their respective associated policies, and return such information as feedback113to VM configuration client110. Then, VM configuration client110may display the real-time feedback on its GUI, notifying the user of the policies that may be deleted along with the tag-deletion operation. Thus, the above approach ensures that real-time feedback113of the various operations is presented to the user before the user invokes these operations via the GUI of VM configuration client110. The details of the creating and configuring VMs with policies and tags are further described below.

FIG.2illustrates multiple GUI windows configured to create policies, assign tags, and display real-time feedback information, according to one or more embodiments of the present disclosure. Specifically, a VM management server (similar to VM management server120or VM management server122ofFIG.1) that interacts with a VM cloud/cluster (similar to VM cloud/cluster140or VM cloud/cluster150ofFIG.1) may receive from a VM configuration client (similar to VM configuration client110ofFIG.1) a set of client instructions. In some embodiments, the VM configuration client may support GUI elements such as create-policy window210and assign-tag window230.

For simplicity, the operations associated with these GUI windows illustrated inFIG.2are discussed in conjunction withFIG.1.

Creation of a New Policy

In some embodiments, create-policy window210corresponds to a GUI element for creating a new policy in the VM cloud/cluster (e.g., VM cloud/cluster140or VM cloud/cluster150). Specifically, via create-policy window210, a user may select one of the VM management servers that VM configuration client110has access to and specify various values and information for a new policy. Afterward, the user may click on the “create” button, which causes VM configuration client110to transmit client instructions111to the selected VM management server, which may in turn generate the requested policy accordingly.

In some embodiments, for all the VM management servers that VM configuration client110has access to, they are presented as selectable options in server selection drop-down menu215. Suppose the user selects VM management server120for VM cloud/cluster140via server selection drop-down menu215, the user may then enter “vm host affinity” via text field217in create-policy window210as the name of the new policy and may further assign the new policy with one of the policy types, each of which is selectable via policy type drop-down menu221. Some example policy types may include, without limitation, “VM-Host Affinity”, “VM-VM Affinity”, “VM-Host Anti-affinity”, “VM-VM Anti-affinity,” “Disable DRS vMotion,” and “Evacuation by vMotion.”

Suppose the new policy corresponds to the selected type of VM-Host Affinity. The user may associate this new policy with at least one VM from the VM cloud/cluster140with one or more VM tags assigned to it. In some embodiments, after having selected a VM tag category via VM category drop-down menu222and a VM tag via VM tag drop-down menu224in create-policy window210, all the VMs that meet the selected criteria are counted in real-time and displayed in create-policy window210in first object count226(e.g., M virtual machines currently have this tag). These VMs also become associated with this new policy after the user selects “Create.”

In some embodiments, after having selected a host tag category via host category drop-down menu223and a host tag via host tag drop-down menu225in create-policy window210, all the hosts that meet the selected criteria are counted in real-time and displayed in create-policy window210in second object count227(e.g., N hosts currently have this tag). These hosts also become associated with this new policy after the user selects “Create.” In some embodiments, the selection of “Create” may transmit the selected information to VM management server120, which may then utilize policy manager123to create and save the new policy.

In some embodiments, after having selected the VM tag category, the VM tag, the host tag category, and the host tag, VM configuration client110may transmit client instructions111with the selected items to VM management server120, which may utilize its tag manager125to retrieve relevant tag categories and tags. Then VM management server120may return these tag categories and tags as feedback113to VM client configuration client110, which presents the information via its GUI.

Tag Assignment

In some embodiments, VM configuration client110may include assign-tag window230, which allows a user to select one or more tags to be assigned to the created VM. As illustrated inFIG.2, assign-tag window230is for an already created VM identified as “v-12.” Assign-tag window230may load all available tags from VM management server120and present these tags in tag names241and/or in categories242. In other words, the user may either pick from all the available names241, or browse by categories242, until identifying the suitable tags for the new VM. Alternatively, drop-menus with selectable choices of names and categories may be presented to the user.

In some embodiments, each newly created VM may be assigned with one or more tags. As illustrated inFIG.2, assign-tag window230presents two available tags for assignment to the new VM. One VM tag with the name of “vmTag” and the category of “VM category” may be assigned to one or more VMs or one or more policies associated with certain VMs. One host tag with the name of “Host VM Affinity Tag” and the category of the “Host Category” may be assigned to one or more hosts or one or more policies associated with certain hosts.

In some embodiments, the user may make a GUI selection on assign-tag window230and “select” no-tag, one-tag, or two-tags for the new VM. When the user makes a single GUI selection in assign-tag window230, in order to provide real-time feedback to the user, prior to the user invoking any additional GUI operations, VM configuration client110may transmit client instructions111to VM management server120. Client instructions111may include, without limitation, the identification of the selected tag(s). After having received client instructions111, VM management server120may retrieve a set of policies that are associated with the selected tag(s), and return the retrieved set of policies as feedback to VM configuration client110.

In some embodiments, assign-tag window230may display the set of policies from the feedback113in a “real-time feedback” GUI element such as message244. The information in message244may show that there are two policies currently associated with the VM tag “vmTag.” By displaying real-time information of the policies that may apply to the new VM with the selected tag, the user can quickly grasp the impact of his or her proposed actions, thereby allowing a more efficient and accurate configuration of the new VM.

Deletion of a Tag

In some embodiments, VM configuration client110includes additional GUI elements to support a tag deletion process. Specifically, in the tag deletion process, a delete-tag window (not shown inFIG.2) may be presented to a user to select a specific tag for deletion. Since the specific tag may be associated with multiple policies, the deletion of the specific tag may also affect all the associated policies. Thus, the delete-tag window may display in real-time a warning of possible impacts of the tag deletion process before the user proceeds to complete the deletion process.

In some embodiments, the delete-tag window may display the set of policies that are associated with the tag to be deleted in a real-time GUI element similar to message244. The information in message244may show that for the tag to be deleted, there are associated policies that will also be affected. By providing this real-time feedback, the user can quickly grasp the impact of his or her actions before proceeding further.

Management of Policies

After the creation of VMs and policies and the assignment of tags, VM configuration client110includes additional GUI elements to support management of policies.FIG.3shows example GUI elements for managing multiple policies, according to one or more embodiments of the present disclosure.

In particular, management window300inFIG.3illustrates two GUI elements for the two policies that have been created. Management window300also includes an “Add” button to add a new policy. Policy302has policy name304(e.g., “vm host affinity 1”), selected VM management server name306(e.g., VM management server120), selected policy type308(e.g., “VM host affinity”), and message310. In some embodiments, message310displays real-time information pertaining to the number of VMs associated with policy302that currently have the specified tag category and tag name. For instance, as shown inFIG.3, message310displays that 2 VMs have the specified tag category of “x” and tag name of “all tags.”

In addition, suppose the status of each of these 2 VMs is inactive. The status information of the VMs is then aggregated for policy302, and the aggregated status information is then presented as “inactive” in text, image, or a combination of text and image. InFIG.3, the aggregated status information is presented as “inactive” in text only.

Similarly, compute312also has policy name314(e.g., “vmotion 1”), selected management server name316(VM management server122), selected policy type318(e.g., “Evacuate vMotion”), and message320. In some embodiments, each of the policy name, selected VM management server name, and VM policy type may be a selectable GUI item. For example, in response to a user's selection of policy name314, “vmotion 1,” a different GUI element, details view350is displayed.

In details view350, in addition to real-time object count352, which indicates the number of VMs the policy “vmotion 1” regulates, additional information about the VMs is presented. In some embodiments, the names of the VMs, their respective status, the identities of the hosts supporting the VMs, and the VM cluster that the VMs belong to are presented. By presenting such detailed information about the VMs to a user, the user is able to identify possible issues and manage VM clusters more easily.

FIG.4shows a flow diagram illustrating a process to create and manage policies with GUI elements, according to one or more embodiments of the present disclosure. Process401may set forth various functional blocks or actions that may be described as processing steps, functional operations, events, and/or acts, which may be performed by hardware, software, and/or firmware. Those skilled in the art in light of the present disclosure will recognize that numerous alternatives to the functional blocks shown inFIG.4may be practiced in various implementations.

UsingFIGS.1,2, and3as an example, at block410, a VM configuration client (e.g., VM configuration client110) may receive a first GUI selection (e.g., a selection of an item in server selection drop-down menu215in create-policy window210) of a first VM management server (e.g., VM management server120). With the selected server, the first VM management server may send the VM configuration client a set of available first tags from a first cluster (e.g., VM cloud/cluster140) that it has access to.

At block420, the VM configuration client receives a second GUI selection (e.g., a selection of an item in VM category drop-down menu222, VM tag drop-down menu224, host category drop-down menu223, or host tag drop-down menu225) of first tag(s) (e.g., VM tags and/or host tags), wherein the selected tags are to be assigned to one or more VMs from the first cluster.

At block430, the VM configuration client receives first real-time feedback associated with the first cluster and the first tag(s) from the VM management server.

At block440, the VM configuration client displays the first real-time feedback (e.g., first object count226and/or second object count227) in a first GUI element (e.g., create-policy window). With the displayed real-time feedback associated with creating a first policy, a user is able to make informed decisions regarding the creation and management of this first policy.

After having created the first policy, at block450, the VM configuration client may display at least the first policy, the selected first tag(s), and the first real-time feedback (e.g., real-time number of objects in VM cloud/cluster140that have the selected first tag(s) and are regulated by the first policy) in a second GUI element (e.g., management window300).

In some embodiments, the VM configuration client may similarly retrieve the one or more previously created policies and also display such policies in the second GUI element.

At block460, the conditions for remediation are checked, either by the administrator using the VM configuration client or by the selected first VM management server. To illustrate, suppose the first policy is a VM-VM anti-affinity policy, and suppose 16 VMs are displayed in the second GUI element to be affected in block450. However, suppose these 16 VMs are actually on the same host, against the VM-VM anti-affinity policy. In this situation, conditions for remediation have been met, because 15 of the 16 VMs need to be migrated to another host to comply with the VM-VM anti-affinity policy.

In another example, suppose the administrator reviews the information displayed in the second GUI element in block450and recognizes discrepancies (e.g., the displayed number of objects is significantly higher than expected). The conditions for remediation have also been met, because the recognized discrepancies need to be reconciled.

If the conditions for remediation are met, process401proceeds to block470. At block470, the VM configuration client may display remediation related information, such as the results of the remediation or the potential impact for performing remediation. Using the above example of migrating 15 VMs, suppose the potential impact for migrating all 15 VMs at once is significant and is shown to the administrator, the administrator may decide to consider alternative schemes, such as migrating the 15 VMs before creating the VM-VM anti-affinity policy, removing the tag from half of the VMs and retagging these VMs after the first batch of the migration completes, or other remediation schemes.

On the other hand, if the conditions for remediation have not been met, then process401proceeds to block480. At block480, the VM configuration client waits to receive the next input, either from an administrator or from the selected first VM management server.

Thus, systems and methods for configuring virtual infrastructure objects (e.g., VMs) via a GUI have been disclosed. 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, 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.

In addition, while described virtualization methods have generally assumed that virtual machines present interfaces consistent with a particular hardware system, persons of ordinary skill in the art will recognize that the methods described may be used in conjunction with virtualizations that do not correspond directly to any particular hardware system. Virtualization systems in accordance with the various embodiments, implemented as hosted embodiments, non-hosted embodiments, or as embodiments that tend to blur distinctions between the two, are all envisioned. Furthermore, various virtualization operations may be wholly or partially implemented in hardware. For example, a hardware implementation may employ a look-up table for modification of storage access requests to secure non-disk data.