Join virtualization expert and industry veteran Ron Oglesby as he breaks down how to select and configure servers, including: • Server CPU selection - they were not made equal! • Desktop-to-core guesstimation? • Memory - and its temperamental relationship with disk design • Local storage options - yes, it's an option • And, overall best practices for VDI implementation

1. Get your GeekOn w/ Ron
Designing your VDI Servers
Not a Unidesk demo, commercial or infomercial. Just pure geekiness.

2. Agenda
 Defining the VMs before designing the servers
 Memory Considerations
 CPU: Processor type? Cores over speed?
 Video impact?
 Storage Considerations
 Converged systems?
 Final thoughts

3. Define/Design your VMs first
 Number of vCPUs
 This leads to a discussion about vCPU count and multi-media
in Win7, which leads to a discussion about video offload
 Memory assigned to the VM
 Has an impact on disk design
 Disk space (define the use case first)
 Networking requirements (DHCP, reservations, Static)
 OS and application requirements

4. CPUs

5. CPUs where to start?
 VDI can tax a system CPU differently than you expect
 The goal is always to increase density in your VDI
server but don’t trust ‘Vendor numbers’
 The choice/tradeoff
 Optimal config (performance wise) is a low ratio of Virtual
Desktops to cores in the server
 Optimal config (cost wise) is a high ration of Virtual Desktops
to cores in the server…
 1- Don’t go “cheap” on the processor
 2- Trade Cores for Speed

6. Video’s CPU Impact – its 2 different things
 PCoIP Offload cards
 Offloads PCoIP functions from the CPU to this cards
 Density numbers they quote may only be seen when LOTS of
desktops are using the CPU for PCoIP functions
 http://www.vmware.com/files/pdf/VMware-View-Using-
PCoIP-HostCards-TN-EN.pdf
 NVIDIA VGX GPU cards
 NVIDIA Quadro GPU
 http://blogs.vmware.com/euc/2012/05/blog-post-from-gtc-
hosted-desktop-and-workstation-workloads-what-about-my-
3d-graphics.html

7. Common CPU “issues” seen in the field
 Over taxing the servers (number of vCPUs to Cores)
 The higher the ratio of vCPUs to physical cores the more
time VMs have to ‘wait’ to be scheduled on a processor core
 Often indicated by a high % Ready time
 In some servers there is a “speed step” issue
 Speed step or power settings configured in the BIOS is not
allowing full CPU utilization at lower server CPU utilization
 Has been seen in Cisco, HP and Dell servers
 Often correctable
 How do I know if this is happening to me?

8. Memory

9. Memory
 Define your memory assignments NOW before you
ever pick your server
 Often the scale tests you see from vendors are not optimal
configurations for memory
 This setting impacts way more than just the VM
 Memory overcommit tools only allow so much over
commit
 Think about 100 VMs at 4GB each…..
 Memory also impacts your storage… HUGELY

10. Memory and Storage
 VMware creates a vSWAP file equivalent to the
machines assigned RAM… it does this at each boot
 A Windows page file MUST be present for Windows to
operate properly
 On a 4gb of memory machine this can equate to 6+
GB of space eaten up
 4GB of vswp + 2GB of page file + other data
 Imagine that for 1000 desktops… 6+TB of space eaten
 Or think about it with a 100% pagefile… 8+ TB

11. Moving to Host Based vSwap?
 Host based vswp moves away from individual vswp
files stored per VM
 Requires that you have local storage for this swap
space can also run swap to host cache!
 http://www.vmware.com/files/pdf/mem_mgmt_perf_vsphere5.pdf
 http://pubs.vmware.com/vsphere-4-esx-
vcenter/index.jsp?topic=/com.vmware.vsphere.resourcemanagement.doc_41/mana
ging_memory_resources/t_enable_host-local_swap_standalone.html
 http://pubs.vmware.com/vsphere-
50/topic/com.vmware.vsphere.resmgmt.doc_50/GUID-FE1108F3-C4CF-41F3-AEE9-
CDB5B44A444F.html
 http://www.yellow-bricks.com/2011/08/18/swap-to-host-cache-aka-swap-to-ssd/

12. Disk

13. Disk Footprint
 First you have to decide what the local disk will be
used for:
 Just ESXi installed?
 Local host based swap replacing vswap per VM?
 Local copies of VM replicas or Unidesk Layers?
 Define the footprint required for each
 Hot data (shared layers, VM Gold images, etc)
 Colder data (vswap, windows page files, Unidesk boot
images, etc)
 This footprint requirement will feed into disk selection

14. Disk IO… the common problem.
 Footprint can be reduced via numerous
technologies
 IO… not so much
 Server IO loads? What is/was typical
 Desktop IO load
 What is all this RAID penalty stuff?

15. Design for the IO, there are options
 Big storage vendors push the big system with their
“Cache” tech
 Fast Cache
 Flash Cache
 Regardless of disk TYPE the key is handling IO and the
storage footprint at the same time
 Centralized storage looked for mixed / hybrid arrays with SSD
and rotating disks – make sure they use some SSD for writes
 Local storage can also be leveraged to keep cost down
 Everything is available from rotating disk to FusionIO cards

16. Local storage options for IO
 SSD can have its draw backs
 Failure rates on consumer level SSD can be an issue for VDI
 Standard MLC on a hot server… I’d give it a year or 18 months
 eMLC should be 4 or 5 years
 SLC 6-8 years? But at generally more than 2 or 3x MLC/eMLC
 Or… lots of rotating: 6 drives * 200 IOps can I get 8?
 50 desktops at 10 IO each with 1:1 read:write = 1250 IO
 1 FusionIO card + 2-4 rotating disk for swap & transient data?
 http://www.brianmadden.com/blogs/rubenspruijt/archive/2012/06/10/spinning-out-
of-control-using-flash-storage-in-enterprise-environments.aspx

17. So what about these “converged”
systems with
servers, storage, everything?

18. Converged systems play
 The idea is to combine your compute (server) and
storage resources together into scalable appliances
 Very cool model, focus on $/desktop and perfromance
 Nutanix.com
 Very cool, redundant storage, 4 server block model
 V3 Systems v3sys.com
 Redundancy through automation

19. Designing your VDI environment and
avoiding common mistakes

20. Common Mistakes in VDI
 Designing the hardware first
 To many variables to choose hardware out of the gate;
 Just duplicating Server Virt hardware
 Believing everything the vendors say…
 Buying software because the “vendor said” it would do what
I needed
 The vendor said I could get 120 Desktops on this system
 Not configuring the Disk subsystem properly
 Forgetting about “personalization” of the desktop

21. Hardware Recommendations
 Smaller servers w/ more cores
 Going to 4 socket boxes from 2 socket is not a simple 2x
change in price
 More memory
 Good storage controllers
 Local disk, SSD, centralized disk, centralized SSD
 Build redundancy through quantity
 Think back to the old “MetaFrame Days”

22. Key “Check Boxes” for your design
 Define what you are delivering and to who
 Ensure your design covers the following:
 Base OS delivery and updating
 Application delivery and updating
 Personalization or profile mgmt
 Broker configuration and requirements
 Pool Vs Persistent desktop decisions
 Storage configuration (foot print and IO load)
 WAN and LAN use cases

23. Q&A
Open Discussion
Ron Oglesby
www.unidesk.com
Twitter: @ronoglesby