Normal 0 false false false EN-US X-NONE X-NONE MicrosoftInternetExplorer4 /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0in 5.4pt 0in 5.4pt; mso-para-margin-top:0in; mso-para-margin-right:0in; mso-para-margin-bottom:10.0pt; mso-para-margin-left:0in; line-height:115%; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;}

Physical PCs usually offer an abundance of resources: Plenty of disk, RAM, CPU horsepower, and network connectivity speed—all dedicated to the user logged on at the keyboard. This fact of life of IT reminds me of a well known rule in physics—a gas in a vacuum will expand to fill its container.  Which is a way of saying that given an abundance of horsepower and available resources at the desktop, operating systems and applications are permitted (nay—encouraged!)  to expand and consume available resources.

When making the transition to VDI, you need to consider the fact that you’re moving the compute resources from the desktop to the datacenter, and in the process you’re moving from a dedicated resource model to a shared resource model. The benefits of this shift are improved management capabilities and lower OPEX, the trade-off is that you must design for a shared resource model. This means you must resize the desktop environment down to take into account this shared nature.

Most PC manufacturers  find that memory is a very profitable component, and find it cost-prohibitive to install less than 1GB of RAM, and probably prefer to include 2GB these days because it entices companies to upgrade to 4GB. Therefore there is very little actual sizing and baselining that goes into the physical desktop memory provisioning decision. It would probably cost more to buy a PC with 512MB of RAM versus 1GB of RAM today.

In VDI, specifically VMware View, the decision to go with a smaller memory footprint has more to do with disk space allocation than memory usage. If the WinXP VMs have excess memory, then ESX Transparent Page Sharing (TPS) takes care of physical memory consumption. But each VM has a VM swap file that is created at a size equal to the memory provisioned; therefore if you don’t need 1GB of RAM for a View VM, you’re wasting 512MB of disk space. The VM swap file by default is stored with the VM configuration file, which is usually kept on the SAN. You can move the VM swap file to the local datastore of the ESX server, which is likely the most cost-effective solution. Bottom line: If you over provision RAM in VMware View, you’re also over-provisioning disk.

Windows swapping occurs 100% of time, except when an administrator explicitly configures no page file. That’s because Windows considers physical RAM the most critical component related to performance. If a memory page isn’t being actively used or is flagged as non-paged, then Windows swaps it to disk to free up as much RAM as possible. Some read-only DLLs are set as non-paged, so even if a DLL is read-only, it might still remain in memory. This is when TPS can optimize it.   

So the Windows paging consideration comes back to disk…specifically now storage performance. If the SAN is being overwhelmed with IOPS demand, then increasing the size of the memory assigned to the VMs may reduce some swapping, which in turn could reduce storage IOPS. To help constrain the paging, we recommend sizing the Windows page file to 50% of provisioned memory. You then have to monitor the VM to see if application memory demand is causing the OS to run out of virtual memory. In Windows, virtual memory is defined as the sum total of memory available, which is physical RAM plus page file size, i.e., a VM with 512MB and a 256MB page file has 768MB of virtual memory.   

Finally, after right sizing the amount of RAM provisioned and the size of the Windows page file, you should turn your attention to the agents, services, and “helper” applications installed and running on your Windows desktop. In a full-featured PC with plenty of spare capacity that cannot be leveraged by other users simultaneously, it probably makes sense to run all these extra processes, and possibly isn’t even noticeable to end-users. In VDI, running these optional components unnecessarily will rob you of VM density or worse—negatively impact the total user experience—and that is just too high a price to pay.

At this stage, each component that is a part of your Windows desktop image should be examined and justified. I can’t tell you which components should or shouldn’t make the cut. For example, many organizations can do without a filesystem or Inbox indexing service, but some may find this a critical requirement. VMware develops and publishes OS slimming guidelines periodically, and this is a good place to start for advice on how to evolve your desktop for VDI. You can also simple search on the phrase “Windows XP (or Vista, or 7) slimming” in your favorite search engine.    

So, to sum up:

·         A VDI design should dictate that the VM memory provisioned should be as small as possible, to conserve disk space

·         The amount of VM memory required and page file size should be determined by a baseline (Liquidware Labs Stratusphere is a perfect tool for completing this task)

·         Windows paging is a fact of life; the VM baseline should determine the tipping point between IOPS and minimum necessary virtual memory to ensure adequate performance for applications

·         Sizing considerations between physical and virtual workloads are done very differently, because there are different economies of scale and cost/benefit ratios

·         Don’t use a Windows build intended for a resource-plentiful, dedicated PC. Instead, use a Windows build that reflects a frugal attitude towards adding software that consumes resources, and add only components that generate value to the end-user or user experience.