Xtravirt — Horizon View App Publishing & Custom Icons

by Curtis Brown

Introduction

VMware have long been a presence in the virtual desktop market – even ignoring their own VMware View® product, vSphere® is used to support other brokers, such as Citrix® XenDesktop. Regardless of product set, a common problem is how to deliver applications to the desktop.

Let’s have a bit of background. Most applications are provided as either a batch of files dropped in place on an end point, while others are provided using an installer application of some sort. This is generally the case regardless of operating system, but let’s focus on Microsoft Windows® as this is most prevalent.

Historically, most application delivery systems have been focussed on pushing down the binaries to a system and installing as required. This approach has a number of limiting factors – it takes time to download the package to the machine and install the application, not to mention in many cases, the application would need a reboot, causing further disruption. This was acceptable for physical PCs and Laptops as these are persistent devices on the whole so a little disruption is manageable.

Of course, one of the key benefits of virtual desktops is supposed to be flexibility and rapid delivery – so spinning up non-persistent desktops, only to have them scuppered by long application delivery times meant other measures were necessary.

Building applications in the base build is very common, but far from efficient, particularly if the application is only used by a user subset.

Application Virtualisation solutions such as VMware® ThinApp answer a number of issues, notably the sandboxing of applications which prevents the need to reboot, and streaming over the network improves delivery times. However, there is still the time-to-deliver over the wire (especially with large applications), plus Application Virtualisation will not work with all applications (such as those with device drivers or Windows Services).

Most organisations would fall back to persistent desktops or Remote Desktop application delivery solutions such as Citrix XenApp to make up the short fall, but there is another way.

CloudVolumes to VMware App Volumes™

CloudVolumes was founded back in 2011 with a simple premise – publish applications using a virtual disk container as a delivery mechanism to a hosting operating system using an agent that merges the virtual disk contents with the operating system partition. VMware scooped them up in 2014 and re-branded the technology as App Volumes.

By using a Virtual Disk as a container, you can collect multiple applications in a single virtual disk (an AppStack) and push them out together. Of course, in a virtual infrastructure, this disk sits on shared storage, alongside the virtual desktop, so delivery time is reduced to how fast the solution can mount the virtual disk.

The other clever feature of this ‘agent plus disk’ affair is that the AppStack disk is read-only (I’ll discuss where changes go later). Being read-only means that the single disk can be shared by many desktops (on SSD, potentially 1,000-2,000 per disk) – doing wonders for scaling and storage efficiency.

So, consider our non-persistent VDI example. Both VMware and Citrix can spin up a non-persistent desktop based upon a template Windows operating system installation in next to no time. The user logs on to the client, the agent takes the identity of the user and pushes it to the App Volumes management server which, in turn, subject to entitlements, attaches the relevant AppStacks to the user’s desktop. All this happens as the user logs on. No mess, no delay – and consistent too.

Creating an AppStack requires only a basic Virtual Machine to serve as a provisioning desktop. A blank AppStack is assigned to this VM in a provisioning mode (read-write) – applications are installed as required. Once it’s ready, it can be entitled to Active Directory users, groups or even computer objects. AppStacks can be assigned to a VM at either boot up, log on (or immediately – though this is not recommended).

App Volumes and Terminal Servers

A clever use case for App Volumes is in conjunction with Terminal Servers. By assigning a common AppStack to a farm of Windows 2008R2/2012 VMs running as a Terminal Server (for example Citrix XenApp, VMware View RDSH), it’s possible to rapidly deploy a consistent farm. A really nice side-benefit is that if you want to re-allocate hosts between multiple farms with different applications, this is possible simply by changing AppStack and re-assigning the host – it’s no longer a rip-down and rebuild affair.

So AppStacks are read-only – what about writing back?

A mighty fine question. If you need to make writes back to an application installation, they are written to the C: drive of the VM (as you’d expect) – don’t forget, our AppStack is invisible – the C: drive is merged.

While many applications drop configuration changes etc. in the user profile, some less than well written ones do tweak content in the installation path. This isn’t too useful for non-persistent applications – such setting changes would be lost as soon as the non-persistent desktop is destroyed. However, another App Volumes feature comes into play here – Writable Disks.

A Writable Disk is a user-specific disk (so one per user) that can be deployed alongside AppStacks (it’s always the last one attached). This too is merged and is otherwise invisible. A Writable Volume can be deployed to support three policies –

• User Profile only – basically, it can replace VMware View Persistent Disks for User Profiles. Don’t consider it as a replacement for a proper environment management solution though.

• **User Installed Applications only ** – so it can manage user writes to the C: drive excluding the user profile.

• **Profile and User Installed Applications ** – a policy covering both of the above.

This disk, particularly with the latter policy is a powerful tool. As it can capture writes back to the OS disk, it provides the ability to capture writes to applications in AppStacks as well as allowing the user to install their own applications (subject to user rights, of course). The implication of this is that it’s possible to deploy a non-persistent desktop and allow it to behave in the same way as a persistent desktop!

Maintaining Applications in an AppStack

This is a pretty straight forward affair. There’s an edit function in App Volumes that effectively clones the current version of an AppStack. This can be attached to a VM in a read-write manner and the application stack upgraded, enhanced etc. prior to being assigned as a replacement for the existing stack. Don’t worry – rolling back is easy too – just re-assign the previous version.

Nice. So….what’s the catch?

As with everything, there are limitations.

Multiple AppStacks can conflict

An AppStack can contain multiple applications, some of which might include shared components, such as specific Java versions, DLLs etc. Presenting multiple AppStacks can have a negative effect – AppStacks are applied in sequence, with the last one applied taking precedence. For example. AppStack A has an application which uses wibble.dll version 1.0, while AppStack B has an application that uses wibble.dll version 2.0. If both AppStacks are assigned to the VM, and AppStack A is attached last, then the application in AppStack B might fail due to wibble.dll 1.0 taking precedence.

There are three ways around this issue:

• For a given application, try deploying it as a ThinApp package inside the AppStack – The virtualised application sandboxing avoids conflicts.
• Override the order in which AppStacks are deployed – this is possible from the App Volumes Manager.
• Plan your AppStacks – try, where possible, to group applications for a department together to minimise the need to deploy multiple AppStacks.

How many AppStacks can you deploy to a VM?

In many ways, this is a limitation of the technology – You’re mounting virtual disks – the more you mount, the longer the log on time. In addition, the more you mount, the more you might risk application issues between AppStacks. VMware recommend less than 15 disks, including AppStacks and Writable disks.

Try not to look at this as a solution for delivering granular applications – use it to shift stacks (the clue is in the AppStack name…). Generally, in most environments, departmental users have applications in common – so using AppStacks containing a common stack can be used to meet 90-100% of a user’s needs in this manner – if granularity is required for the last 10%, consider using Writable Disks, either allowing the user to install their own or using Writable in concert with an alternate delivery system such as SCCM or VMware Horizon® Workspace published ThinApp packages.

Kernal mode content

AppStacks are pretty powerful. Even device drivers and services are possible, however anything that needs direct access to the kernel is a problem – so deploying a PDF printer will work, but deploying an Antivirus tool or disk encryption software probably won’t.

Doesn’t support Windows XP or physical devices.

At present, App Volumes doesn’t support physical devices – for that, you can use VMware Horizon Mirage App Layers for a similar experience.

As for Windows XP – No support here either and this is a good thing. Time to move on – ye olde Windows XP is not in support any more!

Closing Thoughts

So, for delivering applications to a VDI solution, App Volumes is a really slick answer. Provisioning of stacks of applications in a LAN-free rapid manner is an attractive selling pitch, especially as it can support not just virtualized application packages, but full, natively installed Windows applications. The writable disks are a bonus too – the combination of non-persistent desktops, AppStacks and writable disks makes a compelling case for ditching persistent desktops in nearly all scenarios.

The interesting part is that it is (and will remain) broker agnostic. It can be delivered as easily in a Citrix XenDesktop/XenApp solution as it can a VMware Horizon View solution. This is why VMware now offer App Volumes as part of the new Horizon Application Management Bundle – a suite that takes VMware Horizon solutions that complement an existing Citrix solution.

Otherwise, VMware App Volumes is now included as part of the VMware Horizon Enterprise suite or can be purchased individually.

If you’d like any assistance with a VMware App Volumes project or simply want to learn more about it or any aspects of VMware Horizon please contact us, and we’d be more than happy to use our real world experiences to support you.

by Curtis Brown

Once upon a time (in the mid 2000s), VMware decided to delve into the End User Compute market space, taking on the juggernauts of Citrix and Microsoft by releasing VMware Virtual Desktop Manager (VDM). This evolved into VMware View in 2008, and over the following eight years a further re-branding exercise resulted in the release of the VMware Horizon Suite. Our plucky VDI software evolved into VMWare Horizon (with View) then Horizon View with the release of version 6.0, and finally in version 7 ‘Horizon 7’, with the name ‘View’ reserved as a hangover legacy name for the VDM components.

So, as a customer, you’ve decided to invest in VMware Horizon.  These days, Horizon is much more than simply a means to deliver a desktop to a user.  With the modern realisation that the user isn’t really after a desktop (they just want their applications), Horizon is now, more than ever, a suite of products that allow you to deliver applications in a multitude of ways.

This article aims to provide you with a quick primer on these products and how they fit together.  For the sake of simplicity, it will stick to the on-premises offerings, largely as these are still the most common ‘in the wild’, though Cloud based elements, such as AirWatch, are gaining ground.

The Shopping List

Let’s start by exploring the suite from a component level.  The suite comprises the following products*:

Product License Level What does this do

VMware Horizon (

the View component)

Standard

Advanced

Enterprise

Delivers Virtual Desktops as either dedicated VMs or via Remote Desktop Session Hosts (RDSH).

The latter ability is also used to deliver Published Applications (Not in Standard though).

VMware ThinApp Standard

Advanced

Enterprise

This is what is known as Application Virtualisation.  An application is re-packaged in a self-contained executable that can be run on a Windows PC (physical or virtual).  The self-contained nature means that it is essentially sand-boxed – with minimal dependency on the surrounding operating system (required DLLs, configuration etc. are self-contained)

VMware Identity Manager Standard Advanced

Enterprise

This provides user facing authentication and single sign-on (SSO) capabilities as well as an application portal for presenting Virtual Desktops, Remote Applications, ThinApp packages and web-based applications.

The SSO element can be used to provide immediate access to Web based applications if these are capable of SAML-based authentication.

_Beyond Horizon, Identity Manager is available in an Advanced version and as part of AirWatch.  These provide additional features, notably in Mobile Device management including device configuration, remote wipe etc. _

VMware App Volumes Enterprise This product provides the means to deliver defined stacks of applications (AppStacks) to virtual desktops or RDSH servers instantaneously using shared Virtual Disks.

This is quite agnostic – and can be purchased and deployed with other VDI solutions such as Citrix XenDesktop.

VMware User Environment Manager Enterprise This is used to manage user’s Windows Profile – the users environmental and application settings.  The Windows profile is notoriously large and unreliable, especially in a roaming context.  UEM provides a means to streamline and centrally manage the Windows profile, so improving log on times and reliability.

As with App Volumes, this too can be purchased and used outside of Horizon – including with physical devices.  In this context, its central management of settings is particularly useful.

If you’re using Standard or Advanced, the View part of Horizon includes the older Persona Manager product.  This uses a compressed version of the Windows Profile to speed up the delivery of Roaming Profiles to virtual desktops.

VMware Mirage AdvancedEnterprise This provides a layered-image based desktop management solution. Although it can be used in Virtual Machines, it is primarily aimed at the management of physical Windows PCs in a corporate environment.

Its abilities include in place operating system upgrades and the delivery of sets of applications that are layered on top of the base image.  This makes it quite attractive for Windows XP/Vista migrations for example.

VMware FLEX is based on VMware Mirage, combining its technology with that of VMware’s desktop hypervisors – Workstation (for PC) and Fusion (for Apple Mac) – to deliver centrally managed, encrypted offline Virtual Desktops.  This is predominantly intended for BYOD or field staff who require a corporate desktop in a roaming context where connectivity to Horizon might be difficult.  It’s not part of the Horizon Suite and is sold separately.

*the components you’re entitled to depends on the level of licensing you’ve purchased

The Horizon Suite also includes VMware vSphere for Desktops.  This is functionally equivalent to Enterprise Plus in terms of features, but is licensed per desktop.  The idea is that this is used to host the published desktops while the Horizon infrastructure servers are hosted in the corporate server estate.

How it all hangs together…

The following diagram shows how the platform holds together as a single site solution.  This is a somewhat simplified example with no resilient components, firewalls and load balancers and concentrates on Internet based access.

We can see how our user initially connects from their device to Identity Manager.  The user’s device and location can define how they authenticate – for example, access from the outside might need Two Factor Authentication, whereas an internal user might just need an Active Directory Used ID or password.

Once authenticated, the user can see the applications they are entitled to.  Let’s first look at a Cloud based application such as SalesForce.  If the user selects this, Identity Manager (having already been configured with a SAML relationship to Salesforce), passes the user authentication as a token to the user’s browser accessing the Salesforce application – without them needing to log on a second time.

When considering an application or desktop presented by Horizon View, the request is passed to the Connection Servers.  These will initiate a session to an available desktop (either VDI or RDSH, depending on what is requested) – in the case of VDI desktops, these can be provisioned as Linked Clones using Composer.

As the VDI session is logged on, the App Volumes Agent detects the credentials and App Volumes mounts an entitled AppStack containing the application required.  The user’s Windows Profile is provided via UEM.  For internet-based users, the View session is tunnelled out via the Security Server/Appliance in the DMZ.  Internal users connect directly to their session (though this can be configured to tunnel via the Connection server).

ThinApp packaged applications may well be deployed to the Horizon desktop (possibly inside the App Volumes AppStack), but as an alternative, if the Workspace ONE client is installed, Identity Manager can stream a selected entitled package directly to the user’s Windows laptop/desktop, straight from the Identity Manager Portal (this isn’t shown above).

Alternatively, VMware Horizon Mirage can be used to manage and protect our PCs, whether within the network or outside (via the security gateway in the DMZ).

Closing Thoughts

The Horizon suite has quite a few elements, each delivering different pieces of the puzzle – even in a basic configuration.  However, in concert, the solution is quite seamless to the end user.  The single point of access and authentication becomes Identity Manager, with this presenting all the entitlements desired through a single pane of glass.

If you’d like to learn more about VMware Horizon and how to use it to deliver applications to end users, please contact us and we’d be happy to use our wealth of knowledge and experience to assist you.

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strength in VDI, storage integration, backup and Disaster Recovery design/implementation. He is a VMware vExpert 2017.

By Curtis Brown

Introduction

VMware PowerCLI has been in existence for quite some time and over the last 2 years it has been moving at quite a rapid pace.  It has traditionally been used to provide PowerShell based command and control functionality within VMware vSphere environments, with particular focus on the ability to create scripted functions for automation purposes.  Used in conjunction with automation and orchestration tooling, a great many bespoke capabilities are available.

During 2018, there has been a release around every 2 months, the current release, version 11 was released in October and provides support for the following:

• vSphere 6.7U1
  
• VMware Horizon 7.6
  
• NSX-T 2.3
  
• VMware Cloud on AWS
  

Being based on PowerShell, it is also compatible with third party modules, such as those administering Active Directory, to provide an integrated solution across a wide range of products.

In this blog, I look at PowerCLI’s ability to support VMware Horizon.

Installing VMware PowerCLI

Installing PowerCLI was once a case of downloading an installer from the VMware Portal and installing the components.  However, PowerCLI is now published from the PowerShell Gallery on the internet (https://www.powershellgallery.com/packages/VMware.PowerCLI/11.0.0.10380590) permitting installation on a connected PC straight from the PowerShell interface, simply by running:

Install-Module -Name VMware.PowerCLI

You might get something like this (accept the default):

Then it’ll install…

To allow execution of local scripts:

Set-ExecutionPolicy RemoteSigned

Then, run the following to confirm it’s all installed successfully.

Once installed, it’s worth configuring the Customer Experience Program participation by Enabling or Disabling this (It stops nag messages).

Set-PowerCLIConfiguration -Scope User -ParticipateInCEIP $true $false

After that, the basic PowerCLI is ready to go.

What can we do for Horizon?

‘Out of the box’, PowerCLI only provides  the ability to connect or disconnect to the Connection Server, so providing a conduit for accessing the Horizon APIs.  To connect to Horizon Connection Server:

Connect-HVServer -Server connectionserverFQDN -user adminuser@domain -Password XXXX

However, VMware maintain example scripts at https://github.com/vmware/PowerCLI-Example-Scripts that can be used as a basis for automation of Horizon and the other supported components.  

By downloading the scripts as a ZIP file, it is possible to install them.  First, check $env:PSModulePath to locate the modules directory paths (usually, there’s the user specific path, plus system ones)

For Horizon, we extract VMware.hv.helper from the ZIP and drop this into C:\Program Files\WindowsPowerShell\Modules.

In PowerShell, we then unblock the newly exported folder by running

dir ‘C:\Program Files\WindowsPowerShell\Modules\VMware.Hv.Helper\’ | Unblock-File

With this in place, we can now use a whole raft of useful PowerShell commands (they can be listed by using Get-Command -Module ‘VMware.Hv.Helper’). These can be used for automation of tasks and generating reports.

For example, Get-HVPoolSummary will list configured pools, including their type, assignment type and status:

And we can see how many VMs are available:

Get-HVHealth shows a basic status:

By leveraging the ‘New‘ and ‘Remove’ commands, it is possible to provision and destroy new Pools (desktops and applications), entitlements, RDS Farms and Cloud Pod objects such as Sites and Entitlements.  For Example, setting up Shared Desktop pool ‘Teachers 1’:

Closing Thoughts

What we have here is a set of powerful tools that are not just capable of managing the VMware vSphere infrastructure, but can also expand into the realm of delivering desktop pools – all from scripting and automation.  For example, it would be possible to create a script that would leverage PowerShell to create an Active Directory Group and populate it, then create a desktop pool and grant the members of the group access to it.  Further, this could be used in concert with vRealize Automation and Orchestration to provide a portal for self service requests for generating desktop pools and services.

Given that the current release supports VMware Cloud on AWS as well as VMware Horizon, this offers the tantalizing prospect of being able to programmatically manage a federated on-prem and AWS hosted Horizon Cloud Pod Architecture.  The sky is the limit!

If you’re planning to deploy a Virtual Desktop solution, we can help. Xtravirt provide design and implementation services to create the right solution for your organisation. Contact us and we’d be happy to use our wealth of knowledge and experience to assist you.  

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strength in VDI, storage integration, backup and Disaster Recovery design/implementation. He was awarded VMware vExpert 2018 and is a graduate of the VMware Advanced Architecture Course 2018.

About Xtravirt

Xtravirt are an experienced consulting firm dedicated to delivering outcomes to help customers solve their IT challenges. We design and build strategies to help customers unlock the full potential of cloud, datacentre and workspace technology.

We are the VMware Global and EMEA Professional Services partner of the year.

www.xtravirt.com

by Curtis Brown

Introduction

What is GRID?

New Hardware - M6 & M60

Onto the PoC…

Installing the infrastructure

Laying out the GRID

• The Nvidia GPU Mode Switch tool
• NVidia GRID 2.0 software package
• Nvidia GRID 2.0 License server.

GPU Mode Switch

• To check the current mode run gpumodeswitch --listgpumodes
• If the mode needs to be changed to graphics, run gpumodeswitch --gpumode graphics

Installing the VIB

Prep the Nvidia License Server

Configuring the VM for View and 3D acceleration.

Closing thoughts

About the Author

by Curtis Brown

VMware App Volumes are installed with a self-signed certificate, as is common with most products that install with components using certificates, however, this is obviously not the preferred option.  But fear not-help is at hand!

Let’s assume you’ve deployed a VMware Horizon View estate properly and you’ve deployed this with a Microsoft CA signed cert – so you already have a Web Server template cloned out and good to go.

Preparing Certificates & Keys

The first step in preparing certificates and keys is to grant the App Volumes Manager server the rights to read/write and enrol with the certificate template – a bit like this:

Then, as with a View Connection server, you can import the certificate into the computer store on the App Volumes Manager server.  This is carried out using the Certificates console, making sure the Subject Name is set to the value you want (the name of the server or the load balancer name – Subject Alternates might be nice too).

You then export this as a PFX file, making sure you export the private key and note the password.  You can drop that in a folder – let’s call it c:\temp\appvol.pfx.

The next bit is breaking this PFX into a certificate and a key file.  You need openssl to do this (tip – VMware tools has a copy).

First, let’s break out the Key file.

openssl pkcs12 -in c:\temp\appvol.pfx -nocerts -out c:\temp\appvol1.key

You’ll need the password for the PFX.  (If you don’t have this, go have a coffee and try again.)  You’ll then be prompted for another password – this time one to protect the key file.  This can be a good thing; however, you can unprotect the key using:

** openssl rsa -in c:\temp\appvol1.key -out c:\temp\appvol.key**

This is useful for AppVol’s NGINX web server as you either protect the key and put the password in clear text in the nginx.conf (see the next step) or just unprotect the key and not worry.  I tend to do the latter.

Next, you need to export the certificate.

openssl pkcs12 -in c:\temp\appvol.pfx -nokeys -out c:\temp\appvol.crt

This gives us a .key and a .crt file.

Let’s drop these in C:\Program Files(x86)\CloudVolumes\Manager\nginx\conf

Replacing the certificates

In the same path that we’ve dropped our files, you’ll find nginx.conf.

You need to edit this. Using Notepad will be fine but take a backup of the file first.

Look for the ssl_certificate entries and replace the filenames with the new files.

Restart your App Volumes Manager Service (or bounce the box if you must).

Connect with the web browser to test:

You now have App Volumes with a trusted certificate and SSL Encryption is good to go!

Closing Thoughts…

In all seriousness, in these days of hackers and generally bad stuff, we need to make sure that we take appropriate measures to harden an estate.  Using signed certificates prevents numerous attack approaches and is certainly worth the effort.

If you are developing an end user compute solution and need assistance designing and deploying the solution in a secure manner, please contact us and we’d be happy to use our wealth of knowledge and experience to assist you.

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strength in VDI, storage integration, backup and Disaster Recovery design/implementation. He is a VMware vExpert 2017.

By Curtis Brown

The somewhat anticipated release of VMware vSphere 6.7 Update 1 is now with us.  So, the burning question now is “Can I upgrade?”.  The answer is not quite as simple as a yes or no as this is always a mine field, particularly where interoperability is concerned.  My intention with this article is to save you some of the leg work with respect to investigating product interoperability.

However please note, this article doesn’t dig into hardware compatibility, or compatibility with third party products, simply because of the vast array of possible scenarios.

Compatibility with Horizon View 7

The most common starting point is VMware Horizon 7 itself.   By checking the VMware product Interoperability Matrix, we can see that the minimum release of VMware Horizon that is validated with VMware vSphere 6.7 Update 1 is the latest release, 7.6.

VMware Horizon 7.6 - COMPATIBLE

VMware App Volumes

VMware App Volumes 2.14 and the more recent patch release are both listed as a valid configuration.  This would also be the recommended release for use with VMware Horizon 7.6, although it has quite a generous level of backward compatibility.

One observation of note is that the poorly adopted cul-de-sac release 3.0 product has not been validated against 6.7, but as this was explicitly incompatible with 6.5, so this is not particularly surprising.

VMware App Volumes 2.14.2 - COMPATIBLE

VMware vRealize Operations for Horizon

With respect to VMware vRealize Operations support in general, release 6.6.1 or later is required.  This is driven by vSphere rather than Horizon which can work with older vROps releases.

For a VMware Horizon environment running on VMware vSphere 6.7 Update 1, the VMware vRealize Operations for Horizon plugin needs to be on 6.6.0 to support VMware Horizon 7.6 to retain compatibility through to VMware vSphere.

However, care should be taken with the compatibility between the Horizon plugin and vRealize Operations itself.  As the Horizon component only supports Horizon 7.6 directly on release 6.6.0 of the plugin, the interoperability matrix dictates that VMware vRealize Operations should be running on release 6.7.

VMware vRealize Operations Manager 6.7 - COMPATIBLE
VMware vRealize Operations for Horizon 6.6 - COMPATIBLE

Of course, for features, guest operating system compatibility, the latest version is recommended.

VMware User Environment Manager 9.5 - COMPATIBLE

VMware NSX for vSphere

Although not every VMware Horizon deployment uses VMware NSX, it’s included to flag a possible concern. With respect to straight VMware vSphere interoperability, VMware NSX for vSphere 6.4.2 and 6.4.3 both support for vSphere 6.7 Update 1.  However, the supported Horizon release (7.6) has yet to be validated with NSX 6.4.2 or 6.4.3.  This is  unlikely to cause an issue, and validation is likely to be only a matter of time, though it may be enough to cause a pause for thought.

VMware NSX for vSphere 6.4.3 - SUBJECT TO CONFIRMATION BY VMware REGARDING HORIZON 7.6

Upgrading Desktop Templates

With respect to upgrading templates, the back-end components should be upgraded prior to the agents within the image.  As such, upgrading this rather depends on how many change windows are being used to upgrade the above components.  In all cases, VMware have limited support for backward compatibility for agents, so there is flexibility here.  The VM templates have the following components/dependencies:

• VMware App Volumes Agent – used for registering the VM and the logged in user to App Volumes manager.
  
• VMware UEM Agent – used for managing the user persona via UEM.
  
• VMware vRealize Operations for Horizon Agent – although a version is integrated as part of the VMware Horizon Agent, for full functionality in line with the release of vRealize Operations for Horizon, the dedicated agent is recommended.
  
• VMware Horizon Agent – this is used to provide components for managing deployment, assignment and the remote desktop protocol to the desktop.  It is recommended that this is installed after VMware Tools has been upgraded.
  
• VMware Tools – required for interaction with vSphere, as well as providing optimised device drivers for the guest OS.
  
• The VM virtual hardware version – this is defined by the VMware ESXi release. Upgrading should only be carried out once VMware Tools are upgraded but can be beneficial for performance reasons.
  

Where hardware GPUs are deployed, there are further considerations.  For example, if the templates are deployed using a vDGA (Dedicated Graphics) or Nvidia vGPU configuration, further investigation into supported Nvidia drivers should be carried out.

What to upgrade first?

Where to start upgrading will be driven from your starting point, so it’s well worth looking at compatibility of the release that you’re starting at with the relevant components.

Upgrading VMware vRealize Operations and the Horizon plugin is likely to be the best starting point as this supports all the monitored components backwards for a number of releases. In addition, it is the least disruptive activity for users.

After this, updating App Volumes Managers would be the next step.

Upgrading VMware Horizon follows the order it has always followed – VMware Composer, followed by Connection Servers and Security Servers.  The recommendation, however, would be to take the time to retire any Security Servers and replace them with VMware Unified Access Gateway appliances instead.

Where deployed, VMware NSX would be next on the list..

After this, the vCenter upgrade followed by the VMware ESXi hosts should take place.  In the case of the latter, as mentioned previously, pay close attention where hardware GPUs are deployed as this may need upgraded drivers and software in-line with the vSphere release.  If vSAN is deployed, this would take place as the closing step of upgrading all the ESXi hosts in the cluster, ensuring that there is enough space to carry out such an upgrade.

With respect to the desktop templates, upgrading of components can be staged, but the supporting services must be in place first.

Closing Thoughts

Although there are a fair few items to consider, so long as the components are upgraded with consideration to each other and in the proper order, it’s possible to uplift the entire stack to support VMware vSphere 6.7 Update 1.  The only caveat is the lack of interoperability testing  between releases of VMware Horizon 7.6 and NSX 6.4, though it should be remembered that there is no direct connection between the two products and VMware have yet to actually publish test results for this combination.

If you are looking to get the best from VMware infrastructure and understand your upgrade and compatibility options, please contact us, and we’d be happy to use our wealth of knowledge and experience to assist you.

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strength in VDI, storage integration, backup and Disaster Recovery design/implementation. He was awarded VMware vExpert 2018 and is a graduate of the VMware Advanced Architecture Course 2018.

About Xtravirt

Xtravirt are an experienced consulting firm dedicated to delivering outcomes to help customers solve their IT challenges. We design and build strategies to help customers unlock the full potential of cloud, datacentre and workspace technology.

We are the VMware Global and EMEA Professional Services partner of the year.

www.xtravirt.com

by Curtis Brown

VMware’s virtual desktop and application publishing portfolio has gotten increasingly complex of late, with a mix of cloud and on-premises offerings, and this is even before you consider the components that make up the supporting pieces, such as User Environment Manager, App Volumes and integration with Workspace ONE.

In this article I hope to provide you with a (little) clearer view as to which Horizon to look out onto (pun intended).

 The On-Prem option – Horizon 7

This is the ‘great original flavour’ of VMware’s desktop virtualization offering.  The customer provides the tin to host it all on, builds a VMware vSphere estate (with VMware vSphere for Desktops included in the suite) and then layers on the VMware Horizon components for delivery of either Virtual Desktops or Remote Application publishing.

It does have several pro’s and cons –

• You have flexibility on the scale and architecture, including geographic locations.
• Scaling from very small to incredibly large, through the ability to leverage Cloud Pod Architecture.
• Proximity to on-premises services and corporate network users can be an advantage, particularly for client/server resources.
• Scaling down is expensive as you own the tin it’s hosted on.
• It can generate VDI desktops, RDS Desktops and applications, using a number of delivery methods (Linked, Instant and full clones) of whatever specification you’ll need.

Being the most developed product, in combination with being in a customer-owned environment, it has a greater range of integration points with third party products, for example, there are numerous application delivery tools available.

When On-Prem is also Cloudy – Horizon View on VMware Cloud on AWS

This next offering is also the newest.  VMware Cloud on Amazon Web Services (VMC on AWS) is an Infrastructure as a Service (IaaS) offering that allows a customer to purchase VMware vSphere environments on AWS. As an IaaS solution, the customer has more control over the estate than would be the case in most XaaS offerings, to the point that it is possible to deliver VMware Horizon View on the platform.

Functionally, this is the same as the on-premises Horizon View, right down to the point that you build your own servers for hosting the otherwise identical components, however, there are a small number of caveats.  The biggest one of these is that you can’t use Linked Clones for delivering desktops – only full or instant clones are supported.  Although given that Instant Clones are rapidly superseding Linked clones, this is not that much of a loss.

As this is a Cloud solution, there are still questions to answer with respect to connectivity to on-premises resources, though if application services are moved to AWS, this is less of an issue.

By leveraging multiple tenants and AWS connectivity, it is possible to scale outwards for geographical and resilience reasons.  It is even possible to run a Cloud Pod federation that includes both on-premises and VMware Cloud on AWS-hosted Horizon Pods.  It’s a little more elastic than an on-premises solution in that you can scale down the VMware Cloud on AWS tenant.

Going Full Cloud – Horizon Cloud

The next option is VMware’s true Desktop-as-a-Service (DaaS) offering, Horizon Cloud.  Currently, this is available in two flavours – Horizon Cloud on IBM Cloud and Horizon Cloud on Microsoft Azure.   Each of these have slightly different attributes that affect use cases, however as both use a common management backplane, they’re similar to administer.

The key thing that separates the Horizon Cloud flavour is that because it’s a DaaS offering, the buyer is literally just an administrator of desktops – all the broker components and (in the case of the IBM Cloud hosted) infrastructure is controlled and maintained by VMware.  If you require elasticity in scaling both up and down, this is the most dynamic offering as it is purchased in desktop capacity units as a subscription service.

Horizon Cloud on IBM Cloud

This is hosted on an IBM platform based on VMware vSphere technology.  This option is comparatively cheap and is intended to be the ‘all in one’ greenfield solution as the license includes the compute capacity as well as Horizon licensing.

It can provide full VDI desktops, or Remote Desktop Session Host (RDSH) based desktops and published applications.  For VDI, it can produce non-persistent desktops using Linked Clone technology. There are several Nvidia GPU offerings for graphic intensive desktops, but only for full VDI.

While this solution offers VMware App Volumes for application delivery to the desktops (no user assigned disks), it does not support the use of App Volumes with RDSH servers, unlike the Horizon View offerings.

As a DaaS offering, rather than IaaS, integration is limited – for example, little ability to leverage virtualisation-based app delivery tools outside App Volumes and no agentless anti-virus.

Horizon Cloud on Microsoft Azure

By leveraging the same broker technology and management portal as Horizon Cloud on IBM Hosted, it is now possible to deploy on your own Microsoft Azure tenant.  In this case, an appliance is used to automate the cloning process for deploying full clones in Azure – there is no Instant Clone capability here currently.

This is largely intended for those who want to do desktop virtualisation and already have Azure. It’s not particularly cheap as you must pay both VMware (for Horizon licensing) and Microsoft for the Azure VMs. While it has no App Volumes support at all, it does, however, have enhanced 3D graphics support through Microsoft Azure GPU-enabled infrastructure for RDS workloads.

Closing Thoughts

The choice is quite broad, but must be considered with care, leaning heavily on the use case.  The discovery process is more critical than ever and should be embarked upon before signing on the dotted line for a product to ensure that not only is the solution sized and designed correctly, but that the correct platform is selected in the first place.

The Horizon Cloud DaaS offerings are compelling, but they aren’t a panacea – you still need to design and administer the solution.  You’ve only eliminated the infrastructure support and moved your desktops further away from your users and their data.

Horizon View remains the most flexible product and, with the VMware Cloud on AWS support, even offers a cloud presence and better scaling options than previously.  An interesting option here is a hybrid approach of Horizon View on-premises, but federated with an AWS hosted tenant for DR.  The disadvantage is that you need to keep the platform running rather than throwing infrastructure issues over the fence to VMware and that infrastructure will be costly.

Ultimately, it’s a ‘choose your poison’ decision, which re-emphasises the point above – don’t rush in and buy first/design later – carry out a proper investigation into the options and decide based upon business requirements and use cases.

Xtravirt have been involved in End User Compute virtualisation projects of all sizes for many years, bringing a broad range of skills and experience to the table. If you are looking to deploy a new digital workspace solution or wish to enhance or upgrade what you currently have, we can help. We have a long track record of successful workspace projects and can provide advisory, design and implementation services to create the right solution for your organisation. Contact us and we’ll be happy to assist you.

By Curtis Brown

Introduction

As VMware Horizon® 7 has developed, we’re starting to see the product evolve from the existing Horizon Admin Console based on Flash to a new Horizon Console based on HTML5. It’s a steady evolution, in much the same light as VMware® vCenter HTML5 console evolved through releases of VMware vSphere® 6.5 and 6.7.

The 7.8 release of VMware Horizon is the most feature-rich to date and adds much in the way of configuration settings as well as provisioning.

A Quick Guided Tour

So how do we access this new console?  VMware have been particularly imaginative with the URL.  While the old console had the URL of HTTPS://(Connection Server)/admin, we now have HTTPS://(Connection Server)/newadmin for the new console. Which at least allows us to access both consoles.

At the logon page, we can enter our admin credentials.

Once logged in, we see the nice, clean HTML5 interface.

On the left a navigation pane; at the top, we have a dashboard view – this has a splash screen at the moment, so it appears to be more of a placeholder.

Users & Groups covers entitlements while the Inventory section covers the resources to be published, much in the same way as the old console.

JMP is new – this refers to the Just-In-Time Management Platform.  This will be covered in a future post, but it provides a means to integrate Horizon View, User Environment Manager and App Volumes for assigning and controlling resources.

The last section, Settings, is a new area in the Console.  It provides the direct replacement for the Settings in the old admin console, allowing the admin to configure Servers, Cloud Pod Architecture and other settings.

Notice in the vCenter Servers page, it still includes Composer.  Although there’s a push to move to Instant Clones, Composer based Linked Clones are still alive and well.

If we add a vCenter, we get presented with a cleaned up, but familiar wizard.

One significant difference is the non-appearance of the Security Server tab.  However, as is common in the later 7.x iterations admin console, it is possible to register Unified Access Gateway appliances.

Closing Thoughts

There are a few areas where it’s still a work in progress, some of which are a little odd.  While you can configure Cloud Pod Architecture, you can’t control the basic global settings or the Events database, let alone add a Horizon license key.  Remember though, it’s a work in progress and for day-to-day admin, it’s pretty good.

About the author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strengths in VDI, storage integration, backup and disaster recovery design/implementation. He was awarded VMware vExpert 2019.

About Xtravirt

If you’re embarking on either an upgrade or a new VMware Horizon implementation, Xtravirt have the expertise and experience in the End User Compute space and can provide advisory, design and implementation services to create the right solution for your organisation. Contact us and we’ll be happy to assist you.

By Curtis Brown

A brief update

Following my visit to VMworld Europe in 2017 I wrote a blog post on VMware Horizon Cloud on Azure. Much has changed in a year, so it seems rather timely, given that VMworld Europe 2018 has just concluded, that I update the blog.

Where we were….

Going back a year to 2017, VMware Horizon Cloud on Azure had only just launched and at the time, it was capable of publishing full clones of Remote Desktop Session Host servers for publishing Shared Desktops and applications.  A pretty good start, all things considered, albeit slightly functionally limited compared to the VMware Hosted offering that could also offer dedicated VDI desktops.

A year on, where are we now?

Things have definitely moved on in the last year.  Not only is feature-parity between Azure and VMware Hosted offerings somewhat closer, but in one area, graphics, the Azure offering is actually superior!

Deployment

The deployment model has remained the same – you bring your own Azure subscription rather than lean on VMware for the hosting.  In this sense, it is still the case that a cost/benefit analysis needs to be undertaken

The cost of deploying Horizon VMs on Azure can be more expensive when compared to the VMware hosted offering.  To be fair, Azure is more oriented towards a server offering than desktops, so perhaps this shouldn’t be too much of a surprise.  To counterbalance this however, one must also consider connectivity in the equation.  If you already have an established Azure tenant with backhaul connectivity to on-site, then deploying VMware Hosted with its own connectivity overhead may counter the VM costs to a degree – certainly, the operational upkeep of additional environments and connectivity is a consideration.

An additional point to consider may be functionality.  From a deployment perspective, Horizon Cloud on Azure is now starting to offer dedicated and floating full desktops, not just shared.  However, at present, Instant Clones are not supported so deployment is limited to essentially persistent desktops.

Features

There is, as yet, no support for VMware App Volumes AppStacks in Horizon Cloud, so legacy deployment mechanisms will need to be considered.  As desktops are currently persistent in nature, legacy tooling such as Microsoft System Center Configuration Manager remain viable in this sense, though streaming application virtualisation tools such as VMware ThinApp and Microsoft App-V would be attractive too.

One feature that stands out over Hosted Horizon Cloud is that Azure offers enhanced graphics using Nvidia vGPU technology.  So, if you have a need for graphically intensive workloads in the Cloud, then Azure is currently the better choice.

Otherwise, with respect to connectivity protocols, management interfaces and other functionality such as the Skype for Business Virtualization Pack, the two offerings are now aligned.

What about VMware Cloud on AWS with Horizon?

VMware and Amazon Web Services have joined up to offer their VMware Cloud on AWS solution.  This allows customers to deploy a full VMware vSphere infrastructure in AWS data centers.  On top of that, it is possible to deploy VMware Horizon, so in a sense there is now a third Cloud desktop offering.

VMware consider this as an IaaS solution with desktops on, rather than a Desktop-as-a-Service offering as the customer has to look after the management tier of Horizon here, as opposed to Horizon Cloud.

The million-dollar question is - which is best? Well, there’s no easy answer to that.  Functionality wise, Horizon View has been around longer, has far greater scalability and the ability to federate multiple instances for greater resilience.  In an on-prem capacity, vGPU is supported, however this has yet to reach AWS.  The economics are more complex too given the different acquisition model involved.

There are a considerable number of use-cases where Horizon on VMware Cloud on AWS makes much more sense. For example, you have an on-prem VDI (and other services) that you wish to provide an instantaneous Cloud based DR or scaling offering, this is much more seamless and flexible than Horizon Cloud.

Closing Thoughts….

While the choice between on premises and then several cloud offerings is undoubtedly great, never has it been more apparent that an analysis prior to deciding is not just a ‘nice to have’ but a necessity.  The wrong decision can have expensive repercussions.  Such an analysis needs to consider:

• The business needs:
  

1. How does the business function currently and what are the issues to address?
   
2. How will a given solution benefit the business?
   

• Technology needs:
  

1. Compatibility with the existing environment
   
2. What connectivity do I have, and what will I need?
   
3. What resilience and security features are required?
   

• User needs:
  

1. Where are the users working?
   
2. What devices do they use and how do we manage them?
   
3. What and where are application services that users need?
   

For some customers, on-premises will remain the best approach to VDI, while others may benefit from the VMware Cloud on AWS approach offering both hybridity and flexibility and yet more may find a Desktop-as-a-Service the suitable answer.

Horizon Cloud on Azure has evolved rapidly and offers a convincing use case for customers who can gain a tangible benefit from it, but it’s not suitable in all cases.  If you need a DaaS solution and have Azure already or have graphical requirements that can’t be met in Horizon Cloud Hosted, then this might be your answer. But consider all possibilities and use cases before committing.

If you’re considering a VDI solution or digital workspace transformation, whether Cloud or On-Premises, we can help. We provide advisory, design and implementation services to create the right solution for your organisation. Contact us and we’d be happy to use our wealth of knowledge and experience to assist you.  

About the Author

Curtis Brown joined the Xtravirt consulting team in October 2012. His specialist areas include End User Compute solutions and Virtual Infrastructure design and implementation with particular strength in VDI, storage integration, backup and Disaster Recovery design/implementation. He was awarded VMware vExpert 2018 and is a graduate of the VMware Advanced Architecture Course 2018.

About Xtravirt

Xtravirt are an experienced consulting firm dedicated to delivering outcomes to help customers solve their IT challenges. We design and build strategies to help customers unlock the full potential of cloud, datacentre and workspace technology.

We are the VMware Global and EMEA Professional Services partner of the year.

www.xtravirt.com

by Michal Grzeszczak

My name is Michal Grzeszczak and I am a senior consultant at Xtravirt (www.xtravirt.com), an independent cloud consulting business and VMware Master Services Competent Partner.  In this blog, I’d like to share with you my experience of L2 bridging with VMware® NSX-T Data Center and help you to understand some of the differences between NSX-T and NSX-V, as well as cover some NSX use cases.  

Customer background:

The customer is one of the leading organisations in the betting and gambling industry and have been using NSX-V for some time now. When it came to their new greenfield environment, they decided to deploy NSX-T 2.4 Data Center. This decision was largely based on the fact that NSX-T Data Center provides bridging firewalls natively for L2 software bridging, which was their main requirement. Also, given that NSX-T will be the de facto network and security virtualisation platform offered by VMware going forward, by specifying it for this environment the customer is able to future proof the deployment. 

Future upgrades are also accounted for as upgrading from NSX-T 2.4 to future NSX-T releases is simpler than performing upgrades from a previous version of V or T.

NSX-T 2.4 was a major update and brought many changes to the architecture of the product, the main ones being:

• The NSX Manager and NSX Controllers were merged into one appliance deployed in a Cluster of 3 Nodes therefore minimising the footprint of the solution and operational complexity. 
• The other major change was the introduction of the new Simplified UI which “requires just the bare minimum of user input, offering strong default values with prescriptive guidance for ease of use. This means fewer clicks and page hops are required to complete configuration tasks.”

NOTE: In NSX 2.4 two UIs are presented - one is the new Simplified UI, the other one is Advanced. The latter is taken from NSX-T 2.3. The future plan is to remove the Advanced UI and provide all of the functionality via the Simplified UI.

 What are the key benefits of choosing NSX-T over NSX-V?

 There are many benefits of NSX-T over NSX-V, to name a few:

• NSX-T doesn’t require vCenter, however it can be added to NSX-T as a Compute Manager and allows for up to 16 Compute Managers per NSX 2.4 solution . There is no longer a 1:1 requirement like there was with NSX-V. 
• KVM Hypervisor support
• Bare Metal Edges provide sub-second failover 
• Data Plane Development Kit (DPDK) Optimising Forwarding - DPDK is a set of data plane libraries and network interface controller drivers for fast packet processing
• New, more flexible Overlay technology - Geneve replaces     VXLAN  https://docs.vmware.com/en/VMware-Validated-Design/4.3/com.vmware.vvd.sddc-nsxt-design.doc/GUID-CF3C47CA-9BEB-4213-8F08-1494261BF3EC.html 
• Bi-directional Forwarding Detection support
• BGP (Border Gateway Protocol) expanded functionality with features like Route Maps
• Much clearer User Interface (UI)

What were the specific use cases for this case customer and the design considerations?

USE CASE 1 - NSX-T Edge L2 Bridging - Integration of physical, non-virtualised database servers that require L2 connectivity to the virtualised environment. 

Design considerations:

• In NSX-T 2.4 two options are possible to bridge L2 workloads - using ESXi Bridge Clusters or Edge Bridge Profiles. The latter is recommended to use as the former will be deprecated in future. 
• Ideally the use of dedicated Bare Metal Edges, however this is not a requirement. 
• The possibility to deploy Edge Bridges in collapsed vSphere Clusters >     Management + Edge or Compute + Edge
• Consider having active and standby Edge Nodes on different hosts to avoid throughput drop, because VLAN traffic needs to be forwarded to both Edge Nodes in promiscuous mode.
• Overlay traffic can be tagged on a Distributed Port Group or Uplink Profile, but please avoid double tagging. 
• VLAN traffic should not be tagged on the Uplink Profile.
• Distributed Port Group for VLAN traffic connecting to the Edge Node should be in a Trunk Mode. The reason for this is due to the fact that Edge doing Bridging adds 802.1Q tag when transposing Overlay traffic to VLAN. 
• Consider having the same MTU value across your environment - if you can, choose MTU of 9000 for better performance. 
• Several Bridge Profiles can be configured, and a given Edge can belong to several Bridge Profiles. By creating two separate Bridge Profiles, alternating active and backup Edge in the configuration, the user can easily make sure that two Edge nodes simultaneously bridge traffic between Overlay and VLAN

Constraints:

• Edge Cluster with minimum 2 Edge Nodes in Active/Standby mode is needed.
• Standby uplinks are not supported on the Edge Node.
• Source Based Load Based Teaming is not supported on the Edge Node.
• The port group on the VSS/VDS sending and receiving traffic on the VLAN side should be in promiscuous mode, allowing MAC Address changes and Forge Transmits.

Deployment:

• Follow the deployment guide here - https://youtu.be/IwpujflzJhY 
• Or here https://docs.vmware.com/en/VMware-NSX-T-Data-Center/2.3/com.vmware.nsxt.admin.doc/GUID-7B21DF3D-C9DB-4C10-A32F-B16642266538.html 

Validation:

• Log in to the Edge Node with your credentials.
• Type “nsxcli”.
• “Get l2bridge-ports-config” will show the Bridge Port State (Active Edge will have Forwarding, Standby will have Stopped), VLAN ID configured and Bridge UUID which can be copied and used to do a packet capture on the Edge Node.
• To do the packet capture type “start capture interface “copied Bridge UUID” and hit enter, ping from VM to Physical Server to see the flows. 

USE CASE 2 - NSX bridging firewall - Secure communication between physical database servers and Overlay workloads.

• The configuration of the bridging firewall can be done currently only on the Advanced UI.
• Security rules are configured per Logical Switch aka Segment in Simplified UI. 
• NSX-T grouping objects like NSGroups can be used to provide abstraction from the IP based approach.

USE CASE 3 - vRealize Network Insight - Monitoring tool that can provide visibility into both Physical and Virtual environments. 

• NSX-T 2.4 is fully supported with the latest vRealize Network Insight version 4.1.
• Make sure you are allowing ports for communication between vRNI and other devices after the deployment. For example, ESXi Hosts to vRNI Collector on UDP 2055. The full list of ports needed can be found here - https://docs.vmware.com/en/VMware-vRealize-Network-Insight/3.9/com.vmware.vrni.install.doc/GUID-FDDA5F2F-7C3B-472A-A17D-39582FBD5996.html 
• There is a new website that provides in-depth information about new features in vRNI, definitely worth visiting - https://vrealize.vmware.com/t/vmware-network-management/  

What were the outcomes?

Overall, this deployment was a complete success as we were able to satisfy all of the requirements that the customer had. All the production physical databases were able to communicate on the same L2 segments, virtualised and connected to NSX-T segments workloads. On top of that, communication between those workloads was secured by NSX-T Bridging Firewall. vRealize Network Insight was used to provide visibility into the environment. Its ability to quickly troubleshoot network and firewall related issues in both virtual and physical realms allows admins to take a breath in the never-ending battle of making the networks stable.

I hope you enjoyed my blog, if you’d like to talk to Xtravirt about your business’s networking and security requirements, then please send an email to info@xtravirt.com

Some Useful links:

You can read more about the NSX-T 2.4 release here: https://blogs.vmware.com/networkvirtualization/2019/02/introducing-nsx-t-2-4-a-landmark-release-in-the-history-of-nsx.html/