Making a leaner fitter Windows 7 Virtual Desktop

In our last blog post (http://blog.millennia.it/a-closer-look-at-storage-and-virtual-desktops), we touched on the IOPS issues that can mean the difference between a VDI project succeeding or failing.

We have seen how VDI can produce a lot of very random I/O spikes that can cause slow or, worse for the end user, unpredictable performance throughout the working day. It is therefore important that scale testing is done as part of any VDI implementation, because what might look great with 20 VMs running could be exhibiting problems by the time you pass 100 and completely unusable before you reach 150 VMs – a problem if your wish was for 400 concurrent users!

This time we look at making the best Windows 7 image so you can make sure you get the most out of your VDI implementation. This is not meant to be an exhaustive guide, but covers the main areas that can be addressed to be able to cut down the footprint of the master Win7 image, which when scaled to hundreds or thousands of user VMs can make a huge difference to resource consumption and therefore likely performance.

Configure the virtual machine settings

Windows 7 compatibility – make sure that you can support running Windows 7 as a guest OS. With VMware you need a minimum of ESX 4 Update 1 on the host servers plus VMView 4.5 for official Windows 7 support. The VM should also be a version 7 VM ideally – which is easy to configure.

vCPU count – Use as few vCPUs as possible while providing the required amount of CPU resource to your client VMs. Counter-intuitively increasing the number of vCPUs can actually hurt performance as the hypervisor has to co-schedule on to more physical CPU cores. When testing look for VM CPU utilisation to remain below 70% and, importantly, the %RDY (the amount of time the vCPU is waiting for a free physical core to be able to process waiting work) to be less than 10%.

If a VM reports low CPU utilisation and high %RDY values then you are overstressing the physical CPU system and need to investigate the cause of this CPU over-provisioning. It could just be a case of reducing the number of VMs per core, but could also point to an application issue swamping CPU on the guest OS. Silverlight apps are particularly prone to this.

VM memory – Ideally you need to prevent paging to disk in a VM environment as this can kill a system when hundreds of VMs share the same physical disk subsystem. Therefore you should not have more than 75% of VM guest memory active at any one time, and should look to allocate from 1GB to 1.5GB of RAM per VM depending on likely workload. This can be tuned during testing to around 1.25x the maximum active working set size during a normal test load. Note that on boot up Windows zero out all RAM space, so the active size temporarily hits 100% – which can cause issues when a lot of machines first boot up and needs to be noted as a potential issue in the live environment.

SCSI controller – Select the default LSI Logic SAS controller on a VMware system as Windows 7 has drivers already in its image and the controller provides good performance.

Disable virtual machine logging – Every time a VM is powered on it logs diagnostic information to the data store hosting its VMDK file. Disable this or on a large scale VDI system the overhead can be significant.

Edit BIOS settings – When creating the initial Windows 7 image, and before installing the actual OS, force the VM into the BIOS setup via the boot options, and in the I/O Device Configuration disable the serial and parallel ports on the VM if they are not required.

Install using 8KB allocation size – Increased performance has been observed with Windows 7 then formatting the boot volume of the VM with an allocation size of 8192 bytes instead of the default 4096. Because Windows 7 currently does not support creating this during a standard install then use the following procedure:

1.       Boot from the Windows 7 ISO image or CD and proceed through the install steps until the Where do you want to install Windows dialog appears.

2.       Press Shift-F10 to bring up a command window

3.       In the command window enter the following commands

a.       Diskpart

b.      Select disk 0

c.       Create partition primary size=400

d.      Active

e.      Format fs=ntfs label=”System Reserve” quick

f.        Create partition primary

g.       Format fs=ntfs label=”OS_8K” unit=8192

h.      Assign

i.         Exit

4.       Click refresh button to refresh the Where do you want to install Windows screen

5.       Select Disk 0 Partition 2

6.       Complete the install to the second disk partition.

Windows Optimisations

There are two different types of VM in a VDI implementation depending on the persistence of user information when they log off. Persistent VMs maintain user information such as cookies and browser history, and are generally used when it is important that a user gets the same VM each time they log on – e.g. a power user with specific applications installed. Non-persistent VMs are generally deleted after use and re-provisioned, and therefore can be much more aggressively tuned.

In general it is recommended that normal business users have non-persistent desktops as these are the most secure and easy to manage, as well as generally consuming less resources than their persistent counterparts.

Each optimisation listed here will be marked either {NP} for non-persistent or {A} for either type of VM.

Finally make sure VMTools are installed on the master image.

Disable Error reporting {NP} – Disable the error reporting to Microsoft that occurs when there is an application or OS crash. You do not want this to come up on a desktop that will be refreshed anyway on logoff. The best way to do this is via Group Policy; the Disable Windows Error Reporting is located at Computer Configuration > Policies > Administrative Templates > Windows Components > Windows Error Reporting

Disable Automatic Updates {NP} – Updates should be applied by updating the master image and rolling out new virtual desktops from this. Disabling updates can be done during the making of the master image by going to Control PanelSystem and SecurityWindows UpdateChange settings

Remove unnecessary applications {A} – Many applications load boot-time processes that aid with application performance by caching and pre-fetching specific data into memory before the application is even requested by the user. Examples of this are boot-time stubs loaded by QuickTime, Real Player, Adobe Acrobat, etc. Scaled across a large solution these can add unnecessary I/O and may not even be used. Apps like Acrobat can be virtualised so they can be called when needed to read PDF files, but don’t consume resources until then.

Remove Windows components {A} – Remove any Windows components that are not needed but enabled by default after install, such as MSN Explorer or Tablet PC components. Go to Control PanelProgramsPrograms and Features and select Turn Windows features on or off.

Change NTFS behaviour {A} – There are NTFS options that can be tuned using the fsutil command to minimise file system overhead. These options include the ability to disable DOS style 8.3 filenames and the “last accessed” time stamp on a file; this can reduce write workload when applications that access many files are used.

To disable these features open a command window and enter the following commands:

fsutil behaviour set disablelastaccess 1

fsutil 8dot3name set 1

Disable hibernation {A} – Given the high I/O cost of writing the contents of system RAM to the hibernation file do not allow virtual desktops to go into hibernation. This can be disabled with a command powercfg /hibernate off

Disable system restore {A} – Since most VDI environments do not require system restore, this feature can safely be disabled. User data should be redirected to a centrally backed up filestore and away from the desktops, therefore if desktop corruption occurs a replacement can be reprovisioned. This saves significant I/O maintaining a snapshot, and also reduces space used by the desktop.

To disable system restore:

1.       Right click My Computer

2.       Select PropertiesAdvanced System SettingsSystem Protection

3.       Select the C: drive

4.       Click the Configure… button

5.       Under the Restore Settings section, select Turn off System Protection

Disable paging the executive {A} – By default Windows writes kernel-mode drivers and system code to the Windows page file when not in use to make more memory available for the system. So long as the VM is assigned sufficient memory you may disable this option to save I/O.

To disable paging of the executive:

1.       Edit the registry of the master image with regedit or regedt32

2.       Select HKLM > System > CurrentControlSet > Control > Session Manger > Memory Management

3.       Find the DisablePagingExecutive key

4.       Change value from 0 (default) to 1

Set page file to fixed size {A} – Windows dynamically expands and shrinks the Windows page file as required. This can lead to fragmentation and unnecessary I/O overhead. Therefore it is recommended the page file be set to a fixed size, and if memory allocation has been properly conducted then 512MB should suffice as further use would impact I/O of the VDI system and should be avoided. Messages of virtual memory getting low on VMs will act as an early warning that allocated RAM is too low, but this should not happen is RAM is sized correctly in the first place.

Disable Indexing {NP} – Indexing can create I/O overhead on a VM as it builds the index cache. As user data should be held off the VM there should be no reason for indexing to be present and it should be disabled for the C: drive:

1.       From My Computer highlight the C: drive and select Properties

2.       On the General tab clear the Allow Indexing Service to index this disk for fast file searching checkbox

3.       Navigate to Indexing Options

4.       Open the Control Panel and click Modify button

5.       Deselect all locations in the list

Disable unnecessary services {A} – Many services are not useful in a virtual environment and can be disabled. The following list is a suggestion but by no mean comprehensive list of services that could be disabled. You should check to see what others may be safely disabled to help minimise the VM footprint for both RAM and CPU:

·         Telephony

·         Shell Hardware Detection

·         Machine Debug Manager

·         Remote Registry

·         Task Scheduler (this may not allow disabling and could prevent other software from working)

·         Network Location Awareness

·         Windows Audio (if sound is not required in the environment)

·         Themes

·         WWAN AutoConfig

·         WLAN AutoConfig

·         Windows Update ({NP} – persistent desktops should still use Windows Update)

·         Windows Connect Now

Disable SuperFetch {NP} – SuperFetch analyses usage patterns and based on repeated user action it pre-populates RAM with programs the user is likely to launch. This causes unnecessary I/O and any optimisations are destroyed along with the desktop when the user logs off. SuperFetch also allocates more of the system RAM for its use, which can increase pressure in host RAM due to more VM RAM activity.

Note {A} – On systems where the random read performance is over 8 MB/s as measured by the WinSAT test then the SuperFetch service may also be disabled for persistent desktops as the benefit is outweighed by the impact on system RAM for this speed of disk. Run winsat disk from a command line to determine the storage performance of your master VM.

Disable Scheduled Defrag {A} – The disk defrag is scheduled to run once a week by default, which is not desirable due to the system overhead across many VMs. To disable this:

1.       Open the properties for the C: drive

2.       Select the Tools tab

3.       Click Defragment now to display the Disk Defragmenter dialog box

4.       Click Configure Schedule

5.       Clear the Run on a schedule checkbox

Disable boot graphic {A} – Windows 7 draws a startup animation during the boot process. This will not be seen by users as they are not connected to the console of the VM, and therefore it needlessly consumes resources. To disable:

1.       Start the msconfig.exe program

2.       Select the Boot tab

3.       Under the Boot options, select No GUI boot and Base Video

4.       Clear the Boot log checkbox unless this functionality is desired (unlikely after deployment).

Creating a custom default user profile

Under Windows 7 the default user profile can no longer be copied user space from another profile as it was in XP. Therefore a new process is required to provide a default user profile based on changes made to the administrator profile during the creation of the master image.

Create an answer file

To create and manage an answer file the Windows System Image Manager (WSIM) must be installed on a workstation. WSIM is part of the Windows Automated Install Kit (AIK) and can be found by searching for “Windows 7 AIK” at http://www.microsoft.com/downloads.

To create an answer file:

1.       Open WSIM and under Windows Image header, right click and select Select Windows Image

2.       In the open dialog box, browse to the sources directory of a Windows 7 DVD or mounted ISO file and select the install.wim file. This will load the Windows 7 installation image structure into WSIM.

3.       From WSIM select File > New Answer File to create a blank answer file

4.       Save this file as sysprep.xml

5.       Under the Windows Image header, expand Components

6.       Locate the name that is similar to x86_Microsoft-Windows_Shell-Setup_6.1.7600.16385_neutral. If this is a 64-bit VM the prefix will be amd64 instead of x86, and later Windows versions may change the numbering indicated above.

7.       Right click this key and select Add Setting to Pass 4 specialize

8.       In Answer File pane, expand 4 specialize and select x86_Microsoft-Windows-Shell-Setup_neutral (again look for amd64 for 64-bit)

9.       Change Copy Profile option to true

10.   Save the answer file as sysprep.xml

11.   Copy the file to the master golden image under c:Windowssystem32sysprep

Windows profile customisations

This details procedures to customise the Windows profile

Audit Mode – When a valid sysprep.xml file is present the golden image machine must be booted into audit mode. To do this run c:windowssystem32sysprep /audit.  

After the system reboots into audit mode it automatically logs in with the admin account, so the customisation can therefore begin.

Change the default theme – The default theme uses many optimisations to paint a more graphically complex user interface; this creates increased processor and network overhead. For VDI it is suggested the default user theme should be Classic. However if the Themes service has been disabled the Classic theme becomes the default, so this is often the best way to enforce this.

Adjust for best performance – Some of the more advanced UI features, such as menu fading and animations, require extra CPU and memory resources to use. To turn off these effects:

1.       Go to Control PanelSystem and SecuritySystemAdvance System Settings

2.       Click Settings… in Performance

3.       Either select Adjust for best performance to set everything off or deselect some features in Custom.

Disable the screen saver – The screen saver is not needed in a VDI environment and consumes resources so should be disabled.

1.       Go to Control PanelAppearance and PersonalizationPersonalization

2.       Click on Screen Saver icon

3.       In dialog box that opens select None from the drop down box.

Complete the default profile

After all the required changes have been made to the local admin profile, sysprep must be run again to copy the account over the default user account. Reseal the system by running the following in a command window (assuming sysprep.xml file is located at c:windowssystem32sysprep as indicated earlier): c:windowssystem32sysprepsysprep.exe /generalize /oobe /shutdown /unattend:C:windowssystem32sysprepsysprep.xml.

This causes Windows to copy the admin profile over the default profile and shutdown. Now any user logging onto the desktop will inherit these settings. The default user profile can also be copied to a network share if so desired.

Post Installation

After the user configuration is complete; perform a disk cleanup, defrag the hard drive, and then snapshot the virtual machine ready for deployment.

Conclusion

This guide will help you to minimise the footprint of your VM in a VDI environment, which will help to maximise what you can get out of your VDI environment in terms of scale. Typically these hints will save about 30% from the RAM footprint of each VM, and also cut down on amount of disk space used (not such an issue with linked clones) and CPU cycles required to run the base OS before applications are started.

Now you have your VM ready to be used. You then need to turn your attention to the applications to be run, and maintaining user data away from the desktop where settings and application data can be persisted even if a desktop is re-provisioned.

This, however, is a topic for another time.