How Desktop Virtualization Works II

End-User Computing – Simple and Secure


How Desktop Virtualization Works II

End-User Computing – Simple and Secure

VDI Access

Users access VDI with different types of devices:

  • Thin or zero clients
  • Mobile devices (smartphones and tablets)
  • standard PC platforms (Windows, macOS, Linux)

If clients are outside of the corporate network, using WAN, secure access is provided by an additional component – Unified Access Gateway (UAG).

User authentication is done through Active Directory integration, including additional security features such as Single-Sign-On (SSO) and Two-Factor-Authentication.


Figure 1. LAN access


Figure 2. WAN access


Figure 3. Various client devices


Thin/Zero clients


Thin and zero clients are designed for VDI, reliable and straightforward, with low power consumption. They also have a small footprint, which reduces space requirements. These clients are cheaper than standard desktops or laptops, with minimum maintenance required.

  • Zero Clients – contain no operating system, local disk, CPU, or memory resources. With only a PCoIP chip installed, they are extremely energy efficient and easy to administer. No data is ever stored on the device, which makes them suitable for high-security environments. Some of them are configured for specific protocols only, which could be a problem, especially in large environments. Besides, the configuration and use of USB devices can be complicated in some cases.
  • Thin Clients – contain an operating system, disk, CPU, and memory resources. It brings more capabilities but also more challenges in both hardware and software maintenance. These clients support VPN connections and a variety of USB devices.

Optimal device choice depends on many parameters, including the type of work, financials, and overall VDI environment. Some of the crucial factors are:

  • protocol (PCoIP, Blast, etc.)
  • Wi-Fi connectivity
  • VPN support
  • VoIP support
  • maximum resolution and number of monitors
  • graphical processing capabilities
  • security features
  • number and type of ports
  • centralized management capabilities
  • ease of configuration


Mobile devices and standard PC platforms


Users access VDI using Horizon Client software or browser if client installation is not possible (VMware Horizon HTML Access).

Standard PC platforms provide outstanding performance, but that comes with higher costs and more complicated maintenance. One way to lower costs is repurposing older devices at the end of their lifecycle. Both standard platforms and mobile devices are an excellent choice for remote user’s access to corporate VDI.


User profile management


All user environments, huge ones, fully benefit from VDI implementation if the whole process is automated as much as possible. It means the resources are dynamically assigned as needed, at the right point in time, with minimum static, pre-allocated workload capacities. The user logs in and gets the first available virtual machine, which can be different each time. It raises the question of user’s specific data and application settings management.

There are several ways to manage user profiles, depending on specific VDI implementation, Horizon 7 edition, and licensing model:

  • VMware Dynamic Environment Manager (DEM)
  • VMware Persona Management
  • VMware App Volumes Writable Volumes
  • Microsoft FSLogix

Profile management is done through Active Directory integration, using group policies and dedicated administrative templates for Horizon 7. A newer version of DEM can work without AD.


VMware Dynamic Environment Manager (DEM)


Specific settings are kept on the application level rather than complete profile, which provides better granular control. Configurations are kept in separate .zip files for each application (Figure 4). This way, they can be applied on various operating systems, unlike most standard solutions tied to a specific OS. Horizon 7 Enterprise edition is required.



Figure 4. Configuration files (DEM)


VMware Persona Management


This solution keeps the entire user profile, similar to standard Microsoft Roaming Profile solutions. It is available in all Horizon 7 editions, but it doesn’t support RDSH agents and newer versions of Windows 10.


VMware App Volumes – Writable Volumes


Profiles are kept on separate virtual disks and attached to various virtual machines, as needed. Horizon 7 Enterprise edition is required and separate infrastructure for App Volumes (servers, agents, etc.). Virtual disks are in standard .vmdk format, which eases their administration and data backup/recovery. App volumes can be combined with DEM to get a wide range of profile management options.


Microsoft FSLogix


This solution is handy for users without Horizon 7 Enterprise edition who can’t use advanced VMware profile management features. Profiles are kept on network share in VHD(X) format and added to VMs as virtual disks. This way, profile content is not copied at log on, which often caused significant start-up delays. Besides, there are several more optimization features:

  • Filter Driver is used for redirection, so applications see the profile as it was on the local disk; this is important because many applications don’t work well with profiles located on network drives
  • Cloud Cache technology enables part of user data to be stored on local disk and multiple network paths for profiles to be defined; this increases redundancy and availability in case of an outage
  • Application Masking can efficiently control resources based on the number of parameters (e.g., username, address range).

Both 32-bit and 64-bit architecture is supported, including all OS starting from Windows 7 and Windows Server 2008 R2. It is available for all users with any of the following licenses:

  • Microsoft 365 E3/E5
  • Microsoft 365 A3/A5/ Student Use Benefits
  • Microsoft 365 F1
  • Microsoft 365 Business
  • Windows 10 Enterprise E3/E5
  • Windows 10 Education A3/A5
  • Windows 10 VDA per user
  • Remote Desktop Services (RDS) Client Access License (CAL)
  • Remote Desktop Services (RDS) Subscriber Access License (SAL)


Advanced VDI solutions – Teradici PCoIP Remote Workstation


Global data growth requires more and more resources for fast and reliable data processing. Some specific business areas also require very intensive calculations and simulations, as well as complex graphical processing. Standard VDI solutions can’t cope with these demands, and usually, that kind of processing is not moved outside the data centers. On the other hand, many companies need their employees to access corporate resources from any place, at any time.

It can be handled by keeping all processes inside data centers and only transferring display information (in the form of pixels) to remote clients, using the Teradici PCoIP Remote Workstation solution (Figure 5). It is composed of three main components:

  • remote workstation host
  • remote workstation client



Figure 5. Teradici PCoIP Remote Workstation solution


The host can be any standard Windows or Linux platform which does the data processing. The host’s display information is then processed on pixel level by specific PCoIP techniques, encrypted, and sent over a network to the client. The host must have the following components installed:

  • Graphical card (GPU)
  • PCoIP Remote Workstation Card – receives data from GPU and does pixel-level processing, compression, and encoding. This component has three main types, depending on specific requirements and host configuration (Figure 6).



Figure 6. PCoIP Remote Workstation Card


Due to various display information types (text, images, video, etc.), special algorithms are used to recognize each type and apply appropriate compression methods. Moreover, the compression ratio can be adjusted to network fluctuations.

Image from the host is decompressed and displayed on the client side. Clients can be standard PC platforms (desktop/laptop) or dedicated devices (thin/zero clients), with 4 displays maximum, depending on the resolution.

Regardless of client type, security is at a very high level because data never leaves the data center – only encrypted pixels are transmitted. The use of dedicated devices, such as zero clients, additionally decreases the risk of potential attacks and data loss.




As mentioned, every infrastructure is unique, and each implementation depends on many factors. However, some typical scenarios can be used for approximate resource planning and calculation.


Scenario 1. Small and medium environments


The basic option assumes infrastructure for 50 users, scalable up to 200 virtual machines by adding hardware resources and appropriate licenses.

Licensing model is based on Horizon 7 Advanced Add-on (Named/CCU) with separate licensing for vSAN, vSphere and vCenter.

Virtual desktops are created as linked clones which significantly reduces the disk space and eases administration. User data are kept on a network share, with 100 GB per user allocation.

Compute resources consist of 4 hosts in the vSAN cluster with RAID-5 configuration. ESXi operating system is installed on separate M2 disks with RAID-1 protection. Table 1 shows approximate calculation details for the vSAN cluster, and Table 2 shows the host specifications. Licenses are defined in Table 3.



Table 1. vSAN cluster calculation (50 VMs)



Table 2. Host specifications (50 VMs)



Table 3. Licenses (50 VMs)


Scenario 2. Large environments


Besides additional hardware resources, large infrastructures usually need extra features for management, control, and integration. In addition, a certain level of automation is desirable.

This scenario is based on the following presumptions:

  • The number of users is 200, with a possible scale-up to 500
  • Up to 100 GB of data per user
  • Ability to use RDS Published applications
  • Ability to virtualize applications with App Volumes
  • Ability to manage user profiles

The features mentioned above require Horizon 7 Enterprise edition, including vSAN, vSphere, and vCenter licenses. Besides, it enables instant clones for VM deployment, which significantly increases system agility and VM creation speed (compared to linked clones). Licensing model can be both Named or CCU.

User profile management can be done using Writable Volumes – virtual disks assigned to every user, containing all installed applications, data, and specific settings. These disks are attached to VM during logon, so the user profile is always available, regardless of VM assigned. Combined with VMware Dynamic Environment Manager, it can offer a high level of granularity in data and profile management.

The servers used are the same as for Scenario 1, with additional hardware resources installed. All details are listed in Tables 4, 5, and 6.



Table 4. vSAN cluster calculation (200 VMs)



Table 5. Host specifications (200 VMs)



Table 6. Licenses (200 VMs)




Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!

Automation for Better Company Culture

Ansible Automation Platform Overview


Automation for Better Company Culture

Ansible Automation Platform Overview

If we want to do it justice, we could not say that Ansible is just an IT automation platform. Also, if we say that it only saves time making repetitive tasks automated, we will reduce the significance of a project like this. Therefore, I like to say that every part of the IT industry should pay close attention to what Ansible offers.

Why is that? Well, Ansible provides a framework for significant improvements in company culture by eliminating points of misunderstanding between different teams, which leads to better communication and greater employee satisfaction over time. Development, testing, and QA teams, for example, being typical consumers of OS builds, can be sure that they are constantly working on proper base OS configurations while doing their jobs. And this is just the start of Ansible benefits.



So what is Ansible?


We can define it as a configuration management, deployment, and orchestration tool. It aims to be a more productive replacement for many core capabilities in other automation solutions. But, I think the most beneficial aspect of Ansible is portrayed in its endeavors to provide clear orchestration of complex multi-tier workflows, unify OS configuration, and unify application software deployment under a single framework.


Who can use Ansible?


I think anybody who likes elegant solutions on which you can build creatively. This simplicity is shown chiefly in its extremely low learning curve for administrators, developers, and IT managers. Ansible seeks simplicity in building descriptions of IT, and the goal is to make them easy to understand. This practically means that new users can be quickly brought into a new IT project. Likewise, if somebody is away from a project for a long time, longstanding automation content can be easily understood.

Let’s dive into a more in-depth explanation of Ansible architecture!


Platform Components


Ansible Engine – The engine that moves Ansible, relied on the massive, global community behind the Ansible project. It adds the capabilities and assurance from Red Hat to help businesses adopt automation at any scale across the organization.



Ansible Tower – The enterprise foundation of Ansible Automation Platform, helping organizations scale IT automation, manage complex deployments, and govern automation. It allows users to centralize and control their IT infrastructure with a visual dashboard, role-based access control, and more.



Content Collections – Make it easier for Ansible users to get up and running with precomposed roles and modules. Backed by a robust partner network of certified modules, requires less upfront work by the customer.



Automation Hub – The official location to discover and understand Red Hat-supported Ansible content and Ansible Certified Partner content. Find precomposed content written by Ansible Certified Partner organizations and quickly share that content with other users.




Automation Analytics – runs analytics across multiple Ansible Tower clusters, analyzing usage, uptime, and execution patterns across different teams running Ansible. Users can analyze, aggregate, and report on data around their automation and how that automation is running in their environment.



How does Ansible look from the inside?


The keyword here is Playbook. Ansible uses Playbooks to automate IT ecosystems. Essentially, Playbooks are YAML definition of automation tasks, and they describe how a particular segment of automation should be done, and it is human readable. Playbook clearly states what each individual component of your IT infrastructure should behave but still allows components to react to discovered information and to operate dynamically with one another. This responsiveness of Playbooks plays a significant role when you use Ansible for large-scale automation.



If we zoom in and look into Playbooks in more detail, they consist of plays that define automation across a set of hosts, and those set of hosts is called inventory. Each play is composed of various tasks that can target one, a few, or all the hosts in the inventory. A task is a call to Ansible modules, and a module is a small piece of code for doing a specific task. Ansible includes hundreds of modules, from simple configuration management to managing network devices and maintaining infrastructure on major cloud providers. This means that tasks can span from placing a simple configuration file to target machines, to spinning up the entire public cloud infrastructure.

Those included modules in Ansible have a specific idempotency feature, and that means that they check if a particular task needs to be done before executing it. It means that if, for example, we want to start a web server, the configuration is only done if the server is not already started. This ensures that the configuration can be applied repeatedly without side effects.



On top of this, the user can encapsulate the Playbook into a reuseable role. Thus, it can be used if a user wants to apply a standard configuration in different scenarios. I already talked about this at the beginning of this blog. This is the feature that can eliminate a point of misunderstanding between various teams in a company because you can provide the same server configuration role that can be used in the development, test, and production automation. Check out the Ansible Galaxy community site for thousands of customizable roles to build your Ansible Playbook.


Additional benefits: performance and security


Ansible has one differentiating feature that separates it from other automation tools: agentless architecture. It runs in a “push” model, so no software must be installed on remote machines to make them manageable. Ansible uses remote management frameworks that already exist natively on Linux, Unix, and Windows. And now, we have a performance benefit because no resources are consumed on managed machines when Ansible is not controlling them. This ensures Ansible is a go-to solution for automating large environments with concerns about stability or performance. Additionally, this increases security because only Ansible “modules” are passed to remote machines, and thus those machines can’t see or affect how other machines are configured.

Ansible features remoteness on an even higher level because it has elevated security on a higher level. It leverages sudo, su, and other privilege escalation methods on request when necessary. Additionally, it does not require dedicated users or credentials because it respects credentials user supplies when running Ansible. And this is important because those with access to the control server, for example, cannot make content be pushed out to remote systems without also having credentials on remote systems.



Advanced user?


If you intend to be an advanced user of Ansible and want to use it to automate and orchestrate complex environments, there are a set of features that can make your life easier. To name just a few, I like to mention the conditional execution of tasks, the ability to gather variables and information from the remote systems, the ability to spawn long-running asynchronous actions, the ability to operate in push or pull configuration, a check mode to test for pending changes without applying the change and the ability to tag certain plays and tasks so that only certain parts of the configuration can be applied, etc. The best thing about Ansible is that all these features provide a logical framework for automation and orchestration at scale. It can be understood by anyone from the developers to operators to CIOs.


One theoretical example of complex automation


Ansible would not be what it is if it could not do more than just one stream automation tool. Complex orchestration with Ansible can be achieved with zero downtime by combining different tasks into a Playbook. For example, let’s say that the infrastructure consists of:

  • Application servers
  • Database servers
  • Content servers
  • Load balancers
  • Monitoring system

For example, we want to update the whole system, a live and running environment, and we can’t afford downtime. In this case, Ansible can be used to implement a complex cluster-wide rolling update consisting of:

  • Consulting a configuration/settings repository,
  • Configuring the base OS on all machines and enforcing the desired state,
  • Identifying a portion needed to update
  • Signaling the monitoring system
  • Signaling load balancers
  • Stopping the web application server
  • Deploying or updating the web application server code, data, and content
  • Starting the server
  • Running tests
  • Repeating this process for other components or tiers
  • Sending email reports and logging

This is, of course, an exemplary model intended to show one possible Ansible use case. The good thing about Ansible is its modular nature, its ability to extend and cover potentially unlimited automation use-cases. So the question is not how to use Ansible correctly; the question is how you can extend it to apply its features to just the proper case and in just the right way for you.



How to extend Ansible?


It is possible that Ansible module database mentioned above does not contain just the suitable module you need. But, Ansible can accept any code as long as it can take JSON as input and produce JSON as output. That means Ansible is a potent tool for developing new ways of orchestrating and automating infrastructures and has unlimited extensibility potential. So its limitations are pretty much the limitations of the user who uses it for automation.

There is also an extension possibility through support for dynamic inventory. It lets Ansible Playbooks be run against a set of machines and infrastructure discovered at runtime rather than statistically defined. Even the runtime behavior of Ansible can be easily extended by the plugin mechanism. New callback plugins can log to log aggregators, send messages to notification services; new connection plugins can be written to access managed nodes in new ways, etc. So, no matter how custom the environment, you can make it work with Ansible.


Understood by everyone


I’m always for making things simpler and more efficient at the same time. But one important thing in making engineers’ life easier is often overlooked. Of course, we always look for powerful tools that simplify our jobs on a logical level. That is ok and true if we border our view to a single operations team or even an operations department. But we rarely think about how to raise efficiency on the level of the whole organization. This is done by increasing understandability between organization branches or departments, and this is often overlooked. Processes can indeed be simplified, and productivity can rise if all IT teams and departments in a firm have a common language that they can understand.



Ansible can help with this because it can accomplish all types of automation tasks. Yet, it doesn’t resemble software programming languages but rather basic textual descriptions of desired states and processes while being neutral to the types of processes described. Thus, it can be understood even by those untrained in reading those configurations. This is the beginning of, if not the solutions, to the communication issue I mention above, and undoubtedly a good start to implement a DevOps culture in your organization.


Capabilities overview


Now, for the end, let’s dive into a quick tour around basic Ansible capabilities. Red Hat Ansible Automation Platform allows users to take three simple actions with their enterprise automation journey:

  • Create – by using Ansible’s massive open source community and prebuilt Ansible Content Collections of the most-used Ansible roles, plugins, and modules. Codify your infrastructure and share it across teams and individuals.
  • Scale – by easy transfer of your automation into multiple domains and across different use cases.
  • Engage – by taking your automation even further with analytics, policy and governance, and content management with the SaaS-based tools in Ansible Automation Platform. These tools include:
    • Content Collections, a new packaging format that streamlines the management, distribution, and consumption of Ansible content.
    • Automation Hub, a repository for certified content via Ansible Content Collections.
    • Automation Analytics for improving automation efficiencies across Red Hat Ansible Automation Platform deployments.



Breadth of integrations


Red Hat Ansible Automation Platform supports a variety of platforms across servers, clouds, networks, containers, and more to meet you where you are in your automation journey:

  • Operating systems and virtualization: Red Hat Enterprise Linux®, Windows and Windows Server, VMware
  • Networks: Arista, Cisco, F5, Infoblox, Juniper, Palo Alto
  • Cloud: Amazon Web Services, Google Cloud Platform, Microsoft Azure, OpenStack®
  • DevOps tools: Atlassian, Check Point, CyberArk, Datadog, IBM, Splunk

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!