Horizon 7.0 Part 10–Building Your Desktop Golden Images

A virtual desktop environment is nothing without virtual desktops.  Poorly performing virtual desktops and applications, or virtual desktops and remote desktop session hosts that aren’t configured properly for the applications that are being deployed, can turn users off to modern end user computing solutions and sink the project.

How you configure your desktop base image can depend on the type of desktop pools that you plan to deploy.  The type of desktop pools that you deploy can depend on the applications and how you intend to deploy them.  This part will cover how to configure a desktop base image for non-persistent desktop pools, and the next part in this series will cover how to set up both linked and instant clone desktop pools.

Before You Begin, Understand Your Applications

Before we begin talking about how to configure the desktop base image and setting up the desktop pools, its very important to understand the applications that you will be deploying to your virtual desktops.  The types of applications and how they can be deployed will determine the types of desktop pools that can be used.

A few factors to keep in mind are:

  • Application Delivery – How are the applications going to be delivered to the desktop or RDSH host?
  • User Installed Applications – Will users be able to install their own applications?  If so, how are applications managed on the desktop?
  • User Profiles – How are the user profiles and settings being managed?  Is there any application data or setting that you want to manage or make portable across platforms?
  • Licensing – How are the applications licensed?  Are the licenses locked to the computer in some way, such as by computer name or MAC address?  Is a hardware key required?
  • Hardware – Does the application require specific hardware in order to function, or does it have high resource requirements?  This is usually a consideration for high-end CAD or engineering applications that require a 3D card, but it could also apply to applications that need older hardware or access to a serial port.

Application management and delivery has changed significantly since I wrote the Horizon 6.0 series.  When that series was written, VMware had just purchased Cloud Volumes, and it hadn’t been added into the product suite.  Today, App Volumes is available in the Horizon Suite Enterprise SKU, and it provides application layering capabilities in Horizon.  Application layering allows administrators to place applications into virtual disk files that get attached at logon, and this allows you to create a single master golden image that has applications added when the user logs in.  If you don’t have the Horizon Suite Enterprise SKU, there are a few other players in the application layering space such as Liquidware Labs FlexApp and Unidesk, and these tools also provide the ability to abstract your applications from the underlying operating system.

Application layering isn’t the only delivery mechanism.  App Virtualization, using tools like ThinApp, Microsoft AppV, or Turbo, is one option for providing isolated applications.  Reverse layering has all applications installed into the golden template, and applications are exposed on a per-user basis. This is the concept behind tools like FSLogix.  Publishing applications to virtual desktops using XenApp or Horizon Published Applications is an option that places the applications on a centralized server, or you could just install some or all of your applications into the golden image and manage them with tools like Altiris or SCCM.

All of these options are valid ways to deliver applications to virtual desktops, and you need to decide on which methods you will use when designing your desktop golden images and desktop pools.  There may not be a single solution for delivering all of your applications, and you may need to rely on multiple methods to meet the needs of your users.

Supported Desktop Operating Systems

Horizon 7.0 supports desktops running Windows and Linux.  The versions of Windows that are supported for full clone and linked clone desktops are:

  • Windows 10 Enterprise (including the Long Term Servicing Branch and Anniversary Update in Horizon 7.0.2)
  • Windows 8.1 Enterprise or Professional
  • Windows 8 Enterprise or Professional
  • Windows 7 SP1 Enterprise or Professional
  • Windows Server 2008 R2 (RDSH and Server-based Desktop)
  • Windows Server 2012 R2 (RDSH and Server-based Desktop)

In order to run desktops on Windows Server-based OSes, you need to enable the “Enable Windows Server desktops” setting under View Configuration –> Global Settings and install the Desktop Experience feature after installing the OS.  There are some benefits to using Windows Server for your desktop OS including avoiding the Microsoft VDA tax on desktop VDI.  The choice to use a server OS vs. a desktop OS must be weighed carefully, however, as this can impact management and application compatibility.

Instant clone desktops are supported on the following operating systems:

  • Windows 10 Enterprise
  • Windows 7 SP1 Enterprise or Professional

The Horizon Linux agent is supported on the following 64-bit versions:

  • Ubuntu 14.04 (note: VMware recommends disabling Compviz due to performance issues)
  • Ubuntu 12.04
  • RHEL and CentOS 6.6
  • RHEL and CentOS 7.2
  • NeoKylin 6 Update 1
  • SLES 11 SP3/SP4
  • SLES 12 SP1

The Linux component supports both full clone and linked clone desktops in Horizon 7.0.1.  However, there are a number of additional requirements for Linux desktops, so I would recommend reading the Setting Up Horizon 7 Version 7.0.1 for Linux Desktops guide.

For this part, we’re going to assume that we’re building a template running a desktop version of Windows.  This will be more of a high-level overview of creating a desktop template for Horizon, and I won’t be doing a step-by-step walkthrough of any of the steps for this section.  Once the desktop image is set up, I’ll cover some of the ways to optimize the desktop templates.

Configure the VM

Building a desktop VM isn’t much different than building a server VM.  The basic process is create the VM, configure the hardware, install the operating system, and then install your applications.  Although there are a few additional steps, building a desktop VM doesn’t deviate from this.

You should base the number of vCPUs and the amount of RAM assigned to your virtual desktops on the requirements for of the applications that you plan to run and fine tune based on user performance and resource utilization.   Horizon doesn’t allow you to set the CPU and RAM allocation when deploying desktop pools, so these need to be set on the template itself.

The recommended hardware for a virtual desktop is:

  • SCSI Controller – LSI SAS
  • Hard Disk – At least 40GB Thin Provisioned
  • NIC – VMXNET3
  • Remove Floppy Drive, and disable parallel and serial ports in BIOS
  • Remove the CD-ROM drive if you do not have an alternative method for installing Windows.

Note: You cannot remove the CD-ROM drive until after Windows has been installed if you are installing from an ISO.

BIOS Settings
BIOS screen for disabling Serial and Parallel ports and floppy controller

You’ll notice that I didn’t put minimums for vCPUs and RAM.  Sizing these really depends on the requirements of your user’s applications.  I’ve had Windows 7 64-bit desktops deployed with as little as 1GB of RAM for general office workers up to 4GB of RAM for users running the Adobe Suite.  Generally speaking, customers are deploying knowledge or task worker desktops with at least 2 vCPUs and between 2-4 GB of RAM, however the actual sizing depends on your applications.

Install Windows

After you have created a VM and configured the VM’s settings, you need to install Windows.  Again, it’s not much different than installing Windows Server into a VM or installing a fresh copy of Windows onto physical hardware.  You can install Windows using the ISO of the disk or by using the Microsoft Deployment Toolkit and PXE boot to push down an image that you’ve already created.

When installing Windows for your desktop template, you’ll want to make sure that the default 100 MB system partition is not created.  This partition is used by Windows to store the files used for Bitlocker.  Since Bitlocker is not supported on virtual machines by either Microsoft or VMware, there is no reason to create this partition.  This will require bypassing the installer and manually partitioning the boot drive.  The steps for doing this when installing from the DVD/ISO are:

1. Boot the computer to the installer
2. Press Shift-F10 to bring up the command prompt
3. Type DiskPart
4. Type Select Disk 0
5. Type Create Partition Primary
6. Type Exit twice.

diskpart

Once you’ve set up the partition, you can install Windows normally.  If you’re using something like the Microsoft Deployment Toolkit, you will need to configure your answer file to set up the proper hard drive partition configuration.

Install VMware Tools and Join the Template to a Domain

After you have installed Windows, you will need to install the VMware tools package.  The tools package is required to install the View Agent.  VMware Tools also includes the VMXNET3 driver, and your template will not have network access until this is installed.   The typical installation is generally all that you will need unless you’re using Guest Introspection as part of  NSX or your antivirus solution.

After you have installed VMware Tools and rebooted the template, you should join it to your Active Directory domain.  The template doesn’t need to be joined to a domain, but it makes it easier to manage and install software from network shares.  I’ve also heard that there are some best practices around removing the computer from the domain before deploying desktop pools.  This is an optional task, and it’s not required.  I’ve never removed the machines from the domain before provisioning, and I haven’t experienced any issues.

Install The Horizon Agent

After you have installed the VMware tools package and joined your computer to the domain, you will need to install the VMware Horizon Agent.  There are a number of new features in the Horizon 7 Agent install, and not all features are enabled by default.  Be careful when enabling or disabling features as this can have security implications.

One thing to note about the Horizon 7 agent is that there is a Composer component and an Instant Clones component.  These items cannot be installed together.  A desktop template can only be used for Linked Clones or Instant Clones.

Installing Applications on the Template

After you install the Horizon Agent, you can begin to install the applications that your users will need when they log into Horizon View.

With tools like Thinapp available to virtualize Windows applications or layering software like FlexApp, Unidesk and App Volumes, it is not necessary to install all of your applications in your template or to create templates for all of the different application combinations.  You can create a base template with your common applications that all users receive and then either virtualize or layer your other applications so they can be delivered on demand.

“Finalizing” the Image

Once you have the applications installed, it is time to finalize the image to prepare it for Horizon.  This step involves disabling unneeded services and making configuration settings changes to ensure a good user experience.   This may also involve running antivirus or other malware scans to ensure that only new or changed files are scanned after the image is deployed (Symantec…I’m looking at you for this one).

VMware has released a white paper that covers how to optimize a Windows-based virtual desktop or RDSH server.  Previous versions of this white paper have focused on making changes using a PowerShell or batch script.   VMware has also released a fling, the OS Optimization Tool, with a graphical interface that can simplify the optimization process.  Whenever possible, I recommend using the fling to optimize virtual desktop templates.  It not only provides an easy way to select which settings to apply, but it contains templates for different operating systems.  It also provides a way to log which changes are made and to roll back unwanted changes.

Prior to optimizing your desktops, I recommend taking a snapshot of the virtual machine.  This provides a quick way to roll back to a clean slate.  I recommend applying most of the defaults, but I also recommend reading through each change to understand what changes are being made.  I do not recommend disabling the Windows Firewall at all, and I don’t recommend disabling Windows Update as this can be controlled by Group Policy.

Before you shut the virtual machine down to snapshot it, verify that any services required for applications are enabled.  This includes the Windows Firewall service which is required for the Horizon Agent to function properly.

Shutdown and Snapshot

After you have your applications installed, you need to shut down your desktop template and take a snapshot of it.  If you are using linked clones, the linked clone replica will be based on the snapshot you select.

That’s a quick rundown of setting up a desktop template to be used with Horizon desktops.

In the next part of this series, I’ll cover how to create desktop pools.

Horizon 7.0 Part 9–Configuring Horizon for the First Time

Now that the Connection Server and Composer are installed, it’s time to configure the components to actually work together with vCenter to provision and manage desktop pools.

Logging into the Horizon Administrator

Before anything can be configured, though, we need to first log into the Horizon Administrator management interface.  This management interface is based on the Adobe Flex platform, so Flash will need to be installed on any endpoints you use to administer the environment.

The web browsers that VMware currently supports, with Adobe Flash 10.1 or later are:

  • Internet Explorer 9-11
  • Firefox
  • Chrome
  • Safari 6
  • Microsoft Edge

To log in, take the following steps:

1. Open your web browser.

2. Navigate to https://<FQDN of connection server>/admin

3. Log in with the Administrator Account you designated (or with an account that is a member of the administrator group you selected) when you installed the Connection Server.

1. Login

4. After you log in, you will be prompted for a license key.

2. License pt 1

Note:  The license keys are retrieved from your MyVMware site.  If you do not input a license key, you will not be able to connect to desktops or published applications after they are provisioned.  You can add or change a license key later under View Configuration –> Product Licensing and Usage.

5. Click Edit License.  Paste your license key from the MyVMware site into the license key box and click OK.

3. License pt 2

6. After your license key is installed, the Licensing area will show when your license expires and the features that are licensed in your deployment.

4. License pt 3

Configuring Horizon for the First Time

Once you’ve logged in and configured your license, you can start setting up the Horizon environment.  In this step, the Connection Server will be configured to talk to vCenter and Composer.

1.   Expand View Configuration and select Servers.

3

2.  Select the vCenter Servers tab and select Add…

4

3, Enter your vCenter server information.  The service account that you use in this section should be the vCenter Service Account that you created in Part 6.

Note: If you are using vCenter 5.5 or later, the username should be entered in User Principal Name format – username@fqdn.

6

4. If you have not updated the certificates on your vCenter Server, you will receive an Invalid Certificate Warning.  Click View Certificate to view and accept the certificate.

7

5.  Select the View Composer option that you plan to use with this vCenter.  The options are:

A. Do not use View Composer – View Composer and Linked Clones will not be available for desktop pools that use this vCenter.

B. View Composer is co-installed with vCenter Server – View Composer is installed on the vCenter Server, and the vCenter Server credentials entered on the previous screen will be used for connecting.  This option is only available with the Windows vCenter Server.

C. Standalone View Composer Server – View Composer is installed on a standalone Windows Server, and credentials will be required to connect to the Composer instance.  This option will work with both the Windows vCenter Server and the vCenter Server virtual appliance.

Note: The account credentials used to connect to the View Composer server must have local administrator rights on the machine where Composer is installed.  If they account does not have local administrator rights, you will get an error that you cannot connect.

8

6. If Composer is using an untrusted SSL certificate, you will receive a prompt that the certificate is invalid.  Click View Certificate and then accept.

For more information on installing a trusted certificate on your Composer server, please see Part 5.

9

7. The next step is to set up the Active Directory domains that Composer will connect to when provisioning desktops.  Click Add to add a new domain.

11

8. Enter the domain name, user account with rights to Active Directory, and the password and click OK.  The user account used for this step should be the account that was set up in Part 6.

Once all the domains have been added, click Next to continue.

10

9. The next step is to configure the advanced storage settings used by Horizon.  The two options to select on this screen are:

  • Reclaim VM Disk Space – Allows Horizon to reclaim disk space allocated to linked-clone virtual machines.
  • Enable View Storage Accelerator – View Storage Accelerator is a RAMDISK cache that can be used to offload some storage requests to the local system.  Regenerating the cache can impact IO operations on the storage array, and maintenance blackout windows can be configured to avoid a long train of witnesses.  The max cache size is 2GB.

After you have made your selections, click Next to continue.

12

10. Review the settings and click finish.

13

Configuring the Horizon Events Database

The last thing that we need to configure is the Horizon Events Database.  As the name implies, the Events Database is a repository for events that happen with the View environment.  Some examples of events that are recorded include logon and logoff activity and Composer errors.

Part 6 described the steps for creating the database and the database user account.

1. In the View Configuration section, select Event Configuration.

4. Event Configuration

2. In the Event Database section, click Edit.

5. View Events Database Section

3. Enter the following information to set up the connection:

  • Database Server (if not installed to the default instance, enter as servername\instance)
  • Database Type
  • Port
  • Database name
  • Username
  • Password
  • Table Prefix (not needed unless you have multiple Connection Server environments that use the same events database – IE large “pod” environments)

6. Edit Events Database Settings

Note: The only SQL Server instance that uses port 1433 is the default instance.  Named instances use dynamic port assignment that assigns a random port number to the service upon startup.  If the Events database is installed to a named instance, it will need to have a static port number.  You can set up SQL Server to listen on a static port by using this TechNet article.  For the above example, I assigned the port 1433 to the Composer instance since I will not have a named instance on that server.

If you do not configure a static port assignment and try to connect to a named instance on port 1433, you may receive the error below.

7a. Bad Username or Password

5. If setup is successful, you should see a screen similar to the one below.  At this point, you can change your event retention settings by editing the event settings.

7b. Success!

Horizon 7.0 Part 8 – Installing The First Connection Server

Connection Servers are one of the most important components in any Horizon environment, and they come in three flavors – the standard Connection Server, the Replica Connection Server, and the Security Server. 

You may have noticed that I listed two types of connection servers.  The Standard and Replica Connection Servers have the same feature set, and the only difference between the two is that the standard connection server is the first server installed in the pod.  Both connection server types handle multiple roles in the Horizon infrastructure.   They handle primary user authentication against Active Directory, management of desktop pools, provide a portal to access desktop pools and published applications, and broker connections to desktops, terminal servers, and applications.  The connection server’s analog in Citrix environments would be a combination of Storefront and the Delivery Controller.

The Security Server is a stripped down version of the regular Connection Server designed to provide secure remote access.  It is designed to operate in a DMZ network and tunnel connections back to the Connection server, and it must be paired with a specific Connection Server in order for the installation to complete successfully.  Unlike previous versions of this walkthrough, I won’t be focusing on the Security Server in the remote access section as VMware now provides better tools.

Installing the First Connection Server

Before you can begin installing the Horizon View, you will need to have a server prepared that meets the minimum requirements for the Horizon View Connection Server instance.  The basic requirements, which are described in Part 2, are a server running Windows Server 2008 R2 or Server 2012 R2 with 2 CPUs and at least 4GB of RAM.

Note:  If you are going have more than 50 virtual desktop sessions on a Connection Server, it should be provisioned with at least 10GB of RAM.

Once the server is provisioned, and the Connection Server installer has been copied over, the steps for configuring the first Connection Server are:

1. Launch the Connection Server installation wizard by double-clicking on VMware-viewconnectionserver-x86_64-7.x.x-xxxxxxx.exe.

2. Click Next on the first screen to continue.

1

3.  Accept the license agreement and click Next to continue.

2

4.  If required, change the location where the Connection Server files will be installed and click Next.

3

5. Select the type of Connection Server that you’ll be installing.  For this section, we’ll select the Horizon 7 Standard Server.  If you plan on allowing access to desktops through an HTML5 compatible web browser, select “Install HTML Access.”  Select the IP protocol that will be used to configure the Horizon environment.  Click Next to continue.

4

6. Enter a strong password for data recovery.  This will be used if you need to restore the Connection Server’s LDAP database from backup.  Make sure you store this password in a secure place.  You can also enter a password reminder or hint, but this is not required.

5

7. Horizon View requires a number of ports to be opened on the local Windows Server firewall, and the installer will prompt you to configure these ports as part of the installation.  Select the “Configure Windows Firewall Automatically” to have this done as part of the installation.

6

Note: Disabling the Windows Firewall is not recommended.  If you plan to use Security Servers to provide remote access, the Windows Firewall must be enabled on the Connection Servers to use IPSEC to secure communications between the Connection Server and the Security Server.  The Windows Firewall should not be disabled even if Security Servers and IPSEC are not required.

8. The installer will prompt you to select the default Horizon environment administrator.  The options that can be selected are the local server Administrator group, which will grant administrator privileges to all local admins on the server, or to select a specific domain user or group.  The option you select will depend on your environment, your security policies, and/or other requirements.

If you plan to use a specific domain user or group, select the “Authorize a specific domain user or domain group” option and enter the user or group name in the “domainname\usergroupname” format.

7

Note: If you plan to use a custom domain group as the default Horizon View administrator group, make sure you create it and allow it to replicate before you start the installation. 

9.  Chose whether you want to participate in the User Experience Improvement program.  If you do not wish to participate, just click Next to continue.

8

10. Click Install to begin the installation.

9

11. The installer will install and configure the application and any additional windows roles or features that are needed to support Horizon View. 

10

12. Once the install completes, click Finish.  You may be prompted to reboot the server after the installation completes.

Now that the Connection Server and Composer are installed, it’s time to begin configuring the Horizon application so the Connection Server can talk to both vCenter and Composer as well as setting up any required license keys and the events database.  Those steps will be covered in the next part.

What’s New–Horizon 7.0.2 #VMworld2016

VMware has had a fairly steady release cadence for the Horizon Suite, and they have a new point release every 3-6 months.  These releases don’t just correct bugs in the software – they add new features that help close the gap with Citrix.

The next release of Horizon doesn’t disappoint.  Despite being a dot-dot release, Horizon 7.0.2 is packed with improvements.

Some of the highlights of the release are:

Blast Improvements

  • Further enhancements to the protocol
  • Improvements in the GPU-encode/decode that significantly lower bandwidth and latency
  • Improvements in the JPG/PNG codec to reduce bandwidth utilization by 6x
  • vRealize Operations integration with Blast Extreme.  I can now see Blast statistics in the vROPs console
  • UEM Smart Policies Integration with Blast.  I can now use the same PCoIP smart policies to control the Blast protocol.  This enhancement also allows administrators to set per-device policies so I can set different policies for Windows, Mac, Android, and IOS.
  • A Raspberry Pi client

3D Graphics

  • NVIDIA M10 support for high-density graphics acceleration use cases
  • Intel vDGA support on the Skylake platform using 1:1 PCI-E passthru

Horizon RDSH

VMware has continued to close the feature gap with Citrix XenApp, and the latest release checks off a few more boxes.    The main features in this release are:

  • Real-time Audio/Video support for RDSH
  • USB Redirection for RDSH on servers running Windows Server 2012 R2
  • Parameter Passthrough to RDSH Apps – this allows administrators to create custom links that pass parameters through to the application, such as command-line switches or authentication tokens, on launch.

Remote Experience

  • Expanded Windows OS support, including support for Windows 10 LTSB, Anniversary Update, and Pro virtual desktops
  • Flash redirection is now GA.  This allows flash content to be redirected to the local endpoint for rendering for a better experience.
  • Windows Media Redirection support for Windows 10 and Server 2016
  • Windows Media MMR support for Linux-based thin clients
  • Client Drive Redirection is now supported on port 443.  Enhancements have also been made to improve performance on high-latency networks and to speed up file and folder listings
  • DPI synchronization on native Windows clients to ensure crisp rendering of remote session
  • Enhanced clipboard with support for Microsoft Word and Excel
  • Clipboard size increased to 10 MB
  • Ability to link one smart card to multiple accounts

HTML Access Improvements

  • Time Zone Sync
  • File transfer between remote desktop and endpoint using web client
  • RTAV support for desktops and apps

What’s New in NVIDIA GRID August 2016

Over the last year, the great folks over at NVIDIA have been very busy.  Last year at this time, they announced the M6 and M60 cards, bringing the Maxwell architecture to GRID, adding support for blade server architectures, and introducing the software licensing model for the drivers.  In March, GRID 3.0 was announced, and it was a fix for the new licensing model.

Today, NVIDIA announced the August 2016 release of GRID.  This is the latest edition of the GRID software stack, and it coincides with the general availability of the high-density M10 card that supports up to 64 users.

So aside from the hardware, what’s new in this release?

The big addition to the GRID product line is monitoring.  In previous versions of GRID, there was a limited amount of performance data that any of the NVIDIA monitoring tools could see.  NVIDIA SMI, the hypervisor component, could only really report on the GPU core temperature and wattage, and the NVIDIA WMI counters on Windows VMs could only see framebuffer utilization.

The GRID software now exposes more performance metrics from the host and the guest VM level.  These metrics include discovery of the vGPU types currently in use on the physical card as well as utilization statistics for 3D, encode, and decode engines from the hypervisor and guest VM levels.  These stats can be viewed using the NVIDIA-SMI tool in the hypervisor or by using NVIDIA WMI in the guest OS.  This will enable 3rd-party monitoring tools, like Liquidware Stratusphere UX, to extract and analyze the performance data.  The NVIDIA SDK has been updated to provide API access to this data.

Monitoring was one of the missing pieces in the GRID stack, and the latest release addresses this.  It’s now possible to see how the GPU’s resources are being utilized and if the correct profiles are being utilized.

The latest GRID release supports the M6, M60 and M10 cards, and customers have an active software support contract with NVIDIA customers.  Unfortunately, the 1st generation K1 and K2 cards are not supported.

Horizon 7.0 Part 7–Installing Composer

The last couple of posts have dealt with preparing the environment to install Horizon 7.0.  We’ve covered prerequisites, design considerations, preparing Active Directory, and even setting up the service accounts that will be used for accessing services and databases.

Now its time to actually install and configure the Horizon View components.  These tasks will be completed in the following order:

  • Install Horizon Composer
  • Install Horizon Connection Servers
  • Configure the Environment for the first time
  • Install and Configure Remote Access Components

One note that I want to point out is that the installation process for most components has not changed significantly from previous versions.  If you’ve installed Horizon 6.x, this process will look very familiar to you.

Before we can install Composer, we need to create an ODBC Data Source to connect to the Composer database.  The database and the account for accessing the database were created in Part 6.  Composer can be installed once the ODBC data source has been created.

Composer can either be installed on your vCenter Server or on a separate Windows Server.  The first option is only available if you are using the Windows version of vCenter.  This walkthrough assumes that Composer is being installed on a separate server.

Service Account

Part 6 covers the steps for creating the Composer service account that will be used to connect Composer to vCenter.  This account will require local administrator rights on the server prior to installing Composer.

Creating the ODBC Data Source

Unfortunately, the Composer installer does not create the ODBC Data Source driver as part of the Composer installation, and this is something that will need to be created by hand before Composer can be successfully installed.  The View Composer database doesn’t require any special settings in the ODBC setup, so this step is pretty easy.

The SQL Server Native Client is not bundled with the Composer installation.  Prior to configuring the ODBC Data Source, the SQL Server Native Client for your version of SQL Server will need to be installed.  The Native Client for common versions of SQL Server can be found at:

The SQL Server Native Client was discontinued after SQL Server 2012, and it was replaced with a SQL Server ODBC Driver.  I do not know if this driver is supported with Composer, and I do not have a SQL Server 2014 database server to test with.

Once the Native Client is installed, you can begin creating the ODBC Data Source.

Note: The ODBC DSN setup can be launched from within the installer, but I prefer to create the data source before starting the installer.  The steps for creating the data source are the same whether you launch the ODBC setup from the start menu or in the installer.

1. Go to Start –> Administrative Tools –> Data Sources (ODBC).  On Windows Server 2012 R2, go to Start –> All Programs –> ODBC Data Sources (64-bit)

2. Click on the System DSN tab.

1

3. Click Add.

4. Select the correct SQL Server Native Client and click Finish.  If your database is on SQL Server 2008 R2, the native client will be version 10.0, and if it is on SQL Server 2012 or later, the correct version of the native client is 11.0. This will launch the wizard that will guide you through setting up the data source.

5. When the Create a New Data Source wizard launches, you will need to enter a name for the data source, a description, and the name of the SQL Server that the database resides on.  If you have multiple instances on your SQL Server, it should be entered as ServerName\InstanceName.  Click next to continue.

2

6. Select SQL Server Authentication.  Enter your SQL Server username and password that you created above.  Click Next to continue.

3

7. Change the default database to the viewComposer database that you created in Part 6.  Click Next to continue.

4

8. Click Test Data Source to verify that your settings are correct.

5

9. If your database settings are correct, you will see the windows below.  If you do not see the TESTS COMPLETED SUCCESSFULLY, verify that you have entered the correct username and password and that your login has the appropriate permissions on the database object.  Click OK to return to the previous window.

2014-01-04_22-29-37

10. Click OK to close the Data Source Administrator and return to the desktop.

 

Installing Horizon Composer

Once the database connection has been set up, Composer can be installed.  The steps for installing Composer are:

1.  Launch the Horizon 7 Composer installer.

2.  If .Net Framework 3.5 SP1 is not installed, you will be prompted to install the feature before continuing. Note: Windows Server 2012 R2 does not contain the binaries for the .Net 3.5 feature, and you need to choose an alternate source path before installing.  Please see this article from Microsoft.

3.  Click Next to continue.

1

4.  Accept the license agreement and click next.

2

5.  Select the destination folder where Composer will be installed.

3

6. Configure Composer to use the ODBC data source that you set up.  You will need to enter the data source name, SQL login, and password before continuing.

4

7. After the data source has been configured, you will need to select the port that Composer will use for communicating with the Horizon Connection Servers. 

5

8. Click Use an existing SSL certificate, and then click Choose.  Select the certificate and click OK.  Click Next.

6

Click Install to start the installation.

7

9. Once the installation is finished, you will be prompted to restart your computer.

10

So now that Composer is installed, what can we do with it?  Not much at the moment.  A connection server is required to configure and use Composer for linked clone desktops, and the next post in this series will cover how to install that Connection Server.

You Got Your Nutanix in My UCS #NTC

In the 1980s, there was a commercial for Reese’s Peanut Butter cups that described the product with the following lines: “You got your chocolate in my peanut butter.  You got your peanut butter in my chocolate.”

This describes  hyperconverged infrastructure and the Cisco UCS converged platform.

By combining storage and compute into the same nodes, a hyperconverged infrastructure offers many features for customers.  These include highly performant storage, simplified management, and a reduced footprint in the datacenter.  But networking has remained an island unto it’s own, and its still it’s own silo in data centers with hyperconverged infrastructure.

Cisco’s UCS provides similar benefits by converging compute and network – simplified policy-based management combined with high performance compute and networking.

So what happens when you combine them?

You get a best of breed platform that brings the fully-converged stack to life.  Network, storage, and compute are unified with a Nutanix-powered hyperconverged platform running with policy-based hardware management through UCSM.

Today, Nutanix announced support for UCS C-series rackmount servers.  Unlike the previous platform expansions, Nutanix on Cisco UCS will not be an OEM partnership.  It will be a meet-in-the-channel approach where customers would buy Cisco UCS and Nutanix licensing separately, and the integration would take place when the system is installed at the customer site.

Nutanix has certified some Cisco UCS C-series platforms, and they provide the certified Bill of Materials to simplify ordering with your preferred channel partner.  Nutanix is not supporting Cisco B-series blades.

The combination of Nutanix and UCS brings yet another powerful combination to customers who want to utilize the best-of-breed technologies in their data centers.

NVIDIA GRID Community Advisors Program Inaugural Class

This morning, NVIDIA announced the inaugural class of the GRID Community Advisors program.  As described in the announcement blog, the program “brings together the talents of individuals who have invested significant time and resources to become experts in NVIDIA products and solutions. Together, they give the entire NVIDIA GRID ecosystem access to product management, architects and support managers to help ensure we build the right products.”

I’m honored, and excited, to be a part of the inaugural class of the GRID Community Advisors Program along with several big names in the end-user computing and graphics virtualization fields.  The other members of this 20-person class are:

  • Durukan Artik – Dell, Turkey
  • Barry Coombs – ComputerWorld, UK
  • Tony Foster – EMC, USA, @wonder_nerd
  • Ronald Grass – Citrix, Germany
  • Richard Hoffman – Entisys, USA, @Rich_T_Hoffman
  • Magnar Johnson – Independent Consultant, Norway, @magnarjohnsen
  • Ben Jones – Ebb3, UK, @_BenWJones
  • Philip Jones – Independent Consultant, USA, @P2Vme
  • Arash Keissami – dRaster, USA, @akeissami
  • Tobias Kreidl – Northern Arizona University, USA, @tkreidl
  • Andrew Morgan – Zinopy/ControlUp, Ireland, @andyjmorgan
  • Rasmus Raun-Nielsen – Conecto A/S, Denmark, @RBRConecto
  • Soeren Reinertsen – Siemens Wind Power, Denmark
  • Marius Sandbu – BigTec / Exclusive Networks, Norway, @msandbu
  • Barry Schiffer – SLTN Inter Access, Netherlands, @barryschiffer
  • Kanishk Sethi – Koenig Solutions, India, @kanishksethi
  • Ruben Spruijt – Atlantis Computing, Netherlands, @rspruijt
  • Roy Textor – Textor IT, Germany, @RoyTextor
  • Bernhard (Benny) Tritsch – Independent Consultant, Germany, @drtritsch

Thank you to Rachel Berry for organizing this program and NVIDIA for inviting me to participate.

Horizon 7.0 Part 6–Service Accounts and Databases

Back in Part 4, I mentioned that Horizon required up to a few service accounts to function properly.  One of these accounts is for accessing vCenter to provision and manage the virtual machines that users will connect to.  The other service account will manage computer accounts within Active Directory, and this account is only required if you are using Horizon Composer or Instant Clones.

In addition to these two service accounts, two database accounts may need to be created for the Horizon Composer database and the Horizon Events Database.  Edit: The supported database matrix has changed significantly since Horizon 6.2.  Please validate that your database is compatible by checking the VMware Product Interoperability Matrix.

It’s important to build these accounts with the principle of least privileged access in mind.  These accounts should not have more rights than they would need.  So while the easy way out would be to give these accounts vCenter Administrator, Domain Administrator, and SQL Server or Oracle SysAdmin rights, it would not be a good idea as these accounts could potentially be compromised.

vCenter Service Account

The first account that needs to be created is a service account that Horizon will use for accessing vCenter.  Horizon uses this account for provisioning new virtual desktops and performing power operations.  The service account should be a standard Active Directory domain user account without any additional administrator-level rights on the domain or on the vCenter server.

There are a couple of different ways to configure your Horizon environment, so the actual rights required in vCenter will vary.  The specific permissions that are required can be found in the Configuring User Accounts for vCenter Server and View Composer section of the Horizon 7 documentation.

A new role will need to be created within vCenter in order to assign the appropriate permissions.  To create a new role in the vCenter Web Client, you need to go to Administration –> Roles from the main page.  This will bring up the roles page, and we can create a new role from here by clicking on the green plus sign.

2013-12-29_19-14-37

For the purposes of this walkthrough, I’ll be setting up my service account with permissions to deploy linked clone desktops using Horizon Composer.  The permissions that need to be assigned to our new role are:

Privilege Group

Privilege

Datastore
Allocate Space
Browse Datastore
Low Level File Operations

Folder
Create Folder
Delete Folder

Virtual Machine
Configuration –> All Items
Inventory –> All Items
Snapshot Management –> All Items
Interaction:
Power On
Power Off
Reset
Suspend
Provisioning:
Customizing
Deploy Template
Read Customization Spec
Clone Virtual Machine
Allow Disk Access

Resource
Assign Virtual Machine to Resource Pool
Migrate Powered-Off Virtual Machine

Global
Enable Methods
Disable Methods
System Tag
Act As vCenter Note 1

Network
All

Host
Configuration:
Advanced Settings Note 1

Note 1: Act as vCenter and Host Advanced Settings are only needed if Storage Accelerator are used.  If these features are not used, these permissions are not required.

After the role has been created, we will need to assign permissions for our vCenter Server service account to the vCenter root.  To do this from the roles screen, you will need to go back to the vCenter Web Client Home screen and take the following steps:

  1. Select vCenter
  2. Select vCenter Servers under Inventory Lists
  3. Select the vCenter that you wish to grant permissions on
  4. Click on the Manage Tab
  5. Click Permissions
  6. Click the Green Plus Sign to add a new permission
  7. Select the role for Horizon Composer
  8. Add the Domain User who should be assigned the role
  9. Click OK.

2013-12-29_20-33-59

Horizon Events Database Account

The Events Database is a repository for events that happen with the Horizon environment.  Some examples of events that are recorded include logon and logoff activity and Composer errors.

The Events Database requires a Microsoft SQL Server or Oracle database server, and it should be installed on an existing production database server.  There are two parts to configuring the events database.  The first part, creating the database and the database user, needs to be done in SQL Server Management Studio before the event database can be configured in Horizon Administrator.  The steps for configuring Horizon to use the Events database will happen in another post.

Note: Horizon also supports sending event data off to a syslog server.  This can be used in place of an events database.  Configuring a syslog server is beyond the scope of this article.

To set up the database, follow these steps:

1. Open SQL Server Management Studio and log in with an account that has permissions to create users and databases.

2. Expand Security –> Logins.

3. Right-click on Logins and Select New Login…

1. Create New User 1

4. Enter the SQL Login Name and Password and then click OK.

2. Create New User 2

5. Expand Databases.

6. Right-click on Databases and select New Database.

7. Enter the database name.  Select the database user that you created above as the database owner.  Click OK to create the database.

3. Create View Events Database

Note: SQL Server named instances are configured to use dynamic ports.  This means that SQL Server will use a new port every time the server is restarted.  The events database does not support dynamic ports, so a static port will need to be configured and the SQL instance restarted prior to configuring the events database in Horizon.  For instructions on how to configure a static ports in SQL Server, please see this article.

Active Directory Provisioning Account

The Active Directory Provisioning Service account is used by Horizon to manage the computer accounts that are created for Instant Clone and Linked Clone desktops.

This account can be created as a standard domain user, and it should not have domain administrator or account operator rights – it only needs a select group of permissions on the OU (or OUs) where the virtual desktop computer accounts will be placed.

After this account has been created, you need to delegate permissions to it on the OU (or OUs) where your VDI desktops will be placed.  If you use the structure like the one I outlined in Part 4, you only need to delegate permissions on the top-level OU and permission inheritance, if turned on, will apply them to any child or grandchild objects beneath it.

Note:  If inheritance is not turned on, you will need to check the Apply to All Child Objects checkbox before applying the permissions.

The permissions that need to be delegated on the OU are:

  • Create Computer Objects
  • Delete Computer Objects
  • Write All Properties
  • Reset Password

Note: Although granting this account Domain Administrator or Account Operator permissions may seem like an easy way to grant it the permissions it needs, it will grant a number of other permissions that are not needed and could pose a security risk if that account is compromised.  Only the required permissions should be granted in a production environment.

Horizon Composer Service Account

The last two accounts that need to be set up are for Horizon Composer.  These accounts are only required if you plan on using Composer and linked clone desktops.

I recommend two accounts for Composer.  These accounts are:

1. A Composer Service Account– This service account is by Horizon to connect to Composer.  It is a standard Active Directory user account that requires administrator rights on the Composer server.  This account is only required if Composer is not installed on the vCenter Server.

2. A Horizon Composer Database User – This service account is a local SQL Server user account and is required if the SQL Server database is located on a remote server.  If SQL Server is installed on the Composer Server, Windows authentication can be used.

Configuring the Composer Database and Database Service Account

Like the Event database above, Composer requires its own database.  This database is used to keep track of linked clones, replicas, and pending recompose operations.

The steps below will walk through setting up the Composer database.  If your Composer database is located on a separate server, you will have to use SQL authentication, and the steps for creating the SQL user are included.

Note: If your Composer database is located on the same server as the Composer service, you can use Windows Authentication for accessing the database.

1. Log into your database server and open SQL Server Management Studio.

2014-01-04_22-20-17

2. Log in as a user with administrator rights on SQL Server.

3. Create a new SQL Login by expanding Security –> Logins.  Right click on Logins and select New Login.

2014-01-04_22-21-46

4. Enter a login name such as HorizonComposerDB or HorizonComposerUser, select SQL Server Authentication, and enter a password twice.  You may also need to disable Enforce Password Expiration or Enforce Password Policy depending on your environment.  Click OK to create the account.  Note: Check with your DBA on password policy settings and requirements.  In the absence of existing policies, I recommend disabling Password Expiration and Password Policy requirements on this account because an expired SQL User password will break the environment.  There is a VMware KB on how to change the database user password, but I would recommend avoiding that issue entirely.

2014-01-04_22-23-50

5. After the SQL login is created, you need to create an empty database.  To create the database, right click on the database folder and select New Database.

2014-01-04_22-19-58

6. In the database name field, enter a name such as HorizonComposer.  This will be the name of the database.  To select an owner for the database, click on the … button and search for the database user account you created above.  Click OK to create the database.

2014-01-04_22-24-23

You will have a blank database that you can use for Composer after you click OK.

Configuring Composer to use this database will be covered during the Composer installation.

This wraps up all of the prerequisites for the environment.  In the next couple of sections, I will be covering the installation and configuration of VMware Horizon.

#GRIDDays Followup – Understanding NVIDIA GRID vGPU Part 1

Author Node: This post has been a few months in the making.  While GRIDDays was back in March, I’ve had a few other projects that have kept this on the sidelines until now.  This is Part 1.  Part 2 will be coming at some point in the future.  I figured 1200 words on this was good enough for one chunk.

The general rule of thumb is that if a virtual desktop requires some dedicated hardware – examples include serial devices, hardware license dongles, and physical cards, it’s probably not a good fit to be virtualized.  This was especially true of workloads that required high-end 3D acceleration.  If a virtual workload required 3D graphics, multiple high-end Quadro cards hard to be installed in the server and then passed through to the virtual machines that required them. 

Since pass-through GPUs can’t be shared amongst VMs, this design doesn’t scale well.  There is a limit to the number of cards I could install in a host, and that limited the number of 3D workloads I could run.  If I needed more, I would have to add hosts.  It also limits the flexibility in the environment as VMs with pass-through hardware can’t easily be moved to a new host if maintenance is needed or a hardware failure occurs.

NVIDIA created the GRID products to address the challenges of GPU virtualization.  GRID technology combines purpose-built graphics hardware, software, and drivers to allow multiple virtual machines to access a GPU. 

I’ve always wondered how it worked, and how it ensured that all configured VMs had equal access to the GPU.  I had the opportunity to learn about the technology and the underlying concepts a few weeks ago at NVIDIA GRID Days. 

Disclosure: NVIDIA paid for my travel, lodging, and some of my meals while I was out in Santa Clara.  This has not influenced the content of this post.

Note:  All graphics in this slide are courtesy of NVIDIA.

How it Works – Hardware Layer

So how does a GRID card work?  In order to understand it, we have to start with the hardware.  A GRID card is a PCIe card with multiple GPUs on the board.  The hardware includes the same features that many of the other NVIDIA products have including framebuffer (often referred to as video memory), graphics compute cores, and hardware dedicated to video encode and decode. 

image

Interactions between an operating system and a PCIe hardware device happen through the base address register.  Base address registers are used to hold memory addresses used by a physical device.  Virtual machines don’t have full access to the GPU hardware, so they are allocated a subset of the GPU’s base address registers for communication with the hardware.  This is called a virtual BAR. 

image

Access to the GPU Base Address Registers, and by extension the Virtual BAR, is handled through the CPU’s Memory Management Unit.  The MMU handles the translation of the virtual BAR memory addresses into the corresponding physical memory addresses used by the GPU’s BAR.  The translation is facilitated by page tables managed by the hypervisor.

The benefit of the virtual bar and hardware-assisted translations is that it is secure.  VMs can only access the registers that they are assigned, and they cannot access any other locations outside of the virtual BAR.

image

The architecture described above – assigning a virtual base address register space that corresponds to a subset of the physical base address register allows multiple VMs to securely share one physical hardware device.  That’s only one part of the story.  How does work actually get from the guest OS driver to the GPU?  And how does the GPU actually manage GPU workloads from multiple VMs?

When the NVIDIA driver submits a job or workload to the GPU, it gets placed into a channel.  A channel is essentially a queue or a line that is exposed through each VM’s virtual BAR.  Each GPU has a fixed number of channels available, and channels are allocated to each VM by dividing the total number of channels by the number of users that can utilize a profile.  So if I’m using a profile that can support 16 VMs per GPU, each VM would get 1/16th of the channels. 

When a virtual desktop user opens an application that requires resources on the GPU, the NVIDIA driver in the VM will dedicate a channel to that application.  When that application needs the GPU to do something, the NVIDIA driver will submit that job to channels allocated to the application on the GPU through the virtual BAR.

image

So now that the application is queue up for execution, something needs to get it into the GPU for execution.  That job is handled by the scheduler.  The scheduler will move work from active channels into the GPU engines.  The GPU has four engines for handling a few different tasks – graphics compute, video encode and decode, and a copy engine.  The GPU engines are timeshared (more on that below), and they execute jobs in parallel.

When active jobs are placed on an engine, they are executed sequentially.  When a job is completed, the NVIDIA driver is signaled that the work has been completed, and the scheduler loads the next job onto the engine to begin processing.

image

Scheduling

There are two types of scheduling in the computing world – sequential and parallel.  When sequential scheduling is used, a single processor executes each job that it receives in order.  When it completes that job, it moves onto the next.  This can allow a single fast processor to quickly move through jobs, but complex jobs can cause a backup and delay the execution of waiting jobs.

Parallel scheduling uses multiple processors to execute jobs at the same time.  When a job on one processor completes, it moves the next job in line onto the processor.  Individually, these processors are too slow to handle a complex job.  But they prevent a single job from clogging the pipeline.

A good analogy to this would be the checkout lane at a department store.  The cashier (and register) is the processor, and each customer is a job that needs to be executed.  Customers are queued up in line, and as the cashier finishes checking out one customer, the next customer in the queue is moved up.  The cashier can usually process users efficiently and keep the line moving, but if a customer with 60 items walks into the 20 items or less lane, it would back up the line and prevent others from checking out.

This example works for parallel execution as well.  Imagine that same department store at Christmas.  Every cash register is open, and there is a person at the front of the line directing where people go.  This person is the scheduler, and they are placing customers (jobs) on registers  (GPU engines) as soon as they have finished with their previous customer.

Graphics Scheduling

So how does GRID ensure that all VMs have equal access to the GPU engines?  How does it prevent one VM from hogging all the resources on a particular engine?

The answer comes in the way that the scheduler works.  The scheduler uses a method called round-robin time slicing.  Round-robin time slicing works by giving each channel a small amount of time on a GPU engine.  The channel has exclusive access to the GPU engine until the timeslice expires or until there are no more work items in the channel.

If all of the work in a channel is completed before the timeslice expires, any spare cycles are redistributed to other channels or VMs.  This ensures that the GPU isn’t sitting idle while jobs are queued in other channels.

The next part of the Understanding vGPU series will cover memory management on the GRID cards.