Monthly Archives: July 2011

VMware View 4.6 Bootcamp Day 9 – View Reference Architecture for Stateless Virtual Desktops

The VMware View Bootcamp ends today with a talk about the View Reference Architecture. Mac Binesh, a Sr. Technical Marketing Manager outlines some of the typical costs associated with and benefits of adopting a virtual desktop infrastructure. I found the content a fitting end to the View Bootcamp series. When I look back at the previous discussions I realize that many of the regular posters have already come to realize the ways that a product such as View can benefit their organization, and not just with regard to CAPEX/OPEX per physical desktop. My notes from the Day 9 video. What is a Stateless Desktop?

  • Referred to as a “floating” desktop in View 4.5/4.6
  • Generic user desktop that is allocated to a user at login
  • User changed to the desktop are discarded at logoff
  • No User installed application
  • The VM returns to the desktop pool upon log off
  • Lower cost per VM can be realized with tiered storage
  • Starting with View 4.5 the “floating” VM can be placed on solid state disk on a blade server; previously the VM could only reside on the SAN

Reference Architecture Goals and Benefits

  • The reference architecture represents a validated VDI solution that was built and tested by VMware
  • The reference architecture represents a realistic desktop workload, a task/knowledge worker
  • Lower the CAPEX (capital expense) costs as measured on a per desktop basis
Benefits of Using Stateless Desktops
  • To the User:
    • Fast login times
    • Fast access to applications
    • Easy to reboot the VM
  • To the IT Department:
    • Improved SLA’s
    • Easier to manage than physical desktops
    • No “storms” (boot, login)
    • No SAN required
    • Scales easily
  • To the Business:
    • Reduced CAPEX and OPEX compared to physical desktops
    • Enhanced user productivity (more stable and consistent desktop experience)
    • Enhanced IT productivity (less to manage)
    • Plus all the other benefits associated with leveraging VDI

Cost Analysis

  • Since 2008 the datacenter hardware required by VMware View has decreased in cost by approximately 75%.
  • CAPEX Datacenter (Hardware) Cost Per Stateless Virtual Desktop (figures from VMware): $242
    • Qty 12: 8 core server w/96GB of ram: $212,796
      • 12 desktops per server core
      • Windows 7 23-bit with 1Gb of ram.
    • Datacenter switch: $11,842
    • SAN (20TB): $69,450
    • Qty 32: 160GB SSD drives for servers: $15,968
    • Total: $309,756 ($242 per desktop)

Key Use Cases

  • Remote Office/Branch Office OR Business Process Outsourcing
    • Reduced costs since desktops and users are centrally managed.
    • Sensitive data stays in the data center.
    • Streamlines application and desktop deployment.
  • Labs, Kiosks, and Training Centers
    • Supports distance learning environments.
    • Rapidly provision desktops.
    • Enhanced security with centralized control and management.
    • Reduced costs and increased control.

View 4.5 Scalability Testing and Results

  • For VMware testing the following architecture was used:
    • Linked clone replica base image resided on local SSD storage
    • Parent base image, user data, and the VM’s .vswp file resided on the SAN (shared storage)
      • .vswp files and infrastructure VM’s  (parent base image and View servers themselves) resided on NFS
      • Standard file shares were used for Windows user data redirections
    • Non persistent automated pool that refreshes immediately
  • Test Strategy and Success Criteria
    • Establish a baseline for desktops per server
      • Gradually increase the number of desktops until the resources of the server are maxed out
      • Reduce the number of desktops until utilization is at an acceptable level (VMware used ~70% CPU utilization as their figure)
    • Start with two servers, then scale out in two server increments
      • Validate application performance with each server scale out
    • Monitor SSD utilization
  • Test Results
    • VMware was able to scale to 96 desktops on an 8 core server (12 VM’s to server core)
    • Varied reboots of VM’s were sustained without consuming 100% of the system resources
    • 10Gbit ethernet combined with the use of local storage made it obvious that the networking environment could handle a fully scaled server load
    • The traffic observed is similar to that of a typical file server
  • VMware View 4.5/4.6 with tiered storage will drastically lower CAPEX, and simplifies cost modeling of desktop virtualization
  • Testking has proven that VMware View 4.5/4.6 provides linear scalability across both compute and storage regardless of scale

References from the presentation plus some I have added:

I hope everyone has enjoyed my summaries of the VMware View Bootcamp videos. I was interested in viewing the videos simply because I am doing increasing amounts of work with VDI and virtualization in general. My focus is more on validating the data center architecture so I find these videos valuable as they remind me of the end to end requirements of the solution as a whole. Follow the Day 9 discussions on the VMware forum page.

VMware View 4.6 Bootcamp Day 8 – Leveraging Security Server for PCoIP

Day 8 of the VMware Bootcamp was delivered by Mark Benson, a View Architect with VMware. The subject of the day is how and where to deploy VMware View Security Servers to provide secure remote access to View desktops. Earlier videos have touched on the function of the Security Server role but Mark lays out what exactly you need to do to integrate them into your View environment. How does a View Security Server work?

  • A remote user connects to View Security Server over a HTTPS connection using a URL that is configured in theView client.
  • If authentication is successful a secure HTTPS tunnel is established between the client device (View client) and the Security Server.
  • What happens next depends on the version of View:
    • View 4.5: The View Security Server would initiate a RDP connection to a View desktop and provide user access to this session over the HTTPS tunnel established in the previous step.
      • If PCoIP is the preferred protocol the only option is to connect over a VPN; the View 4.5 Security Servercannot tunnel PCoIP traffic.
    • View 4.6: The View Security Server initiates either a RDP or PCoIP connection to the View desktop depending on the configuration of the View Connection Server, again using the tunnel to extend the connection to the end user.
  • At the end of the day the View Security Server just performs a subset of the functionality of the ViewConnection Server.

Why use the View Security Server?

  • Recommended for DMZ deployments or environments with separated networks (no direct/private connection between locations)
  • Only authorized users can gain access through the View Security Server.
  • Ensures that the only traffic that enters the internal data center is that of authenticated users.
  • Ensures that users can only access resources (virtual desktops) that they are authorized to access.
  • Zero administration required beyond the initial setup.
  • View Security Servers offload the HTTPS processing and all desktop protocol traffic away from the ViewConnection Servers.
  • Multiple View Security Servers can be used to for scalability and high availability needs.

What is involved in making a remote PCoIP connection in VMware View 4.6 with a security server?

  • HTTPS must be open from the outside to the View Security Servers (and load balancers if used).
  • Port 4172 TCP and UDP traffic must be allowed inbound from the external clients to the Security Server and from the Security Server to the View Desktops.
  • Port 4172 UDP traffic must also be allowed outbound from the View Desktops to the Security Server and from the Security Server to the external clients.
Basic Troubleshooting and Things to Remember
  • Load balancers can be used to manage load but once the Security Server has been assigned remote clients must be able to connect to that server directly.
  • View Security Servers are only supported on Windows 2008R2 due to PCoIP support.
    • The View Security Server will utilize Intel AESNI instruction set to enhance PCoIP performance if available.
  • The View Connection Server can be run on Windows Server 2003 if you don’t need PCoIP gateway functionality.
  • The View Connection Server must have “PCoIP Gateway Functionality” turned onto enable SS to tunnel it.
    • Edit the “properties” of the View Connection Server to configure this setting.
  • Remember: On the View Connection Server, “Secure Tunnel” is enabled by default, “Secure Gateway” is disabled by default.
  • External facing View Security Servers typically get 2 URLS:
    • “External” URL is used by clients to establish the tunnel.
    • “PCoIP External URL is used by the View Clients to establish the PCoIP connection through the PCoIPgateway.
    • These settings are set in the security server properties; by default they are set to the server IP.
      • You will also have the option to specify these URLs during install time, if known.
  • Multiple View Security Servers can be connected to a single View Connection Server.
  • A single View Security Server supports 2000 active sessions (although it is recommended to have multipleSecurity Severs for resiliency).

Common issues

  • Make sure the View Connection Server is configured to gateway PCoIP (this is the default setting for 4.6).
  • Remote access without a VPN will not work unless you configure the View Connection Server to “Use PCoIPSecure Gateway for PCoIP Connections to desktop”.
    • Edit the “properties” of the View Connection Server to configure this setting.
  • Make sure the external URL’s are set correctly.
    • Edit the “properties” of the View Security Server to configure this setting.
  • Verify that PCoIP is not blocked by a firewall or web proxy.

Final notes:

  • Read the View 4.6 Architecture and Planning Guide.
  • May want multiple View Connection Servers so you can use different settings for internal and external access:
    • Gateway mode for external clients who will use the View Security Server.
    • Direct connections for internal clients who will connect directly to the View Desktops.
  • Plan your deployment and consider the needs for local access and remote access
  • Remember the three key steps:
    • Turn on PCoIP Gateway Functionality on the Connection Server.
    • Set up the two External URL’s on each View Security Server.
    • Set the firewall rules to allow PCoIP and HTTPS traffic as required.
While the video for the day did yield a lot of notes the overall implementation of View Security Servers seems rather straightforward. The View Architecture and Planning Guide and the Day 8 video are great resources for understanding how to deploy resilient and secure external access to View Desktops. Follow the discussions for the day here.

VMware View 4.6 Bootcamp Day 7 – Automating View 4.5 with PowerShell

Day 7 of the VMware View Boot Camp is about leveraging VMware PowerCLI to perform various View tasks. The presentation was given by Tom Elliot, a developer on the VMware View team. My notes for today are just that; there isn’t a lot of opinion to introduce into the subject at hand. I did update some of the links mentioned in the video to reference the current version of View (4.6) as well as the current version of the vSphere PowerCLI (4.1U1). Overview of View PowerCLI

  • The first automation tool released for VMware View.
  • Command line interface that is a snap-in for Windows PowerShell
  • Allows for management of View Desktop Pools, Individual View Desktops, Connection Servers, View registered vCenter Server configuration, User Entitlements, and View Configuration including licensing.
  • Some sample use cases:
    • Manage power consumption by shrinking pools overnight.
    • Manage new users and increase pool size automatically.
    • Schedule recurring Composer operations such as refresh, re-balance, and recompose.


  • View PowerCLI communicates with the Broker Service that runs on the Connection Server.
    • By default PowerCLI must be run from the Connection Server to manage View.
      • Remote connections can be enabled using the Enable-PSRemoting cmdlet.
    • The Broker Service acts as an intermediary between PowerCLI and other View components.

Anatomy of a Cmdlet

  • Verb-Noun Structure:
    • Get-Pool, Set-License, Add-ManualPool
  • Commands utilize input parameters:
    • Set-License -key XXXX-XXXX-XXXX-XXXX
  • Commands can be piped together:
    • Get-Pool -pool_id Sample1 | Remove-Pool
    • Multiple commands pipes are possible
  • View IDs used in PowerCLI:
    • pool_id
    • vc_id
    • machine_id

Setting up an Environment

  • Install View Connection Server
  • Install Windows Management Framework
    • PowerShell 2.0 and WinRM 2.0 (included in Windows 2008/2008R2 and Windows 7)
    • Microsoft KB968930 hosts the files for download for other OS’s.
    • Can be installed on a workstation for remote management.
  • Optional: Install vSphere PowerCLI Toolkit to enable vSphere management cmdlets.
  • Set PowerShell Execution Policy
    • To use your own scripts: Set-ExecutionPolicy Unrestricted
    • To use only signed scripts: Set-ExecutionPolicy AllSigned
    • Enable-PSRemoting allows commands to be executed remotely.
      • Must be enabled using PowerCLI on the Connection Server.
      • Must connect with Domain Admin credentials as View cmdlets require Admin privileges.

Basic Tasks / Sample View PowerCLI Cmdlets

  • Get-Pool : Used to return information about one or multiple pools.
  • Get-DesktopVM : Used to return information about one or multiple View desktops.
  • Add-PoolEntitlement : Used to grant a user or group rights to a View pool.
  • Update-AutomaticPool : Used to expand the size of an automatic pool.
  • Send-SessionLogoff : Used to log a user off of a View desktop.
  • Add-AutomaticLinkedClonePool : Used to create a new automatic linked clone pool.

Getting Help

  • Prepend a cmdlet with Get-Help
    • Get-Help Send-SessionDisconnect
    • Returns information about, a description of, and parameters to the supplied cmdlet.
  • VMware View 4.6 Integration Guide

Creating Your Own Scripts

  • Script files are a text file with a .ps1 extension.
  • You must load the View Cmdlets into the script first by including this line:
    • . “C:Program FilesVMwareVMware ViewServerextrasPowershelladd-snapin.ps1″
  • Syntax used to schedule scripts with Windows Scheduled tasks:
    • powershell.exe c:scriptsmyscript.ps1

Integrating with vSphere

  • vSphere components that are related to View can be administered from the View PowerCLI.
  • vSphere Cmdlets will be loaded by the View PowerCLI if they are present.
  • Limited support exists for piping vSphere Cmdlet output to View Cmdlet and for use of vSphere ID’s.

Advanced Topics Remoting:

  • To remotely manage View you use use the Enter-PSSession cmdlet and load the View Cmdlets as well:
    • Line 1: Enter-PSSession viewcs.vjason.local -Credential (Get-Credential)
    • Line 2: . “C:Program FilesVMwareVMware ViewServerextrasPowershelladd-snapin.ps1″
    • When done log out: Exit-PSSession
    • Notes:
      • Examples shown use the currently logged in account (-Credential (Get-Credential)) as the account used to connect to the View Connection Server (viewcs.vjason.local).
      • All commands are executed against the connection broker.
Known Issues:
  • Executing Update-AutomaticLinkedClone on a pool with profile or temp disks disabled will re-enable the setting.
    • Subsequent desktops that are provisioned will be provisioned with unwanted disks.
    • Existing desktops will not be affected.
  • Get-DesktopVM output is incorrect when multiple vCenter Servers are in use.
    • Reason is that vCenter VM MOID (managed object ID) value may not be unique across all vCenter servers.
    • Use -machine_id rather than -id (which is the MOID) to reference VM’s.
    • Also affects Send-LocalSessionRollback and Send-VMReset cmdlets.
Useful Links

PowerCLI for View is fairly straightforward if you are already using vSphere PowerCLI or even PowerShell for that matter. It is a key tool for automating those tasks that would otherwise require an admin to get up late at night and as such is a worthy topic to learn more about. Follow the Day 7 forum for the video here.

VMware View 4.6 Bootcamp Day 6 – PCoIP Deployment Best Practices and Tuning

The VMware View Bootcamp continues with Day 6:

“PCoIP Deployment Best Practices and Tuning. The speaker for today was Chuck Hirstius, a Senior Consultant with VMware. PCoIP is of course one of the protocols, if not the primary protocol, you use to connect clients to your View environment. I say primary because PCoIP enables secure end to end communications between the clients and the View VM’s, or should I say more secure than the other protocols supported by View. The video of the day generated a lot of notes as nearly every bit of information conveyed is very important when it comes to making View perform as expected. Day 6 notes:

PCoIP Protocol Background

  • Designed for high end workloads such as CAD, video/multimedia, and medical imaging.
  • Initially a hardware solution; starting with View 4.0 it was a software to software solution.
  • Encryption is inherent to the protocol; every packet within the protocol is encrypted.
  • In May ’09 enhancements were added to optimize performance over WAN links (latency, etc).
  • Host-based pixel encoding; sends only the pixels that have changed from frame to frame.
  • Endpoints are essentially simple “video streaming devices” as they are just viewing a streamed presentation of the session.
  • Performance consistent regardless of status  client side rending.
  • Uses a UDP transport. Ideal for real time protocols such as PCoIP which just send new display “pixels”.
  • Build to lossless display; static screens areas are gradually built to perfect.
  • Multiple codecs may be used to decompose the image based on the screen content.
  • Adaptive bandwidth consumption to help ensure a consistent client experience.

PCoIP Deployment Best Practices

  • QoS/CoS: Properly classify PCoIP as real-time interactive, typically below VoIP and ensure that the QoS mappings are preserved across WAN links.
  • Use the View Security Server (PCoIP gateway) for remote access to maximize security. Most efficient remote access solution and most secure since connections are proxied through a server in a DMZ.
  • If VPN is used favor IPSEC/L2TP/GRE/DTLS over SSL based since View traffic is already SSL encrypted.
  • Pass View traffic through any IDS/IPS/Endpoint Protection software as well as WAN optimization solutions (Bluecoat, Riverbed, Cisco, etc).
  • Fixed bandwidth WAN links are preferred over “burstable” links as burstable traffic is typically low priority from the provided. Key to ensure performance when traffic peaks.
  • Use Weighted Red (WRED) on virtual interfaces (not physical) to help avoid network congestion. Avoid “tail drop” as we don’t want packets to be dropped since we are using UDP.
  • Avoid use cases where network latency is greater than 300ms.
  • Avoid per-packet load balancing as packets may be delivered out of order (very bad for UDP traffic).
  • Use View desktop VM optimization guides to ensure optimal visual settings.
  • Optimize PCoIP to your use case!

Tuning PCoIP

  • Have a plan!
  • Identify and understand the problem you are trying to solve.
  • Be diligent about benchmarking and recording data.
  • Old change one variable at a time and record all changes that are made.
Tuning Parameters
  • PCoIP can be adjusted with group policies. Template is located on View Connection Server at: Program FilesVMwareVMware ViewServerExtrasGroupPolicyFilespcoip.adm.
  • PCoIP registry settings located at: HKLMSOFTWAREPoliciesTeradiciPCoIPpcoip_admin|defaults
  • Settings include:
    • pcoip.max_link_rate : Maximum session bandwidth.
    • pcoip.device_bandwidth_floor : Lowest bandwidth to use when congestion is detected.
    • pcoip.mtu_size : Packet size.
    • pcoip.minimum_image_quality : Lower bound of image quality compression used when congestion triggers build to lossless
    • pcoip.maximum_initial_image_quality : Lower bound of image quality PCoIP attempts to deliver initially; leads to more “pixel perfect” screens but with more bandwith peaks.
    • pcoip.maximum_frame_rate : Maximum frequency of  client screen updates.
    • pcoip.enable_audio : Enable/disable audio.
    • pcoip.audio_bandwidth_limit : Maximum audio bandwidth.

Tuning Guidelines

  • Cover the best practices first: network environment and desktop image optimization!
  • PCoIP adapts so altering default parameters may lead to unpredictable results.
  • For low bandwidth links set the limit at or below the maximum link rate.
  • Limits may even make sense for a LAN if throughput is a concern.
  • Configure a session floor when: PCoIP is experiencing packet loss but the network link has plenty of headroom OR when packet loss is seen on WiFi networks. Be careful to avoid unintentional over saturation by setting the floor too high.
  • 30 fps is the default frame rate but 20-24 fps will lead to almost no noticable impact (but little gain).
  • Rich media requires higher frame rates (at least 15 fps) but tasks workers with no media requires may be able to function with 6-8 fps.
  • Configure the maximum initial image quality; if on a WAN link with constrained bandwidth reduce to 60-70%. If the value is too low images may appear “fuzzy” or “blurry”.
  • Configure the minimum image quality (must be lower than max of course). 50% is typically acceptable for most cases.
  • Configure the audio bandwidth limit. Helpful in increasing connection density; vary between 450-50Kbps until ideal mix of bandwidth savings and audio quality is achieved. Audio bandwidth limit is a target, not a literal value!
  • Always start with the basics! Optimize image, address external issues (much more common than PCoIP issues!), and size the network accordingly based on the use case.
  • Use the PCoIP logs to identify where the problems are!
  • No more than one change at a time when working on issues! Test changes multiple times against the use case and repeat the process used to uncover the issue.
  • Don’t forget VMware / Teradici support!
Helpful links:

Lots of info today but as I said critical to getting the necessary performance out of your View environment. Follow the discussion for the day here or feel free to post questions below!

VMware View 4.6 Bootcamp Day 5 – Delivering Applications

Day 5 of the VMware View boot camp was “ThinApp” day. Heath Doer or VMware discussed the benefits of using ThinApp to deliver applications, outlined the ThinApp reference architecture, and discussed how to integrate ThinApp packaged applications with VMware. As with the previous videos I will summarize my takeaways from the daily video. Virtualization: Turns a monolithic system to modular by breaking the bond between the hardware, operating system, and applications. What are the positives of that?

  • Each “module” of the workstation can now be managed separately.
  • The solution is more flexible since neither layer is bound to the one that surrounds it.
  • Costs can be reduced since the modules are deployed once, managed as one, and used by many.
What does the combination of View and ThinApp give us?
Storage needs reduced:
  • Fewer images/less image customization needed since most applications are delivered via ThinApp.
  • Images themselves are smaller and less complex since only the base OS is required.

Streamlined software delivery without agents or additional infrastructure:

  • Multiple versions (Office, Internet browsers, etc) can be run on the same VM at the same time.
  • Can be integrated into the existing environment without the need to add additional server software or hardware.
Streamlined application patching:
  • Patch an application once for the entire environment.
  • In place upgrades as newly patched applications can be deployed in place.
Migration readiness:
  • OS image and applications can be migrated independently of each other.
Key benefits of ThinApp:
  • Agentless: Single file (MSI or EXE) application, no installation or local registry changes required to run a ThinApp, and zero managed required on the local device.
  • Seamless integration: No streaming hardware or software required; plugs into any existing infrastructure management framework.
  • Run (almost) any application from any device:
    • Applications can be run from USB, desktop, terminal services, or Citrix.
    • Windows applications from simple to complex are supported.
    • Any components required for application functionality can be run side by side (multiple versions of Java and .Net are provided as examples).
  • Security without compromising flexibility: ThinApp provides a virtual registry that prevents local registry changes and driver installs. Applications are execute in user mode; local administrative rights are not required.
How ThinApp works:
  • Encapsulates and isolates all the components of the application installation.
  • Intercepts all file and system calls from the application to the host.
  • Uses a virtual operating system (VOS) to “run” the application.
    • This VOS tracks all process and threads within the ThinApp virtual registry.
  • DLL dependencies are loaded from a DLL/EXE/OCX archive within the ThinApp application package.
How is a ThinApp application created:
  • ThinApp Setup Capture utility creates a baseline snapshot of the image prior to the application installation.
  • The application is installed, and the “Build” phase of the Setup Capture utility scans for all changes to the image and creates the virtualized application package.
  • Package options and “entry points” (shortcuts used to launch the application) are set.
  • Package is now ready to be built and put into production.
View Composer integration:
  • Composer can make ThinApps available within a View VM automatically.
  • Application “writes” can be directed to the user data disk (this is the default).
  • Users can be updated to newer versions of the ThinApp packaged application seamlessly.
  • Overall storage needs reduced and application deployment/entitlement/management simplified.
  • Quote from customer: “Application updates are kind of a non-event now”.
Random ThinApp notes:
  • ThinApp packages can talk together and with the host OS.
  • ThinApps can be streamed (only necessary data needed to run the application is copied locally) within Viewfrom a central location or executed locally.
    • Streaming packages are easy to spot since the application will be much smaller than the non streaming version.
  • Remote users should not attempt to stream applications over the WAN/remote link; ideal configuration is to use a View desktop in the datacenter and execute the ThinApp package from there.
  • ThinApp “AppSync” technology enables locally copied ThinApp packages to check in with an “AppSync Point” to see if they are running the latest version; applications can then be updated automatically.
Very interesting subject today although the slides contained a lot of information that was not talked about during the presentation. The bright side of this is that I was forced to do a little research when writing this post. Visit the discussion page for today if you want to read more about the topic of the day.

VMware View 4.6 Bootcamp Day 4 – Optimizing the Base Image for VMware View

The VMware View video bootcamp continued on day 4 with a presentation by Todd Dayton about “Virtual DesktopImage Tuning”. Given that many view environments take a small number of master images and deploy a large number of VM’s it should go without saying that this is a very important subject to View admins and architects out there. The differences (and similarities) between virtual and physical desktops.

  • General rule: If something causes poor performance in a physical desktop, it will also cause performance in a virtual desktop.
  • Some things that don’t cause poor performance on a physical PC *may* case problems in a VM, namely background tasks (indexing, screensavers, and so on).
Key areas for basic OS tuning
  • Start with an image built within the vSphere environment.
  • Understand the ramifications of shared resources (no one wants contention).
  • Wherever possible reduce or eliminate any background process that run when the user is not present.
  • Keep the amount of locally installed applications to a bare minimum.
  • Understand what each component of the OS does and why it is there.
  • Update to the latest or “best” version of the software you are using.
  • Tune the image both for performance AND user acceptance.
  • Know when enough tuning is enough.
  • Remember that time spent in the beginning making sure that the master image is “right” is time saved at the end patching/updating/replacing physical desktops.

Introduction to basic image tuning. Storage reduction

  • Hibernation file – Disable; generally not used in View. Often sized at least 2/3rd of system memory. Can disable at command line by typing “powercfg /hibernate off” (no quotes of course).
  • Debug logs – On by default in the VMware View Agent.
    • Average size in 10MB plus per log and can grow quickly; appear in linked clones and increase overall write operations while in use.
    • Can be disabled by editing the registry key “HKLMSOFTWAREVMware, Inc.VMware VDM“. Set “DebugEnabled = False” and “TraceEnabled = False“.
  • Remove Windows update uninstall folders and patch backups (Windows XP only).
  • Delete any user profiles that were used during image testing.
  • Empty temp folders and clear browser cache.

Background performance

  • Indexing services – Use idle time to catalog files; affects performance of other users whose machines are not idle.
    • Indexing in general is very IO intensive and if/when the VM’s are recomposed any indexing services will start all over again, compounding the issue.
    • General tips:
      • Disable the “Windows Search” service to prevent background scanning.
      • Don’t install any desktop search tools (Google Desktop) in a View image.
      • Ensure that any browser toolbars or add-in software do not contain any indexing functionality.
  • Virus scanning – VMware suggestion is to pre-scan the master image before deployment; any new viruses should be identified by the “On-Access Scanner”.
    • In addition, pre-scan the image before any recompose to make sure that no malware has been introduced into the master image (personally, I would continue to do scheduled scans but stagger and randomize them as I would any scheduled task within the View environment).
    • Randomize (within a wide window) and stagger any virus signature updates to minimize the IO and CPU load these operations require.
  • Screensavers – Screen blanking or locking is preferred as the screen savers require a certain amount CPU resources.
    • The “blank” screensaver “scrnsave.scr” can be forced using Windows group policies (User Configuration Policies – Administrative Templates – Control Panel – Personalization).

Remote display performance

  • Disable wallpaper and sounds
    • In a View environment a high resolution/high color wallpaper can cause resource spikes as it is loaded and uncovered by other windows.
    • Using a solid color background allows for smoother transitions and more consistent bandwidth utilization.
    • Windows sounds should be disabled unless specifically required for the same reason as they lead to random bandwidth spikes within the View protocol stack.
  • PCoIP tuning parameters
    • View includes GPO templates for specifying some PCoIP protocol variables.
    • Values that affect bandwidth include:
      • Configure the maximum PCoIP session bandwidth” : Also known as the ceiling; the maximum amount of bandwidth the PCoIP connection will use.
      • Configure the PCoIP session bandwidth floor” : Lowest bandwidth a PCoIP connection will tune down to when making room for other traffic on the network.
      • Configure PCoIP image quality levels” : Determines how “lossy” an image can be or how “good” it must be; helps ensure a steady framerate.
      • Once the GPO template has been loaded these values appear in “Computer Configuration Policies – Administrative Templates – PCoIP Session Variables – Not Overridable Administrator Settings“.
      • A separate setting (Maximum Frame Rate) must be set by editing the registry key “HKLMSOFTWARETeradiciPCoIPpcoip_admin_defaults”.
        • Edit the pcoip.maximum_frame_rate value which has a default value of 30. For comparison Citrix HDX uses 24, 16 can be considered “good”.
My thoughts: As with any deployment tuning is a subject that will be unique from one deployment from the next. There are basics that you will apply to almost all deployments but user needs and expectations as well as organizational requirements must have a say into any tuning that is done. The day 4 video did a good job in exposing people to the types of things they need to think about as they work with their environment to develop animage that delivers what the organization needs with a level of performance that is acceptable. Also, visit the forums for the day 4 video! Not as active as the previous days oddly enough as we have been talking about imageoptimization since day 1.

VMware View 4.6 Bootcamp Day 3 – Network Considerations and Best Practices

Day three of the View Bootcamp focused on Network Considerations for VMware View; the presenter was Shannon McFarland of Cisco Systems. The video opens by linking View requirements to the capabilities of the network. The requirements are broken down as follows:

View Requirements

Network Capabilities

User Experience

QoS/HA/Performance Availability

End-to-End High Availability Access

Any Device/Anywhere Performance

Network/Compute Security

Defense in Depth

End to end management

Service Management


Common assumptions made by the View admins:

  • The network doesn’t matter. Response: “It is critical to have a hierarchical, scalable and flexible networkarchitecture that can meet your demands regardless of application and service. The network provides end-to-end security, availability, QoS and many other elements that improve user experience”.
  • I need to buy a bunch of networking gear to deploy View. Response: “You probably already have a pretty robustnetwork that supports existing applications and services that can be used for VMware View.”
Direct Mode vs. Tunnel Mode
Direct Mode: A View client establishes a direct connection to the View Agent over RDP or PCoIP; initial connection still goes to the Connection server.
  • Advantages of Direct Mode include: less load on Connection server, more granular application visibility for QoS and WAN optimization, flexibility to use either RDP or PCoIP, and higher availability for in-     progress sessions.
  • Disadvantages include: Comprehensive security policies need to prevent direct logins to VM’s without using the View Connection server. Also, Direct Mode cannot be used in environments where only HTTP/HTTPS is allowed.
Tunnel Mode: Also known as proxy mode; in Tunnel Mode the client uses the View Security or Connection Servers for all phases of communication. Tunnel Mode is based on the encapsulation of RDP into HTTP or HTTPS.
  • Advantages include:
    • Tighter access control and policy enforcement.
    • Allows for HTTPS connection into the View environment which means that the traffic can be optimized using WAN optimization solutions.
  • Disadvantages include:
    • Much heavier load on the View Connection and Security servers.
    • View traffic is more difficult to identify on the network when it is all HTTP/HTTPS.
    • The use of HTTP proxies may interfere with View client connections.
Bandwidth Considerations:
  • Bandwidth consumption can vary depending on the display protocol, workload, and auxiliary connections such as USB redirection.
    • This makes capacity planning difficult as not every connection will be the same.
    • Due to HTTP/HTTPS encapsulation View traffic looks like traditional browser traffic.
  • Thorough testing is critical to capacity planning.
  • WAN optimization can provide a great deal of help in conserving bandwidth.
  • QoS may be a critical requirement in order to manage congested links.
The same tools that are used to protect the datacenter from internal threats must be extended to the View environment. To help manage load and optimize traffic the View environment can use many of the same tools we apply to other datacenter applications:
  • View Client: WAN optimization can help reduce bandwidth needs; dependent on display protocol and features used.
  • View Connection and Security Servers: Supports the use of SSL offload, server load balancing, and WAN optimization.
Examples of where QoS can help manage the View bandwidth:
  • Treats View traffic differently when there is congestion. Examples: View is throttled when competing with voice traffic; non voice traffic is throttled when competing with View traffic.
  • My manage via source/destination since tunneled view traffic is HTTP/HTTPS (similar to browser traffic).
  • Direct mode is the best choice for proper traffic classification.
The video went into a fair amount of detail about load balancing designs; I recommend that anyone with interest in the specifics of load balancing view that bit for themselves.
Link to deeper look inside topics that were covered in the video from Cisco.
As always, the discussions provided additional information related to the day 3 video. Onward to day 4!

VMware View 4.6 Bootcamp Day 2 – Storage Deep Dive – Considerations and Best Practices

Day two of the VMware View Bootcamp focused on storage considerations for the View environment. Jim Yanick talked about a number of different things about how your decisions impact the storage requirements for the Viewinfrastructure. My key takeaways from the video are as follows: View Composer is a key feature of View 4.5/4.6; it allows for linked clones. Linked clones are all deltas of a base (read only)  master image; they deploy rapidly since only a delta of the parent image needs created. 75% average storage savings based on VMware customer data versus deploying full clones. View Premier Bundle includes Composer, ThinApp (application virtualization), and Local Mode (makes full clones portable by making it possible to download them to the local host from the View environment). View vSphere limitations: 8 vSphere Host cluster limit per View Manager Pool with Composer

  • vSphere host limit as 8 as that is the maximum number of hosts that can access a given read only file.
  • 320 VM HA maximum (vCenter 4.1); the limit on the number of VM’s that vCenter can power on in the event of a host failure.
  • The amount of time required to place a vSphere host in maintenance mode; will vary based on number and capabilities of hosts present in the cluster, number of VMs, and the storage infrastructure.
  • The ability of the vSphere cluster to absorb the impact of AV updates or scheduled scans.

View 4.5/4.6 supports Quickprep (VMware View feature) or Sysprep (Microsoft tool). Both use a dedicated domain account that you specify in View Manager

  • Quickprep- All VM’s will share the same machine SID. FYI, based on my own personal experience I would test quickprepped VM’s with IIS applications that use integrated authentication, which includes Exchange 2010 – Outlook 2007/2010 communications. Watch for problems where you are forced to re authenticate over and over again. Read the discussion here (not just the post) for more details.
  • Sysprep – The VM SID will be lost on recompose or rebalance BUT maintained on refresh. Compared to Quickprep system slows VM deployment and requires multiple reboots.

Tiered storage support: The ability to direct replica disks, OS disks, and persistent disks to different storage. For the purpose of optimization redirect the disposable disk to alternate storage locations:

  • Disposable disk contains paging and system temp files (this is to save space on the VM delta files, not specifically for performance)

The persistent disk can be managed using the View web console; one example would be when you need to move a user to a new VM due to job change or some other event. Place the master VM image on SSD for read IOPS to support the IO of many linked clones (simultaneous boots, etc) Important documents:

Involve storage architect in View planning; key for ensuring that storage IO needs are met as IO is usually the issue, not capacity. Some best practices for the parent VM:

  • Use LSI disk drive for XP; SAS forWindows 7
  • Turn off drive indexing
  • Defrag the drive – both the image and the VMDK
  • Clean out all system temp files
  • No P2V; build from scratch
  • Keep the image as clean as is possible
  • Disable any unneeded services
  • Parent VM goes on best storage available, is backed up, protected, etc

View can distribute linked clones evenly across pools (on the fly (round robin) or via rebalance)

  • Keep datastores roughly same size to ensure round robin distribution works as intended
  • Storage over-commitment levels (how many linked clones to place on a given datastore): None, conservative (x4), moderate (x7), aggressive (x15)
  • To assess VM IO needs Lakeside Software / Liquidware Labs products

Dedicated pools require that persona information be stored and protected (use roaming profiles, folder redirection, third party tools). Storage growth management tip: The more you refresh the linked clones, the less they will grow. Things to consider during the design on the View infrastructure:

  • How large is the parent disk image?
  • How many different images to I need? May need few depending on if apps are installed locally or delivered via ThinApp.
  • How many unique linked clone VMs are required?
  • Persistent disks or persona management for dedicated pools?
  • What are the average and peak IOPS of my desktops? (Note: can be sampled with a test VDI desktop on a dedicated LUN and reports from the storage administrator)?
  • What kind of tasks to my users perform?
  • What are the most IO intensive applications?
  • Are any unauthorized applications in use?
  • A proper assessment of the environment will answer these questions

Some important stats: IOPS ratings for disk drives

  • 7200RPM SATA: ~80 IOPS
  • 10K RPM SAS: ~140 IOPS
  • 15K RPM SAS: ~180 IOPS
  • SLC SSD: ~400 IOPS
  • Enterprise Flash (EMC given in the example): ~2500 IOPS

Remember that the IOPS capability for a raid depends on the configuration; you can’t just add up the numbers. Duncan Epping did a good writeup to help explain how to calculate the IOPS limit of a raid group. Baseline desktop IOPS needs (your results may vary):

  • Lite user: ~ 6 to 8 IOPS
  • Medium user: ~ 8 to 20 IOPS
  • Heavy user: ~10 to 30 IOPS

Recommended limits for VM’s per ESX 4.0 datastore (again, your results may vary):

  • Max VM’s per VMFS datastore:  ~90; 60 is “safer”
  • Max VM’s per NFS datastore: ~170; 150 is “safer”

AntiVirus – Scheduled scans and updates can cause severe IO and CPU spikes. Must either plan for this or find alternative solutions. vShield Endpoint as an alternative to traditional AV clients

  • Attached to hypervisor, no client agents
  • More manageable and secure than agents within the VM’s
  • No more resource storms due to client AV activity
  • Trend Micro only vendor offering the plugin at time of training

That concludes the lessons for day two. If you have additional interest in the topic I recommend participating in the accompanying discussion for the day two video or if you like replying to this post. Up next for day 3 is networking!

VMware View 4.6 Bootcamp Day 1 – Design Consideration Guidelines for VMware View – Overview

Let me start out by saying that VMware has done a very good thing. VMware View is a good product that is difficult to obtain low cost training on (save for recent releases by Train Signal and some work by Mike Laverick)  and I think they have finally recognized that. The offer a traditional classroom training for the product but most small shops can’t afford that, especially if they did scrape to afford the flagship vSphere Install/Configure/Manage course.VMware has released a 9 day video bootcamp that covers most of what you need to know to begin planning yourView implementation. I say “most” because subjects such as storage and networking differ from one company to the next so they can’t give much more than basic guidance on those topics. Today was day 4 of the video series and now that the weekend is here I wanted to touch on what we  have learned to date. Day 1: Design ConsiderationGuidelines for VMware View – Overview Day 1 focuses on many of those things that no one likes, which is the types of analysis you must do when planning to implement VMware View. Speaker John Dodge talks about the concept of “design entanglement”, which is basically the idea that every decision you make may impact the Viewdesign in multiple ways. Some examples:

  • The applications required affect memory and CPU requirements.
  • The operating system chosen affects the applications you can run, the CPU you need, the ram you require, and the storage needed.
  • The amont of ram dictates the size of your virtual swap file which impacts your storage needs.

Think about it; these three “simple” things that we rarely think of impact our View design heavily. The video goes on to talk about the decisions we must make when laying out the View components themselves:

  • User persona (profiles): None (use a default Windows profile), native OS (let them grow on the virtual machine), or external (roaming profiles or managed using a third party tool).
  • Desktop design: What OS to deploy, what virtual hardware is required to run it (ram/cpu/storage), and will the apps be installed directly within the base image.
  • View pool design: Floating (virtual machines can be used by multiple individuals), dedicated (virtual machine tied to a specific user), local mode (users “download” virtual desktops to their laptops for transport), or non linked clone (users get a full copy of the base image).
  • Application delivery: Traditional (installed within the base image), virtual (VMware ThinApp or similar), or SAAS.

These questions require that the design team have a solid understanding of the needs of the target audience of theView environment. Only when these needs are known can the true needs of the View environment be estimated. One of the final concepts the video touches on are the constraints that we must consider before moving forward with a View implementation:

  • Quality: Are there organizational standards we must adhere to when undergoing a project such as this?
  • Knowledge: Per my last section, do we have adequate knowledge of the environment so that the Viewimplementation can be properly supported?
  • Standards: Are there existing standards in place that affect the decisions we have made/will make with regard to hardware, software, or other aspects of the View implementation.
  • Budget: Does the organization have the resources needed to implement View according to the designrequirements? What are the CAPEX and OPEX values for the View environment?

Anyone who has lead large IT projects should be familiar with many of these constraints; based on my own experience they are fairly typical. The video closes by going over the new features introduced in View 4.6:

  • Security server: View server placed in a DMZ that acts as an intermediary between the internal View resources and the external clients.
  • Tiered storage: The ability to direct View data to unique storage tiers (example was keeping the replica disk seperate from the linked clones).
  • Local mode: The ability to download a full clone to a local machine for portability (primarily for laptops).

All in all the day 1 video was very interesting and lead to some interesting discussions on the day 1 message board. The message board adds to the overall educational value of this video series and the participants often build upon the video of the day and ask even more involved questions. Day 2 writeup to follow on Saturday! – Jason

Missing: the last 5 days. If found…..

Starting a new job is exciting, well it should be anyway. If you aren’t excited about it why would you have accepted the offer in the first place?

My first week at EMC was spent reading. Perhaps it is better described as an opportunity to learn what it is I don’t know, which is always more than you think. This is in no way a surprise or a source of frustration; I’ve come to realize that I work with some fairly unique (and highly skilled) individuals within the organization whose talents are in demand. The reading also helped prepare me to take an internal exam, which you must pass before you are given access to certain sources of technical information.

My immediate team is rather interesting. My team lead was at Cisco Live last week doing a variety of things EMC related and my coworker (peer if you will, although I wouldn’t use that term just yet) is going up to HQ (Hopkinton, MA) this coming week to perform a customer proof of concept demonstration. My purpose on the team is to be able to equal them as closely as is possible, and I can already tell you that it is going to be among the most challenging things that I have ever done in my career. My team is responsible for developing documents likethese, and I’ve been pouring over them and many like them as I’ll be expected to participate in exercises like that as soon as is possible.

Some things that have become obvious over the last week:

  1. If you paid any attention to the vSphere 5 launch this week and follow the top tech blogs you can’t help but notice that EMC employees that blog (particularly the vSpecialist team) were ready with article after article immediately after the launch. I use Google Reader (my feed list is linked in the left column of this page; EMC maintains a list here that is fairly accurate) and I was overwhelmed that day by post after post of analysis about the announcement. I don’t care if you like EMC or not; if you want timely analysis of virtualization news you should be following them.
  2. Hard work does pay off but luck never hurts. I busted my ass to get where I am today but it took an alignment of the planets to finally get me in the door at EMC. My advice to those who want in: network with employees (this is nothing new) and get to know recruiters (thank you LinkedIn). I had a very helpful recruiter who gave me some resume tips and then got that updated resume to who it needed to get to. I had applied to EMC at least seven previous times and I can assure you that getting an interview is not as easy as you would like. Oh and ifyou do interview and it went well BE PATIENT. Just trust me on that one.
  3. It is very cool to be among a very small number of people in the company who get to see or hear things first. I can’t really get into details but the fact that I got to learn something BEFORE people whose blogs I read religiously (and go to for news) is pretty exciting. For me it is just another reminder that much will be expected of me and that nothing less than 100% effort is going to cut it.
  4. When do all these people have time to write? It requires discipline that I do not yet have. Give me a few months though and I might be able to post some of that “Day 0″ news that is likely the biggest inspiration for them to author new posts. My closing thought: Great things lie ahead; I can’t wait.