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.
I went kite fishing for the first time last week. Well, during this new adventure I got challenged by my teammates to relate kite fishing to XenDesktop, so this is my public reply to that challenge.
If you haven’t gone kite fishing, I’ll try to give you a brief explanation from a layman’s perspective. Kite fishing is on the ocean and you fly a kite off the back of the boat. Attached to the kite line at intervals is a break-a-way loop that you run the fishing line through. The fishing line is then suspended from kite string with the bait in the water and the job of the fisherman is to keep the bait in the water by either letting out the fishing line when the kite goes higher or retracting the fishing line as the kite drops.
After carefully considering the experience, I came up with four areas where I saw similarities. First, I had never been kite fishing before and quite honestly, I would have never figured out how to kite fish without an experienced person to show me the ropes. Second, choosing the right kind of bait to attract the fish we were seeking required a specific knowledge of the fish diet. Third, setting up the kites and stringing the fishing lines didn’t really require a lot of skill, but you had to have done it before – reading it from a book would not have worked for me. (They tried to explain it to me before they did it and I did not understand until I saw it occur). Finally, keeping the bait in the water was the key to getting a fish on the line.
Experienced Guidance
If this is your first time kite fishing, you want someone who had done it before to show you the ropes. Similarly, if this is your first time building or architecting a XenDesktop farm, you want someone knowledgeable to provide that guidance. As a XenDesktop architect with experience designing and architecting large farms, most of my blogs and whitepapers are targeted to providing you the information I believe is relevant to these tasks. In addition, Citrix has many partners (silver, gold, and platinum) and a professional services organization that are trained in XenDesktop design and deployment as well.
Customer Requirements
Selecting the right kind of live bait is key to a successful fishing trip. If the captain is unable to locate the right type of bait fish for the big fish his charter is seeking, he will not likely be successful. In most cases, an assessment should occur which provides input into the next phase. With fishing, the assessment is fairly simple since the captain just asks, “What kind of fish do you want to catch today?” From the conversations that I had, different type of fish required not only different bait, but different fishing techniques and different locations on the ocean. In much the same way, if you understand the customer’s needs and long-term plans you can better design the XenDesktop farm. The XenDesktop assessment answers questions like “Where will the virtual desktops be accessed from?”, ” What applications will the users have?”, and “What application virtualization platforms will be required?”
Setup and Installation
When feeding out the kite and the fishing lines, the whole environment must be configured in a specific order. With the kite going out first, followed by the first latch with the longest fishing line, then the second latch with the medium fishing line, and finally the short fishing line. If the correct process is not followed, it is likely the lines will get tangled and the first mate is not happy with you… Similarly, the XenDesktop farm needs to be installed and configured correctly to meet the customer requirements. Citrix provides many complimentary resources, such as the XenDesktop Checklist, the XenDesktop Quick PoC Kit, and XenDesktop Training. These items plus many resources are available from the XenDesktop website.
Fine Tuning the Environment
When kite fishing you need to work to keep the bait at a fairly consistent level in the water by playing out or retracting the fishing line based on the changing conditions. You have to account for the constantly changing distance between the free-flowing kite and the ocean waves as well as the direction the live bait chooses to swim. Now I know what a “fish out of water” looks like as it hangs from a kite, pretty funny really, but I digress. The skill comes in accurately judging the amount of line to release or reel in based on the environment. Much like fishing, once you get your XenDesktop environment up and running you will need to adjust for your user behavior. Things like desktop boot storms, user login storms, idle pool settings, patches, etc. all take a little bit of planning and adjustment after you get the environment into production.
If you are ever in the Miami area, I highly recommend Captain Nel Martinez of Top Gun Fishing Charters where I guarantee you will be well taken care of. If you are lucky, you will find some way to relate the trip to work and expense the whole thing. ![]()
I could list all the reasons I think the iPad + Citrix are a great fit for healthcare, but it may be more meaningful coming directly from Physicians and IT Pros in the heathcare industry. This is a sample of what has been shared on the blogs when we asked what would Citrix Receiver for iPad be used for.
Dr. Paul Altmann says:
” Chris, the combination of Citrix and the iPad will, I am sure, be a huge success in the healthcare setting where the form factor of the iPad makes it the best all round device to access medical records in real time as clinicians care for their patients.Specifically, I am looking forward to showcase this for Cerner Millennium users who routinely access the application over Citrix.
There will be many other settings where the iPad, which is the first really decently sized, light, with good battery life “thin client”, will become very popular.
Dr Paul Altmann
Clinical Director – Health Informatics – NHS South Central & Oxford Radcliffe Hospitals NHS Trust
Consultant Nephrologist – Oxford Kidney Unit The Churchill – Oxford OX3 7 “
.. says:
“I would love to be able to use citrix on an iPad. I currently use Citrix to log into our hospitals EMR, Epic, from home. Being able to do so both at home and even in the hospital would be awesome. “
..says:
“So Are you saying that I would be able to use my GE Healthcare Centricity EMR Application from the Ipad? We connect to it using XenApp. This is really the only thing holding me back from getting an iPad is that whether I would be able to run my EMR for work.
..says:
“Please tell us you are working on a citrix client for the IPad. It will be so “revolutionary” if you have one ready by the time the IPad is available. Physicians will love to use an IPad to handle their Electronic Medical Records at bedside, exam rooms.”
“Chris Smith says:
Yes, I think this would be fantastic. Many EHR (electronic health record) applications have developed stylus-driven interfaces for slate PCs (tablets with no keyboard option), so touch interface is a natural easy win for those already developed applications. Many of the EHR applications are also already deployed via Citrix, so this is a serious WIN WIN for Citrix to pursue… and as you mentioned, Citrix has already done quite a bit of work on the Citrix Receiver for the iPhone. This really does have so much more capability, now that you have the larger screen.
Also, multi-touch is supported in Windows 7, so it will be interesting to see how the XenReciever can interact with the Win7 host operating system environment, or even hosted application environment, but having the Receiver bridge that gap in the user experience via the iPad would be amazing!”
..says:
“I work for a health care provider and this could be huge. It turns the iPad from an interesting toy, to potentially powerful tool for business”
Todd Bruni says:
“Being in a large Healthcare environment I also see this device as having huge potential. First for ARRA/Hitech initiatives such as CPOE, BMV, Physician Documentation, etc physicians, clinicians, and/or nursing are going to want, need, demand mobile devices. As multiple people have pointed out one of those devices are tablets. The cost of those devices intended for Healthcare are extremely expensive (Motion Computing, etc). Second, as people have pointed out protecting patient data is a requirement. That is one of the beauties of desktop virtualization whether its hosted shared desktops or hosted dedicated desktops that data stays in the data center. Finally organizations need to hit meaningful use in the not so distant future. Most of the large EMR vendors are not web-based today and organizations have to start taking steps now to meet the meaningful use timelines. That means these applications are client based today which is another reason to do desktop virtualization now until the ISVs solutions are ported to the web.
So how does this wrap back around to this device? Any device that is going to help healthcare organizations start taking steps now to adopt desktop virtualization, mobility, extend battery life, and move data into the datacenter without having to spend $2k on a tablet, $3k on cart solution is a great candidate. Being able to purchase 4 or 5 of these devices at the cost of one tablet makes it very intriguing. Add a docking station with keyboard and mouse for $40-50 in key locations and now you don’t have to worry about real estate on the floors (another huge healthcare issue) and the device becomes easy to stop and make updates to your EMR.
Finally, I don’t remember who said it but I completely agree with whoever said that we won’t know any of this until we get these devices into the clinicians hands we won’t know.”
..says:
“Already have XenDesktop environment pushing around 20 desktops using Nextgen out to several medical clinics in my area. Was able to get budget money for purchasing 5 iPads as a demo in less than 2 minutes. Will be an interesting demo as I have connections to several hospitals that are all looking into the EPIC Haiku Application also being developed with Keiser Medical Group in mind. A current rolling wireless cart with a WYSE Thin Client typically costs a Hospital in Oregon $20,000 after we did our full ROI 2 years ago. Interesting what happened in 2 years! “
Checkout the Heathcare IT Community site http://community.citrix.com/p/healthcare
Learn how to make the iPad work for your healthcare organization at Citrix Synergy.
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: 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.
This is the second blog in a two-part series to respond to the remaining unanswered questions from my Citrix, Microsoft, HP: Best Practices for Scaling Virtual Desktops webinar on June 17, 2010. I covered the first half of the questions in XenDesktop Scalability Q&A Part 1. Some questions with similar content have been combined into a single question and others have been adjusted for typing errors.
Q: Can I get a podcast of this audio?
A: Yes. You can replay the webinar by clicking here though registration may be required.
Q: This lab infrastructure looks quite impressive but what would be the price tag on it? What would the initial investment be?
A: Unfortunately I do not have an answer for this question. I did ask that question while I was at HP and they told me that I would have to contact my HP sales rep to get a quote.
I will say that HP, Microsoft, and Citrix have recently teamed up to help you jumpstart your VDI implementation, including discounted licenses and implementation services. You can check out the Activate and Ignite offers by clicking here. Also, HP has released a whitepaper on a building a single rack VDI implementation that supports up to 1,000 users. You can find more about this configuration by downloading the Whitepaper – HP Reference Configuration for Citrix XenDesktop directly from HP’s website.
Q: What are the advantages of for Citrix Provisioning Server vs. other provisioning solutions?
A: I cannot speak for other provisioning solutions, so I am just going to share the advantages of Citrix Provisioning Services (PVS). The primary advantage of Provisioning Services is the ability to save storage costs. With PVS, you can create a single desktop image that can then be streamed over the network to the guests using the PXE boot protocol. The guests can be diskless, though for best performance we usually recommend a 2-3 GB local disk to function as a write-cache. The storage savings comes from only needing a write-cache drive which represents a fraction of the size needed for a full VHD. For instance, a normal virtual desktop deployment of 100 desktops each with a 20GB Windows 7 image would require about 2000GB of costly SAN storage. With PVS, the storage can be reduced to a single 20GB Windows 7 image and 100 2-3GB write cache disks or about 320GB, which could be local or SAN storage.
The second advantage I see is the ability to upgrade or revert with only a simple reboot of the guest. Since a single image can be used across multiple virtual desktops, updates need only be performed in one location. Then virtual desktops automatically pick up the most current image upon reboot. If for some reason that image fails to perform, the administrator can easily revert to a previously working image and reboot the guest. Factor in the reduced overhead on the host’s CPU and disk subsystems, (because the disk reads are now coming over the network), and the solution improves guest performance significantly.
Q: What metrics do you monitor to identify bottlenecks within Provisioning Server? Are the metrics the same between physical and virtual Provisioning Server?
A: Really good question. Normally, you monitor the same metrics you would for any other server, since the bottleneck could be at the CPU, RAM, Disk, Processor or Network level. However, that said, you will find that the network is by far the most utilized resource, so watching the Bytes Sent/sec performance counter is where I start. If your write-cache is on the server-side (instead of client-side) then you will also need to watch the Bytes Received/sec, the Processor % Idle Time, and the Current Disk Queue length. From the test results I have seen I would say the second most utilized resource is the CPU, so watch that one if you do not have a beefy box.
To give you an idea, for the 3500-desktop run we had three BL460C blades each with 48GB RAM, dual Nehalem processors and 4GB of network bandwidth. The network bandwidth was reaching 3GB when booting up all 3500 servers. The processors were at 50% idle. I had only one vDisk image so the current disk queue length averaged slightly over 0 and the server reported 45GB of available RAM.
Q: What metrics do you monitor to identify bottlenecks within the Desktop Delivery Controller?
A: As stated earlier, bottlenecks could appear in any resource, so I watch key indicators across the board. That said, the resource most likely to be the bottleneck with the Desktop Delivery Controller is the CPU. Watch the CPU %Idle time and the CPU %Processor time for the Citrix services, such as CdsPoolMgr on the Pool Master and both CDSController and IMASrv on all the member servers. Also watch the Context Switches and Processor Queue Length for general processor health.
Q: Can you provide the formulas used in the IOPS calculator spreadsheet?
A: No, but I am planning on releasing a copy of the spreadsheet in Q3 so watch my website for updates.
Q: What is the expected completion date for the whitepaper?
A: Currently the draft is circulating for review. Provided the reviews are completed in a timely manner and the document doesn’t have any major flaws, the plan is to release it by the end of Q3.
Q: When will offline virtual desktops be available?
A: Technically speaking, you can have offline virtual desktops today with XenClient, which is free. You can download it here.
Q: What method should I use for sizing XenDesktop?
A: In a general sense, Citrix and other vendors provide sizing guidelines. Some vendors, such as HP even have sizing tools available for download to help you get the best hardware fit for your needs. I believe the best method is probably to do a pilot with your power users. If you are serious about VDI, the best approach is to take and build a small pilot environment. The results of the pilot will give you an idea of what the performance expectations of the virtual desktop should be as well as a taste for how it will fit into your environment. Then you can take your performance data and correlate that with published VDI data on the same hardware, from there you can extrapolate what hardware you will need.
For instance, say you build Windows 7 desktops on a BL460C with 64GB RAM and Nehalem processors and choose Hyper-V as your hypervisor. At the end of the pilot you may determine that the optimal number of users is 50. If published results for the same configuration show an optimal number of users on a BL460C running a medium LoginVSI workload is 75, then you know that your workload requires about 50% more capacity than the medium LoginVSI workload. At this point, you can use the LoginVSI medium workload results on any hardware or hypervisor and adjust the capacity by 50% to get your number on that same configuration.
Q: Without seeing lab results yet, what is the largest number of virtualized desktops I can expect to run concurrently? What is the real-world experience vs. the lab?
A: Since this question is not specific as to the bounds of the concurrency I will presume it is referring to concurrent desktops on a single server. Essentially, the number of concurrent desktops that you can run on a single server depends primarily on your user workload. Generally speaking, the LoginVSI medium workload that we use in the lab is purely for comparative purposes and is unlikely to represent your actual user workload. What LoginVSI does do is give you an idea of what the hardware is capable of supporting in a specific configuration. I have seen the number of desktops for a single server range from 30 to over 120 with the limiting factors usually being available RAM or processor.
Q: Would one expect to see the same results regardless of the hypervisor being used or will that make a difference? Would we expect to see similar performance/numbers if we used vSphere4 or XenServer Enterprise/Platinum instead of Hyper-V?
A: I believe I answered this one during the webinar, but I will reiterate my position again. I believe hypervisors are now becoming more of a commodity with respect to performance and scalability with the key differentiators being features such as migration, snapshots, etc. Each hypervisor has its areas of focus and some may perform better than others in certain configurations. Overall I would venture to say that I expect similar scalability numbers (say within 10% tolerance) on the same physical hardware when comparing hypervisors.
Q: In Active Directory – the more global groups an ID is associated with the larger the ID bloat becomes. Today there is a limit on the size of the ID file which also limits access to the server farm. Today Microsoft doesn’t have any way of correcting this issue. Do you know of a way to get around it?
A: Unfortunately, no. Microsoft Kerberos tokens have a maximum limit of 1024 SIDs, (less in some circumstances depending on the length of your AD domain’s FQDN), which when exceeded prevents user logon because all group memberships cannot be evaluated. The only solution at this point is to reduce the amount of group memberships. Microsoft is aware of this issue and has provided guidance and best practices to help limit the exposure. You can download their guide from the Microsoft website but I cannot provide a better solution at this time.
That concludes the unanswered questions from my webinar. I hope you find the answers helpful. If I misunderstood your question, feel free to clarify it as a comment below.
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.
Two days ago I provided a PowerShell script that could be used to generate an import CSV file for Provisioning Services (PVS). However, after importing the devices, a vDisk still needed to be assigned (if you didn’t configure a template) and more importantly, an account still needed to be created in Active Directory for each device. These extra steps increased the complexity of the import process.
I got to thinking that the MCLI command-line interface could be used to do all three tasks, but the PowerShell script would have to generate all the MCLI commands necessary for each desktop import. I had a bit of spare time, so I sat down and modified the earlier import script into a new PowerShell script that outputs a file of MCLI commands for the desktop import. As with the prior script, this one should be run from the SCVMM server that manages the XenDesktops that you are importing into Provisioning Server.
This new PowerShell script creates a CMD file that contains three MCLI commands for each desktop. The commands are as follows:
1. Adds the device to the configured device collection
2. Assigns the vDisk specified on the command-line to the device
3. Adds the device to the domain
After the PowerShell script has successfully completed, the only step left is to take and run it from the %ProgramFiles%\Citrix\Provisioning Server folder on one of the provisioning servers. The MCLI commands should then execute sequentially the three commands listed above for each desktop.
| GenPVSMCLI Syntax
Usage: GenPVSMCLI.ps1 SiteName CollectionName Description StoreName vDiskName CmdFileName VMMatchCriteria [OUName] Where: Example: .\GenPVSMCLI.ps1 “Dell” “XenDesktops” “XD Desktop” “Local Disk” “Win7Base” “c:\PVSMCLI.cmd” HVDesktop “XenDesktop/VMs” The example above will create a file called PVSMCLI.cmd that will have all the MCLI commands for hosts matching the name HVDesktop (HVDesktop1, 23HVDesktop, etc.) in it to add devices to the XenDesktops device collection in the Dell site. The vdisk Win7Base found in the store called “Local Disk” will be assigned to all the devices imported and the computer accounts will be created in the VMs OU found in the XenDesktop parent OU. |
# Purpose: Create a MCLI cmd file to add devices to Provisioning Services, assign a vDisk # and add the device to Active Directory. The cmd file can then be executed from # any Provisioning Services server. # Date: 1 July 2010 # Author: Paul Wilson # Notes: The file may need to be opened and saved in ANSI format on some computers. # This script automatically appends information to any existing file in case you # need to run the command multiple times with different match criteria ######################################################################################################################## # Special Organizational Unit to add the Device(s) to is an optional parameter. # # Use If it is not specifed, the device is added to the builtin Computers container # # Notes Child OU's should be delimited with forward slashes, e.g. "ParentOU/ChildOU". # # Special characters in an OU name, such as '"', '#', '+', ',', ';', '>', '=', must be # # escaped with a backslash. For example, an OU called "commaIn,TheMiddle" must be specified # # as "commaIn\,TheMiddle". The old syntax of delimiting child OU's with a comma is still # # supported, but deprecated. When delimiting with commas,the child OU comes first, e.g. "ChildOU,ParentOU".# ######################################################################################################################## # Parse the command-line and verify the 7 required parameters are present if ($args -eq $null -or $args.Count -lt 7) { write-output "Usage: GenPVSMCLI.ps1 SiteName CollectionName Description StoreName vDiskName CmdFileName VMNameMatches [OUName]" write-output "Example: .\GenPVSMCLI.ps1 ""Site"" ""Collection"" ""XD Desktop"" ""Local Disk"" ""Win7Base"" ""c:\PVSMCLI.cmd"" HVDesktop ""ParentOU/ChildOU"" " exit 1 } # Place the command-line parameters into named variables for later use. $SName=$args[0] $CName=$args[1] $DString=$args[2] $StName=$args[3] $VName=$args[4] $CmdFName=$args[5] $VMNameMatches=$args[6] $OUName=$args[7] # Connect to the local server as the SCVMM host to process the PowerShell commands $VMMServer = Get-VMMServer -Computername "localhost" # Retrieve a list of all the VMs that match the name matching criteria supplied and sort them by name $AllVMs = Get-VM | where { $_.Name -match "$VMNameMatches" } | sort Name # For each VM found the loop below does the following: # 1. Locates the MAC address of the primary network adapter # 2. Appends to the cmd file supplied the MCLI command-line to add the device with the appropriate information. # 3. Appends to the cmd file supplied the MCLI command-line to assign the provided vdisk to the device. # 4. Appends to the cmd file supplied the MCLI command-line to create the computer account in the domain. foreach ($vm in $AllVms) { $nicDetails = Get-VirtualNetworkAdapter -VM $vm $MacAddr = $nicDetails[0].PhysicalAddress $AddString="MCLI Add Device -r deviceName={0} collectionName=""{1}"" siteName=""{2}"" description=""{3}"" deviceMac={4} bootFrom=1" -f $vm.Name, $CName, $SName, $DString, $MacAddr $AssignString="MCLI Run AssignDiskLocator -p deviceMac={0} diskLocatorName=""{1}"" siteName=""{2}"" storeName=""{3}"" " -f $MacAddr, $VName, $SName, $StName if ($OUName -eq $null) { $DomainString="MCLI Run AddDeviceToDomain -p deviceMac={0}" -f $MacAddr } else { $DomainString="MCLI Run AddDeviceToDomain -p deviceMac={0} organizationUnit=""{1}"" " -f $MacAddr, $OUName } write $AddString | out-File $CmdFName -Append write $AssignString | out-File $CmdFName -Append write $DomainString | out-File $CmdFName -Append }
Now, I have noticed that when adding hundreds of devices at a time that the domain controller gets busy and the AddDeviceToDomain command sometimes fails. I suggest for large deployments that you pipe the output to a text file and then later review it for possible failed commands. Re-running the failed commands should be sufficient since they are mostly independent of one another. The only exception being the Add Device command must succeed or the other two will fail.
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.
This blog is to respond to questions from my Citrix, Microsoft, HP: Best Practices for Scaling Virtual Desktops webinar on June 17, 2010. I received 22 questions during the webinar and unfortunately did not have time to answer them all. I will cover the first half of them in this blog and address the remainder in a follow-up blog. Some questions with similar content have been combined into a single question.
Q: Do you have a link to the specific entry on your blog about your experience with the issues between NIC teaming drivers and the Hyper-V role?
A: Yes, though technically it is not on my blog, but on my XenDesktop with Microsoft Technologies website. Under the Other Resources section you will find the entry “How-to Guide for HP NIC Teaming Software and Microsoft Hyper-V”. Just follow that link.
Q: What would you estimate the ratio of virtual machine to server CPU core to be?
A: It depends mostly on the processor. My experience with Intel Nehalem processors is that the maximum VM Density per core is around 11 for a medium workload. However, I would not recommend running at 11 for that workload, I would probably plan for 9-10 per core to leave some headroom for burst capacity. Keep in mind also that those numbers are taken without an anti-virus solution in place.
Q: Do you have best practice hardware and software setups for 50-100 user increments that are scalable for adding additional 50-100 user blocks that can be downloaded?
A: Not at this time. Citrix Consulting Solutions is currently working on a concept document that covers the creation of a small scale architecture that can be repeated. That document is in the final stages of review, so it should be released in the near future.
Q: From what I know we can create two different types of profiles – standard (for everyone) and dedicated. The dedicated one gives a users “administrator” privileges to make permanent changes to their desktop that are persistent. For a “standard” image, how much information follows a user on their profile from session to session as they log on and off multiple times?
A: Good question. What you are actually referring to is what we call vDisks for Provisioning Services. The vDisks are “golden master” images that are shared or private to a virtual machine. When a vDisk is in “private” image mode, all changes are permanent to the VHD. The “standard” image is considered “read-only” and all software installed is lost when the virtual machine is rebooted. The standard mode is used for creating pools of desktops that are available to service any user. The amount and type of information that follows a user between sessions is dependent on how profiles are managed. The key to deploying this successfully is using profile management software that can redirect the user data folders to a network location or save off the data in a roaming-profile type scenario. In both image modes, the user can be configured to be either a local administrator or just a local user, similar to any other workstation on the network.
Q: How different would the architecture be in a combined scenario of XenDesktop and XenApp?
A: That is the beauty of using XenDesktop Enterprise or Platinum editions, they come with XenApp and the only difference is the addition of XenApp servers. The XenApp farm can leverage the existing License Server, database server for the hosting the farm (though it will be a different farm), and even the same Web Interface servers. In fact, most XenDesktop deployments today include XenApp. Using XenApp provides the advantage of offloading the processing for resource-intensive applications and also helps reduce the licensing costs of applications that are not necessary for all users to have installed.
Q: How many virtual desktops could be supported with a DL380 G6 32GB RAM and 8 cores?
A: Let start by saying “it depends” probably more on the user workload and the SAN/Local storage available than on the RAM and Processor power. I cannot tell you how many desktops you could get in your environment, but I can tell you what I have seen with regard to limitations. The processors will not be a limiting factor because Windows 7 core density on a G6 (Nehalem class processor) will be around 10:1, so 8 cores would about 80 machines. Your primary limiting factor appears to be the RAM. With only 32GB RAM you could get a maximum of about 30 Windows 7 desktops (1 GB RAM) or maybe 60 Windows XP (512MB) on Hyper-V. A DL380 G6 supports up to 8 SFF drives, so the local storage could be used to host guest virtual hard disks. Once again though, it all depends on your user workload.
Q: Was that Hyper-V on server core?
A: No. We used the full Windows Server 2008 R2 Hyper-V version instead of server core. The primary driver for this decision was the need to obtain detailed performance metrics on the host servers and correlate that data with our internally developed test harness, called STAT. Unfortunately, the STAT agent responsible for the metric collection requires a GUI install which would not work on server core. A nice benefit of not using server core was of course that I didn’t need to figure out the script commands for installing and configuring HP NIC teaming drivers.
Q: Can a presentation be prepared or at least a comparison between Hyper-V and ESX4i (VSphere)?
A: Yes. I am currently planning a similar topic for my Q3 webinar. The VMWare EULA prevents any direct comparisons or performance results from being communicated, but I plan to cover the best practices for running guests on the three hypervisors supported by XenDesktop: XenServer, Hyper-V and VMWare VSphere.
Q: Which FlexCast model applies to your testing and scalability numbers?
A: The model that I used is considered the “Hosted VDI” model where a full VM is running on a Hyper-V host. However, technically speaking, it includes the “Streamed VHD” model, since the VHD for the pooled desktops was getting streamed to the virtual desktops running on the host system.
Q: The response times are based on local LAN-based users, correct?
A: Yes. However, since the response times are calculated by Login VSI from within the XenDesktop session, they would be the same no matter where the desktop is accessed from. For WAN users you would need to adjust for the latency on the line.
Q: Seems like Citrix talks a lot about deploying on Hyper-V. Is there a reason why this is done on Hyper-V instead of using XenServer (or even VMWare)?
A: Good Question. The answer is that we perform these tests on all hypervisors. It just turns out that I am the XenDesktop on Microsoft architect, so I volunteered to be the one that did the Hyper-V testing. We do have some scalability test results for other hypervisors on our Citrix eDocs website. Once there choose XenDesktop >> XenDesktop 4 >> XenDesktop Scalability Guidelines. We are continually testing XenDesktop with all supported hypervisors and normally make that information public as it becomes available.
That concludes the first round of unanswered questions from my Scaling XenDesktop webinar. The rest should be posted within the next few days. I hope you find the answers helpful. If I misunderstood your question, feel free to clarify it as a comment below.
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.
Today I want to provide a PowerShell script that can be used to export information from a XenDesktop Hyper-V installation and import it back into the Provisioning Services (PVS) console. This script is useful when you are not using the XenDesktop Setup Wizard and are creating the virtual machines manually. Exporting and importing is much quicker than manually adding each guest VM machine name and MAC address to the console.
The PowerShell script should be run from the SCVMM server that manages the XenDesktops that you are importing into Provisioning Server.
| Syntax Information
Usage: GenPVSFile.ps1 SiteName CollectionName Description ImportFileName VMMatchCriteria The example will locate all VMs with a name that matches HVDesktop (HVDesktop1, 23HVDesktop, etc.) and generate a CSV file called PVSImport.csv. When imported via the PVS console, the devices will go into the XenDesktops collection for the Dell site. |
# Purpose: Create a CSV file that can be imported by Provisioning services # Date: 14 April 2010 # Author: Paul Wilson # Notes: The CSV file may need to opened and saved in the ANSI format on some computers. # This script automatically appends information to any existing file in case you need to # run the command multiple times with different match criteria. if ($args -eq $null -or $args.Count -lt 5) { write-output "Usage: GenPVSFile.ps1 SiteName CollectionName Description ImportFileName VMMatchCriteria" write-output "Example: .\GenPVSFile.ps1 ""Site"" ""Collection"" ""XD Desktop"" ""c:\PVSImport.csv"" HVDesktop " exit 1 } # Pulls the VM Name Match criteria off the command-line $VMNameMatches = $args[4] # Connects to the local SCVMM Server $VMMServer = Get-VMMServer -Computername "localhost" # Finds all matching VMs and sorts by their machine name $AllVMs = Get-VM | where { $_.Name -match "$VMNameMatches" } | sort Name # The following loop gets the MAC address of the primary NIC then writes # that output to the CSV file along with the other fields required for the PVS import # most of which were supplied as parameters on the command-line. foreach ($vm in $AllVms) { $nicDetails = Get-VirtualNetworkAdapter -VM $vm $csvString = "{0},{1},{2},{3},{4}" -f $vm.Name, $nicDetails[0].PhysicalAddress, $args[0], $args[1], $args[2] write $csvString | out-File $args[3] -Append }
After you have the file, you have two options for importing the data into Provisioning Server. Before doing either, the best approach is to configure a default template for the collection and set the appropriate vDisk for that template. This way you will not later need to go back and assign a vDisk to all the devices. You can use the PVS Administrator’s guide to obtain instructions on how to create and assign a device template.
Using the GUI you can select a device collection, then right-click and choose Target Device >> Import Devices… from the context menu as shown in the screen shot below.
Alternatively you can use the MCLI command-line utility that comes with Provisioning Server. The MCLI commands must be run from a Provisioning server at this point. You can find MCLI in the %ProgramFiles%\Citrix\Provisioning Services folder. The command-line for importing looks like this:
MCLI run importdevices -p filename=\\server\share\pvsimport.csv copyTemplate=1
Remember after you finish importing all the MAC addresses be sure to add them to Active Directory. You can do this by selecting all of the devices, right-clicking on them and choosing Active Directory >> Create Machine Account… from the context menu as shown below.
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.
Electronic Medical Records (EMR) implementations have their own, unique challenges. Healthcare organizations are concerned with selecting a vendor, complying with a myriad of regulations, and basically transforming the way healthcare is delivered to their patients.
Given the transformative nature of an EMR implementation, virtualization is often just a side thought for health CIOs. Therefore, I’d like to shed some light into the topic and share my personal top 5 reasons to pursue this topic further- starting with the centralization of medical records data.
For a quick definition of the term itself, please refer to yesterday’s blog.
I assume that the backend database for your electronic health records reside in a single, centralized datacenter. Through global server load balancing, you may have already implemented site-to-site redundancy, but that’s beside the point for today’s discussion.
So, traditionally, you would have rich client applications or web browsers on the user’s endpoint to consume and manipulate the medical records data. This automatically implies that a lot of health data moves to and from the datacenter and often to remote locations where it is challenging to maintain a tight grip on security.
Application or Desktop Virtualization can solve that problem. Both of these techniques move the client software piece (or web browser) to the datacenter, where it executes securely inside your facility. The health data never even leaves the datacenter. The user interaction happens via a secure, high performance protocol (such as Citrix’ HDX in the XenApp and XenDesktop product lines) and gives the user a snappy interaction with the software, while only exchanging screen updates and keyboard/mouse events between the end user and the datacenter. Additional data streams pertaining to peripherals, printers, USB devices, scanners, and client hard drives are possible, but can easily be disabled to promote further security.
No data ever makes it to the end point, and therefore reducing the risk of HIPAA/HITECH covered security breaches. In addition, user sessions can be audited to establish an independent trail of information in case the regulators or courts require a closer look.
If you’re curious, I encourage you to check out Dan Feller’s Ask the Architect site. Dan has a wealth of information on desktop and application virtualization and associated whitepapers and reference architectures.
Florian Becker
Twitter: @florianbecker
Virtualization Pulse: Tech Target Blog
Ask the Architect – Everything Healthcare
The following is a blog I posted on my “other” site – Virtualization Pulse, hosted by Tech Target. Most readers on these pages are already very knowledgeable, so please forgive the simplistic view. In the near future, I will publish additional blogs on virtualization and specifically focus on the the healthcare IT space. Consider this one a relatively simple level-set for the audience. Enjoy.
———————————
Given that there are a lot of incentives associated with the adoption of Electronic Medical Records, medical CIOs and their teams are inundated by vendor messages these days. Phrases like “Meaningful Use”, “HITECH”, “HIPAA” are on the forefront of everyone’s mind, but you may also hear about virtualization. Given that there is still some confusion on the topic, I’d like to clear a couple of things up:
“Virtualization” is a term that has been traditionally used in the context of server virtualization. The technology involved is often referred to as “Hypervisors” which basically allow a modern server with plenty of CPU and Memory resources to share those resources between multiple “workloads” or “virtual servers”. So, instead of having one physical server with 16 CPU cores and 128 GB of RAM, this server can often house 40-60+ individual workloads that act on your network just as if they were much smaller individual servers. The benefits are obvious. Today’s servers are relatively cheap to acquire and most server workloads don’t require nearly as many computing resources to do their job. IT departments can lower cost by running fewer physical servers, consume less rackspace, lower power consumption and cooling costs. Advanced virtualization solutions also allow for virtual servers to automatically move to a separate physical host in case of a hardware failure. The failover process is often seamless and therefore provides resiliency, but typically requires a separate, redundant storage area network for this to work on the fly. Workloads with less criticality can be moved in a semi-manual fashion where they are simply restarted on another physical host by the administrator.
Vendors in this space include VMware (vSphere), Citrix (XenServer), Microsoft (Hyper-V) and a number of other players.
Application Virtualization. This is another form of virtualization, which has virtually nothing to do with server virtualization (pun intended). In this model, an application (think about your office productivity suite, or your electronic medical records client) is installed on a central server and executes there. The user connects from their endpoint (PC, laptop, thin client devices, etc.) via a remoting protocol and essentially controls the application remotely. This can be done on the simple level with Microsoft Terminal Services and the RDP protocol, and on the higher end via specialized solutions such as Citrix XenApp (formerly known as Presentation Server or MetaFrame). The benefits are obvious. Applications can be centrally managed and IT support personnel would no longer have to touch an end users system to install or patch an application. All updates are performed on a few centrally located servers. This approach also has the advantage of the application being physically close to the backend data of the app (on a low-latency, high bandwidth network), which leads to faster execution of the app and much increased security as the data never leaves the datacenter. The only information that is exchanged between the end-user’s device and the central server are screen updates and mouse and keyboard events. The protocols also include the capability of conveying information such as audio, printing, USB device support etc. The performance is actually astonishing in many cases and the most demanding customers in the area of engineering run their complex design applications via Citrix XenApp.
Desktop Virtualization. This is the latest and greatest. Instead of executing just a set of applications in the datacenter, the industry is moving towards executing desktop operating systems in the datacenter and allowing users to connect to the desktops . One could write a whole book about desktop virtualization, so I am trying to keep it brief. Some vendors tout a “VDI” or “Virtual Desktop Infrastructure” model, where each user basically has their own, assigned, virtual desktop in the datacenter. This model moves the headache of desktop maintenance to a central location, but still encounters some of the same challenges associated with traditional desktop management (such as the need to patch multiple desktop instances and troubleshoot/fix corrupted or infected desktops).
More advanced models go towards a shared desktop image model, where each user connects to a brand new, pristine desktop operating system, which folds the applications and user settings into the desktop as the user connects. This has the advantage of ensuring the highest performance (after all, a brand new desktop always performs best) and can also cut down on the number of desktops to maintain. Having just one or a handful of desktop master images to patch and maintain for thousands of users provides great efficiency gains and cost savings.
So, let’s recap. Server, Application, and Desktop Virtualization are three distinct disciplines in healthcare IT and are important to understand. Don’t fall for the siren’s song and believe that a particular vendor who is good at one discipline is automatically an expert at the other virtualization disciplines.
Check back on these pages in the near future for my rundown on virtualization techniques for your EMR implementation.
Florian Becker
Twitter: @florianbecker
Virtualization Pulse: Tech Target Blog
Ask the Architect – Everything Healthcare



