WO2017117086A1 - Gestion de groupes d'instances de bureau virtuel - Google Patents

Gestion de groupes d'instances de bureau virtuel Download PDF

Info

Publication number
WO2017117086A1
WO2017117086A1 PCT/US2016/068638 US2016068638W WO2017117086A1 WO 2017117086 A1 WO2017117086 A1 WO 2017117086A1 US 2016068638 W US2016068638 W US 2016068638W WO 2017117086 A1 WO2017117086 A1 WO 2017117086A1
Authority
WO
WIPO (PCT)
Prior art keywords
virtual desktop
instance
instances
client
pool
Prior art date
Application number
PCT/US2016/068638
Other languages
English (en)
Inventor
Nathan Bartholomew Thomas
Salman Aftab Paracha
Varun Verma
Original Assignee
Amazon Technologies, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Amazon Technologies, Inc. filed Critical Amazon Technologies, Inc.
Priority to DE112016006080.7T priority Critical patent/DE112016006080B4/de
Priority to CN201680076692.5A priority patent/CN108431778A/zh
Publication of WO2017117086A1 publication Critical patent/WO2017117086A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5061—Partitioning or combining of resources
    • G06F9/5077—Logical partitioning of resources; Management or configuration of virtualized resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/5011—Pool

Definitions

  • virtualization technologies may allow a single physical computing machine to be shared among multiple users by providing each user with one or more virtual machines hosted by the single physical computing machine, with each such virtual machine being a software simulation acting as a distinct logical computing system that provides users with the illusion that they are the sole operators and administrators of a given hardware computing resource, while also providing application isolation and security among the various virtual machines.
  • some virtualization technologies are capable of providing virtual resources that span two or more physical resources, such as a single virtual machine with multiple virtual processors that spans multiple distinct physical computing systems.
  • the single physical computing device can create, maintain or delete virtual machines in a dynamic manner.
  • users can request computer resources from a data center and be provided with varying numbers of virtual machine resources on an "as needed” basis or at least on an "as requested” basis.
  • Some of these virtualized resources can be used to implement virtual desktop instances on which remote computing sessions may be hosted.
  • Service providers that implement virtual desktop instances for the benefit of customers often shut down the underlying service provider resources each time the customer disconnects from their virtual desktop instance (e.g., by logging out).
  • the customer wants to reconnect to their virtual desktop instance it can take a long time to bring the service provider resources back up. Additionally, it can also take a long time to restart any applications that were previously running on the service provider resources so that the customer can continue working (e.g., two orders of magnitude longer than logging into a local machine).
  • FIG. 1 is a block diagram illustrating an example provider network environment, according to at least some embodiments.
  • FIG. 2 is a block diagram illustrating an example provider network that provides a storage virtualization service and a hardware virtualization service to clients, according to at least some embodiments.
  • FIG. 3 is a block diagram illustrating a networked computing environment that includes a client computing device in communication with a service provider computer network, according to at least some embodiments.
  • FIG. 4 is a block diagram illustrating an example service provider data center, according to at least some embodiments.
  • FIG. 5 is a flow diagram illustrating one embodiment of a method for managing resources for virtual desktop instances.
  • FIG. 6 is a flow diagram illustrating one embodiment of a method for detecting that a client has disconnected from a virtual desktop instance (or has effectively disconnected from a virtual desktop instance through inactivity).
  • FIG. 7 is a flow diagram illustrating one embodiment of a method for determining whether and/or when to shut down the computing resource instances for a virtual desktop instance by applying one or more shutdown policies.
  • FIG. 8 is a flow diagram illustrating one embodiment of a method for building a predictive model of connections and disconnections for a virtual desktop instance.
  • FIG. 9 is a flow diagram illustrating one embodiment of a method for managing service provider resources for a virtual desktop instance in response to a disconnection a reconnection.
  • FIG. 10 is a flow diagram illustrating one embodiment of a method for initializing and modifying a configuration and/or shutdown policy for a virtual desktop instance.
  • FIG. 11 is a block diagram illustrating an example provider network that provides a virtual desktop service with a virtual desktop instance pool to a client organization, according to at least some embodiments.
  • FIG. 12 is a block diagram illustrating further aspects of the example provider network that provides a virtual desktop service with a virtual desktop instance pool, including connected and disconnected virtual desktop instances in slots in the pool, according to at least some embodiments.
  • FIG. 13 is a block diagram illustrating further aspects of the example provider network that provides a virtual desktop service with a virtual desktop instance pool, including providing access to a virtual desktop instance outside the pool to a client device when all slots in the pool have been taken by connected instances, according to at least some embodiments.
  • FIG. 14 is a block diagram illustrating further aspects of the example provider network that provides a virtual desktop service with a virtual desktop instance pool, including reclamation of disconnected virtual desktop instances in the pool, according to at least some embodiments.
  • FIG. 15 is a block diagram illustrating further aspects of the example provider network that provides a virtual desktop service with a virtual desktop instance pool, including providing access to a restarted virtual desktop instance in the pool to a client device, according to at least some embodiments.
  • FIG. 16 is a flow diagram illustrating one embodiment of a method for management of virtual desktop instance pools.
  • FIG. 17 is a flow diagram illustrating one embodiment of a method for reclamation of disconnected virtual desktop instances in a pool.
  • FIG. 18 is a block diagram illustrating an example computer system that implements some or all of the techniques described herein, according to different embodiments.
  • a virtual desktop service may provide virtual desktop instances to clients.
  • a client organization and the provider network may reach an agreement that the provider network will reserve a pool of virtual desktop instances to users of the client organization.
  • the pool may include a predetermined or fixed number of slots. Any of the slots may be filled by a connected virtual desktop instance, a disconnected (but still running) virtual desktop instance, or no virtual desktop instance (i.e., an empty slot).
  • the number of users in the client organization may typically exceed the number of slots in the pool.
  • a user in the client organization may be denied access to the pool if all the slots are consumed by connected instances.
  • Disconnected (but running) instances may be reclaimed and made available for new connection requests, e.g., as the rate of connected instances approaches full consumption of the slots. Disconnected instances may be selected for reclamation based on the duration of instance idleness (e.g., to prioritize maintaining the most recently disconnected instances), the anticipated duration of instance restart (e.g., to prioritize maintaining disconnected instances that would take longest to restart), the relative rankings or other characteristics of users (e.g., to prioritize maintaining disconnected instances for higher-ranked or higher-priority users), and/or other suitable criteria. In some circumstances, the pool may be dynamically expanded or a client device may be provided access to a virtual desktop instance outside the pool (e.g., an instance charged on an hourly basis) if the pool is full of connected instances.
  • the duration of instance idleness e.g., to prioritize maintaining the most recently disconnected instances
  • the anticipated duration of instance restart e.g., to prioritize maintaining disconnected instances that would take longest to restart
  • the relative rankings or other characteristics of users e.g., to prioritize maintaining
  • FIG. 18 An example computer system on which embodiments of the techniques for managing resources for virtual desktop instances described herein may be implemented is illustrated in FIG. 18.
  • Embodiments of various systems and methods for implementing these techniques are generally described herein in the context of a service provider that provides to clients, via an intermediate network such as the Internet, virtualized resources (e.g., virtualized computing and storage resources) implemented on a provider network of the service provider.
  • FIGS. 1-4 and 11 (and the corresponding descriptions thereof) illustrate and describe example environments in which embodiments of the systems and methods described herein may be implemented, and are not intended to be limiting.
  • At least some of the resources provided to clients of the service provider via the provider network may be virtualized computing resources implemented on multi-tenant hardware that is shared with other client(s) and/or on hardware dedicated to the particular client.
  • Each virtualized computing resource may be referred to as a resource instance.
  • Resource instances may, for example, be rented or leased to clients of the service provider.
  • clients of the service provider may access one or more services of the provider network via APIs to the services to obtain and configure resource instances and to establish and manage virtual network configurations that include the resource instances, for example virtualized private networks.
  • the resource instances may, for example, be implemented according to hardware virtualization technology that enables multiple operating systems to run concurrently on a host computer, i.e. as virtual machines (VMs) on the hosts.
  • a hypervisor, or virtual machine monitor (VMM), on a host may present the VMs on the host with a virtual platform and monitors the execution of the VMs.
  • Each VM may be provided with one or more private IP addresses; the VMM on a host may be aware of the private IP addresses of the VMs on the host.
  • FIG. 4 An example of a system that employs such a hardware virtualization technology is illustrated in FIG. 4 and described in detail below.
  • a service provider may host virtualized resource instances on behalf of a customer that can be access by end users.
  • end users who are associated with the customer on whose behalf the virtualized resources instances are hosted (e.g., members of the same organization or enterprise) may be able to access the virtualized resources instances using client applications on client devices.
  • the virtualized resources instances may be configured to implement virtual desktop instances.
  • FIG. 1 illustrates an example provider network environment, according to at least some embodiments.
  • a provider network 100 may provide resource virtualization to clients via one or more virtualization services 110 that allow clients to purchase, rent, or otherwise obtain instances 112 of virtualized resources, including but not limited to computation and storage resources, implemented on devices within the provider network or networks in one or more data centers.
  • Private IP addresses 116 may be associated with the resource instances 1 12; the private IP addresses are the internal network addresses of the resource instances 1 12 on the provider network 100.
  • the provider network 100 may also provide public IP addresses 114 and/or public IP address ranges (e.g., Internet Protocol version 4 (IPv4) or Internet Protocol version 6 (IPv6) addresses) that clients may obtain from the provider 100.
  • IPv4 Internet Protocol version 4
  • IPv6 Internet Protocol version 6
  • the provider network 100 may allow a client of the service provider (e.g., a client that operates client network 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 client with particular resource instances 112 assigned to the client.
  • the provider network 100 may also allow the client to remap a public IP address 114, previously mapped to one virtualized computing resource instance 112 allocated to the client, to another virtualized computing resource instance 112 that is also allocated to the client.
  • a client of the service provider such as the operator of client network 150A may implement client-specific applications and present the client's applications on an intermediate network 140, such as the Internet.
  • Other network entities 120 on the intermediate network 140 may then generate traffic to a destination public IP address 114 published by the client network 150A; the traffic is routed to the service provider data center, and at the data center is routed, via a network substrate, to the private IP address 1 16 of the virtualized computing resource instance 112 currently mapped to the destination public IP address 114.
  • response traffic from the virtualized computing resource instance 112 may be routed via the network substrate back onto the intermediate network 140 to the source entity 120.
  • Private IP addresses refer to the internal network addresses of resource instances in a provider network. Private IP addresses are only routable within the provider network. Network traffic originating outside the provider network is not directly routed to private IP addresses; instead, the traffic uses public IP addresses that are mapped to the resource instances.
  • the provider network may include network devices or appliances that provide network address translation (NAT) or similar functionality to perform the mapping from public IP addresses to private IP addresses and vice versa.
  • NAT network address translation
  • Public IP addresses are Internet routable network addresses that are assigned to resource instances, either by the service provider or by the client. Traffic routed to a public IP address is translated, for example via 1 : 1 network address translation (NAT), and forwarded to the respective private IP address of a resource instance.
  • NAT network address translation
  • Some public IP addresses may be assigned by the provider network infrastructure to particular resource instances; these public IP addresses may be referred to as standard public IP addresses, or simply standard IP addresses.
  • the mapping of a standard IP address to a private IP address of a resource instance is the default launch configuration for all a resource instance types.
  • At least some public IP addresses may be allocated to or obtained by clients of the provider network 100; a client may then assign their allocated public IP addresses to particular resource instances allocated to the client. These public IP addresses may be referred to as client public IP addresses, or simply client IP addresses. Instead of being assigned by the provider network 100 to resource instances as in the case of standard IP addresses, client IP addresses may be assigned to resource instances by the clients, for example via an API provided by the service provider. Unlike standard IP addresses, client IP addresses may be allocated to client accounts and remapped to other resource instances by the respective clients as necessary or desired. In some embodiments, a client IP address is associated with a client's account, not a particular resource instance, and the client controls that IP address until the client chooses to release it.
  • client IP addresses may allow the client to mask resource instance or availability zone failures by remapping the client's public IP addresses to any resource instance associated with the client's account.
  • the client IP addresses may enable a client to engineer around problems with the client's resource instances or software by remapping client IP addresses to replacement resource instances.
  • the resource instances 112 that are made available to clients (e.g., client devices 152) via virtualization service(s) 1 10 may include multiple network interfaces. For example, at least some of them may include one network interface for communicating with various components of a client network 150 and another network interface for communicating with resources or other network entities on another network that is external to provider network 100 (not shown).
  • FIG. 2 is a block diagram of another example provider network environment, one that provides a storage virtualization service and a hardware virtualization service to clients, according to at least some embodiments.
  • hardware virtualization service 220 provides multiple computation resources 224 (e.g., VMs) to clients.
  • the computation resources 224 may, for example, be rented or leased to clients of the provider network 200 (e.g., to a client that implements client network 250). Each computation resource 224 may be provided with one or more private IP addresses. Provider network 200 may be configured to route packets from the private IP addresses of the computation resources 224 to public Internet destinations, and from public Internet sources to the computation resources 224.
  • Provider network 200 may provide a client network 250, for example coupled to intermediate network 240 via local network 256, the ability to implement virtual computing systems 292 via hardware virtualization service 220 coupled to intermediate network 240 and to provider network 200.
  • hardware virtualization service 220 may provide one or more APIs 202, for example a web services interface, via which a client network 250 may access functionality provided by the hardware virtualization service 220, for example via a console 294.
  • each virtual computing system 292 at client network 250 may correspond to a computation resource 224 that is leased, rented, or otherwise provided to client network 250.
  • a virtualized data store gateway may be provided at the client network 250 that may locally cache at least some data, for example frequently accessed or critical data, and that may communicate with virtualized data store service 210 via one or more communications channels to upload new or modified data from a local cache so that the primary store of data (virtualized data store 216) is maintained.
  • a user via a virtual computing system 292 and/or on another client device 290, may mount and access one or more storage volumes 218 of virtual data store 216, each of which appears to the user as local virtualized storage 298.
  • the virtualization service(s) may also be accessed from resource instances within the provider network 200 via API(s) 202.
  • a client, appliance service provider, or other entity may access a virtualization service from within a respective private network on the provider network 200 via an API 202 to request allocation of one or more resource instances within the private network or within another private network.
  • the hardware virtualization service 220 may be configured to provide computation resources 224 that have been configured to implement a virtual desktop instance, which may appear to the user as a local desktop (implemented by a virtual computing system 292).
  • the computation resources 224 that are made available to the client 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 client network 250 and another network interface for communicating with computation resources or other network entities on another network that is external to provider network 200 (not shown).
  • various components of a service provider network may be configured for the generation and management of remote computing sessions between client computing devices and virtual desktop instances hosted by one or more remote data center computers of a Program Execution Service (PES) platform.
  • PES Program Execution Service
  • a number of data centers may be organized as part of a single PES platform that can facilitate the utilization of resources of the data centers by customers of the PES.
  • the PES may include several hundreds or thousands of data center computers.
  • client computing devices may access the virtual desktop instances during one or more remote computing sessions, and a virtual desktop instance may provide a user with all of the capabilities of a client desktop environment but with centralized provisioning of the services accessed by the client.
  • a user via a client computing device, may transmit a request to load an application such as a remote computing application. Subsequent to the receipt of the request, the client computing device may communicate with a PES platform to start a remote computing session.
  • the communication between the client computing device and the PES platform may include login information.
  • the communication may also include information identifying resource usage information, processing requirements, 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 further communicate various information relating to the device state, including, but not limited to, a current or future availability of device resources (e.g., processing power, memory, storage, network usage, etc.).
  • the PES platform may identify one or more virtual desktop instances for execution in one or more remote computing sessions.
  • the PES platform may instantiate, or cause to have instantiated, a virtual machine instance on a data center computer, and 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 user interface of the operating system (e.g., the output of the operating system, such as a graphical user interface, sound, etc.) may be sent to the client computing device via a particular network interface of the virtual machine instance or virtual desktop instance and presented to the user (e.g., the graphical user interface may be rendered on a display of the client computing device).
  • the user interface of the operating system e.g., the output of the operating system, such as a graphical user interface, sound, etc.
  • the operating system may use a desktop profile associated with the user and stored on a desktop store accessible by the PES to configure the virtual desktop instance for the user by setting the desktop background, screen saver, desktop layout, pointer preferences, sound settings, and the like.
  • User input such as mouse and keyboard activity may then be sent to the virtual machine (via a particular network interface of the virtual machine instance or virtual desktop instance) and injected into the operating system as if the activity was performed by a user directly at the virtual machine.
  • the PES platform may receive or generate data associated with the interaction of the client computing device with the virtual desktop instance on the client computing device during the remote computing session.
  • the data may include user data and preferences, files, and the like.
  • the PES platform may save the data to the desktop store associated with the virtual desktop instance.
  • the desktop store may be implemented on a volume, or on another logical block storage device.
  • the PES may create a backup copy of the data or also store the data to a central repository. The saved data may then be used to restore remote computing sessions that have been interrupted due to a failure, such as a failure of the virtual desktop instance, the server hosting the virtual desktop instance, the network, etc.
  • the PES platform may ensure that the re-establishment of a remote computing session occurs with minimal delay and disruption to a user of a client computing device.
  • the virtual desktop instance provided may be configured according to a user profile stored at a user profile store of the PES.
  • the configuration of the virtual desktop instance may also be adjusted according to monitored usage of the instance.
  • the user profile may be set by an administrator associated with an entity governing the user's use.
  • the user profile may indicate various memory and processing requirements associated with the PES computers executing the one or more virtual desktop instances as well as requirements for the virtual desktop instances.
  • the user profile may indicate the programs to which the user is given access while using the virtual desktop instance.
  • the user profile may also indicate a maximum time or cost associated with the remote computing session.
  • the PES may take a user profile for the user into consideration when placing and configuring the virtual desktop instances.
  • placement and configuration decisions may also be adjusted based on a user's interaction with the virtual desktop over time.
  • FIG. 3 is a block diagram illustrating an example networked computing environment 300 that includes a client computing device 306 in communication with a service provider computer network 305 via the communication network 304.
  • the client computing device 306 may be used for providing access to a remote operating system and applications to a user.
  • the client computing device 306 may correspond to a wide variety of computing devices including personal computing devices, laptop computing devices, hand-held computing devices, terminal computing devices, mobile devices (e.g., mobile phones, tablet computing devices, electronic book readers, etc.), wireless devices, various electronic devices and appliances, and the like.
  • the client computing device 306 includes necessary hardware and software components for establishing communications over a communication network 304, such as a wide area network or local area network.
  • the client computing device 306 may be equipped with networking equipment and browser software applications that facilitate communications via the Internet or an intranet.
  • the client computing device 306 may have varied local computing resources such as central processing units and architectures, memory, mass storage, graphics processing units, communication network availability and bandwidth, etc.
  • the client computing device 306 may run a remote computing application 330.
  • the remote computing application 330 may request access to a virtual desktop instance hosted by the service provider computer network 305.
  • the remote computing application 330 may also manage the remote computing session between the client computing device 306 and the service provider computer network 305.
  • the service provider computer network 305 may also include a PES platform 302.
  • the PES platform 302 illustrated in FIG. 3 corresponds to a logical association of one or more data centers associated with a service provider.
  • the PES platform 302 may be associated with a number of data center computers, such as, for example, data center computers 310.
  • Each data center computer 310 may host one or more virtual desktop instances 314.
  • the data center computer 310 may host a virtual desktop instance by executing a virtual machine on a physical device.
  • the virtual machine may execute an instance of an operating system and application software to create a virtual desktop instance.
  • Each virtual desktop instance executed by the PES 302 may be accessed by one or more client computing devices, such as client computing device 306.
  • client computing devices such as client computing device 306.
  • data center computers 310 may be associated with private network addresses, such as IP addresses, within the service provider computer network 305 such that they may not be directly accessible by the client computing devices 306.
  • the virtual desktop instances 314 may be associated with public network addresses that may be made available by a gateway at the edge of the service provider computer network 305. Accordingly, the virtual desktop instances 314 may be directly addressable by client computing devices 306 via the public network addresses.
  • each data center computer 310 would include physical computing device resources and software to execute the multiple virtual desktop instances 314 or to dynamically instantiate virtual desktop instances 314. Such instantiations can be based on a specific request, such as from the client computing device 306.
  • the data center computers 310 may include one or more instance managers 322.
  • the instance managers 322 may be on the same computer as the respective instances 314, or on a separate computer.
  • the instance managers 322 may track progress of the instances executed on the data center computers 310, monitor and coordinate the storage of data created by the user while interacting with the instances 314 via the client computing devices, and monitor the overall health and state of the data center computers 310 and of the remote computing applications running on the client computing devices 306.
  • the instance managers 322 may communicate information collected through tracking and monitoring with the data center management component 301 of the PES platform 302 in order to efficiently manage the various remote computing sessions between the data center computers 310 and the client computing devices 306.
  • the techniques described herein for detecting activity or inactivity on a virtual desktop instance, monitoring and tracking connections to, disconnections from, and reconnections to various virtual desktop instances, and determining whether and/or when to shut down the underlying virtualized computing resources may be performed by the instance managers 322.
  • 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.
  • the storage servers 307 may be used for storing data generated or utilized by the virtual desktop instances 314.
  • the data generated or utilized by the virtual desktop instances 314 may be based on the interaction between the client computing devices 306 and the PES 302 via one or more remote computing sessions.
  • the storage service platform 303 may logically organize and maintain information associated with a hosted virtual desktop instance 314 in a desktop store.
  • the information associated with a virtual desktop instance 314 maintained in the desktop store may include, but is not limited to, user preferences, user or customer-specific policies, information associated with the execution of program data, user content, references to user content, and the like.
  • folders used by the user to store music, files, and the like on other storage devices, including through storage service providers may also be mapped to the desktop store via references to those storage locations. That is to say, input/output operations, such as requests to open files in these folders, can be redirected to the desktop store.
  • the request can be redirected by the operating system running in the virtual desktop instance to the desktop store.
  • the user's desktop profile which may include, for example, configuration information for the desktop such as the background picture, fonts, arrangement of icons, and the like, may also be stored on the desktop store associated with the user's virtual desktop instance.
  • the service provider computer network 305 may be able to mitigate the effect of failures of the data center computer(s) 310 running the virtual desktop instances 314 or errors associated with the execution of virtual desktop instances 314 on the data center computer(s) 310 by storing data on storage servers independent from the data center computers 310. Additionally, the service provider network 305 may also facilitate client interaction with multiple virtual desktop instances 314 by maintaining the information in the desktop stores. In some embodiments, if one virtual desktop instance 314 fails, a new instance may be launched and attached to the same desktop store that was previously attached to the virtual desktop instance 314 that failed.
  • the desktop stores may be distributed across multiple servers, they may be replicated for performance purposes on servers in different network areas, or they may be replicated across multiple servers with independent failure profiles for backup or fault performance purposes.
  • the servers may be attached to different power sources or cooling systems, the servers may be located in different rooms of a data center or in different data centers, and/or the servers may be attached to different routers or network switches.
  • a desktop store may be located on one storage server, and changes made to the desktop store may be replicated to another desktop store on a different storage server. Such replication may create a backup copy of the user's data. If the desktop store fails or the virtual desktop instance 314 loses its connection to the desktop store, the PES 302 may switch the connection of the virtual desktop instance 314 from the desktop store to the back-up desktop store.
  • the PES platform 302 may also include a central storage device such as a PES repository 340 for storing data stored by the various desktop stores and backup stores on storage servers 307.
  • the data center computers 310 and the storage servers 307 may further include additional software or hardware components that facilitate communications including, but not limited to, load balancing or load sharing software/hardware components for selecting instances of a virtual machine supporting a requested application and/or providing information to a DNS name server to facilitate request routing.
  • 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 a user is given access to while using a virtual desktop instance 314.
  • the user profiles stored may also indicate a maximum time or cost associated with the remote computing sessions of different users.
  • the PES platform 302 may take user profiles into consideration when placing, configuring, and/or managing virtual desktop instances 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 template images of operating systems without customizations applied per user profiles.
  • data center computers 310 and storage servers 307 may be considered to be logically grouped, regardless of whether the components, or portions of the components, are physically separate.
  • a service provider computer network 305 may maintain separate locations for providing the virtual desktop instances 314 and the storage components.
  • the data center computers 310 are illustrated in FIG. 3 as logically associated with a PES platform 302, the data center computers 310 may be geographically distributed in a manner to best serve various demographics of its users.
  • the service provider computer network 305 may be associated with various additional computing resources, such additional computing devices for administration of content and resources, and the like.
  • the service provider computer network 305 (and/or various ones of the virtual desktop instances 314 implemented thereon) may be configured to communicate with other network entities 320 over communication network 304 or over another communication network (e.g., at least some of the virtual desktop instances 314 may include a network interface usable to access one or more other network entities 320 that is separate and distinct from to a network interface that is usable to communicate with client computing device 306).
  • These other network entities 320 may include, for example, other client networks or computing devices thereof, computing systems that provide resources for servicing requests received from client computing device 306, and/or networks or computing devices thereof that access other services, applications, or data over the Internet.
  • the processing requirements associated with a user or a client computing device may be determined based on a variety of scenarios.
  • the determination may be based on a user request at launching of the remote computing application 330.
  • the user may be presented with a graphical user interface (GUI) displaying a variety of options for resources and applications.
  • GUI graphical user interface
  • the user may then select the applications they wish to have access to, or, alternatively, the version of those applications. For example, one user may wish to access a basic version of an application while another user may wish to access a professional version of the same application.
  • the determination may also be based on preselected options for certain users as determined by administrators of entities associated with the users.
  • the pre-selected options may be presented to the user as a list of different packages of applications to which the user may wish to have access.
  • the determination may be made on historical usage data of a user, which the PES platform 302 may determine once the request is received from the user.
  • the determination of the processing requirements may be based on ongoing monitoring of use of processes by the user once the remote computing session is initiated. In such cases, the selection of adequate resource instances may be dynamically changed after the session is established, and the dynamic change over to new instance(s) may be performed as described with respect to FIG. 3 above.
  • the remote computing application 330 may request that a virtual desktop session be opened on behalf of the client, in response to which a virtual desktop instance 314 may be instantiated, configured for the use of the client, and/or connected to the client computing device 306 over network 304 (e.g., via one of two network interfaces of the virtual desktop instance 314).
  • a service provider network that implements VMs and VMMs may use Internet Protocol (IP) tunneling technology to encapsulate and route client data packets over a network substrate between client resource instances on different hosts within the provider network.
  • IP Internet Protocol
  • the provider network may include a physical network substrate that includes networking devices such as routers, switches, network address translators (NATs), and so on, as well as the physical connections among the devices.
  • the provider network may employ IP tunneling technology to provide an overlay network via which encapsulated packets (that is, client packets that have been tagged with overlay network metadata including but not limited to overlay network address information for routing over the overlay network) may be passed through the network substrate via tunnels or overlay network routes.
  • the IP tunneling technology may provide a mapping and encapsulating system for creating the overlay network on the network substrate, and may provide a separate namespace for the overlay network layer (public IP addresses) and the network substrate layer (private IP addresses). In at least some embodiments, encapsulated packets in the overlay network layer may be checked against a mapping directory to determine what their tunnel substrate target (private IP address) should be.
  • the IP tunneling technology may provide a virtual network topology overlaid on the physical network substrate; the interfaces (e.g., service APIs) that are presented to clients are attached to the overlay network so that when a client resource instance provides an IP address to which packets are to be sent, the IP address is run in virtual space by communicating with a mapping service that can determine where the IP overlay addresses are.
  • An example use of overlay network technology is illustrated in FIG. 4 and described in detail below.
  • client resource instances on the hosts may communicate with other client resource instances on the same host or on different hosts according to stateful protocols such as Transmission Control Protocol (TCP) and/or according to stateless protocols such as User Datagram Protocol (UDP).
  • TCP Transmission Control Protocol
  • UDP User Datagram Protocol
  • the client packets are encapsulated according to an overlay network protocol by the sending VMM and unencapsulated by the receiving VMM.
  • a VMM on a host upon receiving a client packet (e.g., a TCP or UDP packet) from a client resource instance on the host and targeted at an IP address of another client resource instance, encapsulates or tags the client packet according to an overlay network (or IP tunneling) protocol and sends the encapsulated packet onto the overlay network for delivery.
  • a client packet e.g., a TCP or UDP packet
  • the encapsulated packet may then be routed to another VMM via the overlay network according to the 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.
  • client packet e.g., a TCP or UDP packet
  • the encapsulations described herein may 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., data packets for multiple client applications may be traveling on the same physical network but it may appear as if the traffic directed to each of the client applications is traveling on a private network).
  • the overlay network may be a stateless network implemented according to a connectionless (or stateless) IP protocol.
  • the sending may be a stateless network implemented according to a connectionless (or stateless) IP protocol.
  • VMM sends the encapsulated packet onto the overlay network for routing and delivery, but does not receive an acknowledgement (ACK) or other response regarding delivery of the packet.
  • the VMM may receive an ACK or other response regarding delivery of an encapsulated packet.
  • FIG. 4 illustrates an example data center (e.g., one that implements an overlay network on a network substrate using IP tunneling technology), according to at least some embodiments.
  • a provider data center 400 may include a network substrate that includes networking devices 412 such as routers, switches, network address translators (NATs), and so on.
  • networking devices 412 such as routers, switches, network address translators (NATs), and so on.
  • At least some embodiments may employ an Internet Protocol (IP) tunneling technology to provide an overlay network via which encapsulated packets may be passed through network substrate 410 using tunnels.
  • IP Internet Protocol
  • the IP tunneling technology may provide a mapping and encapsulating system for creating an overlay network on a network (e.g., a local network in data center 400 of FIG.
  • the IP tunneling technology provides a virtual network topology (the overlay network); the interfaces (e.g., service APIs) that are presented to clients are attached to the overlay network so that when a client provides an IP address to which the client wants to send packets, the IP address is run in virtual space by communicating with a mapping service (e.g., mapping service 430) that knows where the IP overlay addresses are.
  • a mapping service e.g., mapping service 430
  • the IP tunneling technology may map IP overlay addresses (public IP addresses) to substrate IP addresses (private IP addresses), encapsulate the packets in a tunnel between the two namespaces, and deliver the packet to the correct endpoint via the tunnel, where the encapsulation is stripped from the packet.
  • IP overlay addresses public IP addresses
  • substrate IP addresses private IP addresses
  • FIG. 4 an example overlay network tunnel 434A from a virtual machine (VM) 424A on host 420A to a device on the intermediate network 440 (e.g., a computing system 470, a computing system 452 on local network 450, or a data center 46), and an example overlay network tunnel 434B between a VM 424B on host 420B and a VM 424A on host 420A are shown.
  • VM virtual machine
  • a packet may be encapsulated in an overlay network packet format before sending, and the overlay network packet may be stripped after receiving.
  • an overlay network address (public IP address) may be embedded in a substrate address (private IP address) of a packet before sending, and stripped from the packet address upon receiving.
  • the overlay network may be implemented using 32-bit IPv4 (Internet Protocol version 4) addresses as the public IP addresses, and the IPv4 addresses may be embedded as part of 128-bit IPv6 (Internet Protocol version 6) addresses used on the substrate network as the private IP addresses.
  • At least some networks in which embodiments of the techniques described herein for managing resources for virtual desktop instances may be implemented may include hardware virtualization technology that enables multiple operating systems to run concurrently on a host computer (e.g., hosts 420 A and 420B of FIG. 4), i.e. as virtual machines (VMs) 424 on the hosts 420.
  • the VMs 424 (some of which may be configured to implement a virtual desktop instance for the use of a client) may, for example, be rented or leased to clients of a network provider.
  • a hypervisor, or virtual machine monitor (VMM) 422, on a host 420 may serve as an instance manager for the VMs 424 and/or other virtualized resource instances on the hosts 420, which may include presenting the VMs 424 on the host with a virtual platform and monitoring the execution of the VMs 424.
  • VMM virtual machine monitor
  • the techniques described herein for detecting activity or inactivity on a virtual desktop instance, monitoring and tracking connections to, disconnections from, and reconnections to various virtual desktop instances, and determining whether and/or when to shut down the underlying virtualized computing resources may be performed by the VMM 422.
  • Each VM 424 may be provided with one or more private IP addresses; the VMM 422 on a host 420 may be aware of the private IP addresses of the VMs 424 on the host.
  • a mapping service 430 may be aware of all network IP prefixes and the IP addresses of routers or other devices serving IP addresses on the local network. This includes the IP addresses of the VMMs 422 serving multiple VMs 424.
  • the mapping service 430 may be centralized, for example on a server system, or alternatively may be distributed among two or more server systems or other devices on the network.
  • a network may, for example, use the mapping service technology and IP tunneling technology to, for example, route data packets between VMs 424 on different hosts 420 within the data center 400 network; note that an interior gateway protocol (IGP) may be used to exchange routing information within such a local network.
  • IGP interior gateway protocol
  • a network such as the provider data center 400 network (which is sometimes referred to as an autonomous system (AS)) may use the mapping service technology,
  • FIG. 4 shows an example provider data center 400 implementing a network that provides resource virtualization technology and that provides full
  • the provider data center 400 may, for example, provide clients the ability to implement virtual computing systems (VMs 424) via a hardware virtualization service (such as hardware virtualization service 220 in FIG. 2) and the ability to implement virtualized data stores 416 on storage resources 418 via a storage virtualization service (such as storage virtualization service 210 in FIG. 2).
  • VMs 424 virtual computing systems
  • a hardware virtualization service such as hardware virtualization service 220 in FIG. 2
  • storage virtualization service such as storage virtualization service 210 in FIG. 2
  • the data center 400 network may implement IP tunneling technology, mapping service technology, and a routing service technology to route traffic to and from virtualized resources, for example to route packets from the VMs 424 on hosts 420 in data center 400 to Internet destinations, and from Internet sources to the VMs 424.
  • Internet sources and destinations may, for example, include computing systems 470 connected to the intermediate network 440 and computing systems 452 connected to local networks 450 that connect to the intermediate network 440 (e.g., via edge router(s) 414 that connect the network 450 to Internet transit providers).
  • the provider data center 400 network may also route packets between resources in data center 400, for example from a VM 424 on a host 420 in data center 400 to other VMs 424 on the same host or on other hosts 420 in data center 400.
  • the VMs 424 may include two or more network interfaces. For example, they may include one network interface usable for communications between VMs 424 and the clients on whose behalf VMs 424 are hosted by the provider and a second (separate and distinct) network interface that is usable to access 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 an IP tunneling technology, as described herein.
  • a service provider that provides data center 400 may also provide additional data center(s) 460 that include hardware virtualization technology similar to data center 400 and that may also be connected to intermediate network 440. Packets may be forwarded from data center 400 to other data centers 460, for example from a VM 424 on a host 420 in data center 400 to another VM on another host in another, similar data center 460, and vice versa.
  • a public network may be broadly defined as a network that provides open access to and interconnectivity among a plurality of entities.
  • the Internet, or World Wide Web (WWW) is an example of a public network.
  • a shared network may be broadly defined as a network to which access is limited to two or more entities, in contrast to a public network to which access is not generally limited.
  • a shared network may, for example, include one or more local area networks (LANs) and/or data center networks, or two or more LANs or data center networks that are interconnected to form a wide area network (WAN).
  • Examples of shared networks may include, but are not limited to, corporate networks and other enterprise networks.
  • a shared network may be anywhere in scope from a network that covers a local area to a global network.
  • a shared network may share at least some network infrastructure with a public network, and that a shared network may be coupled to one or more other networks, which may include a public network, with controlled access between the other network(s) and the shared network.
  • a shared network may also be viewed as a private network, in contrast to a public network such as the Internet.
  • either a shared network or a public network may serve as an intermediate network between a provider network and a client network, or between a provider network and other network entities (e.g., external resources, computing systems, data centers, or Internet destinations on networks other than the provider network and the client network on whose behalf VMs 424 are hosted by the provider).
  • a provider network and other network entities e.g., external resources, computing systems, data centers, or Internet destinations on networks other than the provider network and the client network on whose behalf VMs 424 are hosted by the provider.
  • the client applications may be running as virtual machines on the physical computers.
  • internal processes of the cloud computing environment that are configured to manage the creation of these virtual machines, to provision resources for these virtual machines, and/or to perform other administrative tasks on behalf of clients and/or their applications (e.g., monitoring resource usage, customer accounting, billing for services, etc.) may execute in a control plane layer (or hypervisor) in the cloud computing environment.
  • client applications e.g., each resource instance that implements an application component
  • each resource instance may execute as if it has its own network (e.g., a virtual network).
  • each resource instance may have its own data plane network connection(s), but may make local API calls (e.g., calls to a component on the same node) without needing to rely on these data plane network connections.
  • a customer may have an application running on a local machine, but may provision resources instances in a cloud computing environment to be used in case of a failure on the local machine.
  • multiple resource instances may be executing in a cloud computing environment to implement a distributed application on behalf of a client.
  • the cloud computing environment may be a multi-tenant environment in which each application (and/or each virtual private network) may have its own namespace.
  • each client may have its own allocation of network connectivity and/or throughput capacity (bandwidth).
  • the network connectivity and/or throughput capacity in the data plane network may be provisioned (e.g., designated or reserved) for the use of various clients.
  • a provider of virtual computing services may implement private networks on the provider network for at least some clients.
  • a client's virtualized private network on the service provider network may enable a client to connect their existing infrastructure (e.g., client devices) on the client network to a set of logically isolated resource instances (e.g., VMs and storage devices or volumes), and to extend management capabilities such as security services, firewalls, and intrusion detection systems to include their resource instances.
  • a client's virtualized private network may be connected to a client network via a private communications channel.
  • a private communications channel may, for example, be a tunnel implemented according to a network tunneling technology or some other peering connection over an intermediate network.
  • the intermediate network may, for example, be a shared network or a public network such as the Internet.
  • a private communications channel may be implemented over a direct, dedicated connection between a virtualized private network and a client network.
  • one or more resource instances may be allocated to the virtualized private network. Note that other resource instances may remain available on the provider network for the use of other clients. A range of public IP addresses may also be allocated to the virtualized private network.
  • one or more networking devices may be allocated to the virtualized private network.
  • a virtualized private network may include a public gateway that enables resources within the virtualized private network to communicate directly with other entities (e.g., network entities) via an intermediate network, and vice versa, instead of or in addition to via a private communications channel.
  • a virtualized private network may be, but is not necessarily, subdivided into two or more subnets (not shown).
  • one or more VMs may be configured to access a client network over a private communications channel through a private gateway (e.g., via a network interface that is configured for communication between the VM and a client device) and to access other network entities over an alternate communications channel through a public gateway.
  • a private gateway e.g., via a network interface that is configured for communication between the VM and a client device
  • the client may assign particular client public IP addresses to particular resource instances in a virtualized private network.
  • a network entity on an intermediate network may then send traffic to a public IP address published by the client; the traffic may be routed, by the provider network, to the associated resource instance. Return traffic from the resource instance may be routed, by the provider network, back to the network entity over the intermediate network.
  • routing traffic between a resource instance and a network entity may require network address translation to translate between the public IP address and the private IP address of the resource instance.
  • At least some embodiments may allow a client to remap public IP addresses in a client's virtualized private network to devices on the client's external network.
  • the network may determine that the destination IP address indicated by the packet has been remapped to an endpoint on an external network and handle routing of the packet to the respective endpoint, either via a private communications channel, an alternate communications channel, or an intermediate network.
  • Response traffic may be routed from the endpoint to the network entity through the provider network, or alternatively may be directly routed to the network entity by the client network. From the perspective of the network entity, it may appear as if the network entity is communicating with the public IP address of the client on the provider network. However, the network entity may actually be communicating with the endpoint on the client network.
  • a service provider may employ one of the example provider networks described above (or another suitable provider network environment) to implement a hosted desktop service in a cloud computing environment.
  • a customer may 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 may then provide access to those virtual desktop instances to one or more end users (e.g., through a client application).
  • an administrator within an organization or enterprise may set up an account with a service provider, may contract with the service provider to set up some number of virtual desktop instances, and (once the virtual desktop instances are set up), may provide credentials for accessing these virtual desktop instances.
  • one or more end users may launch a client application on their a client device (e.g., a computer, tablet device, or other mobile device) and enter the credentials for the virtual desktop instance, after which they may be logged into a virtual desktop environment.
  • a client device e.g., a computer, tablet device, or other mobile device
  • the virtual desktop environment is implemented by virtualized resource instances in the cloud computing environment, it may appear to the end user as if it were a local desktop and it may operate as if it were an independent computer to which the user is connected.
  • the virtual desktop environment may provide access to productivity software and other software programs to which the user would typically have access if the user were logged onto a physical computer owned by the organization or enterprise.
  • these virtual desktop instances may be intended to replace a desktop computer, e.g., they may be intended to run the same software programs that a member of the organization or enterprise on whose behalf they were instantiated and configured would access on a desktop computer in an office setting (e.g., applications that perform end-user productivity tasks). Note that these applications may or may not be stand-alone applications.
  • each of the virtual desktop instances (and/or the applications running thereon) may be part of the active directory framework of the organization or enterprise and may be able to access shared files or other resources on the existing network of the organization or enterprise once the credential presented by the user upon logging into the virtual desktop instance have been authenticated.
  • a computing resource instance manager may implement some or all of the techniques described herein for managing the resources that implement a virtual desktop instance, both when a client is connected to the virtual desktop instance and when no client is connected to the virtual desktop instance.
  • these techniques may include intelligently dropping unconnected sessions (e.g., shutting down the underlying computing resource instance for the virtual desktop instance) while maintaining data for the virtual desktop instance in a storage volume that is uncounted from the underlying computing resource instance). This may allow the service provider to more efficiently manage its resources (e.g., if capacity becomes constrained, or simply to avoid incurring costs for resources that are not being used).
  • the systems described herein may provide a high degree of availability to customers and a good customer (and/or end user) experience when connecting or reconnecting to a virtual desktop instance, while allowing the service provider to reclaim resources when they are not being used (e.g., when the customer or end user is not connected).
  • the service provider may implement a connection-based and/or "time bucket" based approach to managing resources for virtual desktop instances, which may or may not carry over into its approach to billing customers for those virtual desktop instances.
  • the service provider when the service provider (or a computing resource instance manager on the service provider network) detects that there is no user connected to a particular virtual desktop instance, the service provider (or computing resource instance manager) may, after a certain number of minutes of inactivity (according to a configurable and/or predefined threshold), shut down the underlying computing resource instance. As previously noted, when the computing resource instance is shut down, the storage volumes for the virtual desktop instance may still be maintained, but may be detached (unmounted) from the virtual desktop instance and the computing resource instance. In some embodiments, if a user reconnects to a virtual desktop instance was previously shut down, the service provider (or computing resource instance manager) may start the computing resource instance back up and attach the appropriate storage volumes (e.g., on-demand).
  • the appropriate storage volumes e.g., on-demand
  • the service provider may track when each virtual desktop instance is "in use", meaning that a customer (e.g., an end user in a service provider customer organization) is logged in/connected (e.g., through a client) to the virtual desktop instance.
  • the service provider (or computing resource instance manager) may measure the amount of time (e.g., the number of hour-long time buckets) during which a user is connected, regardless of whether they are actually using the resources to perform a task, and the amount of time (e.g., the number of hour-long time buckets) during which the virtual workspace is active, but the user is not connected to the virtual desktop instance.
  • the customer organization may be billed differently (e.g., charged different amounts) for the periods during which a user is connected than for the periods during which the virtual workspace is active, but the user is not connected to the virtual desktop instance.
  • a virtual desktop instance may be considered disconnected (and its underlying computing resource instances eligible to be shut down) only if the connection has been broken from the client side. In other embodiments, a virtual desktop instance may be considered to be effectively disconnected due to inactivity.
  • the method may include receiving (at a service provider) a request from a client to connect to a virtual desktop instance on behalf of a customer or a particular end user (e.g., a request to log into a virtual desktop instance).
  • the method may include the service provider (e.g., resource management logic on the service provider network) provisioning computing resources and storage resources for the virtual desktop instance, if it has not already been provisioned, as in 520. For example, if this is the first time a login request has been received for the virtual desktop instance, the service provider may need to provision and configure virtualized computing resources and/or storage resources to implement the virtual desktop instance.
  • the method may also include starting up the virtual desktop instance (e.g., booting up the underlying computing resources and attaching the storage resources for the virtual desktop instance) and starting a virtual desktop session on the virtual desktop instance, as in 530.
  • the method may include receiving a request from the client to disconnect from the virtual desktop instance, as in 540.
  • the method may include the service provider shutting down the computing resources for the virtual desktop instance after the client disconnects (but not necessarily immediately), in accordance with a resource management policy, as in 550.
  • the resource management policies may include a policy specifying criteria for shutting down the computing resources for a virtual desktop instance (e.g., specifying that they should be shut down two hours after a disconnection or only between the hours of 7 pm and 7 am).
  • the method may include receiving a request from a client to reconnect to the virtual desktop instance, as in 560.
  • the request may be received from a client on same machine as the one from which a previous connection request was received or from a client on another machine through which an end user accesses the virtual desktop instance.
  • the method may include restarting the computing resources for the virtual desktop instance and starting a new virtual desktop session on the virtual desktop instance, as in 570. Note that, in some embodiments, the operations illustrated in 540 - 570 may be repeated as additional requests to disconnect from and reconnect to the virtual desktop instance are received on behalf of the customer or a particular end user.
  • the service provider may employ different mechanisms to determine whether or not there is a connection to a particular virtual desktop instance. For example, in some embodiments, the service provider (or computing resource instance manager) may measure the number of bytes (or the rate) of communication traffic flowing over the network interface to determine whether or not the user is using the virtual desktop instance. In some embodiments, the streaming protocols include two- way communication channels, and the service provider may send information down to the client device representing the output of the pixels. In this example, if a user is watching a video, that pixel data may have a very high change rate.
  • the service provider may also get information back from the client (e.g., mouse clicks and keyboard inputs) which, even if they are encrypted, may provide statistics for determining activity or inactivity on the virtual desktop instance.
  • the service provider (or computing resource instance manager) may look at heuristics on the total number of packets, the volume at which they are transmitted, etc., and may determine whether an observed pattern or characteristic of the traffic matches a known (or previously observed) pattern or characteristic for activity or inactivity on a virtual desktop instance. If it matches a known (or previously observed) pattern or characteristic for inactivity, the virtual desktop instance may be considered effectively disconnected and its underlying computing resource instances may be eligible to be shut down (in accordance with an applicable shutdown policy).
  • a session gateway may be established for that session.
  • a session gateway component may provide a tunnel for one or more virtual desktop sessions, and may detect when those sessions are dropped or otherwise terminated.
  • the presence or absence of an active session on a particular virtual desktop instance may provide a clear picture of whether or not a client is connected to the virtual desktop instance.
  • a user may be considered to be connected to a virtual desktop instance (e.g., to have an active session on a virtual desktop instance), if they have a logon session on the virtual desktop instance at the time of a detection process.
  • there may be multiple protocols supported by the service provider system each of which uses a different mechanism to detect an active session.
  • each virtual desktop instance may include a software agent that enables the streaming of screen pixels from the virtual desktop instance.
  • the agent may support two types of login methods: a standard mode and a console mode. The agent may emit session statistics every second, one of which is a property representing the duration of a session in seconds.
  • a second software agent on the virtual desktop instance may expose an API through which this information may be obtained to determine whether or not there is an active session on a particular virtual desktop instance.
  • This API may be invoked by a monitoring service at regular intervals, and the data that is retrieved may be provided to the user or customer organization, in some embodiments.
  • each virtual desktop instance may house an agent that enables the streaming of screen pixels from the virtual desktop instance.
  • This agent may create a pipe to enable inter-process communication between a WebRTC agent and a second software agent.
  • the WebRTC agent may emit messages relevant to the health of the virtual desktop instance and an active session on the virtual desktop instance for a user.
  • the second agent may attach to the pipe, read these messages, and respond to API invocations made by a monitoring service to determine the health state of the virtual desktop instance and/or the presence (or absence) of an active session for the user.
  • a virtual desktop instance from the customer's virtual private cloud.
  • An agent on each virtual desktop instance may query an operating system level audit account to detect connection (login) and disconnection (logoff) attempts (events). The logon types for these events may be used to distinguish between console mode and standard mode.
  • this agent may serve as the single point of contact for various monitoring services. In such embodiments, this agent may also perform the functions described as being performed by the "second software agent" in the other two protocols.
  • the method may include a client connecting to a virtual desktop instance that is implemented by service provider resources on behalf of an end user.
  • the method may include an agent of the service provider (e.g., logic implemented on service provider resources) beginning to monitor communication channels (e.g., two-way communication channels) between the client and the resources that implement the virtual desktop instance, as in 620.
  • the method may include the agent collecting information about the number of packets transmitted, the rate of packet transmissions, and/or other activity indicators and heuristics, as in 630.
  • the method may include the service provider applying one or more policies to determine if and when to shut down the computing resources for the virtual desktop instance in response to the explicit disconnection or apparent inactivity (as in 660).
  • the agent may monitor two-way streaming data and compare the observed traffic patterns to known or previously observed patterns of activity or inactivity to determine whether or not the end user is actively using the virtual desktop instance.
  • the method may include the agent continuing to collect information about the number of packets transmitted, the rate of packet transmissions, and/or other activity indicators and heuristics and/or the gateway component watching for an indication of an explicit disconnection. This is illustrated in FIG. 6 by the path from the negative exit of 640 to 650 and from the negative exit of 650 to 630.
  • the gateway component and the agent on the service provider may operate in parallel.
  • the service provider may implement a gateway component (such as that described herein) or an agent that monitors communication channels, but may not implement both of these components.
  • the systems described herein may, in various embodiments, implement more, fewer, or different mechanisms for detecting that a client has disconnected from a virtual desktop instance or has effectively disconnected from a virtual desktop instance through inactivity than those described herein.
  • the service provider may apply some intelligence and/or machine learning in order to decide whether and/or when to shut down the computing resource instances for a virtual desktop instance in response to a disconnection by the client.
  • decisions may be dependent on time-based shutdown criteria.
  • the shutdown criteria may specify how long the client has to be disconnected from the virtual desktop instance before the underlying computing resource instance is shut down.
  • the shutdown criteria may specify that no computing resource instances are shut down between 8 am and 6 pm, even if the user disconnects from the virtual desktop instance, or may specify that there is a longer threshold before the computing resource instance is shut following a disconnection down during those hours.
  • Some embodiments of the systems described herein may support the use of customer- defined resource management policies, which may include customer-defined shutdown policies. This may allow the customer (or an end user within a customer organization) more control over the state of the resources used to provide services to the customer. For example, in some embodiments, an IT administrator within a service provider customer organization may be able to specify criteria for when and if computing resource instances should be shut down in response to a disconnection from a virtual desktop instance.
  • shutdown preferences may be set up by an IT administrator for the virtual desktops that are hosted on behalf of their end users.
  • the IT administrator may define a policy specifying that the computing resources for a virtual desktop instance should be shut down after two hours following a disconnection by an end user (e.g., because the IT administrator does not want to pay a high rate for the virtual desktop instance during a time period in which it is not being used). Being able to specify how long the computing resource instance should continue to run after a disconnection may allow the IT administrator to grant the end users leeway to disconnect, go to a meeting in a different room and reconnect without the computing resource instance shutting down in between.
  • an IT administrator may delegate at least some control over resources to their end users.
  • the IT administrator may allow at least some end users to define shutdown policies or shutdown criteria for their own virtual desktop instances.
  • a resource management policy or shutdown policy may explicitly define a schedule for shutting down computing resource instances for virtual desktop instances.
  • an end user may define a schedule for shutting down and/or restarting a computing resource instances for a virtual desktop instance if the end user knows in advance when they will be connecting to and/or disconnecting from the virtual desktop instance.
  • FIG. 7 One embodiment of a method for determining whether and/or when to shut down the computing resource instance(s) for a virtual desktop instance by applying one or more shutdown policies is illustrated by the flow diagram in FIG. 7.
  • the service provider system may support the specification of shutdown criteria by an IT administrator of the customer organization on whose behalf the virtual desktop instance is instantiated and/or by an end user.
  • the service provider may allow the IT administrator to select or set shutdown policies for their organization and/or to delegate the selection or setting of a shutdown policy to an individual end user (e.g., for a specific virtual desktop instance that is implemented on their behalf).
  • the method may include a service provider (or resource management logic implemented on the service provider network) determining that a client has disconnected from a virtual desktop instance implemented by computing and storage resource instances on the service provider network.
  • the method may include the service provider applying these policies.
  • the end user or IT administrator may have defined one or more conditions under which the underlying computing resource instance(s) for the virtual desktop instance should be shut down following a disconnection.
  • the method may include the service provider applying one or more default shutdown policies of the service provider, as in 740.
  • the method may include the service provider keeping the computing resource instance(s) for the virtual desktop instance active. This is illustrated in FIG. 7 by the path from the positive exit of 750 to 780. If the applicable shutdown criteria is met (shown as the positive exit from 760), the method may include shutting down the computing resource instance(s) for the virtual desktop instance, as in 790.
  • the method may include waiting for the time-based criteria to be met before shutting down the computing resource instance(s). This is illustrated in FIG. 7 by the negative exit of 760, and the feedback from the positive exit of 770 to 760. In this case, once the time-based criteria is met, the method may include shutting down the computing resource instance(s) for the virtual desktop instance, as in 790.
  • the method may include the service provider keeping the computing resource instance(s) for the virtual desktop instance active, as in 780.
  • the system may not support all of these types of shutdown policies (e.g., it may not support a hierarchy of shutdown policies) or may support more, fewer, or different mechanisms for determining whether and/or when to shut down the computing resource instance(s) for a virtual desktop instance.
  • the service provider may tracking when a user if connected to a virtual desktop instance and when the user is disconnected from the virtual desktop instance, and may identify patterns of usage for the virtual desktop instance (new patterns, common patterns, or previously observed patterns).
  • the patterns may, in turn, be used as inputs for building predictive models (e.g., on end user basis or customer-wide) for shutting down and restarting computing resource instances with a goal to never have a computing resource instance for a virtual desktop instance be in a shutdown state when a user tries to connect to and/or a goal to maximize the amount of time (e.g., the number or percentage of hours) that a computing resource instance for a virtual desktop instance is running with a connection rather than without a connection.
  • the information collected by the service provider (or computing resource instance manager) may also be used as inputs to a billing mechanism, as described herein. For example, connections to and/or disconnections from a virtual desktop instance may trigger various types of billing events, in some embodiments.
  • the service provider may identify, in the collected data, a pattern in which a user typically reconnects frequently throughout the work day. In this example, even if the user disconnects from the virtual desktop instance, the service provider (or computing resource instance manager) may leave the computing resource instance active (e.g., until 6:00). In another example, if the service provider (or computing resource instance manager) identifies, in the collected data, a pattern in which a user only disconnects once a day does not reconnect for the rest of the day, then when the user disconnects from the virtual desktop instance, the service provider (or computing resource instance manager) may immediately shut down the computing resource instance for that virtual desktop instance.
  • the service provider may, based on the collected data, generate a model for performing a predictive (proactive) shutdown and/or restart, based on observed usage patterns. For example, if the service provider
  • the service provider may, based on that pattern set, decide to predictively (proactively) boot up this virtual desktop instance every weekday (or work day) at 8 am (e.g., an hour before the user gets in) and to shut it down every weekday (or work day) at 6 pm.
  • the service provider might not charge them at a connection-based rate until they are actually connected (so the service provider may be taking an expense risk in this case), but it may be worth the expense risk to give the user a great experience, i.e., a fast login time.
  • the service provider (or computing resource instance manager) may shut down the computing resource instance automatically and may restart (reboot) it automatically, but the user will not know that it was shut down (and that their applications were closed) and then restarted for them. The user will only know that they experience a fast login every day.
  • a user who is connected to a virtual desktop instance at 10:00 in the morning on a particular day may go to a meeting and may not reconnect until 3 :00 in the afternoon, and then may disconnect at 6:00 in the evening.
  • the user's connection/disconnection patterns may vary all over the day, and may be different from day to day.
  • any predictive model is probably going to have a very low confidence interval.
  • the service provider or computing resource instance manager
  • the service provider may apply a default shutdown policy (e.g., waiting for two following a disconnection before shutting down the computing resource instance, or waiting until after 6 pm before shutting down the computing resource instance), or may apply some other low confidence approach that allows the service provider to reclaim capacity without having to take a risk.
  • the service provider may generate and apply a predictive policy for when to shut down a computing resource instance, may generate and apply a predictive policy for when to restart a computing resource instance, or both.
  • the method may include provisioning a computing resource instance and storage resources for a virtual desktop instance on behalf of a service provider customer.
  • the method may include beginning to monitor, and collecting data about, connections to and disconnections from the virtual desktop instance as in 820. For example, such monitoring and collection activities may be performed by logic on the service provider system.
  • the method may include identifying new and/or common usage patterns for the virtual desktop instance in the most recently collected data and/or in data that has been accumulated over a longer period of time (e.g., over many days, week, and/or virtual desktop sessions), as in 830.
  • the method may also include developing or refining a predictive usage model for the virtual desktop instance based, at least in part, on the identified usage patterns and developing or refining a shutdown policy based on that predictive usage model, as in 840.
  • the predictive usage model may identify times at which a user is predicted to connect to the virtual desktop instance (and at which it may be beneficial for the underlying computing resource instance to already be active) and/or times at which the user is predicted to be disconnected from the virtual desktop instance (and at which it may be safe to shut down the underlying computing resource instance).
  • the method may include continuing to monitor, and to collect data about, connections to and disconnections from the virtual desktop instance (as in 860), and using that information to refine the predictive usage model and/or shutdown policy (e.g., repeating the operations shown as 830 - 840). This is illustrated in FIG. 8 by the feedback from 860 to 830.
  • the method may include the service provider de- provisioning the service provider resources for the virtual desktop instance. This is illustrated in FIG. 8 by the feedback from the negative exit of 850 to 870.
  • information about the identified usage patterns and/or the predictive usage model may be provided to the customer (e.g., to an IT administrator within the customer organization and/or to the end user).
  • the machine learning approach may be based, at least in part, on a fitness function that seeks to avoid having the virtualized computing resource instance in a shutdown state when a client requests a connection to the virtual desktop instance and/or a fitness function that seeks to minimize the amount of time that the virtualized computing resource instance is active but no client is connected to the virtual desktop instance.
  • a fitness function may specify that the computing resource instance for a virtual desktop instance should always be re-launched (or remain active) before the end user needs to connect to the virtual desktop instance.
  • Another fitness function may specify that the computing resource instance for a virtual desktop instance is active for no more than a certain number of hours when no user is connected to it. Between those two fitness functions, the service provider (or computing resource instance manager) would like to be able to predict when the user is going to connect, to launch the computing resource instance prior to that point, and then to shut down the computing resource when appropriate.
  • a computing resource instance for a virtual desktop instance when a computing resource instance for a virtual desktop instance is shut down (e.g., in accordance with a shutdown policy), all of the data for the virtual desktop instance (e.g., for the applications that were running on the virtual desktop instance) may continue to be maintained on one or more storage volumes that are associated with the computing resource instance for the use of the virtual desktop instance, although they may be detached (unmounted) from the computing resource instance.
  • the computing resource instance may be rebooted and the storage volumes may be reattached (mounted) for the use of the virtual desktop instance. In this way, when the user reconnects, their applications may be re-launched as well.
  • a new computing resource instance (e.g., an instance of the same type as the previous computing resource instance or of another type) may be started for the virtual desktop instance elsewhere and the same storage volume may be attached (mounted) to that new instance.
  • the method may include, in response to a connection request, provisioning and starting up a computing resource instance for a virtual desktop instance and attaching one or more storage volumes to the computing resource instance.
  • the method may include, at some point later, detecting that the user has disconnected from the virtual desktop instance, as in 920.
  • the method may include disconnecting and unmounting the storage volumes from the computing resource instance for the virtual desktop instance, but continuing to maintain the storage volumes for the virtual desktop instance on the service provider network, as in 930.
  • the method may also include shutting down the computing resource instance for the virtual desktop instance, as in 940.
  • the method may include, at some point later, detecting that the user has reconnected to the virtual desktop instance, as in 950.
  • the method may include restarting the computing resource instance for the virtual desktop instance (as in 960) and reattaching and remounting the storage volumes to the computing resource instance for the virtual desktop instance (as in 970).
  • the user may be able to specify that the virtual desktop instance be hosted on a different computing resource instance type. For example, the user may 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 picking an instance type from a drop-down menu of a client-side GUI). In some embodiments, once the newly selected computing resource instance has been started up and configured to host the virtual desktop instance, this may be the default instance type the next tie the user reconnects following a shutdown.
  • the user In embodiments in which the user is going to be billed at a higher rate during time periods in which they are connected to the virtual desktop instance (e.g., on an hourly basis), if the user knows that they are going to be performing a task that requires better performance, they may upgrade the computing resource instance for their virtual desktop instance to a higher performance (and more expensive) instance type for that time period, and then go back to the previous instance type when they don't need the higher performance.
  • the user is being charged by the month regardless of how long they are connected to the virtual desktop instance or are disconnected from it, they might want to keep a high performance computing resource instance active for their virtual desktop instance all month if they will (or might) need it at some point during the month.
  • the user may be able to specify a different storage capacity when they reconnect to their virtual desktop instance. For example, they may decide that they need more storage capacity than was originally provisioned for their virtual desktop instance.
  • the service provider or computing resource instance manager
  • the amount of storage capacity that is provisioned for a virtual desktop instance may be fixed and/or may be dependent on the computing resource instance type.
  • the method may include receiving (e.g., by a service provider) from a user (e.g., through a client), a request specifying a computing resource instance type, a storage volume capacity, and a shutdown policy for a virtual desktop instance.
  • the method may include provisioning and starting up a computing resource instance of the specified type for the virtual desktop instance and attaching one or more storage volumes (e.g., enough to meet the specified capacity) to the computing resource instance, as in 1020.
  • the method may include, at some point later, the service provider system detecting that the user has been disconnected from the virtual desktop instance, as in 1030.
  • the method may include, in accordance with the shutdown policy, disconnecting and unmounting the storage volumes from the computing resource instance, and shutting down the computing resource instance for the virtual desktop instance, as in 1040.
  • the method may also include, at some point later, the service provider system receiving a request to reconnect to the virtual desktop instance, as in 1050. If the request specifies a different computing resource instance type or storage capacity (shown as the positive exit from 1060), the method may include restarting or booting up a computing resource instance of the specified type (as in 1070) and reattaching and remounting the storage volumes, while adding or removing capacity, if applicable (as in 1075).
  • the method may include restarting the computing resource instance for the virtual desktop instance (as in 1080) and reattaching and remounting the storage volumes to the computing resource instance (as in 1085).
  • the service provider may tradeoffs to be made by the service provider between the expense costs associated with keeping computing resource instances active when they are not being used and providing customers with great experiences (e.g., fast connections every time they log in), especially when operating under a connection-based or time bucket based billing model in which they do not charge (or do not charge as much) when the resources are not being used (e.g., when no user is connected to the virtual desktop instance).
  • the service provider may need to manage their resources such that their costs are also less (in similar proportions).
  • that may be facilitated by shutting down the computing resource instances for unconnected virtual desktop instances so that those resources can be used for other purposes (e.g., for other virtual desktop instance).
  • the service provider (or computing resource instance manager) decides when to leave a computing resource instance running (e.g., using a default or predictive model) then the service provider may absorb that cost.
  • the customer may be charged (e.g., at the connected rate) for all of the time that the computing resource instance remains active, even after a disconnection. For example, if the customer defines shutdown criteria specifying that the computing resource instance should not be shut down until two hours after a disconnection, the customer may have to pay at the connected rate for the extra two hours after the disconnection.
  • the system may implement a hybrid approach, in which there may be some default policies defined by the service provider and/or by the IT administrator of the customer organization, but these default policies may be overridden in certain scenarios (e.g., by a user that stays connected longer or who is granted permission from the IT administrator to apply a different policy.
  • the customer are billed on a monthly basis for their virtual desktop instances as long as they are active (and regardless of whether, how often, and/or for how long any end user is connected to the virtual desktop instance). For example, if a customer created a virtual desktop instance on the 20 th of the month, for the rest of that month (e.g., from the 20 th to the 30 th of the month) they will be charged on a pro-rated basis. However, if they have a virtual desktop instance on the 1 st of the month, they may be charged for that virtual desktop instance for the entire month even if they delete it on the 2 nd of the month.
  • the systems described herein may, instead, employ a time bucket based approach to resource management and/or billing for virtual desktop instances, which may be applied in combination with a connection-based approach to resource management and billing. For example, in an embodiment in which customers are charged by the hour for virtual desktop instances that are hosted on behalf of their end users,
  • customers may be charged for a virtual desktop instance based on two different dimensions:
  • the service provider may keep track of how long the end users are using the virtual desktop instance and may provide that information to a billing mechanism as the amount of time (or the number of time buckets) for which the customer should be charged at connected rate.
  • the service provider may keep track of how long the end users are not using the virtual desktop instance and may provide that information to a billing mechanism as the amount of time (or the number of time buckets) for which the customer should be charged at connected rate.
  • the non-connected rate may be much lower than the connected rate, and may essentially be a charge for maintaining the virtual desktop instance and associated storage volumes on the customer's behalf.
  • the connected rate may be multiple cents (or tens of cents) per hour, but the non-connected rate may be a fraction of a cent per hour.
  • the combined cost to the customer for the time billed at the connected rate and the time billed at the non-connected rate may be much less than what they would have paid under a monthly billing approach.
  • a customer may be able to specify that they do not need the service provider to maintain the storage volumes associated with a virtual desktop instance after being disconnected from it (e.g., if they are not planning to reconnect to the virtual desktop instance after a particular virtual desktop session, if they are only planning 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 for the virtual desktop instance between virtual desktop sessions).
  • the service provider may disconnect the storage volumes that are associated with the virtual desktop instance upon detecting inactivity or an explicit disconnection and may re-allocate them for other uses (e.g., after deleting any information that is specific to the virtual desktop instance).
  • a service provider system may employ a time bucket based approach to resource management and/or billing for virtual desktop instances, which may be applied in combination with a connection-based approach to resource management and billing for time buckets other than hourly time buckets. For example, a this approach may be applied to time buckets of one minute, a day, one week, one month, or any other predefined time period, in different embodiments.
  • the systems described herein may be able to detect inactivity for a virtual desktop instance and may apply a shutdown policy as if the virtual desktop instance were effectively disconnected. For example, if a user walks away from their laptop and it stays connected to their virtual computing instance all weekend (e.g., when they are not using it), the most customer-centric thing for the service provider to do may 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 at the connected rate.
  • the service provider may be able to determine when an end user is streaming something to a virtual desktop instance from an entity other than the actual virtual desktop instance client. For example, an IT administrator may, in response to an end user reporting a problem with their virtual desktop instance, connect to the virtual desktop instance (for trouble-shooting) from a streaming solution, such as the Remote Desktop Protocol (RDP) developed by Microsoft Corporation.
  • RDP Remote Desktop Protocol
  • component of the virtual desktop instance may be able to identify when such a session is active, and the service provider may be able to bill during that time, even though monitoring mechanisms described earlier may not detect that activity.
  • the IT administrator needs to trouble-shoot a virtual desktop instance, they may be able to request that (at least temporarily) the computing resource instance remain active, regardless of whether any shutdown policies would otherwise be applicable.
  • connection-based resource management for virtual desktop instances may be applied in systems in which the computing resource instances are pooled. For example, they may be applied within each of multiple pools of resources (e.g., customer-specific pools of resources) or within one large pool of resources that is managed on the service provider side, in different embodiments. Management of virtual desktop instance pools
  • a virtual desktop service may provide virtual desktop instances to clients.
  • the virtual desktop service may reserve pools of virtual desktop instances for particular clients.
  • the pooled instances may be provided along with other types of virtual desktop instances as discussed above with respect to FIG. 5 through FIG. 10, such as instances that are available on demand to any client and charged on an hourly rate.
  • FIG. 11 is a block diagram illustrating an example provider network that provides a virtual desktop service with a virtual desktop instance pool to a client organization, according to at least some embodiments.
  • a provider network 1100 may 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 may provide clients with access to virtual desktop instances as discussed above, e.g., with respect to FIG. 3.
  • the virtual desktop service 1120 may instantiate and manage, on behalf of clients, a plurality of virtual desktop instances such as instances 1130A and 1130B as well as instances 1130Q and 1130R through 1130Z.
  • a set of the virtual desktop instances may be reserved in a virtual desktop instance pool 1131.
  • the client organization may represent a customer to which the provider network permits access to one or more services and/or resources (e.g., access to virtualized computing resources).
  • the client organization may represent a business organization, governmental organization, non-profit organization, educational organization, or any other suitable group of individuals.
  • the client organization may include end users (also referred to herein as users) who are permitted to access the services and/or resources of the provider network 1100.
  • the end users may use client devices, such as devices 1160 A and 1160B through 1160N through 1160Z, to access the provider network 1100.
  • the client devices 1160A-1160Z may be user-specific or may be shared among multiple users, e.g., using user-specific access credentials.
  • the client devices 1160A-1160Z may be linked in one or more client networks 1150.
  • the client network(s) 1150 may be communicatively coupled to the virtual desktop service 1120 of the provider network 1100. Any of the client devices 1160A-1160Z may be implemented using the example computing device shown in FIG. 18.
  • the virtual desktop instance pool 1130 may have a defined quantity of slots, e.g., slots 1 and 2 through N.
  • the client organization may submit or agree to the number N of slots, e.g., using any suitable programmatic interface and/or user interface for the provider network 1100.
  • the client organization may agree to pay the provider network 1100 for the number N of virtual desktop slots for a particular period of time. For example, the client organization may agree to pay the provider network for one hundred virtual desktop slots on a monthly basis (and potentially recurring per month until canceled or modified by either party).
  • the number N of virtual desktop slots may represent a fixed or predetermined quantity of slots for virtual desktops that the provider network agrees to provide at substantially all times during the course of the agreement.
  • Each of the virtual desktop slots may represent a virtual desktop instance that is connected to a client device in the client organization (e.g., a connected virtual desktop instance), a virtual desktop instance that is disconnected but still running (e.g., a disconnected virtual desktop instance, also referred to herein as an unused virtual desktop instance), or an empty slot (e.g., a slot where no virtual desktop instance is running, either connected or disconnected).
  • the client organization may pay for all of the slots regardless of which slots are used or how often any slot is used.
  • the number of end users at the client organization e.g., users who have access to the virtual desktop slots
  • a particular slot may be used by different end users at the client organization at different points in time.
  • the pool 1131 of virtual desktop instances may be reserved for the client organization.
  • the pool 1131 may include virtual desktop instances that are running and connected to users of the client organization, such as instances 1130A and 1130B.
  • the pool 1131 may also include virtual desktop instances that are running and not connected to users.
  • one or more slots in the pool may be empty (i.e., not filled with a running virtual desktop instance), such as slot N.
  • Reserving the pool of instances generally includes excluding other clients from accessing the instances during the period of time for which the client organization has reserved access.
  • the number of instances in the pool 1131 may not exceed the number N of virtual desktop slots for the client organization.
  • the pool 1131 of instances may include running instances in all (or nearly all) of the N slots at substantially all times following an initialization stage. In one embodiment, the pool 1131 may be initialized with all the N slots empty, and running instances may be added to the pool when connection requests are received or anticipated. Slots in the pool
  • 1131 with disconnected instances may be reclaimed, e.g., by restarting the instance or otherwise replacing it with a fresh instance that is running and ready for a new connection.
  • instances may be provisioned for access by client devices only when connection requests are received from those devices.
  • Disconnected instances or the computing resources used to implement them may be returned to a set of available instances and/or resources outside of the pool 1131.
  • the instances 1130Q-1130Z may represent a larger set of instances available to multiple client organizations, and the instances 1130A-1130B may be reserved from that larger set of instances in response to connection requests from client devices 1160A and 1160B that belong to the client organization associated with the pool 1131.
  • a set of underlying resources in the provider network 1100 may be shared among multiple pools of virtual desktop instances for the same client or for multiple clients.
  • a virtual desktop instance may be implemented on behalf of a given end user.
  • a service provider network 1100 may include a plurality of computing nodes (for example, computing devices as shown in FIG. 18) that collectively provide a virtual desktop service to one or more client organizations or other users of the provider network.
  • the provider network 1100 may implement a virtualized computing resource instance executing on one of the computing nodes, and the virtualized computing resource instance may implement the virtual desktop instance as discussed above with respect to FIG. 1 through FIG. 4.
  • One or more applications may be installed on the virtual desktop instance and executed using the virtualized computing resource instance.
  • the virtual desktop service may maintain the virtual desktop, e.g., by maintaining data such as configuration data and application data usable to generate a graphical user interface (GUI) for the virtual desktop instance and run the application(s).
  • GUI graphical user interface
  • a virtual desktop may include a graphical depiction of a set of resources associated with the virtual desktop instance (e.g., one or more graphical indicators of applications, one or more windows associated with applications, one or more interface elements for browsing files or folders, one or more interface elements for browsing available applications or switching running applications, and so on).
  • a client device 1 160 A may access a virtual desktop 1135A via the virtual desktop instance 1130A
  • a client device 1160B may access a virtual desktop 1135B via the virtual desktop instance 1130B.
  • the virtual desktops 1135A and 1135B may be configured in a similar manner (e.g., with the same set of applications) or in a different manner (e.g., with a different set of applications).
  • Each of the virtual desktop instances 1130A and 1130B may include a respective root drive and also a respective data drive that is specific to the user of the corresponding client device.
  • FIG. 12 is a block diagram illustrating further aspects of the example provider network that provides a virtual desktop service with a virtual desktop instance pool, including connected and disconnected virtual desktop instances in slots in the pool, according to at least some embodiments.
  • the pool 1131 may include virtual desktop instances that are running and connected to users of the client organization, such as instances 1130A and 113 ON.
  • a connection to an instance may be performed in response to a connection request from a client device associated with a user of the client organization.
  • the virtual desktop service 1120 may receive a connection request from a client device 1160N and respond by providing access to a virtual desktop instance 1130N in slot N.
  • the client device 1160A may access a virtual desktop 1135 A via the virtual desktop instance 1130A
  • the client device 1160N may access a virtual desktop 1135N via the virtual desktop instance 113 ON.
  • the pool 1131 may also include virtual desktop instances that are running but not connected to users, such as instance 1130B.
  • instance 1130B may also include virtual desktop instances that are running but not connected to users, such as instance 1130B.
  • the client device 1160B may disconnect from the virtual desktop instance 1130B to which it was previously connected.
  • a disconnection from an instance may be performed in response to an explicit disconnection request from a client device or based on automatic detection of a disconnection, e.g., as discussed above with respect to FIG. 5 through FIG. 10.
  • the disconnected instance 1130B may be left running and may occupy a slot (e.g., slot 2) in the pool 1131.
  • the disconnected instance 1130B may be left running with an attached data drive associated with the user of the previously connected client device 1160B.
  • connection between the client device 1160B and the instance 1130B may be reinstated more quickly (e.g., without restarting or reprovisioning a virtual desktop instance) in case a connection request is received from the user of the client device 1160B.
  • FIG. 13 is a block diagram illustrating further aspects of the example provider network that provides a virtual desktop service with a virtual desktop instance pool, including providing access to a virtual desktop instance outside the pool to a client device when all slots in the pool have been taken by connected instances, according to at least some embodiments.
  • all of the slots 1-N in the pool 1131 may be consumed by connected instances.
  • all of the slots in the pool 1131 may be used by virtual desktop instances 1130A-1130N that are running and connected to respective client devices 1160A-1160N.
  • the client organization may include more users than the number N of slots in the pool 1131.
  • a new connection request is received from a client device of the client organization while all the N slots in the pool 1131 are completely taken by connected instances, then that user may be denied access to a virtual desktop instance in the pool.
  • a notification of no available capacity in the pool 1131 may be provided to the user.
  • access to the pool 1131 may be denied only at the current point in time, and the user may be put on a waiting list for an available instance in the pool and notified accordingly.
  • the size of the pool 1 131 may be dynamically increased in response to a new connection request when the pool is full of connected instances. Such dynamic modification of the pool size may be performed only if the client organization has an agreement in place to pay additional or increased fees as charged by the provider network 1100.
  • the user may instead be given access to a virtual desktop instance 1130Z outside the pool 1131.
  • the user may be given access to a virtual desktop instance 1130Z that is available on demand and charged on an hourly basis, e.g., the virtual desktop instances discussed above with respect to FIG. 5 through FIG. 10.
  • Such access outside the pool may be granted only if the client organization has an agreement in place to pay appropriate fees as charged by the provider network 1100.
  • FIG. 14 is a block diagram illustrating further aspects of the example provider network that provides a virtual desktop service with a virtual desktop instance pool, including reclamation of disconnected virtual desktop instances in the pool, according to at least some embodiments.
  • client devices 1160A and 1160B may be disconnected from instances 1130A and 1130B, respectively, while client device 1160N may remain connected to virtual desktop instance 1130N.
  • the virtual desktop service 1120 may include a functionality for virtual desktop instance reclamation 1170. Using the functionality for virtual desktop instance reclamation 1170, the virtual desktop service 1120 may reclaim slots in the pool 1131 that are taken by disconnected but running instances.
  • the virtual desktop instance reclamation 1170 may determine, at appropriate points in time, the anticipated rate of the virtual desktop slots being consumed by connected instances.
  • the anticipated rate may represent a growth rate in connected instances or velocity at which the pool 1131 is filling up with connected instances.
  • the anticipate rate may be based (at least in part) on reconnection requests to running instances as well as new connection requests to fresh instances.
  • the virtual desktop instance reclamation 1170 may determine whether the slots are approaching full use by connected instances. Such a determination may be based on any suitable heuristics or thresholds. For example, the virtual desktop instance reclamation 1170 may determine that the pool will fill up within an hour based on the rate of new connection requests.
  • the virtual desktop instance reclamation 1170 may select disconnected instances (if any) for reclamation. Reclamation may also be performed under other suitable circumstances and policies, e.g., when the pool is full of connected instances, a waiting list for new connections is in place, and one of the existing instances is disconnected.
  • One or more of the disconnected instances 1130A and 1130B may be reclaimed.
  • Reclamation of a virtual desktop instance may include restarting the instance with a fresh root drive or otherwise replacing the instance with a fresh instance that has been subjected to any relevant security procedures and is ready for a new connection.
  • Any suitable reclamation policies or criteria may be applied to select one or more disconnected instances for reclamation.
  • disconnected instances may be selected for reclamation based on the duration of instance idleness, e.g., to prioritize maintaining the most recently disconnected instances.
  • disconnected instances may be selected for reclamation based on the anticipated duration of instance restart, e.g., to prioritize maintaining disconnected instances that would take longest to restart.
  • disconnected instances may be selected for reclamation based on the relative rankings or other characteristics of users, e.g., to prioritize maintaining disconnected instances for particular users.
  • one or more instances within the pool 1131 may be indefinitely reserved for access by one or more particular users within the client organization or for users having a particular characteristic; these instances may be left running at all times, whether or not the corresponding user is currently connected, and may not be subject to reclamation.
  • FIG. 15 is a block diagram illustrating further aspects of the example provider network that provides a virtual desktop service with a virtual desktop instance pool, including providing access to a restarted virtual desktop instance in the pool to a client device, according to at least some embodiments.
  • the virtual desktop instance reclamation 1170 may restart the virtual desktop instances
  • a ready instance may represent a virtual desktop instance that is running, that has been through any security procedures, and that is ready for a new connection request from a user.
  • the ready instance may represent a reclaimed instance that has been restarted with a fresh root drive for security purposes.
  • a ready instance may not have a user-specific data drive attached but may be domain joined into the appropriate domain.
  • FIG. 16 is a flow diagram illustrating one embodiment of a method for management of virtual desktop instance pools. As shown in 1610, a number (i.e., a defined quantity) of virtual desktop slots for a client organization may be determined. The client organization may represent a customer to which the provider network permits access to one or more services and/or resources (e.g., access to virtualized computing resources).
  • a number i.e., a defined quantity
  • the client organization may represent a customer to which the provider network permits access to one or more services and/or resources (e.g., access to virtualized computing resources).
  • the client organization may represent a business organization, governmental organization, non-profit organization, educational organization, or any other suitable group of individuals.
  • the client organization may include end users who are permitted to access the services and/or resources.
  • the end users may use client devices to access the provider network.
  • the client devices may be user-specific or may be shared among multiple users, e.g., using user-specific access credentials.
  • the client organization may submit or agree to the number of slots, e.g., using any suitable programmatic interface and/or user interface for the provider network.
  • the client organization may agree to pay the provider network for the number of virtual desktop slots for a particular period of time. For example, the client organization may agree to pay the provider network for one hundred virtual desktop slots on a monthly basis (and potentially recurring per month until canceled or modified by either party).
  • the number of virtual desktop slots may represent a fixed or predetermined quantity of slots for virtual desktops that the provider network agrees to provide at substantially all times during the course of the agreement.
  • Each of the virtual desktop slots may represent a virtual desktop instance that is connected to a client device in the client organization (e.g., a connected virtual desktop instance), a virtual desktop instance that is disconnected but still running (e.g., a disconnected virtual desktop instance), or an empty slot (e.g., a slot where no virtual desktop instance is running, either connected or disconnected).
  • the client organization may pay for all of the slots regardless of which slots are used or how often any slot is used.
  • the number of end users at the client organization e.g., users who have access to the virtual desktop slots
  • a particular slot may be used by different end users at the client organization at different points in time.
  • a pool of virtual desktop instances may be reserved for the client organization.
  • the pool of instances may include virtual desktop instances that are running and connected to users of the client organization along with virtual desktop instances that are running and not connected to users. Reserving the pool of instances generally includes excluding other clients from accessing the instances during the period of time for which the client organization has reserved access.
  • the number of instances in the pool may not exceed the number of virtual desktop slots for the client organization.
  • the pool of instances may include running instances in all (or nearly all) of the slots at substantially all times following an initialization stage.
  • the pool may be initialized with all the slots empty, and running instances may be added to the pool when connection requests are received or anticipated. Slots in the pool with disconnected instances may be reclaimed, e.g., by restarting the instance or otherwise replacing it with a fresh instance that is running and ready for a new connection.
  • a virtual desktop instance may be implemented on behalf of a given end user.
  • a service provider network may include a plurality of computing nodes (for example, computing devices as shown in FIG. 18) that collectively provide a virtual desktop service to one or more client organizations or other users of the provider network.
  • the provider network may implement a virtualized computing resource instance executing on one of the computing nodes, and the virtualized computing resource instance may implement the virtual desktop instance as discussed above with respect to FIG. 1 through FIG. 4.
  • One or more applications may be installed on the virtual desktop instance and executed using the virtualized computing resource instance.
  • the virtual desktop service may maintain the virtual desktop, e.g., by maintaining data such as configuration data and application data usable to generate a graphical user interface (GUI) for the virtual desktop instance and run the application(s).
  • GUI graphical user interface
  • the graphical depiction of a set of resources associated with the virtual desktop instance (e.g., one or more graphical indicators of applications, one or more windows associated with applications, one or more interface elements for browsing files or folders, one or more interface elements for browsing available applications or switching running applications, and so on) and the associated applications may collectively be referred to as a virtual desktop.
  • resources associated with the virtual desktop instance e.g., one or more graphical indicators of applications, one or more windows associated with applications, one or more interface elements for browsing files or folders, one or more interface elements for browsing available applications or switching running applications, and so on
  • the associated applications may collectively be referred to as a virtual desktop.
  • connection request for a virtual desktop instance in the pool may be received.
  • the connection request may be received from a client device associated with an end user of the client organization.
  • the connection request may be received by a virtual desktop service of the provider network over a network connection to the client organization.
  • the connection request may be received using any suitable programmatic interface and/or user interface and may include access credentials of the user of the client organization.
  • the user may be denied access to a virtual desktop instance in the pool.
  • a notification of no available capacity in the pool may be provided to the user.
  • access to the pool may be denied only at the current point in time, and the user may be put on a waiting list for an available instance in the pool and notified accordingly.
  • the user may instead be given access to a virtual desktop instance outside the pool. For example, the user may be given access to a virtual desktop instance that is available on demand and charged on an hourly basis, e.g., the virtual desktop instances discussed above with respect to FIG. 5 through FIG. 10. Such access outside the pool may be granted only if the client organization has an agreement in place to pay appropriate fees as charged by the provider network.
  • a ready instance may represent a virtual desktop instance that is running, that has been through any security procedures, and that is ready for a new connection request from a user.
  • the ready instance may represent a reclaimed instance that has been restarted with a fresh root drive for security purposes.
  • a ready instance may not have a user-specific data drive attached but may be domain joined into the appropriate domain.
  • a virtual desktop instance may be provisioned in one of the slots. Provisioning a virtual desktop instance is discussed above with respect to FIG.
  • provisioning a virtual desktop instance may include booting the instance with a fresh root drive. Again, a ready instance may not have a user-specific data drive attached but may be domain joined into the appropriate domain. As shown in 1670, the virtual desktop instance may be prepared for the user, and the user may be provided access to the instance. Preparing the instance for the user may include attaching a data drive associated with the user to the instance.
  • FIG. 17 is a flow diagram illustrating one embodiment of a method for reclamation of disconnected virtual desktop instances in a pool.
  • a pool of virtual desktop instances may be provisioned, and access to the pool may be provided to a client organization.
  • the pool of instances may include virtual desktop instances that are running and connected to users of the client organization along with virtual desktop instances that are running and not connected to users.
  • the number of instances in the pool may not exceed a number of virtual desktop slots for the client organization.
  • the client organization may submit or agree to the number of slots, e.g., using any suitable programmatic interface and/or user interface for the provider network.
  • the client organization may agree to pay the provider network for the number of virtual desktop slots for a particular period of time.
  • the client organization may agree to pay the provider network for one hundred virtual desktop slots on a monthly basis (and potentially recurring per month until canceled or modified by either party).
  • the number of virtual desktop slots may represent a fixed or predetermined quantity of slots for virtual desktops that the provider network agrees to provide at substantially all times during the course of the agreement.
  • the client organization may pay for all of the slots regardless of which slots are used or how often any slot is used.
  • the number of end users at the client organization e.g., users who have access to the virtual desktop slots
  • a particular slot may be used by different end users at the client organization at different points in time.
  • Each of the virtual desktop slots may represent a virtual desktop instance that is connected to a client device in the client organization (e.g., a connected virtual desktop instance), a virtual desktop instance that is disconnected but still running (e.g., a disconnected virtual desktop instance), or an empty slot (e.g., a slot where no virtual desktop instance is running, either connected or disconnected).
  • the pool of instances may include running instances in all (or nearly all) of the slots at substantially all times following an initialization stage.
  • the pool may be initialized with all the slots empty, and running instances may be added to the pool when connection requests are received or anticipated. Slots in the pool with disconnected instances may be reclaimed, e.g., by restarting the instance or otherwise replacing it with a fresh instance that is running and ready for a new connection.
  • a given client device may be connected to or disconnected from one of the virtual desktop instances in the pool.
  • a connection to an instance may be performed in response to a connection request from a client device associated with a user of the client organization.
  • a disconnection from an instance may be performed in response to an explicit disconnection request from a client device or based on automatic detection of a disconnection, e.g., as discussed above with respect to FIG. 5 through FIG. 10.
  • Either a connection or disconnection may change the composition of the pool, i.e., the numbers of connected instances, disconnected (but running) instances, and empty slots.
  • the anticipated rate of the virtual desktop slots being consumed by connected instances may be determined.
  • the anticipated rate may represent a velocity at which the pool is filling up with connected instances.
  • it may be determined, based on the anticipated rate, whether the slots are approaching full use by connected instances.
  • the determination shown in 1740 may be based on any suitable heuristics or thresholds. For example, it may be determined that the pool will fill up within an hour based on the rate of new connection requests. If so, then as shown in 1750, it may be determined whether there are any disconnected (also referred to as unused) instances in the pool. [0143] If so, then as shown in 1760, one or more of the disconnected instances may be reclaimed.
  • Reclamation of a virtual desktop instance may include restarting the instance with a fresh root drive or otherwise replacing the instance with a fresh instance that has been subjected to any relevant security procedures and is ready for a new connection.
  • Any suitable reclamation policies or criteria may be applied to select one or more disconnected instances for reclamation.
  • disconnected instances may be selected for reclamation based on the duration of instance idleness, e.g., to prioritize maintaining the most recently disconnected instances.
  • disconnected instances may be selected for reclamation based on the anticipated duration of instance restart, e.g., to prioritize maintaining disconnected instances that would take longest to restart.
  • disconnected instances may be selected for reclamation based on the relative rankings of users, e.g., to prioritize maintaining disconnected instances for higher-ranked users.
  • a system comprising:
  • each of the computing nodes comprises at least one processor and a memory, and wherein the client organization comprises a plurality of users;
  • the virtual desktop service is configured to:
  • a method comprising:
  • a computer-readable storage medium storing program instructions computer- executable to perform:
  • a server that implements some or all of the techniques for managing pools of virtual desktop instances as described herein may include a computer system that includes or is configured to access a non-transitory computer-accessible (e.g., computer-readable) media, such as computer system 2000 illustrated in FIG. 18.
  • a non-transitory computer-accessible (e.g., computer-readable) media such as computer system 2000 illustrated in FIG. 18.
  • any or all of the computer system components described herein may be implemented using a computer system similar to computer system 2000 that has been configured to provide the functionality of those components.
  • computer system 2000 includes one or more processors (e.g., processors 201 OA and 2010B through 2010N) coupled to a system memory 2020 via an input/output (I/O) interface 2030.
  • Computer system 2000 further includes one or more network interfaces 2040 coupled to I/O interface 2030.
  • network interfaces 2040 may include two or more network interfaces (including, e.g., one configured for communication between a virtualized computing resource hosted on the computer system 2000 and its clients, and one configured for communication between a virtualized computing resource and external resources, computing systems, data centers, or Internet destinations on networks other than the provider network and a client network on whose behalf the virtualized computing resources are hosted.
  • computer system 2000 may be a uniprocessor 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 processors capable of executing instructions.
  • processors 2010A-2010N may be processors implementing any of a variety of instruction set architectures (ISAs), such as the x86, PowerPC, SPARC, or MIPS ISAs, or any other suitable ISA.
  • ISAs instruction set architectures
  • each of processors 2010A-2010N may commonly, but not necessarily, implement the same ISA.
  • System memory 2020 may be configured to store instructions and data accessible by processor(s) 2010A-2010N.
  • system memory 2020 may be implemented using any suitable memory technology, such as static random access memory
  • SRAM synchronous dynamic RAM
  • SDRAM synchronous dynamic RAM
  • nonvolatile/Flash-type memory any other type of memory.
  • program instructions and data implementing one or more desired functions are shown stored within system memory 2020 as code 2025 and data 2026.
  • I/O interface 2030 may be configured to coordinate I/O traffic between processor 2010, system memory 2020, and any peripheral devices in the device, including any of network interface(s) 2040 or other peripheral interfaces.
  • I/O interface 2030 may perform any necessary protocol, timing or other data transformations to convert data signals from one component (e.g., system memory 2020) into a format suitable for use by another component (e.g., processors 2010A-2010N).
  • I/O interface 2030 may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard, for example.
  • PCI Peripheral Component Interconnect
  • USB Universal Serial Bus
  • I/O interface 2030 may be split into two or more separate components, such as a north bridge and a south bridge, for example. Also, in some embodiments some or all of the functionality of I/O interface 2030, such as an interface to system memory 2020, may be incorporated directly into processors 2010A- 2010N.
  • Network interface(s) 2040 may be configured to allow data to be exchanged between computer system 2000 and other devices 2060 attached to a network or networks 2050, such as other computer systems or devices as illustrated in the figures, for example.
  • network interface(s) 2040 may support communication via any suitable wired or wireless general data networks, such as types of Ethernet network, for example.
  • network interface(s) 2040 may support communication via telecommunications/telephony networks such as analog voice networks or digital fiber communications networks, via storage area networks such as Fibre Channel SANs, or via any other suitable type of network and/or protocol.
  • system memory 2020 may be one embodiment of a computer- accessible medium configured to store program instructions and data as described above for implementing various embodiments of the techniques for managing resources for virtual desktop instances described herein.
  • program instructions and/or data may be received, sent or stored upon different types of computer-accessible media.
  • a computer-accessible (e.g., computer-readable) medium may include non-transitory storage media or memory media such as magnetic or optical media, e.g., disk or DVD/CD coupled to computer system 2000 via I/O interface 2030.
  • a non-transitory computer-accessible (e.g., computer-readable) storage medium may also include any volatile or non-volatile media such as RAM (e.g.
  • a computer-accessible medium may include transmission media or signals such as electrical, electromagnetic, or digital signals, conveyed via a communication medium such as a network and/or a wireless link, such as may be implemented via network interface(s) 2040.

Abstract

La présente invention concerne des procédés, des systèmes et des supports lisibles par ordinateur pour la gestion de groupes d'instance de bureau virtuel. Une pluralité d'instances de bureau virtuel sont approvisionnées dans un groupe pour une organisation client. Le nombre d'instances de bureau virtuel n'excède pas un nombre d'emplacements de bureau virtuel pour l'organisation client. Pour un premier dispositif client associé à un premier utilisateur, un accès est fourni à une instance particulière de bureau virtuel sur la base (au moins en partie) d'une détermination selon laquelle un nombre courant d'instances de bureau virtuel connectées est inférieur au nombre. Pour un second dispositif client associé à un second utilisateur, un accès est refusé à la pluralité d'instances de bureau virtuel sur la base (au moins en partie) d'une détermination selon laquelle un nombre courant d'instances de bureau virtuel connectées satisfait le nombre.
PCT/US2016/068638 2015-12-28 2016-12-27 Gestion de groupes d'instances de bureau virtuel WO2017117086A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
DE112016006080.7T DE112016006080B4 (de) 2015-12-28 2016-12-27 Verwaltung von virtuellen desktopinstanzenpools
CN201680076692.5A CN108431778A (zh) 2015-12-28 2016-12-27 对虚拟桌面实例池的管理

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/981,587 US10037221B2 (en) 2015-12-28 2015-12-28 Management of virtual desktop instance pools
US14/981,587 2015-12-28

Publications (1)

Publication Number Publication Date
WO2017117086A1 true WO2017117086A1 (fr) 2017-07-06

Family

ID=57799878

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2016/068638 WO2017117086A1 (fr) 2015-12-28 2016-12-27 Gestion de groupes d'instances de bureau virtuel

Country Status (4)

Country Link
US (2) US10037221B2 (fr)
CN (1) CN108431778A (fr)
DE (1) DE112016006080B4 (fr)
WO (1) WO2017117086A1 (fr)

Families Citing this family (43)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9135437B1 (en) * 2014-03-24 2015-09-15 Amazon Technologies, Inc. Hypervisor enforcement of cryptographic policy
WO2017080590A1 (fr) * 2015-11-10 2017-05-18 Telefonaktiebolaget Lm Ericsson (Publ) Technique pour échanger des datagrammes entre des modules d'application
US10037221B2 (en) 2015-12-28 2018-07-31 Amazon Technologies, Inc. Management of virtual desktop instance pools
US10412168B2 (en) * 2016-02-17 2019-09-10 Latticework, Inc. Implementing a storage system using a personal user device and a data distribution device
US10778750B2 (en) * 2016-06-23 2020-09-15 Vmware, Inc. Server computer management system for supporting highly available virtual desktops of multiple different tenants
US10860342B2 (en) * 2017-01-30 2020-12-08 Citrix Systems, Inc. Computer system providing cloud-based session prelaunch features and related methods
US10348836B2 (en) * 2017-02-22 2019-07-09 Microsoft Technology Licensing, Llc Migrating clients between servers
EP3603028B1 (fr) * 2017-03-28 2023-05-24 NetApp, Inc. Procédés et systèmes de fourniture d'un accès de réveil sur demande à des serveurs de session
US11587196B2 (en) * 2017-04-10 2023-02-21 Dell Products L.P. Information handling system remote desktop protocol selection
US10776145B2 (en) 2017-04-21 2020-09-15 Dell Products L.P. Systems and methods for traffic monitoring in a virtualized software defined storage architecture
US10296369B2 (en) 2017-04-27 2019-05-21 Dell Products L.P. Systems and methods for protocol termination in a host system driver in a virtualized software defined storage architecture
KR102105683B1 (ko) * 2017-04-28 2020-05-29 한국전자통신연구원 유선 및 이동 통신 서비스의 통합 플랫폼 관리 장치 및 방법
US10503922B2 (en) * 2017-05-04 2019-12-10 Dell Products L.P. Systems and methods for hardware-based security for inter-container communication
US10936353B2 (en) 2017-05-16 2021-03-02 Dell Products L.P. Systems and methods for hypervisor-assisted hardware accelerator offloads in a virtualized information handling system environment
US10652247B2 (en) * 2017-06-09 2020-05-12 Dell Products, L.P. System and method for user authorization in a virtual desktop access device using authentication and authorization subsystems of a virtual desktop environment
US10592293B2 (en) * 2017-08-31 2020-03-17 Cisco Technology, Inc. Tenant-specific policy generation and enforcement within containers
US10887287B2 (en) * 2018-05-11 2021-01-05 Citrix Systems, Inc. Connecting client devices to anonymous sessions via helpers
US11263036B2 (en) * 2018-07-16 2022-03-01 Samsung Electronics Co., Ltd. Method and device for controlling access of application
US10680945B1 (en) * 2018-09-27 2020-06-09 Amazon Technologies, Inc. Extending overlay networks to edge routers of a substrate network
US11171913B2 (en) * 2018-09-28 2021-11-09 Nutanix, Inc. Systems and methods for implementing address translation services
AT521713B1 (de) * 2018-10-11 2023-07-15 Avl List Gmbh Verfahren zur Detektion sicherheitsrelevanter Datenflüsse
US10785056B1 (en) * 2018-11-16 2020-09-22 Amazon Technologies, Inc. Sharing a subnet of a logically isolated network between client accounts of a provider network
EP3884628A1 (fr) * 2018-11-20 2021-09-29 Amazon Technologies Inc. Extensions de services de réseau de fournisseurs
US10833949B2 (en) 2018-11-20 2020-11-10 Amazon Technologies, Inc Extension resource groups of provider network services
US11153281B2 (en) 2018-12-06 2021-10-19 Bank Of America Corporation Deploying and utilizing a dynamic data stenciling system with a smart linking engine
CN109710379A (zh) * 2018-12-24 2019-05-03 广州供电局有限公司 虚拟运维管理方法、装置、系统、计算机设备和存储介质
US10860361B2 (en) 2019-01-07 2020-12-08 Citrix Systems, Inc. Computer system providing virtual computing sessions through virtual delivery agent leasing with enhanced power savings and connectivity and related methods
US10884768B2 (en) * 2019-01-25 2021-01-05 Vmware, Inc. Solution which can improve VDI user experience automatically
US11188372B2 (en) 2019-04-29 2021-11-30 Citrix Systems, Inc. Computing system with dual VDA registration and related methods
US11362943B2 (en) 2019-05-20 2022-06-14 Citrix Systems, Inc. System and method for validating virtual session requests
CN112241299B (zh) * 2019-07-18 2023-08-18 上海达龙信息科技有限公司 电子设备的运营管理方法、系统、介质及服务器
US11064017B2 (en) 2019-09-24 2021-07-13 Amazon Technologies, Inc. Peripheral device enabling virtualized computing service extensions
US11520530B2 (en) 2019-09-24 2022-12-06 Amazon Technologies, Inc. Peripheral device for configuring compute instances at client-selected servers
US11569997B1 (en) 2020-03-09 2023-01-31 Amazon Technologies, Inc. Security mechanisms for data plane extensions of provider network services
US11888936B2 (en) * 2020-07-01 2024-01-30 Jpmorgan Chase Bank, N.A. Method and system for an object proxy service
US20220129295A1 (en) 2020-10-25 2022-04-28 Meta Platforms, Inc. Server-side hosted environment for a cloud gaming system
CN112288404A (zh) * 2020-10-29 2021-01-29 迈普通信技术股份有限公司 一种会议管理方法、装置、电子设备及存储介质
US11595319B2 (en) * 2020-12-21 2023-02-28 Microsoft Technology Licensing, Llc Differential overbooking in a cloud computing environment
WO2022141159A1 (fr) * 2020-12-30 2022-07-07 Citrix Systems, Inc. Reprise de session sécurisée
US11385925B1 (en) * 2021-07-06 2022-07-12 Bank Of America Corporation System and method for provisioning hosted virtual desktop resources to remote users
CN114895996A (zh) * 2022-03-25 2022-08-12 阿里巴巴（中国）有限公司 云实例的运行方法、装置、电子设备和存储设备
CN115396290B (zh) * 2022-06-29 2023-11-17 北京车网科技发展有限公司 一种故障自动恢复方法、装置及服务系统
CN116560859B (zh) * 2023-07-11 2023-09-22 恒辉信达技术有限公司 一种基于云计算的访问设备资源分配方法及相关装置

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120084443A1 (en) * 2010-09-30 2012-04-05 Amazon Technologies, Inc. Virtual provisioning with implementation resource boundary awareness
WO2015039181A1 (fr) * 2013-09-23 2015-03-26 Gopc Pty Ltd Systèmes et procédés de calcul virtuel
US20150256474A1 (en) * 2014-03-10 2015-09-10 Vmware, Inc. Resource management for multiple desktop configurations for supporting virtual desktops of different user classes

Family Cites Families (47)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6510466B1 (en) 1998-12-14 2003-01-21 International Business Machines Corporation Methods, systems and computer program products for centralized management of application programs on a network
US6912578B1 (en) * 2000-02-25 2005-06-28 Sun Microsystems, Inc. Method and apparatus for improving utilization of a resource on a shared client
US7383329B2 (en) * 2001-02-13 2008-06-03 Aventail, Llc Distributed cache for state transfer operations
US7802251B2 (en) * 2005-11-09 2010-09-21 Hitachi, Ltd. System for resource allocation to an active virtual machine using switch and controller to associate resource groups
CA2633966C (fr) 2005-12-15 2014-04-15 Lehman Brothers Inc. Systeme et procede d'acces securise a un bureau distant
US8719816B2 (en) 2006-03-14 2014-05-06 University Of Utah Research Foundation Extendable framework for distributed applications and data
US20080127348A1 (en) * 2006-08-31 2008-05-29 Kenneth Largman Network computer system and method using thin user client and virtual machine to provide immunity to hacking, viruses and spy ware
US8065676B1 (en) * 2007-04-24 2011-11-22 Hewlett-Packard Development Company, L.P. Automated provisioning of virtual machines for a virtual machine buffer pool and production pool
US8141090B1 (en) * 2007-04-24 2012-03-20 Hewlett-Packard Development Company, L.P. Automated model-based provisioning of resources
US7953833B2 (en) 2008-01-31 2011-05-31 Wanova Technologies Ltd. Desktop delivery for a distributed enterprise
JP5047870B2 (ja) * 2008-04-17 2012-10-10 株式会社日立製作所 マスタ管理システム、マスタ管理方法、およびマスタ管理プログラム
US10411975B2 (en) 2013-03-15 2019-09-10 Csc Agility Platform, Inc. System and method for a cloud computing abstraction with multi-tier deployment policy
US8856783B2 (en) 2010-10-12 2014-10-07 Citrix Systems, Inc. Allocating virtual machines according to user-specific virtual machine metrics
US9130903B2 (en) 2009-07-01 2015-09-08 Citrix Systems, Inc. Unified out of band management system for desktop and server sessions
US9009219B2 (en) 2010-01-27 2015-04-14 Vmware, Inc. Native viewer use for service results from a remote desktop
US9244700B2 (en) 2010-05-09 2016-01-26 Citrix Systems, Inc. Methods and systems for delivering applications from a desktop operating system
US8224781B2 (en) * 2010-05-14 2012-07-17 Lsi Corporation Data protection in a data storage system
US8954564B2 (en) 2010-05-28 2015-02-10 Red Hat, Inc. Cross-cloud vendor mapping service in cloud marketplace
US20120239729A1 (en) 2010-09-13 2012-09-20 Neverware, Inc. Methods and apparatus for connecting a thin client to a virtual desktop
US20120066679A1 (en) * 2010-09-13 2012-03-15 Startforce, Inc. Disposable virtual desktop for transient use by multiple users
WO2012045021A2 (fr) * 2010-09-30 2012-04-05 Commvault Systems, Inc. Améliorations apportées à la gestion économique des données, telles que la connexion de modules de gestion de données ayant des fonctionnalités limitées à un système de gestion de données ayant des fonctionnalités complètes
US8849941B2 (en) * 2010-09-30 2014-09-30 Microsoft Corporation Virtual desktop configuration and operation techniques
US8850429B2 (en) * 2010-10-05 2014-09-30 Citrix Systems, Inc. Load balancing in multi-server virtual workplace environments
CN102447723B (zh) 2010-10-12 2015-09-09 运软网络科技(上海)有限公司 客户端虚拟化架构
US8607054B2 (en) 2010-10-15 2013-12-10 Microsoft Corporation Remote access to hosted virtual machines by enterprise users
US9069890B2 (en) * 2011-04-20 2015-06-30 Cisco Technology, Inc. Ranking of computing equipment configurations for satisfying requirements of virtualized computing environments based on an overall performance efficiency
US9251033B2 (en) * 2011-07-07 2016-02-02 Vce Company, Llc Automatic monitoring and just-in-time resource provisioning system
US9038063B2 (en) 2011-09-07 2015-05-19 International Business Machines Corporation Determining virtual machine image pattern distributions in a networked computing environment
US9213503B2 (en) 2011-10-30 2015-12-15 Hewlett-Packard Development Company, L.P. Service provider management of virtual instances corresponding to hardware resources managed by other service providers
US9047476B2 (en) 2011-11-07 2015-06-02 At&T Intellectual Property I, L.P. Browser-based secure desktop applications for open computing platforms
TWI459296B (zh) * 2012-02-21 2014-11-01 Hon Hai Prec Ind Co Ltd 增加伺服器的虛擬機配置數量的方法
US8997093B2 (en) 2012-04-17 2015-03-31 Sap Se Application installation management by selectively reuse or terminate virtual machines based on a process status
US20140047114A1 (en) * 2012-08-13 2014-02-13 Cisco Technology, Inc. Virtual desktop policy control
US9507612B1 (en) * 2012-08-31 2016-11-29 United Services Automobile Association (Usaa) Managing dedicated and floating pool of virtual machines based on demand
US9529613B2 (en) * 2012-12-12 2016-12-27 Vmware, Inc. Methods and apparatus to reclaim resources in virtual computing environments
US10313345B2 (en) 2013-03-11 2019-06-04 Amazon Technologies, Inc. Application marketplace for virtual desktops
CN105765526B (zh) * 2013-06-14 2019-11-22 华为技术有限公司 通过网络从远程磁盘镜像进行引导
US20150019728A1 (en) 2013-06-26 2015-01-15 Amazon Technologies, Inc. Management of computing sessions
KR102102168B1 (ko) * 2013-10-21 2020-04-21 한국전자통신연구원 가상 데스크탑 서비스 장치 및 방법
US9386079B2 (en) * 2014-06-10 2016-07-05 American Megatrends, Inc. Method and system of virtual desktop infrastructure deployment studio
US10241836B2 (en) * 2014-06-11 2019-03-26 Vmware, Inc. Resource management in a virtualized computing environment
CN104133750A (zh) * 2014-08-20 2014-11-05 浪潮(北京)电子信息产业有限公司 主机与存储设备兼容适配测试方法和系统
US20160056975A1 (en) * 2014-08-25 2016-02-25 Conexlink, LLC System and Method for Virtualizing an IT Infrastructure with Remotely Accessible Virtual Desktops
US9747136B2 (en) * 2014-12-09 2017-08-29 Vmware, Inc. Methods and systems that allocate cost of cluster resources in virtual data centers
US9645625B2 (en) * 2015-02-19 2017-05-09 American Megatrends, Inc. System and method for power management of computing devices in a virtual desktop infrastructure
US9569276B2 (en) * 2015-03-16 2017-02-14 Dell Products L.P. System and method for dynamic user assignment in a virtual desktop environment
US10037221B2 (en) 2015-12-28 2018-07-31 Amazon Technologies, Inc. Management of virtual desktop instance pools

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120084443A1 (en) * 2010-09-30 2012-04-05 Amazon Technologies, Inc. Virtual provisioning with implementation resource boundary awareness
WO2015039181A1 (fr) * 2013-09-23 2015-03-26 Gopc Pty Ltd Systèmes et procédés de calcul virtuel
US20150256474A1 (en) * 2014-03-10 2015-09-10 Vmware, Inc. Resource management for multiple desktop configurations for supporting virtual desktops of different user classes

Also Published As

Publication number Publication date
CN108431778A (zh) 2018-08-21
US20170185437A1 (en) 2017-06-29
DE112016006080B4 (de) 2023-09-21
DE112016006080T5 (de) 2018-09-13
US10853117B2 (en) 2020-12-01
US10037221B2 (en) 2018-07-31
US20180336059A1 (en) 2018-11-22

Similar Documents

Publication Publication Date Title
US10853117B2 (en) Management of virtual desktop instance pools
US11048534B2 (en) Connection-based resource management for virtual desktop instances
US11409550B2 (en) Low latency connections to workspaces in a cloud computing environment
US10848431B2 (en) Virtual network interface objects
US10075459B1 (en) Securing workspaces in a cloud computing environment
US9712386B1 (en) Grouping routing resources for isolated virtual network traffic management
US9397909B2 (en) Methods and apparatus for scalable private services
US9692729B1 (en) Graceful migration of isolated virtual network traffic
US9037775B2 (en) Network filtering in a virtualized environment
US8370481B2 (en) Inventory management in a computing-on-demand system
US20170293501A1 (en) Method and system that extends a private data center to encompass infrastructure allocated from a remote cloud-computing facility
US9319272B1 (en) Methods and apparatus for providing composed appliance services in virtualized private networks
CA2914802A1 (fr) Gestion de verrous distribues dans un environnement de cloud computing
US10218597B1 (en) Provider network address range-based models
US11159646B1 (en) Identifying, presenting, and launching preferred applications on virtual desktop instances
Udayakumar Design Essentials of AVS
Tian et al. Virtualization and Cloud
Udayakumar Deployment Essentials of AVS

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16826603

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 112016006080

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16826603

Country of ref document: EP

Kind code of ref document: A1