The third drop-down section of the main tree manages the Virtual Desktop Infrastructure (VDI) of flexVDI. It is configured through two kind of objects: Terminal and Desktop Policies. Terminal Policies apply to the terminal the user is connecting with, and desktop policies apply to the desktops a user is allowed to access. In order to fully understand these concepts, let's see how the flexVDI Manager decides which desktop is shown when a user connects to the platform:
The user opens a connection with the Manager. The client software identifies itself with a Terminal Identificator (TID). Usually, this TID is shown in the login form of the flexVDI Client.
The Manager uses the TID to look for a Terminal Policy that contains it, or selects the "default" policy (if it exists; otherwise an error is reported to the client).
The Terminal Policy determines how to look for the Desktop Policies that can apply to this connection. Two types of Terminal Policy exist of now:
Unauthenticated (kiosk) policies: It contains a list of one or more Desktop Policies, that is directly returned to the client. Username and password is not needed in this case.
Authenticated with LDAP: The username and password are required to authenticate the user against an LDAP server. If the authentication succeeds, the user entry is checked to see if it contains a list of Desktop Policies for this user. Otherwise, a default list is returned. If the authentication fails, an error is returned to the user.
The client receives the list of Desktop Policies and presents them to the user. The user selects one of them, and the client reports it to the Manager. If there is just one Desktop Policy in the list, it is automatically selected upon reception.
The Desktop Policy determines how to instantiate and connect to a desktop, and the capabilities of the connection. It includes things like the template from which the instance is cloned, what functionalities will be available during the VDI session (clipboard, printers, USB devices, etc) and what happens to the desktop once the user disconnects.
When a desktop has been instantiated, its connection parameters are returned to the client, and the client connects to the actual desktop.
In this section, we will explain in detail how Terminal and Desktop Policies are configured, and the best practices to manage them in a useful way.
A Terminal Policy groups together a set of terminals (flexVDI Client software). When a terminal identifies itself with its TID, the Manager selects a Terminal Policy for it:
It first looks for a Terminal Policy that already has this TID registered.
If the TID is not yet registered with any policy, the Manager looks for a Terminal Policy named after the host name that the client used to establish the connection with the Manager. More later on Named Terminal Policies.
If it cannot find it, the TID is associated with the Terminal Policy named "default".
The Manager then uses the Terminal Policy to get the list of Desktop Policies that will be presented to the user. In an unauthenticated policy, this list is directly stored in the policy. In an authenticated one, the list is retrieved from an LDAP server.
A terminal can be moved from one Terminal Policy to another, or even unregistered. In this way, you can create Terminal Policies for specific groups of terminals, and have a "default" policy for other terminals and the new ones. For instance, there can be a group of public kiosk terminals that require no authentication to connect to a desktop, and the rest of terminals, which must be authenticated.
In the end, the result of applying a Terminal Policy is a list of Desktop Policies, from which the user will pick one. The syntax of this list, in the policy or the LDAP directory, is a comma-separated sequence of items. Each item may be:
A Guest name. When the user connects to the system with a flexVDI Client he will access the console of this Guest.
The name of a Desktop Policy; in our example: "freeAccessRoomDesktop". When the user logs in, flexVDI will present him one of the desktops created with the corresponding Desktop Policy.
Each item may be followed by the text that will be presented to the user in the selection box. For instance, an item can be "w7prox64" or "w7prox64=Windows 7 Professional 64-bit". In the first case, the user will see the text "w7prox64", while in the second case the user will see the much more informative text "Windows 7 Professional 64-bit".
Authenticated policies contain all the parameters needed to query an LDAP server:
Directory server IP: Name or IP address of the directory server.
Directory server port: TCP port of the directory server. Usually, it is 389.
Bind user: User to bind to the directory server. It must be able to make queries on the branch where users are stored. If the Authentication server is an Active Directory, the "Proxy user" may also be composed like "NetBIOS Domain Name"\"User Name" or "User Name"@"Domain FQDN". E.g. "MYCOMPANY\Administrator" or "Administrator@mycompany.com".
Bind password: Password for the bind user.
Search base: Branch of the directory tree where users are searched. Queries are made in subtree mode. E.g. "cn=Users,dc=companyname,DC=com"
Identifier attribute: Attribute of user entries that identify them, e.g. cn, sAMAccountName, uid, email, etc.
Desktop policy attribute in user: Attribute of user entries that stores the desktop policies for each user. You can write a comma-separated list of Desktop Policy names. To simplify user management, flexVDI recommends using an attribute that already exists in your directory schema but is not used. For instance, in an Active Directory, the "info" attribute is hardly ever used and is easily visible and editable with the "AD Users and Computers" tool (it is labeled "Notes").
Desktop policy attribute in group: The same, but for group entries. All users in a group are assigned to a Desktop Policy in this way.
When the Terminal Policy is authenticated, the client asks the user for a username and a password, and passes them to the Manager. The Manager then authenticates the user against the LDAP server and retrieves the list of Desktop Policies. This list is created by merging the values of the desktop attribute from the following LDAP entries:
The user entry.
The entries of any group the user is member of, either directly or indirectly. A user is a member of a group G1 if the user entry contains a "memberOf" attribute with value "G1". A user is also member of a group G2 if group G1 is a member of G2.
If neither the user or any of the groups it is member of contain a list of Desktop Policies, the default desktop policy list is returned.
Finally, a test form is included so that you can check that the configuration is correct. After saving the Terminal Policy configuration, enter a username and its password and click "Test". A status message will inform you of the result, and the list of desktops that the Manager retrieved for that user.
Several desktop policies can be assigned to a user/group instead of one. Simply enter a comma separated list of desktop policy names in the field where you would enter one. You can enter this list:
In the “Default desktop policy” in a terminal policy
In the ldap entry of a user, in the attribute specified by “Desktop policy attribute in user” in the Desktop policy.
In the ldap entry of a group, in the attribute specified by “Desktop policy attribute in group” in the Desktop policy.
This list would look like:
policy_1,policy_2,policy_3 |
If you want your users to see an alternative text instead of the desktop policy name, you can use labels like this:
policy_1=1 Option 1,policy_2=2 Alternate option,policy_3=3 Last one |
For instance, in our public demo we can offer four options to our users, using the following value at the Default desktop policy in the terminal policy
fedora26_mate_public=Fedora 26 Mate,windows10_public=Windows 10,windows7_public=Windows 7,windowsXP_public=Windows XP |
In many scenarios, you will want to have different authentication domains; e.g. different LDAP branches for each department in a big company, or even different LDAP servers for each client in a multi-tenancy platform. You need to create a different policy for each domain. However, manually registering terminals to each policy can be an cumbersome task. Named Terminal Policies solve this problem by associating a Terminal Policy with the host name the clients are using to connect with the Manager:
Create an entry in your DNS servers associating your platform IP address with a different name for each authentication domain. E.g. accounts.mycompany.com and hhrr.mycompany.com.
Create a Terminal Policy for each of these names, and configure their authentication parameters accordingly.
Instruct your users to connect to your flexVDI platform using the appropriate name. E.g. users from the accounts department will enter "accounts.mycompany.com" in the hostname field of the flexVDI Client.
Usually, you will want your "default" Terminal Policy to be authenticated and/or use named policies. In this way, your users will be able to move to new, unregistered terminals (like their phone or tablet, or a new computer) and still be able to access the platform without you having to register the new terminals explicitly. Then, you can create additional unauthenticated policies for public kiosk-type terminals. Other common groups of terminals are classrooms, laboratories, office floors, etc.
Use a desktop attribute that already exists in your LDAP directory schema, but is not in use, so that you do not need to modify the schema. If you are using an Active Directory, a suitable attribute would be "info" (or Comment in the AD nomenclature). It can be easily edited with the "AD Users and Computers" tool, where it appears as a big text box labeled "Notes", for both users and groups.
A Desktop Policy controls how a desktop is instantiated for a user. Most of it was explained when we configured an unauthenticated Terminal Policy in the First steps guide. Here we will go again explaining the meaning of all the fields of a new Desktop Policy. Select the Desktop Policies subsection of the VDI section in the tree view, and you will see the list of existing Desktop Policies. To create a new one, click on the "New Desktop Policy" button. The details view will show the new Desktop Policy form, which contains four tabs:
This tab lets us define general settings about the new Desktop Policy.
Name of the new Desktop Policy.
Template that will be used to create users' desktops. Every time a new desktop is needed, a clone of this template will be created.
Pool from which resources will be taken. New desktops will consume resources (vCPUs and RAM) from this pool. If not enough resources are present in the pool for new desktops, the VDI session will fail and an error will be returned to the client.
Image Storage and Volume that will contain the differential images of the clones. You can select ones you created, or the default local storage.
The default location is "Image storage: Default local storage" and "Volume: Default local volume". These are special values that do not correspond to storage objects created by the administrator. In the hosts, it means the volatile desktops are stored in the directory /var/lib/flexvdi/volatile, in each host. This directory is local to each host, not shared, so while clones can be started in any Host, they cannot migrate to a different one once they are created. For volatile desktops, that have a short lifespan and do not need to migrate, mounting this directory in fast local storage is a good alternative to more expensive shared storage.
Number of precreated guests is the number of cloned desktops that will be created and started in addition to the desktops already in use. When a new user connects to the VDI platform, one of the precreated desktops will be assigned to them, ready to be used, greatly improving the user experience. Then, new desktops will be precreated in the background to keep up with this number.
Disable precreation at is the maximum number of desktops that can be created with this Desktop Policy. The number of desktops currently in use and the number of precreated desktops cannot be greater than this number. In that case, the number of precreated desktops will decrease.
Sysprep file: location to a file (relative to /var/lib/flexvdi/local in the hosts) that will be passed to the new desktops to initialise them with the Windows Sysprep utility. If the path to an executable or script file is written here followed by the pipe symbol (|), it will be run and its output will become the content of the file copied into the Guest.
Windows domain. This domain is passed to the virtual desktop along with the username and password so that the SSO plugin can automatically log into a Windows session.
On the right column, there is a list of the capabilities of the desktops that will be created. These capabilities can be enabled or disabled to limit the features that are available to the users, to prevent information leaks and usage of restricted resources, and include:
USB Redirection: Allow the redirection of USB devices connected to the local machine through the network connection, so that the Guest sees the device as locally attached.
Enable pasting to Guest: Sending clipboard content from local user machine to the Guest.
Enable pasting to Client: Sending the Guest clipboard contents to the user's local machine.
Enable Power Actions. Allow the user to send ACPI commands (shutdown, reset, power-off) to the Guest. These options do not affect the shutdown options given by the Guest OS, but the actions that are performed pushing hardware buttons on physical computers, and can be accessed through the flexVDI Client menu.
Enable Follow me Printing: Allow the creation of virtual printers in the Guest machine that actually print on printers installed on the client's machine.
Enable audio output: Enables audio produced in the Guest to be played through the playback device on the local machine.
Enable audio input: Enables reception at the Guest of the audio received through the input device (microphone, ....) of the local machine.
Enable video streaming: enables streaming of areas of the Guest virtual display device detected as video (animations, games, or more generally content that produces large changes on the screen for more than a few seconds, generating a lot of network traffic) to the flexVDI Client. If disabled, when video on the Guest is detected, it will not be sent, reducing network usage.
Multiple clients: Allows several flexVDI Client programs to share (connect simultaneously to) the same virtual desktop session. This feature is still experimental, but can be handy when the system administrator wants to see what a user is doing in his or her desktop.
Enable file drag&drop. This feature requires flexVDI Desktop Client 3.1 and only works with Linux Guests. It lets you transfer a file to the Guest just by dropping a file on the client's window.
Enable shared folder. This feature requires flexVDI Desktop Client 3.1 and lets the client share a local folder with the Guest.
The feature limitations are applied when a new desktop is created, and they will not change during that desktop's lifetime. If you want to change the features that are available to the desktops of a Desktop Policy, you will have to destroy them first and let the platform create new ones.
This second tab lets us control what happens to the desktops when the users stop using them.
The user inactivity timeout limits the time (in seconds) that a user session stays open when the user does not interact with the desktop (mouse movements or keystrokes). 0 means "no limit".
This page also lets you specify up to three actions that will take place once the user has disconnected from its desktop and the session ends. For each operation you must specify an amount of time and an action. Then, the action will be performed on the desktop that amount of time after the session ends. If the user connects again before the time of an operation elapses, the action is not executed. The possible actions are:
Do nothing
Pause
Suspend
Stop, which will send an ACPI signal so that the guest's OS can orderly halt the machine
Shutdown, which will stop the guest immediately
Destroy, which will stop the guest immediately and remove its state
Pause, suspend, stop and shutdown will leave the desktop in a state that is recoverable. Furthermore, the guest will be started again when its user reconnects. On the other hand, if a desktop is destroyed it will be shut down and its state removed. When the user connects again, a new desktop will be created for him or her.
These operations are best suited to automatically recycle volatile desktops. For instance, if your users connect everyday from Monday to Friday and you want to recycle the desktops on weekends, you can destroy desktops after 1 day. Or you may destroy desktops after just some hours of being idle. Pausing desktops when the users disconnect is also a good way of not wasting CPU resources, because resuming from paused state is almost instantaneous. Using volatile desktops, with precreated instances and automatic recycling provides a great VDI experience.
The Parameters tab shows a table with all the parameters that you created for a Desktop Policy. These parameters lets you assign arbitrary properties to the desktops created automatically by a Desktop Policy. When a desktop is created, a value will be generated automatically for each of these parameters, following a pattern given by the administrator. Values of a parameter can be unique among the desktops of a Desktop Policy, or even among all the desktops of the platform. These pairs of parameter and value are passed to the Sysprep file or script, in order to generate unique configuration files. For instance, this Desktop Policy has two parameters, for an IP address and a host name:
The pattern of a parameter accepts any combination of constant characters and special generator sequences. These generators can be:
Character class generators. They have the form [...]{n,m}, and will generate a string of between n and m characters of those contained between the square brackets. Any combination of characters can be specified between the square brackets, either individually (e.g. [abc]) or as a range (e.g. [A-Z]). The part between brackets can be written as {m}, in which case n = m; or be omitted, in which case n = m = 1. In the example, the hostname parameter is generated with a constant string "host_" followed by a character class generator, that will output an 8-character string of numbers and capital letters between A and F. For instance, "host_DEADBEEF".
Number generators. They have the form \n{min,max}, and will generate an integer number between min and max. They can be either positive or negative numbers, but they must meet the condition min <= max. In the example, the IP address is generated with a constant string "192.168.0." followed by a number generator, that will output a number between 2 and 250. For instance "192.168.0.123".
You can specify the next value that will be used for a parameter in the "Current value" column. Each time a value is used in a new desktop, it is incremented to the next value generated by the pattern, lexicographically speaking. Finally, the "Globally unique" flag sets whether values for a parameter must be unique just among the desktops of the current Desktop Policy or among all the desktops of the platform.
When copying the Sysprep file specified in the Desktop Policy Settings tab to the Guest, its content is parsed, and the appearance of strings in the form ${param} is substituted with the value of the parameter param of the new desktop. Besides, if the content is generated with a program or script, parameters are passed to its process as environment variables.
Finally, the Sessions tab shows a table with the current user sessions of a Desktop Policy. The table is empty on a newly created policy, and is populated as desktops are created when users connect or when the platform precreates them.
For each desktop session, the table show the user it belongs to, the Guest that was created for this session, its state and the dates of last access and exit. The user name can be the one that was used to log in to an authenticated Terminal Policy, or the string "guest-" followed by the terminal ID in the case of an unauthenticated Terminal Policy. The Guest's name is a link that will get you to that Guest's details view. The "Last exit" column will show the value "connected" when the user is currently connected to the desktop. Finally, there are also some tool buttons to quickly control the life cycle (start, stop, destroy, ...) of a desktop session, or all of the session in the list at once.
One of the most common tasks of a flexVDI administrator is to update the template assigned to a Desktop Policy. This can consist in updating the software, installing new programs, applying some patches, etc... In general, any action that modifies a template's disk images. The problem is that a template cannot be directly modified. It must be first converted into a standalone guest, and in order to do so it must have no cloned guests. As a result, a pre-condition to modify the template of a Desktop Policy is to destroy all the desktops cloned from that template. This also means that your desktops must be volatile. More on how to configure your guests so that they are volatile in this page of this guide.
However, in order to avoid destroying the desktops of users that are currently using them while you modify the template, the preferred way of updating a Desktop Policy's template is the following:
In the Guest / Host / Pool section, locate the template to modify, and make a new copy of it with a different name. A best practice is to append the date to the name of the template, like "Windows7_20171130".
Convert the copy of the template into a normal Guest, and launch it (with "Run once", so it does not restart after shutdown).
Open the console of the new Guest, and make any desired changes, as you would normally do on any computer.
After completing the changes, shutdown the Guest and convert it into a template again.
In the VDI section, open the context menu of the Desktop Policy, and modify it so that it uses the new template.
From now on, when new desktops are created under this Desktop Policy, they will make use of the new template. The desktops that were already running with the old template will not be affected. Then, you can configure your Desktop Policy so that the desktops are destroyed when the users disconnect, so that the next time they connect an updated desktop will be created for them. Once all the desktops cloned from the original template are destroyed, it can be deleted if desired.