Management of virtual desktop instance pools

Abstract

Methods, systems, and computer-readable media for managing a pool of virtual desktop instances are disclosed. A plurality of virtual desktop instances are provided in a pool for a client organization. A number of virtual desktop instances does not exceed a number of virtual desktop slots for the client organization. Access to a particular virtual desktop instance is provided to a first client device associated with a first user based on (at least in part) a determination that a current number of connected virtual desktop instances is less than the number of virtual desktop slots. Access to the plurality of virtual desktop instances is denied to a second client device associated with a second user based on (at least in part) a determination that the current number of connected virtual desktop instances is consistent with the number of virtual desktop slots.

Description

Background Technology

[0001] Many companies and other organizations operate computer networks that interconnect numerous computing systems to support their operations, such as those located in the same location (e.g., as part of a local network) or, alternatively, in multiple different geographical locations (e.g., connected via one or more private or public intermediary networks). Data centers housing large numbers of interconnected computing systems have become commonplace, such as private data centers operated and used by a single organization, and public data centers commercially operated by an entity to provide computing resources to customers or clients. Some public data center operators provide network access, power, and security installations for hardware owned by various customers, while others offer “full-service” facilities that also include hardware resources available for their customers. However, as the typical size and scope of data centers continue to expand, the task of providing, manipulating, and managing physical computing resources becomes increasingly complex.

[0002] The emergence of virtualization technologies for commercial hardware has offered benefits for managing large-scale computing resources for numerous customers with diverse needs, allowing various computing resources to be shared efficiently and securely by multiple customers. For example, virtualization technologies can allow a single physical computer to be shared among multiple users by providing each user with one or more virtual machines hosted by that single physical computer. Each such virtual machine acts as a software emulation of a different logical computing system, giving users the illusion that they are the sole operator and manager of the given hardware resources, while also providing application isolation and security between the various virtual machines. Furthermore, some virtualization technologies are capable of providing virtual resources spanning two or more physical resources, such as a single virtual machine with multiple virtual processors spanning multiple different physical computing systems. Using virtualization, a single physical computing device can dynamically create, maintain, or delete virtual machines. In turn, users can request computing resources from the data center, and varying numbers of virtual machine resources can be provided to users “on demand” or at least “on request.” Some of these virtualized resources can be used to implement virtual desktop instances that can host remote computing sessions.

[0003] Service providers that implement virtual desktop instances for their customers' benefit typically shut down the underlying service provider resources each time a customer disconnects from their virtual desktop instance (e.g., by logging out). When a customer wants to reconnect to their virtual desktop instance, it can take a long time for the service provider resources to be restored. Furthermore, restarting any applications that were previously running on the service provider resources can also take a very long time before the customer can continue working (e.g., two orders of magnitude longer than logging into the local computer). Attached Figure Description

[0004] Figure 1 This is a block diagram illustrating an exemplary provider network environment according to at least some implementation schemes.

[0005] Figure 2 This is a block diagram illustrating an exemplary provider network according to at least some embodiments, which provides storage virtualization services and hardware virtualization services to customers.

[0006] Figure 3 This is a block diagram illustrating a networked computing environment according to at least some embodiments, the networked computing environment including client computing devices communicating with a service provider's computer network.

[0007] Figure 4 This is a block diagram illustrating an exemplary service provider data center according to at least some implementation schemes.

[0008] Figure 5 This is a flowchart illustrating one implementation of a method for managing resources for virtual desktop instances.

[0009] Figure 6 This is a flowchart illustrating an implementation of a method for detecting that a client has disconnected from a virtual desktop instance (or has been effectively disconnected from a virtual desktop instance through inactivity).

[0010] Figure 7 This is a flowchart illustrating an implementation of a method for determining whether and / or when to shut down a computing resource instance of a virtual desktop instance by applying one or more shutdown policies.

[0011] Figure 8 This is a flowchart illustrating an implementation of a method for predictive models of establishing and disconnecting virtual desktop instances.

[0012] Figure 9 This is a flowchart illustrating an implementation of a method for managing service provider resources in response to disconnection and reconnection of virtual desktop instances.

[0013] Figure 10 This is a flowchart illustrating one implementation of a method for initializing and modifying the configuration and / or shutdown policies of a virtual desktop instance.

[0014] Figure 11 This is a block diagram illustrating an example provider network that provides virtual desktop services with a pool of virtual desktop instances to client organizations, according to at least some implementation schemes.

[0015] Figure 12This is a block diagram illustrating a further aspect of an example provider network offering virtual desktop services with a pool of virtual desktop instance pools, according to at least some implementations, wherein the virtual desktop instance pool includes connected and disconnected virtual desktop instances in different slots within the pool.

[0016] Figure 13 This is a block diagram illustrating a further aspect of an example provider network offering virtual desktop services with a pool of virtual desktop instances according to at least some implementations, including providing client devices with access to virtual desktop instances outside the pool when all slots in the pool are occupied by connected instances.

[0017] Figure 14 This is a block diagram illustrating other aspects of an example provider network offering virtual desktop services with a pool of virtual desktop instances, according to at least some implementations, including the recycling of disconnected virtual desktop instances in the pool.

[0018] Figure 15 This is a block diagram illustrating a further aspect of an example provider network offering virtual desktop services with a pool of virtual desktop instances, according to at least some embodiments, including providing client devices with access to restarted virtual desktop instances in the pool.

[0019] Figure 16 This is a flowchart illustrating one implementation of a method for managing a pool of virtual desktop instances.

[0020] Figure 17 This is a flowchart illustrating one implementation of a method for recycling disconnected virtual desktop instances in a pool.

[0021] Figure 18 The diagram illustrates an exemplary computer system block diagram according to different implementations, which implements some or all of the technologies described herein.

[0022] While embodiments have been described herein by way of example with reference to several embodiments and illustrative drawings, those skilled in the art will recognize that the embodiments are not limited to the described embodiments or drawings. It should be understood that the drawings and their detailed description are not intended to limit the embodiments to the specific forms disclosed, but rather are intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope defined by the appended claims. The headings used herein are for organizational purposes only and are not intended to limit the scope of this specification or the claims. The word “may” as used throughout this application is used in a permissive sense (i.e., meaning possible) rather than a mandatory sense (i.e., meaning required). Similarly, the word “comprising” means including, but not limited to, the embodiments described herein. Detailed Implementation

[0023] This document describes various implementations of systems, methods, and computer-readable media for managing virtual desktop instance pools. In a service provider system that provides virtualized computing resources to customers, a virtual desktop service can offer virtual desktop instances to customers. The client organization and the provider network can agree that the provider network will reserve a pool of virtual desktop instances for the client organization's users. This pool can include a predetermined or fixed number of slots. Any slot can be filled with connected virtual desktop instances, disconnected (but still running) virtual desktop instances, or no virtual desktop instances (i.e., empty slots). The number of users in the client organization may typically exceed the number of slots in the pool. If all slots are occupied by connected instances, users in the client organization may be denied access to the pool. For example, when the ratio of connected instances approaches complete exhaustion of all slots, disconnected (but running) instances can be reclaimed and made available to satisfy new connection requests. Disconnected instances to be reclaimed can be selected based on the duration of instance idle time (e.g., prioritizing the most recently disconnected instances), the expected duration of instance restart (e.g., prioritizing disconnected instances that will take the longest to restart), the user's relative ranking or other characteristics (e.g., prioritizing disconnected instances belonging to users with higher rankings or higher priorities), and / or other suitable criteria. In some cases, if the pool is full of connected instances, the pool can be dynamically expanded, or client devices can be provided with access to virtual desktop instances outside the pool (e.g., hourly billed instances).

[0024] Resource management of virtual desktop instances

[0025] In different implementations, the systems and methods described herein are implemented through one or more computing systems within a network environment. Figure 18 The document illustrates an example computer system on which implementations of the techniques described herein for managing resources of virtual desktop instances can be carried out. In this document, implementations of various systems and methods for implementing these techniques are typically described in the context of a service provider that provides virtualized resources (e.g., virtualized computing and storage resources) to customers via an intermediary network (such as the Internet), which are implemented on the service provider's provider network. Figure 1-4 and Figure 11(And its corresponding description) Exemplary environments are shown and described in which embodiments of the systems and methods described herein may be implemented, and are not intended to be limiting. In at least some embodiments, at least some of the resources provided to the service provider's customers through the provider network may be virtualized computing resources implemented on multi-tenant hardware shared with other customers and / or on hardware dedicated to a particular customer. Each virtualized computing resource may be referred to as a resource instance. Resource instances may, for example, be leased to the service provider's customers. For example, the service provider's customers may access one or more services of the provider network via the service's API to obtain and configure resource instances and to establish and manage virtual network configurations (e.g., virtualized private networks) including resource instances.

[0026] In some implementations, resource instances may be implemented, for example, using hardware virtualization technology that enables multiple operating systems to run simultaneously on a host computer (i.e., as virtual machines (VMs) on the host). A hypervisor or virtual machine monitor (VMM) on the host can present the VMs on the host through the virtual platform and monitor their execution. Each VM can be configured with one or more dedicated IP addresses; the VMM on the host can know the dedicated IP addresses of the VMs on the host. Examples of systems employing this hardware virtualization technology are... Figure 4 It is shown in the figure and described in detail below.

[0027] Exemplary provider network environment

[0028] This section describes exemplary provider network environments in which implementations as described herein can be carried out. However, these exemplary provider network environments are not intended to be limiting. In various implementations, within these provider network environments, the service provider may host virtualized resource instances on behalf of customers that can be accessed by end users. For example, an end user associated with a customer hosting a virtualized resource instance on their behalf (e.g., a member of the same organization or enterprise) may be able to access the virtualized resource instance using a client application on a client device. In some implementations, the virtualized resource instance may be configured to implement a virtual desktop instance.

[0029] Figure 1An exemplary provider network environment according to at least some embodiments is illustrated. Provider network 100 may provide resource virtualization to customers through one or more virtualization services 110, which allow customers to purchase, lease, or otherwise obtain instances 112 of virtualized resources (including, but not limited to, compute and storage resources) implemented on devices within one or more provider networks in one or more data centers. A private IP address 116 may be associated with resource instance 112; the private IP address is the internal network address of resource instance 112 on provider network 100. In some embodiments, provider network 100 may also provide public IP addresses 114 and / or ranges of public IP addresses (e.g., Internet Protocol version 4 (IPv4) addresses or Internet Protocol version 6 (IPv6) addresses), which customers may obtain from provider 100.

[0030] Typically, provider network 100 may, via virtualization service 110, allow the service provider's customers (e.g., customers operating customer networks 150A, 150B, or 150C, each of which may include one or more client devices 152) to dynamically associate at least some public IP addresses 114 assigned or allocated to the customer with specific resource instances 112 assigned to the customer. Provider network 100 may also allow customers to remap public IP addresses 114 previously mapped to one virtualized computing resource instance 112 assigned to the customer to another virtualized computing resource instance 112 also assigned to the customer. For example, by using virtualized computing resource instances 112 and public IP addresses 114 provided by the service provider, the service provider's customers (such as operators of customer network 150A) can implement customer-specific applications and present these applications on an intermediate network 140 (such as the Internet). Then, other network entities 120 on intermediate network 140 can generate traffic destined for public IP address 114 published by customer network 150A; the traffic is routed to the service provider data center, and at the data center, it is routed via the network layer to the private IP address 116 of the virtualized computing resource instance 112 currently mapped to the destination public IP address 114. Similarly, response traffic from virtualized computing resource instance 112 can be routed back to intermediate network 140 via the network layer to the source entity 120.

[0031] As used herein, a private IP address refers to the internal network address of a resource instance within a provider network. Private IP addresses can only be routed within the provider network. Network traffic originating outside the provider network is not directly routed to private IP addresses; instead, traffic uses public IP addresses mapped to resource instances. A provider network may include network devices or facilities that provide Network Address Translation (NAT) or similar functionality to perform mappings from public IP addresses to private IP addresses and vice versa.

[0032] As used in this article, a public IP address is a network address that is routed on the Internet and assigned to a resource instance by a service provider or customer. Traffic routed to a public IP address is translated, for example, via 1:1 Network Address Translation (NAT) and forwarded to the corresponding private IP address of the resource instance.

[0033] Some public IP addresses may be assigned to specific resource instances by the provider's network infrastructure; these public IP addresses may be referred to as standard public IP addresses or simply as standard IP addresses. In at least some implementations, mapping the standard IP addresses of resource instances to private IP addresses is the default startup configuration for all resource instance types.

[0034] At least some public IP addresses may be assigned to or obtained by the provider network 100's customers; customers can then assign the public IP addresses assigned to them to specific resource instances assigned to them. These public IP addresses may be referred to as client public IP addresses or simply client IP addresses. Instead of being assigned to resource instances by the provider network 100 as in the case of standard IP addresses, client IP addresses may be assigned to resource instances by the customer via, for example, an API provided by the service provider. Unlike standard IP addresses, client IP addresses may be assigned to customer accounts by the respective customers as needed or desired, and remapped to other resource instances. In some implementations, client IP addresses are associated with customer accounts rather than specific resource instances, and the customer has control over the IP address until the customer chooses to release it. Unlike regular static IP addresses, client IP addresses allow clients to mask resource instance or availability zone failures by remapping the client's public IP address to any resource instance associated with the customer's account. Client IP addresses, for example, may enable clients to resolve resource instance or software problems by remapping the client IP address to an alternative resource instance.

[0035] It should also be noted that in some implementations, the resource instance 112 available to a client (e.g., client device 152) via virtualization service 110 may include multiple network interfaces. For example, at least some of them may include a network interface for communicating with various components of the client network 150, and another network interface for communicating with resources or other network entities on another network (not shown) outside the provider network 100.

[0036] Figure 2 This is a block diagram of another exemplary provider network environment according to at least some embodiments, which provides storage virtualization services and hardware virtualization services to customers. In this example, hardware virtualization service 220 provides multiple computing resources 224 (e.g., VMs) to customers. Computing resources 224 may, for example, be leased to customers of provider network 200 (e.g., customers implementing customer network 250). Each computing resource 224 may be configured with one or more private IP addresses. Provider network 200 may be configured to route packets from the private IP addresses of computing resources 224 to public Internet destinations, and from public Internet sources to computing resources 224.

[0037] Provider network 200 enables client network 250, for example, connected to intermediate network 240 via local network 256, to implement virtual computing system 292 via hardware virtualization service 220 connected to intermediate network 240 and connected to provider network 200. In some embodiments, hardware virtualization service 220 may provide one or more APIs 202 (e.g., web service interfaces), through which client network 250 may access functionality provided by hardware virtualization service 220, for example, via console 294. In at least some embodiments, each virtual computing system 292 on client network 250 at provider network 200 may correspond to computing resources 224 leased or otherwise provided to client network 250.

[0038] Clients can access the functionality of storage virtualization service 210 from an instance of virtual computing system 292 and / or another client device 290 or console 294 (e.g.) via one or more APIs 202 to access data from virtual data storage 216 provided by provider network 200 and to store data in virtual data storage 216. In some embodiments, a virtualized data storage gateway (not shown) may be provided at client network 250, which may locally cache (e.g.) at least some frequently accessed or important data and may communicate with virtualized data storage service 210 via one or more communication channels to upload new or modified data from the local cache, thereby maintaining the primary storage (virtualized data storage 216) of the data. In at least some embodiments, users can mount and access one or more storage volumes 218 of virtual data storage 216 via virtual computing system 292 and / or on another client device 290, each of which appears to the user as a local virtualized storage area 298.

[0039] Although Figure 2 While not shown, the virtualization service can also be accessed from resource instances within provider network 200 via API 202. For example, a customer, facility service provider, or other entity can access the virtualization service via API 202 from a corresponding private network on provider network 200 to request allocation of one or more resource instances within that private network or another private network. Note that in some embodiments, hardware virtualization service 220 may be configured to provide computing resources 224 that have been configured to implement virtual desktop instances that may appear to the user as a local desktop (implemented by virtual computing system 292). It should also be noted that in some embodiments, computing resources 224 available to clients via hardware virtualization service 220 may include multiple network interfaces. For example, at least some of them may include one network interface for communicating with various components of customer network 250, and another network interface for communicating with computing resources or other network entities on another network (not shown) outside provider network 200.

[0040] In some implementations, various components of the service provider network can be configured to generate and manage remote computing sessions between virtual desktop instances hosted on one or more remote data center computers within a client computing device and a Program Execution Service (PES) platform. Numerous data centers can be organized as part of a single PES platform that facilitates the utilization of data center resources by PES customers. In some implementations, the PES may comprise hundreds or thousands of data center computers. For example, in some implementations, client computing devices can access virtual desktop instances during one or more remote computing sessions, and the virtual desktop instances can provide users with all the capabilities of a client desktop environment, but centrally provide the services accessed by the client.

[0041] In some implementations, a user may transmit a request to load an application, such as a remote computing application, via a client computing device. Upon receiving the request, the client computing device may communicate with the PES platform to initiate a remote computing session. In one implementation, communication between the client computing device and the PES platform may include login information. In other implementations, communication may also include information identifying resource usage information, processing requests, or rules regarding the duration or conditions of the remote computing session for the user of the client computing device. The client computing device may additionally transmit various information about the device status, including but not limited to the current or future availability of device resources (e.g., processing power, memory, storage devices, network usage, etc.). Using the received information, the PES platform may identify one or more virtual desktop instances for execution in one or more remote computing sessions. In one example, the PES platform may instantiate, or cause to instantiate, a virtual machine instance on a data center computer; the virtual machine instance may include an operating system. The client computing device may then establish a remote computing session with the virtual machine, and the operating system's user interface (e.g., operating system output, such as a graphical user interface, sound, etc.) may be sent to the client computing device via a specific network interface of the virtual machine instance or virtual desktop instance and presented to the user (e.g., a graphical user interface may be presented on the client computing device's display). The operating system can use a desktop profile associated with the user and stored on desktop storage accessible by the PES to configure the user's virtual desktop instance by setting desktop background, screen saver, desktop layout, pointer preferences, sound settings, and more. User input, such as mouse and keyboard activity, can then be sent to the virtual machine (via a specific network interface of the virtual machine instance or virtual desktop instance) and injected into the operating system as if the user were performing the activity directly at the virtual machine.

[0042] In some implementations, the PES platform can receive or generate data during a remote computing session, the data being associated with interactions between a client computing device and a virtual desktop instance on that client computing device. The data may include user data and preferences, files, etc. Upon receiving the data, the PES platform can save it to desktop storage associated with the virtual desktop instance. In some implementations, the desktop storage may be implemented on a volume or on another logical block storage device. In some implementations, PES may create a backup copy of the data or additionally store the data in a central repository. The saved data can then be used to restore remote computing sessions interrupted due to failures such as failures of the virtual desktop instance, the server hosting the virtual desktop instance, the network, etc. By saving user data, the PES platform ensures that remote computing sessions are re-established with minimal latency and interruption for the client computing device user.

[0043] In some implementations, the provided virtual desktop instances can be configured based on user profiles stored in the PES user profile store. The configuration of virtual desktop instances can also be adjusted based on monitored usage of the instances. In some implementations, user profiles can be set by an administrator associated with the entity controlling user usage. User profiles can specify various memory and processing requirements associated with the PES computer running one or more virtual desktop instances, as well as requirements for the virtual desktop instances. For example, user profiles can specify the programs that a user can access while using a virtual desktop instance. User profiles can also specify the maximum time or cost associated with a remote computing session. The PES can take user profiles into account when placing and configuring virtual desktop instances. Furthermore, placement and configuration decisions can be adjusted over time based on user interactions with the virtual desktops.

[0044] Figure 3This is a block diagram illustrating an exemplary networked computing environment 300, which includes a client computing device 306 communicating with a service provider's computer network 305 via a communication network 304. The client computing device 306 can be used to provide users with access to a remote operating system and applications. In various embodiments, the client computing device 306 can correspond to a wide variety of computing devices, including personal computing devices, laptop computing devices, handheld computing devices, terminal computing devices, mobile devices (e.g., mobile phones, tablet computing devices, e-book readers, etc.), wireless devices, various electronic devices and facilities, etc. In some embodiments, the client computing device 306 includes the necessary hardware and software components for establishing communication via the communication network 304 (such as a wide area network or a local area network). For example, the client computing device 306 may be equipped with networking devices and browser software applications that facilitate communication via the Internet or an internal network. The client computing device 306 may have different local computing resources, such as central processing units and architectures, memory, mass storage devices, graphics processing units, communication network availability and bandwidth, etc.

[0045] In one implementation, client computing device 306 may run remote computing application 330. Remote computing application 330 may request access to a virtual desktop instance hosted on service provider computer network 305. Remote computing application 330 may also manage remote computing sessions between client computing device 306 and service provider computer network 305. Figure 3 As shown, the service provider computer network 305 may also include the PES platform 302. Figure 3 The PES platform 302 shown corresponds to a logical association with one or more data centers associated with a service provider. The PES platform 302 may be associated with multiple data center computers, such as data center computer 310. Each data center computer 310 may host one or more virtual desktop instances 314. For example, data center computer 310 may host virtual desktop instances by executing virtual machines on physical devices. Virtual machines may execute instances of operating systems and application software to create virtual desktop instances. Each virtual desktop instance executed by PES 302 may be accessed by one or more client computing devices, such as client computing device 306.

[0046] In some implementations, data center computers 310 may be associated with private network addresses (such as IP addresses) within the service provider computer network 305, preventing them from being directly accessed by client computing devices 306. Virtual desktop instances 314 may be associated with public network addresses, which can be obtained through a gateway at the edge of the service provider computer network 305. Therefore, virtual desktop instances 314 can be directly addressed by client computing devices 306 via public network addresses. Those skilled in the art will recognize that each data center computer 310 will include physical computing resources and software to execute multiple virtual desktop instances 314 or dynamically instantiate virtual desktop instances 314. Such instantiation may be based on specific requests, such as those from client computing devices 306.

[0047] like Figure 3 As shown, the data center computer 310 may include one or more instance managers 322. The instance manager 322 may reside on the same computer as the corresponding instance 314, or on a separate computer. The instance manager 322 may track the progress of instances running on the data center computer 310, monitor and coordinate the storage of data created by users when users interact with instance 314 via client computing devices, and monitor the overall health and status of the data center computer 310 and the remote computing applications running on client computing devices 306. The instance manager 322 may exchange information collected through tracking and monitoring with the data center management component 301 of the PES platform 302 to effectively manage various remote computing sessions between the data center computer 310 and client computing devices 306. In some embodiments, the techniques described herein for detecting activity or inactivity on virtual desktop instances, monitoring and tracking connections, disconnections, and reconnections with various virtual desktop instances, and determining whether and / or when to shut down underlying virtualized computing resources may be performed by the instance manager 322.

[0048] like Figure 3 As shown, the service provider network 305 may also include a storage service platform 303. The storage service platform 303 may include, or be connected to, one or more storage servers 307. Storage servers 307 may be used to store data generated or utilized by the virtual desktop instance 314. The data generated or utilized by the virtual desktop instance 314 may be based on interactions between the client computing device 306 and the PES 302 via one or more remote computing sessions.

[0049] In some implementations, the storage service platform 303 logically organizes and maintains information associated with the virtual desktop instances 314 hosted in the desktop storage. The information associated with the virtual desktop instances 314 maintained in the desktop storage may include, but is not limited to, user preferences, user or customer-specific policies, information related to program data execution, user content, references to user content, etc. For example, folders used by users to store music, files, etc., on other storage devices (including through storage service providers) may also be mapped to the desktop storage via references to those storage locations. That is, input / output operations (such as requests to open files in these folders) may be redirected to the desktop storage. Thus, when a user attempts to open a file stored in their folder, the request may be redirected from the operating system running in the virtual desktop instance to the desktop storage. In addition to user-created data, a user's desktop profile may also be stored on the desktop storage associated with the user's virtual desktop instance, and the user's desktop profile may include, for example, desktop configuration information such as background images, fonts, icon arrangements, etc. In some implementations, the service provider computer network 305 may be able to mitigate the impact of failures of the data center computer 310 running the virtual desktop instance 314, or errors associated with the execution of the virtual desktop instance 314 on the data center computer 310, by storing data on a storage server independent of the data center computer 310. Additionally, the service provider network 305 may facilitate client interaction with multiple virtual desktop instances 314 by maintaining information in the desktop storage. In some implementations, if a virtual desktop instance 314 fails, a new instance can be launched and attached to the same desktop storage previously attached to the failed virtual desktop instance 314.

[0050] In various implementations, desktop storage can be distributed across multiple servers. For performance purposes, it can be replicated between servers in different network zones, or for backup or fault performance purposes, it can be replicated across multiple servers with independent fault profiles. For example, servers may be attached to different power or cooling systems, servers may be located in different server rooms or different data centers, and / or servers may be attached to different routers or network switches. In some implementations, desktop storage may reside on a single storage server, and changes made to the desktop storage can be replicated to another desktop storage on a different storage server. Such replication can create a backup copy of the user's data. If desktop storage fails or virtual desktop instance 314 loses its connection to desktop storage, PES 302 can switch the connection of virtual desktop instance 314 from desktop storage to backup desktop storage.

[0051] like Figure 3As shown, the PES platform 302 may also include a central storage device (such as the PES repository 340) for storing data stored by various desktop and backup storage devices on the storage server 307. The data center computer 310 and the storage server 307 may also include additional software or hardware components that facilitate communication, including but not limited to load balancing or load sharing software / hardware components for selecting instances of virtual machines to support the requested application and / or providing information to the DNS name server to facilitate request routing.

[0052] As illustrated in this example, the service provider computer network 305 may include a user profile store 308. The user profile store 308 may be used to store, for example, various programs that a user can access while using the virtual desktop instance 314. The stored user profiles may also indicate the maximum time or cost associated with a remote computing session for a different user. The PES platform 302 may take user profiles into account when placing, configuring, and / or managing the virtual desktop instance 314. The PES platform 302 may also include, or be connected to, a virtual desktop image store 309. The virtual desktop image store 309 may include a template image of the operating system that is not customized according to the user profile.

[0053] In some implementations, data center computer 310 and storage server 307 can be considered logically grouped, regardless of whether the components or parts of the components are physically separate. For example, service provider computer network 305 may provide virtual desktop instances 314 and storage components in separate locations. Additionally, although data center computer 310 is... Figure 3 While shown as logically associated with PES platform 302, data center computers 310 can be geographically distributed in a manner best suited to the diverse demographic characteristics of their users. Furthermore, those skilled in the art will recognize that service provider computer network 305 can be associated with various additional computing resources, such as those used for managing content and resources. For example, service provider computer network 305 (and / or various virtual desktop instances 314 implemented thereon) can be configured to communicate with other network entities 320 via communication network 304 or another communication network (e.g., at least some of the virtual desktop instances 314 may include network interfaces for accessing one or more other network entities 320, said network interfaces being separate and different from the network interfaces used for communicating with client computing devices 306). These other network entities 320 may include, for example, other client networks or their computing devices, computing systems providing resources to fulfill requests received from client computing devices 306, and / or networks or their computing devices that access other services, applications, or data via the Internet.

[0054] In some implementations, processing requirements associated with a user or client computing device can be determined based on various scenarios. In some implementations, this determination may be based on a user request when the remote computing application 330 is launched. For example, a graphical user interface (GUI) can be presented to the user, displaying various options for resources and applications. The user can then select the applications they wish to access, or alternatively, select versions of those applications. For example, one user might wish to access the basic version of an application, while another user might wish to access a professional version of the same application. The determination may also be based on options pre-selected for certain users, as determined by an administrator of the entity associated with the user. For example, pre-selected options may be presented to the user as a list of different application packages that the user might wish to access. In some cases, this determination can be made based on the user's historical usage data, and the PES platform 302 can make the determination once a request is received from the user. In other cases, once a remote computing session is initiated, the determination of processing requirements can be based on real-time monitoring of the user's process usage. In such cases, the selection of an appropriate resource instance can be dynamically changed after the session is established, and the action of dynamically replacing it with a new instance can be referenced above. Figure 3 Perform as described. In some implementations, the remote computing application 330 may request to open a virtual desktop session on behalf of the client. In response, a virtual desktop instance 314 may be instantiated, configured for client use, and / or connected to the client computing device 306 via network 304 (e.g., via one of the two network interfaces of the virtual desktop instance 314).

[0055] In some implementations, service provider networks implementing VMs and VMMs can use Internet Protocol (IP) tunneling technology to encapsulate and route client data packets between client resource instances on different hosts within the provider network, through the network layer. The provider network may include a physical network layer comprising networking devices such as routers, switches, Network Address Translation (NAT) devices, and physical connections between these devices. The provider network may employ IP tunneling technology to provide an overlay network through which encapsulated data packets (i.e., client data packets tagged with overlay network metadata, including but not limited to overlay network address information used for routing through the overlay network) can be transmitted through the network layer via tunnels or overlay network routes. IP tunneling technology can provide a mapping and encapsulation system for creating overlay networks at the network layer and can provide separate namespaces for the overlay network layer (public IP addresses) and the network layer (private IP addresses). In at least some implementations, encapsulated data packets in the overlay network layer can be examined against a mapping directory to determine what their tunnel layer target (private IP address) should be. IP tunneling technology can provide a virtual network topology overlaid on the physical network layer; the interface presented to the client (e.g., a service API) is attached to the overlay network, so that when a client resource instance provides the IP address to which a packet will be sent, the IP address is enabled in the virtual space by communicating with a mapping service that can determine where the IP overlay address is located. Figure 4 An exemplary use of overlay network technology is shown in the figure and described in detail below.

[0056] In various implementations, client resource instances on a host can communicate with other client resource instances on the same or different hosts using stateful protocols such as Transmission Control Protocol (TCP) and / or stateless protocols such as User Datagram Protocol (UDP). However, client packets are encapsulated by the sending VMM according to an overlay network protocol and decapsulated by the receiving VMM. Upon receiving a client packet (e.g., a TCP or UDP packet) from a client resource instance on that host and destined for the IP address of another client resource instance, the host-based VMM encapsulates or tags the client packet according to an overlay network (or IP tunneling) protocol and sends the encapsulated packet over the overlay network for delivery. The encapsulated packet can then be routed to another VMM via the overlay network using IP tunneling technology. The other VMM strips the overlay network encapsulation from the packet and delivers the client packet (e.g., a TCP or UDP packet) to the appropriate VM on the host that implements the target client resource instance. In other words, in some implementations, although there may be a single underlying physical network in the service provider computing environment (e.g., a service provider data center), the encapsulation described herein can allow it to appear as if each client application (or each client resource instance on which one or more client applications execute) is running on its own virtual network (e.g., packets from multiple client applications may travel on the same physical network, but may appear as if traffic destined for each client application is traveling on a private network).

[0057] In some implementations, the overlay network may be a stateless network implemented according to a connectionless (or stateless) IP protocol. In some such implementations, the sending VMM sends encapsulated packets to the overlay network for routing and delivery, but does not receive acknowledgments (ACKs) or other responses regarding the delivery of the packets. In other implementations, the VMM may receive ACKs or other responses regarding the delivery of the encapsulated packets.

[0058] Figure 4 An exemplary data center according to at least some embodiments is illustrated (e.g., a data center implementing an overlay network at a network layer using IP tunneling technology). As shown in this example, provider data center 400 may include a network layer including networking devices 412, such as routers, switches, network address translation (NAT), etc. At least some embodiments may employ Internet Protocol (IP) tunneling technology to provide an overlay network, which can be used to transmit encapsulated data packets through the network layer 410 via the overlay network. IP tunneling technology can provide for overlay networks (e.g., Figure 4A mapping and encapsulation system for overlay networks is created on the local network in data center 400, and separate namespaces are provided for the overlay layer (public IP addresses) and the underlying network layer 410 (private IP addresses). Packets in the overlay layer can be examined against a mapping catalog (e.g., provided by mapping service 430) to determine what their tunneling underlying target (private IP address) should be. IP tunneling technology provides a virtual network topology (overlay network); an interface presented to the client (e.g., a service API) is attached to the overlay network, so that when the client provides the IP address to which it wants to send packets, the IP address is enabled in the virtual space by communicating with the mapping service (e.g., mapping service 430) that knows the location of the IP overlay address.

[0059] In at least some implementations, IP tunneling technology maps IP overlay addresses (public IP addresses) to underlying IP addresses (private IP addresses), encapsulates packets within a tunnel between two namespaces, and delivers the packets via the tunnel to the correct endpoint, where the encapsulation is stripped from the packets. Figure 4 The diagram illustrates an exemplary overlay network tunnel 434A from virtual machines (VMs) 424A (424A1, 424A2, 424A3, or 424A4) on host 420A to a device on intermediate network 440 (e.g., computing system 470, computing system 452 on local network 450, or data center 46), and an exemplary overlay network tunnel 434B between VMs 424B (424B1, 424B2, 424B3, or 424B4) on host 420B and VMs 424A on host 420A. In some embodiments, packets may be encapsulated in an overlay network packet format before transmission and may be stripped of the overlay network packet upon receipt. In other embodiments, instead of encapsulating packets in an overlay network packet format, the overlay network address (public IP address) may be embedded in the underlying address (private IP address) of the packet before transmission and stripped of the overlay network address from the packet address upon receipt. As an example, a 32-bit IPv4 (Internet Protocol version 4) address can be used as a public IP address to implement an overlay network, while the IPv4 address can be embedded as part of a 128-bit IPv6 (Internet Protocol version 6) address used as a private IP address on the underlying network.

[0060] At least some of the networks implementing the techniques described herein for managing resources of virtual desktop instances may include hardware virtualization techniques that enable multiple operating systems to run simultaneously on a host computer (e.g., Figure 4The virtual machines (VMs) 424 (i.e., virtual desktop instances 424) run on hosts 420A and 420B. Some of these VMs 424 (which may be configured to implement virtual desktop instances for client use) may be leased to customers of a network provider, for example. A hypervisor or virtual machine monitor (VMM) 422 (422A or 422B) on host 420 may act as an instance manager for VMs 424 and / or other virtualized resource instances on host 420, and may include presenting virtual platforms to VMs 424 on the host and monitoring the execution of VMs 424. In some implementations, the techniques described herein for detecting activity or inactivity on virtual desktop instances, monitoring and tracking connections to various virtual desktop instances, disconnecting and reconnecting, and determining whether and / or when to shut down underlying virtualized computing resources may be performed by VMM 422. Each VM 424 may be configured with one or more private IP addresses; VMM 422 on host 420 may be aware of the private IP addresses of the VMs 424 on host. Mapping service 430 can know all network IP prefixes and IP addresses of routers or other devices providing IP addresses on the local network. This includes the IP addresses of VMM 422 serving multiple VMs 424. Mapping service 430 can be centralized, for example, on a single server system, or alternatively distributed among two or more server systems or other devices on the network. The network can use, for example, mapping service technology and IP tunneling technology to route packets between VMs 424 on different hosts 420 within the data center 400 network; note that Interior Gateway Protocol (IGP) can be used to exchange routing information within such a local network.

[0061] In addition, networks such as provider data center 400 networks (sometimes called Autonomous Systems (AS)) can use mapping services, IP tunneling, and routing services to route packets from VM 424 to Internet destinations, and from Internet sources to VM 424. It should be noted that External Gateway Protocol (EGP) or Border Gateway Protocol (BGP) is typically used for Internet routing between sources and destinations on the Internet. Figure 4 An exemplary provider data center 400 is illustrated according to at least some embodiments of a network that provides resource virtualization technology and offers full internet access via an edge router 414 connected to an internet transit provider. The provider data center 400 may, for example, enable clients to access the network via hardware virtualization services (such as...) Figure 2 The hardware virtualization service 220 in the middle) implements a virtual computing system (VM424), and can also be used through storage virtualization services (such as Figure 2 The storage virtualization service 210 implements virtualized data storage 416 on storage resources 418 (including 418A, 418B...).

[0062] In some implementations, the data center 400 network may implement IP tunneling, mapping, and routing technologies to route traffic to and from virtualized resources, such as routing packets from VM 424 on host 420 in data center 400 to an internet destination, and from an internet source to VM 424. Internet sources and destinations may include, for example, computing system 470 connected to an intermediate network 440 and computing system 452 connected to a local network 450, which is connected to the intermediate network 440 (e.g., by connecting network 450 to an edge router 414 of an internet transit provider). The provider's data center 400 network may also route packets between resources within data center 400, such as routing packets from VM 424 on host 420 in data center 400 to other VM 424 on the same host or other hosts 420 in data center 400. In some implementations, at least some VM 424 may include two or more network interfaces. For example, they may include a network interface for communication between the VM 424 and a client hosted by the provider on its behalf, and a second (separate and different) network interface for accessing external resources, computing systems, data centers, or Internet destinations on networks other than the provider network and the client network, either or both of which may employ IP tunneling technology as described herein.

[0063] The service provider providing data center 400 may also provide an additional data center 460, which includes hardware virtualization technology similar to data center 400 and can also be connected to an intermediate network 440. Data packets can be forwarded from data center 400 to other data centers 460, for example, from VM 424 on host 420 in data center 400 to another VM on another host in another similar data center 460, and vice versa.

[0064] While the above describes hardware virtualization technology that enables multiple operating systems to run simultaneously on a host computer as virtual machines (VMs) on the host, where VMs can be leased to network provider customers, hardware virtualization technology can also be used to provide other computing resources (e.g., storage resource 418) as virtualized resources to network provider customers in a similar manner.

[0065] Note that a public network can be broadly defined as a network that provides open access to multiple entities and interconnectivity between them. The Internet or the World Wide Web (WWW) is an example of a public network. A shared network can be broadly defined as a network where access is limited to two or more entities, unlike a public network where access is generally unrestricted. A shared network may include, for example, one or more local area networks (LANs) and / or data center networks, or two or more LANs or data center networks interconnected to form a wide area network (WAN). Examples of shared networks include, but are not limited to, corporate networks and other enterprise networks. The scope of a shared network can range from a network covering a local area to a global network. It should be noted that a shared network may share at least some network infrastructure with a public network, and the shared network may be connected to one or more other networks, which may include public networks, with controlled access between the shared network and other networks. Compared to public networks such as the Internet, a shared network can also be considered a private network. In various implementations, both shared and public networks can be used as intermediary networks between the provider network and the customer network, or between the provider network and other network entities, such as external resources, computing systems, data centers, or Internet destinations on networks other than the provider network and the customer network on which the provider hosts VM 424.

[0066] In some implementations, although a physical computer exists to execute the client applications and other processes described herein, the client applications may run as virtual machines on the physical computer. For example, internal processes of a cloud computing environment may execute in the control plane layer (or hypervisor) of the cloud computing environment, configured to manage the creation of these virtual machines, provide resources for these virtual machines, and / or perform other administrative tasks on behalf of clients and / or their applications (e.g., monitoring resource usage, customer accounting, service billing, etc.). In contrast, client applications (e.g., each resource instance implementing application components) may execute in the data plane layer of the cloud computing environment. Below these layers, in some implementations, only one physical network card may exist for each host node (or for multiple host nodes), but each resource instance can execute as if it had its own network (e.g., a virtual network). In some implementations, each resource instance may have its own data plane network connectivity but can make local API calls (e.g., calls to components on the same node) without relying on these data plane network connections.

[0067] In some implementations, a customer may have an application running on a local machine, but resource instances in a cloud computing environment may be available for use in case the local machine fails. In some implementations, multiple resource instances may be executed in a cloud computing environment to implement a distributed application on behalf of the client. In various implementations, the cloud computing environment may be a multi-tenant environment where each application (and / or each virtual private network) may have its own namespace. In some implementations, each client may have its own allocated network connectivity and / or throughput (bandwidth). For example, network connectivity and / or throughput in a data plane network may be provided (e.g., specified or reserved) for use by various clients.

[0068] In various implementations, a provider of virtual computing services may implement a private network for at least some customers on its provider network. For example, a virtual private network (VPN) for a customer on a service provider network allows the customer to connect its existing infrastructure (e.g., client devices) on its customer network to a set of logically isolated resource instances (e.g., VMs and storage devices or volumes) and extend management capabilities such as security services, firewalls, and intrusion detection systems to encompass its resource instances. In some implementations, the customer's virtualized private network can be connected to the customer network via a dedicated communication channel. This dedicated communication channel can be, for example, a tunnel implemented using network tunneling technology or through other peer-to-peer connections of an intermediate network. The intermediate network can be, for example, a shared network or a public network (such as the Internet). Alternatively, the dedicated communication channel can be implemented via a direct dedicated connection between the VPN and the customer network.

[0069] To establish a Virtual Private Network (VPN) for customers on a provider network, one or more resource instances (e.g., VM storage devices or volumes) can be assigned to the VPN. Note that other resource instances can remain available on the provider network for use by other clients. A public IP address range can also be assigned to the VPN. Additionally, one or more networking devices (routers, switches, etc.) from the provider network can be assigned to the VPN. A dedicated communication channel can be established between a dedicated gateway at the VPN and a gateway at the customer network. In at least some embodiments, in addition to or instead of a dedicated gateway, the VPN may include a public gateway that enables resources within the VPN to communicate directly with other entities (e.g., network entities) via an intermediate network (instead of or besides via a dedicated communication channel), and vice versa. In some embodiments, the VPN may, but is not necessarily, be subdivided into two or more subnets (not shown). In other embodiments, one or more VMs can be configured to access the customer network via a dedicated communication channel through a dedicated gateway (e.g., via a network interface configured for communication between the VM and client devices), and to access other network entities via a public gateway, via an alternate communication channel.

[0070] In some implementations, a customer can assign a specific client public IP address to a specific resource instance within a VPN. A network entity on an intermediate network can then send traffic to the public IP address published by the client; the traffic can be routed by the provider network to the associated resource instance. Traffic returning from the resource instance can be routed by the provider network back to the network entity via the intermediate network. It should be noted that routing traffic between the resource instance and the network entity may require network address translation to convert between the resource entity's public IP address and private IP address. At least some implementations allow customers to remap public IP addresses in their VPN to devices on the customer's external network. When a packet is received (e.g., from a network entity), the network can determine that the destination IP address indicated by the packet has been remapped to an endpoint on the external network and process the routing of the packet to the appropriate endpoint via a dedicated communication channel, a backup communication channel, or an intermediate network. Response traffic can be routed from the endpoint to the network entity via the provider network, or alternatively, directly from the customer network to the network entity. From the network entity's perspective, it may appear as if the network entity is communicating with a client's public IP address on the provider network. However, the network entity may actually be communicating with an endpoint on the customer network.

[0071] Connection-based resource management of virtual desktop instances

[0072] In various implementations, service providers may employ one of the exemplary provider networks (or another suitable provider network environment) described above to provide hosted desktop services in a cloud computing environment. In such implementations, customers can access the provider network in the cloud computing environment to request the instantiation and / or configuration of one or more virtual desktop instances in the cloud, and can subsequently provide access to those virtual desktop instances to one or more end users (e.g., via a client application). For example, an administrator within an organization or enterprise can create an account with a service provider, contract with the service provider to create a number of virtual desktop instances, and (once the virtual desktop instances are created) provide credentials for accessing those virtual desktop instances. In this example, once the virtual desktop instances have been created and credentials have been provided, one or more end users can launch a client application on their client device (e.g., a computer, tablet, or other mobile device) and enter the credentials for the virtual desktop instance, after which they can log in to the virtual desktop environment. Although the virtual desktop environment is implemented by virtualized resource instances in the cloud computing environment, it may appear to the end user as a local desktop, and it may operate as if it were a separate computer to which the user has connected. In some implementations, a virtual desktop environment can provide access to productivity software and other software programs as if a user were logged into a physical computer owned by an organization or enterprise, where the user would typically access productivity software and other software programs.

[0073] In some implementations, these virtual desktop instances may replace desktop computers. For example, the software programs running on the virtual desktops may be the same as those accessed by members of an organization or enterprise (which instantiates and configures the virtual desktops on its behalf) on a desktop computer in an office environment (e.g., applications performing end-user productivity tasks). Note that these applications may or may not be standalone applications. For instance, in some cases, each virtual desktop instance (and / or the applications running on it) may be part of the organization or enterprise's Active Directory framework, and once the credentials presented by the user are authenticated when the user logs onto the virtual desktop instance, they may be able to access shared files or other resources on the organization or enterprise's existing network.

[0074] In some implementations of the system described herein, a compute resource instance manager (or another component on the service provider network) may implement some or all of the technologies described herein for managing the resources used to implement the virtual desktop instance, both when a client is connected to the virtual desktop instance and when no client is connected. In some implementations, these technologies may include intelligently discarding unconnected sessions (e.g., shutting down the underlying compute resource instance used for the virtual desktop instance) while maintaining the virtual desktop instance's data in a storage volume not included in the underlying compute resource instance's count. This can allow service providers to manage their resources more efficiently (e.g., if capacity is limited, or simply to avoid incurring charges for unused resources). In some implementations, the system described herein can provide customers with high availability and a good customer (and / or end-user) experience when connecting to or reconnecting to the virtual desktop instance, while allowing service providers to reclaim resources when they are not used (e.g., when a customer or end-user is not connected). As described in more detail herein, in some implementations, service providers may implement a connection-based and / or "time-period" approach to manage resources used for the virtual desktop instance, which may or may not extend to their method of billing customers for those virtual desktop instances.

[0075] In some implementations, when the service provider (or compute resource instance manager on the service provider network) detects that no user is connected to a specific virtual desktop instance, the service provider (or compute resource instance manager) may shut down the underlying compute resource instance after a certain number of inactivity minutes (based on a configurable and / or predefined threshold). As mentioned earlier, when the compute resource instance is shut down, the storage volume of the virtual desktop instance may still be maintained, but can be detached (unmounted) from the virtual desktop instance and the compute resource instance. In some implementations, if a user reconnects to the previously shut-down virtual desktop instance, the service provider (or compute resource instance manager) may start the compute resource instance and attach the appropriate storage volume (e.g., on demand).

[0076] In some implementations, the service provider (or compute resource instance manager) can track when each virtual desktop instance is "in use," meaning when a customer (e.g., an end user in the service provider's customer organization) logs in / connects (e.g., via a client) to the virtual desktop instance. The service provider (or compute resource instance manager) can measure the amount of time users are connected (e.g., the number of time periods in hours), regardless of whether they actually use resources to perform tasks, and the amount of time the virtual workspace is active but the user is not connected to the virtual desktop instance (e.g., the number of time periods in hours). In some implementations, the customer organization is charged differently for the time periods the user is connected and for the time periods the virtual workspace is active but the user is not connected to the virtual desktop instance (e.g., different amounts are charged). In some implementations, a virtual desktop instance can only be considered disconnected (and its underlying compute resource instance meets the shutdown criteria) when the connection is broken from the client. In other implementations, a virtual desktop instance can be considered effectively disconnected due to inactivity.

[0077] exist Figure 5 The flowchart illustrates one implementation of a method for managing resources of a virtual desktop instance. As shown in 510, in this example, the method may include (at the service provider's location) receiving a request from a client to connect to the virtual desktop instance (e.g., a request to log in to the virtual desktop instance) on behalf of a customer or a specific end user. As shown in 520, the method may include a service provider (e.g., resource management logic on a service provider network) providing compute and storage resources (if not already provided) to the virtual desktop instance. For example, if this is the first time a login request to the virtual desktop instance has been received, the service provider may need to provide and configure virtualized compute and / or storage resources to enable the virtual desktop instance. As shown in 530, the method may also include launching the virtual desktop instance (e.g., boots the underlying compute resources and attaches storage resources for the virtual desktop instance) and initiating a virtual desktop session on the virtual desktop instance.

[0078] As shown in the example, at a later point in time, the method may include receiving a request from a client to disconnect from the virtual desktop instance, as shown in 540. As shown in 550, the method may include the service provider shutting down (but not necessarily immediately) the computing resources used for the virtual desktop instance after the client disconnects, according to a resource management policy. For example, the resource management policy may include a standard policy specifying the shutdown of computing resources for the virtual desktop instance (e.g., specifying that they should be shut down two hours after disconnection or only between 7 p.m. and 7 a.m.). At a later point in time, the method may include receiving a request from a client to reconnect to the virtual desktop instance, as shown in 560. For example, this request may come from a client on the same machine as the previous connection request, or from a client on a different machine used by the end user to access the virtual desktop instance. In response to the reconnection request, the method may include restarting the computing resources of the virtual desktop instance and starting a new virtual desktop session on the virtual desktop instance, as shown in 570. Note that in some implementations, the operations shown in 540-570 may be repeated as additional requests to disconnect and reconnect from the virtual desktop instance are received on behalf of a client or a specific end user.

[0079] In various implementations, the service provider (or compute resource instance manager) may employ different mechanisms to determine the existence of a connection to a particular virtual desktop instance. For example, in some implementations, the service provider (or compute resource instance manager) may measure the number of bytes (or rate) of communication traffic flowing through a network interface to determine whether a user is using the virtual desktop instance. In some implementations, the streaming protocol includes a bidirectional communication channel, and the service provider may send information representing pixel output to the client device. In this example, if the user is watching a video, the pixel data may have a very high rate of change. The service provider may also obtain returned information from the client (e.g., mouse clicks and keyboard input), even if they are encrypted, which can provide statistics for determining activity or inactivity on the virtual desktop instance. In this example, the service provider (or compute resource instance manager) may look at heuristics about the total number of packets, the amount they are transmitted, etc., and may determine whether the observed traffic pattern or characteristics match known (or previously observed) patterns or characteristics of activity or inactivity on the virtual desktop instance. If it matches known (or previously observed) inactivity patterns or characteristics, the virtual desktop instance can be considered effectively disconnected, and its underlying compute resource instance may be eligible to be shut down (depending on applicable shutdown policies). In other implementations, a session gateway can be established for a virtual desktop session when it is established. For example, a session gateway component can provide tunneling for one or more virtual desktop sessions and can detect when these sessions are dropped or otherwise terminated. In some implementations, the presence or absence of active sessions on a particular virtual desktop instance (as detected by the session gateway) can provide a clear picture of whether a client is connected to the virtual desktop instance.

[0080] More specifically, in some implementations, if a user has a login session on a virtual desktop instance during the detection process, the user can be considered connected to the virtual desktop instance (e.g., having an active session on the virtual desktop instance). In some implementations, the service provider system can support multiple protocols, each using a different mechanism to detect active sessions. In one example, if the system supports the PCoIP protocol, each virtual desktop instance can include a software agent capable of streaming screen pixels from the virtual desktop instance. In this example, the agent can support two login methods: standard mode and console mode. The agent can emit session statistics once per second, one piece of information being an attribute representing the session duration in seconds. This attribute transitions from zero to a non-zero value when the session begins and from a non-zero value to zero when the PCoIP session ends. A second software agent on the virtual desktop instance can expose an API through which this information can be obtained to determine whether an active session exists on a particular virtual desktop instance. In some implementations, this API can be periodically invoked by the monitoring service, and the retrieved data can be provided to the user or client organization.

[0081] In another example, if the system supports the WebRTC protocol, each virtual desktop instance can include an agent capable of streaming screen pixels from the virtual desktop instance. This agent can create pipes to enable inter-process communication between the WebRTC agent and a second software agent. The WebRTC agent can issue messages related to the health status of the user's virtual desktop instance and active sessions on that instance. The second agent can attach to the pipes, read these messages, and respond to API calls made by a monitoring service to determine the health status of the user's virtual desktop instance and / or the presence (or absence) of active sessions.

[0082] In yet another example, if the system supports the RDP protocol, a user can log in to a virtual desktop instance from the customer's virtual private cloud. In this example, two login methods can be supported: standard mode and console mode. The agent on each virtual desktop instance can query the operating system-level audit account to detect connection (login) and disconnection (logout) attempts (events). The login type of these events can be used to distinguish between console mode and standard mode. Note that in some implementations where the service provider system supports multiple protocols (such as the three protocols described herein), the agent can act as a single point of contact for various monitoring services. In such implementations, the agent can also perform functions described as being performed by a "second software agent" in the other two protocols.

[0083] exist Figure 6The flowchart illustrates one implementation of a method for detecting that a client has disconnected from a virtual desktop instance (or has been effectively disconnected from the virtual desktop instance through inactivity). As shown at 610, in this example, the method may include the client connecting to a virtual desktop instance implemented by a service provider resource on behalf of the end user. In some implementations, the method may include a service provider agent (e.g., logic implemented on the service provider resource) initiating monitoring of the communication channel (e.g., a bidirectional communication channel) between the client and the resource implementing the virtual desktop instance, as shown at 620. As shown at 630, the method may include the agent collecting information about the number of packets sent, the packet sending rate, and / or other activity indicators and heuristics.

[0084] As illustrated in this example, if a gateway component on the service provider network detects an explicit disconnection at any time (e.g., by detecting that a virtual desktop session has ended, shown as a positive response to 640), or if at any time the agent determines that the collected packet information indicates inactivity (shown as a positive response to 650), the method may include the service provider applying one or more policies to determine whether and when to shut down the computing resources of the virtual desktop instance in response to an explicit disconnection or apparent inactivity (as shown in 660). In some implementations, the agent may monitor bidirectional streaming data and compare observed traffic patterns with known or previously observed activity or inactivity patterns to determine whether an end user is actively using the virtual desktop instance.

[0085] As illustrated in this example, until and unless any of these conditions are detected, the method may include the agent continuing to collect information about the number of packets transmitted, packet transmission rate, and / or other activity indicators and heuristics, and / or the gateway component is monitoring for explicit disconnection indications. This in Figure 6 The path is illustrated by the negative response to 640 to 650 and the negative response to 650 to 630. Note that in at least some embodiments, the gateway component and the agent on the service provider machine can operate in parallel. It should also be noted that in some embodiments, the service provider may implement either the gateway component (such as the one described herein) or an agent monitoring the communication channel, but not both simultaneously. Generally, in various embodiments, the system described herein may implement more, fewer, or different mechanisms than those described herein for detecting whether a client has disconnected from the virtual desktop instance or has been effectively disconnected from the virtual desktop instance through inactivity.

[0086] As described herein, in some implementations of the system described herein, the service provider (or compute resource instance manager) may apply certain intelligence and / or machine learning to determine whether and / or when to shut down the compute resource instance of the virtual desktop instance in response to a client disconnection. In some implementations, such a decision may depend on a time-based shutdown criterion. For example, the shutdown criterion may specify the length of time a client must disconnect from the virtual desktop instance before the underlying compute resource instance is shut down. In another example, the shutdown criterion may specify that the compute resource instance will not be shut down between 8:00 AM and 6:00 PM, even if the user disconnects from the virtual desktop instance, or it may specify a longer time threshold between disconnection and shutdown of the compute resource instance within this period.

[0087] Some implementations of the system described herein can support the use of customer-defined resource management policies, which may include customer-defined shutdown policies. This allows customers (or end users within the customer organization) to have greater control over the state of resources used to provide services to customers. For example, in some implementations, IT administrators within the service provider customer organization may be able to specify criteria for when and whether compute resource instances should be shut down in response to disconnecting from virtual desktop instances.

[0088] In some implementations, IT administrators can set shutdown preferences for virtual desktops hosted on behalf of their end users. In one example, an IT administrator might define a policy specifying that compute resources used for virtual desktop instances should be shut down two hours after an end user disconnects (e.g., because the IT administrator doesn't want to pay high fees for virtual desktop instances during periods when they are not in use). Being able to specify how long compute resource instances should continue running after disconnection allows IT administrators to give end users the option to disconnect, attend meetings in different rooms, and reconnect without having to shut down the compute resource instances in between. In another example, an IT administrator at a university who doesn't trust students to use virtual desktop instances (and the underlying compute resource instances) can exert strict control by setting a short threshold for shutting down compute resource instances after disconnection. In other implementations, IT administrators can delegate at least some control over resources to their end users. For example, an IT administrator might allow at least some end users to define shutdown policies or shutdown criteria for their own virtual desktop instances. In some implementations, resource management policies or shutdown policies can explicitly define a schedule for shutting down compute resource instances used for virtual desktop instances. For example, if end users know in advance when they will connect to and / or disconnect from a virtual desktop instance, they can define a schedule for shutting down and / or restarting the compute resource instances of the virtual desktop instance.

[0089] exist Figure 7 The flowchart illustrates one implementation of a method for determining whether and / or when to shut down compute resource instances used for virtual desktop instances by applying one or more shutdown policies. In this example, the service provider system may support shutdown criteria specified by IT administrators of the customer organization (instantiating virtual desktop instances on their behalf) and / or by end users. For example, the service provider may allow IT administrators to select or set shutdown policies for their organization and / or delegate the selection or setting of shutdown policies to individual end users (e.g., for specific virtual desktop instances implemented on their behalf). As shown in 710, in this example, the method may include the service provider (or resource management logic implemented on the service provider network) determining that a client has disconnected from the virtual desktop instance implemented by compute and storage resource instances on the service provider network.

[0090] If the end user has specified a shutdown policy (shown as an affirmative answer to 720) or if the customer organization's IT administrator has specified a shutdown policy (shown as an affirmative answer to 730), the method may include the service provider applying these policies. For example, the end user or IT administrator may have defined one or more conditions under which the underlying compute resource instance of the virtual desktop instance should be shut down after disconnection. If neither the end user nor the customer organization's IT administrator has specified a shutdown policy (shown as a negative answer to 720 and 730), the method may include the service provider applying one or more of the service provider's default shutdown policies, as shown in 740.

[0091] As illustrated in this example, if the applicable shutdown policy specifies that the virtual desktop instance should not be shut down (e.g., the compute resource instances of the virtual desktop instance should not be shut down during the contract period, or they should not be shut down in response to a client's disconnection), the method may include the service provider keeping the compute resource instances of the virtual desktop instance active. This is in Figure 7 The path from an affirmative answer to 750 to 780 is illustrated in the diagram. If the applicable shutdown criteria are met (shown as an affirmative answer to 760), the method may include shutting down the compute resource instance of the virtual desktop instance, as shown in 790.

[0092] In some implementations, if applicable shutdown criteria are not met, but the applicable shutdown criteria are time-based (e.g., if the applicable policy specifies that a virtual desktop instance's compute resource instance is shut down only after a predetermined period of time has elapsed since the client disconnects, or only at a specific time of day), the method may include waiting for the time-based criteria to be met before shutting down the compute resource instance. This is in... Figure 7The method is illustrated by a negative response to 760 and a feedback from a positive response to 770 back to 760. In this case, once the time-based criterion is met, the method may include shutting down the computing resource instance of the virtual desktop instance, as shown in 790.

[0093] On the other hand, if the applicable shutdown criteria are not met (shown as a negative answer to 760) and the applicable shutdown criteria are not time-based (shown as a negative answer to 770), the method may include the service provider keeping the compute resource instance of the virtual desktop instance active, as shown in 780. Note that in other implementations, in these types of shutdown policies, the system may not support all (e.g., it may not support a hierarchy of shutdown policies), or may support more, fewer, or different mechanisms to determine whether and / or when to shut down the compute resource instance of the virtual desktop instance.

[0094] As described herein, in some implementations, the service provider (or compute resource instance manager) can track when a user connects to and disconnects from a virtual desktop instance, and can identify usage patterns of the virtual desktop instance (new patterns, common patterns, or previously observed patterns). These patterns can then be used as input to build predictive models for shutting down and restarting compute resource instances (e.g., based on end users or across the entire client organization), with the goal of never leaving the compute resource instance used for the virtual desktop instance in a powered-off state and / or maximizing the amount of time (e.g., hours or percentage) the compute resource instance of the virtual desktop instance is running with a connection rather than without a connection when a user attempts to connect. In some implementations, information collected by the service provider (or compute resource instance manager) can also be used as input to billing mechanisms, as described herein. For example, in some implementations, both connecting to and / or disconnecting from a virtual desktop instance can trigger various types of billing events.

[0095] In one example, the service provider (or compute resource instance manager) can identify patterns in the collected data that users typically reconnect frequently throughout the workday. In this example, even if a user disconnects from the virtual desktop instance, the service provider (or compute resource instance manager) can keep the compute resource instance active (e.g., until 6:00 AM). In another example, if the service provider (or compute resource instance manager) identifies in the collected data a pattern where a user disconnects only once a day and does not reconnect for the rest of the day, then the service provider (or compute resource instance manager) can immediately shut down the compute resource instance for that virtual desktop instance when the user disconnects.

[0096] In some implementations, the service provider (or compute resource instance manager) can generate models for performing predictive (proactive) shutdowns and / or restarts based on collected data and observed usage patterns. For example, if the service provider (or compute resource instance manager) determines (e.g., by reviewing connection logs) that a particular user typically connects to a virtual desktop instance at 9:00 AM, maintains the connection until they go to lunch (at which point they disconnect), reconnects at 1:00 PM, and maintains the connection until 5:00 PM when they leave the office (at which point they disconnect), then the service provider (or compute resource instance manager) can, based on this pattern set, predictively (proactively) start this virtual desktop instance at 8:00 AM every weekday (e.g., one hour before the user arrives at the office) and shut it down at 6:00 PM every weekday. In this example, the service provider may not charge them at a connection-based rate until they actually connect (therefore, the service provider may bear the cost risk in this case), but it may provide a good user experience—fast login—making the cost risk worthwhile. In this example, the service provider (or compute resource instance manager) can automatically shut down the compute resource instance and then automatically restart it, but the user is unaware that it has been shut down (and their application has been closed), and then it is restarted for them. The user will only know that they will experience fast login every day.

[0097] In a more complex example, a user who connects to a virtual desktop instance at 10:00 AM on a particular day might be attending a meeting and might not reconnect before 3:00 PM, then might disconnect at 6:00 PM. In this example, the user's connection / disconnection pattern might change throughout the day and could be different every day. In this example, any predictive model would likely have a very low confidence interval. In other words, because the user's connection / disconnection pattern is so variable, the service provider (or compute resource instance manager) might find itself in a situation where it lacks sufficient confidence to take action. In this case, the service provider (or compute resource instance manager) could apply a default shutdown policy (e.g., waiting two hours before shutting down the compute resource instance after disconnection, or waiting until after 6:00 PM to shut down the compute resource instance), or it could apply some other low-confidence approach that allows the service provider to reclaim capacity without incurring risk. Note that in various implementations, the service provider (or compute resource instance manager) can generate and apply predictive policies about when to shut down compute resource instances, generate and apply predictive policies about when to restart compute resource instances, or both.

[0098] exist Figure 8The flowchart illustrates one implementation of a method for predictive models of establishing and disconnecting virtual desktop instances. As shown in 810, in this example, the method may include providing compute and storage resource instances for the virtual desktop instances on behalf of a service provider customer. As shown in 820, the method may include initiating monitoring and collecting data regarding connections and disconnections with the virtual desktop instances. For example, such monitoring and collection activities may be performed by logic on the service provider system.

[0099] This method may include identifying new and / or common usage patterns of virtual desktop instances from recently collected data and / or data accumulated over longer periods (e.g., many days, a week, and / or multiple virtual desktop sessions), as shown in 830. The method may also include developing or improving a predictive usage model of the virtual desktop instance based at least in part on the identified usage patterns, and developing or improving a shutdown strategy based on the predictive usage model, as shown in 840. For example, the predictive usage model may identify when a user is predicted to connect to the virtual desktop instance (and at those times, it may be advantageous if the underlying compute resource instance is already active) and / or when a user is predicted to disconnect from the virtual desktop instance (and at those times, it may be safe to shut down the underlying compute resource instance). As this example shows, while a customer is still renting a virtual desktop instance, the method may include continuously monitoring and collecting data on connection and disconnection with the virtual desktop instance (as shown in 860), and using this information to improve the predictive usage model and / or shutdown strategy (e.g., repeating the actions shown in 830-840). This in Figure 8 The feedback from 860 to 830 is shown in the middle.

[0100] In some implementations, once a customer no longer leases a virtual desktop instance (e.g., once the service contract expires, is cancelled, or modified to exclude the virtual desktop instance), the method may include the service provider releasing the service provider resources that provide the virtual desktop instance. This is in Figure 8 The diagram illustrates the progression from affirmative responses at 850 to feedback at 870. In some implementations, information about identified usage patterns and / or predicted usage models may be provided to the customer (e.g., to IT administrators and / or end users within the customer's organization).

[0101] In one implementation that employs machine learning methods to determine when and whether to shut down and / or restart a virtual desktop instance's compute resource instance, the machine learning method may be based at least in part on an adaptive function that seeks to avoid situations where the virtualized compute resource instance is shut down when a client requests a connection to the virtual desktop instance, and / or on an adaptive function that seeks to minimize the amount of time the virtualized compute resource instance is active but no client connects to it. For example, one adaptive function may specify that the virtual desktop instance's compute resource instance should always be restarted (or kept active) before an end user needs to connect to the virtual desktop instance. Another adaptive function may specify that the length of time the compute resource instance used for the virtual desktop instance is active when no user connects to the virtual desktop instance does not exceed a specific number of hours. Between these two adaptive functions, the service provider (or compute resource instance manager) wants to be able to predict when a user will connect, start the compute resource instance before that time, and then shut it down when appropriate.

[0102] As previously described, in some implementations, when the compute resource instance used for the virtual desktop instance is shut down (e.g., according to a shutdown policy), all data of the virtual desktop instance (e.g., that of applications running on the virtual desktop instance) can remain on one or more storage volumes associated with the compute resource instance for the virtual desktop instance to use, although they can be detached (unmounted) from the compute resource instance. In such implementations, when a user reconnects, the compute resource instance can be restarted and the storage volumes can be reattached (mounted) for use by the virtual desktop instance. Thus, when the user reconnects, their applications can also be restarted. In some implementations, when a user requests to reconnect to the virtual desktop instance, but the compute resource instance that previously implemented (hosted) the virtual desktop instance is shut down, a new compute resource instance (e.g., an instance of the same type as the previous compute resource instance or a different type of compute resource instance) can be started for the virtual desktop instance elsewhere, and the same storage volumes can be attached (mounted) to the new instance.

[0103] exist Figure 9The flowchart illustrates one implementation of a method for managing service provider resources for a virtual desktop instance in response to disconnection and reconnection. As shown in 910, in this example, the method may include, in response to a connection request, providing and launching a compute resource instance for the virtual desktop instance, and attaching one or more storage volumes to the compute resource instance. As shown in 920, the method may include, at a later point in time, detecting that a user has disconnected from the virtual desktop instance. In response to disconnection (and according to a shutdown policy), the method may include disconnecting and unloading the storage volumes from the compute resource instance of the virtual desktop instance, but continuing to maintain the storage volumes of the virtual desktop instance on the service provider network, as shown in 930. The method may also include shutting down the compute resource instance of the virtual desktop instance, as shown in 940.

[0104] As shown in this example, the method may include detecting, at a later point in time, that the user has reconnected to the virtual desktop instance, as shown in 950. In response to the reconnection, the method may include restarting the compute resource instance of the virtual desktop instance (as shown in 960) and reattaching and remounting the storage volume to the compute resource instance of the virtual desktop instance (as shown in 970).

[0105] In some implementations, for example, when a user requests to reconnect to a virtual desktop instance whose underlying compute resource instance has been shut down, the user may be able to specify that the virtual desktop instance is hosted on a different compute resource instance type. For example, a user can decide (and may indicate on the client side) that they want to move from a standard performance instance to a higher-performance instance (e.g., by selecting the instance type from a dropdown menu in the client GUI). In some implementations, once the newly selected compute resource instance is started and configured to host the virtual desktop instance, this can be the default instance type for the user's next reconnection after shutdown. In implementations where users are billed at a higher rate (e.g., hourly) for the period they are connected to the virtual desktop instance, if a user knows they will be performing a task requiring higher performance, they can upgrade their virtual desktop instance's compute resource instance to a higher-performance (and more expensive) instance type during that period, and then revert to the previous instance type when they no longer need the higher performance. In contrast, if users are charged monthly regardless of how long they are connected to the virtual desktop instance or whether they disconnect from it, they may want their virtual desktop instance's high-performance computing resource instance to be active throughout the month if they will (or may) need the high-performance computing resource instance at some point during the month.

[0106] In some implementations, users may be able to specify different storage capacities when they reconnect to their virtual desktop instance. For example, they might decide they need more storage than was initially allocated to their virtual desktop instance. In some implementations, if more storage is requested, in addition to reattaching previously attached (mounted) storage volumes, the service provider (or compute resource instance manager) also attaches (mounts) one or more additional storage volumes to the compute resource instance when it is restarted (or launched). In other implementations, the amount of storage provided to the virtual desktop instance may be fixed and / or may depend on the compute resource instance type.

[0107] exist Figure 10 The flowchart illustrates one implementation of a method for initializing and modifying the configuration and / or shutdown policy of a virtual desktop instance. As shown in 1010, in this example, the method may include receiving a request from a user (e.g., via a client) specifying the compute resource instance type, storage volume capacity, and shutdown policy of the virtual desktop instance (e.g., by a service provider). The method may include providing and launching a compute resource instance of the specified type for the virtual desktop instance, and attaching one or more storage volumes (e.g., sufficient to meet the specified capacity) to the compute resource instance, as shown in 1020. As shown in 1030, the method may include, at a later point in time, the service provider system detecting that the user has disconnected from the virtual desktop instance.

[0108] As shown in 1040, the method may include disconnecting and unloading the storage volume from the compute resource instance and shutting down the compute resource instance of the virtual desktop instance, according to a shutdown policy. As shown in 1050, the method may further include, at a later point in time, the service provider system receiving a request to reconnect to the virtual desktop instance. If the request specifies a different compute resource instance type or storage capacity (shown as an affirmative answer to 1060), the method may include restarting or booting the specified type of compute resource instance (as shown in 1070) and reattaching and remounting the storage volume, while increasing or decreasing capacity (if applicable) (as shown in 1075).

[0109] However, if the request does not specify a different compute resource instance type or storage capacity (shown as a negative answer to 1060), the method may include restarting the compute resource instance of the virtual desktop instance (as shown in 1080) and reattaching and remounting the storage volume to the compute resource instance (as shown in 1085).

[0110] In various implementations, service providers can strike a tradeoff between the expenses associated with keeping compute resource instances active when they are not in use and providing a good customer experience (e.g., fast connection on every login), particularly when operating under connection-based or time-based billing models, where they do not charge (or charge very little) when resources are not in use (e.g., when no users are connected to the virtual desktop instance). When operating under this type of billing model, with reduced charges to customers, service providers may need to manage their resources to reduce their costs (in a similar proportion). In some implementations, this can be facilitated by shutting down the compute resource instances of unconnected virtual desktop instances so that these resources can be used for other purposes (e.g., for other virtual desktop instances).

[0111] In various implementations, customers or end users can also strike a trade-off between the cost they incur for their virtual desktop instances and the performance they experience when reconnecting to their virtual desktop instances (e.g., the time required to reconnect / log in could be orders of magnitude longer if the compute resource instance is shut down).

[0112] In some implementations, the service provider (or compute resource instance manager) can bear the cost if it decides when to keep compute resource instances running (e.g., using a default or predictive model). However, if IT administrators or end users within a customer organization make these choices (by defining resource management policies that include shutdown criteria), customers can be charged for all the time the compute resource instance remains active, even after disconnection (e.g., at the connection rate). For example, if a customer defines shutdown criteria specifying that a compute resource instance should not be shut down within two hours of disconnection, the customer may have to pay at the connection rate for the additional two hours after disconnection. In some implementations, the system can implement a hybrid approach where there can be several default policies defined by the service provider and / or the customer organization's IT administrator, but these default policies can be overridden in certain situations (e.g., by users connected for longer periods or users who have obtained permission from the IT administrator to apply different policies).

[0113] In some existing systems that provide virtual desktop instances to customer organizations and their end users, customers are billed monthly as long as the virtual desktop instance is active, regardless of whether end users connect to the virtual desktop instance, how frequently they connect, and / or how long they connect. For example, if a customer creates a virtual desktop instance on the 20th of a month, they will be charged pro rata for the remainder of that month (e.g., from the 20th to the 30th). However, if they have a virtual desktop instance on the 1st of a month, they may still be charged for the entire month's worth of that virtual desktop instance even if they delete it on the 2nd of that month. As previously mentioned, in some implementations, the system described herein can alternatively employ a time-based approach to resource management and / or billing of virtual desktop instances, which can be combined with a connection-based approach for both resource management and billing. For example, in one implementation, customers are billed hourly for virtual desktop instances hosted on their behalf by their end users.

[0114] In one example, under such a combined billing model, customers can be charged for virtual desktop instances based on two different dimensions:

[0115] (1) The number of hours they actually use the virtual desktop instance (or more precisely, the number of one-hour time slots, within which the end user is connected to the virtual desktop instance for any part of the one-hour time slot). Service providers (or compute resource instance managers) can track how long end users use the virtual desktop instance and can provide this information to the billing mechanism as the amount of time (or number of time slots) that should be charged to the customer at the connection rate.

[0116] (2) The number of hours a customer is running but not using a virtual desktop instance (or more specifically, the number of one-hour periods in which no end-user connects to the virtual desktop instance during any part of an one-hour period). Service providers (or compute resource instance managers) can track how long end-users are not using virtual desktop instances and can provide this information to the billing mechanism as the amount of time (or number of periods) that should be charged to the customer at the non-connection rate.

[0117] Please note that the disconnected rate may be significantly lower than the connected rate and may essentially be the cost of maintaining the virtual desktop instance and associated storage volume on behalf of the customer. For example, in one implementation, the connected rate may be a few cents (or tens of cents) per hour, while the disconnected rate may be a fraction of a cent per hour. In some implementations, and for some customers and workloads, the combined cost charged to the customer for the time billed at the connected rate and the time billed at the disconnected rate may be significantly lower than what they would pay under a monthly billing scheme. In some implementations, customers may be able to specify that they do not require the service provider to maintain the storage volume associated with the virtual desktop instance after disconnection from the virtual desktop instance (e.g., if they do not intend to reconnect to the virtual desktop instance after a particular virtual desktop session, if they only intend to use the virtual desktop instance and its resources during a single virtual desktop session, or if their use of the virtual desktop instance does not depend on maintaining any history or state of the virtual desktop instance between virtual desktop sessions). In such implementations, the service provider may disconnect the storage volume associated with the virtual desktop instance upon detecting inactivity or explicit disconnection and may reallocate it for other purposes (e.g., after deleting any information specific to the virtual desktop instance). In such an implementation, when no user is connected to the virtual desktop instance, the service provider can charge customers a different rate than the standard non-connection rate (e.g., a lower rate) for the virtual desktop instance because the service provider does not have to maintain the storage volume for that particular virtual desktop instance.

[0118] In some implementations, the service provider system can employ a time-based approach to manage and / or bill virtual desktop instances. This approach can be combined with a connection-based approach for resource management and billing across time periods other than hourly time periods. For example, in different implementations, this approach can be applied to time periods of one minute, one day, one week, one month, or any other predefined time period.

[0119] As previously mentioned, in some implementations, the system described herein may be able to detect inactivity of virtual desktop instances and apply shutdown policies as if the virtual desktop instance were effectively disconnected. For example, if a user leaves their laptop and remains connected to their virtual computing instance throughout the weekend (e.g., when they are not using it), the most customer-friendly thing for the service provider to do might be to disconnect the virtual desktop instance and / or shut down the underlying computing resource instance (according to predefined shutdown criteria), rather than charging the customer a connection rate.

[0120] In some implementations, the service provider (or compute resource instance manager) can determine when an end user streams something from an entity other than the actual virtual desktop instance client to the virtual desktop instance. For example, in response to an end user reporting a problem with their virtual desktop instance, an IT administrator can connect to the virtual desktop instance from a streaming solution, such as the Remote Desktop Protocol (RDP) developed by Microsoft, for troubleshooting. In some implementations, components of the virtual desktop instance may be able to identify when such a session is active, and the service provider can bill for that time, even if the monitoring mechanisms described above may not have detected the activity. In some implementations, if an IT administrator needs to troubleshoot a virtual desktop instance, they may be able to request that the compute resource instance remain active (at least temporarily), regardless of whether any shutdown policies apply.

[0121] Note that in some implementations, the concepts described herein for implementing connection-based resource management for virtual desktop instances can be applied to systems where compute resource instances are pooled. For example, in different implementations, they can be applied within each of multiple resource pools (e.g., customer-specific resource pools) or within a large resource pool managed on the service provider side.

[0122] Management of virtual desktop instance pools

[0123] In service provider systems that offer virtualized computing resources to clients, as referenced above... Figures 1 to 4 The virtual desktop service discussed here can provide virtual desktop instances to clients. The virtual desktop service can reserve a pool of virtual desktop instances for a specific client. Instances pooled together can be provided along with other types of virtual desktop instances, as referenced above. Figures 5 to 10 Examples discussed include those offered to any customer on demand and charged on an hourly rate.

[0124] Figure 11 This is a block diagram illustrating an example provider network offering virtual desktop services with a pool of virtual desktop instances to client organizations, according to at least some implementation schemes. (See above reference.) Figures 1 to 4 The provider network 1100 discussed herein can provide access to resources, including virtualized computing resources, to one or more clients. The provider network 1100 may include a virtual desktop service 1120. The virtual desktop service 1120 can provide clients with access to virtual desktop instances, as described above, for example, in the reference section. Figure 3 The subject of discussion. For example... Figure 11As shown in the example, Virtual Desktop Service 1120 can instantiate and manage multiple virtual desktop instances on behalf of a client, such as instances 1130A and 1130B, and instances 1130Q and 1130R through 1130Z. For a specific client organization, a set of virtual desktop instances can be reserved in Virtual Desktop Instance Pool 1131.

[0125] A client organization can refer to a customer of a provider network that is allowed access to one or more services and / or resources (e.g., access to virtualized computing resources). A client organization can represent a commercial organization, government organization, non-profit organization, educational organization, or any other suitable individual organization. A client organization can include end users (also referred to herein as users) who are allowed access to the services and / or resources of provider network 1100. End users can access provider network 1100 using client devices such as devices 1160A and 1160B to 1160N to 1160Z. Client devices 1160A-1160Z can be user-specific or can be shared among multiple users, for example, by using user-specific access credentials. Client devices 1160A-1160Z can be linked in one or more client networks 1150. Client network 1150 can be communicatively coupled to the virtual desktop service 1120 of provider network 1100. Any of client devices 1160A-1160Z can be used... Figure 18 The example computing device shown is used for implementation.

[0126] Virtual desktop instance pool 1130 may have a limited number of slots, such as slots 1 and 2 through N. A client organization may submit or agree to the number N of slots, for example, using any suitable programming and / or user interface of provider network 1100. A client organization may agree to pay provider network 1100 for a number of N virtual desktop slots for a specific period. For example, a client organization may agree to pay the provider network for one hundred virtual desktop slots per month (and this may repeat monthly until either party cancels or modifies). The number N of virtual desktop slots may represent a fixed or predetermined number of virtual desktop slots that the provider network agrees to provide for substantially all of the duration of the agreement. Each virtual desktop slot may represent a virtual desktop instance connected to a client device in the client organization (e.g., a connected virtual desktop instance), a disconnected but still running virtual desktop instance (e.g., a disconnected virtual desktop instance, also referred to herein as an unused virtual desktop instance), or an empty slot (e.g., no virtual desktop instance is running, whether connected or disconnected). A client organization may pay for all slots, regardless of which slots are used or the frequency with which any slot is used. Typically, the number of end users within a client organization (e.g., users with access to virtual desktop slots) may exceed the number of virtual desktop slots, N. Different end users within the client organization can use specific slots at different times.

[0127] A pool 1131 can be reserved for virtual desktop instances for client organizations. Pool 1131 may include virtual desktop instances running and connected to users within the client organization, such as instances 1130A and 1130B. As will be discussed below, pool 1131 may also include virtual desktop instances that are running but not connected to users. Figure 11 As illustrated in the example, one or more slots in the pool can be empty (i.e., not filled with running virtual desktop instances), such as slot N. A reserved instance pool typically includes a period of time reserved for client organizations to access the instance, during which other clients are denied access to the instance. The number of instances in pool 1131 must not exceed the number of virtual desktop slots N for the client organization. In one implementation, instance pool 1131 may include all (or nearly all) running instances in all N slots for substantially all of the time following the initialization phase. In one implementation, pool 1131 may be initialized with all N slots empty, and running instances may be added to the pool when a connection request is received or anticipated. Slots in pool 1131 with disconnected instances can be reclaimed, for example, by restarting the instance or replacing it with a new running instance ready to accept new connections.

[0128] In one implementation, instances are made available to client devices only when a connection request is received from the client device. Disconnected instances or the computing resources used to implement them can be returned to a set of available instances and / or resources outside of pool 1131. For example, instances 1130Q-1130Z could represent a larger set of instances available to multiple client organizations, and instances 1130A-1130B could be reserved from this larger set of instances in response to connection requests from client devices 1160A and 1160B belonging to client organizations associated with pool 1131. In this way, a set of underlying resources in provider network 1100 can be shared among multiple virtual desktop instance pools for the same or multiple clients.

[0129] A virtual desktop instance can be implemented on behalf of a given end user. Service provider network 1100 may include multiple compute nodes (e.g., such as...) that collectively provide virtual desktop services to one or more client organizations or other users within the provider network. Figure 18 (The computing device shown). Provider network 1100 can implement virtualized computing resource instances that run on one of the computing nodes, and these virtualized computing resource instances can implement virtual desktop instances, as referenced above. Figures 1 to 4 The discussion focuses on one or more applications that can be installed on a virtual desktop instance and executed using a virtualized computing resource instance. A virtual desktop service can maintain a virtual desktop, for example, by maintaining data such as configuration data and application data that can be used to generate a graphical user interface (GUI) for the virtual desktop instance and run applications. A virtual desktop may include a graphical representation of a set of resources associated with the virtual desktop instance (e.g., graphical indicators for one or more applications, one or more windows associated with an application, one or more interface elements for browsing files or folders, or one or more interface elements for browsing available applications or switching between running applications, etc.). Figure 11 As shown in the example, client device 1160A can access virtual desktop 1135A via virtual desktop instance 1130A, and client device 1160B can access virtual desktop 1135B via virtual desktop instance 1130B. Virtual desktops 1135A and 1135B can be configured in a similar manner (e.g., configured with the same set of applications) or in a different manner (e.g., configured with different sets of applications). Each virtual desktop instance 1130A and 1130B can include a corresponding root drive and a corresponding user-specific data drive for the respective client device.

[0130] Figure 12This is a block diagram illustrating a further aspect of an example provider network offering virtual desktop services with a pool of virtual desktop instances, according to at least some embodiments, wherein the virtual desktop instance pool includes connected and disconnected virtual desktop instances in different slots within the pool. As described above, pool 1131 may include virtual desktop instances running and connected to users within a client organization, such as instances 1130A and 1130N. A connection to an instance can be performed in response to a connection request from a client device associated with a user of the client organization. For example, in Figure 11 The state shown is the same as Figure 12 Between the states shown, virtual desktop service 1120 can receive connection requests from client device 1160N and respond by providing access to virtual desktop instance 1130N in slot N. Therefore, client device 1160A can access virtual desktop 1135A via virtual desktop instance 1130A, and client device 1160N can access virtual desktop 1135N via virtual desktop instance 1130N.

[0131] Pool 1131 may also include virtual desktop instances that are running but not connected to users, such as instance 1130B. Figure 11 The state shown and Figure 12 Between the states shown, client device 1160B can disconnect from its previously connected virtual desktop instance 1130B. This is in response to an explicit disconnection request from the client device or based on automatic detection of a disconnection (e.g., as referenced above). Figures 5 to 10 As discussed, disconnection from the instance can be performed. The disconnected instance 1130B can remain running and may occupy a slot (e.g., slot 2) in pool 1131. In one implementation, the disconnected instance 1130B can remain running with the attached data drive associated with the user of the previously connected client device 1160B. By keeping instance 1130B running (e.g., while an application is running) and attached with a user-specific data drive, the connection between client device 1160B and instance 1130B can be restored more quickly (e.g., without restarting or re-serveing ​​the virtual desktop instance) when a connection request is received from the user of client device 1160B.

[0132] Figure 13 This is a block diagram illustrating a further aspect of an example provider network offering virtual desktop services with a pool of virtual desktop instances, according to at least some embodiments, including providing client devices with access to virtual desktop instances outside the pool when all slots in the pool are already occupied by connected instances. In some cases, all slots 1-N in pool 1131 may be consumed by connected instances. Figure 13As shown in the example, all slots in pool 1131 can be used by virtual desktop instances 1130A-1130N running and connected to the corresponding client devices 1160A-1160N. However, a client organization may include more users than the number of slots N in pool 1131. If a new connection request is received from a client device in the client organization, and all N slots in pool 1131 are fully occupied by connected instances, the user may be denied access to the virtual desktop instances in the pool. The user may be notified that there is no available capacity in pool 1131. In one implementation, access to pool 1131 may be denied only at the current point in time, and the user may be placed in a list of waiting instances in the pool and notified accordingly.

[0133] In one implementation, the size of pool 1131 can be dynamically increased in response to new connection requests when the pool is full of connected instances. This dynamic modification of the pool size can only be performed if the client organization agrees to pay any additional or increased fees charged by provider network 1100. In one implementation, as... Figure 13 As shown in the example, a user may alternatively be allowed access to a virtual desktop instance 1130Z outside of pool 1131, and client device 1160Z may access virtual desktop 1135Z via virtual desktop instance 1130Z. For example, a user may be allowed access to virtual desktop instance 1130Z, which is available on demand and charged by the hour (e.g., see reference above). Figures 5 to 10 Access to the virtual desktop instance under discussion is permitted only if the client organization agrees to pay the appropriate fees charged by the provider network 1100.

[0134] Figure 14 This is a block diagram illustrating other aspects of an example provider network offering virtual desktop services with a pool of virtual desktop instances, according to at least some implementation schemes, including the recycling of disconnected virtual desktop instances in the pool. (As...) Figure 14 As shown in the example, client devices 1160A and 1160B can disconnect from instances 1130A and 1130B respectively, while client device 1160N can remain connected to virtual desktop instance 1130N. Virtual desktop service 1120 may include functionality 1170 for virtual desktop instance reclamation. By using functionality 1170 for virtual desktop instance reclamation, virtual desktop service 1120 can reclaim slots in pool 1131 occupied by disconnected but running instances.

[0135] In one implementation, the virtual desktop instance recycling function 1170 can determine, at an appropriate time point, the expected rate at which the virtual desktop slot is consumed by connected instances. The expected rate can represent the growth rate of connected instances or the rate at which pool 1131 is filled by connected instances. The expected rate can be (at least in part) based on reconnection requests to running instances and new connection requests to new instances. Based on the expected rate, the virtual desktop instance recycling function 1170 can determine whether the slot is approaching full utilization by connected instances. Such determination can be based on any suitable heuristic or threshold. For example, the virtual desktop instance recycling function 1170 can determine that the pool will fill up within one hour based on the rate of new connection requests. If so, the virtual desktop instance recycling function 1170 can select disconnected instances (if any) for recycling. Recycling can also be performed under other suitable circumstances and strategies, such as when the pool is full of connected instances, a list of waiting new connections already exists, and one of the existing instances is disconnected.

[0136] One or more disconnected instances 1130A and 1130B can be reclaimed. Reclaiming a virtual desktop instance (or the slot it occupies) may include restarting the instance using a new root drive or replacing it with a new instance that has undergone any relevant security procedures and is ready for a new connection. Any suitable reclamation strategy or criterion can be applied to select one or more disconnected instances for reclamation. In one implementation, disconnected instances to be reclaimed may be selected based on the duration of instance inactivity, for example, prioritizing the most recently disconnected instance. In one implementation, disconnected instances to be reclaimed may be selected based on the expected instance restart duration, for example, prioritizing the disconnected instance that will take the longest to restart. In one implementation, disconnected instances to be reclaimed may be selected based on the relative ranking of users or other characteristics, for example, prioritizing the retention of disconnected instances for a specific user. In one implementation, one or more instances within pool 1131 may be retained indefinitely for access by one or more specific users within a client organization or for users with specific characteristics; these instances may remain running regardless of whether the corresponding user is currently connected and may not be reclaimed.

[0137] Figure 15 This is a block diagram illustrating a further aspect of an example provider network offering virtual desktop services with a pool of virtual desktop instances, according to at least some implementations, including providing client devices with access to restarted virtual desktop instances in the pool. Figure 14 The state shown and Figure 15Between the states shown, the virtual desktop instance reclamation function 1170 can restart virtual desktop instances 1130A and 1130B. The restarted instances 1130A and 1130B can then be ready for new connection requests. A ready instance can represent a running virtual desktop instance that has undergone any security procedures and is ready to accept new connection requests from users. For example, a ready instance might represent a reclaimed instance that has been restarted with a new root drive for security purposes. However, a ready instance may not be attached to a user-specific data drive but may have been joined to the appropriate domain. When a new connection request is received from client device 1160C, access to the restarted virtual desktop instance 1130B can be provided to the client device to enable virtual desktop 1135C. Providing client device 1160C with access to instance 1130B may include attaching a user-specific data drive to that instance. Another restarted instance 1130A can remain available in pool 1131, for example, until a new connection request is received.

[0138] Figure 16 This is a flowchart illustrating one implementation of a method for managing a pool of virtual desktop instances. As shown in 1610, the number of virtual desktop slots for a client organization can be determined (i.e., the defined number). A client organization can represent a customer of a provider network who is allowed access to one or more services and / or resources (e.g., access to virtualized computing resources). A client organization can represent a commercial organization, a government organization, a non-profit organization, an educational organization, or any other suitable individual organization. A client organization can include end users who are allowed access to services and / or resources. End users can use client devices to access the provider network. Client devices can be user-specific or can be shared among multiple users, for example, by using user-specific access credentials.

[0139] The client organization may submit or agree on the number of slots, for example, using any suitable programming and / or user interface of the provider network. The client organization may agree to pay the provider network for a certain number of virtual desktop slots for a specific period of time. For example, the client organization may agree to pay the provider network for one hundred virtual desktop slots per month (and this may repeat monthly until either party cancels or modifies). The number of virtual desktop slots may represent a fixed or predetermined number of slots for virtual desktops that the provider network agrees to provide for substantially all time during the duration of the agreement. Each virtual desktop slot may represent a virtual desktop instance connected to a client device within the client organization (e.g., a connected virtual desktop instance), a disconnected but still running virtual desktop instance (e.g., a disconnected virtual desktop instance), or an empty slot (e.g., no virtual desktop instance is running, whether connected or disconnected). The client organization may pay for all slots, regardless of which slots are used or how frequently any slot is used. Typically, the number of end users within the client organization (e.g., users authorized to access virtual desktop slots) may exceed the number of virtual desktop slots. Different end users within the client organization may use specific slots at different times.

[0140] As shown in 1620, a pool of virtual desktop instances can be reserved for a client organization. The instance pool can contain virtual desktop instances that are running and connected to users within the client organization, as well as virtual desktop instances that are running but not connected to users. The reserved instance pool typically includes denying access to instances to other clients for the period reserved for the client organization. The number of instances in the pool must not exceed the number of virtual desktop slots in the client organization. In one implementation, the instance pool may include all (or nearly all) running instances in all slots for substantially all time after the initialization phase. In one implementation, the pool may be initialized with all slots empty, and running instances may be added to the pool when a connection request is received or anticipated. Slots in the pool with disconnected instances can be reclaimed, for example, by restarting the instance or replacing it with a new running instance ready to accept new connections. Virtual desktop instances can be implemented on behalf of a given end user.

[0141] A service provider network may include multiple computing nodes (e.g., such as...) that jointly provide virtual desktop services to one or more client organizations or other users within the provider network. Figure 18 (The computing device shown). The provider network can implement virtualized computing resource instances that run on one of the computing nodes, and these virtualized computing resource instances can implement virtual desktop instances, as referenced above. Figures 1 to 4The discussion focuses on one or more applications that can be installed on a virtual desktop instance and executed using a virtualized computing resource instance. A virtual desktop service can maintain a virtual desktop, for example, by maintaining data such as configuration data and application data that can be used to generate a graphical user interface (GUI) and run applications for the virtual desktop instance. A virtual desktop is a graphical representation of a set of resources associated with a virtual desktop instance (e.g., graphical indicators for one or more applications, one or more windows associated with an application, one or more interface elements for browsing files or folders, or one or more interface elements for browsing available applications or switching between running applications, etc.), and the associated applications can be collectively referred to as a virtual desktop.

[0142] As shown in 1630, connection requests for virtual desktop instances in the pool can be received. Connection requests can be received from client devices associated with end users of the client organization. Connection requests can be received by the provider network's virtual desktop service via a network connection to the client organization. Connection requests can be received using any suitable programming interface and / or user interface, and may include access credentials for the client organization's users.

[0143] As shown in 1640, it can be determined whether the connected instances at the current time have consumed all slots. If so, then as shown in 1680, the user may be denied access to virtual desktop instances in the pool. The user can be notified that there is no available capacity in the pool. In one implementation, access to the pool can be denied only at the current point in time, and the user can be placed in a list of waiting instances in the pool and notified accordingly. In one implementation, the user can alternatively be allowed access to virtual desktop instances outside the pool. For example, the user can be allowed access to virtual desktop instances that are available on demand and charged by the hour (e.g., referenced above). Figures 5 to 10 Access to the virtual desktop instance under discussion is permitted only if the client organization agrees to pay the appropriate fees charged by the provider network.

[0144] If not all slots are occupied by connected instances, then, as shown in 1650, it can be determined whether the virtual desktop instances in the pool are ready for use by users. A ready instance can represent a running virtual desktop instance that has undergone any security procedures and is ready to accept new connection requests from users. For example, a ready instance might represent a reclaimed instance that has been restarted with a new root drive for security purposes. However, a ready instance may not be attached to a user-specific data drive but may have been joined to the appropriate domain. As shown in 1660, if no instances are ready in the pool, a virtual desktop instance can be provided in one of the slots. (See above reference) Figure 5Providing virtual desktop instances is discussed, which generally includes reserving and configuring resources within the provider's network. In one implementation, providing a virtual desktop instance may include booting the instance with a new root drive. Similarly, the prepared instance may not have a user-specific data drive attached, but may have been joined to the appropriate domain. As shown in 1670, a virtual desktop instance can be prepared for a user, and the user can be given access to that instance. Preparing an instance for a user may include attaching a data drive associated with the user to the instance.

[0145] Figure 17 This is a flowchart illustrating one implementation of a method for reclaiming disconnected virtual desktop instances in a pool. As shown in 1710, a pool of virtual desktop instances can be provided, and access to the pool can be offered to client organizations. The instance pool can contain virtual desktop instances that are running and connected to users within the client organization, as well as virtual desktop instances that are running but not connected to users. The number of instances in the pool must not exceed the number of virtual desktop slots in the client organization. The client organization can submit or agree to the number of slots, for example, using any suitable programming interface and / or user interface of the provider network. The client organization can agree to pay the provider network for a certain number of virtual desktop slots for a specific period of time. For example, the client organization may agree to pay the provider network for one hundred virtual desktop slots per month (and this may repeat monthly until either party cancels or modifies). The number of virtual desktop slots can represent a fixed or predetermined number of virtual desktop slots that the provider network agrees to provide for substantially all of the duration of the agreement. The client organization can pay for all slots, regardless of which slots are used or how frequently any slot is used. Typically, the number of end users within the client organization (e.g., users with access to virtual desktop slots) may exceed the number of virtual desktop slots. Different end users within a client organization can use specific slots at different times.

[0146] Each virtual desktop slot can represent a virtual desktop instance connected to a client device in the client organization (e.g., a connected virtual desktop instance), a disconnected but still running virtual desktop instance (e.g., a disconnected virtual desktop instance), or an empty slot (e.g., no virtual desktop instance is running, whether the slot is connected or disconnected). In one implementation, the instance pool can include all (or nearly all) running instances in all slots for substantially all time after the initialization phase. In one implementation, the pool can be initialized with all slots empty, and running instances can be added to the pool when a connection request is received or anticipated. Slots in the pool with disconnected instances can be reclaimed, for example, by restarting the instance or replacing it with a new running instance ready to accept new connections.

[0147] As shown in 1720, a given client device can connect to or disconnect from one of the virtual desktop instances in the pool. A connection to an instance can be made in response to a connection request from a client device associated with a user of the client organization. A disconnection request can be made in response to an explicit disconnection request from a client device or based on automatically detected disconnection (e.g., as referenced above). Figures 5 to 10 (As discussed), disconnection from instances can be performed. Connecting or disconnecting may change the composition of the pool, namely the number of connected instances, disconnected (but running) instances, and empty slots.

[0148] As shown in 1730, the expected rate at which connected instances consume virtual desktop slots can be determined. The expected rate can represent the speed at which the pool is filled by connected instances. As shown in 1740, it can be determined based on the expected rate whether the slot is approaching full utilization by connected instances. The determination shown in 1740 can be based on any suitable heuristic or threshold. For example, it can be determined that the pool will fill within an hour based on the rate of new connection requests. If so, as shown in 1750, it can be determined whether any disconnected (also known as unused) instances exist in the pool.

[0149] If so, as shown in 1760, one or more disconnected instances can be reclaimed. Reclaiming a virtual desktop instance (or the slot it occupies) may include restarting the instance using a new root drive or replacing it with a new instance that has undergone any relevant security procedures and is ready for new connections. Any suitable reclamation strategy or criterion can be applied to select one or more disconnected instances for reclamation. In one implementation, disconnected instances to be reclaimed may be selected based on the duration of instance inactivity, for example, prioritizing the most recently disconnected instance. In one implementation, disconnected instances to be reclaimed may be selected based on the expected instance restart duration, for example, prioritizing the disconnected instance that will take the longest to restart. In one implementation, disconnected instances to be reclaimed may be selected based on the relative ranking of users, for example, prioritizing the retention of disconnected instances for users with higher rankings.

[0150] Furthermore, the embodiments disclosed herein may be described in light of the following provisions:

[0151] 1. A system comprising:

[0152] Multiple computing nodes in a provider network collectively provide virtual desktop services to a client organization, wherein each computing node includes at least one processor and memory, and wherein the client organization includes multiple users;

[0153] The virtual desktop service is configured as follows:

[0154] A fixed number of virtual desktop slots is determined for the client organization, wherein the fixed number of virtual desktop slots is less than the number of users in the client organization;

[0155] Multiple virtual desktop instances are provided in the pool, wherein the virtual desktop instances are implemented using the resources of the provider network, and wherein the number of virtual desktop instances in the pool does not exceed the fixed number of virtual desktop slots;

[0156] Receive a first connection request from a first client device associated with a first user among the users;

[0157] At least in part, based on the determination that the current number of connected virtual desktop instances in the pool at the time of the first connection request is less than the fixed number of virtual desktop slots, the first client device is provided with access to a specific virtual desktop instance in the pool;

[0158] Receive a second connection request from a second client device associated with the second user among the users; and

[0159] The second client device is denied access to the plurality of virtual desktop instances in the pool, at least in part, based on the determination that the current number of connected virtual desktop instances in the pool at the time of the second connection request is consistent with the fixed number of virtual desktop slots.

[0160] 2. The system according to Clause 1, wherein the virtual desktop service is further configured to:

[0161] Determine the expected rate at which the fixed number of virtual desktop slots are consumed by multiple connected virtual desktop instances; and

[0162] Based at least in part on the expected rate, one or more disconnected virtual desktop instances in the pool are recycled, wherein one or more recycled virtual desktop instances are available for new connection requests.

[0163] 3. The system according to Clause 1, wherein the virtual desktop service is further configured to:

[0164] At least in part, based on the determination that the current number of connected virtual desktop instances in the pool at the second time point is consistent with the fixed number of virtual desktop slots, the second client device is provided with access to a second virtual desktop instance outside the pool.

[0165] 4. A method comprising:

[0166] The virtual desktop service is implemented by one or more computing devices jointly provided by the provider network:

[0167] Multiple virtual desktop instances are reserved in a pool for a client organization, wherein the virtual desktop instances are implemented using resources of the provider network, wherein the number of virtual desktop instances in the pool does not exceed the number of virtual desktop slots of the client organization, wherein the client organization includes multiple users;

[0168] Based at least in part on determining that the current number of connected virtual desktop instances in the pool at a first time point is less than the number of virtual desktop slots, access to a specific virtual desktop instance in the pool is provided to a first client device associated with a first user among the users; and

[0169] Access to the plurality of virtual desktop instances in the pool by a second client device associated with a second user is denied, at least in part, based on the determination that the current number of connected virtual desktop instances in the pool at a second point in time is consistent with the number of virtual desktop slots.

[0170] 5. The method described in Clause 4 further includes:

[0171] Determine the expected rate at which the number of virtual desktop slots are consumed by multiple connected virtual desktop instances; and

[0172] Based at least in part on the expected rate, one or more unused virtual desktop instances in the pool are reclaimed, wherein one or more reclaimed virtual desktop instances are available for new connection requests.

[0173] 6. The method described in Clause 5 further includes:

[0174] The selection of one or more unused virtual desktop instances to be reclaimed is based at least in part on the idle duration.

[0175] 7. The method described in Clause 5 further includes:

[0176] The selection of one or more unused virtual desktop instances to be reclaimed is based at least in part on the expected restart duration.

[0177] 8. The method described in Clause 5 further includes:

[0178] The selection of one or more unused virtual desktop instances to be reclaimed is based at least in part on user characteristics.

[0179] 9. The method described in Clause 4 further includes:

[0180] At least in part, based on the determination that the current number of connected virtual desktop instances in the pool at the second time point matches the number of virtual desktop slots, the second client device is provided with access to a second virtual desktop instance outside the pool.

[0181] 10. The method according to Clause 4, wherein the specific virtual desktop instance is launched using the root storage volume before receiving a connection request from the first client device, and wherein the method further comprises:

[0182] Receive the connection request from the first client device; and

[0183] A data volume associated with the first user is added to the specific virtual desktop instance, wherein the data volume is added at least in part based on the connection request from the first client device.

[0184] 11. The method described in Clause 4 further includes:

[0185] It is determined that the first user has disconnected from the specific virtual desktop instance; and

[0186] Reclaiming the specific virtual desktop instance includes:

[0187] Separate the root volume and data volume from the specific virtual desktop instance; and

[0188] Restart the specific virtual desktop instance using the new root volume.

[0189] 12. The method described in Clause 4 further includes:

[0190] Another virtual desktop instance in the pool is designated as a reserved instance for a specific user among the users of the client organization, wherein the reserved instance is not reclaimed if it is disconnected from the client device associated with the specific user among the users.

[0191] 13. The method described in Clause 4 further includes:

[0192] Determine that the specific virtual desktop instance is disconnected from the first client device; and

[0193] Return the specific virtual desktop instance to a set of available instances, wherein the set of available instances is accessible to the client organization and one or more other client organizations.

[0194] 14. A computer-readable storage medium storing program instructions, said program instructions being computer-executable to perform:

[0195] Multiple virtual desktop instances are provided in a pool for a client organization, wherein the virtual desktop instances are implemented using the resources of the provider network, wherein the number of virtual desktop instances in the pool does not exceed the number of virtual desktop slots in the client organization, wherein the client organization includes multiple users, and wherein the number of virtual desktop slots is less than the number of users in the client organization;

[0196] Based at least in part on determining that the current number of connected virtual desktop instances in the pool at a first time point is less than the number of virtual desktop slots, access to a specific virtual desktop instance in the pool is provided to a first client device associated with a first user among the users; and

[0197] Access to the plurality of virtual desktop instances in the pool by a second client device associated with a second user is denied, at least in part, based on the determination that the current number of connected virtual desktop instances in the pool at a second point in time is consistent with the number of virtual desktop slots.

[0198] 15. The computer-readable storage medium according to Clause 14, wherein the program instructions are also executable by a computer to perform:

[0199] Determine the expected rate at which the number of virtual desktop slots are consumed by multiple connected virtual desktop instances; and

[0200] Based at least in part on the expected rate, one or more disconnected virtual desktop instances in the pool are recycled, wherein one or more recycled virtual desktop instances are available for new connection requests.

[0201] 16. The computer-readable storage medium according to Clause 15, wherein the program instructions are also executable by a computer to perform:

[0202] The selection of one or more disconnected virtual desktop instances to be reclaimed is based at least in part on the idle duration.

[0203] 17. The computer-readable storage medium according to Clause 15, wherein the program instructions are also executable by a computer to perform:

[0204] The selection of one or more disconnected virtual desktop instances to be reclaimed is based at least in part on the expected restart duration.

[0205] 18. The computer-readable storage medium according to Clause 15, wherein the program instructions are also executable by a computer to perform:

[0206] The selection of one or more disconnected virtual desktop instances to be reclaimed is based at least in part on user characteristics.

[0207] 19. The computer-readable storage medium according to Clause 14, wherein the program instructions are also executable by a computer to perform:

[0208] At least in part, based on the determination that the current number of connected virtual desktop instances in the pool at the second time point matches the number of virtual desktop slots, the second client device is provided with access to a second virtual desktop instance outside the pool.

[0209] 20. The computer-readable storage medium according to Clause 14, wherein the particular virtual desktop instance is launched using a root storage volume before a connection request is received from the first client device, and wherein the program instructions are also executable by a computer to perform:

[0210] Receive the connection request from the first client device; and

[0211] A data volume associated with the first user is added to the specific virtual desktop instance, wherein the data volume is added at least in part based on the connection request from the first client device.

[0212] Explanatory System

[0213] In at least some implementations, a server implementing some or all of the technologies described herein for managing virtual desktop instance pools may include a computer system that includes or is configured to access non-transitory computer-accessible (e.g., computer-readable) media, such as... Figure 18The computer system 2000 is illustrated. For example, in various embodiments, any or all of the computer system components described herein (including, for example, data center computers and / or other components on a service provider network that collectively provide virtual computing services and / or virtual storage services, virtualized computing resource instances, virtual machines, virtual machine monitors or hypervisors, session gateway components, computing resource instance managers and / or virtual desktop instances; or client computing devices or other components on a client network) can be implemented using a computer system similar to computer system 2000 that has been configured to provide the functionality of these components. In the illustrated embodiment, computer system 2000 includes one or more processors (e.g., processors 2010A and 2010B to 2010N) coupled to system memory 2020 via input / output (I / O) interface 2030. Computer system 2000 also includes one or more network interfaces 2040 coupled to I / O interface 2030. In some implementations, network interface 2040 may include two or more network interfaces, including, for example, a network interface configured to communicate between virtualized computing resources hosted on computer system 2000 and their clients, and a network interface configured to communicate between the virtualized computing resources and Internet destinations on networks other than provider networks and client networks hosting the virtualized computing resources on their behalf.

[0214] In various embodiments, computer system 2000 may be a single-processor system including one processor, or a multiprocessor system including several processors 2010A-2010N (e.g., two, four, eight, or another suitable number). Processors 2010A-2010N may be any suitable processor capable of executing instructions. For example, in various embodiments, processors 2010A-2010N may be processors implementing any of a variety of instruction set architectures (ISAs) (e.g., x86, PowerPC, SPARC, or MIPS ISA or any other suitable ISA). In a multiprocessor system, each processor 2010A-2010N may, but does not necessarily, implement the same ISA.

[0215] System memory 2020 may be configured to store instructions and data accessible by processors 2010A-2010N. In various embodiments, system memory 2020 may be implemented using any suitable memory technology, such as static random access memory (SRAM), synchronous dynamic RAM (SDRAM), non-volatile / flash memory, or any other type of memory. In the illustrated embodiment, program instructions and data implementing one or more desired functions (such as the methods, techniques, and data described above for managing resources of virtual desktop instances) are shown stored within system memory 2020 as code 2025 and data 2026.

[0216] In one embodiment, I / O interface 2030 may be configured to coordinate I / O traffic between processor 2010, system memory 2020, and any peripheral devices within the device, including network interface 2040 or any other peripheral interface. In some embodiments, I / O interface 2030 may perform any necessary protocol, timing, or other data conversions to transform data signals from one component (e.g., system memory 2020) into a format suitable for use by another component (e.g., processors 2010A-2010N). In some embodiments, I / O interface 2030 may include support for devices attached via various types of peripheral buses, such as, for example, the Peripheral Component Interconnect (PCI) bus standard or variations of the Universal Serial Bus (USB) standard. In some embodiments, the functionality of I / O interface 2030 may be distributed across two or more separate components, such as, for example, a northbridge and a southbridge. Additionally, in some implementations, some or all of the functions of the I / O interface 2030 (such as an interface to system memory 2020) may be directly incorporated into the processors 2010A-2010N.

[0217] Network interface 2040 can be configured to allow data exchange between computer system 2000 and other devices 2060 (such as other computer systems or devices as shown in the figures) attached to one or more networks 2050. In various embodiments, one or more network interfaces 2040 can support communication over any suitable wired or wireless general-purpose data network (such as Ethernet network types). Additionally, one or more network interfaces 2040 can support communication over telecommunications / telephone networks (such as analog voice networks or digital fiber optic communication networks), over storage area networks (such as Fibre Channel SANs), or over any other suitable type of network and / or protocol.

[0218] In some embodiments, system memory 2020 may be one embodiment of a computer-accessible medium configured to store program instructions and data as described above, which are used to implement various embodiments of the techniques described herein for managing resources of virtual desktop instances. However, in other embodiments, program instructions and / or data may be received, transmitted, or stored on different types of computer-accessible media. Generally, computer-accessible (e.g., computer-readable) media may include non-transitory storage media or memory media, such as magnetic or optical media, such as a disk or DVD / CD connected to computer system 2000 via I / O interface 2030. Non-transitory computer-accessible (e.g., computer-readable) storage media may also include any volatile or non-volatile media that may be included as system memory 2020 or another type of memory in some embodiments of computer system 2000, such as RAM (e.g., SDRAM, DDR SDRAM, RDRAM, SRAM, etc.), ROM, etc. Additionally, computer-accessible media may include transmission media or signals, such as electrical signals, electromagnetic signals, or digital signals transmitted via communication media (networks and / or wireless links), which may be implemented via one or more network interfaces 2040.

[0219] The various methods illustrated in the figures and described herein represent exemplary embodiments of the methods. The methods can be implemented in software, hardware, or a combination thereof. The order of the methods can be changed, and various elements can be added, reordered, combined, omitted, modified, etc.

[0220] It will be apparent to those skilled in the art that various modifications and changes can be made. All such modifications and changes are intended to be included, and accordingly, the above description should be considered illustrative rather than restrictive.

Claims

1. A system comprising: Multiple computing nodes in a provider network collectively provide virtual desktop services to a client organization, wherein each computing node includes at least one processor and memory, and wherein the client organization includes multiple users; The virtual desktop service is configured as follows: Based on submissions made by the client organization through a programming interface or a user interface, a fixed number of virtual desktop slots is determined for the client organization, wherein the fixed number of virtual desktop slots is less than the number of users in the client organization; Multiple virtual desktop instances are provided in a pool, wherein the virtual desktop instances are implemented using the resources of the provider network, wherein the number of virtual desktop instances in the pool does not exceed the fixed number of virtual desktop slots, and wherein the virtual desktop slots in the fixed number of virtual desktop slots represent: (a) a virtual desktop instance of the multiple virtual desktop instances connected to a client device in the client organization, (b) a virtual desktop instance of the multiple virtual desktop instances whose connection has been interrupted but is still running and is available only for connection requests from the same client device, or (c) an empty slot available for a virtual desktop instance; Receive a first connection request from a first client device associated with a first user among the users; The first client device is provided with access to a specific virtual desktop instance in the pool, based at least in part on the determination that the current number of connected virtual desktop instances in the pool at the time of the first connection request is less than the fixed number of virtual desktop slots. Receive a second connection request from a second client device associated with the second user among the users; and The second client device is denied access to the plurality of virtual desktop instances in the pool, at least in part, based on the determination that the current number of connected virtual desktop instances in the pool at the time of the second connection request is consistent with the fixed number of virtual desktop slots.

2. The system according to claim 1, wherein the virtual desktop service is further configured as follows: Determine the expected rate at which the fixed number of virtual desktop slots are consumed by multiple connected virtual desktop instances; and Based at least in part on the expected rate, one or more disconnected virtual desktop instances in the pool are recycled, wherein one or more recycled virtual desktop instances are available for new connection requests.

3. The system according to claim 1, wherein the virtual desktop service is further configured as follows: At least in part, based on the determination that the current number of connected virtual desktop instances in the pool at the second time point is consistent with the fixed number of virtual desktop slots, the second client device is provided with access to a second virtual desktop instance outside the pool.

4. A method comprising: The virtual desktop service is implemented by one or more computing devices jointly provided by the provider network: Multiple virtual desktop instances are reserved in a pool for a client organization, wherein the virtual desktop instances are implemented using resources of the provider network, wherein the number of virtual desktop instances in the pool does not exceed the number of virtual desktop slots of the client organization, wherein the number of virtual desktop slots is based on a submission by the client organization through a programming interface or a user interface, wherein the client organization includes multiple users, and wherein the virtual desktop slots in the number of virtual desktop slots represent: (a) virtual desktop instances of the multiple virtual desktop instances connected to client devices in the client organization, (b) virtual desktop instances of the multiple virtual desktop instances whose connection has been interrupted but are still running and are available only for connection requests from the same client device, or (c) empty slots available for virtual desktop instances; Access to a specific virtual desktop instance in the pool is provided to a first client device associated with a first user, based at least in part on the determination that the current number of connected virtual desktop instances in the pool at a first time point is less than the number of virtual desktop slots. as well as Access to the plurality of virtual desktop instances in the pool by a second client device associated with a second user is denied, at least in part, based on the determination that the current number of connected virtual desktop instances in the pool at a second point in time is consistent with the number of virtual desktop slots.

5. The method according to claim 4, further comprising: Determine the expected rate at which the number of virtual desktop slots are consumed by multiple connected virtual desktop instances; as well as Based at least in part on the expected rate, one or more unused virtual desktop instances in the pool are reclaimed, wherein one or more reclaimed virtual desktop instances are available for new connection requests.

6. The method according to claim 4, further comprising: At least in part, based on the determination that the current number of connected virtual desktop instances in the pool at the second time point matches the number of virtual desktop slots, the second client device is provided with access to a second virtual desktop instance outside the pool.

7. The method of claim 4, wherein the specific virtual desktop instance is launched using a root storage volume before receiving a connection request from the first client device, and wherein the method further comprises: Receive the connection request from the first client device; as well as A data volume associated with the first user is added to the specific virtual desktop instance, wherein the data volume is added at least in part based on the connection request from the first client device.

8. The method according to claim 4, further comprising: Determine that the first user has disconnected from the specific virtual desktop instance; as well as Reclaiming the specific virtual desktop instance includes: Separate the root volume and data volume from the specific virtual desktop instance; as well as Restart the specific virtual desktop instance using the new root volume.

9. The method according to claim 4, further comprising: Another virtual desktop instance in the pool is designated as a reserved instance for a specific user among the users of the client organization, wherein the reserved instance is not reclaimed if it is disconnected from the client device associated with the specific user among the users.

10. The method of claim 4, further comprising: It is determined that the specific virtual desktop instance is disconnected from the first client device; as well as The specific virtual desktop instance is returned to a set of available instances, which are accessible to the client organization and one or more other client organizations.

11. A computer-readable storage medium storing program instructions, said program instructions being computer-executable to perform: Multiple virtual desktop instances are provided in a pool for a client organization, wherein the virtual desktop instances are implemented using resources of a provider network, wherein the number of virtual desktop instances in the pool does not exceed the number of virtual desktop slots in the client organization, wherein the number of virtual desktop slots is based on submissions by the client organization through a programming interface or a user interface, wherein the client organization includes multiple users, wherein the number of virtual desktop slots is less than the number of users in the client organization, and wherein the number of virtual desktop slots represents: (a) a virtual desktop instance of the multiple virtual desktop instances connected to a client device in the client organization, (b) a virtual desktop instance of the multiple virtual desktop instances whose connection has been interrupted but is still running and is available only for connection requests from the same client device, or (c) an empty slot available for a virtual desktop instance; Based at least in part on determining that the current number of connected virtual desktop instances in the pool at a first time point is less than the number of virtual desktop slots, access to a specific virtual desktop instance in the pool is provided to a first client device associated with a first user among the users; and Access to the plurality of virtual desktop instances in the pool by a second client device associated with a second user is denied, at least in part, based on the determination that the current number of connected virtual desktop instances in the pool at a second point in time is consistent with the number of virtual desktop slots.

12. The computer-readable storage medium of claim 11, wherein the program instructions are also executable by a computer: Determine the expected rate at which the number of virtual desktop slots are consumed by multiple connected virtual desktop instances; and Based at least in part on the expected rate, one or more disconnected virtual desktop instances in the pool are recycled, wherein one or more recycled virtual desktop instances are available for new connection requests.

13. The computer-readable storage medium of claim 11, wherein the program instructions are also executable by a computer: The selection of one or more disconnected virtual desktop instances to be reclaimed is based at least in part on user characteristics.

14. The computer-readable storage medium of claim 11, wherein the program instructions are also executable by a computer: At least in part, based on the determination that the current number of connected virtual desktop instances in the pool at the second time point matches the number of virtual desktop slots, the second client device is provided with access to a second virtual desktop instance outside the pool.

15. The computer-readable storage medium of claim 11, wherein the specific virtual desktop instance is launched using a root storage volume before a connection request is received from the first client device, and wherein the program instructions are also executable by a computer to perform: Receive the connection request from the first client device; and A data volume associated with the first user is added to the specific virtual desktop instance, wherein the data volume is added at least in part based on the connection request from the first client device.

Images