logo
1x1 1x1 1x1 1x1 1x1 1x1
1x1
 

VMware View sizing & best practices

November 4th we published an article on Virtual Infrastructure best practices and the response was overwhelming. During the last month we received a lot of questions regarding best practices on VDI/VMware View. When I then read a comment from VMware’s evangelist, Richard Garsthagen, that the attention on blogs for VMware View was minimal I thought well let’s extend our View articles/knowledge base.

So, VMware View best practices. First of all check the article on Virtual Infrastructure best practices to create a good understanding for the underlying virtual infrastructure challenges.

So hereby my list of best practices which I gather from VMware KB articles, instructor led VMware View design training and the VMware community:

  • CPU sizing;
  • Memory sizing;
  • Storage sizing;
  • Network sizing.

If you have additions or new insights please reply.

CPU Sizing
Depending on your application workload you can deploy 6 to 9 virtual desktops per CPU core. On a dual quad core ESX host this means we can deploy 48 to 72 virtual desktops. With VMware vSphere, the more efficient hyper-threading and the new CPU’s with MMU/RVI/EPT/etc like the Intel Nehalem CPU’s, we can, on average, deploy 50% more virtual desktops. This means that depending on the workload you can deploy between 72 and 108 virtual desktops. I always like to keep the sizing figures safe and go with the 72 virtual desktops per dual quad core ESX host.

Memory sizing
Again, depending on your application workload a Windows XP virtual desktop needs 700MB to 1GB of RAM. For a Windows 7 desktop we can easily double those figures. With VMware ESX’s Transparent Page Sharing (TPS) this means that roughly 60% of the memory for a Windows XP desktop is actually used and 40% is shared. With Windows 7 this number drops to 20% because of encrypting it’s memory which results in 80% memory usage. Besides that a ESX hosts needs 4GB of memory for it’s own needs.

With the virtual desktops we calculated with the CPU sizing this results in 48GB memory for 72 Windows XP virtual desktops with 1GB memory. For 72 Windows 7 desktops with 2GB this boils down to 116GB host memory.

Storage sizing
The sizing of your storage needs for VMware View is all about performance and has nothing to do with storage capacity. Storage is calculated by the amount of I/O operations per second (IOPS) needed. Per virtual desktop you need 5 to 20 IOPS depending on your application workload and operating system in a 20/80 read/write ratio.

Again, for the 72 virtual desktops calculated earlier, we need 360 IOPS for task workers running for instance Windows XP and 1440 IOPS for power users running Windows 7.

We have the amount of IOPS and the read/write ratio it is in, now it’s time to determine RAID level and LUN sizing. As I said earlier, storage sizing is all about performance and not storage capacity and with the high number of IOPS needed you will probably have plenty of storage capacity to store all virtual machines and data. I always pick the RAID level which gives you the best of both worlds, high performance with a nice margin to the values calculated and not too much overhead so there’s enough storage capacity left.

LUN sizing depends on the deployment method used, full virtual machines or linked clones. With full virtual machines you can place between 25 and 32 virtual desktops on a single LUN. With linked clones the maximum virtual desktops per LUN is 64.

The storage capacity needed with linked clones is a difficult item to size because it depends on many many factors like client anti-virus (updates), persistent or non-persistent desktops, application distribution method, etc. Numbers we see in real life scenarios with our customers is that when they use non-persistent desktop which are deleted after use, application deployment is done using application virtualization and all software in the template is up-to-date, so no updates or patches, the deltas are between 10 and 25% of the base image.

Assuming a disk image of 10GB for a Windows XP virtual desktop and 20GB for a Windows 7 one and the above scenario with a User Data Disk (UDD), which keeps user data out of the virtual machine storage space, you would need:

  • 3 LUNs of 300GB for 72 Windows XP full virtual desktops with 20% free space;
  • 2 LUNs of 108-240GB for 72 Windows XP linked virtual desktop with 20% free space;
  • 3 LUNs of 600GB for 72 Windows 7 full virtual desktops with 20% free space;
  • 2 LUNs of 220-470GB for 72 Windows 7 linked virtual desktops with 20% free space.

And now an area I’m not so familiar with, you can use linked clones to reduce the amount of storage capacity needed but there are SANs which have this feature build in, data deduplication.

So my question to you storage experts out there: ‘Is linked clones a ‘poor man’s’ data deduplication?’ and are they interchangeable or does VMware View linked clones offer us more?‘.

My limited view now says, let VMware do what it is best in and let the storage vendors do what they’re best in. So VMware View creates full virtual machines and the storage deduplicates the data. That’s the road VMware chose with their new storage API’s and that the future in my opinion. Your opinion, please!

Network sizing
Network sizing has always been a bit more difficult and now with VMware View 4 with PCoIP it has not become any easier. During sizing in a View 3 environment I always used the following rule of thumb, 50kbps for a task worker, 100 kbps for a knowledge worker and 150kbps for a power user. This number probably still stands for VMware View 4 using RDP but with PCoIP these numbers are quite different. From what I’ve heard from VMware engineers, PCoIP starts at 128kbps per session and goes up real fast when using all nice graphical features like flash, HD video, etc. With the use of PCoIP the latency may not exceed 250ms.

So with RDP, we would need between 3.6 and  10,8Mbps, with PCoIP it start with a minimum of 9.2Mbps and the maximum is dictated by the line capacity. In my opinion there will be very few 100% PCoIP implementations. PCoIP will be used for the power users which need the graphical muscle. The rest can perfectly manage and have great performance with an RDP connection.

For this networking capacity 2 gigabit network interfaces would be sufficient for both the RDP and the limited PCoIP scenario. With a total capacity of 2Gbps each of the 72 virtual desktops has 27Mbps to fill up.

View 4 building blocks
In essence we now have VMware View 4 building block for Windows XP and Windows 7 virtual desktops.

(* value mentioned for linked clone scenarios are based on minimal deltas 10% and maximum 25%.)

 

About

Erik Scholten is the founder of VMGuru.nl and works for Imtech ICT as a Solution Architect creating the most ingenious virtual infrastructures. He has over 16 years experience as a system engineer and consultant and now he specializes in virtualization. His current job includes selling, presenting, designing and developing virtual infrastructures for some major companies in the Netherlands. Erik is a certified VMware VCP (3, 4, 5), VCP Desktop (5), VSP (3, 4, 5) and VTSP (3, 4, 5). In 2009, 2010, 2011, 2012, 2013 and 2014 VMware awarded him the vExpert award for his virtualization community efforts.

  • Pingback: Tweets die vermelden VMware View sizing & best practices | VMGuru.nl - I choose (a virtual) life! -- Topsy.com

  • Sudharsan

    HI ,

    Good Article. Thanks for the post . Can you please post something similar to this for VCB ? We are facing lot of issues in time taken to complete backup and other associated issues that arises with the same . looking forward to it !!

  • Sudharsan

    HI ,

    Good Article. Thanks for the post . Can you please post something similar to this for VCB ? We are facing lot of issues in time taken to complete backup and other associated issues that arises with the same . looking forward to it !!

  • http://myvirtualcloud.net/ Ande Leibovici

    Nice post, but for storage calculations the numbers you are working with are only valid for FC SAN deployments. Most of the new deployments I see today are being done with IP storage arrays using NFS protocol.

    As an example, Number of VMs per VMFS datastore: This information is critical for sizing scalable VMware View solutions on VMFS datastores. For NFS, there are no VMware recommendations on the maximum number of VMs per datastore.

    Besides that, nice work!

    http://myvirtualcloud.net
    Andre

  • http://myvirtualcloud.net Ande Leibovici

    Nice post, but for storage calculations the numbers you are working with are only valid for FC SAN deployments. Most of the new deployments I see today are being done with IP storage arrays using NFS protocol.

    As an example, Number of VMs per VMFS datastore: This information is critical for sizing scalable VMware View solutions on VMFS datastores. For NFS, there are no VMware recommendations on the maximum number of VMs per datastore.

    Besides that, nice work!

    http://myvirtualcloud.net
    Andre

  • Pingback: That’s my View - Enterprise desktop virtualization at a glance » Blog Archive » VMware View sizing & best practises

  • http://www.yellow-bricks.com/ Duncan

    Sorry for the delayed response but I am on a holiday :-). ESX tries to keep 6% of memory free for it’s own processes. So the amount of memory needed for ESX VMkernel is variable. Will start with roughly 50MB I believe.

  • http://www.yellow-bricks.com Duncan

    Sorry for the delayed response but I am on a holiday :-). ESX tries to keep 6% of memory free for it’s own processes. So the amount of memory needed for ESX VMkernel is variable. Will start with roughly 50MB I believe.

  • http://www.yellow-bricks.com/ Duncan

    good article by the way!

  • http://www.yellow-bricks.com Duncan

    good article by the way!

  • http://www.vmguru.nl Anne Jan Elsinga

    @Andre I agree that these figures are not for NFS, but they do go for iSCSI SANs that don’t use NFS. There are a lot more considerations for storage of virtual desktops.

    If you use linked clones you also need to take into consideration:
    - Are you using a virusscanner in your VMs? How is it updating itself?
    - Are you using a User Data Disk that stores your profile during usage?
    - Do you allow users to install software?
    - How is your software distribution handled?
    - Is Windows updating itself?
    - How often do you do a refresh or recompose?

    All these things make it somewhat hard to correctly size for linked clones. Best practice is to observe the growth of the delta files during the testing or Proof of Concept period.

  • http://www.vmguru.nl Anne Jan Elsinga

    @Andre I agree that these figures are not for NFS, but they do go for iSCSI SANs that don’t use NFS. There are a lot more considerations for storage of virtual desktops.

    If you use linked clones you also need to take into consideration:
    - Are you using a virusscanner in your VMs? How is it updating itself?
    - Are you using a User Data Disk that stores your profile during usage?
    - Do you allow users to install software?
    - How is your software distribution handled?
    - Is Windows updating itself?
    - How often do you do a refresh or recompose?

    All these things make it somewhat hard to correctly size for linked clones. Best practice is to observe the growth of the delta files during the testing or Proof of Concept period.

  • Pingback: Musings on VDI performance » TechAgility

  • Pingback: my-virt » VMware View sizing & best practises

  • Nadine

    Hello,
    Please I am running with the VMWare 7 on Vista and would like to know how to get the application webs from my host windows.
    I installed E-Business Suite R12 on the virtual machine RHEL4 and would like to have access to the link from my Vista machine. I can ping the Virtual machine from Vista, but can't do the same from RHEL4.
    Regards,

  • Ed

    Regarding the comment about the SAN or VMware dealing with the deduplication of virtual machine disks: Dedupe within Storage Arrays is performance-limiting as all writes need to be compared to existing data (either at time of write or shortly afterwards). I would be amazed if storage-array-dedupe can come close to meeting the IOPS figures you discuss. The current mechanism where VMware View writes the changes to snapshot/difference disks makes a lot of sense and gives good performance with much lower storage costs. What we need now is a change to allow the 'master' copy of the base image for a VM to be kept on a different LUN, so that it can be kept on Solid State Disks – that would really give a great way to improve performance without too much cost.

    • Robert Holden

      Look at Fusio-io or similar PCIe based NAND storage.  I’m no expert, but if you have your VMs on a hunk of NAND and let the users store whatever data they have on spinning rust shares, you’ll definitely be smashing the IOPS bottleneck.  That doesn’t cover dedupe, but it would help the workstations.

  • Achim

    Thanks for this great article!

    First of all an important disclaimer: I do not consider myself an IT expert! Still, I developed most parts of the new IT-strategy for our family business (plastics wholesale, 70 employees, 35 users). For about 6 months we've been testing 10 View4 clients on our vSphere hosts.

    We found out that our average task worker needs 275 kbits using Dynamics AX 2009 (Axapta) ove the WAN. Switching back and forth to Outlook we saw peaks at around 850-900 kbits!

    The values given are for PCoIP and shouldn't come as a big surprise. Teradici as well as WAN optimization vendors claim that a peak bandwith of 1 Mbits should be taken into account for any given PCoIP session.

    What might be possible to accomodate on land lines just won't work over mobile networks. Therefore we are currently investigating if our 7 road warriors will get Dynamics AX delivered using ICA. XenApp or XenDesktop, that is the question! :-)

    Is there any chance we can expect a better performance from View 4.5? Maybe using some kind of improved bitmap caching?

  • http://www.vmguru.nl Erik Scholten

    I'm participating in the beta but art of the beta agreement is that I can't disclose any info, sorry. Check back here as soon as it is released and we can tell you more about it.

  • Pingback: VMware View sizing & best practices | Virtual Clouds

  • bahare gh

    hello all i want to implement vitualization in the oganization that have 50 clint and 48 client connect to server
    in same time,and ,please let me know hardware requirment for m server which has 50 virtual desktop and all 50 thin client remote to it, all thinclient loads are on the server all thin client use windows xp,and sever platform is windows server 2008 r2,
    all user use office2007,powerpoint acrobat reader,and team viewer,oganization officially software.i think that i shoul use 2X quad core CPU with out mmu for 48 to 72 client,48 GBram,am i right?
    please let me know the size of RAM,CPU,HDD I should use?
    please help me
    thanks

  • Max

    Great work! Is there an updated version of this for View 5.x?

    • http://www.vmguru.nl Erik Scholten

      we’re working on a updated version for View 5.1 or newer.