Since we introduced support for Machine Creation Services with Linux VDA 7.18, we’ve seen a lot of growth in Linux VDA deployments with Citrix. That momentum has only accelerated in the last year with the increased need for secure, remote access to Linux workloads due to more people than ever working away from the office. Getting those deployments right is critical to ensuring employees can stay productive, no matter where they are.

Our Linux VDA documentation details all the prerequisites and installation steps for deploying Citrix Linux VDA. But there are some parts of the process that need a little extra care so you can avoid issues when deploying our Linux VDA solution.

In this blog post, I’ll focus on a few common Linux VDA deployment pitfalls we see customers encounter and how you can avoid them so you don’t have to deal with the extra work of re-doing installations and base image creation.

Graphical Desktop Environment Requirement

A Linux VDA needs at least one graphical desktop environment installed on the master image, and you have a variety from which to choose. GNOME and KDE desktops are supported in SUSE 12, RHEL 7, CentOS 7, RHEL 8, and CentOS 8. Unity desktop is supported in Ubuntu 16.04. GNOME desktop is supported in Ubuntu 20.04 and Ubuntu 18.04.

A few customers I’ve worked with didn’t want to have a graphical desktop on Linux VDAs and instead wanted to publish the terminal for users. Even if you don’t have the graphical desktop installed, Machine Creation Services will not fail, and you can still deploy VDAs. However, your application/desktop launch will fail.

No Extra Disk on the Master Image

An extra disk on the master image is one of the most common reason for Linux VDA deployments failure when using Machine Creation Services. Extra disk attached to the master image will give the following error:

No image preparation results found. There may be no suitable VDA installed Or some serious failure in the master VM. Image preparation failed.

Generally, an extra disk is either left attached on the master image because admins don’t know to remove it or prefer the extra disk for purposes like a home drive for users.

Postgresql.service Rename

Postgre SQL is a must for Linux VDA. Linux VDA saves all the configuration items in the Postgre SQL database. Currently there is no alternative of using any other database for Linux VDA.

When a Linux VDA configuration is done using the ctxsetup.sh script, it tries to restart the Postgresql.service. However, the Postgre SQL installation and the file name are version specific. For example, if you install Postgres 13 on your master image, the service name will be ‘Postgresql-13.service’, but the script will look for ‘postgresql.service’.

Because of this difference in the names, you’ll get the following error:

Failed to start Postgresql.service: Unit not found.

The image below shows the error where Linux VDA configuration failed due to failure in starting the postgresql service.

One solution to this issue is to create a copy of the Postgresql-xx.service in the same directory and rename it as Postgresql.service. This way, no changes are required in the Linux VDA configuration script, and it will be able to start the postgresql.service.

Use a Master Image VM from the Azure Marketplace

If you’re deploying Linux VDAs on Microsoft Azure, always use the image from the Azure Marketplace instead of a private offer. There are a lot of publishers for various Linux distributions, particularly due to the availability of bring-your-own-subscription (BYOS) offerings.

Machine Creation Services won’t support an image from a private offer because the plan information is not captured in these images (even if you create a snapshot of the final disk). If you try to use an image that isn’t from the Azure Marketplace, you’ll get the following Machine Creation Services failure error:

Creating a virtual machine from Marketplace image or a custom image sourced from a Marketplace image requires plan information in the request.

Install Dotnet 3.1 before the VDA

Linux VDA 2012 requires Dotnet 3.1 to be installed before installing the VDA. You also need to make sure that you set the path to the Dotnet in the VDA configuration correctly to avoid Machine Creation Services failure and VDA registration issues. Dotnet 3.1 is used by ctxvda service on the Linux VDA. Without Dotnet 3.1 ctxvda service will not be able to start. Due to this dependency, it is vital to install Dotnet 3.1 before installing the Linux VDA.

Supported Method for Integrating with Active Directory

When you check the system requirements for VDA installation, you’ll see which methods — Samba Winbind, Centrify, SSSD, and PBIS — are supported for your Linux distribution. Check out the table below for Linux VDA 2012 as a reference:

This support matrix changes for Machine Creation Services. For example, Winbind, SSSD, and Centrify are supported for VDA installation with RHEL 8.3 and CentOS 8.2. However, only Winbind is supported for Machine Creation Services.

You should consider this before deploying a VDA on your image because, at some point, you’ll have to reconfigure the VDA. The table below shows supported Linux distributions for Machine Creation Services with different AD integration methods.

This guidance should complement what you’ll find in our documentation for Linux VDAs, which includes details on build prerequisites and system requirements. Good luck with your Linux VDA deployment!