Everyone associated with virtualization is obsessed with storage! Well, it may be hyperbole to some but it cannot be ignored as one of the key challenges in desktop virtualization.

But why so much talk about storage? After all, the concept of storage has been there for ages. Yes it existed before digital storage, in the form of physical files. Later on the concept caught-up for digital storage when the PCs invaded the households. This is precisely the reason for the noise and confusion! Everyone assumes they understand storage. After all, how complicated can it be when every computer user has knowledge of storing digital data on HDD/DVD/CD/USB/external drives etc? However, the fact remains that storage is least understood and taken for granted by many, even though it is complicated, especially for desktop virtualization which requires a specific expertise to configure it.

The reality in virtualization is further complex for storage. Things were simpler until Direct Attached Storage (DAS). However, since the introduction of NAS and SAN in the virtualization environment it has become more complex. We are faced with issues including RPM, RAID, IOPS, file vs. block, thick vs. thin provisioning etc. which are all relevant for desktop virtualization.

The key drivers for desktop virtualization are reducing the capex/opex and increasing the agility of the business environment. The TCO gets impacted heavily if the storage is not configured correctly for desktop virtualization, specifically for NAS/SAN. There are numerous challenges to overcome for optimizing the storage in the desktop virtualization environment. For example, sizing, cost, performance and skilled storage resources are a few key ones. Few desktop administrators have been trained on NAS/SAN storage configuration. The skilled storage resources are more focused on storage provisioning for server virtualization mainly to optimize the database, ERP or exchange applications. Storage is one of the highest item impacting TCO for infrastructure, and even more so in desktop virtualization. Optimally configured storage can significantly increase the number of virtualized desktops supported. Storage and virtualization vendors working together should provide guidelines including best practices and configuration / sizing guides etc. so that the end users reap all the benefits and feel more confident to embrace desktop virtualization.

Citrix has invested considerably in the Citrix Ready program and is working with key storage vendors to address these market needs. Storage partners can make use of the Citrix Ready program to certify their products and validate their offerings with Citrix products. Citrix has introduced StorageLink for better management and seamless configuration of storage. StorageLink also provides site recovery automation capabilities. Citrix’s introduction of Intellicache will also help in reducing TCO.

To conclude, I am hoping that even though the storage and virtualization vendors have been showing greater cooperation day-by-day, there is still an immediate need for storage vendors to focus their attention to address the market needs of desktop virtualization, which has its own specific storage issues to deal with.

The views expressed here are mine alone and have not been authorized by, and do not necessarily reflect the views of, Citrix.

With XenDesktop 5 Express, you can create a virtual desktop (VDI) production environment for up to 10 users or an evaluation environment as a POC …for free! The XenDesktop Express download includes everything you need plus a tutorial video that walks you through the installation process. (You could also use XenDesktop with Microsoft Hyper-V or VMware vSphere as the virtualization layer, but we recommend the included XenServer 5.6).

Then when you’re comfortable with your XenDesktop environment on a LAN, you can try it out on a WAN for free with Citrix Access Gateway VPX 5.0.1 Express.

Here’s what you need… 

Product Download

Download XenDesktop 5 Express edition from: http://www.citrix.com/tryxendesktop

This download (filename: XD5_Express.zip) includes:

• XenDesktop5.iso - XenDesktop Controller & Virtual Desktop Agent
• XenServer 5.6.0-install-cd.iso - XenServer 5.6 virtualization infrastructure
• XenCenter.ja.msi - Install for XenCenter Japanese language version
• XenDesktop_Express_Edition_License.lic - 10 user XenDesktop license
• XenDesktop5_Express_Edition_Tutorial.wmv - Step-by-step guidance for a XenDesktop setup
  
  
  
  

Licenses

Included in the XenDesktop Express download zip:
(Note: Product offers a 30 day grace period until license is applied.)

• XenDesktop 5 Express License file - Covers Controller, Virtual Desktops, and XenServer
• XenServer License - License using XenDesktop Controller’s licensing feature (refer to tutorial video)
  
  
  
  

Sample Configuration

One or more servers capable of supporting the following:

• Windows 2008 or Windows 2008 R2 servers

      -- Desktop controller, 2 GB quad core
      -- Optional server for other pieces (IIS SQL, Web Interface*, Active Directory, etc.)

      *Note: Web Interface could be included on the Desktop Controller instead.

• Windows 7 virtual desktops (VDAs), at least 1GB and 1 core each VM
  
  
  
  

Documentation

• XenDesktop Evaluation Guide - Get step-by-step guidance throughout the installation process.
• XenDesktop 5 Eval Scenarios - Review once you complete the installation.
• Key differences in XenDesktop 5 - Find out what’s new in XenDesktop 5.
• XenDesktop Experience Newsletter - Get technical best practices & other info. Subscribe here

More documentation can be found here.

General Info

• XenDesktop Product Page
• HDX Product Page
• XenDesktop Case Studies 
• Citrix Blogs: XenDesktop
  
  
  
  

Phase 2: Access Gateway

Once you’re comfortable with your XenDesktop environment on a LAN, it’s time to try it out on a WAN …for free. Citrix Access Gateway VPX is a virtual machine based solution for remote access to your XenDesktop environment. Access Gateway VPX configured in “Express mode,” will allow a max of 5 users for 1 year. Here are links to the resources:

• Download Access Gateway VPX 5.0.1 Express and the license file (via MyCitrix)
• Review a guide for integrating Access Gateway VPX with XenDesktop
• View Access Gateway VPX Hardware Requirements
• Configure Access Gateway 5.0 for Citrix Receiver for mobile devices
  
  
  
  

Hope you find this information helpful. If you’ve tried this yourself or there are other resources that you’ve found useful, please share!

Laura Whalen
Citrix Systems, Inc.
Follow me on Twitter

You may have seen the recent announcement of the availability of XenClient 1.0 SP1.  There was a line item in that post regarding the autoboot feature that deserves a bit more explanation.  The autoboot feature was developed in response to customer requests to address these key XenClient use case challenges:

• There are XenClient UI’s (XenClient splash screen and Citrix Receiver for XenClient) that are new to the lay person and might cause end user confusion or create training requirements; In response, we have provided the ability to hide those UI’s from the end user
• Eliminate the double login – i.e. eliminate the need for a user to log into XenClient and then again into the Windows VM; In response, now the user bypasses the XenClient login screen; Note: When using XenClient disk encryption, you need to authenticate into XenClient on device boot
• Eliminate the challenges associated with a XenClient device being bound to the user that first logs into a XenClient device; Normally if an admin provides the initial login, that same admin login would be required once the device is in the hands of the end user; In response, auto boot lets the user bypass the XenClient login screen
• Prevent users from making changes to VM settings for security reasons; In response, the Citrix Receiver for XenClient and its configuration settings are hidden from the end user 

Here are simple steps to enable the auto boot feature in XenClient to achieve the above benefits: 

1. The Admin will bind (‘Connect to Synchronizer’ option in the Citrix Receiver for XenClient) the XenClient device to a Synchronizer* with a  password only admin knows
2. From the Synchronizer, download the required virtual machine(s) to the XenClient device
3. Set the device to autoboot** via the Citrix Receiver for XenClient interface under the “General” tab
4. Provide the device to the user
5. When the user powers on the device, it goes straight to the virtual machine and skips the XenClient splash screen and XenClient authentication screen – it feels just like bare metal:

• • The user never has to provide the XenClient credentials, only the AD credentials for Windows (if connected to AD)
  • The user never interacts with the Citrix Receiver for XenClient environment
  • The user cannot change the wireless or other settings that are in the Citrix Receiver for XenClient environment
  • Auto boot can be applied to multiple VM’s on a single XenClient device – the user will be taken to the one with HDX enabled (if one exists)
  • Policies can be pushed down as normal from the Synchronizer  
    
    

*XenClient doesn’t have to be bound to a Synchronizer; The admin can set a local password from the Citrix Receiver for XenClient; Go to System -> Login and check the box to “Require password on XenClient startup” to prevent users from accessing Citrix Receiver for XenClient.

**This behavior is new in XenClient 1.0 SP1.  Systems that are upgraded from 1.0 to 1.0 SP1 will still be prompted to authenticate if they have downloaded a VM from Synchronizer. New installs of XenClient 1.0 SP1 will boot directly to a VM if the VM is set to auto boot.

Give it a try and let us know how it works for you.

Lately, I have been getting questions around how to “size” a XenDesktop deployment. I have an AskTheArchitect webinar scheduled on How Scalability Impacts your XenDesktop Deployment that will help answer most of the common questions. However, with the recent release of the Hyper-V / Windows 7 / XenDesktop whitepaper I thought it would be a good time to go over just a few points on how you can leverage the scalability reports that have been released by Citrix and other vendors.

Citrix intentionally follows the same process for scalability testing so that the results can be used for comparing hardware and hypervisor platforms. Since it is impractical to create tests that match each customer’s environment, a standard configuration is selected and the performance data published. The choice of the Login VSI medium user workload allows for a consistent, repeatable, and slightly random workload to be run across different configurations to determine performance. Also, by using a readily available third-party tool for the workload, customers can easily reproduce the test results with an unbiased workload.

Sizing a XenDesktop environment should neither be done blindly nor should it rely solely on published scalability results. If you want to size your environment correctly, you must conduct a pilot with actual desktop users and their applications. The pilot results can then be used in combination with published data to determine the expected number of desktops a given hardware platform can support in your environment. Most initial pilots should focus on two key areas: CPU and storage activity. These two areas have a significant impact on a desktop virtualization project and are historically the ones that are undersized in larger environments. Certainly other areas can be monitored such as RAM and network activity, but these areas are not as difficult to size as CPU and storage.

In most cases, scalability results published by any vendor will not meet the requirements of your environment making it impossible to size your farm using the reported numbers. For instance, the Login VSI medium workload which uses Microsoft Office, IE, and Adobe generates about 5 IOPS per user when running in the steady-state loop. What is also true is that in order to prevent any network latency from affecting the response times, IE is using cached web pages for viewing. If a user was actually browsing web pages, both the network and storage activity would increase as the pages are read and cached by the browser. Recent tests have shown that a heavy IE workload can generate as much as 20-30 IOPS per session. Therefore, testing with your anticipated workload is paramount to obtaining realistic sizing data.

With a bit of logic, you can integrate the results from published reports with your pilot results to anticipate how the proposed XenDesktop environment will perform. For instance, the published results from the Citrix whitepaper show a BL460C G6 blade with 64GB RAM is capable of hosting about 75 Windows 7 users on Hyper-V with the Login VSI medium workload. Suppose you run a pilot with a similar hardware configuration but with your user workload and at the end of the pilot determine the optimal number of users per server is 50. Taking both pieces of data into account you can derive that your pilot workload requires approximately 50% more server capacity than the Login VSI medium workload.

Knowing this relationship allows you to leverage the studies published with the Login VSI medium workload. To determine how your workload would perform using the environment in the study, whether it be a different hypervisor or hardware, just adjust the Login VSI sizing results reported by 50% for your environment. Similar conclusions can be drawn regarding CPU usage or storage I/O operations (IOPS) when comparing published reports to pilot results.

To learn more, come join my webinar on Wednesday September 22nd at 1pm Eastern time. In an effort to provide more relevant content to attendees, I have requested a change to our registration process. During the registration, you can provide a single question that you are expecting to have answered during the webinar. If you register far enough in advance and the question is relevant to my presentation, I will work the answer into the webinar.

If you found this information useful and would like to be notified of future blog posts, please follow me on Twitter @pwilson98 or visit my XenDesktop on Microsoft website.

Thank you to all those that attended the Essentials for using Windows PowerShell with XenApp and XenDesktop Tech Talk on August 24, 2010 – we had a fantastic turnout! For those of you that missed it, both the recording and presentation have been posted.

• Tech Talk Recording
• Tech Talk Presentation

Mike Bogobowicz and I co-presented this session where I led the XenDesktop PowerShell SDK side, and Mike let the XenApp PowerShell SDK side. This blog will focus on just the XenDesktop SDK questions that came from the session. Mike will have a separate blog post on the XenApp SDK questions.

XenDesktop SDK Q&A
Here’s the list of questions we received specific to the XenDesktop PowerShell SDK. In no particular order:

Q: Are you going to post the scripts you used in today’s session?
A: All the scripts we demonstrated are contained in the blog series that was posted prior to the session. You can find links to the blog series at the bottom of this article.

Q: What does “DDC” mean?
A: First, this is a great question!! If you are a XenApp admin that hasn’t touched XenDesktop, DDC is a brand new term. DDC stands for Desktop Delivery Controller. It is the component of XenDesktop 4 that brokers virtual desktops to end-users, much like how the XenApp Zone Data Collector (ZDC) brokers published applications to end-users.

Q: This looks a lot like the PowerShell SDK for XenServer, just different commands. Is it similiar?
A: Yes, I believe Engineering made the PowerShell SDKs for XenServer, XenDesktop, and XenApp similar in structure on purpose. In that way, once you learn one, learning the others will be much simpler.

Q: The 4th XenDesktop PowerShell script from the Tech Talk showed how to shut down a single virtual desktop session. How would you modify this script to interact with an entire Desktop Group or multiple users?
A: The key here is to play with the parameters of the Get-XdSession cmdlet. If you provide the -User parameter, you can get specific user sessions. If you provide the -Group parameter, you can get all sessions from a particular desktop group. If you don’t include either of these parameters, you’ll get back all sessions across the entire farm. To get started, I would encourage you to check out the full help details for this cmdlet.

Get-Help Get-XdSession -Full

Q: With the virtual desktop session shutdown script, is there a way to allow the user to prevent the shutdown?
A: I don’t believe so. Once you call the Stop-XdSession cmdlet to shut down the session, it’s going to perform an immediate shutdown of that virtual desktop. That’s why in the demo I mentioned sending a warning message to the user to give them a heads up of the shut down, perhaps 10 to 30 minutes prior for them to save their work.

Q: Do we need to provide some credential (i.e. username/password) in order to be able to run the PowerShell script from a remote domain machine?
A: You can execute all of the scripts I’m providing in the blog series from a remote domain machine. I did some additional research on this and it looks like your logged on account to that remote machine needs to be both a XenDesktop admin and have access to the XenDesktop database. This would make sense from a security perspective to not allow any domain user to manipulate your farm. So the security is performed with your logged on machine account. We don’t need to pass a XenDesktop credential to the XenDesktop cmdlets.

Q: Can you create a desktop group in a specific folder?
A: I checked the New-XdDesktopGroup cmdlet that is used for creating a new desktop group and I couldn’t find a parameter for specifying a folder as part of the desktop group creation process. It does appear, however, we can move a desktop group to a new folder immediately after it’s been created. You would use commands like below:

#************************************************************
#Move desktop group to a different folder
#************************************************************

#Add the XenDesktop snap-in to the current Powershell session
Add-PSSnapin "XdCommands"

#Set up variables for the script
$strDDCAddress = "10.10.10.56"
$strDesktopGroupName = "Windows XP"
$strTargetFolderName = "Folder1"

#Get the target XenDesktop folder
$xdfolder = Get-XdFolder -Name $strTargetFolderName -AdminAddress $strDDCAddress 

#Get a particular desktop group
$xdgroup = Get-XdDesktopGroup -Name $strDesktopGroupName -AdminAddress $strDDCAddress -HostingDetails

#Display the current folder assignment for the desktop group
echo $xdgroup.Folder 

#Change the folder assignment for the desktop group
$xdgroup.Folder = $xdfolder

#Apply the change to the DDC
Set-XdDesktopGroup $xdgroup

#Verify the update
echo $xdgroup.Folder

Q. Is it possible to enable the “User-driven desktop restart” setting for a desktop group as part of creating the desktop group with PowerShell?
A. Just as with the last question, I checked the New-XdDesktopGroup cmdlet for creating a new desktop group and couldn’t find a way to enable this setting as part of executing that command. However, you can enable this setting immediately after creating the new desktop group. You would use commands like below:

#*************************************************************************************
#Enable "User-driven desktop restart" setting for a desktop group
#*************************************************************************************

#Add the XenDesktop snap-in to the current Powershell session
Add-PSSnapin "XdCommands"

#Set up variables for the script
$strDDCAddress = "10.10.10.56"
$strDesktopGroupName = "Windows XP"

#Get a particular desktop group
$xdgroup = Get-XdDesktopGroup -Name $strDesktopGroupName -AdminAddress $strDDCAddress -HostingDetails

#Enable user-drive desktop restart
$xdgroup.AllowUserDesktopRestart = $true

#Apply the change to the DDC
Set-XdDesktopGroup $xdgroup

#Verify the update
echo $xdgroup.AllowUserDesktopRestart

Q: If you have multiple DDCs, do you have to specify each, or just the master DDC to run against?
A: In a multiple DDC environment, if you point your scripts to the “master” DDC you should be fine. My XenDesktop farm only has one DDC so I can’t verify this one, but I’m thinking you might be able to point the scripts to any of the DDCs in the farm. If someone has a larger farm out there that can verify for us, please post a note at the bottom. Essentially, check out the scripts from the blog series and look for the -AdminAddress parameter I’ve been using for several of the XenDesktop cmdlets. If you have multiple DDCs, experiment putting the different IP addresses for that parameter and see if the script runs fine against each DDC in the farm.

Q: How can you check for disconnected sessions? Can you tell how long they’ve been disconnected?
A: The code snippet below explains how to get all the disconnected sessions for the XenDesktop farm. It looks like the properties of the $xdsession object will tell you the start time of the session, but not when it was disconnected.

#*****************************************************************
#Checking for disconnected virtual desktop sessions
#*****************************************************************

#Add the XenDesktop snap-in to the current Powershell session
Add-PSSnapin "XdCommands"

#Set up variables for the script
$strDDCAddress = "10.10.10.56"

#Get all disconnected sessions for the XenDesktop farm
$xdsession = Get-XdSession -AdminAddress $strDDCAddress -SessionDetails | where { $_.State -eq "Disconnected" }

#Display the disconnected sessions
echo $xdsession

Q: Can you monitor what is happening on the virtual desktop through PowerShell?? Or interact with a specific session (SendKeys style)?
A: The XenDesktop SDK doesn’t provide much in way of getting the details inside the session. In the Tech Talk, I demo’d how you can send messages to the session. You can also get some attributes for the session such as the client name and client IP that launched it. This blog goes into some of that. You can probably run other types of PowerShell scripts from within the virtual desktop session to get some additional metrics or details. Plus, there’s Citrix EdgeSight as well to have an agent running on the virtual desktop to collect performance metrics and other details!

Q: When doing an automated desktop deployment using MDT or other image deployment tool, what is the best way to have the desktop imported into it’s appropriate Desktop Group as part of the post install task sequence? These desktops are not pre-staged in AD and would prefer not to have the SDK installed on each VM. Can it execute a script on a remote server to do the import?
A: The XenDesktop PowerShell scripts do not need to be executed on the virtual desktops nor the DDC for that matter. They can be executed from any domain machine that can reach the DDC. You can use this blog for a sample script on adding virtual desktops to a desktop group. As part of your MDT automation process, you are going to want to install the virtual desktop agent (VDA) software on the virtual desktops prior to adding them to the desktop group. You’ll also want these machines added to your domain prior as well.

Q: Is it possible to create an advanced presentation for those comfortable with PowerShell and SDKs?
A: This is something that we’ve been discussing for a bit. Now that we have laid out the groundwork for the XenDesktop 4 SDK Primer, we can now think about adding in some more complex scripts to build on top of that knowledge. If you are experienced with the XenDesktop SDK and have some suggestions for what you would like to see, please post a comment below. For the more complex stuff, it’s always good to have a goal in mind for something practical that is needed out in the field.

Q: Do you cover VMware as a hypervisor in your blogs?
A: I didn’t cover VMware specifically, but the scripts I provided in the Tech Talk and blogs should also work with a VMware ESX host. If you are using VMware ESX to host virtual desktops, you are still considered to be using a VM-based desktop group. In the blogs I created, they were focused on interacting with VM-based desktop groups with XenServer as the host. My understanding is that the syntax should be very close if not identical. If anyone has used the XenDesktop PowerShell SDK for a VMware host, feel free to provide a comment at the bottom regarding your experience. Were the commands pretty much the same? Did you find any differences with using the SDK compared to my scripts with a XenServer host?

Tech Talk Resources
As a reminder, we based the Tech Talk on the blog series we posted prior to the session. You can find all the sample scripts we demonstrated in the Tech Talk within these blogs.

XenDesktop 4 PowerShell SDK Primer blog series – by Ed York

• Getting Started
• Retrieving the XenDesktop farm properties
• Creating a new desktop group
• Enabling/disabling a desktop group
• Updating the idle pool settings of a desktop group
• Adding virtual desktops to a desktop group
• Adding AD users and groups to a desktop group
• Disconnecting and stopping virtual desktop sessions
• Restarting virtual desktops and series wrap-up

XenApp 6 PowerShell SDK blog series – by Mike Bogobowicz

• Getting a XenApp Farm Inventory
• Checking XenApp Application Setting Consistency
• Checking Server Availability

About the Presenters
Ed York – Senior Architect – Worldwide Technical Readiness
Ask-the-Architect Site: http://community.citrix.com/p/product-automation#home
Follow Ed on twitter: http://twitter.com/citrixedy

Mike Bogobowicz – Principal Consultant – Worldwide Consulting Solutions
Blog Site: http://community.citrix.com/blogs/citrite/michaelbog
Follow Mike on twitter: http://twitter.com/mcbogo

In another blog, I discussed Windows 7 services that you might wish to disable when going down the path of desktop virtualization. In this article, I’m now focusing on registry modification you will want to make to optimize Windows 7 for virtual desktops. I’ve broken it down into Recommended configurations, Standard Mode configurations (for Provisioning services), and Optional configurations.

As I learn more from upcoming Windows 7 implementations, I’ll be updating the following tables, so it might be worthwhile to stay updated with RSS or subscribe via Email. Now, for the good stuff…

Recommended Configurations

The following registry changes are recommended for all deployment scenarios and would almost always be desirable in a Windows 7 hosted VM-based VDI desktop implementation:

Note: The Optimizer column indicates whether this registry change is included in the XenConvert Optimizer tool that is installed with the Provisioning Services target device software.

Standard Mode Recommended Configurations

The next set of registry changes are recommended for images deployed using standard mode vDisk images with Citrix Provisioning services. Standard mode images are unique in that they are restored to the original state at each reboot, deleting any newly written or modified data. In this scenario, certain processes are no longer efficient. These configurations may also apply when deploying persistent images and in many cases should be implemented in addition to the changes recommended in the preceding section.

Optional Configurations

This last set of machine-based registry changes is optional regardless of whether the image is deployed as a persistent or standard image. In many cases, the following configurations should be implemented; however, these configurations should be analyzed for suitability to each unique environment.

Note: These are only recommendations. You should implement these at your own risk

Remember, you can stay current with this and other Windows 7 virtual desktop recommendations via the Virtualize My Desktop – Windows 7 site.

Daniel
Lead Architect – Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
My Blog: Virtualize My Desktop
Questions, then email Ask The Architect

Speed.  More speed. And to get more speed with desktop virtualization, we hear more and more about how important IOPS are to being able to support the virtual desktop. Not enough IOPS means slowness. No speed. I’ve had a few blogs about it and plan to have a few more. What I wanted to talk about was an interesting discussion I recently had with 3 Senior Architects within Citrix Consulting(Doug Demskis, Dan Allen and Nick Rintalan).  There are 3 smart guys who I talk to fairly regularly and the discussions get quite interesting.

This particular discussion was no different.  We were talking about the importance of IOPS, RAID configs, spindle speeds with regards to an enterprise’s SAN infrastructure. (Deciding if you are going to use a SAN for your virtual desktops is a completely different discussion that I’ve had before and Brian Madden had more recently). But for the sake of this article, let’s say you’ve decided “Yes, I will use my SAN.” If your organization already has an enterprise SAN solution, chances are that the solution has controllers with plenty of cache. Does this make the IOPS discussion a moot point? If we simply use an IOPS calculator (at least the ones I’ve seen) and do not take into account the caching capabilities of the SAN controllers, won’t we over-provision our virtual desktop environment and end up wasting more money/resources?

Many of us who are familiar with XenDesktop knows that changes made to the golden disk image, when delivered via Provisioning services, is stored in a PVS Write Cache.  From numerous tests and implementations, we know that 80-90% of the IO activity from a virtual desktop will be writes.  If we configure the SAN Controllers to be 75% write (assuming we have battery-backed write cache controllers), we allow the controllers to allocate more cache for write operations, thus helping to offload the write IO to the disk, which raises the number of effective IOPS the storage infrastructure can support. Think of the controller’s caching capabilities as a large buffer for our disks.  If our disks can only support so many write operations, the controller cache stores the writes until the disk is able to write it to the platter. This cache allows the infrastructure to keep moving forward with new operations even though the previous operations were not written to the disk yet.  They are all buffered. Just remember, we aren’t reducing the total number of IO operations, we are just buffering them with the controller cache.

Think about it another way. If we encounter a storm where each user will require 10MB of write operations and the storage controller has a 4GB cache, that one controller can support 400+ simultaneous users for this particular storm, and we haven’t even talked about the disk IOPS yet!!!  With this scenario, wouldn’t a single disk spindle be able to support this particular storm because the controller is buffering everything? And what’s also interesting is those write operations are being flushed to disk continuously so the number of users the controller will be able to support would be much, much higher.

So if we have cache on our controllers, which most SAN controllers I’ve seen lately have, are we over designing the storage infrastructure by only focusing on IOPS?  (this is assuming you are using SAN and not local disks on your hypervisor which I talk about a lot as well).  Just remember that those write operations must eventually get written to disk. So if we know what our controller cache is capable of, and we know the amount of storage required for a particular storm (logon, boot, logoff, etc), can’t we support more users (and I mean a lot more users) on the SAN?

What do you think?

Daniel – Lead Architect – Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
My Blog: Virtualize My Desktop
Questions, then email Ask The Architect

In an effort to finish publishing the PowerShell scripts I use for scalability testing, today’s GenVMs.ps1 PowerShell script demonstrates how to create basic virtual machines on Microsoft Hyper-V 2008 R2 hosts through the SCVMM PowerShell interface. The exciting part about today’s script is that when combined with the scripts I have previously released on this blog, it can be used to almost completely replace all the functionality of the XenDesktop Setup Wizard. The only thing left would be to create the Desktop Group, (which is on my list to automate but I have not got to that yet), in the Delivery Services Console.

This PowerShell script does the following:

1. Gets the next available MAC address from the Hyper-V address pool.
2. Creates a default profile with a single processor, 1GB RAM, and boot order.
3. Creates a VM using the supplied base name with a legacy network adapter and a DVD drive.

GenVMs Syntax Usage: GenVMs.ps1 VMTargetHost VMBaseName NetworkName LocalVMStoragePath NumberToCreate StartingAt Where: VMTargetHost= The Hyper-V host that will have the VMs created on it. VMBaseName= The base name for the virtual machines created. This name will have 00-99 appended to it. NetworkName= The name of the Hyper-V network to assign to the Legacy network adapter. LocalVMStoragePath= The path local to (or appears local to in the case of a CSV) the VMTargetHost. This is the path where the VM configuration files and the .BIN memory save-state file will be created. NumberToCreate= The number of virtual machines to create. Must be between 1 and 99. StartingAt= The starting number for the virtual machine incremental counter. This number plus the NumberToCreate should not exceed 99. Example: .\GenVMs.ps1 “HOST01″ “HVDesktop” “External” “E:\Hyper-V” 50 1 The example above will create desktops named HVDesktop01 – HVDesktop50 on HOST01 and the VM configuration files will be stored in HOST01′s E:\Hyper-V folder.

# Purpose:    Generate up to 99 virtual machines using the command-line parameters supplied
#             for customization of the new virtual machine.
# Date:       22 July 2010
# Author:     Paul Wilson (no implied or expressed warranties)
# Notes:      The script only creates VMs on a single host. To create VMs on multiple hosts
#             run multiple instances of the script from a batch file or create an outer loop.
#             The LocalVMStorage path must exist or the script fails. I have not added any
#             data validation checks to the script.

# Parse the command-line and verify the 6 required parameters are present, if not display usage info
if ($args -eq $null -or $args.Count -lt 6)
{
    write-output "Usage: GenVMs.ps1 VMTargetHost VMBaseName NetworkName LocalVMStoragePath NumberToCreate StartingAt"
    write-output "Example: .\GenVMs.ps1 ""HOST01"" ""HVDesktop"" ""External"" ""E:\Hyper-V"" 50 1 "
    exit 1
}

# Get the name of the SCVMM server we are running this on. The VMM server could be passed as a parameter as well.
$VMMServer = Get-VMMServer -Computername "localhost"

# Place the command-line parameters into named variables for later use.
$VMHost = $args[0]
$VMBaseName = $args[1]
$NetworkName = $args[2]
$VMPath = $args[3]
$VMCount = $args[4]
$StartCount = $args[5]
$EndCount = $StartCount + $VMCount - 1

for ($i=$StartCount; $i -le $EndCount; $i++)
{

    # Create a job group id to link the items together and create them as a group with the New-VM command

    $JobGroupID = [System.Guid]::NewGuid().ToString()

    # Get a MAC Address from the pool of available MAC addresses on the server. (Alternatively a MAC address could be assigned here.)

    $PooledMACAddress = New-PhysicalAddress -Commit

    # Get a network object for creating the network adapters

    $VNetwork = Get-VirtualNetwork | where {$_.Name -match $NetworkName -and $_.VMHost -match $VMHost}

    # Create a Virtual Legacy Network Adapter required for PXE booting with Provisioning Services

    New-VirtualNetworkAdapter -JobGroup $JobGroupID -PhysicalAddressType Static -PhysicalAddress $PooledMACAddress -VirtualNetwork $VNetwork

    # In case PXE booting will not be required or a second synthetic adapter the following line can be uncommented

    # New-VirtualNetworkAdapter -JobGroup $JobGroupID -PhysicalAddressType Dynamic -Synthetic -VirtualNetwork $VNetwork

    # Create a virtual DVD

    New-VirtualDVDDrive -JobGroup $JobGroupID -Bus 1 -LUN 0

    # Create a new Hardware Profile for a XenDesktop and set the default values or use the existing profile.

    $HWProfile = Get-HardwareProfile | where {$_.Name -eq "XD4Profile"}

    if ($HWProfile -eq $null)
    {
        write-output "Hardware profile not found. Creating a default profile."
        $HWProfile = New-HardwareProfile -Owner "XD4\Administrator" -Description "Hosted XenDesktop" -Name "XD4Profile" -CPUCount 1 -MemoryMB 1024 -BootOrder PXEBoot,IDEHardDrive,CD,Floppy
    }

    # Create the Virtual Machine and assign the VM Name. This only works up to 99 virtual machines.
    if ($i -lt 10)
    {
        $VMName = "{0}0{1}" -f $VMBaseName, $i
    }
    else
    {
        $VMName = "{0}{1}" -f $VMBaseName, $i
    }

    New-VM -VMMServer $VMMServer -Name $VMName -VMHost $VMHost -Path $VMPath -HardwareProfile $HWProfile -JobGroup $JobGroupID -RunAsynchronously -RunAsSystem -StartAction NeverAutoTurnOnVM -StopAction TurnOffVM
}

As mentioned earlier, this is a basic script and is meant to provide an example of how to create virtual machines on Hyper-V. This script could easily be modified to create VMs with different CPU/RAM requirements or even include the write-cache drive for Provisioning Server implementations as described in my previous blog PowerShell Scripts for XenDesktop Part 2.

In fact, if you run multiple instances of GenVMs.ps1 followed by copyVHD.ps1 from Part 2 the machine creation can be run in parallel (rather than serially) significantly reducing the deployment time over the XenDesktop Setup Wizard. Once the machines are created, use either GenPVSFile.ps1 from Part 3 or GenPVSMCLI.ps1 from Part 4 to load the machine and MAC address information into the Provisioning Services database. The final step is to return to the Delivery Services Console and create the desktop group.

If you found this information useful and would like to be notified of future blog posts, please follow me on Twitter @pwilson98 or visit my XenDesktop on Microsoft website.

It almost sounds like I’m talking about personal finances. You better plan your cache appropriately or you will run out. I’m not talking about money; I’m talking about system memory (although if you plan poorly we will quickly be talking about money).

It comes down to this… system cache is a powerful feature allowing a server to service requests extremely fast because instead of accessing disks, blocks of data are retrieved from RAM. Provisioning services relies on fast access to the blocks within the disk image (vDisk) to stream to the target devices. The faster the requests are serviced, the faster the target will receive. Allocating the largest possible size for the system cache should allow Provisioning services to store more of the vDisk into RAM as opposed to going to the physical disk.

Not planning system cache appropriately is the 8th mistake made when deploying virtual desktops

10. Not calculating user bandwidth requirements

9.   Not considering the user profile

8.   Lack of Application Virtualization Strategy

7.   Improper Resource Allocation

6.   Protection from Anti-Virus

5.   Managing the incoming storm

4.   Not Optimizing the Desktop Image

Unfortunately, many environments are not configured optimally. Simply adding RAM to a Provisioning services server is not enough; the system must be configured appropriately.

Parameter	Description
Operating System	The operating system plays a large role in how large the system cache can become.     * Windows Server 2003/2008 x32: 960 MB     * Windows Server 2003/2008/2008 R2 x64: 1 TB Because the 64 bit operating system can have a larger system cache, a larger portion of the vDisk can be stored in RAM, which is recommended. Windows 2008 is recommended over 2003 because of the improvements in the memory manager subsystem, which has shown some improvements.
RAM	8-32GB of RAM The more RAM allocated for the server, the larger the system cache can become. The larger the cache means vDisks reads will be faster. If you have more vDisks, you will need more RAM. A quick estimate is to plan for 2GB of RAM/Cache for each vDisk you will host. If you want more details, then I recommend the great article: Advanced Memory and Storage Considerations for Provisioning Servicescreated by Dan Allen (Sr. Architect at Citrix). It goes into the details of how Windows deals with cache.
vDisk Storage	The vDisk can be stored on just about any type of storage (iSCSI, Fiber, local, NFS, CIFS, etc). However, there are a few instances where the storage selected will have an impact on how the Provisioning services server’s operating system caches the vDisk blocks. 1. Network Drive: If the Provisioning services server sees the vDisk drive as a network drive via a UNC path, the server will not cache the file. 2. CIFS Share: If the storage infrastructure is a network CIFS share, Provisioning services will not cache the vDisk in memory.
Optimizations	In Windows Server 2003, large system cache must be enabled by configuring the server’s performance options, which is shown in the figure to the right. In Windows Server 2008, this setting is not required due to the enhancements in the memory allocation system. Windows 2008 utilizes a dynamic kernel memory assignment that reallocates portions of memory on-the-fly, while previous versions had these values hard set during startup. As Windows 2008 requires more system cache, the operating system will dynamically allocate.

Daniel – Lead Architect – Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
My Blog: Virtualize My Desktop
Questions, then email Ask The Architect

Since launching XenDesktop, one of the most common questions I have heard from XenApp customers is “Why would I use XenDesktop with my current XenApp implementation?” Well, there are a lot of reasons and this white paper helps answer them. According to the document’s description:

Application delivery scenarios covered in the white paper include:

• Installed Applications
• Streamed Applications
• VM Hosted Applications

Take a read and let us know what you think.

 
Technical Guide to Application Delivery Options for XenApp/XenDesktop