Day two of the VMware View Bootcamp focused on storage considerations for the View environment. Jim Yanick talked about a number of different things about how your decisions impact the storage requirements for the Viewinfrastructure. My key takeaways from the video are as follows: View Composer is a key feature of View 4.5/4.6; it allows for linked clones. Linked clones are all deltas of a base (read only) master image; they deploy rapidly since only a delta of the parent image needs created. 75% average storage savings based on VMware customer data versus deploying full clones. View Premier Bundle includes Composer, ThinApp (application virtualization), and Local Mode (makes full clones portable by making it possible to download them to the local host from the View environment). View vSphere limitations: 8 vSphere Host cluster limit per View Manager Pool with Composer
- vSphere host limit as 8 as that is the maximum number of hosts that can access a given read only file.
- 320 VM HA maximum (vCenter 4.1); the limit on the number of VM’s that vCenter can power on in the event of a host failure.
- The amount of time required to place a vSphere host in maintenance mode; will vary based on number and capabilities of hosts present in the cluster, number of VMs, and the storage infrastructure.
- The ability of the vSphere cluster to absorb the impact of AV updates or scheduled scans.
View 4.5/4.6 supports Quickprep (VMware View feature) or Sysprep (Microsoft tool). Both use a dedicated domain account that you specify in View Manager
- Quickprep- All VM’s will share the same machine SID. FYI, based on my own personal experience I would test quickprepped VM’s with IIS applications that use integrated authentication, which includes Exchange 2010 – Outlook 2007/2010 communications. Watch for problems where you are forced to re authenticate over and over again. Read the discussion here (not just the post) for more details.
- Sysprep – The VM SID will be lost on recompose or rebalance BUT maintained on refresh. Compared to Quickprep system slows VM deployment and requires multiple reboots.
Tiered storage support: The ability to direct replica disks, OS disks, and persistent disks to different storage. For the purpose of optimization redirect the disposable disk to alternate storage locations:
- Disposable disk contains paging and system temp files (this is to save space on the VM delta files, not specifically for performance)
The persistent disk can be managed using the View web console; one example would be when you need to move a user to a new VM due to job change or some other event. Place the master VM image on SSD for read IOPS to support the IO of many linked clones (simultaneous boots, etc) Important documents:
Involve storage architect in View planning; key for ensuring that storage IO needs are met as IO is usually the issue, not capacity. Some best practices for the parent VM:
- Use LSI disk drive for XP; SAS forWindows 7
- Turn off drive indexing
- Defrag the drive – both the image and the VMDK
- Clean out all system temp files
- No P2V; build from scratch
- Keep the image as clean as is possible
- Disable any unneeded services
- Parent VM goes on best storage available, is backed up, protected, etc
View can distribute linked clones evenly across pools (on the fly (round robin) or via rebalance)
- Keep datastores roughly same size to ensure round robin distribution works as intended
- Storage over-commitment levels (how many linked clones to place on a given datastore): None, conservative (x4), moderate (x7), aggressive (x15)
- To assess VM IO needs Lakeside Software / Liquidware Labs products
Dedicated pools require that persona information be stored and protected (use roaming profiles, folder redirection, third party tools). Storage growth management tip: The more you refresh the linked clones, the less they will grow. Things to consider during the design on the View infrastructure:
- How large is the parent disk image?
- How many different images to I need? May need few depending on if apps are installed locally or delivered via ThinApp.
- How many unique linked clone VMs are required?
- Persistent disks or persona management for dedicated pools?
- What are the average and peak IOPS of my desktops? (Note: can be sampled with a test VDI desktop on a dedicated LUN and reports from the storage administrator)?
- What kind of tasks to my users perform?
- What are the most IO intensive applications?
- Are any unauthorized applications in use?
- A proper assessment of the environment will answer these questions
Some important stats: IOPS ratings for disk drives
- 7200RPM SATA: ~80 IOPS
- 10K RPM SAS: ~140 IOPS
- 15K RPM SAS: ~180 IOPS
- SLC SSD: ~400 IOPS
- Enterprise Flash (EMC given in the example): ~2500 IOPS
Remember that the IOPS capability for a raid depends on the configuration; you can’t just add up the numbers. Duncan Epping did a good writeup to help explain how to calculate the IOPS limit of a raid group. Baseline desktop IOPS needs (your results may vary):
- Lite user: ~ 6 to 8 IOPS
- Medium user: ~ 8 to 20 IOPS
- Heavy user: ~10 to 30 IOPS
Recommended limits for VM’s per ESX 4.0 datastore (again, your results may vary):
- Max VM’s per VMFS datastore: ~90; 60 is “safer”
- Max VM’s per NFS datastore: ~170; 150 is “safer”
AntiVirus – Scheduled scans and updates can cause severe IO and CPU spikes. Must either plan for this or find alternative solutions. vShield Endpoint as an alternative to traditional AV clients
- Attached to hypervisor, no client agents
- More manageable and secure than agents within the VM’s
- No more resource storms due to client AV activity
- Trend Micro only vendor offering the plugin at time of training
That concludes the lessons for day two. If you have additional interest in the topic I recommend participating in the accompanying discussion for the day two video or if you like replying to this post. Up next for day 3 is networking!