Swapping non-virtualizing and self-virtualizing devices

A computer in a cloud computing environment includes a virtualization instance (VI) providing cloud services to a consumer device. The computer includes non-virtualizing and self-virtualizing type devices. The VI uses a first virtual device that is a virtual form of one of the non-virtualizing and self-virtualizing type devices to meet Quality of Service (QoS) objectives. A method for managing the resources of the cloud comprises receiving QoS metrics, determining that the VI cannot meet the QoS objectives using the first virtual device, determining that a second virtual device comprising a virtual form of the non-virtualizing and self-virtualizing type device alternative to that of first virtual device is available and can meet the QoS objectives, and configuring the VI to use the second virtual device in place of the first virtual device. A computer programming product and a system can embody the method.

BACKGROUND

The present disclosure relates to managing computing resources in a cloud computing environment and, more particularly, to managing resources associated with virtualized computing devices.

SUMMARY

According to embodiments of the present disclosure, a processor can perform a computer-implement method to manage cloud computing resources. In performing the method, the processor receives Quality of Service (QoS) metrics associated with a virtualization instance (VI) of a cloud computing environment. The processor receives the metrics via an interface communicatively coupled to the processor. The VI provides cloud computing services to a consumer device accessing cloud computing services, and the VI is associated with VI QoS objectives. The VI QoS objectives correspond to the VI providing the cloud computing services to the consumer device.

The VI is configured to use a virtual device to meet the QoS objectives. In response to receiving the QoS metrics, and based on a comparison of the QoS metrics with the VI QoS objectives, the processor determines that the VI is unable to meet the VI QoS objectives using the virtual device. Based on the VI unable to meet the VI QoS objectives using the virtual device, the processor determines that the virtual device is a virtual form of a non-virtualizing computing device, that a substitute virtual device, comprising a virtual form of a self-virtualizing computing device, is available to substitute for the virtual device, and that VI is able to meet the VI QoS objectives using the substitute virtual device. Based on the VI able to meet the VI QoS objectives using the substitute virtual device, the processor configures the VI to use the substitute virtual device in place of the virtual device.

In some embodiments, the VI is configured to use a second virtual device to meet the VI QoS objectives, and the method can further include the processor performing a second comparison of second QoS metrics with the VI QoS objectives. In response to receiving the second QoS metrics, and based on a comparison of the second QoS metrics with the VI QoS objectives, the processor determines that the VI is able to surpass the VI QoS objectives using the second virtual device. Based on the VI able to surpass the VI QoS objectives using the second virtual device, the processor determines that the second virtual device is a virtual form of a non-virtualizing computing device, that a second substitute virtual device, comprising a virtual form of a self-virtualizing computing device, is available to substitute for the second virtual device, and that VI is able to meet the VI QoS objectives using the second substitute virtual device. Based on the VI able to meet the VI QoS objectives using the second substitute virtual device, the processor configures the VI to use the second substitute virtual device in place of the second virtual device.

In embodiments, the QoS metrics can include performance indicators associated with at least one of the VI, the second virtual device, and a component among the components underlying the first virtual device, and the processor can determine that the VI is able to surpass the VI QoS objectives using the first or second virtual device based on the performance indicators. In some embodiments, each of the non-virtualizing computing device and the self-virtualizing computing device can comprise a network device.

A computer-programming product can embody features of the method. A system, comprising a computer in a cloud computing environment and a QoS manager in communication with the computer, can embody aspects of the method. The computer comprises a VI, a first computing device comprising a non-virtualizing type device and a second computing device comprising a self-virtualizing type device. The QoS manager comprises one or more processors to perform features of the method and cause the computer to configure the VI to use a substitute virtual device in place of a virtual device configured in the VI to meet the QoS objective, according to aspects of the method.

DETAILED DESCRIPTION

Aspects of the present disclosure (hereinafter, “the disclosure”) relate to allocation of virtual device resources to virtualization instances (e.g., virtual machines) in a cloud computing environment. More particular aspects relate to dynamically interchanging virtual device resources using underlying physical computing devices that do not have self-virtualization capabilities and virtual device resources using underlying physical computing devices that have self-virtualization capabilities, and vice-versa.

While the disclosure is not necessarily limited to such applications, various aspects of the disclosure may be appreciated through a discussion of various examples using this context. It is to be further understood that although this disclosure includes a detailed description of aspects and elements of cloud computing, implementation of the teachings recited herein are not limited to a cloud computing environment or components and/or functions thereof.

Cloud computing is a model of computing service delivery to “cloud consumers” that can enable a cloud consumer to have convenient, on-demand network access to a shared pool of configurable computing resources within a cloud computing environment (e.g., computing devices and/or virtual instances thereof, networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and computing services). It is further an aspect of cloud computing environments that cloud computing resources can be rapidly provisioned and released with minimal management effort or interaction between a cloud consumer and a provider of cloud computing services (hereinafter, “provider”). As used herein, “cloud” refers to any cloud computing environment such as, but not necessarily limited to, embodiments described herein.

A cloud consumer can be, for example, a computing device or computing application, and/or a computing or other electronic device used by a human user (or, users) capable of accessing cloud computing services (hereinafter, “cloud services”) via an on-demand computing network. A cloud consumer can be a human user, or a human organization or enterprise, and human users can use a consumer device to provision, access, and/or receive cloud computing services. As used herein, “consumer device” refers to any computing or electronic device (or, computing application executing therein) connected to, or capable of connecting to, a cloud computing environment to provision, access, and/or receive cloud services provided by a cloud computing environment, whether operating autonomously or at the direction of a human user. Further, “consumer”, as used herein, refers interchangeably to a user of a consumer device (e.g., a human, or an application executing on a consumer device) and a consumer device used by, or operating as, a consumer to access a cloud and/or resources thereof.

It will be apparent to one of ordinary skill in the art that a “cloud consumer” can be any entity external to a cloud that can access the cloud by one or more consumer devices connected to on-demand networks to receive computing services provided by the cloud.

A cloud computing model can include at least five characteristics, at least three service models, and at least four deployment models.

Cloud computing comprises at least these five characteristics:

Broad network access: capabilities are available over a network and accessed through standard mechanisms that promote use by heterogeneous thin or thick client (e.g., consumer device) platforms (e.g., mobile phones, laptops, and PDAs).

Cloud computing comprises at least three service models:

Infrastructure as a Service (IaaS): the consumer is provided with the capability to provision processing, storage, networks, and other fundamental computing resources where the consumer is able to deploy and run arbitrary software, which can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and possibly limited control of select networking components (e.g., host firewalls).

Cloud computing comprises at least these four deployment models:

Private cloud: the cloud infrastructure is operated solely for an organization. It can be managed by the organization or by a third party, and can exist on or off the consumer premises, or can exist in a combination of both on and off the consumer premises.

Community cloud: the cloud infrastructure is shared by more than one organization and supports a specific community that has shared concerns (e.g., mission, security requirements, policy, and compliance considerations). It can be managed by the organizations or by a third party and can exist on or off the consumer premises, or can exist in a combination of both on and off the consumer premises.

A cloud is service oriented with a focus on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.FIG. 1illustrates example cloud50. As shown, cloud50includes one or more cloud computing nodes10, Consumer (e.g., computing) devices used by, or operating as, cloud consumers—such as, for example, personal digital assistant (PDA) or cellular telephone54A, desktop computer54B (which can, alternatively, be a server or other type of computer), laptop computer54C, and/or automobile computer system54D—can communicate with nodes among nodes10. Nodes10can include computing devices such as, for example, mainframe computers, server computers, storage systems, and/or storage servers, and network components, such as switches, gateways, and/or routers. Nodes10can include, for example, compute nodes, storage nodes, network nodes, and/or virtualization instances (e.g., virtual machines) that can execute on computing devices among the nodes.

Nodes10can communicate with one another, such as by, for example, Local Area Networks (LANs), Wide Area Networks (WANs), point-to-point links, and/or I/O buses, or combinations of these, within and/or connected to the cloud. They may be grouped (not shown) physically or virtually, in one or more computing clouds, such as Private, Community, Public, or Hybrid clouds as previously described herein, or a combination thereof. This allows cloud50to offer infrastructure, platforms and/or software as services for which a cloud consumer does not need to maintain resources on a local computing, or consumer, device. It is understood that the types of computing devices54A-54D shown inFIG. 1are intended to be illustrative only and that computing nodes10and cloud50can communicate with any type of computerized device over any type of network and/or network addressable connection (e.g., using a web browser).

FIG. 2illustrates an example set of functional abstraction layers that a cloud, such as50inFIG. 1, can provide. It should be understood that the components, layers, and functions shown inFIG. 2are intended to be illustrative only and embodiments are not limited thereto. For example, whileFIG. 2illustrates various components and functions of a cloud computing system as organized into particular example abstraction layers, it is not necessary that components or functions of a cloud be organized according to the particular abstraction layers illustrated inFIG. 2, be implemented within a particular one of these layers, or be constrained to a particular one of these (or, other) layers. Rather, it would be apparent to one of ordinary skill in the art that embodiments can organize components, layers, and functions performed within a cloud utilizing more or fewer layers, or differing types of layers, than as shown in the example ofFIG. 2.

As depicted inFIG. 2, hardware and software layer60includes software and hardware components. In some embodiments, software components can include network software67and database software68. Examples of hardware components include: mainframes61, RISC (Reduced Instruction Set Computer) architecture based servers62, rack mount servers63, blade servers64, storage devices65, and networks and networking devices66. Network components66can include, for example, network routers and/or gateways, network adapters, or “network interface cards (NICs)”, and/or network ports. As used herein, “NIC” refers to any form of network interface card that can interconnect processors and/or memory of a computer to a communications network, such as an Ethernet, or other type of physical communications network.

In embodiments, servers61-64can include processors and memories, storage devices and/or media, and network hardware. For example, servers61-64can include storage similar to storage65, and/or network components similar to66, as components within the servers or can access storage, such as65, and/or network hardware, such as66, as components external to the servers within a cloud such as50inFIG. 1.

Virtualization layer70can provide virtual entities such as (for example) virtualization instances (e.g., virtual machines or servers)71, virtual storage72, virtual networks73(which can include virtual private networks and/or virtual local area networks, or “VLANs”), virtual applications and operating systems74, and virtual clients75. In embodiments, virtualization layer70can include virtual devices (not shown inFIG. 2), such as, for example, virtual processors, virtualized memory, virtual disks (e.g., virtual hard drives), and virtual network devices (e.g., virtual network adapters and/or network ports).

Also in embodiments, a virtualization layer, such as70, can include virtualization functions such as hypervisor76. A hypervisor can operate to create virtual entities and/or virtual devices, and can operate to manage use of virtual entities and/or devices by components of other layers. A hypervisor can be implemented in various embodiments as firmware or an operating system, an application executing within an operating system, and/or a combination of any of these. Components of a hypervisor can be components of hardware and software layer60, of virtualization layer70, or components of both of these layers.

Management layer80can provide, in some embodiments, computing and cloud system management functions. Resource provisioning81can provide, for example, dynamic procurement of computing resources and other resources that are utilized to perform tasks within the cloud, such as components of hardware and software layer60, and/or virtual entities and/or virtual devices included in layer70. Metering and Pricing82can provide, for example, cost tracking as resources are utilized within the cloud, and billing or invoicing for consumption of these resources. In one example, these resources can include application software licenses.

User portal83can provide, for example, access to the cloud by consumer devices (a consumer device used by, for example, a system administrator). Service level management84can provide, for example, cloud computing resource allocation and management such that required service levels are met. Service Level Agreement (SLA) planning and fulfillment85can provide, for example, pre-arrangement for, and procurement of, cloud computing resources for which a future requirement is anticipated in accordance with an SLA. Security86can provide, for example, identity verification for cloud consumers, consumer devices, and/or tasks or computing applications, as well as protection for data and other resources.

Workloads layer90can provide functionality for which the cloud may be utilized. For examples, workload layer90can provide workloads and functions such as mapping and navigation91, software development and lifecycle management92, virtual classroom education delivery93, data analytics processing94, and transaction processing95.

Individual consumers (or, alternatively, individual groups of related users) can require a secure and exclusive computing environment to execute workloads providing cloud services to consumer devices used by those consumers. Various software and/or hardware technologies are known to provide secure, exclusive computing environments. For example, Virtual Machines (VMs) and software containers (e.g., Linux Containers), and “physical partitions”, which rely on partitioning of hardware within a computing system based on strict physical (e.g., hardware unit) boundaries, are examples of technologies that can provide a secure, exclusive computing environment for consumer devices to access a cloud. Clouds can implement secure, exclusive computing environments for consumer devices to access cloud computing resources using any particular one, or any particular combination, of such technologies. As used herein, “Virtualization Instance”, or “VI”, refers to any computing technology—such as VMs, containers, and/or physical partitions—that can provide a cloud consumer device with a secure and exclusive computing environment. In providing cloud services to a particular consumer device, a cloud can employ one or more of such VIs to provide cloud services to a particular consumer device, or a plurality of consumer devices, according to the manner in which the cloud provides services to the consumer devices.

VIs can include virtual devices, such as virtual processors, virtual memory, virtual storage, and/or virtual network devices, such as previously described in reference toFIG. 2layer70. Embodiments can implement VIs and/or virtual devices using, for example, hardware components within the cloud, such as within servers61-64, storage65, and network components66of layer60inFIG. 2. Embodiments can include, for example, virtual processors corresponding to physical components within a server such as processors (or, components thereof, such as processor thread), virtual memory corresponding to physical memory, and virtual network devices corresponding to physical network adapters and/or physical network ports.

FIG. 3illustrates an example embodiment of a cloud that can provide secure, exclusive computing environments to consumer devices using VIs. Cloud300inFIG. 3is simplified to illustrate the disclosure but is not intended to limit embodiments. Cloud300includes application servers302A,302B, and302C (collectively, “servers302”), networks306A and306B, and storage servers308A and308B. Consumer devices310A,310B, and310C (collectively, “consumers310”) are connected to computing resources of cloud300(and, possibly to each other) by means of connections to one of networks306A and306B. Using these network connections, consumers310can access computing resources of cloud300, such as one or more of servers302, and/or one or more of storage servers308A and308B.

Servers300further include VIs, such as illustrated by VIs304A,304B, and304C (collectively, “VIs304) hosted (or, “executing”) on server302A. VIs304can provide a secure, exclusive computing environment for consumer devices among consumers310. Cloud300can allocate one or more of VIs304to particular consumer devices, among consumers310, and the consumer devices (and/or consumers using those consumer devices) can specify particular SLA requirements to a cloud provider owning or managing cloud300.

VIs can provide consumer devices with physical and/or virtual computing resources associated with a server hosting one or more VIs (referred to herein as a “hosting server”). Virtual resources, in particular, can enable a cloud to share physical computing resources in a highly flexible manner, such as dynamically changing the amount, type, and/or physical location, of a computing resource (or, device) as the computing resource demands of consumer devices, cloud services, VIs, and/or servers change while a cloud is providing cloud services. Physical computing resources that can be virtualized include, for example, physical processor cores and/or threads of processor cores; physical memory units or regions of memory units; storage devices, such as disk or solid state drives; and/or, network devices such as network adapters (or, in some embodiments, NICs), or facilities of such adapters, such as network ports.

FIG. 4illustrates an example embodiment of a computer having physical resources that can be virtualized and included, in virtualized form, in one or more VIs to provide cloud services and/or resources to consumer devices. Server computer400(hereinafter, “server400”) can be a server computer, such as one of servers302inFIG. 3or servers61,62,63, and/or64inFIG. 2, included in\ a cloud. Server400includes hardware components430, which include physical processors434A and434B and physical memory440interconnected by means of interface432, which can be, for example, a processor or memory bus, or other forms of component interconnections known in the art. Memory440contains instructions442(e.g., programs) which processors434A and/or434B can execute, and instruction output444, which can be the results of the processors executing instructions442, for example. While not shown inFIG. 4, memory440can also include data used by programs executing on processors434A and/or434B.

Hardware430also includes input/output (I/O) devices438A and438B, connected to processors434A and434B, and memory440, by means of I/O bridge436. I/O devices438A and438B can devices such as keyboards, mice, network interface devices, storage devices (e.g., disk or solid state disk storage) and/or storage interface devices. In some embodiments, I/O devices438A and438B can be, for example, network adapters, which can include network ports that connect to a network (e.g., an Ethernet, or the Internet) and can enable processors434A and/or4334B to communicate with computing devices connected to that network.

Server400is depicted having software components420. Software components among420include firmware428, hypervisor426, VIs422A and422B, and programs424A,424B, and424C (referred to collectively herein as “programs424”) hosted by the VIs. The term “software”, as used herein, should be understood to encompass all varieties of computer program embodiments comprising computer-executable instructions, such as micro-code, milli-code, firmware, software loaded from a storage medium, licensed program products, and such other varieties of computer program embodiments as are known to those of ordinary skill in the art.

VIs422A and422B can be VMs, containers, physical partitions of server400hardware430, or combinations of these. Programs among programs424can be, for example, software containers (e.g., within a VM), components of an operating system, and/or application programs. Programs among programs424can be accessed and/or used by consumer devices, or by a VI, while server400is used by a cloud to provide cloud services to those consumer devices. Some or all of software components420can be embodied within instructions442stored in memory440, and some or all of the results, and/or data used by, programs executing in server400can be stored in memory440as instruction output444. Alternatively, some of all of software components420can be embodied in other media (not shown), such as Non-Volatile Random Access Memory (NVRAM) or flash memory, hard drive or solid state disk (SSD), compact disk (CD), and/or digital video disk (DVD), for example.

Firmware428can include, for example, instructions (e.g., programs) that enable programs, such as hypervisor426, programs among programs424, programs included in firmware428, and/or other programs (not shown) that can execute in server400, to manage, monitor, and/or control components within hardware430. Hypervisor426can operate to create and/or manage VIs, such as422A and422B. Hypervisor426can be embodied as an operating system, or component thereof, executing within server400. In alternative embodiments, hypervisor426can be “built-in” within server400, such as comprising one or more programs embodied wholly or partially in firmware428.

Programs within a VI can create and/or manage other VIs, either external to or within that VI. A hypervisor, VM, or other form of VI, can create and/or manage other VIs. For example, a hypervisor can create and/or manage VMs; a VM operating as a “host” VM (or, hypervisor) can creating and/or manage guest VMs; and, an operating system executing in a VM can create and/or manage software container VIs within that VM. Hypervisor426, and/or VIs422A and422B, create and/or manage “virtual devices” (not shown) associated with physical resources among hardware430, such as virtual processors, virtual storage devices, and/or virtual network devices. Programs operating in (or, “hosted” by) VIs422A and/or422B can provide cloud services to consumer devices and can utilize virtual devices in providing those services. Hypervisor426can manage and/or dynamically allocate and/or de-allocate particular virtual devices to VIs422A and/or422B. VIs422A and422B can manage and/or dynamically allocate and/or de-allocate particular virtual devices to programs operating within these VIs (including VIs encapsulated within VIs422A and/or422B, such as containers within a VM).

Server400can receive input410(e.g., from one or more computing devices external to server400) by means of interface412. Interface412can be any of a variety of interfaces known in the art to communicatively couple functions and/or components of one computing device or system (e.g., a computing device that can provide input410to server400), with functions and/or components of the same or, alternatively, another computing device or system (e.g., server400). Examples such interfaces include: a network or other communications interface; an I/O or processor bus or interconnect; a shared memory; a messaging interface; a program call, exception, or interrupt; and, so forth as are common in the art. In alternative embodiments, interface412can be an interface internal to server400, such as among the examples just described, and can couple components internal to server400(e.g., components of software420and/or hardware430).

Input410can be, for example, data or instructions to direct server400to perform particular operations or, in another example, to report operating conditions of server400or components thereof (e.g., one or more components among software420and/or hardware430). Input410can be associated with services delivered to consumer devices by a cloud that includes server400. For example, input410can be a program (e.g., an application or workload) and/or data to execute on server400for a consumer device accessing the cloud services. In another example, input410can be instructions to server400(or, components thereof) to perform particular operations associated with providing cloud services to a consumer device, such as instructions directing server400to modify resources of server400(e.g., components of software420and/or hardware430) used in providing the cloud services.

WhileFIG. 4illustrates server400as having particular hardware and software components, this is not intended to limit embodiments. Rather, it will be appreciated by one of ordinary skill in the art that embodiments can include a variety of other hardware and/or components in addition to and/or different from those illustrated inFIG. 4. It will be further appreciated by one of ordinary skill in the art that embodiments can include more or fewer instances of components illustrated inFIG. 4, such as more or fewer VIs and/or programs, memories, processors, etc.

FIG. 5illustrates an example system for managing virtual resources in a computer and/or cloud computing environment. System500includes QoS manager502and server510, which can be a server (i.e., a computer) similar to computer400ofFIG. 4. QoS manager502and server510are shown communicatively coupled by means of interface504. QoS manager502can be, for example, a component or function operating in one or more computing devices communicatively coupled to server510by means of interface504. Interface504can be any of a variety of interfaces known in the art, to communicatively couple computing devices, such as previously described in reference to interface412ofFIG. 4, and which can enable QoS manager502to communicate with server510or components thereof. In alternative embodiments, QoS manager can be a component of server510and interface504can be an interface internal to server510(e.g., such as those previously described in reference to interface412ofFIG. 4)

For simplicity of the illustration, server510is shown without all of the hardware components430and software components420illustrated in the example ofFIG. 4; However, it will be understood by one of ordinary skill in the art that server510can have similar hardware and/or software components, and these can be configured similarly to the manner of example server400ofFIG. 4. Server510can be a node included in a cloud, such as a node among nodes10ofFIG. 1.

Server510includes hypervisor520and VIs512A and512B. Consumer devices accessing a cloud that includes server510can use, or access, VIs512A and/or512B to receive cloud services. Server510further includes network adapter530(hereinafter, “adapter530”) and network adapter540(hereinafter, “adapter540”). Adapter530includes physical network ports532A and532B and adapter540includes physical network ports544A and544B. Physical ports532A,532B,544A, and544B can, in turn, connect server510to network560, which can be, for example, a network such as an Ethernet or the Internet. While not shown inFIG. 5, consumer devices, and/or other components of a cloud providing cloud services to consumer devices, can connect to server510by means of network560(or, alternative networks not shown inFIG. 5) and can receive cloud services from server510by means of network560(or, alternative networks not shown inFIG. 5).

A server, such as510, can include virtual devices corresponding to physical hardware resources in the server, and the virtual devices can be used by VIs to provide cloud services to consumer devices. As previously described, virtualizing physical resources of a server (e.g., network adapters) can allow for more efficient sharing of those physical resources by multiple components (e.g., VIs) of a computing system, where capacity of those physical resource might be otherwise un- or under-utilized if fully dedicated to a single element (e.g., a single VI). Virtual devices can include virtual network devices, such as a virtual network interface card (VNIC), a virtual switch (VSWITCH), and a virtual Ethernet adapter (VEA).

Server510includes virtual network devices VSWITCH522, VNICs518A-518C (collectively, “VNICs518”), and VEA508. Hypervisor520(or, in alternative embodiments, another virtualization function or component of a computing system) can create the server510virtual network devices utilizing physical network devices of server510, such as adapters530and540and their respective physical ports532A,532B,544A, and544B. The server510virtual network devices can be virtual instances of underlying physical (e.g., hardware) devices. As shown, VEA508is a virtual instance of underlying adapter540, VPORT542A, and port544A, and each of VNICs518are virtual instances of underlying adapter530and port532A.

VIs512A and/or512B can utilize the server510virtual network devices to communicate, over network560and/or VSWITCH522, with other VIs within server510or other computing components within or external to server510, such as other servers within or external to the cloud, and/or consumer devices. A cloud can use VIs512A and/or512B to provide cloud services to consumer devices, and VIs512A and/or512B can, in turn, utilize the virtual network devices in providing those services.

In embodiments, physical (e.g., hardware) resources and/or devices can be of such a design that they provide particular functions, such as network functions, but do not provide any additional capabilities particularly in support of virtualizing those hardware resources and/or devices. As used herein, “adapter” refers to a computing device adapted to provide or perform functions associated with computer or computing system I/O. As used herein, “non-virtualizing adapter” refers to an I/O adapter that does not include intrinsic capabilities (i.e., within the adapter) directed towards virtualizing components or functions of that adapter (or, computing device). Accordingly, to provide virtual resources using a non-virtualizing adapter, embodiments can require software to emulate functions required for virtualization of a non-virtualizing adapter. A hypervisor (for example), or other virtualization function or component of a computing system, can implement virtual resources, and/or virtual devices, as software functions and/or components that utilize the resources and capabilities of an underlying physical adapter.

For example, an embodiment can require software (as one or more programs particular to computing resource type) to implement virtual devices, such as VNICs518, and/or VSWITCH522. As used herein, but not intended to limit embodiments, “VNIC” refers to a virtual network device (e.g., a virtual network interface card or network port) utilizing an underlying non-virtualizing network adapter. Embodiments can virtualize resources of a non-virtualizing adapter using, for example, an I/O server. I/O server514can function as an intermediary between VNICs in VIs of server510to share resources of adapter530and/or to communicate with network560. I/O server514can be a VI, or other program(s), executing independently or, alternatively, within a VI of server510.

A disadvantage of providing virtual devices using an underlying non-virtualizing adapter can be that software components implementing the virtual devices, or included in the communications paths of a virtual device, can increase utilization of processors in a server executing these software virtualization functions (which can in turn reduce virtual device bandwidth and/or throughput) and/or can add latency to virtual device operations (which can, in turn, reduce overall virtual device throughput). For example, VSWITCH522, VNIC518C, and device driver516underlying and in the communications paths of VNICs518A and/or518B to adapter530and/or network560can increase utilization of processors in server510used by I/O server514and can increase network latency (with possible accompanying reductions in throughput) for VI512A and/or512B network communications.

As alternative to or, in addition to, implementing virtual devices using underlying non-virtualizing adapters, embodiments can implement virtual devices using a “self-virtualizing” type of adapter. A self-virtualizing adapter is a type of adapter that has intrinsic capabilities to virtualize functions of the adapter. An advantage of implementing virtual devices using a self-virtualizing adapter can be that a self-virtualizing adapter can avoid the need to implement virtual resources in software interfacing with the adapter, and the associated software performance overhead. For example, a self-virtualizing adapter can provide resources and functions internally that can create a virtual port, or “VPORT”, within the adapter itself, utilizing only resources (such as hardware specific to virtual instances of adapter facilities or resources) internal to the adapter. Accordingly, self-virtualizing adapters can reduce or avoid additional software virtualization functions (e.g., a VSWITCH and/or an I/O server) between a virtual device and the underlying self-virtualizing adapter, which can in turn reduce or eliminate performance overhead associated with such software virtualization functions.

Adapters that conform to the Peripheral Component Interface-Express (PCI-E) Single-Root I/O Virtualization (SR-IOV) design standard are an example of self-virtualizing adapters. PCI-E SR-IOV adapters (hereinafter, “SR-IOV adapters”) can provide “Virtual Functions (VFs)” associated with particular physical devices (e.g., physical ports) of an adapter and that are virtual instances of those physical devices. For example, an SR-IOV network adapter can embody a VPORT as a VF of the adapter and associated with particular physical resources of the adapter (e.g., Ethernet network ports).

In some embodiments, particular SR-IOV VFs of the same adapter can be of different types. For example, an Ethernet type SR-IOV adapter can have one or more Ethernet ports and can provide either or both Ethernet VFs and, for example, Fiber Channel Over Ethernet (FCoE) VFs, which function as Ethernet protocol or FCoE protocol virtual devices, respectively. In some embodiments, Ethernet and FCoE VFs provided by an Ethernet SR-IOV adapter can be configured to share the same physical Ethernet port or to operate using different physical ports.

Referring again to the example ofFIG. 5, adapter540can be a self-virtualizing adapter and can provide virtual instances—VPORTs542A,542B, and542C—of physical ports544A and/or544B within adapter540. For example, adapter540can be an SR-IOV adapter and VPORTs542A,542B, and542C can be implemented as SR-IOV VFs within adapter504. VEA508can interface directly with VPORT542A to communicate with network560. In some embodiments VEA508can embody functions to directly control and/or manage hardware elements of adapter540encapsulated within VPORT542A, an/or to communicate with network560, in a manner similar to the manner in which device driver516can directly control and/or manage hardware elements of adapter530and communicate with network560. In this way, self-virtualizing adapter540can avoid most or all of the software performance overhead associated with VNICs518A and518B accessing facilities of adapter540and/or network560.

While a self-virtualizing adapter of a particular type (e.g., a two-port 10 gigabit Ethernet adapter) can provide higher performing virtual devices than a comparable non-virtualizing adapter, such self-virtualizing capabilities can also increase the cost of that self-virtualizing adapter in comparison to the comparable non-virtualizing adapter. Accordingly, a computer server can be configured to utilize a greater number of non-virtualizing adapters than self-virtualizing adapters. An administrator, or management function, of a computer server can prefer to configure virtual devices to use lower-cost non-virtualizing adapters where such virtual devices can meet performance requirements of VIs to deliver cloud services to particular consumer devices, or to provide a higher level of availability of higher performing self-virtualizing adapters for server operations or cloud services require that that level of performance. Where particular VIs require higher performance to deliver cloud services to particular consumer devices, a computer server (or, an administrator or management function of a computer server) can configure virtual devices for these VIs that use higher performing self-virtualizing adapters.

Consumers using cloud services can have a Service Level Agreement (SLA), or other form of agreement, with a cloud service provider that can specify requirements that the cloud service provider must meet when delivering services to the consumer, and/or consumer device(s) used by the consumer, such as particular cloud computing performance requirements. Such requirements can be associated with Quality of Service (QoS) levels provided by cloud computing resources to particular consumer devices. For example, QoS settings can be specified for one or more particular VIs used, or accessed, by particular consumer devices.

QoS settings can specify particular QoS requirements (e.g., minimum QoS levels), VI QoS objectives (e.g., QoS goals that are not necessarily requirements), or a combination of these, for one or more of the VIs providing cloud services to a particular one or more consumer devices. QoS requirements can include particular expected levels of performance, for example, such as a level of processor, network, and/or storage performance and/or capacities provided to a VI. QoS objectives can include a desired, or preferred, level of performance. A consumer may be willing to pay higher service costs to obtain preferred performance levels included in QoS objectives. QoS settings can include particular consumer criteria under which a cloud service provider (or, a VI used to provide cloud services) should provide a particular level of service, such as at particular times of day, at particular levels of utilization of one resource (e.g., increased network bandwidth corresponding to increased processor utilization by a VI). As used herein, “VI QoS objectives” comprises at least VI QoS objectives, QoS requirements, and consumer criteria that can be included in QoS settings associated with particular VIs in providing cloud services to particular consumer devices using those VIs.

A cloud service provider can meet VI QoS objectives of one or more particular consumer devices, as represented in QoS settings for (i.e., associated with) those consumer devices, through various means of managing computing resources within a cloud. For example, as a particular VI increases the demand (e.g., throughput, or utilization) placed on a computing resource (e.g., a network resource), or the ability of cloud resources used by a VI to deliver cloud services decreases, a cloud can substitute higher performing virtual resources for those presently in use by the VI to meet corresponding VI QoS objectives. Alternatively, as a particular VI decreases the demand (e.g., throughput, or utilization) placed on a computing resource (e.g., a network resource), or the ability of cloud resources used by a VI to deliver cloud services increases, a cloud can substitute lower performing virtual resources for those presently in use by the VI and continue to meet corresponding VI QoS objectives.

To illustrate, but not intended to limit embodiments, server510ofFIG. 5can be a server in cloud300ofFIG. 3, and cloud300can include QoS manager502inFIG. 5in communication with server510as illustrated inFIG. 5. Server510can be used by cloud300to provide cloud services to consumer device310A, for example, and consumer device310A can use VI512B to access or receive those cloud services. As will be described, QoS manager502can operate to manage virtual resources used by VI512B to provide cloud services to consumer device310A.

Consumer device310A can have an SLA that determines or specifies particular QoS settings for delivering cloud services to consumer device310A. The QoS settings can, optionally, also specify a preferred level of network performance. In some embodiments, a cloud service provider can charge a greater than prevailing charge for cloud services when providing the preferred levels of network performance; and, a consumer device, such as310A, may be willing to pay that greater charge and this can be included in QoS settings associated with providing cloud services to consumer device310A. The QoS settings can correspond to particular QoS objectives associated with VI512B, and the QoS objectives can include a particular minimum level of network performance (e.g., data rate, bandwidth, and/or network latency, such as Internet Protocol, or “IP”, packet latency) required by VI512B to meet those objectives.

A cloud (or, the cloud service provider owning cloud300) can have a resource management policy to select particular virtual network resources for us by VIs to provide cloud services to consumer devices. For example, a resource management policy can preferably select the lowest capacity network resources possible to meet the network QoS settings of any particular VI, or to preferably leave higher performing (and, possibly more expensive) network resources available for VIs having higher QoS network performance objectives. A resource management policy can preferably leave higher performing (and, possibly more expensive) network resources available for delivering services to consumer devices used by consumers willing to pay higher than prevailing charges for those resources.

QoS manager502(or, other components of cloud300and/or server510) can implement a resource management policy and select a particular virtual network device to provide network services to a VI based partially, or wholly, on the policy in combination with QoS objectives for a particular VI. For example, either of VEA508or VNIC518A can provide network services for VI512B to deliver services to consumer device310A. VNIC518A utilizes adapter530, which can be a lower cost (in some embodiments, possibly much lower cost) than adapter540, utilized by VEA508. Provided VNIC518A, using non-virtualizing adapter530, can meet the VI512B QoS objectives for delivering cloud service to consumer device310A, and possibly based on a cloud300resource management policy, QoS manager502can prefer to select VNIC518A and non-virtualizing adapter530, as lower-cost and/or lower-performing than a virtual device using adapter540, or to leave resources of higher performing adapter540available to select for other VIs having higher QoS performance objectives or willing to pay for higher performance.

However, while VI512B is providing cloud services to consumer device310A, VNIC518A, and/or network components underlying VNIC518A (e.g., VNIC518C, DD516, and/or adapter530and port532A), can experience conditions that can cause VI512B to no longer meet the VI512B QoS objectives associated with consumer device310A. For example, utilization of network components underlying VNIC518A can increase and can result in VNIC518A having insufficient network performance (e.g., reduced throughput or bandwidth, or increased latency) to meet VI512B QoS objectives for delivering services to consumer device310A. Alternatively, while providing services to consumer device310A, VI512B can increase the amount of network resources required to continue to meet VI512B QoS settings associated for delivering those services. A QoS manager can detect such dynamic changes in the QoS provided to a VI and can act to modify which resources are provided to the VI s to deliver services efficiently and/or, possibly, at lowest costs to the cloud services provider and/or consumers.

For example, QoS manager502can monitor dynamic status of network components and/or resources underlying VNIC518A, such as performance indicators (e.g., individual and/or aggregate component statistics) for VI512B, VNIC518A and/or network resources underlying VNIC518A (VNIC518D, VSWITCH522, adapter530, physical ports532A and/or532). QoS manager502can determine, based on these performance indicators, that VNIC518A is unable to continue to meet the VI512B QoS objectives for consumer device310A. Alternatively, QoS manager502can determine that consumer device310A QoS setting include a preference to, at a particular time or under particular conditions, use higher performing network resources than provided by VNIC518A for VI512B.

In response to changing operating conditions, and/or preferences, QoS manager502can act to transfer VI512B network services from VNIC518A to a higher performing virtual network device. For example, QoS manager502can act to transfer VI512B network services (e.g., using hypervisor520) from VNIC518A to higher-performing VEA508and underlying VPORT542A and port544A of adapter540. If VEA508has not already been created (e.g., by hypervisor52), QoS manager502can act to create VEA508(e.g., by using hypervisor520) to use resources of adapter540, such as VPORT542A and port544A.

Alternatively, QoS settings associated with cloud services provided to consumer device310A, VI512B can require higher performing network resources, or consumer device310A can be willing, or prefer, to utilize higher performing network resources, such as resources of higher-performing, self-virtualizing adapter540. Accordingly, based on QoS objectives that require or prefer higher performing network resources, and/or a cloud300resource management policy, QoS manager502can prefer to select VEA508to provide a virtual network device to VI512B for providing cloud services to consumer device310A.

However, while utilizing VEA508, VI512B can, at times, require lower levels of network performance such that VEA508can surpass the QoS objectives (e.g., exceed particular performance levels) specified for consumer device310A. QoS manager502can detect that VI512B, at a particular time, and based on VI512B using VEA508, is surpassing QoS objectives associated with consumer device310A. Accordingly, QoS manager502can determine that a VNIC using a lower-performing and possibly lower-cost, adapter, such as VNIC518A using resources of adapter530, can alternatively provide network services that meet those VI512B QoS objectives. QoS manager502can act to transfer VI512B network services from VEA508to VNIC518A (including, if not already created, to create VNIC518A).

Transferring network services for VI512B from VEA508and adapter540to VNIC518A and adapter530, at times when VNIC518A and adapter530can meet the VI512B QoS settings for consumer device310A, can enable cloud300to make adapter540higher performance resources available to VIs providing services to consumer devices accessing resources of cloud300that require such performance, or to consumer devices used by consumers that are willing to pay a higher cloud services price for such performance.

It will be appreciated by one of ordinary skill in the art that a QoS manager can be implemented in a variety of functions and/or components, or combinations of functions and/or components, of a cloud computing system. For example, QoS manager502, can be implemented partially (or, alternatively, wholly) within components of server510, such as I/O server514, VIs512A and512B and/or hypervisor520. QoS manager502can be implemented partially (or, alternatively, wholly) as a function of a computer (not shown inFIG. 3orFIG. 5) in communication with server510(e.g., using interface504).

It will be further appreciated by one of ordinary skill in the art that the ability of a VI to meet or surpass VI QoS objectives for a particular consumer device can continue to change dynamically while providing cloud services to that consumer device. It will be apparent to one of ordinary skill in the art that embodiments can continually swap resources used by a VI to provide cloud services to a particular consumer device, interchanging higher performing resources (e.g., VEAs) with lower performing resources (e.g., VNICs) and vice-versa, as the ability of the VI to meet or surpass QoS objectives corresponding to the consumer device changes over time.

FIG. 6illustrates example method600, andFIG. 7illustrates related example method630, to manage cloud computing resources to meet VI QoS objectives associated with providing cloud services to a consumer device. Embodiments of methods600and630can detect that the performance of computing resources used by a VI to deliver cloud services to a consumer device are falling below VI QoS objectives or, alternatively, surpassing VI QoS objectives, and in response act to substitute different computing resources for those in use by the VI.

Embodiments can implement methods600and/or630using, for example, a system like system500inFIG. 5as a component of a cloud. Accordingly, to illustrate the methods, but not intended to limit embodiments, methods600and630are as performed by a QoS manager, included in a cloud computing environment, managing virtual network devices providing network resources to VIs in servers within the cloud. Accordingly, with respect to the ensuing descriptions of methods600and630:

“cloud” refers to a cloud similar to cloud300ofFIG. 3and including a system, similar to system500ofFIG. 5, for managing virtual resources in a computer and/or cloud computing environment;

“non-virtualizing adapter” refers to an adapter similar to adapter530ofFIG. 5, which can be, for example, network adapter type not having SR-IOV capabilities, and “VNIC” refers to a virtual network devices similar to VNIC518A ofFIG. 5;

“self-virtualizing adapter” refers to an adapter similar to adapter540ofFIG. 5, which can be, for example, an SRIOV type network adapter, and “VEA” refers to a virtual network devices similar to VEA508ofFIG. 5;

“server” refers to a server similar to server510ofFIG. 5;

“consumer device”, refers to a consumer device similar to those among consumers310ofFIG. 3, used by a consumer to access services of the cloud;

“VI” refers to a VI, similar to VI512B ofFIG. 5, having particular VI QoS objectives associated with providing cloud services to a particular consumer device; and

“QoS manager” refers to a QoS manager similar to QoS manager502ofFIG. 5. However, it will be understood by one of ordinary skill in the art that illustrating methods600and630in this context is not intended to be limiting to embodiments.

Referring now toFIG. 6, at602of method600a QoS manager receives (or otherwise obtains) and monitors QoS metrics related to VIs operating in a server within a cloud to provide cloud services to consumer devices. At602, the QoS manager can, for example, receive QoS metrics from components of the cloud (e.g., servers, VIs, or other metric collecting agents of the cloud), can itself inspect components of the cloud to extract or obtain the metrics, or can obtain the metrics by a combination of these. The QoS manager can receive, or otherwise obtain the metrics, periodically or, alternatively, continuously.

The QoS metrics can be, for example, associated with a particular consumer and/or consumer device, a server, a particular VI, computing resources (within a server, or within the cloud) used by a particular VI, or a plurality or combinations of any of these. It will be apparent to one of ordinary skill in the art that QoS metrics, and/or QoS objectives, associated with a particular consumer can be, or can correspond to, respective QoS metrics, and/or QoS objectives, associated with consumer devices that operate as, or are used by, the consumer to access cloud services. Accordingly, references to QoS metrics, and/or QoS objectives, associated with a consumer device further implies respective QoS metrics and/or QoS objectives associated with a consumer operating as, or using, the consumer device, whether the consumer device QoS metrics and/or QoS objective, are the same as, or derived from, the respective QoS metrics and/or QoS objectives associated with the consumer.

The QoS manager, at602, can monitor QoS metrics to determine if one or more VIs are meeting QoS objectives associated with particular consumer devices or, alternatively, to determine if one or more VIs are exceeding QoS objectives associated with particular consumer devices. QoS metrics monitored at602can include QoS settings associated with the VI and/or particular indications of the degree to which the VI is able to meet (or, alternatively, exceed) the VI QoS objectives associated with a particular consumer device.

Indications that a VI is meeting, or exceeding, QoS objectives can include performance indicators (e.g., network latency, bandwidth, and/or throughput) associated with, for example, virtual devices used by the VI(s) to provide network services to the consumer device. In one example, QoS metrics received and monitored at602can include performance indicators associated with a VNIC in use by a VI to provide cloud services to a consumer device, and/or network components underlying the VNIC, such as a VSWITCH, a VNIC and/or device driver in an I/O server, a non-virtualizing adapter, and/or a physical adapter port of the non-virtualizing adapter. In an alternative case, QoS metrics received and monitored at602can include performance indicators associated with a VEA in use by a VI, using a self-virtualizing adapter and/or a VPORT, and/or physical port, of the self-virtualizing adapter underlying the VEA, to provide cloud services to a consumer device. QoS metrics received at602can also include performance indicators associated with the VI itself, such as for example, instantaneous or aggregate processor utilization and/or network throughput of the VI.

At604the QoS manager determines if the QoS metrics received at602indicate that the VI(s) are meeting the VI QoS objectives (e.g., greater than or equal to the objectives) associated with a particular consumer device using the VI(s). For example, a VI can be using one or more VNICs to perform network operations and the VI and/or VNICs can be experiencing conditions (e.g., increased VI workload and/or increased utilization of underlying network components and/or resources) under which the VI can no longer meet the VI QoS objectives using the VNIC(s). If the server includes a self-virtualizing adapter with an available VPORT, potentially the VI can, as an alternative to one or more of the VNICs, use one or more VEAs to meet the VI QoS objectives.

Accordingly, if at604, the QoS manager determines that the VI is not meeting the VI QoS objectives, at606the QoS manager determines if the VI is using one or more VNICs, corresponding to one or more non-virtualizing adapters, to provide cloud services to the consumer device. If so, at608the QoS manager selects a VNIC among these. The QoS manager can select a VNIC based on, for example, performance indicators included in the QoS metrics that indicate that VNIC is experiencing conditions that reduce its ability to provide required network performance to the VI. Alternatively, the QoS manager can select a VNIC, or any one VNIC among several configured in the VI, based solely, for example, on that VNIC having an underlying lower-performing, non-virtualizing adapter.

At610, the QoS manager determines if the server has a self-virtualizing network adapter, and whether that self-virtualizing network adapter then has a VPORT available, or that can be created (or, instantiated) to substitute for the selected VNIC. If so, at612the QoS manager determines if the VI using the available VPORT can meet the VI QoS objectives. For example, the QoS manager can evaluate VPORT capabilities such as maximum bandwidth or throughput, and/or minimum latency, in comparison to capabilities required to meet the VI QoS objectives.

If, at612, the QoS manager determines that the available VPORT can meet the VI QoS objectives, at614the QoS manager acts to swap the available VPORT for the selected VNIC, to continue to provide cloud services to the consumer device. The QoS manager can, for example, act to swap the VPORT for the VNIC using, or communicating with, components of the server, such as a hypervisor (e.g., hypervisor520inFIG. 5) to perform the swapping. In some embodiments, the QoS manager can be, or can include, a component of a server (e.g., partially or wholly a function of a hypervisor) hosting the VIs, which can potentially perform the swapping.

Swapping the available VPORT and the selected VNIC can comprise configuring the VI to use the VPORT in place of the VNIC to provide cloud services to the consumer device. Configuring the VI to use the VPORT in place of the VNIC can include, for example, de-activating and/or de-configuring the selected VNIC from the VI and configuring and/or activating a VEA using the available VPORT as a virtual device within the VI. Swapping the VPORT and VNIC can include creating a VEA within the VI prior to configuring or activating the VEA, and/or deleting the VNIC from the VI, subsequent to de-activating and/or de-configuring the VNIC in the VI. Swapping the VPORT and VNIC can further include, for example, reassigning the VNIC IP address to the VEA associated with the VPORT.

Subsequent to swapping the VPORT and VNIC at614, or if the QoS manager determines, at610, that there is not a self-virtualizing VPORT available to swap for the selected VNIC, or determines, at612, that the available VPORT cannot meet the VI QoS objectives, the QoS manger resumes QoS monitoring at602. If, in resuming monitoring at602, requirements to meet the VI QoS objectives in support of a particular consumer device no longer require such monitoring, the QoS manger can, optionally, discontinue monitoring. If, at604of method600, the QoS manager determines that the virtual device (e.g., a VEA or VNIC) in use by VI is meeting or exceeding the VI QoS objectives, then at616the QoS manager can perform method630illustrated inFIG. 7.

Referring now toFIG. 7, at632of method630, the QoS manager continues, from616of method600, processing QoS metrics received at602of method600. At634the QoS manager determines if the QoS metrics from602of method600are surpassing (i.e., exceeding) the VI QoS objectives. For example, a VI can be using one or more VEAs to perform network operations and the VI and/or the VEAs can be experiencing conditions (e.g., reduced VI workload and/or utilization of underlying network components and/or resources) under which the VI is surpassing the VI QoS objectives using those VEAs. If the server includes a non-virtualizing adapter and virtualization functions (e.g., those associated with a VNIC), potentially the VI can, as an alternative to one or more of the VEAs, use one or more VNICs to meet the VI QoS objectives.

Accordingly, if the QoS manager determines, at634, that the VI is surpassing the VI QoS objectives, at636the QoS manager determines if the VI is using one or more VEAs, corresponding to one or more self-virtualizing adapters, to provide cloud services to the consumer device. If so, at638the QoS manager selects a VEA from the VEAs in use by the VI. The QoS manager can select a VEA based on, for example, performance indicators, included in the QoS metrics, associated with the ability of the VEA to provide required network performance to the VI. Alternatively, the QoS manager can select a VEA, or any one VEA among several configured in the VI, based solely, for example, on that virtual device being a VEA having an underlying higher-performing, self-virtualizing adapter.

At640, the QoS manager determines if the server includes a non-virtualizing adapter, and/or VNIC virtualization functions (e.g., a VSWITCH and/or an I/O server with a VNIC or other virtualization intermediary, such as a VEA), that can provide a VNIC to substitute for the selected VEA. If so, at642the QoS manager determines if the VI can meet the VI QoS objectives using the VNIC (and/or, the non-virtualizing adapter). If so, at644the QoS manager acts to swap the VNIC for the selected VEA. The QoS manager can, for example, act to swap the VNIC for the VEA using, or communicating with, components of the server, such as a hypervisor (e.g., hypervisor520inFIG. 5) to perform the swapping. In some embodiments, the QoS manager can be, or can include, a component of a server (e.g., partially or wholly a function of a hypervisor) hosting the VIs, which can potentially perform the swapping.

Swapping the VEA and VNIC can comprise configuring the VI to use the VNIC in place of the VEA to provide cloud services to the consumer device. Configuring the VI to use the VNIC in place of the VEA can include, for example, de-activating and/or de-configuring the selected VEA from the VI and configuring and/or activating a VNIC within the VI using the available non-virtualizing adapter. Swapping the VEA and VNIC can include creating a VNIC within the VI prior to configuring or activating the VNIC, and/or deleting the VEA from the VI, subsequent to de-activating and/or de-configuring the VEA in the VI. Swapping the VEA and VNIC can further include reassigning the VEA IP address to the VNIC associated with the non-virtualizing network adapter.

Subsequent to swapping the VEA and VNIC at644, or if the QoS manager determines: at634that the QOS metrics are meeting the VI QoS objectives, at636that the VI is not using VEAs, at640that there is not a non-virtualizing adapter available (or, alternatively, that the server does not provide VNIC virtualization functions), or, at642, that a VNIC cannot meet the VI QoS objectives, at646the QoS manger resumes QoS monitoring, at602of method600. If, in resuming monitoring at602of method600, requirements to meet the VI QoS objectives in support of a particular consumer device no longer require such monitoring, the QoS manager can, optionally, discontinue monitoring.

While method630is described as ensuing from616of method600, it will be understood by one of ordinary skill in the art that embodiments can, alternatively, implement method630to include an operation to receive and monitor QoS metrics, similar to operation602of method600, and can, accordingly, perform method630independently of method600. Similarly, it will be understood by one of ordinary skill in the art that embodiments can, alternatively, omit performing method630and can perform method600independently of method600.

Embodiments can repeat method600forFIG. 6, and/or method630ofFIG. 7, as operating conditions (e.g., utilization, bandwidth, throughput, and/or latency) of cloud computing resources (e.g., servers and/or component I/O adapters, VIs, and/or networks) change dynamically. For example, embodiments can perform the methods to swap a first pair of virtual devices (e.g., a VNIC and a VEA) and repeat the methods for additional virtual devices in use by a particular VI or, alternatively, for a plurality of VI.

While examples of the disclosure, such as system500ofFIG. 5, and example methods600and630ofFIGS. 6 and 7, are described in the context of a cloud computing environment, such as cloud300ofFIG. 3, this is not intended to limitations. On the contrary, it would be apparent to one of ordinary skill in the art that the examples of the disclosure can be modified as necessary to be embodied in a computing system not included in a cloud computing environment, or to be employed in various virtualizing computing systems having virtual devices with differing types of underlying physical devices.

Computer readable program instructions described herein can be downloaded to respective computing/processing devices—such as servers61-64ofFIG. 2, servers302ofFIG. 3, server400ofFIG. 4, and/or server510ofFIG. 5—from a computer readable storage medium or to an external computer or external storage device via a network, for example, the Internet, a local area network, a wide area network and/or a wireless network. The network may comprise copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers and/or edge servers. A network adapter card or network interface in each computing/processing device receives computer readable program instructions from the network and forwards the computer readable program instructions for storage in a computer readable storage medium within the respective computing/processing device.

Computer readable program instructions for carrying out operations of the present invention may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuitry, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++, or the like, and procedural programming languages, such as the “C” programming language or similar programming languages.

The computer readable program instructions can be stored in a memory, such as instructions442of memory440inFIG. 4, and results of executing the computer readable program instructions can be stored in in a memory, such as instruction output444of memory440inFIG. 4. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field-programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present invention.