HK1176186A - Virtual switch interceptor - Google Patents

Description

Virtual switch interceptor

Technical Field

The present invention relates to virtual machines, and more particularly to virtual application management.

Background

Information Technology (IT) professionals are responsible for managing computing resources for an enterprise. Often, these IT professionals are tasked with reducing costs and increasing operating efficiency. However, data centers are approaching capacity quickly, and purchasing new servers increases capital and operating expenses, among other costs. At the same time, servers are often and substantially underutilized, and providing new machines is a lengthy process that makes it difficult to respond to rapidly changing business needs.

Virtual machine technology facilitates increased physical resource utilization and flexible machine provisioning. Traditionally, software applications are tightly coupled to the physical server running the software application. Virtual machine technology provides an abstraction layer between software applications and physical hardware and allows multiple virtual machines to be provisioned, for example, on a single physical server. Thus, workloads can be integrated to improve physical asset utilization, and machines can be deployed and shut down quickly as needed.

To facilitate management, IT is helpful for IT professionals to be provided with means for monitoring physical resources, virtual resources, or both. For example, metrics regarding performance or failure may be useful for determining whether to add, remove, or move machines. This information can be obtained by application instrumentation.

Typically, agents are added to an application, which monitor the application and pass relevant information out of the application to a management component for further processing. In other words, for each application, one agent is added and there is a static relationship between the agent and the manager. For example, a virtual machine manager on a host server may receive status messages related to an application from a virtual machine through a local application proxy.

Disclosure of Invention

The following presents a simplified summary in order to provide a basic understanding of some aspects of the disclosed subject matter. This summary is not an extensive overview. It is not intended to identify key/critical elements or to delineate the scope of the claimed subject matter. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.

Briefly, the present disclosure is generally directed to facilitating management of virtual applications. Messages from the virtual application may be observed outside of the virtual machine hosting the application, and one or more actions may then be performed in accordance with the messages. For example, a virtual switch or similar mechanism may be equipped to observe messages passing between locally and/or remotely hosted virtual applications and provide the messages to a management service for further processing. The actions performed may include monitoring application execution as well as routing, filtering, and/or transforming messages, among others. In addition, locally collected information may be sent to higher level management layers to withstand rapid deployment and migration of virtual machines, as well as addition, deletion, updating, and renaming of physical machines.

To the accomplishment of the foregoing and related ends, certain illustrative aspects of the claimed subject matter are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways in which the subject matter may be practiced, all of which are within the scope of the claimed subject matter. Other advantages and novel features of the invention may become apparent from the following detailed description when considered in conjunction with the drawings.

Drawings

FIG. 1 is a block diagram of a system that facilitates virtual application management.

FIG. 2 is a block diagram of a representative management component.

FIG. 3 is a block diagram of a representative message processor component.

FIG. 4 is a block diagram of a system that facilitates virtual application management.

FIG. 5 is a block diagram of a system that facilitates hierarchical management of virtual applications.

FIG. 6 is a flow diagram of a method of facilitating virtual application management.

Fig. 7 is a flow chart of a method of applying communication processing.

FIG. 8 is a flow diagram of a method of facilitating virtual application management.

FIG. 9 is a schematic block diagram illustrating a suitable operating environment for aspects of the present disclosure.

Detailed Description

The following details are generally directed to facilitating virtual application management. Typically, an agent/manager approach is employed in which a virtual application is instrumented with an agent that can observe actions in the virtual application and provide information to a manager located outside the application for further processing. However, conventional approaches do not adapt well to current and future multi-layer virtualization. A single server may currently host tens of virtual machines, and in the near future, a server will be able to host hundreds of virtual machines. Furthermore, the number of virtual machines residing on one server may change rapidly as virtual machines are deployed, removed, and moved from one server to another. Current agent manager approaches require that the application first be equipped with an agent (but not always) and that a static link be established between the agent and the manager. The absolute volume of the virtual machine and the associated vitality do not contribute to the method.

As described herein, application messages can be observed from outside the application and the master virtual machine, where the messages correspond to communications between the virtual applications. For example, a virtual switch or similar component may be equipped to observe messages. The observed messages may then be analyzed, and actions performed based on the messages, and so on. For example, management metrics related to application execution, errors, and/or exceptions may be generated. Additionally or alternatively, inbound and outbound messages may be rerouted, filtered, and/or translated. Data collected at the local host server may also be provided to the management server for further processing of and interaction with the application across the servers.

Various aspects of the present disclosure will now be described in more detail with reference to the appended drawings, wherein like reference numerals designate like or corresponding elements throughout. It should be understood, however, that the drawings and detailed description relating thereto are not intended to limit the claimed subject matter to the particular form disclosed. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the claimed subject matter.

Referring initially to FIG. 1, a system 100 that facilitates virtual application management is illustrated. As shown, system 100 includes a host server 110, host server 110 being capable of hosting multiple virtual machines 120 (VMs)₁-VM_XWhere "X" is a positive integer). Each virtual machine 120 can host one or more applications 122, applications 122 including system and application software, and each virtual machine 120 can include a network protocol stack 124 that allows communication across applications and thus across virtual machines. In other words, the application 122 may be openThe cross-master virtual machine 120 sends messages to one or more other applications 122 hosted by different virtual machines 120 and receives messages from one or more other applications hosted by different virtual machines 120. The message may be implemented as a data packet, such as a TCP/IP (transmission control protocol/internet protocol) packet, a pointer to a memory shared by the virtual machines, or raw data for processing by subsequent protocols, among other forms.

Virtual switch 130 is a component that allows communication by routing messages to a target virtual machine, and the like. Virtual switch 130 may be embedded within virtualization component 132 (e.g., a virtual machine monitor, hypervisor, or. As shown, the message may be routed by virtual switch 130 to a local virtual machine or to a remote virtual machine that forms part of a computer network (or in other words, network cloud 140). Thus, virtual switch 130 may allow for local as well as remote dynamic resource allocation. For example, virtual machine 120 can be migrated from one physical host to another, while virtual switch 130 can reroute messages to its new location to maintain the communication link. Furthermore, virtual switch 130 may do more than simply forward data packets. Virtual switch 130 may also be responsible for various packet inspection functions (assuming it is provided with the necessary data). Thus, the virtual switch 130 can utilize provisioned or otherwise available credentials, certificates, or the like (e.g., from the virtualization component 132) to provide readable data for review. Further, note that virtual switch component 130 is not limited to being a virtual switch itself, but may also include other similar mechanisms, such as, but not limited to, virtual hubs and virtual routers.

Additionally, virtual switch 130 may be equipped with a switch interface component 150 (also referred to simply as interface component 150) configured to observe, or observe and intercept, communicated messages and forward the messages or copies of the messages to management component 160 for further processing. According to one embodiment, the interface component 150 may correspond to one or more application programming interfaces. Note that by locating the interface component 150 outside of the virtual machine hosting the application, observation is independent of whether the application has an agent capable of observing messages from within the virtual machine, and any number of virtual machines are easily handled as they are dynamically deployed, removed, and/or moved.

In addition to traffic, the interface component 150 can be configured to obtain and provide metadata related to the virtual machine to the management component 160. For example, the metadata may identify how the virtual machine is configured and what applications may be executed on the virtual machine. For example, when deploying a virtual machine, at least a portion of the metadata can be provided to the virtualization component 132, which can then be provided to the management component 160 by the interface component 150.

The management component 160 is configured to perform actions based on the application messages and, optionally, metadata obtained from the interface component 150. For example, application messaging may be monitored and used to compute metrics that provide information about how the application is executing and whether any errors and/or anomalies have occurred. Data may also be collected to allow for trend prediction or other analysis. The management component 160 can also make decisions regarding routing, filtering, and translation of messages based on exchanged messages, and can communicate the decisions as instructions to the virtual switch 130 and/or perform actions specified by the instructions in person. Further, the actions performed by the management component 160 can be based on one or more policies and/or explicit instructions specified by, for example, a system administrator (IT professional).

By way of example and not limitation, information about which virtual machine is communicating with which other virtual machines may be collected. This information can be used to place virtual machines on the same host, chassis (enclosure), local area network, etc. if permitted by isolation policies (e.g., restrictions specifying where virtual machines can be placed relative to each other) to improve performance by moving the virtual machines in communication closer to each other, thereby reducing communication costs.

Further, it can be appreciated that the impact of the constraint management on the primary functionality of the system is desirable. Thus, the management component 160 does not need to change or route messages, which can be queued and gracefully processed from time to time, without significantly negatively impacting system performance. Furthermore, if messages arrive at the queue faster than they are processed, the messages can simply be discarded without being processed at all.

Fig. 2 depicts a representative management component 160 in more detail. The management component 160 includes one or more packet monitor components 210, one or more message checker components 220, and a message handler component 230. The one or more packet monitor components 210 and the message checker component 220 provide preprocessing operations to allow the message handler component 230 to perform actions at a higher level of abstraction.

The one or more packet monitor components 210 can be configured to employ known or new techniques to reconstruct application-generated messages (e.g., entire SOAP envelope or HTTP request) from smaller communicated units. In other words, the one or more packet monitor components 210 may be configured to parse network communications and interpret the messages at any layer within the stack of a set of network protocols (also referred to as communication protocols). To this end, the packet monitor component 210 may be configured to reassemble the network stack (e.g., layers 4-7 (transport, session, representation, application)) based on observations of lower layers (e.g., layer 2 (data) and layer 3 (network)). According to one implementation, this functionality may be implemented by running a copy of the same protocol stack 124 as is run within the virtual machine. In this way, messages can be understood at different levels (e.g., layer 2, IP, TCP, HTTP, SOAP,.. and where appropriate, decryption can be applied at the appropriate level. Similarly, since the network protocol stack can be interpreted at any level of the required, policies that at least affect the actions to be performed can be specified at any layer (e.g., data packet layer, message layer. Also note that one or more of the packet monitor components 210 may be technology dependent (e.g., a monitor component for operating system a, a monitor component for operating system B).

The one or more message checker components 220 can be configured to check for technology-specific communications at one or more specified layers of the network stack. Further, one or more message checker components 220 can be assigned tasks that request and reply pairs for a particular technology and stack layer identification. Once the message pair is identified, the message pair can be provided to the message processor component 230 for further processing.

The message handler component 230 provides additional processing associated with messages provided by the one or more message checker components 220. More specifically, the message processor component 230 can employ metadata related to the virtual machine including the supported applications, etc., to assist in associating the message with a particular application. Any number of operations may then be performed on the message data. For example, performance metrics may be computed, health information derived, and application-related event data collected. Additionally, messages may be rerouted to other destinations, filtered, and/or translated.

One representative embodiment of the message processor component 230 is depicted in fig. 3. As shown, the message processor component 230 includes one or more identity monitor components 310 (identity monitor components)₁Identity monitor Assembly_MWhere "M" is a positive integer) configured to identify a source or destination application from the message itself and optionally metadata about one or more virtual machines (e.g., transmitters, receivers) associated with the message. Once the application is associated with the message, one or more work items 320 (work items)₁Work item_NWhere "N" is a positive integer) may be generated to define an action to be performed. For example, work items 320 may include instructions for storing application activity or instructions for reporting the occurrence of software exceptions. In other words, a queue of work items is maintained.

The work manager component 330 is configured to schedule work items 320 from the queue for execution, for example, according to contextual information (e.g., workflow items, CPU utilization, memory utilization. As an example, where messages are not changed or routed, the queue of work items may be gracefully processed to limit the impact on the currently executing virtual application when an acceptable performance threshold is met. Further, if the work manager component 330 and associated hardware cannot keep up with message processing, the message may simply be discarded, or in other words, the message is allowed to pass through without complete analysis and processing.

To monitor for new or unsupported technologies, the message checker component 220 can register with the host server 110 (FIG. 1). However, the data being monitored and how the data relating to the application is configured, identified, or collected can be processed largely without knowledge of the specific technology stack used to observe or otherwise obtain the data.

Furthermore, since traffic outside of the virtual machine is the observation insertion point, virtual machine lifetime and configuration are no longer an issue for message observation, interception, and the like. In addition, once a virtual machine is configured to run and started, virtualization software (e.g., a hypervisor, a virtual monitor, a virtual switch, a....) will store data related to the virtual machine to help identify applications when observing messages for the virtual machine. Similarly, the virtual machine can provide credentials (e.g., certificates) for decrypting encrypted communications, which can be used by the management component 160 to facilitate viewing and processing of messages. More generally, the data may be protocol dependent, and the virtualization component 132 may understand the data based on, for example, information provided by the virtual machine.

FIG. 4 depicts a system 400 that facilitates virtual application management. Similar to system 100 of fig. 1, system 400 includes a host server 110, host server 110 including a plurality of virtual machines 120 and a virtual switch 130, where virtual switch 130 forms part of a virtualization component 132 (e.g., a virtual machine monitor, hypervisor. Virtual switch 130 is equipped with an interface component 150 for allowing monitoring of communications between multiple virtual machines 120 and other virtual machines accessible through network cloud 140. Unlike the system 100 of FIG. 1, in this embodiment, the administration component 160 is comprised of a plurality ofOne of the virtual machines 120 hosts. In other words, the management component 160 is a virtual appliance (e.g., a software image designed to run inside a virtual machine). As shown here, the management component 160 is represented by a "VM_X"to master. Thus, the interface component 150 can pass communication messages through the "VM" based on observations, intercepts, and the like of communications across virtual machines_X"to the management component 160. Similarly, note that the management component 160 can be located external to the host server 110 (not shown) and can be accessed through the network cloud 140. In either embodiment, the management component 160 maintains the functionality previously described in connection with performing various actions in accordance with messages and optional metadata or the like.

Turning attention to FIG. 5, a system 500 that facilitates hierarchical management is illustrated. Several local host servers 502 (host servers)₁Host server_MWhere "M" is a positive integer) may include respective local management components 504 (local management components) corresponding to the management components 160 in fig. 1, 2, and 4₁-local management component_MWhere "M" is a positive integer). The data collected by each local management component 504 may be provided to a management server 506 that includes a central management component 510. Additionally, the central management component 510 can store application definitions (or in other words, application metadata) in the data store 520 to allow subsequent modeling of the application and the state of the application. In addition, various data about the application may be collected and deposited in data store 520 for analysis, trend prediction, and the like. Based on the analysis, administrator input, and/or other factors, central manager component 510 can instruct one or more of local management components 504 to perform an action or enforce a policy. For example, central management component 510 can adjust load balancing among host servers 502. To allow virtual machines to move between hosts during execution while maintaining an understanding of messages, virtual machine live migration may occur within a TCP (transmission control protocol) timeout, and central management component 510 may include a running copy of the same protocol stack as the virtual machine being moved.

The system 500 illustrates a two-tiered, hierarchical management structure, where a first tier corresponds to local management components 504 residing on respective host servers 502, and a second tier corresponds to a central management component 510 executed by a management server 506. The structure is beneficial to application management under the condition that a large number of virtual machines exist, quick placement and migration of the virtual machines, and addition, subtraction, updating and renaming of the physical machines. Further, it should be understood that system 500 is not limited to two layers, but is scalable to support any number of layers or hierarchical levels for ease of management. By way of example and not limitation, a group of management servers may be supervised by a global management server (not shown) and/or an intermediate management server (not shown) may be interposed between host server 502 and management server 506.

The above systems, architectures, environments, etc. have been described with reference to interaction between several components. It should be understood that such systems and components can include those components or sub-components specified therein, some of the specified components or sub-components, and/or additional components. Sub-components may also be implemented as components communicatively coupled to other components rather than included within parent components. Further, one or more components and/or sub-components may be combined into a single component providing aggregate functionality. Communication between systems, components, and/or sub-components may be implemented according to a push (push) and/or pull (pull) model. Each component may also interact with one or more other components not specifically described herein for the sake of brevity, but known by those of skill in the art.

Moreover, various portions of the above disclosed systems and the following methods may include or incorporate artificial intelligence, machine learning, or knowledge or rule-based components, subcomponents, processes, means, methods or mechanisms (e.g., support vector machines, neural networks, expert systems, bayesian belief networks, fuzzy logic, data fusion engines, classifiers). Such components, and others, may automate certain mechanisms or processes performed thereby to make portions of the systems and methods more adaptive as well as efficient and intelligent. By way of example and not limitation, local management component 504 and global management component 510 can employ such a mechanism to determine or infer management strategies and the like.

In view of the exemplary systems described above, methodologies that may be implemented in accordance with the disclosed subject matter will be better appreciated with reference to the flow charts of FIGS. 6-8. While, for purposes of simplicity of explanation, the methodologies are shown and described as a series of blocks, it is to be understood and appreciated that the claimed subject matter is not limited by the order of the blocks, as some blocks may occur in different orders and/or concurrently with other blocks from what is depicted and described herein. Moreover, not all illustrated blocks may be required to implement the methodologies described hereinafter.

Referring to FIG. 6, a methodology 600 that facilitates virtual application management is illustrated. At reference numeral 610, messages sent to and from one or more virtual machines are observed. For example, an application may be distributed across two or more virtual machines and cross-application communication may be observed. Further, such observation, interception, and the like may be performed outside the virtual machine. In one embodiment, these messages may take the form of TCP/IP data packets. However, the message is not limited thereto. By way of example and not limitation, a message may specify a pointer to a local memory shared by two or more virtual machines. Further, it is to be understood that cross-application communication is not limited to local virtual machines, but may include communication between virtual machines hosted by other network-accessible physical servers.

At numeral 620, one or more actions can be performed in accordance with the message. In one example, the action may correspond to identifying a particular application to which the message corresponds from the message and optionally from the virtual machine metadata. In another example, the action may correspond to monitoring the application message and storing the message for subsequent use. Additionally or alternatively, message data may be analyzed, correlated, aggregated, and/or thresholded, etc., the results of which may be used, for example, to route, filter, and/or convert messages as well as to place, migrate, update virtual machines. Further, these actions may be performed based on one or more policies or explicit instructions, for example, as specified by a system administrator. By way of example and not limitation, policy-based message translation may be performed using an appropriate hierarchical protocol depending on the relative locations of the source and destination virtual machines. That is, if the virtual machines are on the same host, a memory block transfer may be performed; if the virtual machine is on the same blade server chassis, a huge number of blocks can be transferred; if the virtual machines are located in the same local area network, active blocking can be adopted; and if it is determined that the transmission control protocol is offloaded for the network interface card, a particular protocol, such as streaming, may be employed.

Fig. 7 depicts a method 700 of applying communication processing. At reference numeral 710, a data packet is obtained from an interface that observes or intercepts application messages across virtual machines, for example. At reference 720, the message is reconstructed. The application layer (layer 7) and other intermediate layers of the network protocol stack may be reconstructed from the data link layer and/or network layer (layers 2 and 3) data packets using known or new mechanisms. This may be done, for example, by running a local copy of the same network protocol stack (e.g., an implementation of the network protocol suite) as the virtual machine from which the data packet was obtained. At numeral 730, the credentials are applied to decrypt the encrypted data packet (or more specifically, the network protocol stack layers). When a virtual machine is placed (or in other words, deployed) on a host server, these credentials or information related to other security mechanisms may be provided by the virtual machine and subsequently may be retrieved and used to enable the data to be read. At reference numeral 740, a message pair is identified, i.e., a request is paired with a response to the respective request, e.g., for a particular technology or network protocol layer. At numeral 750, an application associated with the message is identified from the message and, optionally, from metadata related to the virtual machine.

Fig. 8 is a flow diagram illustrating a method 800 of application management. At reference numeral 810, data is obtained from the virtual application message. For example, messages between locally and/or remotely hosted virtual applications may be observed, and the message content may be the retrieved data. At numeral 820, one or more actions can be performed on the data. For example, the data may be stored for subsequent application modeling or trend prediction, and/or processed to compute how the application performs or how packets should be routed, filtered, or transformed. In addition, it is to be understood that the actions performed are also specified by policies or explicit instructions. At reference numeral 830, the results of the one or more actions are output to, for example, a system administrator or file for later analysis. Further, where the message is intercepted and a different route is desired, the output may correspond to the rerouted message.

As described herein, virtual application management can be facilitated by observing messages external to the hosting virtual machine, as opposed to conventional management systems that observe application activity at the application layer through agents. However, these two methods of application management need not be mutually exclusive. Instead, the management method of the present invention can be added to accept output from an agent residing in an application, as opposed to, or in addition to, observing messages, for example, from a virtual switch. Similar information may be obtained by either of two methods. Furthermore, employing both methods may provide a means for corroborating the results, or in other words, a means for increasing the confidence of the results produced by one method.

As used herein, the terms "component," "system," and "engine," as well as forms thereof, refer to a computer-related entity, either hardware, a combination of hardware and software, or software in execution. For example, a component may be, but is not limited to being, a process running on a processor, an object, an instance, an executable, a thread of execution, a program, and/or a computer. By way of illustration, both an application running on a computer and the computer can be a component. One or more components can reside within a process and/or thread of execution and a component can be localized on one computer and/or distributed between two or more computers.

The word "exemplary" or various forms thereof is used herein to mean serving as an example, instance, or illustration. Any aspect or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs. Furthermore, the examples are provided solely for purposes of clarity and understanding and are not meant to limit or restrict the claimed subject matter or relevant portions of the invention in any way. It will be appreciated that a number of additional or alternative examples of varying scope could have been presented, but have been omitted for purposes of brevity.

As used herein, the term to "infer" or "inference" refers generally to the process of reasoning about or inferring states of the system, environment, and/or user from a set of observations as captured via events and/or data. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic-that is, the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources. Various classification schemes and/or systems (e.g., support vector machines, neural networks, expert systems, bayesian belief networks, fuzzy logic, data fusion engines.) may be employed to perform automated and/or inferred actions with respect to the claimed subject matter.

Furthermore, to the extent that the terms "includes," "including," "has," "contains," or other variants thereof are used in either the detailed description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprising" as "comprising" is interpreted when employed as a transitional word in a claim.

In order to provide a context for the claimed subject matter, FIG. 9 and the following discussion are intended to provide a brief, general description of a suitable environment in which the various aspects of the subject matter can be implemented. However, the suitable environment is only an example and is not intended to suggest any limitation as to scope of use or functionality.

While the above disclosed systems and methods can be described in the general context of computer-executable instructions of a program that runs on one or more computers, those skilled in the art will recognize that aspects also may be implemented in combination with other program modules and the like. Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the above-described systems and methods can be practiced with various computer system configurations, including single-processor, multi-processor or multi-core processor computer systems, minicomputers, mainframe computers, as well as personal computers, hand-held computing devices (e.g., Personal Digital Assistants (PDAs), telephones, watches), microprocessor-based or programmable consumer or industrial electronic devices, and the like. Aspects may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. However, some, if not all aspects of the claimed subject matter can be practiced on stand-alone computers. In a distributed computing environment, program modules may be located in one or both of local and remote memory storage devices.

Referring to fig. 9, an example general purpose computer 910 or computing device (e.g., desktop, laptop, server, handheld device, programmable consumer or industrial electronics, set-top box, gaming system) is illustrated. The computer 910 includes one or more processors 920, memory 930, a system bus 940, mass storage 950, and one or more device interface components 970. The system bus 940 is communicatively coupled with at least the above-described system components. However, it is to be appreciated that in its simplest form, the computer 910 can include one or more processors 920 coupled to a memory 930, the one or more processors 920 executing various computer-executable acts, instructions, and/or components stored in the memory 930.

The processor 920 may be implemented with a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any processor, controller, microcontroller, or state machine. Processor 920 may also be implemented as a combination of computing devices, e.g., a combination of a DSP and a microprocessor, a plurality of microprocessors, multi-core processors, one or more microprocessors in conjunction with a DSP core, or any other such configuration.

Computer 910 can include or otherwise interact with a variety of computer-readable media to facilitate controlling computer 910 to implement one or more aspects of the claimed subject matter. Computer readable media can be any available media that can be accessed by computer 910 and includes both volatile and nonvolatile media, removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media.

Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, memory devices (e.g., Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM)), magnetic storage devices (e.g., hard disk, floppy disk, magnetic cassettes, magnetic tape), optical disks (e.g., Compact Disk (CD), Digital Versatile Disk (DVD)), and solid state devices (e.g., Solid State Drive (SSD), flash memory drive (e.g., card, stick, key drive)), or any other medium which can be used to store the desired information and which can be accessed by computer 910.

Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of any of the above should also be included within the scope of computer readable media.

Memory 930 and mass storage 950 are examples of computer-readable storage media. Depending on the exact configuration and type of computing device, memory 930 may be volatile (such as RAM), non-volatile (such as ROM, flash memory), or some combination of the two. By way of example, the basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 910, such as during start-up, may be stored in a non-volatile memory, while a volatile memory may act as an external cache memory to facilitate processing by the processor 920, and so on.

Mass storage 950 includes removable/non-removable, volatile/nonvolatile computer storage media for storage of large amounts of data relative to memory 930. For example, mass storage 950 includes, but is not limited to, one or more devices such as a magnetic or optical disk drive, floppy disk drive, flash memory, solid state drive, or memory stick.

Memory 930 and mass storage 950 may include, or have stored therein, operating system 960, one or more applications 962, one or more program modules 964, and data 966. The operating system 960 acts to control and allocate resources of the computer 910. Applications 962 include one or both of system and application software and may utilize management of resources by operating system 960 to perform one or more actions through program modules 964 and data 966 stored in memory 930 and/or mass storage 950. Thus, applications 962 can turn a general-purpose computer 910 into a special-purpose machine in accordance with the logic provided thereby.

All or portions of the claimed subject matter can be implemented using standard programming and/or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed functionality. By way of example and not limitation, interface component 150 and management component 160 of system 100, or portions thereof, may be or form part of an application 962 and include one or more modules 964 and data 966 stored in memory and/or mass storage 950, whose functions may be implemented when executed by one or more processors 920.

According to one particular embodiment, the processor 920 may correspond to a system on a chip (SOC) or similar architecture that includes, or in other words integrates, hardware and software on a single integrated circuit die. Here, the processor 920 may include one or more processors and memories, etc., at least similar to the processor 920 and the memory 930. Conventional processors include a minimal amount of hardware and software and rely extensively on external hardware and software. By contrast, an SOC implementation of a processor is more powerful because it embeds hardware and software therein to enable specific functions with minimal or no reliance on external hardware and software. For example, the interface component 150 and the management component 160 and/or associated functionality can be embedded within hardware in the SOC architecture.

The computer 910 also includes one or more device interface components 970 that are communicatively coupled to the system bus 940 and facilitate interaction with the computer 910. By way of example, the device interface component 970 may be a port (e.g., serial, parallel, PCMCIA, USB, firewire), or an interface card (e.g., voice, video), or the like. In one example implementation, the device interface component 970 may be embodied as a user input/output interface that enables a user to enter commands and information into the computer 910 through one or more input devices (e.g., a pointing device such as a mouse, a trackball, a stylus, a touch pad, a keyboard, a microphone, a joystick, a game pad, a satellite dish, a scanner, a camera, other computers. In another example implementation, the device interface component 970 may be embodied as an output peripheral interface that provides output to a display (e.g., a CRT, LCD, plasma), speakers, printer, and/or other computer, etc. Further, the device interface component 970 may be embodied as a network interface that enables communication with other computing devices (not shown), such as over wired or wireless communication links.

What has been described above includes examples of aspects of the claimed subject matter. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the claimed subject matter, but one of ordinary skill in the art may recognize that many further combinations and permutations of the claimed subject matter are possible. Accordingly, the disclosed subject matter is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims.

Claims (10)

1. A method that facilitates application management, comprising:

employing at least one processor (920) configured to execute computer-executable instructions stored in memory (930) to perform the following acts:

observing virtual application messages external to a virtual machine (120) hosting an application; and

performing an action in accordance with the message.

2. The method of claim 1, further comprising performing the action in accordance with metadata related to at least one of the virtual machines of the master application.

3. The method of claim 1, further comprising receiving a policy that affects the action performed.

4. The method of claim 3, further comprising interpreting the message at a network protocol stack level according to the policy.

5. The method of claim 1, wherein performing an action comprises determining placement of one or more of the virtual machines from the message.

6. A system (100, 900) that facilitates virtual application management, comprising:

a processor (920) coupled to a memory (930), the processor (920) configured to execute the following computer-executable components stored in the memory (930):

a first component (150) configured to observe messages between applications executing on separate virtual machines (120) communicating through a virtual switch (130); and

a second component (160) configured to perform an action based on the observed message.

7. The system of claim 6, the second component is configured to perform the action according to metadata related to at least one of the virtual machines.

8. The system of claim 6, wherein the message provides a pointer to a memory shared by two or more of the virtual machines.

9. The system of claim 6, wherein the message is provided by a dedicated virtual device that provides protocol processing for one or more local virtual machines.

10. The system of claim 1, further comprising a third component configured to communicate results of the actions performed by the monitoring application from the local host server to the management server.