METHOD AND SYSTEM FOR MAXIMIZING RESOURCE UTILIZATION AND USER EXPERIENCE FOR A POOL OF VIRTUAL DESKTOPS

A system and method for optimizing compute resources for virtual desktops in a cloud based virtual desktop system is disclosed. The desktop system provides access to virtual desktops by remote devices. The virtual desktops consume compute resources. A compute resource optimization service communicates with a client on the remote display device. A virtual desktop having an agent is in communication with the resource optimization service. A virtual infrastructure system is in communication with the compute resource optimization service. The compute resource optimization service optimizes allocation of the compute resources to the virtual desktop from the virtual infrastructure system by setting the virtual desktop in one of a plurality of states.

TECHNICAL FIELD

The present disclosure relates generally to network-based systems. More particularly, aspects of this disclosure relate to a system that maximizes resource utilization for a system having a pool of virtual desktops.

BACKGROUND

Computing systems that rely on applications operated by numerous networked computers are ubiquitous. Information technology (IT) service providers thus must effectively manage and maintain very large-scale infrastructures. An example enterprise environment may have many thousands of devices and hundreds of installed software applications to support. The typical enterprise also uses many different types of central data processors, networking devices, operating systems, storage services, data backup solutions, cloud services, and other resources. These resources are often provided by means of cloud computing, which is the on-demand availability of computer system resources, such as data storage and computing power, over the public internet or other networks without direct active management by the user.

Users of networked computers such as in a cloud-based system may typically log into a computer workstation or client device and are provided a desktop application that displays an interface of applications and data available via the network or cloud. Such desktop applications will be initially accessed when a user logs in, but may remain active to respond to user operation of applications displayed on the desktop interface. While users may activate the desktop application on any computer on the network, most users work from one specific computer.

Because physical desktops cannot be dynamically modified as needs change, their users must usually be allocated a hardware class sufficient to handle the application scenario's peak performance requirement, even though that requirement is often the exception and not the rule. For example, each desktop user will be allocated a dedicated physical machine that is continuously available to that user, for 7×24 hours of the week. The cost of the hardware resources is constant, and therefore there is significant over-provisioning and wasted cost.

Remote desktop virtualization solutions have been available for over a decade. These solutions provide virtual desktops to network users. In remote desktop virtualization offerings, there is typically a capability of associating a remote desktop virtualization template in a particular datacenter with a remote desktop virtualization pool in the same datacenter as part of the general configuration model. This remote desktop virtualization template is customized with the image of the right desktop for a particular remote desktop virtualization use case.

A global virtual desktop service system includes a large number of desktop service resources, including many virtual machines, virtual networks, and other services. There are numerous dependent components of a global desktop service system. Such dependent components may include installed client software, endpoint client devices, the network used by the endpoint client devices, cloud APIs provided to manage virtual desktop infrastructure globally, regional resources utilized by cloud infrastructure providers, such as networks, gateway hosts, the virtual desktop hosts, agent services, the virtual desktop operating system, and computing, storage, and network services provided by the cloud infrastructure provider.

An application scenario and its operating system environment are run on certain desktop hardware components, which may be physically co-located with the user, or may be “virtual machines” that are accessed remotely and/or indirectly by a service provider. In the case of virtual machines, the physical hardware involved may be a different solution that emulates the physical machine attributes expected by the user. Virtual machines are employed in many different industrial uses, such as web services that respond to requests constantly. Application scenarios for virtual desktops, more specifically, are designed for individual users interacting with desktop software. In fact, these application scenarios may utilize compute resources sporadically, may rarely require peak operational performance, and are often completely idle. Typically, a desktop user only requires the applications for some duration of time during a work day. It is possible that the desktop will perform background processing without user interaction; however, for some hours of the day, the desktop is generally unused.

As an application scenario is used, the consumption of hardware compute resources varies over time for each desktop user. Some operations consume more CPU or GPU resources; others consume more RAM memory. Some are long operations, and some very short. The following diagram illustrates the consumption of compute resources for a single user over the course of a week, for a specific hardware class. Simply replacing physical machines with virtual machines does not in itself solve this, because they are typically provisioned and managed in such a way that they are still statically maintained, and the cost of hardware compute resources is therefore still constant.

For example, a graph of CPU and memory use for a virtual desktop over a period of time, such as a week, will show wasted periods of compute resource consumption such as times when the user is not even connected to the virtual desktop. Because of the lack of resource optimization, many virtual desktop service systems face similar costs to physical hardware provisioning, without an optimization solution.

Thus, there is a need for a service for a virtual desktop system that optimizes resource use by determining idle times and allows pausing of virtual desktops during such times. There is also a need for a service that has different states for a virtual desktop based on stored policies for optimal resource use.

SUMMARY

One disclosed example is a system for a virtual remote desktop system providing remote devices access to virtual desktops. The virtual desktops consume compute resources. The system includes a compute resource optimization service communicating with a client on a remote device. The system includes a virtual desktop having an agent in communication with the resource optimization service. A virtual infrastructure system in communication with the compute resource optimization service. The compute resource optimization service optimizes allocation of the compute resources to the virtual desktop from the virtual infrastructure system by setting the virtual desktop in one of a plurality of states.

A further implementation of the example system is an embodiment where the plurality of states includes a paused state. Another implementation is where the paused state includes one of suspending a virtual machine associated with the virtual desktop, powering down the virtual machine. or de-allocating the virtual machine. Another implementation is where the plurality of states further includes a resuming state, a disconnected state, and a connected state. Another implementation is where the plurality of states includes an error handling state. Another implementation is where a transition to the pause state from another state occurs via one of explicit logout, explicit disconnect or a protocol idle connection timeout. Another implementation is where the system includes a storage device storing a policy accessible by the compute resource optimization service. The policy determines the transition to the one of the plurality of states of the virtual desktop in response to events. Another implementation is where the policy is one of a plurality of policies, each of the plurality of policies determining a different allocation of compute resources to the virtual desktop. Another implementation is where the virtual desktop is a member of a pool of virtual desktops, and wherein the policy is applied to each virtual desktop in the pool. Another implementation is where one of the plurality of states is a pause state designated as a normal state for the virtual desktop. Another implementation is where the policy is a configurable policy allowing the specification of a delay period that follows a disconnection before a pause automatically occurs. Another implementation is where the policy is a configurable policy allowing the specification of a period of work hours where the virtual desktop is not paused. Another implementation is where the optimization service includes the capacity to pause the virtual desktop by reallocating the compute resources when the virtual desktop is idle. Another implementation is where the reallocation of the compute resources is made to at least one other user of another virtual desktop in a different time zone than the user. Another implementation is where a period of time for pausing the virtual desktop is determined from a previous pattern of use of the virtual desktop by the user. Another implementation is where a period of time for pausing the virtual desktop is determined from a schedule associated with the user of the virtual desktop. Another implementation is where the optimization service includes the capacity to resume or reallocate compute resources dedicated to the virtual desktop. Another implementation is where the virtual desktop is provisioned by the infrastructure system and is initially paused after being provisioned by the infrastructure system. Another implementation is where the virtual desktop is configurable to be re-connected unless a pause state is determined by the compute resource optimization service. Another implementation is where if the virtual desktop is in a pause state, feedback is provided to the user of the remote device to indicate a short delay before the virtual machine becomes available. Another implementation is where the compute resources include at least one of processing or memory provided by the infrastructure system.

Another disclosed example is a virtual remote desktop system providing remote devices access to virtual desktops. The virtual desktops consume compute resources. The system includes a compute resource optimization service communicating with a client on a remote device. The system includes a virtual desktop having an agent in communication with the resource optimization service. a virtual infrastructure system is in communication with the compute resource optimization service. The compute resource optimization service optimizes allocation of the compute resources to the virtual desktop from the virtual infrastructure system by setting the virtual desktop in a paused state allowing conservation of the compute resources and a resume state when a user uses the virtual desktop.

Another disclosed example is a method for optimizing processing and/or memory resources for a virtual desktop. User access to a virtual desktop is provided on a remote device. The virtual desktop has a client consuming compute resources on a virtual infrastructure system. A compute resource optimization service communicates with the client on the remote device. Allocation of the compute resources to the virtual desktop from the virtual infrastructure system is optimized via the compute resource optimization service by setting the virtual desktop in one of a plurality of states.

The present disclosure is susceptible to various modifications and alternative forms. Some representative embodiments have been shown by way of example in the drawings and will be described in detail herein. It should be understood, however, that the invention is not intended to be limited to the particular forms disclosed. Rather, the disclosure is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS

The present inventions can be embodied in many different forms. Representative embodiments are shown in the drawings, and will herein be described in detail. The present disclosure is an example or illustration of the principles of the present disclosure, and is not intended to limit the broad aspects of the disclosure to the embodiments illustrated. To that extent, elements and limitations that are disclosed, for example, in the Abstract, Summary, and Detailed Description sections, but not explicitly set forth in the claims, should not be incorporated into the claims, singly or collectively, by implication, inference, or otherwise. For purposes of the present detailed description, unless specifically disclaimed, the singular includes the plural and vice versa; and the word “including” means “including without limitation.” Moreover, words of approximation, such as “about,” “almost,” “substantially,” “approximately,” and the like, can be used herein to mean “at,” “near,” or “nearly at,” or “within 3-5% of,” or “within acceptable manufacturing tolerances,” or any logical combination thereof, for example.

The following are definitions of terms used in this disclosure that relate in general to the virtual desktop system.

An agent is software that performs certain operations and monitoring tasks that has direct access to, or runs on, some virtual computing resource and may maintain a duplex communication channel with a desktop service control plane.

An API is a set of specific, controlled, well-defined functional entry points to get, create, update, and delete resources and otherwise change the state of a remote system.

A cloud API is, in this context, an API specific to an Infrastructure as a Service (IaaS) provider.

A connection broker is desktop service resource sometimes used to dynamically connect desktop clients with desktops.

A datacenter is a collection of computing resources, such as servers, in one physical location.

A virtual desktop is a computer's interactive desktop, or a single interactive application provided without access to the full desktop, or other experience provided by remote desktop virtualization via a desktop service.

A client, or desktop client (sometimes called a VDI client) is a software application that provides display and input access to a desktop as part of a desktop service. It may be installed on a standard desktop or mobile operating system, or be pre-installed on dedicated hardware devices, or downloaded dynamically via a web browser application, or deployed in some other way. Like an agent, it may also perform certain operations and monitoring tasks and may maintain a duplex communication channel with a desktop service control plane.

A cloud desktop fabric is a scalable virtual desktop interface system that orchestrates multiple regional fabric regions to allow a user anywhere in different regions to access a virtual desktop interface.

A desktop service resource refers to some virtualized hardware, networking service, or virtual machine, other than the desktops themselves, that exists to support a desktop service.

A desktop service is remote desktop virtualization hosted on a public or private cloud, provided as a turnkey managed service.

A desktop service control plane is an application that implements and manages a desktop service.

A desktop user is a person who uses a desktop.

An enterprise connector is a desktop service resource used to integrate the network of a desktop service with the network services, including but not limited to directory services that support authentication and authorization.

A gateway, sometimes referred to as a protocol gateway, is a type of desktop service resource running a service that manages secure access to a desktop supporting protocols including a remote display protocol (RDP). In this disclosure, gateways are accessed as a gateway cluster unless explicitly noted otherwise.

A gateway cluster is a set of gateways managed together for load balancing purposes and high availability purposes.

Infrastructure as a service (IaaS) is a set of virtualized computing resources available from a public cloud provider.

An infrastructure template is a collection of desktop service resources and/or definitions that provide a blueprint for replicating a regional cloud datacenter.

A multi-tenant desktop service control plane is a single desktop service control plane implementation that is used by multiple customers in such a way that no single customer is aware of or is impacted by activities of the others.

A non-persistent desktop user is a desktop user that is allocated a new desktop for each login session.

A persistent desktop user is a desktop user that is allocated a specific desktop for exclusive use over multiple connection sessions.

Pool desktops are a set of desktops managed by the desktop service control plane as a unit.

A regional cloud datacenter is a datacenter providing virtualized computing resources to implement a desktop service for efficient access within a single geography or availability zone.

Remote desktop virtualization is software technology that separates the desktop environment and associated application software from the physical client device that is used to access it in a client/server environment.

A virtualized computing resource is a virtual machine that is created by an Infrastructure as a Service (IaaS) provider.

A virtual machine is an emulation of a physical computer that can be accessed over a network.

A virtual network is hardware and software network resources combined into a single, software-based administrative entity, made available by an Infrastructure as a Service (IaaS) provider.

Virtual storage is storage resources provided as part of Infrastructure as a Service.

The present disclosure is directed toward a method and system that optimizes virtual hardware resource consumption, while meeting user experience requirements of application scenarios. The system optimizes utilization of hardware resources not only at the level of each virtual desktop, but at the level of an entire pool of virtual desktops. A combination of a policy-driven configuration and a run-time desktop state management system accomplishes the optimization.

The goal of the example system is to pause the more common, normal state of a virtual desktop at periods of time determined by a policy. The pause incurs minimized costs and resources because the associated compute resources to the virtual desktop are deallocated. Only when the virtual desktop is being used, which is generally a minority of the time, is it resumed. Awareness of the pause/resume operations is minimized, with the goal that such operations are completely transparent to desktop users, or at worst, cause a small and acceptable delay.

FIG.1shows a high level block diagram of a cloud desktop service system100. The cloud desktop service system100may also be referenced as a global desktop system because it provides virtual desktops for users globally. The cloud desktop service system100includes four layers, a users layer110, a use cases layer120, a fabric layer130, and a cloud layer140.

The users layer110represents desktop users having the same computing needs, that may be located anywhere in the world. In this example, the users layer110includes users112and114, who are in geographically remote locations and access desktops via computing devices.

The use cases layer120represents common logical global pools of virtual desktops available to serve the users, whereby each global pool is based on a common desktop template. There can be multiple global pools based on which groups users belong to and their job requirements. In this example, the pool for the users112and114may be one of a developer desktop pool122, an engineering workstation pool124, or a call center application pool126. Pools such as the developer desktop pool122or the engineering workstation pool124allow users in the pool a virtual desktop that allows access to graphic processing unit (GPU) based applications. Other example applications may include those applications used for the business of the enterprise, for example, ERP (enterprise resource planning) applications or CRM (customer relationship management) applications. These applications allow users to control the inventory of the business, sales, workflow, shipping, payment, product planning, cost analysis, interactions with customers, and so on. Applications associated with an enterprise may include productivity applications, for example, word processing applications, search applications, document viewers, and collaboration applications. Applications associated with an enterprise may also include applications that allow communication between people, for example, email, messaging, web meetings, and so on.

The fabric layer130includes definitions and configurations for infrastructure and desktop service resources, including gateways, desktop templates, and others. The resources are maintained as fabric regions such as a master fabric region132, and expansion regional fabric regions134,136, and138. As will be explained below, the fabric regions such as the regional fabric regions134,136, and138can be added or removed as needed. The master fabric region is the configuration of record.

The cloud layer140implements the resources defined by the use case layer120and fabric layer130, including virtual desktops, infrastructure, and other virtual resources, all of which are virtual machines or other virtual resources hosted in a public cloud.

The layers110,120,130, and140are created and orchestrated by a desktop service control plane150that can touch all the layers. The desktop service control plane150is a key component to orchestrate a cloud desktop service system such as the cloud desktop service system100inFIG.1. The desktop service control plane150can manage the entire lifecycle of a desktop service implementation, from creating and managing the required desktops, to monitoring and analyzing the stream of operational data collected, enforcing security policies, and optimizing the experience for IT administrators and desktop users. For example, the desktop service control plane150may register a set of a virtual networks, virtual storage resources, and more. Within a virtual network, the control plane150may further register and coordinate the use of gateways, enterprise connectors, desktop templates, connection brokers, and more.

The two desktop users112and114in different parts of the world who are each able to access an example high-performance desktop service from the cloud desktop service system100. As will be explained below, the cloud desktop service system100eliminates the need to divide users with similar requirements into user groups specific to a region. Rather, all users having similar needs throughout the world are considered as a single worker pool. Users, such as users112and114, each may use a client device to access the desktop service. Client devices may be any device having computing and network functionality, such as a laptop computer, desktop computer, smartphone, or tablet. Client devices execute a desktop client to access remote applications such as the desktop. The client application authenticates user access to the applications. A client device can be a conventional computer system executing, for example, a Microsoft™ Windows™-compatible operating system (OS), Apple™ OS X, and/or a Linux distribution. A client device can also be a client device having computer functionality, such as a personal digital assistant (PDA), mobile telephone, tablet, video game system, etc.

FIG.2is a block diagram of some examples of components of the global desktop service system100, including an example set of desktop clients210, a regional cloud datacenter212, and an administration center214, that interact with and can be orchestrated by the desktop service control plane150. The desktop client210communicates with the desktop service control plane150in order to be registered with the fabric, assigned a desktop, remotely configured, and for other purposes. There may be multiple regional cloud datacenters similar to the regional cloud datacenter212, but only one datacenter is shown in detail for simplicity of explanation. The regional cloud datacenter212may include a set of protocol gateways220, a set of managed virtual desktops222, and a cloud provider operational API224. These components all communicate with the desktop service control plane150. Such datacenters include servers that host the various applications. The datacenter typically comprises IT infrastructure that is managed by IT personnel. The IT infrastructure may include servers, network infrastructure, software, and so on. If there is an issue related to an application reported by a user, the IT personnel can check the health of the infrastructure used by the application. A datacenter may include a firewall to control access to the applications hosted by the datacenter. The firewall enables computing devices behind the firewall to access the applications hosted by the datacenter, but prevents computing devices outside the firewall from directly accessing the applications. The firewall may allow devices outside the firewall to access the applications within the firewall using a virtual private network (VPN).

The protocol gateway220may be present to provide secure public or internal access to the managed virtual desktops. A gateway agent230is software that is deployed on that gateway host by the desktop service control plane150, and serves to monitor the activity on the gateway220, and enable the desktop service control plane150to assist in configuration and operations management of the gateway.

The example desktop client210is software and device hardware available in the local environment of a desktop user240to remotely access a managed virtual desktop using a remote desktop protocol. The desktop client210communicates with the desktop service control plane150/

The managed virtual desktop222is itself provisioned and maintained by the desktop service control plane150. A desktop agent such as desktop agent232is software that is deployed on that managed virtual desktop by the desktop service control plane150, and serves to monitor the activity on the managed virtual desktop, and enable the desktop service control plane150to assist in configuration and operations management of the virtual desktop.

The cloud provider operational application programming interface (API)224presents services provided by the cloud provider that also participate in the management of the virtual machine. This can be utilized by a desktop service control plane150to perform operations like provisioning or de-provisioning the virtual machine.

Administrative users242can interact with network operations center software at the administration center214that allows management and administration of the desktop service control plane150.

Other components and services may interact with the desktop service control plane150but are omitted fromFIG.2for simplicity. These components and services may include enterprise connectors, network monitoring services, customer relationship management (CRM) systems, and many others.

The desktop service control plane150itself can perform many internal centralized functions also not depicted in inFIG.2, including pool management, user and group management, cloud service adapters, virtual desktop templates, data analysis, high-availability management, mapping users to the optimal regional data center, security policy management, monitoring, compliance, reporting, and others.

The control plane150includes a user and group manager250, a monitoring service252, a desktop management service (DMS)254, an external API (EAPI)256, a configuration service (CS)258, and a compute resource optimization service (CROS)260. The control plane150may access an event data repository270and a configuration repository272for storing and reference to relevant operational data. Although only one regional datacenter212is shown in detail, it is to be understood that the control plane150may facilitate numerous regional datacenters.

The monitoring service252makes both routine and error events available to administrators and can analyze operational performance and reliability. The desktop management service254interacts with the one or more managed virtual machines (MVMs)222in the regional cloud datacenter212.

The administration center214works directly with the desktop service control plane150as its primary human interface. The administration center214allows the administrative user242to configure the functions of the control plane150through the configuration service258. The configuration service258supports editing and persistence of definitions about the desktop service, including subscription information and policies. In this example, the policies include optimization policies that pause virtual desktops to conserve compute resources.

The global desktop service system100includes a large number of desktop service resources, including many virtual machines, virtual networks, and other services. Managing a global desktop service system, and ensuring that it is running in a performant, secure, and resilient fashion, can become very complex because of the large number of dependencies between desktop users and desktop service resources, and among desktop service resources. As will be explained the compute resource optimization service (CROS)260optimizes usage of compute resources of the system100supporting the virtual desktops.

FIG.3is a diagram that shows the dependencies of an acceptable user experience such as that of the user240inFIG.2. The user240may be remote desktop user that executes the desktop client210on a local computer and expects a certain quality of user experience310. This in turn depends on the performance of a set of one or more application(s) installed on the same desktop to be available for certain periods of time to solve a specific set of business use cases as explained above. The applications available may be an application scenario320. For example, a user may be designing a specification for large engineering project. The set of installed applications may include computer aided design and rendering tools, project inventory management tools, and video processing facilities. Furthermore, these tools may all need to be run concurrently and interact with each other. Additionally, the desktop operating system environment can be considered another part of the application scenario. As such, the desktop operating system adds another set of processor and memory requirements.

The principles described herein relate to application scenarios320in which every user is allocated a dedicated virtual desktop that can have its own file system state and customized experiences (such as keyboard shortcuts, window arrangements, and so on). Every application scenario320has implicit, or possibly explicit, performance requirements. For example, in order to produce a rendering of a certain blueprint, it may be considered a failed user experience if it takes longer than a certain number of minutes. In other cases, such as a routine menu selection, the performance requirement is that it take less than 1 second.

The speed of a particular operation may be dependent on many factors, including the performance of disk storage, network speed, or network bandwidth. These may be collectively referenced as required compute resources330. The compute resources are related to the performance implication of the virtual hardware profile, including the number and/or rating of processors such as CPUs or GPUs, and the amount of RAM memory available. As part of the application scenario320, there are peak performance requirements that cover the most demanding operations needed by a user. To handle this, as an example, some application scenarios may require that the CPU is generally not utilized at more than 75%, and at least 10 GB of free RAM available to handle peak operational requirements. If adding more processor capacity speeds up an operation, that operation is considered to be CPU-bound. If adding more RAM speeds the operation up, it is considered to be memory-bound.

An application scenario and its operating system environment are run on certain desktop hardware components, which may be physically co-located with the user, or may be “virtual machines” that are accessed remotely and/or indirectly by a service provider, in which the physical hardware involved may be a different solution that emulates the physical machine attributes expected by the user.

Hardware resources are provisioned by providers of both physical and virtual hardware. They are available in various permutations known as hardware classes, that each have their own total capacity and associated costs. For example, for one hardware class, there may be an array of CPUs, each of which may only support a certain number of operations per seconds. RAM can only represent a finite amount of volatile data. A disk can only store a finite amount of persistent data. Therefore, although hardware components can generally be shared between application processes, they may be considered to be consumable resources for any given moment of time.

Virtual machines supported by the system100inFIGS.1-2may be employed in many different industrial uses, such as web services that respond to requests constantly. Application scenarios for virtual desktops, more specifically, are designed for individual users interacting with desktop software, and typically do not follow a pattern of constant requests. Desktop application scenarios may utilize compute resources sporadically, may rarely require peak operational performance, and are often completely idle. For example, the desktop user240inFIG.2begins interactively using the desktop for some duration of time during a work day. Thus, for some hours of the day, the desktop is generally unused. The patterns of use can vary greatly by application scenario, and some uses may fall outside of any pattern.

As an application scenario is used, the consumption of hardware compute resources varies over time for each desktop user. Some operations consume more CPU or GPU resources; others consume more memory resources such as RAM memory. Some are long operations, and some very short.FIG.4Ais a graph400of compute resources for a specific hardware class consumed by an example user during a week. The graph shows a trace of processing (CPU) resources410and a trace of memory (RAM) resources412during times of each day of the week. As shown by the traces410and412, peak usages of processing resources and memory resources occur during the middle of typical working days, Monday through Friday. Low use of such resources occurs at night time and early morning as well as weekend days such as Saturday and Sunday.

FIG.4Bis a graph420that shows the resource use inFIG.4Awith wasted periods of compute resource consumption shown as blocks430, when the user is not even connected to the virtual desktop. Because of the lack of resource optimization, known virtual desktop service systems face similar costs to physical hardware provisioning, without an optimization solution such as the compute resource optimization service260. A system providing virtual machines such as the system200inFIG.2have several capabilities to dynamically manage compute resources for a particular virtual machine through the compute resource optimization service (CROS)260. One capability is to pause a virtual machine, meaning that the service can dynamically deallocate compute resources at any time. A compute resource that is paused has a different, and typically much lower, cost structure than a running compute resource. For example, the cloud provider may charge significantly less for paused compute resources, in some cases no more than the cost of the disk storage to keep the last known state of the virtual machine before it was paused. Another capability is to quickly resume, or reallocate compute resources that were previously paused, restoring the exact memory and processor state of the virtual machine. Because of these capabilities, the cost of compute resources no longer needs to be constant.

FIG.4Cshows a graph440derived from the compute resource graph400ofFIG.4Ato show periods where the compute resources are paused for CPU and RAM consumption over the course of one week for one virtual desktop of a particular hardware class. The periods where the compute resources are paused are illustrated by blocks450inFIG.4Cbased on the implementation of the compute resource optimization service260. While the virtual desktop is not actively used (in this example, this is typically evenings and weekends) it is paused by the compute resource optimization service260. The previously wasted compute resources inFIG.4Bare now saved and may be reallocated to other tasks.

In this example, virtual desktops are initially paused after they are provisioned and made ready by the desktop infrastructure system200inFIG.2. At the time a user initiates a connection to a paused desktop through the desktop client210, the desktop is automatically resumed for the user. Once a connected session on the virtual desktop for a user has become idle (no interaction detected for some period of time), the system200may decide to pause the desktop based on configured policies. Once a user has explicitly disconnected from a desktop, the system200decides when to pause the desktop based on built-in or configured policies managed by the compute resource optimization service260. When an automatic reconnection occurs, the system200will decide whether a resume is required based on configured policies and the current state of the virtual desktop.

For example, in a scenario without the pause and resume capability of the example system, a virtual desktop is running all the time, that is, for 24 hours a day or 168 hours per week. If the cost of a fully running machine is $10 per hour, the cost per week per user is $1,680. With the pause and resume capability, a virtual desktop might be resumed to cover a 9 AM to 5 PM regular work shift of 40 hours out of the full 168 hours of the week, so the virtual desktop is paused for 128 hours per week. The cost of a paused machine (for example $1 per hour) is much less than the cost of a resumed machine. In this example, the compute resource cost is (40×$10)=$400 for the resumed time, plus (128×$1), or $128, for the paused time, for a total of $528, or approximately =31% of the full compute resource cost without pause/resume. Depending on the amount of actual use, and actual costs, the savings provided by the example pause and resume capability will vary.

The use of the pause capability during periods of low usage allows several advantages and improvements. First, the pause capability allows optimal sharing of compute resources across different users in different time zones using the system200. The system200allows lower cost of compute resources leading to higher margins. Further, providers of the system200incur costs dynamically, which enables more granular billing, such as hourly billing, instead of flat-rate plans, giving more flexibility to consumers.

Policies about compute resource optimization may be applied in aggregate to multiple virtual desktops based on various groupings and/or rules for the system100inFIG.1. For example, a policy may be applied to a pool of virtual desktops managed by the system200inFIG.2, affecting every virtual desktop in the pool. Alternatively, a policy may be applied to multiple virtual desktops based on a rule about an end user's time-zone, an end user groupings or other attributes.

The compute resource optimization service260can be implemented to support options explicitly defined and configured as part of the system200inFIG.2, or may work with pre-existing configurability that is already present in components that are utilized by the system200. An example of an explicitly provided policy would be a rule defined within the compute resource optimization service260that causes the compute resource optimization service260to disconnect an idle user as defined by the policy. A similar rule may be natively enforced by the operating system and remote display protocol itself, and this external configuration may work just as well with the compute resource optimization service260.

Another example of a configurable policy is the ability to specify a delay period that follows a disconnection before a pause automatically occurs. This is useful in cases where a user may often wish to reconnect to the virtual desktop quickly after a short break. Another example of a configurable policy is the ability to specify a period of “normal work hours,” during which no automatic pause can take effect. This policy is useful to optimize user experience by allowing for instant reconnection during the periods when the user is likely to be working, and minimizing delays in reconnection.

FIG.5is a block diagram of an example compute resource optimization service architecture500of the compute resource optimization service260for implementing a pause to conserve virtual resources. The architecture500is centered around the compute resource optimization service260. The compute resource optimization service260accesses different policies512. The policies512may be selected by a configuration interface514accessible by a system administrator.

An end user uses a remote display device such as a device520running the client210to establish a remote display protocol connection to a virtual desktop such as the virtual desktop222. The end user uses a particular application scenario on the virtual desktop222. The virtual desktop222includes the agent232that monitors the activity on the managed virtual desktop and assists in configuration and operations management. For example, the agent232sends event information when remote desktop protocol connections are established or changed, and can report performance metrics such as CPU and memory utilization. Furthermore, the agent232may implement commands such as shutting down or rebooting the virtual machine. The agent232interfaces with the virtual desktop infrastructure system200that is run by a cloud virtual infrastructure provider530in this example. The client210is installed software on that remote display device520that manages this connection, and communicates with the compute resource optimization service260about connection events.

In this example, the compute resource optimization service260interacts with the cloud virtual infrastructure service provider530to handle pause/resume requests for the virtual desktop222. The policies512are created and persistently maintained by the administrators of system200for the compute resource optimization service260in order to control its behavior as related to pause/resume optimizations of resources for the virtual desktops. This can be done with the interactive user interface514providing options and default values in a standard way. There are many possible implementations of this capability.

In one example, the compute resource optimization service260tracks at least five distinct states of a virtual desktop. Of course, there will likely be at least one more state defined for error handling purposes such as a state representing a failed virtual desktop.FIG.6is a virtual desktop state diagram of the compute resource optimization service260that includes a paused state610, a pausing state614, a resuming state616, a disconnected state618, and a connected state620. In this example, the paused state610is the default or normal state of a virtual desktop when it is not being actively used. The resuming state616is a transitory state that exists after the resume operation has been initiated but before it is completed. The disconnected state618is a state that represents that the virtual desktop that has been fully resumed, and is ready for connection and use. The connected state620is a state that represents that the client has a remote display protocol session with the virtual desktop, and application scenarios are able to be used interactively. The connected state620implies that the virtual desktop is running normally. The pausing state614is a transitory state that exists after the pause operation has been initiated for a disconnected client, but before pause has completed.

FIG.7shows the process of provisioning a virtual desktop performed by the architecture500. The provisioning process begins by the compute resource optimization service260sending a request for a new virtual machine to Cloud virtual infrastructure provider530(710). The virtual infrastructure provider530creates the new virtual machine (712). The virtual infrastructure provider530creates the new virtual machine according to a desktop template as specified in the configuration of the desktop service control plane200. The creation of the new virtual machine includes allocating appropriate compute, disk, network, and other infrastructure resources. The compute resource optimization service260sends policies to the agent232(714), including an Inactivity Timeout setting. The agent232waits an appropriate time according to the Inactivity Timeout setting in the policy (716). If there is no activity within the specified timeout, the agent232sends a pause request to the compute resource optimization service260(718). The compute resource optimization service260then directs the cloud virtual infrastructure provider530to pause the virtual desktop (720). The cloud provider530then pauses the virtual desktop.

FIG.8shows the process of connection to a paused virtual desktop performed by the architecture500. The normal state of a virtual desktop is to be paused. Whenever an end user deliberately attempts to connect to the virtual desktop222, the client210triggers a resume by requesting a resume from the compute resource optimization service260. The compute resource optimization service260waits until the virtual desktop222is resumed (but disconnected) and then connects to the virtual desktop222as it normally would for any virtual desktop it has access to.

It is also possible that the compute resource optimization service260can be configured to bring the virtual desktop222to a pristine status, in which all persisted files and user configuration settings are reset to the same state as a freshly-provisioned virtual desktop. This may be done every time the virtual desktop is resumed. This option may be employed in environments where there are legal requirements preventing leftover files or stored configurations that were created by a user in an earlier session to be retained. In effect, whenever a user is given access to a resumed virtual desktop, it is equivalent to a freshly-provisioned virtual desktop.

As shown inFIG.8, a user of the remote display device520first explicitly requests connection (810). This request is received by the client210and reported to the compute resource optimization service260(812). The compute resource optimization service260directs the Cloud virtual infrastructure provider530to resume (814). The Cloud virtual infrastructure provider530then resumes the virtual desktop222(516). This does not require provisioning any new resources, but does require the cloud virtual infrastructure provider530to resume the existing resources. The client210polls the compute resource optimization service260to wait for the resume (818). The client210then connects the virtual desktop222(820). This allows the user to access the virtual desktop222for connected usage.

FIG.9shows the process of disconnecting and pausing a virtual desktop such as the virtual desktop222performed by the architecture500. Disconnection and pause occurs once the user is no longer connected to the virtual desktop222. The agent232handles the triggering of the pause operation. Based on the policies that were previously sent to the agent232, the agent232may wait some period of time, as specified by the inactivity timeout, before triggering the pause. The agent232tracks the waiting time as a timeout counter. During this period of time, the client210may reestablish a connection to the virtual desktop222and the timeout counter is reset. Assuming any configured timeout interval has passed, the agent232sends the pause request to compute resource optimization service260. The compute resource optimization service260in turn delegates the request to the virtual service provider530. At this point, the virtual desktop222(including the agent232) is paused and is unavailable. Alternatively, the decision to pause may be made by the compute resource optimization service260.

The process is initiated by the connection of the remote display device520to the agent232ending by explicit logout, explicit disconnect or a protocol idle connection timeout (910). For example, the user may have simply let the connection go idle without any activity, or may have shut down the client program. The agent232waits an appropriate time (912) as set out by the policy selected by the compute resource optimization service260. During the time, a reconnection may occur based on a request made by the client210(914) such as when the user reconnects in some fashion. This can happen by the user explicitly requesting a connection, or by resuming the client program.

If the period of time for pause expires, the agent232sends a pause request to the compute resource optimization service260(916). The compute resource optimization service260directs the Cloud virtual infrastructure provider530to pause (918). The Cloud virtual infrastructure provider530pauses the virtual desktop222(920).

FIG.10shows the process of automatic reconnection performed by the architecture500. Remote display devices that host the client210such as the device520have the ability to hibernate (or sleep) based on lack of activity or other conditions such as closing the lid of a laptop, or deactivating a mobile device. When the client210is activated again such as by waking up the remote display device520, the client210will detect that it no longer has a connection to a virtual desktop to which it was previously connected. However, the client210does not know whether the virtual desktop222is in a paused state or is simply disconnected.

Attempting to reconnect to the virtual desktop222is not optimal behavior, because the virtual desktop222may be paused and there is no reason for it to be resumed. Therefore, the client210will ask the compute resource optimization service260to send the state of the virtual desktop222before taking action. If the virtual desktop222is simply in the disconnected state, the client will automatically attempt to reconnect. Otherwise, the client210will do nothing until the user explicitly attempts to create a connection, as described above.

A detection of a loss of connection (1010) occurs from the client210. The loss of connection detection may occur with a network problem or when the client210is reactivated after the remote device520is awakened. The client210asks the compute resource optimization service260for the state of the virtual desktop (1012). If the virtual desktop222is in a paused state, the client210ignores the reactivation, as a connection still exists and a user may access the virtual desktop222through the client210. If the virtual desktop222is disconnected, the client210performs a simple reconnection (1014).

Failures that affect end users typically occur while attempting to connect to a paused virtual desktop. Information is returned by the compute resource optimization service260to the client so it can handle various scenarios. One scenario may be if the virtual desktop was not paused. The client210simply connects to the disconnected virtual desktop222instantly. Another scenario is if the virtual desktop222was paused, the client210may give feedback to the user to indicate a short delay while the virtual desktop222is resumed. Thus, the client210may display an interface to the remote display deice520asking the user to wait.

If the virtual desktop222fails to resume, but the compute resource optimization service260is retrying that operation, the client210may display an interface to the user to the effect that the virtual desktop is taking longer than usual to restart, but is attempting to retry. If the virtual desktop222fails to resume, and the virtual cloud provider530has provided information to the compute resource optimization service260that the failure is due to a temporary problem, the client210may display an interface to the user that the desktop is not available now, but to try to access it again later.

If the virtual desktop222fails to resume, and the virtual cloud provider530has provided information to the compute resource optimization service260that a reboot of the virtual desktop222might solve the problem, the client210may display an interface to the user that the virtual desktop222requires a reboot. If the virtual desktop222fails to resume, and the virtual cloud provider530has provided information to the compute resource optimization service260that the problem has no known self-correction activity, the client210may display an interface to the user that the desktop is not available and to contact their support team.

FIG.11is a screen image1100of an example interactive user interface, such as the interface514inFIG.5for configuring pause/resume policies of the compute resource optimization service architecture500. The example screen image1100of the interactive user interface shown inFIG.11shows a display of editable policy properties for a policy that will affect the behavior of the agent232inFIG.2. In this example, the interface includes a policy name field1110, a policy type selection field1112, an inactivity timeout selection field1114, an inactivity message field1116, and an inactivity timer action selection field1118. The example fields1110,1112,1114,1116, and1118allow an administrative user to edit the policy properties. The selected properties may be saved via a save button1120. Entries in any of the fields1110,1112,1114,1116, and1118may be canceled by selecting a cancel button1122.

In this example, the administrative user may provide a policy name in the file policy name field1110that gives the policy a unique identity. The policy type field1112provides a dropdown list of the possible components in the system100that the policy is applied. In this example, a selection of “Desktop Agent” causes the policy to be applied to the agent232inFIG.2. The interface1100may therefore be used for other policies other than configuring pause and resume policies for desktop agents. The administrative user may select different times for the inactivity timeout selection field1114. The selected time controls how many minutes will elapse after the end user stops interacting with the virtual desktop before the policy is applied. The administrative user may provide a message via the inactivity message field1116that controls what the end user sees on the remote device after the timeout occurs. The administrative user may select an action via the inactivity timer action field1118. This controls the behavior after timeout, with the default choice to being to sign out and end the session. Another optional action could be to disconnect from the session but leave it running. In the case of pause/resume functionality, sign out also causes the virtual machine to be paused.

FIGS.12-13illustrate an example computing system1300, in which the components of the computing system are in electrical communication with each other using a bus1302. The system1300includes a processing unit (CPU or processor)1330and a system bus1302that couple various system components, including the system memory1304(e.g., read only memory (ROM)1306and random access memory (RAM)1308), to the processor1330. The system1300can include a cache of high-speed memory connected directly with, in close proximity to, or integrated as part of the processor1330. The system1300can copy data from the memory1304and/or the storage device1312to the cache1328for quick access by the processor1330. In this way, the cache can provide a performance boost for processor1330while waiting for data. These and other modules can control or be configured to control the processor1330to perform various actions. Other system memory1304may be available for use as well. The memory1304can include multiple different types of memory with different performance characteristics. The processor1330can include any general purpose processor and a hardware module or software module, such as module11314, module21316, and module31318embedded in storage device1312. The hardware module or software module is configured to control the processor1330, as well as a special-purpose processor where software instructions are incorporated into the actual processor design. The processor1330may essentially be a completely self-contained computing system that contains multiple cores or processors, a bus, memory controller, cache, etc. A multi-core processor may be symmetric or asymmetric.

To enable user interaction with the computing device1300, an input device1320is provided as an input mechanism. The input device1320can comprise a microphone for speech, a touch-sensitive screen for gesture or graphical input, keyboard, mouse, motion input, and so forth. In some instances, multimodal systems can enable a user to provide multiple types of input to communicate with the system1300. In this example, an output device1322is also provided. The communications interface1324can govern and manage the user input and system output.

Storage device1312can be a non-volatile memory to store data that is accessible by a computer. The storage device1312can be magnetic cassettes, flash memory cards, solid state memory devices, digital versatile disks, cartridges, random access memories (RAMs)1308, read only memory (ROM)1306, and hybrids thereof.

The controller1310can be a specialized microcontroller or processor on the system1300, such as a BMC (baseboard management controller). In some cases, the controller1310can be part of an Intelligent Platform Management Interface (IPMI). Moreover, in some cases, the controller1310can be embedded on a motherboard or main circuit board of the system1300. The controller1310can manage the interface between system management software and platform hardware. The controller1310can also communicate with various system devices and components (internal and/or external), such as controllers or peripheral components, as further described below.

The controller1310can generate specific responses to notifications, alerts, and/or events, and communicate with remote devices or components (e.g., electronic mail message, network message, etc.) to generate an instruction or command for automatic hardware recovery procedures, etc. An administrator can also remotely communicate with the controller1310to initiate or conduct specific hardware recovery procedures or operations, as further described below.

The controller1310can also include a system event log controller and/or storage for managing and maintaining events, alerts, and notifications received by the controller1310. For example, the controller1310or a system event log controller can receive alerts or notifications from one or more devices and components, and maintain the alerts or notifications in a system event log storage component.

Flash memory1332can be an electronic non-volatile computer storage medium or chip that can be used by the system1300for storage and/or data transfer. The flash memory1332can be electrically erased and/or reprogrammed. Flash memory1332can include EPROM (erasable programmable read-only memory), EEPROM (electrically erasable programmable read-only memory), ROM, NVRAM, or CMOS (complementary metal-oxide semiconductor), for example. The flash memory1332can store the firmware1334executed by the system1300when the system600is first powered on, along with a set of configurations specified for the firmware1334. The flash memory1332can also store configurations used by the firmware1334.

The firmware1334can include a Basic Input/Output System or equivalents, such as an EFI (Extensible Firmware Interface) or UEFI (Unified Extensible Firmware Interface). The firmware1334can be loaded and executed as a sequence program each time the system1300is started. The firmware1334can recognize, initialize, and test hardware present in the system600based on the set of configurations. The firmware1334can perform a self-test, such as a POST (Power-On-Self-Test), on the system1300. This self-test can test the functionality of various hardware components such as hard disk drives, optical reading devices, cooling devices, memory modules, expansion cards, and the like. The firmware1334can address and allocate an area in the memory1304, ROM1306, RAM1308, and/or storage device1312, to store an operating system (OS). The firmware1334can load a boot loader and/or OS, and give control of the system1300to the OS.

The firmware1334of the system1300can include a firmware configuration that defines how the firmware1334controls various hardware components in the system1300. The firmware configuration can determine the order in which the various hardware components in the system1300are started. The firmware1334can provide an interface, such as an UEFI, that allows a variety of different parameters to be set, which can be different from parameters in a firmware default configuration. For example, a user (e.g., an administrator) can use the firmware1334to specify clock and bus speeds, define what peripherals are attached to the system1300, set monitoring of health (e.g., fan speeds and CPU temperature limits), and/or provide a variety of other parameters that affect overall performance and power usage of the system1300. While firmware1334is illustrated as being stored in the flash memory1332, one of ordinary skill in the art will readily recognize that the firmware1334can be stored in other memory components, such as memory1304or ROM1306.

System1300can include one or more sensors1326. The one or more sensors1326can include, for example, one or more temperature sensors, thermal sensors, oxygen sensors, chemical sensors, noise sensors, heat sensors, current sensors, voltage detectors, air flow sensors, flow sensors, infrared thermometers, heat flux sensors, thermometers, pyrometers, etc. The one or more sensors1326can communicate with the processor, cache1328, flash memory1332, communications interface1324, memory1304, ROM1306, RAM1308, controller1310, and storage device1312, via the bus1302, for example. The one or more sensors1326can also communicate with other components in the system via one or more different means, such as inter-integrated circuit (I2C), general purpose output (GPO), and the like. Different types of sensors (e.g., sensors1326) on the system1300can also report to the controller1310on parameters, such as cooling fan speeds, power status, operating system (OS) status, hardware status, and so forth. A display1336may be used by the system1300to provide graphics related to the applications that are executed by the controller1310.

FIG.13illustrates an example computer system1400having a chipset architecture that can be used in executing the described method(s) or operations, and generating and displaying a graphical user interface (GUI). Computer system1400can include computer hardware, software, and firmware that can be used to implement the disclosed technology. System1400can include a processor1410, representative of a variety of physically and/or logically distinct resources capable of executing software, firmware, and hardware configured to perform identified computations. Processor1410can communicate with a chipset1402that can control input to and output from processor1410. In this example, chipset1402outputs information to output device1414, such as a display, and can read and write information to storage device1416. The storage device1416can include magnetic media, and solid state media, for example. Chipset1402can also read data from and write data to RAM1418. A bridge1404for interfacing with a variety of user interface components1406, can be provided for interfacing with chipset1402. User interface components1406can include a keyboard, a microphone, touch detection, and processing circuitry, and a pointing device, such as a mouse.

Chipset1402can also interface with one or more communication interfaces1408that can have different physical interfaces. Such communication interfaces can include interfaces for wired and wireless local area networks, for broadband wireless networks, and for personal area networks. Further, the machine can receive inputs from a user via user interface components1406, and execute appropriate functions, such as browsing functions by interpreting these inputs using processor1410.

Moreover, chipset1402can also communicate with firmware1412, which can be executed by the computer system1400when powering on. The firmware1412can recognize, initialize, and test hardware present in the computer system1400based on a set of firmware configurations. The firmware1412can perform a self-test, such as a POST, on the system1400. The self-test can test the functionality of the various hardware components1402-1418. The firmware1412can address and allocate an area in the memory1418to store an OS. The firmware1412can load a boot loader and/or OS, and give control of the system1400to the OS. In some cases, the firmware1412can communicate with the hardware components1402-1410and1414-1418. Here, the firmware1412can communicate with the hardware components1402-1410and1414-1418through the chipset1402, and/or through one or more other components. In some cases, the firmware1412can communicate directly with the hardware components1402-1410and1414-1418.

It can be appreciated that example systems1300(inFIG.12) and1400can have more than one processor (e.g.,1330,1410), or be part of a group or cluster of computing devices networked together to provide greater processing capability.

While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. Although the invention has been illustrated and described with respect to one or more implementations, equivalent alterations and modifications will occur or be known to others skilled in the art upon the reading and understanding of this specification and the annexed drawings. In addition, while a particular feature of the invention may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. Thus, the breadth and scope of the present invention should not be limited by any of the above described embodiments. Rather, the scope of the invention should be defined in accordance with the following claims and their equivalents.