Current situations accelerate the demand for virtual desktops and a proper virtual desktop infrastructure. I am working for years in the field of the software-defined datacenter and virtual desktops delivered via VMware Horizon. While standard office virtual desktops have become something like a commodity, the usage of hardware graphics accelerated workload and high-end demand is still kind of ‘newer’ and not as mature as the non-gpu workload.
I am involved in a large scale product that creates a virtual desktop landscape for engineers doing a lot computer aided engineering (CAE). This is a very interesting environment that comes with a lot of difficult user requirements and how it can be solved.
3D Acceleration required during normal “working” operations when modelling / analyzing components. (NVIDA vGPU for the win)
Huge amount of local persistent storage to cache models loaded/checked out from a network location. (vSAN is everywhere in the cluster, included in Horizon Advanced & brutal fast if you do it right).
High throughput between the virtual desktops and the network location (The big benefit of a VDI setup).
Secure access from everywhere & sharing of the session (Another big benefit of VDI).
Windows & Linux Desktops must be supported (Horizon can do that)
Huge amount of memory per virtual desktop since sometimes models can have 100/200GB of size and needs to resist in the memory of the virtual machine. (vSphere scales indefinelty [almost :P]).
Most engineers will require a dedicated linux desktop where he can individually use modules/kernels/packages based on his needs (an IT managements nightmare). (dedicated user assignment with persistent VDIs).
Different working behaviours (more than 500 different user-interaction scenarios) that cannot easily be matched to a single use-case.
Store certain states of the virtual desktop. Loading / pre-processing might take 1-XX hours and needs to be repeated several times (VM snapshots with memory ftw).
Certain Desktops should be shared among team-members (working in parallel or sequential).
I am currently working on some datacenter migration and during one of the tests we ran into an issue where the provisioning of linked clones was not working properly.View Composer Fault: ExceptionTruncatedFault
View Composer Fault: ExceptionTruncatedFault
After the replica cloning process, all relevant VM files have been deleted. I had this issue in the past and I remembered that it might have been related to some networking problems.
Two weeks ago I had the pleasure to spent 4 days on problematic Applications within an App Volumes environment of a customer. The best thing that can happen to me as an infrastructure guy is to work on building AppStack with guys who know how to package and therefore troubleshoot those applications. Bringing together the knowledge from multiple domains helped us to fix the problems that we had so far with App Volumes.
Common issues we have been faced with:
During the AppStack provisioning process an Application was not able to get installed
(Crappy) Applications put user-data-files into C:\Windows
Start-Up Performance of applications was really really slow (factor 20x slower)
A mounted AppStack leads to a repair of Office-components
One of the common problems I have seen with App Volumes in the past. The infrastructure can be designed and delivered by an Infrastructure guy -> As soon as we talk about applications. We or more correct the organization that is planning to create AppStacks needs application packaging expertise.
So let’s make it quick. I will give you some hints how some of your problems might get solved.
Over the last months I gathered more and more experience about VMware’s secure Linux appliance that allows secure access to a virtual Desktop (and more) over an unsecure network (e.g.) the Internet: Unified Access Gateway (UAG).
Keep in mind the UAG is not just a replacement for the old Windows based Security Sever, it is also offering much more functionality (Edge Services for Airwatch / Workspace One, reverse proxy, 2nd-factor authentication integration, etc.).
There might be use cases where we want to design our horizon environment in a way that we use the UAGs not just for external unsecure access, but internally as well.
Offering access to internal users coming from a not so trust-worthy site/location (including a second-factor authentication for those users). // Access restricted via Firewalls/ACLs
Constraints to always use tunneled connections (because of network-simplicity or security constraints).
Within the vSphere world we have currently one goal regarding our vCenter. Migrate it from a Windows based installation to the vCenter Server Appliance (vCSA).
The doing of this migration is pretty straight forward and works pretty well (e.g. here). But since we will shutdown the original vCenter VM based on Windows afterwards we need to make sure how to deal with applications that were running besides the vCenter.
We need to migrate them as well. Especially in case of the Horizon View Composer we need to do some proper planning, otherwise our linked-clones (which require the composer) cannot be created and maintained anymore (refresh, rebalance, recompose (R-R-R) operations).
Doing that migration is quite straight-forward. But we need to do some specific and not very well known tasks before we can do all of the steps.
Goal: Migrate the vCenter to the vCSA and get rid of all currently used Oracle Databases within the VMware vSphere & Horizon environment.
Define a Maintenance windows and make sure no further Horizon View maintenance operations takes place (R-R-R).
Backup the Horizon Composer Database with the included View backup mechanism.
Create Windows Server for the Composer (compvm)
Create a Database for the Composer and the corresponding ODBC connection.
Restore the Backup on the compvm
Repoint Horizon within the View Admin to the new Composer
Sometimes I really love the #vCommunity – Just kidding: I love them all of the time. I was confronted with a scenario where only certain users of a Horizon environment should be allowed to access their own Desktop via the Internet.
In general you have certain options to do some kind of restrictions:
Using Tags on the Connection Server and Create Desktop Pools that only allow the usage by Users coming from a tagged Connection Server
Using VMware vIDM (Identity Manager) and create conditonal access rules. This will work, but will also create some new overhead to implement vIDM in a high-available fashion.
Fortuneatly the EUC-Champion Slack Community came up with another idea I haven’t really heard about before (The feature was introduced with Horizon 7). Thx Sven and Joe for your help here.
During (and around) VMworld 2017 VMware has lifted many of their products to a new level to enable their customer a better and more agile software-defined datacenter than ever. Besides their datacenter portfolio VMware is pushing their vision of a digital workspace in the end-user computing field much further.
Horizon + Airwatch -> Workspace One try to combine all relevant subjects within the EUC field (Identities, Desktops, Applications, Devices, Policies, … ) within one single solution.
The following post summarize the EUC announcements within VMware’s current and upcoming products.
The following section shows you how to make use of VMware’s Unified Access Gateway (UAG) Appliance to give the enduser access into our virtual Desktop / Remote hosted Applications over an unsecure network like the Internet.
When we are creating this access we have multiple options.
Using a VPN to ‘tunnel’ into the secure cooperate network environment and connect further to the Horizon View environment.
Placing a Windows Server in the DMZ and installing/configuring the Horizon View Security Server and make it public accessible.
Placing the virtual Unified Access Gateway in the DMZ and installing/configuring the Horizon View Security Server and make it public accessible.
What is the / my recommendation nowadays? Go with the Unified Access Gateway. Why?
It is a general opinion within Security experts that a Windows, even if it’s hardened, offers more attack potentials than a hardened minimal linux.
Using the Windows based security server creates a 1:1 relationship between the Security Server and the Connection Server, therefore it takes away some access flexibility.
The UAG is getting more and more features to integrate other solutions like specific Airwatch functionality
You can make use of the UDP based Blast Extreme Protocol Adaptive Transport protocol that gives you a better remote/user experience even if you are connecting over a lossy network
It is much easier to operate than the first Access Point versions VMware has made GA a few years ago ;-)
One important aspect of the UAG is that you need to know about the packet-flow between the Horizon Client and the Desktop. You will be dependant on the networking and security guys. Make sure you are able to clearly articulate the requirements and what is going to happen. If you can tell the flow, the other people will be able to help you much better.
In the following article I am going to tell you how easy it is to set up a load balanced Horizon View environment. But remember: Just because something is easy to install it is not necessarily easy to design. There are multiple design affecting factors I am going to discuss in my #design guide. There are many Installation Guidelines out there, so I will keep it quick and simple and try to give you some hints what to do or not to do.
What do I want to achieve or show to you in this blog post?
Creation Redundant Connection Server to access virtual Desktops
A redundant Load Balancer in front of it (#NSX ftw)
Internal Access only – I spent a lot of time with the Unified Access Gateway and show you in the second blog post about how to enable access over the Internet into your Horizon Homelab
The Connection Server is a core component within our Horizon View environment. It gives us the opportunity to create Desktop Pools out of Windows / Linux machines or Application Pools (based on Microsoft RDSH-Hosts) and entitle them to any Active Directory User in our environment. It offers us the following key functionality
Brokering between Endpoints (that have the Horizon Client installed) and a virtual Desktop / Remote Desktop Session Host (Application)
Authentication Handler (AD only or 2nd factor)
View Administration via web-based (Flash :-/ ) user interface
HTML5-Client to access the Desktops/Applications without the need of a client
Connection to the vCenter Server to create new VMs / Desktops
This section within my VDI series is not just relevant for VDI environments. In the following I will cover many things that are relevant for regular vSphere (cloud-a-like) environments.
The Management & Virtualization Layer plays quite an important role within a VDI environment. Within EUC solutions we typically should focus on the User and the User experience. But before we can deliver a performant, reliable and available working environment we need to make sure the layer on the bottom is rock solid as well.
What is the purpose of this layer?
Hosting Instances of Virtual Desktops
Hosting Instances of Remote Desktop Session Hosts (RDSH)
Hosting Management components
Components for brokering between Endpoints (Desktop User) and the Virtual Desktops Horizon View)
Components for Integrating with Virtualization Management (Horizon View & vCenter Server)
Delivering Applications into the Virtual Desktops (App Volumes)
Monitoring of the Environment (e.g. Icinga)
Operations Management (vRealize Operations Manager and Log Insight)
Management of the Virtual Machines (aka Desktops / RDSH Hosts) and the Hypervisor (vCenter Server)
Component for managing Security relevant components (NSX-Manager)
In my design guide I will write about general design decisions regarding the management & virtualization layer. In my implementation guide I will give you hints about the setup of the environment.
The goal of this post is to describe / discuss design implications, design decisions and characteristics for the following relevant Products within the core Layer in their most current release: