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
- 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.
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).
- 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.
- 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
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:
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.
- 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
- 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.
- 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.
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.
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!
- 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.
- 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.
- 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!
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!
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.
- 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.
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.
- 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.
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:
End-to-End High Availability Access
Any Device/Anywhere Performance
Defense in Depth
End to end 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 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!