--- myst: html_meta: "description lang=en": "Pooling together a group of fixed infrastructure that can be launched as a single endpoint as presented on the user dashboard in Kasm Workspaces." "keywords": "Kasm, Pooling, Server, RDP, Fixed, Static, KasmVNC" "property=og:locale": "en_US" --- ```{title} Pools ``` # Pools Pools can be used to group a set of similar fixed systems together, so they can be treated as a single Workspace for user access. Users will see a single Workspace icon on their dashboard, but their session will get distributed to an available server in the pool. Each server in the pool can be set to support 1 or more concurrent sessions. Kasm automatically distributes the sessions evenly over the servers. Pools can also be used to auto scale servers using a supported [VM provider](./vm_providers.md). Auto scaling can be used to automatically provision [Servers](./servers.md) or [Docker Agents](../agent_settings.md). ```{note} If the license includes auto-scale configs, the adminsitrator will have 3 links underneath the table for **All AutoScale Configs**, **All VM Provider Configs** and **All DNS Provider Configs**. These allow the administrator to see all of the configs available and make changes, but the recommended approach is to use the **Edit** option on a specific pool. ``` ```{figure} /images/compute/pools.webp :align: center **Server Pools** ``` ## Create Pool - Click the **Infrastructure** item in the navigation menu. - Select the **Pools** option in the dropdown menu. - Select **Add** from the top right of the **Pools** table. ```{figure} /images/compute/create_server_pool.webp :align: center **Create Server Pool** ``` Provide a name for the server pool. The type can be either [Docker Agent](../agent_settings.md) or [Server](./servers.md). ## Servers List **This list is only shown for Pools of type Server** This list is almost identical to the [Servers](servers.md) list with the exception that only servers that are assigned to this pool are shown. Use the assign button to assign existing servers to this pool. ```{figure} /images/compute/server_list.webp :align: center **Server List** ``` ## Docker Agents List **This list is only shown for Pools of type Docker Agent** This list is almost identical to the [Agents](../agent_settings.md) list with the exception that only servers that are assigned to this pool. Use the assign button to assign existing agents to this pool. ```{figure} /images/compute/agent_list.webp :align: center **Agent List** ``` (autoscale_configuration)= ## AutoScale Configurations ```{note} This feature requires an Enterprise license. Please contact a Kasm Technologies representative for details. ``` Kasm has the ability to automatically provision and destroy {term}`Servers ` and Docker {term}`Agents ` based on user demand. The AutoScale configuration differs slightly between Servers and Agents. ```{figure} /images/compute/autoscale_list.webp :align: center **Autoscale List** ``` In this section the administrator can **Assign** or **Add** AutoScale configurations, if the administrator adds an AutoScale configuration it will automatically be assigned to this pool with the **AutoScale Type** and **Pool** both set and prevented from being changed. Clicking Add button on the AutoScale Configuration table will walk the administrator through a Wizard. The first step is the AutoScale configuration, which is slightly different between a Server pool and a Docker Agent pool. (autoscale-scheduling)= ### AutoScale Scheduling Kasm AutoScaling configurations have the capability of being scheduled for active times. This capability allows customers to save compute costs by turning off Kasm AutoScaling when that extra compute is not needed. AutoScale schedules are available as a tab when editing an AutoScale configuration. If no schedule is defined then the AutoScale configuration is considered active unless disabled. Kasm will not scale down a server that has active sessions on it, so the administrator can be assured they will not disrupt any existing Kasm sessions when the schedule becomes inactive. When an AutoScale configuration for **Docker Agents** is inactive any unused staged sessions will be removed and no new sessions (staged or user created) will be assigned to any **Docker Agents** that are part of the inactive AutoScale configuration. Since an AutoScale configuration with an inactive schedule will not provision any compute resources, the administrator may want two AutoScale configurations: one that has minimal standby compute available to minimize compute costs and one that has more substantial resources configured. This will allow users to always get a session even if it takes extra time on off hours. The administrator can even configure 0 for the standby cpu/memory/gpu during the off hours and allow session resource provisioning to be fulfilled fully on demand. ```{image} /images/compute/autoscale_schedule_tab.png :align: center :scale: 70% ``` Click on **Add Schedule** to create a new schedule for the AutoScaling configuration. On the **Add Schedule** screen there are fields for what days of the week this schedule should be active as well as both a start time, end time, and a timezone. Kasm will convert the time from the Kasm database to match the timezone specified when determining if a schedule is active or not. Multiple schedules can be defined for each AutoScale configuration. ```{image} /images/compute/add_new_autoscale_schedule_config.png :align: center :scale: 70% ``` #### Example AutoScale Schedules Here are a few examples of how AutoScale schedules can be leveraged. ```{eval-rst} .. dropdown:: Basic Example (Traditional Business Schedule) :animate: fade-in A business whose core hours are 8 a.m. to 5 p.m. Monday through Friday. The administrator could configure Kasm AutoScaling to turn on autoscaling at 7 a.m. so all compute was available well before the 8 a.m. start time and turn off AutoScaling at 6 p.m. each evening. This allows the administrator to save overnight compute costs when there is not a business need for that compute. Defining this schedule is straight forward the **Add Schedule** screen would look similar to this: .. figure:: /images/compute/basic_autoscale_schedule.png :align: center Basic AutoScale Schedule ``` ```{eval-rst} .. dropdown:: Multiple Continuous Days Schedule :animate: fade-in A more complicated example would be if an Administrator wanted compute resources to come on line at 3 p.m. Wednesday, and stay on until 11 a.m. Friday. For this the administrator would create three separate schedules on the autoscale config which would provide the desired functionality. The first schedule the administrator would select only wednesday, start time 3:00 p.m., and end time 11:59 p.m. .. figure:: /images/compute/continuous_autoscale_schedule_wednesday.png :align: center Wednesday Start AutoScale Schedule The second schedule the administrator would select Thursday, with start time 12:00 a.m. and end time 11:59 p.m. .. figure:: /images/compute/continuous_autoscale_schedule_thursday.png :align: center Thursday All Day AutoScale Schedule The third schedule the administrator would select Friday, with start time 12:00 a.m. and end time 11:00 a.m. .. figure:: /images/compute/continuous_autoscale_schedule_friday.png :align: center Friday End AutoScale Schedule .. figure:: /images/compute/continuous_autoscale_schedules.png :align: center Set of Schedules For Multi-Day AutoScale Scheduling ``` ```{eval-rst} .. dropdown:: Overnight schedule :animate: fade-in Here is an example of an overnight schedule where the start time is later than the end time. This will result in an overnight schedule. It will become active on the start time on the day(s) of the week selected, and will become inactive at the end time of the following day. In the following example the Autoscale configuration will become active on Tuesday and Thursday at 9:00 p.m. and will deactivate on Wednesday and Friday at 5:00 a.m. .. figure:: /images/compute/autoscale_schedule_overnight.png :align: center Overnight AutoScale Schedule ``` ```{eval-rst} .. dropdown:: Multiple Time Periods Within a Day :animate: fade-in By using multiple schedules it is possible to configure multiple active times within a single day. Here morning shift is configured from 8:00 a.m. until 12:00 p.m. on Monday, Wednesday and Friday. .. figure:: /images/compute/autoscale_schedule_split_day_morning.png :align: center Multiple Time Periods Morning AutoScale Schedule The afternoon shift is configured from 2:00 p.m. until 6:00 p.m. on the same days. .. figure:: /images/compute/autoscale_schedule_split_day_afternoon.png :align: center Multiple Time Periods Afternoon AutoScale Schedule .. figure:: /images/compute/autoscale_schedule_split_day.png :align: center List of AutoScale Schedules for Multiple Time Periods Within a Day ``` ### AutoScale Config (Server Pool) This section covers the AutoScale configuration step of the Wizard for Pools of type Server. ```{figure} /images/compute/create_autoscale_server.webp :align: center **Create Autoscale Server** ``` ```{eval-rst} .. table:: General AutoScaling Settings :widths: 200 +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Name | Description | +=============================================+===================================================================================================================================================================+ | **Name** | Name for the AutoScale config . | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **AutoScale Type** | The type of AutoScale confog this is, either a Docker Agent or a Server. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Pool** | Which pool this AutoScale config is attached to. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Enabled** | Whether to enable this config or not. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Aggressive Scaling** | When enabled, the system may take more expedient measures to provision raw compute resources for on-demand session requests. See :ref:`aggressive-scaling` | | | for more details. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Deployment Zone** | Which zone this AutoScale config applies to. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Require Checkin** | When enabled, the system will wait to receive a callback from the newly created server to set its status to Running. The callback may come from the Kasm Windows | | | Service or by calling the `set_server_status` API. See :ref:`require-checkin` for more details. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Agent Installed** | When enabled, the sytem will assume the Kasm Windows Service is installed, enabling workflows that require the agent. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Connection Type** | Whether to use KasmVNC or RDP, VNC, or SSH. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Connection Port** | Which port to connect on. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Connection Username** | Which username to connect to the server with. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Connection Password** | Which password to connect to the server with. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Use User SSH Key** | Whether to use the SSH keys assigned to a Kasm user. (Only applicable to SSH connection type) | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Connection Private Key** | The private key to authenticate against the SSH server with. (Only applicable to SSH connection type) | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Connection Private Key Passphrase** | The passphrase encrypting the specified private key. (Only applicable to SSH connection type) | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Connection Info (JSON)** | Any extra connection info. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Create Active Directory Computer Record** | Whether to create an active directory record or not. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Reusable** | Whether the connection reusable. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Minimum Available Sessions** | The minimum available sessions there are. | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Max Simultaneous Sessions Per Server** | Max sessions per server allowed | +---------------------------------------------+-------------------------------------------------------------------------------------------------------------------------------------------------------------------+ ``` (require-checkin)= ### Require Checkin The **Require Checkin** flag can be used to ensure the system waits until a newly created server is fully ready before allowing a users session to connect. Administrators may use the autoscale startup script to ensure the desired configurations and services are properly initialized (e.g RDP is enabled and running). If using Windows sessions, adminstrators may use the [Kasm Windows Service](../../guide/windows/windows_service.md). All systems may use the `set_server_status` API. ```{eval-rst} .. http:post:: /api/set_server_status?token={checkin_jwt} **Example request**: .. tabs:: .. code-tab:: json { "status": "running", "status_message": "Initialization Complete", "status_progress": "100" } .. code-tab:: bash curl -k -X POST -H "Content-Type: application/json" -d '{{"status": "running", "status_message": "Initialization Complete", "status_progress": "100"}}' https://{upstream_auth_address}/api/set_server_status?token={checkin_jwt} ``` Additional examples are available in the [workspaces-autoscale-startup-scripts](https://github.com/kasmtech/workspaces-autoscale-startup-scripts/) repo. #### Create Active Directory Computer Record As covered in the above table, the AutoScaling configuration for a Server Pool allows the administrator to automatically join new VMs to an active directory domain. If the checkbox for **Create Active Directory Computer Record** is checked two additional fields will be shown, **LDAP Config** and **Active Directory Computer OU DN**. ```{figure} /images/compute/join_to_domain.webp :align: center **Join to Domain** ``` Kasm Workspaces creates the AD Computer record, but it **does not join the computer to the domain**, this needs to be done on the system itself. When Kasm creates the AD record, a temporary randomly generated password is created which can be used on the target VM to join it to Active Directory. Kasm can inject this password in a PowerShell script on the VM. That PowerShell script needs to be executed when the VM starts up, in order to complete the process of adding the VM to Active Directory. Below is an example PowerShell script, the special tags `{ad_join_credential}` and `{domain}` will be replaced by Kasm with the randomly generated password and domain name respectively. This script is placed in the [VM Provider](./vm_providers.md) configuration in the Startup Script field. ```powershell $joinCred = New-Object pscredential -ArgumentList ([pscustomobject]@{{ UserName = $null; Password = (ConvertTo-SecureString -String '{ad_join_credential}' -AsPlainText -Force)[0] }}) Add-Computer -Domain "{domain}" -Options UnsecuredJoin,PasswordPass -Credential $joinCred -Force -Restart ``` ```{note} Some cloud providers will automatically execute this startup script when the VM boots, making it easy to get auto AD joining working end-to-end. Other cloud providers, such as Azure, do not automatically execute this script. See the details of each [VM Config Provider](./vm_providers.md). ``` **LDAP Config** The LDAP Config drop down allows the administrator to select which [LDAP configuration](../ldap.md) to use to add the computer record to Active Directory. The LDAP Configuration does not have to be enabled, this allows the administrator to use one LDAP configuration for Authentication and another for AD Computer record creation. If using LDAP for end-user authentication to Kasm Workspaces, the administrator can also configure single-sign on to the Windows systems. **Active Directory Computer OU DN** This is the DN of the Active Directory Computer OU that the administrator would like the computer records placed in. ```{note} The LDAP config must be using an SSL secured LDAPS connection or the LDAP server will not permit Kasm to create the AD Computer record. ``` #### Single Sign-On to Windows Systems via LDAP When users login to Kasm via [LDAP Authentication](../ldap.md), they are able to create sessions to Windows systems that are joined to the same Active Directory domain and are configured for SSO credential pass-through. In the above table covering the Auto Scale configuration fields for Server Pools are the **Connection Username** and **Connection Password** fields. Place the value `{sso_username}` in the **Connection Username** field and place the value `{sso_cred}` in the field **Connection Password** in the Auto Scale configuration for the Server Pool. This requires that all users accessing servers in this Server Pool are authenticated to Kasm using LDAP authentication. See our Windows Deployment Guide video for a walk through of this topic and more. #### Authentication Options When Connecting to an SSH Server Kasm Workspaces has the ability to connect to arbitrary SSH servers. It can use SSH key or password authentication. There are a few combinations of options on the Autoscale Config edit screen that can be selected. The Autoscale Config can be configured to use: - Username/password authentication - Username and select the `Use User SSH Key` to send the username and private key stored with the Kasm user. - Username and a pasted in private key, optionally you can include a passphrase if the key has one. Place the value `{sso_username}` in the **Connection Username** field and check the **Use User SSH Key** checkbox and Kasm Workspaces will send the user's Kasm Workspaces username along with the user's Kasm Workspaces SSH key allowing easy multiple user support on SSH servers. There are some restrictions on the ssh keys supported that are enforced by the connection proxy library used for the ssh server connections: The SSH key must be an ssh-rsa key in PKCS1 format (i.e. the header of the key starts with `-----BEGIN RSA PRIVATE KEY-----`) with a key size of 2048. In addition, some newer Linux distributions such as Ubuntu 22.04 LTS will not accept ssh-rsa keys by default. To work around this edit the `/etc/ssh/sshd_config` file on the target server using the startup script of the vm provider and add these two lines to the config. ```{parsed-literal} HostKeyAlgorithms +ssh-rsa PubkeyAcceptedKeyTypes +ssh-rsa ``` ### AutoScale Config (Docker Agent Pool) This section covers the AutoScale configuration step of the Wizard for Pools of type Docker Agent. ```{figure} /images/compute/create_autoscale_agent.webp :align: center **Create Autoscale Agent** ``` ```{eval-rst} .. table:: General AutoScaling Settings :widths: 200 +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Name | Description | +=================================+===========================================================================================================================================================================================================================================================================================================================================================================================================+ | **Name** | Name for the AutoScale config . | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **AutoScale Type** | The type of AutoScale confog this is, either a Docker Agent or a Server. | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Pool** | Which pool this AutoScale config is attached to. | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Enabled** | Whether to enable this config or not. | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Aggressive Scaling** | When enabled, the system may take more expedient measures to provision raw compute resources for on-demand session requests. See :ref:`aggressive-scaling` for more details | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Deployment Zone** | Which zone this AutoScale config applies to. | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Standby Cores** | The number of standby cores that the system should try to keep "always available" at any given time in addition to any that is needed to satisfy the Staging Config requirements. If the number of available cores falls below this number, more Agents are created. If the number of available cores rises above this number, Agents are deleted as long as it wont result in the number of available | | | cores falling below this number. A value of 0 indicates no additional standby compute is created. The AutoScaler will only provision enough compute according to the Staging Config requirements. | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Standby GPUs** | The number of standby GPUs that the system should try to keep "always available" at any given time in addition to any that is needed to satisfy the Staging Config requirements. If the number of available GPUs falls below this number, more Agents are created. If the number of available GPUs rises above this number, Agents are deleted as long as it wont result in the number of available | | | GPUs falling below this number. A value of 0 indicates no additional standby compute is created. The AutoScaler will only provision enough compute according to the Staging Config requirements. | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Standby Memory (MB)** | The amount of memory (in MB) that the system should try to keep "always available" at any given time in addition to any that is needed to satisfy the Staging Config requirements. If the amount of available memory falls below this number, more Agents are created. If the amount of available memory rises above this number, Agents are deleted as long as it wont result in available amount | | | falling below this number. A value of 0 indicates no additional standby compute is created. The AutoScaler will only provision enough compute according to the Staging Config requirements. | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Downscale Backoff (Seconds)** | This setting prevents prevents the system from downscaling (deleting Agents) for this amount of time (in seconds) when needed. This is useful for preventing the system from thrashing up and down if the available resource hover around an interval that would typically trigger autoscaling. | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Agent Cores Override** | When an Agent is created, the compute resource (e.g AWS EC2 / Digital Ocean Droplet) will have a set amount of CPU and Ram as defined by the cloud provider's instance type. This setting should typically be set to match the instance type but can be set to a preferred value. | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Agent GPUs Override** | When an Agent is created, the compute resource (e.g AWS EC2 / Digital Ocean Droplet) will have a set number of GPUs as defined by the cloud provider's instance type. This setting should typically be set to match the instance type but can be set to a higher number to allow oversubscribing. | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Agent Memory Override (GB)** | When an Agent is created, the compute resource (e.g AWS EC2 / Digital Ocean Droplet) will have a set amount of CPU and Ram as defined by the cloud provider's instance type. This setting should typically be set to match the instance type but can be set to a preferred value. | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **NGINX Cert** | The PEM encoded SSL certificate to use for the kasm_proxy role on the created Agents. This cert should be a wildcard for the Base Domain Name (e.g \*.agents.kasm.example.com) | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **NGINX Key** | The PEM encoded SSL Key to use for the kasm_proxy role on the created Agents. | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Register DNS** | If enabled, the Agent's IP will be registered in DNS. | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | **Base Domain Name** | Define a base name for the automatic DNS registration for the Agent. The system will create a full name using .. If the Base Domain Name is "agents.kasm.example.com", the full DNS name generated will be .agents.kasm.example.com (e.g 123abcd.agents.kasm.example.com). This Base Domain Name, must already be a registered DNS zone within the cloud provider's DNS system. | +---------------------------------+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ ``` (aggressive-scaling)= ### Aggressive Scaling Starting in Workspaces 1.14.0, administrators can choose to leverage fully on-demand compute resources for container and server/server pool based sessions. When users requests a session, and no compute is available, the system will queue the request, provision the resources according to the autocale configs, then fulfill the request. This will prevent the user from receiving a No Resources error. Instead, the user will be presented with a status indicator while the request is fulfilled, which may take several minutes. This can be used alongside the existing standby and staging mechanism to give the administrator more options to balance compute costs with session delivery times. Enabling **Aggressive Scaling** in the Autoscale Config, instructs the system to make more opportunistic choices when requesting resources, with the goal of reducing the users wait time. This mode may result in compute resources being utilized in less cost-efficient ways, since users may end up on separate machines instead of pooled together depending on the circumstance. This mode may also result in the system scaling slighty beyond the max instances defined on the associated VM Provider due to the potential concurrent nature of resource provisioning. ```{figure} /images/compute/queued_session.png :align: center **A Requested Session in Queue** ``` ```{include} /guide/compute/vm_providers.md ``` ```{include} /guide/compute/dns_providers.md ```