Last updated on August 14, 2024 by Robert Plamondon
Release 1.6.0 of the Workspot Linux Agent supports Red Hat Linux (RHEL) 7.9 on VMware and Hyper-V virtual machines (only). This article tells you how to create, deploy, and manage Workspot Linux templates for desktop and application server pools.
See Workspot Linux Desktops for features, limitations, and release-specific information.
See Workspot Compatibility Matrices for a graphical representation of features.
Acquiring the RHEL 7.9 ISO Image
Start with a standard RHEL_x86_64 DVD ISO image from Red Hat, which requires a developer’s account.
Go to https://developers.redhat.com/products/rhel/download and download the image.
Importing the Image into Hyper-V
Import the ISO into Hyper-V using the “New Virtual Machine Wizard” in Hyper-V Server Manager:
We recommend a Generation 1 VM.
Select the desired memory size, disk size, etc.
Use the “Browse..” button to select the ISO image.
Hit “Finish” to import the image.
Click on “Connect.”
Sign into the VM and install the Workspot Linux Agent as described below.
Import the Image
In Vcenter Console, use “Create a New Virtual Machine.”
Give it a name.
Assign it to a cluster.
Select Compatibility and Guest OS settings.
Select CPU, memory, hard disk, network, and CD/DVD settings (CD/DVD settings are where you select the RHEL 7.9 ISO).
Finish the VM creation and power on the VM.
Connect to the VM via the console to configure it as described below.
Installing the Workspot Linux Agent and Related Packages
Connect to the RHEL VM as root using the console or via SSH/PuTTY.
You will need your Red Hat developer credentials for the subscription-manager register command below.
Install RHEL RPMs
subscription-manager register
subscription-manager repos --enable=rhel-7-server-rpms
subscription-manager repos --enable=rhel-7-server-optional-rpms
subscription-manager repos --enable=rhel-7-server-extras-rpms
subscription-manager repos --enable=rhel-7-server-supplementary-rpms
Install and Run Workspot Linux Installer
curl -O https://download.workspot.com/Workspot_linux_installer_1.6.0_RHEL7.9_on_prem.sh
chmod +x workspot_installer.sh
sudo bash workspot_installer.sh
The Workspot Installer will display a series of screens that prompt for input.
Enable Multi-User Configuration:
“No” sets up the VM as a normal desktop VM.
“Yes” allows the VMs to be used as Workspot Application Servers, with the “application” being a full Linux desktop login. This lets you use up to 50 simultaneous users per VM (more if you change the MaxSession field in /etc/xrdp/sesman.ini to more than 50 and restart xrdp).
Additional DNS Servers: Specify any extra (non-default) DNS servers here.
Join Active Directory Domain.
“No” means the VM will not be domain-joined.
“Yes” means it will. You will see additional screens for the domain name, the OU string used by your Operational Unit (which for “example.com” might take the form of “OU=MyOuName,DC=example,DC=com”), a service account capable of joining the domain, and the password for that account.
Workspot Control Registration. This identifies the VM to Workspot.
Credentials-based registration prompts for the username and password of a Workspot Administrator.
Token-based registration uses a template registration token from Workspot Control.
Execute reboot automatically if required? Answer “Yes.”
After this you will see a summary screen and then the VM will reboot.
Additional Steps for Hyper-V
In Hyper-V, there are additional steps to turn the VM into a Workspot template that can be used by Control.
Power down the VM we just configured.
In Hyper-V Virtual Machine Manager, go to “Home > Library > Templates > VM Templates > Create VM Template.” This launches the “Create VM Template Wizard.”
Select “From an existing virtual machine that is deployed on a host” and browse to the VM we just configured, which must be powered down.
Click “Yes” and “Continue.”
On the “Identity” screen, give the VM template a name and description, then click “Next” and “Finish.”
On the “Select Path” screen, choose the parent folder.
Click “Finish” to create the template from our VM, and the template should appear in the Templates list.
Select the template from the list and right-click to go to Properties.
Add a Tag with a value of WorkspotTemplate (otherwise the template will not appear in Control).
Click on the “Hardware Configuration” tab and select the Hyper-V checkbox if it isn’t checked already and save.
Creating Linux Desktop Pools in Control
Linux desktop pools are created in Control in the same way as Windows desktop pools. The Linux template is part of the pool definition. See Control: Desktop Pools.
Creating Linux Desktop Application Servers in Control
Multi-user Linux VMs behave like desktop pools but use Workspot’s Application Server (Cloud Application) mechanism. A group of one or more Linux VMs becomes a server pool, and each server supports multiple simultaneous user logins. The “application” is a Linux login session.
Application server pools are similar to desktop pools, but you specify the number of simultaneous users per VM in addition to the number of VMs. In addition, you specify the “Application” separately,
Note: The Control UI calls Application Server Pools “Cloud App Pools.”
Define the Application Server Pool
This is quite similar to defining a desktop pool. The main differences are:
Location: “Resouces > Cloud App Pools > Add Cloud App Pool” when creating a pool or “Resources > Cloud App Pools > poolname” to edit an existing pool.
Select Template: This is a template that you saved with the Multiuser setting.
Host or Cluster: The DNS name of the Hyper-V host.
Shared Storage: “C:\ProgramData\Microsoft\Windows\Virtual Hard Disks””.
Limit number of sessions on servers: In a desktop pool, this is implicitly set to one, but it can be larger in an app pool. The value you set here should be less than or equal to the value of the MaxSession field in /etc/xrdp/sesman.ini on your template, which defaults to 50.
Define the Application
A new Linux desktop application is defined under “Resources > Applications > Add Application” and an existing one is edited under “Resources > Applications > appname.”
Application definitions have something in common with desktop pool definitions. Gateways and login types, for example, are specified in the same way. For a Linux desktop application, the most important fields are:
Application Type: Cloud Application
Server Type: Workspot Cloud App Pools
Cloud App Type: Cloud App Session Hosted Desktop