User-allocated network interface queues

Abstract

An application programming interface (API) allows a virtual machine to be launched, where a user may configure a queue count. More specifically, a pool of queues may be allocated to each virtual machine. Further, each virtual machine may have a plurality of virtual network interfaces, and a user may assign a plurality of queues to each virtual network interface from a pool. Accordingly, a new metadata field is described, which can be used with a request to launch the virtual machine. The metadata field includes one or more parameters that associate a plurality of queues with each virtual network interface. A user may dynamically configure queue counts to ensure that the queue is effectively used while the user knows the intended application of the virtual machine being launched.

Description

Background Art

[0001] Cloud computing is the use of computing resources (hardware and software) that are available at a remote location and can be accessed through a network (such as the Internet). Users are able to use these computing resources (including storage and computing power) as a utility on demand. Cloud computing delegates the user's data, software, and computation to remote services. Using virtual computing resources can provide many advantages, including cost advantages and / or the ability to quickly adapt to changing computing resource needs.

[0002] In a cloud computing environment, a virtual machine image contains an operating system (e.g., Linux) and other data required to start a virtual machine in a virtual environment. A virtual machine image is similar to a disk volume of a physical computer and can include a file system, an operating system, and other components required to boot as a machine. In order to start a virtual machine, hardware needs to be selected. Hardware selection is done through instance types, which allow for various sizes of memory, CPU capacity, I / O performance, etc. The combination of a virtual machine image and an instance type can be used to create an "instance" or virtual machine.

[0003] I / O performance is related to the network interface associated with the virtual machine. The network interface may have many transmit queues and receive queues that allow data to be transferred over the network. Typically, larger virtual machines with more CPUs have a larger number of queues. However, some virtual machines may be assigned to operations with lower data throughput, such as virtual machines that primarily provide management functions. In such cases, the virtual machine may not need the number of queues assigned to it. Other virtual machines may be focused on data transfer and have an insufficient number of queues. Better queue utilization is needed in current cloud environments. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Figure 1 is a system diagram illustrating starting a virtual machine with customized network interface queues.

[0005] Figure 2 is an example system diagram illustrating multiple virtual machine instances running in a multi-tenant environment.

[0006] Figure 3 Further details of an example system including multiple management components associated with a control plane are shown.

[0007] Figure 4 Shown are examples of multiple host computers, routers, and switches, which are hardware assets used to run virtual machine instances.

[0008] Figure 5 It shows that customized virtual machines are allocated according to user queues.

[0009] Figure 6is a flow diagram for customizing a queue based on a user request, according to one embodiment.

[0010] Figure 7 is a flow chart for customizing a queue based on a user request according to another embodiment.

[0011] Figure 8 A generalized example of a suitable computing environment is depicted in which the described innovations may be implemented. DETAILED DESCRIPTION

[0012] In cloud environments, each virtual network interface has a limited number of queues available for use by virtual machine instances. Ideally, each processor associated with a virtual machine would be assigned its own network queue to avoid contention / locking and cache pollution. However, each queue consumes a significant amount of resources, including memory and hardware acceleration resources on the interface card and host memory (e.g., kernel buffers and interrupts). Due to the number of supported network interfaces per virtual machine and the number of queues per network interface, the user experience is often affected.

[0013] An application programming interface (API) allows a virtual machine to be launched, where a user can configure a queue count. More specifically, a queue pool can be assigned to each virtual machine. In addition, each virtual machine can have multiple virtual network interfaces, and a user can assign multiple queues to each virtual network interface from a pool. Therefore, a new metadata field is described that can be used with a request to launch a virtual machine. The metadata field includes one or more parameters that associate multiple queues with each virtual network interface. The user can dynamically configure the queue count to ensure efficient use of the queue if the user understands the intended application of the virtual machine being launched. Although generally described in relation to virtual machines, the user can also configure multiple queues in other applications, such as multiple queues between a storage service and local storage.

[0014] Figure 11 is a system diagram 100 for launching and configuring a virtual machine based on a user request. To launch a virtual machine 110, an API call 112 is made using a virtual machine image identifier. The identifier can be used to identify a virtual machine (VM) image 114 (also referred to as a "machine image") and a VM registration record 116. For example, the identifier can be used to determine an appropriate VM registration record 116, which in turn can point to the VM image 114. Alternatively, the identifier can be used to determine the VM image 114, which can include a pointer to the VM image registration record 116. Other implementations can also be used. The VM image 114 can be similar to a hard drive volume and contain software running in the virtual machine 110. For example, the VM image can include a file system, an operating system, etc. required to launch the virtual machine 110. The VM registration record 116 can include a VM image configuration 120, which identifies the virtual hardware used as a platform for the virtual machine image 114. Example data stored in the VM image configuration includes architecture, target virtualization type, operating system type, which kernel to use at startup, and which additional virtual disk image should be connected to the instance after startup. The VM registration record 116 may also include metadata 122, which may include available queue pools that may be used for a particular VM image and may be used to further configure the VM 110 after it is started. For example, the metadata 122 may be free-format data interpreted by the VM 110. The metadata 122 may be stored and determined in a variety of ways. For example, it may be included in the VM image configuration 120, the VM image configuration 120 may have a pointer to the metadata 122, there may be a separate record that points to both the VM image configuration and the metadata 122, and so on. In addition, the metadata 122 may be stored in one or more files. When the API call 112 is received, the instance manager 124 may use the VM image identifier to determine the associated VM image 114 and the VM image configuration 120. The instance manager 124 may then use the VM image 114 in conjunction with the VM image configuration 120 to start the virtual machine 110. The VM 110 may include code for retrieving the metadata 122. The instance manager 124 may retrieve the queue pool data in the metadata 122 and use it to start the VM 110. Alternatively, the provided metadata 122 may be interpreted by the VM 110 or otherwise executed by the VM. Typically, the customization of the VM 110 using the metadata 122 occurs after the VM is started or during startup by the instance manager 124. The instance manager 124 may instruct the hypervisor 130 to configure the virtual machine 110 using the network interface customized according to the API request 112. More specifically, the instance manager 124 learns the number of queues available in the queue pool from the metadata 122, and may allocate queues from the queue pool to the virtual machine 110 according to the user request 112 by instructing the hypervisor 130.This gives users the flexibility to use the queue pool in any desired manner, including assigning all queues in the queue pool to a single VM interface.

[0015] As shown, virtual machine 110 can be started by any number of virtual network interfaces 150 (as indicated by repeating point 152). Each network interface 150 includes a transmission queue 160 (TQ) and a receiving queue 162 (RQ). The hypervisor 130 can use a base address register (BAR) to define the location of queues 160, 162 in memory. More specifically, each queue is a set of registers, and those registers are placed on the BAR by the hypervisor 130. The number of transmission queues 160 and receiving queues 162 is controlled by the user via API request 112, and the limit is that the desired number cannot exceed the queue pool number 122. In this way, the user can select any desired number of queues from the queue pool, and the queue is assigned to the network interface to customize the queue on the network interface in the virtual machine. In other embodiments, API can be used to dynamically change the queue allocation on the active VM. Therefore, API does not need to be associated with the new startup of VM, but can change the existing allocation. In such cases, the user can include the identifier of the VM and the interface list and its associated queue allocation. Such dynamic allocation may occur when virtual network interface 150 is detached from virtual machine 110 and then reattached.

[0016] As further described below, when an API request is issued, the service receives the request. Services are commonly used in cloud computing. A service is a software function provided at a network address via a web or cloud. The client initiates a service request to the server, and the server processes the request and returns an appropriate response. Client service requests are usually initiated using, for example, an API request (such as request 112). For simplicity, the service request is usually described as an API request below, but it should be understood that other service requests can be made. An API request is a programming interface for a defined request-response message system, usually expressed in JSON or XML, and exposed through the Web - most commonly through an HTTP-based Web server. Therefore, in some embodiments, an API can be defined as a set of hypertext transfer protocol (HTTP) request messages, and a definition of a response message structure, which can be in extensible markup language (XML) or JavaScript object notation (JSON) format. An API can specify a set of functions or routines that perform an action, including completing a specific task or allowing interaction with a software component. When a service receives an API request from a client device, the service can generate a response to the request and send the response to an endpoint identified in the request.

[0017] Figure 2It is a computing system diagram of a network-based computing service provider 200, which shows an environment in which the embodiments described herein can be used. As background, the computing service provider 200 (i.e., cloud provider) can deliver computing and storage capacity as a service to the final recipient community. In an example embodiment, a computing service provider can be established for an organization by or on behalf of an organization. That is, the computing service provider 200 can provide a "private cloud environment". In another embodiment, the computing service provider 200 supports a multi-tenant environment in which multiple users operate independently (i.e., a public cloud environment). In general, the computing service provider 200 can provide the following models: infrastructure as a service ("IaaS"), platform as a service ("PaaS"), and / or software as a service ("SaaS"). Other models can be provided. For the IaaS model, the computing service provider 200 can provide computers as physical or virtual machines and other resources. The virtual machine can be run as a guest through a hypervisor, as further described below. The PaaS model provides a computing platform, which may include an operating system, a programming language execution environment, a database, and a web server. Application developers can develop and run their software solutions on the computing service provider platform without the cost of purchasing and managing the underlying hardware and software. The SaaS model allows application software to be installed and operated in a computing service provider. In some embodiments, an end user uses a network client device (such as a desktop computer, laptop computer, tablet computer, smart phone, etc. running a web browser or other lightweight client application) to access the computing service provider 200. Those skilled in the art will recognize that the computing service provider 200 can be described as a "cloud" environment.

[0018] In some embodiments of the disclosed technology, the computing service provider 200 may be a cloud provider network. A cloud provider network (sometimes referred to simply as a "cloud") refers to a pool of network-accessible computing resources (such as computing, storage and network resources, applications, and services), which may be virtualized or bare metal. A cloud may provide convenient, on-demand network access to a shared pool of configurable computing resources that may be programmatically provided and released in response to user commands. These resources may be dynamically provisioned and reconfigured to adjust for variable loads. Cloud computing may therefore be viewed as both applications delivered as services over a publicly accessible network (e.g., the Internet, a cellular communications network) and the hardware and software in a cloud provider data center that provides those services.

[0019] With cloud computing, instead of purchasing, owning and maintaining their own data centers and servers, organizations can acquire technologies such as computing power, storage, databases and other services as needed. A network of cloud providers can provide users with an on-demand scalable computing platform over a network, allowing users, for example, to have scalable "virtual computing devices" at their disposal through their use of computing servers and block storage servers. These virtual computing devices have the attributes of a personal computing device, including hardware (various types of processors, local memory, random access memory ("RAM"), hard disk and / or solid state drive ("SSD") storage devices), a choice of operating system, networking capabilities and pre-loaded application software. Each virtual computing device can also virtualize its console input and output ("I / O") (e.g., keyboard, display and mouse). This virtualization allows users to connect to their virtual computing devices using computer applications such as browsers, application programming interfaces, software development kits, etc., so as to configure and use their virtual computing devices like personal computing devices. Unlike personal computing devices that have a fixed number of hardware resources available to users, the hardware associated with the virtual computing device can be scaled up or down according to the resources required by the user. Users may choose to deploy their virtual computing systems to provide network-based services for their own use and / or for use by their users or clients.

[0020] The cloud provider network can be formed into multiple regions, where a region is a separate geographic area in which the cloud provider clusters data centers. Each region may include two or more availability zones connected to each other via a private high-speed network (e.g., a fiber optic communication connection). An availability zone (also referred to as an availability domain or simply a "zone") refers to an isolated fault domain including one or more data center facilities, which have power, network, and cooling separated from data center facilities in another availability zone. A data center refers to a physical building or housing that houses servers of a cloud provider network and provides power and cooling for servers of the cloud provider network. Preferably, the availability zones within a region are located far enough apart from each other so that the same natural disaster does not take more than one availability zone offline at the same time. Users can connect to the availability zones of the cloud provider network via a publicly accessible network (e.g., the Internet, a cellular communication network) through a switching center (TC). TC is the main backbone location that links users to the cloud provider network, and can be co-located at other network provider facilities (e.g., an Internet service provider, a telecommunications provider) and securely connected to the availability zone (e.g., via a VPN or direct connection). Two or more TCs can be operated in each region to achieve redundancy. The regions are connected to a global network that includes a private network infrastructure (e.g., a fiber connection controlled by the cloud provider) that connects each region to at least one other region. The cloud provider network can deliver content from points of presence located outside of these regions but networked to these regions through edge locations and regional edge cache servers. This partitioning and geographic distribution of computing hardware enables the cloud provider network to provide users with low-latency access to resources around the world with a high degree of fault tolerance and stability.

[0021] The cloud provider network may implement various computing resources or services (which implement the disclosed techniques for TLS session management), which may include elastic computing cloud services (which are referred to in various embodiments as elastic computing services, virtual computing services, computing cloud services, computing engines, or cloud computing services), data processing services (e.g., map-reduce, data streaming, and / or other large-scale data processing techniques), data storage services (e.g., object storage services, block-based storage services, or data warehouse storage services), and / or any other type of network-based services (which may include various other types of storage, processing, analysis, communication, event handling, visualization, and security services not described). The resources required to support the operation of such services (e.g., computing and storage resources) may be provisioned in an account associated with the cloud provider, in contrast to resources that may be provisioned in a user account requested by a user of the cloud provider network.

[0022] The computing service provider 200 shown specifically includes multiple server computers 202A-202D. Although only four server computers are shown, any number can be used, and large centers can include thousands of server computers. Server computers 202A-202D can provide computing resources for executing software instances 206A-206D. In one embodiment, instances 206A-206D are VMs. As known in the art, a virtual machine is an instance of a software implementation of a machine (i.e., a computer) that executes an application like a physical machine. In the example of a virtual machine, each of servers 202A-202D can be configured to execute a hypervisor 208 or another type of program, and the another type of program is configured to enable execution of multiple instances 206 on a single server. In addition, each of instances 206 can be configured to execute one or more applications. As shown at 209, hypervisor 208 can configure instances 206A-206C by connecting a virtual network interface to an instance, wherein the virtual network interface has a customized queue according to a user request and is located on a physical network interface card (NIC) 211. Alternatively, as shown in server computer 202D, no customization is required and the default number of queues can be used on NIC 211. Although three queues 209 are shown, there are generally any number of queues, with different virtual NICs for each of the multiple instances, such as shown at 206A. In addition, the customized queues 209 can be shared between the network and storage. For example, there can be a first set of queues 209 for the network and a second set of queues 209 for storage. In addition, the same queue pool can be used for both the network and storage. Alternatively, the network and storage can have separate queue pools for generating customized queues 209.

[0023] It should be understood that although the embodiments disclosed herein are primarily described in the context of virtual machines, other types of instances may also be used with the concepts and techniques disclosed herein. For example, the techniques disclosed herein may be used with storage resources, data communication resources, and other types of computing resources. The embodiments disclosed herein may also execute all or part of an application program directly on a computer system without utilizing a virtual machine instance.

[0024] One or more server computers 204 may be retained for executing software components for managing the operation of server computers 202 and instances 206. For example, server computers 204 may execute management components 210. Users may access management components 210 to configure various aspects of the operation of instances 206 purchased by customers. For example, users may purchase, rent or lease instances and make changes to the configuration of instances. Users may also specify settings on how to scale the purchased instances in response to demand. Management components may also include policy documents to implement user policies. Automatic scaling components 212 may scale instances 206 based on user-defined rules. In one embodiment, automatic scaling components 212 allow users to specify amplification rules for determining when new instances should be instantiated and specify reduction rules for determining when existing instances should be terminated. Automatic scaling components 212 may consist of multiple subcomponents executed on different server computers 202 or other computing devices. Automatic scaling components 212 may monitor available computing resources through an internal management network and modify available resources as needed.

[0025] A deployment component 214 may be used to help a user deploy a new instance 206 of a computing resource. The deployment component may access account information associated with the instance, such as who is the owner of the account, credit card information, the country of the owner, etc. The deployment component 214 may receive a configuration from a user that includes data describing how the new instance 206 should be configured. For example, the configuration may specify one or more applications to be installed in the new instance 206, provide scripts and / or other types of code to be executed for configuring the new instance 206, provide caching logic that specifies how application caches should be prepared, and other types of information. The deployment component 214 may configure, prepare, and start the new instance 206 using the configuration and caching logic provided by the user. In addition, the deployment component may use parameters received in an API request to configure a queue on a network instance. The configuration, caching logic, and other information may be specified by a user using the management component 210 or by providing this information directly to the deployment component 214. The instance manager may be considered part of the deployment component.

[0026] User account information 215 may include any desired information associated with a user of a multi-tenant environment. For example, user account information may include a unique identifier for the user, the user's address, billing information, licensing information, custom parameters for launching instances, scheduling information, auto-scaling parameters, previous IP addresses used to access the account, etc. In some cases, a user may specify queue assignments in user account 215 rather than providing queue assignments in an API (e.g., Figure 1 shown).

[0027] A network 230 may be used to interconnect server computers 202A-202D and server computer 204. Network 230 may be a local area network (LAN) and may be connected to a wide area network (WAN) 240 so that end users can access computing service provider 200. It should be understood that the present invention has been simplified. Figure 2 The network topologies shown are shown, and many more networks and network devices may be used to interconnect the various computing systems disclosed herein.

[0028] Figure 3 Further details are shown for management component 306 that can be used in a multi-tenant environment of computing service provider 200. Figure 2 Instance 206), a client device may be used. Client device 310 may be any of a variety of computing devices, mobile devices, or other devices, including mobile phones, smart phones, handheld computers, personal digital assistants (PDAs), desktop computers, and the like. Client device 310 may communicate with computing service provider 200 via endpoint 312, which may be a DNS address designed to receive and process API requests. An API request may be a request to specify a queue allocation on a virtual machine that has been started to dynamically modify queue allocations, or an API request may be a request to specify a queue allocation on a virtual machine and identify a virtual machine to be started. Endpoint 312 may be a Web server configured to expose such an API. Using an API request, client 310 may issue a request to implement any functionality described herein. Other services 315 (which may be inside computing service provider 200) may also issue an API request to endpoint 312.

[0029] Other general management services that may or may not be included in the computing service provider 200 include admission control 314, for example, one or more computers operating together as an admission control service. Admission control 314 can authenticate, verify, and unpack API requests for services or store data within the computing service provider 200. Capacity tracker 316 is responsible for determining how servers need to be configured to meet the needs of different instance types by managing and configuring physical inventory in terms of forecasting, provisioning, and real-time configuration and allocation of capacity. Capacity tracker 316 maintains an available inventory pool in a capacity pool database 318. Capacity tracker 316 can also monitor capacity levels to understand whether resources are available quickly or limited. Instance manager 350 controls the launch and termination of instances in the network. When an instruction to launch an instance is received (such as through an API request), the instance manager pulls resources from the capacity pool 318 and launches the instance on the determined host server computer. As shown at 352, the launched instance can perform customized queue allocations on the virtual network interface associated with the virtual machine. Specifically, multiple transmission queues and receive queues allocated to each network interface can be used according to an API from the client device 310. Similar to the instance manager are the storage manager 322 and the network resource manager 324. The storage manager 322 is involved in the startup and termination of storage volumes, while the network resource manager 324 is involved in the startup and termination of routers, switches, subnets, etc. The partition network 340 will be combined with Figure 4 Further described, and includes the physical layer on which the instance is launched.

[0030] Figure 4 A partitioned network 340 and the physical hardware associated therewith are shown. The partitioned network 340 may include multiple data centers, such as data center 410, which are coupled together by routers 416. Routers 416 read the address information in the received packet and determine the destination of the packet. If the router determines that a different data center contains a host server computer, the packet is forwarded to that data center. If the packet is addressed to a host in data center 410, it is passed to a network address translator (NAT) 418, which converts the public IP address of the packet into a private IP address. The NAT also translates the private address into a public address bound to the outside of the data center 410. Additional routers 420 may be coupled to the NAT to route packets to one or more racks of host server computers 430. Each rack 430 may include a switch 432 coupled to multiple host server computers. A specific host server computer is shown in an expanded view at 440.

[0031] Each host 440 has underlying hardware 450, including one or more CPUs, memory, storage devices, etc. Hardware 450 may include one or more NICs 452, which may host virtual NICs 454. Running above the hardware 450 is a hypervisor or kernel layer 460. The hypervisor or kernel layer may be classified as a type 1 or type 2 hypervisor. A type 1 hypervisor runs directly on the host hardware 450 to control the hardware and manage the guest operating system. A type 2 hypervisor runs within a conventional operating system environment. Therefore, in a type 2 environment, the hypervisor may be a different layer running above the operating system, and the operating system interacts with the system hardware. Different types of hypervisors include hypervisors based on Xen, Hyper-V, ESXi / ESX, Linux, etc., but other hypervisors may also be used. A management layer 470 may be part of or separate from the hypervisor and typically includes device drivers required to access the hardware 450. A partition 480 is a logical unit isolated by a hypervisor. Each partition 480 may be assigned its own portion of the memory, CPU allocation, storage, etc. of the hardware layer. In addition, each partition may include a virtual machine and its own guest operating system. Thus, each partition is an abstract portion of the capacity designed to support its own virtual machines independently of other partitions. Any virtual machine executing on partition 480 may be customized according to user requests, including queue assignments for each network interface in the virtual machine, as described herein.

[0032] Figure 5 Further details of virtual machine 500 are shown, which can be connected to virtual machine 110 ( Figure 1 ) are the same. The virtual machine 500 may include multiple network interfaces, two of which are shown at 510, 512, but may include any number of network interfaces. Each interface 510, 512 may include a number of queues 520, 522, respectively, which are independent of each other, and the number of queues 520, 522 may be independently controlled by a user, such as through an API request. A queue may represent a memory descriptor or a memory address in a host computer that can be used to store data packets. Queues may be used to transmit or receive network packets. Each network interface 510, 512 may be associated with its own virtual CPU 530. Customized queue assignments may be stored in a memory 540 and describe or control which queues 520, 522 are assigned to which network interfaces 510, 512. A user may modify customized queue assignments 540 through an API, such as Figure 1 At startup, as shown at 112, or after startup (dynamically).

[0033] Figure 6is a flow chart for starting a virtual machine with customized queue assignments according to one embodiment. In process block 610, an API request to start a virtual machine is received. The API request may include one or more parameters related to the number of queues per network interface. For example, in Figure 1 In the example of FIG. 6 , the API request 112 may include a virtual machine image identifier indicating the type of virtual machine to be started and queue allocation parameters. Such parameters may identify each network interface and the number of queues for each network interface. In process block 620, a server computer on which the virtual machine is to be started may be determined. For example, in Figure 3 , instance manager 350 may determine which server computer in capacity pool 318 has an available partition 480 ( Figure 4 ). In process block 630, the virtual machine may be started and a queue pool may be assigned to it. Figure 1 In process block 640, a virtual machine interface may be assigned to the virtual machine. For example, in Figure 1 In the example, the network interface 150 may be assigned to the virtual machine 110 by the hypervisor 130. Finally, in process block 650, a queue may be assigned to the virtual network interface from the queue pool. Figure 1 In the example embodiment, the hypervisor 130 may allocate a transmit queue 160 and a receive queue 162 to the network interface 150 .

[0034] Figure 7 is a flow chart for starting a virtual machine according to another embodiment. In process block 710, a user request to start a virtual machine is received. The request may include a queue allocation that defines how many queues are associated with one or more network interfaces. For example, in Figure 3 In the example, a user request may be received from the client device 310 and ultimately received by the instance manager 350. Figure 5 In process block 720, a user request may be received to modify a customized queue allocation 540 that customizes how many queues 520, 522 and what types of queues 520, 522 are located on the network interfaces 510, 512. In process block 720, a virtual machine may be started with the queues allocated according to the user request. Figure 1 In the example, the virtual machine 110 may be started with each network interface 150 having the number of queues 160 , 162 as defined in the user request 112 .

[0035] Figure 8A generalized example of a suitable computing environment 800 in which the described innovations may be implemented is depicted. The computing environment 800 is not intended to present any limitation as to scope of use or functionality, as the innovations may be implemented in a variety of general-purpose or special-purpose computing systems. For example, the computing environment 800 may be any of a variety of computing devices (e.g., a desktop computer, a laptop computer, a server computer, a tablet computer, etc.).

[0036] refer to Figure 8 , the computing environment 800 includes one or more processing units 810, 815 and memories 820, 825. Figure 8 , this basic configuration 830 is included within the dashed line. Processing units 810, 815 execute computer executable instructions. The processing units may be general purpose central processing units (CPUs), processors in application specific integrated circuits (ASICs), or any other type of processor. In a multi-processing system, multiple processing units execute computer executable instructions to increase processing power. For example, Figure 8 A central processing unit 810 and a graphics processing unit or co-processing unit 815 are shown. Tangible memory 820, 825 may be volatile memory (e.g., registers, cache, RAM), non-volatile memory (e.g., ROM, EEPROM, flash memory, etc.), or some combination of both, accessible by the processing unit. The memory 820, 825 stores software 880 implementing one or more innovations described herein in the form of computer-executable instructions suitable for execution by the processing unit.

[0037] The computing system may have additional features. For example, the computing environment 800 includes a storage area 840, one or more input devices 850, one or more output devices 860, and one or more communication connections 870. An interconnection mechanism (not shown) such as a bus, controller, or network interconnects the components of the computing environment 800. Typically, operating system software (not shown) provides an operating environment for other software executed in the computing environment 800 and coordinates the activities of the components of the computing environment 800.

[0038] The tangible storage area 840 may be removable or non-removable and include disks, magnetic tapes or cartridges, CD-ROMs, DVDs, or any other medium that can be used to store information in a non-transitory manner and that can be accessed within the computing environment 800. The storage area 840 stores instructions for software 880 implementing one or more innovations described herein.

[0039] Input device 850 may be a touch input device such as a keyboard, mouse, pen or trackball, voice input device, scanning device, or another device that provides input to computing environment 800. Output device 860 may be a display, printer, speaker, CD writer, or another device that provides output from computing environment 800.

[0040] Communication connection 870 enables communication with another computing entity via a communication medium. The communication medium transmits information, such as computer executable instructions, audio or video input or output, or other data, in the form of a modulated data signal. A modulated data signal has one or more of its characteristics set or changed in such a manner as to encode the information in the signal. By way of example, but not limitation, the communication medium may use electrical, optical, radio frequency or other carriers.

[0041] Although the operations of some disclosed methods are described in a particular ordered sequence for ease of presentation, it should be understood that such a description includes reordering unless the specific language set forth below requires a particular sequence. For example, the operations described in sequence may in some cases be rearranged or performed simultaneously. In addition, for simplicity, the accompanying drawings may not show the various ways in which the disclosed methods may be used in conjunction with other methods.

[0042] Any disclosed method may be implemented as computer-executable instructions stored on one or more computer-readable storage media (e.g., one or more optical media disks, volatile memory components (such as DRAM or SRAM), or non-volatile memory components (such as flash memory or hard disk drives)) and executed on a computer (e.g., any commercially available computer, including smart phones or other mobile devices that include computing hardware). The term computer-readable storage medium does not include communication connections, such as signals and carrier waves. Any computer-executable instructions for implementing the disclosed technology and any data created and used during the implementation of the disclosed embodiments may be stored on one or more computer-readable storage media. The computer-executable instructions may be a dedicated software application or part of a software application that is accessed or downloaded, for example, via a web browser or other software application (such as a remote computing application). Such software may be executed, for example, on a single local computer (e.g., any suitable commercially available computer) or in a network environment (e.g., via the Internet, a wide area network, a local area network, a client-server network (such as a cloud computing network), or other such networks) using one or more network computers.

[0043] For the sake of clarity, only certain selected aspects of software-based implementations are described. Other details well known in the art are omitted. For example, it should be understood that the disclosed technology is not limited to any particular computer language or program. For example, various aspects of the disclosed technology can be implemented by software written in C++, Java, Perl, or any other suitable programming language. Likewise, the disclosed technology is not limited to any particular computer or hardware type. Certain details of suitable computers and hardware are well known and need not be elaborated in this disclosure.

[0044] It should also be fully understood that any function described herein may be performed at least in part by one or more hardware logic components instead of software. For example, but not limited to, illustrative types of hardware logic components that may be used include field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), system-on-a-chip systems (SOCs), complex programmable logic devices (CPLDs), etc.

[0045] In addition, any software-based implementation (e.g., including computer-executable instructions for causing a computer to perform any disclosed method) can be uploaded, downloaded, or remotely accessed via suitable communication means, including, for example, the Internet, the World Wide Web, an intranet, a software application, cables (including fiber optic cables), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communications means.

[0046] The disclosed methods, apparatuses, and systems should not be construed as limiting in any way. On the contrary, the present disclosure is directed to all novel and non-obvious features and aspects of the various disclosed embodiments, both individually and in various combinations and sub-combinations with each other. The disclosed methods, apparatuses, and systems are not limited to any particular aspect or feature or combination thereof, nor do the disclosed embodiments require the presence of any one or more specific advantages or the resolution of any one or more specific problems.

[0047] For example, the following numbered paragraphs may provide various features of the present disclosure.

[0048] Paragraph 1. A method for starting a virtual machine, the method comprising:

[0049] receiving an application programming interface (API) request to start a virtual machine, wherein the API request includes one or more parameters associated with a plurality of queues;

[0050] determining a server computer on which to start the virtual machine;

[0051] Starting the virtual machine on the server computer and allocating a queue pool to the virtual machine;

[0052] allocating a plurality of virtual interfaces to the virtual machine; and

[0053] Based on the API request, a queue is allocated from the queue pool to the virtual interface associated with the virtual machine.

[0054] Paragraph 2. A method as described in paragraph 1, wherein the API request includes a virtual machine identifier for identifying the virtual machine.

[0055] Paragraph 3. A method as described in paragraph 1, wherein the queue includes a transmission queue and a reception queue for transmitting and receiving network packets.

[0056] Paragraph 4. A method as described in paragraph 1, wherein the API request includes at least a first number of queues associated with a first virtual network interface and a second number of queues associated with a second virtual network interface, wherein the combined number of the first number of queues and the second number of queues is less than the number of queues in the queue pool.

[0057] Paragraph 5. A method as described in paragraph 1, wherein a hypervisor executed on the server computer allocates a first portion of the queue pool to the virtual interface being a virtual network interface, and allocates a second portion of the queue pool to a virtual interface for storage.

[0058] Paragraph 6. A method comprising:

[0059] receiving a user request to start a virtual machine, wherein the request includes a queue assignment defining how many queues should be located on each of one or more interfaces associated with the virtual machine; and

[0060] The virtual machine is started on a server computer while allocating the queue to the one or more interfaces according to the user request.

[0061] Paragraph 7. A method as described in paragraph 6, wherein a hypervisor executed on the server computer assigns the queue from a pool of available queues to the one or more interfaces, wherein a first portion of the queue pool is assigned to the one or more interfaces for the network and a second portion of the queue pool is assigned to the one or more interfaces for storage.

[0062] Paragraph 8. The method of Paragraph 6, wherein the user request is an application programming interface (API) request including a virtual machine image identifier.

[0063] Paragraph 9. A method as described in paragraph 6, wherein the queues are a transmit queue and a receive queue.

[0064] Paragraph 10. The method of paragraph 6, further comprising receiving additional user requests to dynamically modify the queue allocation.

[0065] Paragraph 11. The method of Paragraph 6, wherein the virtual machine includes a plurality of processors, and at least some of the plurality of processors have at least one of the queues assigned thereto for packet processing.

[0066] Paragraph 12. The method of paragraph 6, wherein the user request allows a user other than the service provider to customize how many queues are associated with each interface.

[0067] Paragraph 13. The method of Paragraph 6, further comprising selecting the server computer on which to start the virtual machine from a pool of server computers.

[0068] Paragraph 14. The method of paragraph 6, wherein the queue assignment is stored as metadata in a virtual machine registration record.

[0069] Paragraph 15. The method of Paragraph 6, wherein the queue is allocated from a first queue pool for networking and a second queue pool for storage.

[0070] Paragraph 16. One or more computer-readable media comprising computer-executable instructions that, when executed, cause a computing system to perform a method comprising:

[0071] receiving a request to start a virtual machine, wherein the request includes at least one parameter for customizing a number of queues on an interface linked to the virtual machine; and

[0072] The virtual machine associated with the interface is started if the number of queues on the interface matches the at least one parameter in the request.

[0073] Paragraph 17. The computer-readable storage medium of Paragraph 16, wherein the method further comprises:

[0074] The queue is assigned to one or more processors executing on the virtual machine.

[0075] Paragraph 18. The computer-readable storage medium of paragraph 16, wherein the request is an application programming interface (API) request received from a client computer external to the computing service provider.

[0076] Paragraph 19. The computer-readable storage medium of paragraph 16, wherein the method further comprises:

[0077] A server computer is selected from a pool of server computers, and wherein said launching of said virtual machine occurs on the selected server computer.

[0078] Paragraph 20. The computer-readable storage medium of paragraph 16, wherein the user request allows a user other than a computing service provider to customize how many queues are associated with each interface.

[0079] Paragraph 21. The computer-readable storage medium of paragraph 16, wherein the method further comprises:

[0080] An additional request is received to dynamically modify the customization of the number of queues.

[0081] Paragraph 22. The computer-readable storage medium of paragraph 16, wherein a first portion of the queue is used for networking and a second portion of the queue is used for storage.

[0082] Paragraph 23. The computer-readable storage medium of Paragraph 22, wherein the first portion of queues and the second portion of queues are from the same queue pool or from different queue pools.

[0083] In view of the many possible embodiments to which the principles of the disclosed invention may be applied, it should be recognized that the illustrated embodiments are merely exemplary of the invention and should not be taken as limiting the scope of the invention. Therefore, we claim the full content of our invention to be within the scope of these claims.

Claims

1. A method comprising: receiving a user request to start a virtual machine, wherein the request includes a queue assignment defining how many queues should be located on each of one or more interfaces associated with the virtual machine; as well as The virtual machine is started on a server computer while allocating the queue to the one or more interfaces according to the user request.

2. The method of claim 1 , wherein a hypervisor executing on the server computer assigns the queues to the one or more interfaces from a pool of available queues, wherein a first portion of the pool of queues is assigned to the one or more interfaces for networking and a second portion of the pool of queues is assigned to the one or more interfaces for storage.

3. The method of claims 1 to 2, wherein the user request is an application programming interface (API) request including a virtual machine image identifier.

4. The method of claims 1 to 3, wherein the queues are a transmit queue and a receive queue.

5. The method of claims 1 to 4, further comprising receiving additional user requests to dynamically modify the queue allocation.

6. The method of claims 1 to 5, wherein the virtual machine comprises a plurality of processors, and at least some of the plurality of processors have at least one of the queues assigned thereto for packet processing.

7. The method of claims 1 to 6, wherein the user request allows a user other than the computing service provider to customize how many queues are associated with each interface.

8. The method of claims 1 to 7, further comprising selecting the server computer on which to start the virtual machine from a pool of server computers.

9. The method of claims 1 to 8, wherein the queue assignment is stored as metadata in a virtual machine registration record.

10. The method of claims 1 to 9, wherein the queues are allocated from a first pool of queues for networking and a second pool of queues for storage.

11. A method for starting a virtual machine, the method comprising: receiving an application programming interface (API) request to start a virtual machine, wherein the API request includes one or more parameters associated with a plurality of queues; determining a server computer on which to start the virtual machine; Starting the virtual machine on the server computer and allocating a queue pool to the virtual machine; Allocating a plurality of virtual interfaces to the virtual machine; as well as Based on the API request, a queue is allocated from the queue pool to the virtual interface associated with the virtual machine. 12 . The method of claim 11 , wherein the API request includes a virtual machine identifier for identifying the virtual machine.

13. The method of claims 11 to 12, wherein the queues include a transmit queue and a receive queue for transmitting and receiving network packets.

14. The method of claims 11 to 13, wherein the API request includes at least a first number of queues associated with a first virtual network interface and a second number of queues associated with a second virtual network interface, wherein the combined number of the first number of queues and the second number of queues is less than the number of queues in the queue pool.

15. The method of claims 11 to 14, wherein a hypervisor executing on the server computer allocates a first portion of the queue pool to the virtual interface being a virtual network interface and allocates a second portion of the queue pool to a virtual interface for storage.

Images