Negotiated assignment of resources to a virtual machine in a multi-virtual machine environment

A system and method are disclosed. In one embodiment the system includes a physical resource that is capable of generating I/O data. The system also includes multiple virtual machines to utilize the physical resource. Among the virtual machines are a resource source virtual machine that is capable of owning the physical resource. The resource source virtual machine is also capable of sending a stream of one or more I/O packets generated from the I/O data that targets a resource sink virtual machine. The resource sink virtual machine is designated as a termination endpoint of the I/O data from the physical device. Also among the virtual machines are one or more resource filter virtual machines. Each of the resource filter virtual machines is capable of filtering I/O packets of a particular type from the stream prior to the stream reaching the resource sink virtual machine.

FIELD OF THE INVENTION

The invention relates to the negotiation of the assignment of resources to a virtual machine.

BACKGROUND OF THE INVENTION

Virtualization software and hardware architecture have evolved to support the concept of “device remapping.” This is the ability to take a physical device and map it to a dedicated virtual machine (VM) where the VM has complete control of the device. Optionally, the VM may offer the device's capabilities and services to other VMs, typically by implementing a device model that connects to virtual devices in other VMs. The ability to directly map a native device to a VM enables the VM to use the native capabilities of the device and interact with minimal possible overhead. “Virtual Appliance” models such as intrusion prevention or network isolation capabilities find it optimal to use this direct mapping architecture as it provides the opportunity to optimize performance and capabilities of the solution. Although direct mapping of devices works fine when a single appliance is installed on a computer platform, issues arise when multiple appliances are simultaneously installed and all wish to gain direct access to physical devices on the platform.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments of a system and method to negotiate the assignment of physical and virtual resources to a virtual machine in a multi-virtual machine environment are described. In the following description, numerous specific details are set forth. However, it is understood that embodiments may be practiced without these specific details. In other instances, well-known elements, specifications, and protocols have not been discussed in detail in order to avoid obscuring the present invention.

FIG. 1describes a system that negotiates the assignment of physical and virtual resources to a virtual machine in a multi-virtual machine environment. In many embodiments, the system described inFIG. 1resides on a computer platform such as a desktop computer, a laptop computer, a server, a handheld device, or any other type of known computer platform available. The computer platform includes components such as one or more central processing units and a memory subsystem. Additionally, the computer platform supports one or more types of hardware virtualization (e.g. Intel ® Virtualization Technology).

The computer platform includes a physical resource100(i.e. a device) that is virtualized among one or more virtual machines on the platform. In different embodiments, the device may be a network interface controller (NIC), an audio controller, or a graphics controller among other potential devices located on the computer platform.

In order to manage one or more virtual machines (VMs) on the virtualized computer platform, in many embodiments, the system includes a virtual machine manager (VMM)102. VMM102includes a configuration manager104that provides boot and runtime device assignment to the one or more VMs. Thus, during the computer platform boot, device100is assigned to one or more VMs present in the system. A VM that is assigned device100is given partial or total ownership of the resource to manage during runtime. Additionally, the configuration manager also may be required to change the assignments of one or more devices during runtime for one of a number of reasons (e.g. a device is hot-plugged into the computer system, requiring assignment to one or more VMs during runtime).

The configuration manager additionally creates and configures a device topology for each platform resource. In other words, for any given device, such as device100, one or more VMs resident within the computer platform may have requirements regarding the device. E.g. a virtual machine controlling a voice-over-Internet-protocol (VoIP) engine has certain requirements for a NIC device since the VoIP engine requires network traffic I/O (input/output).

In a computer platform that has multiple VMs, there may be more than one VM that has resource requirements for any one device. Thus, a device topology for a device may include a resource chain of assignments of that device to each VM with one or more resource requirements regarding the device. The resource chain for a given device links all VMs with one or more resource requirements regarding the device to the device itself. The configuration manager constructs the resource chain using a set of priority-based rules to resolve any potential resource conflicts among VMs for the device. Each VM that has at least one resource requirement for a device, such as device100, provides the VMM102with a resource descriptor. The resource descriptor is a data structure that describes the VM's resource requirements for one or more devices on the computer platform. The resource descriptors provided to the VMM102are stored in the VMM's VM resource descriptors106and utilized by the configuration manager104at boot time and runtime to determine the resource requirements and VM type per device for every device in the computer platform.

FIG. 1describes a three-type VM classification model per device. The configuration manager, at its discretion, can promote or demote a VM from one class of VM to another class to resolve conflicts regarding the device. The three types of VMs include a resource source VM, a resource filter VM, and a resource sink VM. Each type is described in detail below.

The resource source VM, such as resource source VM108, owns the device I/O interface, in many embodiments. The VMM assigns the device100to the guest physical address space of the resource source VM. The guest physical address space is memory address space in the computer platform that is partitioned and reserved specifically for the resource source VM. The resource source VM108is responsible for enumerating device100(i.e. physical resource), loading the physical driver110for the device, configuring the device, and starting the device. The resource source VM is required to export a virtual device interface to any other VM in the computer platform that requests the services of the device. There is only one resource source VM for a given device.

The configuration manager within the VMM, through a negotiation protocol, determines whether a VM in the system is willing to provide virtual services regarding the device to other VMs. For example, to become the resource source VM, the VM in question must be able to provide a virtual interface to the device to any other VM in the system. This interface, called a virtual device back end (VDBE) interface, is discussed below. If the VM is not capable or willing to provide this interface, among any one or more other determined services, then the configuration manager must request another VM to be designated as the resource source VM. If the configuration manager has determined that there is no VM in the system which is willing or capable of being designated as the resource source VM, then the configuration manager may designate itself as the resource source VM and can provide these virtual services to other VMs. In a situation where a VM has agreed to provide the virtual services, but has failed to actually provide these virtual services, the configuration manager may remove the physical device from the control of the VM that is failing to provide the virtual services.

A resource filter VM examines and filters a specific device's I/O traffic. In many embodiments, there may be multiple resource filter VMs present for a given device (such as resource filter VMs112and114inFIG. 1). In other embodiments, there may be only one resource filter VM present (not pictured). In yet other embodiments, there may be no resource filter VMs present (not pictured). In many embodiments, the I/O traffic is in the form of a stream of I/O data packets. For example, inFIG. 1, any given I/O data packet may be either inbound from device100or outbound to device100. In the inbound (from the device100) situation, resource filter VMs112and114may filter one or more specific types of packets.

The specific filtering each resource filter VM performs can be any one or more conceivable filtering situations. For example, a resource filter VM may provide firewall services for other VMs in the computer platform receiving network traffic from device100(when device100is a NIC). In this example, packets may be filtered based on content, originating Internet protocol (IP) address, etc.

A resource filter VM may be promoted to a resource source VM if no resource source VM is installed in the computer platform. The configuration manager104may be able to make the determination as to whether a particular resource filter VM is capable and willing for promotion based on the resource descriptor provided to the VMM.

A resource sink VM, such as resource sink VMs116,118, and120, is any VM that is an endpoint for the I/O traffic for a specific device. In the embodiment shown inFIG. 1, all inbound traffic from device100that is not filtered out of the stream by resource filter VMs112and114is terminated at the resource sink VM that the I/O traffic is targeting (this could be any of resource sink VMs116,118, or120). In many embodiments, resource filter VMs112and114only filter traffic in the inbound stream from device100. In these embodiments, all traffic (i.e. data packets) originating from resource sink VM116, pass through resource filter VMs112and114and reach the physical driver110in resource source VM108(which, in turn, potentially sends the traffic to device100). In other embodiments, resource filter VMs may also perform filtering operations on outbound traffic (from resource sink VM to device100). Similar to promotions involving the resource source VM, if no VM in the computer platform is providing the role of the resource sink VM, the configuration manager may promote a resource filter VM that is capable and willing to take that role.

The device topology, such as the resource chain shown inFIG. 1, is not dependent on any particular boot order of the VMs in the chain. The topology is relative only to the device the chain was built for (in this case device100). For any other device in the computer platform other than device100, the resource chain may be entirely different as well as each VM taking on a different role. For example, VM108that has taken on the role of the resource source VM for device100, may take on the role of the resource sink VM for another device in the computer platform.

In many embodiments, to create the resource chain, such as the chain shown inFIG. 1(i.e. resource source VM is chained to resource filter VM112, which is chained to resource filter VM114, which is chained to resource sink VMs116,118, and120), an inter-VM virtual driver model is utilized. Each VM in the chain includes a virtual driver that allows the VM to interact with adjacent VMs. In many embodiments, any given VM is adjacent to either one or two other VMs in the chain. This may be referred to as a serial chain since the VMs are chained in a series rather than in parallel. Thus, an inbound stream of data packets from device100first passes through resource source VM108, then passes through resource filter VM112, then passes through resource filter VM114, and then reaches resource sink VM116.

Every data packet in the stream (if not filtered by one of the resource filter VMs) will pass through each VM in this serial order. Thus, for each VM in the resource chain, the serially adjacent VMs are as follows: resource source VM108is serially adjacent to only resource filter VM112, resource filter VM112is serially adjacent to resource source VM108and resource filter VM114, resource filter VM114is serially adjacent to resource filter VM112and resource sink VMs116-120, and each resource sink VM (116-120) is serially adjacent to resource filter VM114.

The inter-VM virtual driver model allows for each serially adjacent pair of VMs in the resource chain to interact with each other (e.g. passing data packets in the stream between them). In many embodiments, the virtual driver on the resource source VM108interacts with the physical driver110to send and receive data packets to and from device100. In some embodiments, the resource source VM108will packetize data it receives from the device100. In other words, the physical driver110may provide data from the device100in one format and the resource source VM108may be required to format the data to send across the resource chain depending upon the requirements of one or more VMs within the resource chain.

Additionally, the virtual driver on the resource source VM108provides a virtual device back end (VDBE) interface122for a serially adjacent VM in the resource chain. The VDBE122is a virtual representation of the physical device interface that the physical driver110utilizes. Thus, resource filter VM112, which is serially adjacent in the resource chain to resource source VM108, interacts with the VDBE122as if it were the actual physical driver110.

To effectively interact with VDBE122, the virtual driver within resource filter VM112creates a virtual device front end (VDFE) interface124. Thus, for any two serially adjacent VMs, the respective virtual drivers within each of the two VMs interact with each other using a VDBE-VDFE pairing. This VDBE-VDFE pairing is able to logically couple (i.e. link) two VMs together to allow data packets in the stream to pass between the two VMs. Thus, a VDBE in a VM closer to a device is logically coupled to a VDFE in a serially adjacent VM further from the device (e.g. VDBE122in resource source VM108is logically coupled to VDFE124in resource filter VM112).

To complete the resource chain inFIG. 1, the virtual driver in resource filter VM112provides VDBE126to resource filter VM114. The virtual driver in resource filter VM114provides VDFE128to resource filter VM112and provides three separate VDBEs (130,132, and134). Each of these three VDBEs is matched to one of the resource sink VMs (i.e. VDBE130is provided to resource sink VM116, VDBE132is provided to resource sink VM118, and VDBE134is provided to resource sink120). Finally, the virtual driver in each of the three resource sink VMs provides a VDFE to resource filter VM114(i.e. resource sink VM116provides VDFE136to resource filter VM114, resource sink VM118provides VDFE138to resource filter VM114, and resource sink VM120provides VDFE140to resource filter VM114).

Each resource sink VM only has a VDFE because each one is the end of a resource chain. Therefore, there is no additional VM to provide a virtual device interface.

In many embodiments, a priority level exists per VM regarding the device. In many embodiments, when the configuration manager is creating the resource chain, the VM with the highest priority for the physical resource (i.e. device) is given the role of the resource sink. Then, once the resource sink VM has been determined, the remaining VMs, apart from the VM that was designated as the resource source VM, are chained in the order of their priority level. Where the second highest priority VM is logically coupled to the resource sink VM, the third highest priority VM is logically coupled to the second highest priority VM and so on.

In many embodiments, there are multiple physical resources on the computer platform. For each physical resource, a resource source VM is designated, though, the resource source VM for a first physical resource may be any type of VM for a second resource. For example, for a first physical resource, a first VM may be designated as a resource source VM, for a second physical resource, the first VM may be designated as a resource sink VM, for a third physical resource, the first VM may be designated as a resource filter VM, and for a fourth physical resource, the first VM may not be associated at all with the fourth physical resource, so no designation applies. In many embodiments, the first VM may provide all of these different VM roles for these different physical resources simultaneously.

FIG. 2is a flow diagram of one embodiment of a process to configure a virtual machine resource chain. The process is performed by processing logic that may be hardware, software, or a combination of both. Turning toFIG. 2, the process begins by processing logic within the configuration manager determining which of a group of VMs will be designated as the resource source VM through a resource descriptor provided by each VM (processing block200).

Then processing logic determines whether a resource source VM exists for designation (processing block202). If there is a designated resource source VM, then processing logic within the VMM launches each VM of the group of VMs and waits until all VMs in the group give a successful boot signal (processing block204).

If there is no designated resource source VM, then processing logic within the configuration manager searches through any resource filter VMs within the group of VMs to determine if one is available to promote to the resource source VM (processing block204). In many embodiments, processing logic utilizes the VM resource descriptors to determine whether there is a resource filter VM willing and capable of promotion.

Next, processing logic determines whether a resource filter VM has been found to promote (processing block206). If a resource filter VM exists to promote, then processing logic proceeds to processing block210(described above). Otherwise, if a resource filter VM does not exist to promote, then the VMM assumes the resource source VM responsibility (processing block208). In this situation the VMM is the only component in the computer platform that has the capability or is willing to be the resource source VM.

Then processing logic, once determining the resource source, performs processing block210as described above. Next, processing logic within the VMM sorts the VMs in the group according to resource type (i.e. source, filter, sink) and resource priority (processing block212). Once all VMs in the group have been sorted, then processing logic within the VMM creates a suitable resource chain configuration (processing block214) taking into account the priority levels of each VM as well as any potential resource conflicts.

Finally, processing logic within the VMM creates the front end and back end virtual driver interfaces for each VM (utilizing the inter-VM virtual driver model) and logically couples each serially adjacent VM pair together into the resource chain (processing block216) and the process is finished.

FIG. 3is a flow diagram of a process to stream and potentially filter one or more packets from a resource source to a resource sink. The process is performed by processing logic that may hardware, software, or a combination of both. Turning toFIG. 3, the process begins by processing logic sending a data packet (as part of a stream) from a resource source VM (processing block300). The data packet passes through a resource filter VM and processing logic within the resource filter VM applies its filter to the data packet (processing block302).

Processing logic determines whether the filter removes the packet from the stream (processing block304). If it is determined that the filter does remove the packet then processing logic physically removes the packet from the stream (processing block306) and the process is finished. Otherwise, if it is determined that the filter does not remove the packet from the stream, then processing logic determines if the packet passes through another resource filter VM (processing block308). If the packet does pass through another filter, then the process repeats starting at processing block302. Otherwise, if the packet has no more resource filter VMs to pass through, then processing logic within the resource sink VM receives the packet (processing block310) and the process is finished.

Thus, embodiments of a system and method to negotiate the assignment of physical and virtual resources to a virtual machine in a multi-virtual machine environment are described. These embodiments have been described with reference to specific exemplary embodiments thereof. It will be evident to persons having the benefit of this disclosure that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the embodiments described herein. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense.