Isolating network resources in a virtualized environment

Embodiments of the disclosure provide techniques for isolating network resources in a virtualized environment. A method is provided that includes identifying a security context data structure including a first security context label, a resource identifier and a plurality of access types. The first security context label is associated with a virtual machine. Each of the plurality of access types represents a type of access permitted to a resource associated with the resource identifier. The first security context label is associated with a network resource. A request to validate an access right of a client with respect to the network resource is received. The request comprises a second security context label associated with the client and the first security context label associated with the resource. The request is validated in view the first and second security context labels and the security context data structure.

TECHNICAL FIELD

The present disclosure is generally related to virtualized computer systems, and is more specifically related to systems and methods for isolating network resources in a virtualized environment.

BACKGROUND

A virtual machine (VM) is a software artifact that, when executed on appropriate hardware, creates an environment that allows for a virtualization of various resources of an actual physical computer system (e.g., a server, a mainframe computer, etc.). The actual physical computer system is typically referred to as a “host machine,” and the operating system of the host machine is typically referred to as the “host operating system.” On the host machine, a virtual machine monitor known as a “hypervisor” manages the execution of one or more virtual machines. The virtual machine monitor provides a variety of functions, such as allocating and executing request by the virtual machines for the various resources of the host machine.

DETAILED DESCRIPTION

Described herein are techniques for isolating network resources in a virtualized environment. In the virtualized environment, there is typically a hypervisor component that can run a plurality of “guest” domains (e.g., operating systems and virtual machines) on a physical host platform. The hypervisor may provide a device emulation framework, such as quick emulator (QEMU®), on the physical host machine that allows each guest domain to have a complete virtualized machine platform to run on. The device emulation framework is often run on a host kernel or operating system (OS) that may provide a limited amount of isolation for virtualized guest domains to prevent them from interfering with each other or the host platform. For example, if a device emulator needs to access a host block device (e.g., hard disks, cd-rom drives, etc.), the device emulator's access may need to be restricted to that particular block device only rather than having access to all block devices.

Some systems may implement mandatory access controls (MAC) to provide system controlled policy restricting access to resource objects of the host system, such as data files, devices, etc. In some situations, these systems may implement a kernel security module also referred to as Security-Enhanced Linux (SELinux) that may provide a mechanism for supporting access control security policies, such as MAC, by labeling resources that are assigned to a specific guest domain. In some embodiments, the techniques disclosed herein may use secure virtualization to provide isolation of a device emulator on a virtualized host through labeling of the resource objects using the kernel security module. For example, in the event of a security flaw in a given device emulator, secure virtualization may prevent the compromised emulator from being used to compromise other emulator processes or the host OS. In this way two guests running on the same host may have a security separation that is closer to what can be achieved if they were running on separate physical machines.

In operation, secure virtualization may include confining the guest domains on the host operating system or host kernel. In some embodiments, each guest domain is assigned a security context label to uniquely identify a specific guest domain (e.g., virtual machine). Any resources on the host machine that are allocated to a specific guest are assigned a security context label that is assigned to the guest domain. For example, a disk image exclusively allocated to a guest may be relabeled using the security context label for that guest.

When a guest domain attempts to access a file on the relabeled disk, the host OS may deny access unless there is a policy rule permitting the guest domain access and a match between the security context labels associated with the guest domain and the disk. Since each guest domain has a unique security context label, the guest domains may be restricted from accessing each other's disk images, even if the permissions set by the emulator for a group of guest domains would have otherwise allowed them all to access the disk. As long as the resource assigned to the guest domain can be labeled, then access to that resource can be controlled via secure virtualization. This allows the security context labels to confine resources of the physical host that include not only disk images, for example, the host resources may include serial console logs, UNIX sockets, shared memory files, arbitrary block/character devices, etc.

Increasingly, many systems today use network based resources, such as a network based storage device (e.g., RBD, Gluster, iSCSI). In some situations, when a network based storage device is used, the virtualized host acts as a network client with respect to communicating with the storage device. For example, the hypervisor process may access a remote network client associated with the network based storage device directly to perform I/O against the device. For a variety of reasons, it is becoming more common to push the network client code into the hypervisor itself, which bypasses the kernel and/or host OS services. Principally, this helps the guest domains obtain a shorter I/O path by being able to connect to the network devices without going through the host OS in order to improve system performance.

For the hypervisor to act as the network client, it needs to be given permission to connect directly to the storage server over the network. As a result, the hypervisor has direct access to the networked storage server, thus bypassing any access controls that the host OS can implement on resources of the server once the host OS is authenticated. For example, while the host OS can see the connection between the hypervisor and the networked storage server, it cannot interpret the data being transferred. The host OS is thus unable to determine what network resources are being accessed by the hypervisor and thus cannot isolate them. This may impose a significant risk for certain systems (e.g., cloud-based systems) that may need to use direct connection of the hypervisor to the storage device to obtain better I/O performance from the hypervisor by eliminating data copies through the host OS storage infrastructure.

Embodiments of the present disclosure provide systems and methods to extend secure visualization protections for isolating network resources while still allowing a virtualized host to act as a network client. In one embodiment, a host OS may generate security context labels and transfer the labels to a network server associated with the network resources. The network server is then modified to request access control checks using the security context labels whenever there is a request to access the network resources. In another embodiment, instead of modifying the network server, a proxy server residing, for example, on the host machine may be employed for maintain security context labels associated with the network resources and may be used to interpret access protocols for the network resources in order to apply access control checks for the virtualization host. In yet another embodiment, each virtual machine of the virtualization host may be assigned a unique login account associated with the network resources. Each login account may be configured to only permit access to the network resources associated with the virtual machine using that account. Still further, the techniques disclosed herein may be used in other embodiments for isolating network resources in a virtualized environment.

Although aspects of the present disclosure may be particularly useful with certain type of network devices/services, the techniques disclosed herein may be used with are other types of network services that a virtual machine emulator like the hypervisor may need to access. For example, the hypervisor process may have the ability to receive random entropy (e.g., seed data) from a separate network process, to feed into a guest random number generator. If the random entropy can be passed to the security context of the hypervisor process, it may be possible to restrict the ability of certain guest domains to request entropy.

FIG. 1depicts a high-level component diagram of an exemplary computer system100for isolating network resources that may be used to implement one or more aspects of the present disclosure. As shown, the computer system100may be coupled to a network110and include a processor120communicatively coupled to a memory130, and an I/O device135.

“Processor” herein refers to a device capable of executing instructions encoding arithmetic, logical, or I/O operations. In one illustrative example, a processor may include an arithmetic logic unit (ALU), a control unit, and a plurality of registers. In a further aspect, a processor may be a single core processor which is typically capable of executing one instruction at a time (or process a single pipeline of instructions), or a multi-core processor which may simultaneously execute multiple instructions. In another aspect, a processor may be implemented as a single integrated circuit, two or more integrated circuits, or may be a component of a multi-chip module (e.g., in which individual microprocessor dies are included in a single integrated circuit package and hence share a single socket). A processor may also be referred to as a central processing unit (CPU). “Memory” herein refers to a volatile or non-volatile memory device, such as RAM, ROM, EEPROM, or any other device capable of storing data. “I/O device” herein refers to a device capable of providing an interface between a processor and an external device capable of inputting and/or outputting binary data. Although, for simplicity, a single processor120is depicted inFIG. 1, in some other embodiments computer system100may comprise a plurality of processors. Similarly, in some other embodiments computer system100may comprise a plurality of I/O devices, rather than a single device135.

The computer system100may be a server, a mainframe, a workstation, a personal computer (PC), a mobile phone, a palm-sized computing device, etc. The network110may be a private network (e.g., a local area network (LAN), a wide area network (WAN), intranet, etc.) or a public network (e.g., the Internet). Computer system100may run “host” software or kernel, such host operating system140, that manages the hardware resources of the computer system and that provides functions such as inter-process communication, scheduling, memory management, and so forth. In one embodiment, the host operating system140may also comprises a hypervisor145, which may be software that provides a virtual operating platform for a set of virtual machines (VMs)150-154, and manages the execution of these virtual machines.

Hypervisor145may take many forms. For example, hypervisor145may be part of or incorporated in the host operating system140of computer system100, or hypervisor145may be running on top of the host operating system140. Alternatively, hypervisor145may a “bare metal” hypervisor that runs on hardware of computer system100without an intervening operating system. The hypervisor145manages system resources, including access to processor120, memory130, I/O device135, and so on. The hypervisor145, though typically implemented in software, may emulate and export a physical layer of computer system100to higher level software. Such higher level software may comprise a standard or real-time operating system (OS), may be a highly stripped down operating environment with limited operating system functionality, may not include traditional OS facilities, etc. The hypervisor145presents to other software (e.g., VMs150-154) an abstraction of the physical layer that may provide the same or different abstractions to various guest software, such as guest operating system, guest applications, etc.). Some examples of hypervisors include quick emulator (QEMU®), kernel mode virtual machine (KVM®), virtual machine monitor (VMM), etc.

The hypervisor145may support a plurality of VMs150-154residing on the computer system100. In some embodiments, more than one hypervisor (not shown) may be provided to support the VMs150-154of the computer system100. The VMs150-154may be a software implementation of a machine that executes programs as though the VMs150-154were an actual physical machine. Each virtual machine may execute a guest operating system and other types of software and/or applications. The hypervisor145can either handle request by the VMs150-154for machine resources, or forward the request to the host OS140.

In some embodiments, computer system100may provide isolation for local processes to prevent them from interfering with each other or the physical layer of the system100. In one embodiment, system100may include a security context unit160implemented in the host OS140. The security context unit160may include secure virtualization logic implemented as software, firmware, and hardware or in any combination thereof. In some embodiments, the security context unit160may implement certain secure virtualization methods (e.g., confining the guest domains) to isolate local processes, such as VMs150-154, from accessing with each other's assigned resources. For example, the security context unit160may be adapted to generate unique context labels161-165for resources associate with a corresponding VM of the VMs150-154. Each context label of the context labels161-165may be used to identify one of the VMs150-154. In this regard, the host OS140may assign a unique security context label generated by the security context unit160to each virtual machine when that VM is started. These security context labels are used to isolate the VMs150-154from each other.

In some embodiments, the host OS140can enforce a security policy the VMs150-154based on the context labels161-165. For example, each context label may be used to label a type of resource to enforce rules for permitting access to that resource by the VMs150-154. In some embodiments, the host OS140may re-label a reference name (e.g., an Internet protocol (IP) address) of a resource to include one of the context labels161-165for a particular VM of the VMs150-154to indicate that the resource is assigned to that VM. Once the resource is labeled by the host OS140, the host OS140can apply a set of administrative context policy rules for authorizing or rejecting access by the VMs150-154to the labeled resources.

To enforce the administrative context policy rules, the host OS140may include a security context data structure162(e.g., an array, tree, list or other types of data structures, etc.) that may include a plurality of entries, such as entry180. Each entry may include, but not limited to, a context label182that may be associated with one of the labels161-165assigned to the VMs150-154, a recourse identifier184and a set of access types186. Each of the access types186may represent a type of access permitted to a resource associated with the resource identifier184. Theses access types186may include an access right to read or write or change a security context label associated with the resource.

In one illustrative example, the host OS140may check the security context data structure162when a VM attempts to access a resource of system100. In such cases, the host OS140may use the security context data structure162may identify certain access rights that the VM has for a specified resource. The host OS140validates the VM's right to access a resource by determining whether the security context label associated a VM and the security context label associated with the resource corresponds to an entry in the security context structure162. For example, the host OS140may determine whether the security context label identifies the VM. The host OS140may also determine whether at least one of the access types associated with the entry in the security context data structure162corresponds with the access right of the VM. For example, if the VM only has rights read a resource, then any attempt for the VM to write to the recourse should be rejected by the host OS140. If the host OS140validates the access rights of the VM, then a response may be generated by the host OS140authorizing the request of the VM. Otherwise, the host OS140may generate a rejection response to the request of the VM to access the resource.

In some situations, the VMs150-154may also need to access certain network based resources, for example, for certain cloud-based applications. In one embodiment, the VMs150-154may be in communication via network110with a network-attached storage device170. In some embodiments, the network-attached storage device170may include one or more processors173that execute a device OS or kernel operating system that runs locally on the device170. In some situations, when the network-attached storage device170is used, the hypervisor145may directly perform I/O against the device170. In such situations, the host OS140may not be able to intercept access request made by the VMs150-154to the network-attached storage device170because the hypervisor145is directly connecting to it, thus the security context unit160may not be able to label network based resources (e.g., file paths or volumes) associated with the device170to isolate the resources from amongst the different VMs150-154.

In some embodiments, to isolate network based resources (e.g., file paths, volumes, etc.) associated with the device170, the security context unit160may communicate with the storage device170using administrative login credentials via a secure communication protocol, such as internet protocol security (IPsec). In some embodiments, the context labels161-165may be transmitted across and used by a second security context unit162installed on the storage device170. For example, the storage device170may be modified to run the second security context unit162on a local host OS of the device. In some embodiments, the second security context unit162may run in the device OS173that is executed by the processor171. Thereafter, the context labels161-165may be used to label resources associated with the storage device170.

In one embodiment, the host OS140may communicate with device170to identify which labels should be assigned to certain resources of the storage device170. For example, the host OS140may set context labels to resources on the storage device170using a determined system call associated with the device170. Using the system call, the host OS140may instruct the second security context unit172on the storage device170to associate a given context label with a particular resource that the device170hosts in a second security context data structure174local to the storage device170. For example, the second security context data structure174may be similarly configured to include a plurality of entries, such as entry180where each entry includes a context label, such as context label182, reference identifier, such as resource ID184and a plurality of access types, such as access types186. The storage device170may be instructed to append the context label to a reference identifier or name of the resources at the storage device170. In some embodiments, this may be done before starting any virtual machines and immediately prior to hot-plugging a resource associated with the storage device170. When hot-unplugging the resource or shutting down a virtual machine, the security context labels are reset to deny any further access using those labels.

The storage device170may then perform an access control check for any access attempt to its labeled resource using the second security context unit172to validate the security context labels associated with a connecting network client. In one embodiment, when a network client (e.g., one of the VMs150-154) attempts to accesses resources of storage device170(e.g., read, write, etc.), the device170will request that the network client provide its security context label. In other embodiments, the network client may provide its security context label with the request. For example, the network client may use a secure network protocol, such as Internet protocol security (IPsec), to transmit over network110a security context label associated with the client to the storage device170. In an alternative embodiment, the storage device170may retrieve a security context label associated with a connecting network client directly from the client by using, for example, a determined interface of the client.

The storage device170may then request that the device OS173perform the access control check by using the security context unit172to apply context policy rules associated with the resource. To apply the context policy rules, the device OS173may use the security context data structure174of security context unit172to identify an entry associated with the security context label of the network client to validate that the client has access to those resources according to the access types in that entry. In this regard, the storage device170is not actually interpreting the context policy rules of the host OS140, rather it is passing security context labels associated with the resource and the client to the device OS173which may in turn transmit an authorization or rejection response. The storage device170is thus applying mandatory access control checks that are equivalent to those performed when the host OS140is accessing local resources, for example, via local files or block devices.

In some embodiments, the storage device170can also request a check of whether a connecting client has access to assign and/or reassign security context labels of resources associated with the device170. For example, the security context172may itself have a security context label that may be made available to the storage device170that can be validated by device OS173. The storage device170can thus verify whether that client is actually permitted to change the security context labels of resources associated with the storage device170. An advantage of this type of access control check is that it may add an additional level of protection by helping to prevent unauthorized clients from changing security context labels for the resources of the storage device170.

InFIG. 2, another system200for isolating network resources in accordance with one or more aspects of the present disclosure is shown. Similar to system100ofFIG. 1, system200may be include host OS140and hypervisor145for managing VMs150-154as well as other similar components coupled to network110. As shown, the host OS140may also include security context unit160for isolating system resources from each of the different VMs150-154and a security context data structure162for storing a set of administrative context policy rules for authorizing or rejecting access to resources that are labeled by the host OS140using the security context unit160. As noted above, in some embodiments, the security context unit160may communicate with a modified network-attached storage device170in order to isolate network-based resources associated with the device170.

In this example, instead of modifying the network-attached storage device170, a proxy service unit201may be created. In some embodiments, the proxy service unit201may run directly run on the host OS140. In other embodiments, the proxy service unit201may run off of the host OS140and be in communication with system100. The security context unit160may be adapted to connect to this local proxy service unit201instead of the storage device170. The local proxy service unit201may be configured to maintain the security context labels associated with the storage device170. In some embodiments, the proxy service unit201may communicate with the storage device170in order to apply access control checks for accesses request to labeled resources of the device170. In one embodiment, the security context unit160may communicate with the proxy service unit201to associated security context labels with resources of the storage device170.

In some embodiments, when a client (e.g., one of the VMs150-154) connects with the storage device170, the proxy service unit201can communicate with the storage protocol to identify which resources the client was attempting to access. In this regard, since the security context unit160is running on the same host, the proxy service unit201can obtain the security context label of the client without having to use a secure communication protocol, such as IPsec. The proxy service unit201can then request for the host OS140to perform an access control check on the security context label of the client and the resources to determine whether to authorize or reject the access request. If the request is allowed, then the proxy service unit201may perform un-modified data transmissions in both directions between the host OS140and the storage device170. An advantage of using a local proxy server, such as proxy service unit201, is that the storage device does not need to be modified to have knowledge of the security context labels associated with its resources and that there is no need to maintain a secure communication between the virtualization host and the storage device170.

InFIG. 3, yet another system300for isolating network resources in accordance with one or more aspects of the present disclosure is shown. Similar to system100ofFIG. 1and system200ofFIG. 2, system300may include host OS140and hypervisor145for managing VMs150-154as well as other similar components coupled to network110. In this example, isolation of network based resources associated with network-attached storage device170may be achieved by dynamically creating separate unique user accounts361-365and setting up access control checks for each of the VMs150-154as they are booted, as opposed to the traditional approach where a system administrator would have to manually pre-create accounts an associated with them virtual machines explicitly.

In some embodiments, system300may include a user authentication unit360to communicate directly with the storage device170. In one embodiment, the user authentication unit360may create a unique user account (e.g., user name and password) for each virtual machine and pass the user account information to the storage device170. In some embodiment, the unique user account may be generated based on a universally unique identifier (UUID) associated with a corresponding VM and/or with a random number prefix or other type of techniques for generating a unique user account. In an alternative embodiment, the user authentication unit360may instruct the storage device170to dynamically create user accounts, such as user accounts361-365, for each virtual machine when required and generate a unique password for that account. In some embodiments, the user authentication unit360may instruct the storage device170to setup an access control mapping that permits a given user account to access the specific network-based resources of the storage device170that are to be assigned to the virtual machine using that user account.

In some embodiments, permissions for the network-based resources may be set such that the user account associated with the virtual machine only has the ability to access the network-based resources that are to be assigned to it. For example, when launching a VM, the user authentication unit201may pass the VM connection details for the network-attached storage device170which include the unique user account & password it is allowed to use. Thus, while hypervisor145may have a direct connection to the storage device170, in the event of a compromise, the VM will still be restricted in what storage devices it would be able to access. This is an improvement over the case where all VMs361-365share the same login credentials and thus same access rights over the storage device170.

One advantage achieved by using user authentication based access control checks is a separation between the identity that a user or application is authenticated with (UNIX login name/group), and the identity under which access control decisions are made at a VM level (e.g., labeling using security context labels). This may permit finer grained controls over access policy and allows for rules to be written by determining when the authorization identity is changed. An additional advantage of using user authentication based access control checks is that the storage device does not need to the modified to have knowledge of the security context labels associated with its resources.

To better aid in understanding an example of some of the aspects of the present disclosure described above, for example, that are related to isolating network resources in a virtualized environment, reference is now made to the following example flow diagrams. Although the operations of the flow diagrams herein are shown and described in a particular order, the order of the operations of each flow diagram may be altered so that certain operations may be performed in an inverse order or so that certain operation may be performed, at least in part, concurrently with other operations. In certain implementations, instructions or sub-operations of distinct operations may be in an intermittent and/or alternating manner.

FIG. 4depicts a flow diagram of one embodiment of a method400for isolating network resources in accordance with one or more aspects of the present disclosure. In one embodiment, host OS140or the device OS173of network-attached storage device170ofFIG. 1may perform method400to isolate network resources in a virtualized environment. The method400may be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. Alternatively, in some other embodiments, some or all of the method400might be performed by other components of computer system. As noted above, the blocks depicted inFIG. 4can be performed simultaneously or in a different order than that depicted.

Method400begins at block402where a processing device of a host computer system generates a security context data structure comprising a first security context label, a resource identifier and a plurality of access rules. The first security context label associated with a virtual machine and each of the plurality of access rules representing a type of access permitted to a resource associated with the resource identifier. At block404, the processing device associates a first security context label with a network resource in view of the security context data structure. A request to validate an access right of a requestor client with respect to the network resource is received at block406. The request includes at least a second security context label associated with a requestor client device and the first security context label associated with the network resource. At block408, the processing device validates (e.g., authorizes or rejects) the request in view the first and second security context labels and the security context data structure.

FIG. 5depicts a flow diagram of one embodiment of a method500for isolating network resources in accordance with one or more aspects of the present disclosure. In one embodiment, the host OS140ofFIG. 2may perform method500to isolate network resources in a virtualized environment. The method500may be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. Alternatively, in some other embodiments, some or all of the method500might be performed by other components of computer system. As noted above, the blocks depicted inFIG. 5can be performed simultaneously or in a different order than that depicted.

Method500begins at block502where a processing device of a host computer system generates a security context data structure associated with a virtual machine. At block504, using a proxy server the security context label may be associated with a network resource. A request to validate an access right of a requestor client with respect to the network resource is received at block506. The request includes at least a second security context label associated with a requestor client device and the first security context label associated with the network resource. At block508, the processing device validates (e.g., authorizes or rejects) the request in view the first and second security context labels and the security context data structure.

FIG. 6depicts a flow diagram of one embodiment of a method600for isolating network resources in accordance with one or more aspects of the present disclosure. In one embodiment, the host OS140ofFIG. 3may perform method600to isolate network resources in a virtualized environment. The method600may be performed by processing logic that may comprise hardware (circuitry, dedicated logic, etc.), software (such as is run on a general purpose computer system or a dedicated machine), or a combination of both. Alternatively, in some other embodiments, some or all of the method600might be performed by other components of computer system. As noted above, the blocks depicted inFIG. 6can be performed simultaneously or in a different order than that depicted.

Method600begins at block602where by a processing device of a host computer system identifies account data associated with a virtual machine. The account data includes an account credential that uniquely identifies the virtual machine. At block604, the processing device associates a first account label with a network resource in view of the account data. A request to validate an access right of a requestor client with respect to the network resource is received at block606. The request includes at least a second security context label associated with a requestor client device and the first security context label associated with the network resource. At block608, the processing device validates (e.g., authorizes or rejects) the request in view the first and second security context labels and the account data.

FIG. 7depicts an example computer system700which can perform any one or more of the methods described herein for isolating network resources in a virtualized environment. In one example, computer system700may correspond to computer system100ofFIG. 1. The computer system may be connected (e.g., networked) to other computer systems in a LAN, an intranet, an extranet, or the Internet. The computer system700may operate in the capacity of a server in a client-server network environment. The computer system700may be a personal computer (PC), a set-top box (STB), a server, a network router, switch or bridge, or any device capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that device. Further, while only a single computer system is illustrated, the term “computer” shall also be taken to include any collection of computers that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methods discussed herein.

The exemplary computer system700includes a processing system (processor)702, a main memory704(e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) such as synchronous DRAM (SDRAM)), a static memory706(e.g., flash memory, static random access memory (SRAM)), and a drive unit716, which communicate with each other via a bus708.

Processor702represents one or more general-purpose processing devices such as a microprocessor, central processing unit, or the like. More particularly, the processor702may be a complex instruction set computing (CISC) microprocessor, reduced instruction set computing (RISC) microprocessor, very long instruction word (VLIW) microprocessor, or a processor implementing other instruction sets or processors implementing a combination of instruction sets. The processor702may also be one or more special-purpose processing devices such as an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), network processor, or the like. The processor702is configured to execute instructions that may include instructions to execute instructions726for performing the operations and steps discussed herein. For example, in one embodiment, the instructions726may perform any one of the methods of flow diagram400ofFIG. 4, flow diagram500ofFIG. 5and flow diagram600ofFIG. 6.

The computer system700may further include a network interface device722. The computer system700also may include a video display unit710(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device712(e.g., a keyboard), a cursor control device714(e.g., a mouse), and a signal generation device720(e.g., a speaker).

The drive unit716or secondary memory may include a computer-readable medium724on which is stored one or more sets of instructions726(e.g., instructions for the instructions) embodying any one or more of the methodologies or functions described herein. Instructions for the instructions726may also reside, completely or at least partially, within the main memory704and/or within the processor702during execution thereof by the computer system700, the main memory704and the processor702also constituting computer-readable media. Instructions726may further be transmitted or received over a network via the network interface device722. The instructions726may further be transmitted or received over a network725via the network interface device722.

The non-transitory computer-readable storage medium724may also be used to store the instructions726persistently. While the computer-readable storage medium724is shown in the illustrative examples to be a single medium, the term “computer-readable storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “computer-readable storage medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instructions for execution by the machine and that cause the machine to perform any one or more of the methodologies of the present disclosure. The term “computer-readable storage medium” shall accordingly be taken to include, but not be limited to, non-transitory computer-readable storage mediums, solid-state memories, optical media, and magnetic media.

The instructions726, components and other features described herein can be implemented as discrete hardware components or integrated in the functionality of hardware components such as ASICS, FPGAs, DSPs or similar devices. In addition, the instructions726can be implemented as firmware or functional circuitry within hardware devices. Further, the instructions726can be implemented in a combination hardware devices and software components. For example, the functionality of this module can exist in a fewer or greater number of modules than what is shown, with such modules residing at one or more computing devices that may be geographically dispersed. The modules may be operable in conjunction with network725from which it may receive and provide relevant information regarding isolating network resources in a virtualized environment.