Conflicting Guidance on No GUI Boot and Base Video settings for VMware View Desktops

I’ve been working on writing up a complete guide for optimizing VMware View desktops.  In my research I’ve come across some conflicting information on using the ‘No GUI Boot’ and ‘Base Video’ boot optimizations found in the Microsoft System Configuration Utility (msconfig.exe).

Why You Might Use ‘No GUI Boot’ and ‘Base Video’ Tweaks

No GUI Boot

The ‘No GUI Boot’ option disables visual elements in the Windows boot sequence (the Starting Windows screen with the swirling colored dots that turn into the Windows logo).  The idea with this optimization is that CPU cycles are needed to render, on the console, the animated logo.  Saving CPU cycles by using No GUI Boot will have a cumulative effect when multiple VDI desktops are booted, thus reducing the boot storm effect on the VMware View infrastructure.

Hardcore Windows tweakers will also tell you that enabling the No GUI Boot option will make Windows boot faster, and faster boot times will get non-persistent desktops back online faster in a very dynamic floating pool View implementation.  The actual boot speed performance impact is marginal at best as can be seen here:

Base Video

The ‘Base Video’ option forces Windows to run the console session with a standard VGA graphics driver instead of the VMware SVGA driver that is installed with VMware Tools.  This works with View because the PCoIP Server that runs as part of the View Agent install loads a specific version of the VMware SVGA 3D driver to support PCoIP sessions at user connection while the base video VGA driver or the VMware Tools/View Agent driver run on the vSphere console session.

With Base Video set, the Windows console runs at 640 x 480.  A standard VGA driver running with a low resolution will consume less memory. VMware View desktops pull their memory from the shared physical memory on the host and not a dedicated GPU or video card, so a little savings multiplied by potentially hundreds of VM’s on a host will begin to change RAM sizing for the View ESXi servers.  The vSphere Video Memory Calculator demonstrates the difference in memory consumption vs. screen resolution:

Saving ~7 MB per desktop, with 200 desktops per host, *could* yield back a whopping savings of 1.4GB of RAM per host.  You’ll consume more RAM enabling the View Storage Accelerator.  If you’re hurting for 1.4GB of memory on a host with 512GB of RAM (0.2% savings) you’ve got bigger problems!  That’s the problems with many tweaks – many yield marginal improvements in performance that probably aren’t worth your time, even when you’ve taken the multiplying effect of many high VM:phyicsal consolidation ratios.  I’m not saying not to optimize – many, such as reserving a portion of your View desktop’s RAM to save on vSwap space and improve responsiveness of idle but in-use desktops, will pay off.  But I digress…

Documentation Conflicts

So we’ve seen that these two optimizations may yield some savings.  In fact, they are called out in several VMware, EMC, and third-party documents and blog posts.  For example, see page 55 of the View 4.5 Admin Guide – a dated document to be sure, but still out there and still influential in some of the older blog posts.  A current document with this guideance is EMC’s ‘h8043 Deploying Microsoft Windows 7 Virtual Desktops with VMware View: Applied Best Practices‘ – damn fine document, to be sure, but with some errors.  I’ll also point out this blog post as it is often returned near the top of a search for Windows 7 Optimization for VMware View searches: https://ituda.com/vmware-view-5-x-windows-7-golden-image/ -an awesome post with some often missed steps.

So what’s the problem? There is a known issue where dual monitors configured using PCoIP does not span both the monitors for VMware View.  The issue is described in VMware KB 1027899 and Teradici KB 15134-793 with symptoms described as:

• Second display blanks after a VM reboot.
• After a VM reboot only the primary display is visible, the secondary display is blank.
• When configuring dual monitors using the PCoIP protocol, the display does not span both the monitors.
• The display appears only in one half of each monitor.
• The other half of each monitor is rendered blank.
• This issue does not occur when using the RDP protocol.

The KB’s both instruct you to uncheck the No GUI Boot and Base Video options, as well as to increase the maximum number of monitors and maximum resolution size on the parent VM for the pool (the opposite effect we were after with the Base Video option), to correct these display problems.

Note: these aren’t the only multi-monitor issues in View – I covered another one here: Lag When Dragging a Window Between Monitors in VMware View.

Bottom line: don’t use the No GUI Boot and Base Video options when optimizing your View desktops – they cause more problems than they solve.

Optimization Rules

I”ll leave you with my top 10 rules of thumb to consider when applying optimizations to View desktops.

1. Don’t disable features your users depend on (Windows Search, for example).
2. Don’t waste time messing with tweaks that may yield less than a couple percentage points of performance increase or resource consumption decrease per virtual desktop.
3. Test your optimizations with all of your applications – a setting that you tested in a base image may work well, but could cause problems when apps are installed.  Then test again (not all optimizations you find on the Internets can be believed).
4. Search the VMware, Microsoft, and Teradici knowledge base repositories for info on your tweaks before applying them.
5. Use the latest version of VMware View and reference the latest official documentation or documentation from a trusted source.
6. Balance user experience with your performance and resource utilization goals.  A stripped down Windows install might consume less IOPS, memory, CPU and memory, but look like Windows 2000.
7. Reconsider #6 again.  Many guides suggest disabling the Recycle Bin, for example.  How many times have you deleted something then pulled it back from the Recycle Bin?  Immediately deleting files instead of recycling them is probably inconsequential as far as disk space goes, and once is all it takes for a user to begin cursing IT and their newfangled virtual desktops when they lose a file that they expected to end up in the Recycle Bin.
8. Track your changes to your parent image.  If something does cause problems, you’ll want a list to work back from as you troubleshoot.
9. Optimize more than your base image.  Many guides focus on just optimizing a basic Windows install.  Think about optimizing the applications you thick install, your ThinApp packages, etc.  Disabling auto-updates in apps might reduce Linked Clone growth rates and reduce network bandwidth consumption, while reducing user pop-ups.  Removing unused features can save disk space.  Turning off Outlook Cache Mode (.ost files) can save a ton of bandwidth and disk space in a non-persistent setup.  The list could go on….
10. Apply optimizations to your base image and copy the default user profile (use a Sysprep Answer File .xml for this) AND apply them with Group Policy whenever possible to ensure that the settings remain in place despite your users’ best attempts to override your work.

I’m finalizing a complete guide to optimizing Windows 7 for VMware View that will be published on the Clearpath Solutions Group blog.  I encourage you to sign up for email updates on our blog to be notified when it is published – there’s a sign-up form on the right-hand side of the site.  The guide will include all of optimizations I know of, and go beyond Windows basics to include sizing, standard application enhancements, scripts and GPO policies to automate the tweaks, and some best practices guidelines.