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.
For those of you who missed the June 18th TechTalk on the design for a 20,000 user environment, missed out. Well, not really. Luckily, we recorded the presentation so you can watch it whenever you desire. As you know, the webinar was based on a reference design for a 70,000 user school district. Links to the materials are as follows:
- TechTalk Webinar for 20,000 User Design
- Reference Design for the ABC School District
- ABC School District Blogs
In addition to the materials, we also had some really great questions during the webinar, which I’ve answered below:
- Yes
- No
- Maybe
- No Way
- Of Course
- Possibly
- You are Crazy!!!
- E-MC2
Just kidding, the questions you are probably more interested in are as follows:
| Q: Can you go over a little more on the RAM requirements that you need for the virtual desktops? A: Sure. Scalability tests conducted were able to run Windows 7 with 768MB of RAM. However, in an actual real-world implementation, you will most likely need more than that. First, you need to break your users down into different categories (Light, Normal and Power). As you move through these, the users will require more RAM. Based on the student population, high school users will use more apps than middle school or elementary. Thus we need to allocate more RAM for those groups of users. |
| Q: Great Webinar – Did you experience latency problems using Streaming Applications A: If you mean in the launching of applications, yes. Streamed applications will take longer to start than installed applications. What we did to help shorten the time (still not the same) was to move the RadeCache for the streamed applications to the virtual desktop’s D Drive, which is persistent across reboots. That means the application cache stays put and is reused for subsequent launches. Of course it still isn’t as fast as installed because streamed applications also validate the application cache is correct. |
| Q: how did you design HA for PXE services A: You will need redundancy in your DHCP environment. Unfortunately, DHCP can only give you 1 address for the TFTP server. If we integrate NetScaler VPX into the environment, we can perform load balancing for the TFTP server. So with 1 IP address we automatically balance across X number of TFTP servers. And NetScaler is smart enough to know when TFTP is down and it will not forward requests onto i |
| Q: Virtualization of PVS. How many workloads is the cutover between PVS virtual and PVS physical. I guess 2000 desktops = physical PVS , @40 XenApp servers = Virtual PVS is ok? Can you comment ..ta A: No good answer, unfortunately. Can you virtualize PVS… Yes. Do we recommend it? Not for large, enterprise deployments. Most people agree that server virtualization makes sense for workloads that do not fully consume a system resources. PVS does not fit as it will utilize your NIC to the fullest. Putting PVS on the hypervisor offers little benefit. However, for small deployments, 200 virtual desktops, you won’t fully utilize the NIC and might be able to consolidate some servers |
| Q: How can you figure out network overhead on your environment using PVS streaming to XenDesktop host A: Testing PVS is bursty. You only get traffic when you need more of the vDisk. When you do your pilot, you can look to see how much network traffic PVS is generating for a XenDesktop virtual desktop. Some guidelines are as follows: 1 Gbps NIC should be able to support 500 virtual desktop streams. Booting Windows 7 requires roughly 200-230 MB of data across the wire. As you use Office, 300 more MB is transferred (assuming you are using PowerPoint, Word and Excel). Once that data has been transferred, utilization drops until you need more of the vDisk. Although it is bursty, you need to have enough capacity (bandwidth) to support your storms (boot, logon, logoff) |
| Q: what was the plan for fault tolerance on the virtual desktops if using local storage? A: Users log onto another virtual desktop. If we assume the desktops are throw away machines, then there should be nothing relevant for the user. Their files, data, and personalization should be on a network share and not on the virtual desktop. If the server fails, a user just connects to a new virtual desktop |
| Q: What kind of impact do techs like WAAS and Riverbed have on this type of network traffic? A: Not certain. The challenge technologies will have is HDX is encrypted. In order for these devices to do caching/compression, they must be able to decrypt the traffic. Once the optimization solution can read the HDX packets, it can then compress not only within a single session, but across perform cross-session compression for users within the same office or school. But then before the packets are placed on the WAN, the traffic must be re-encrypted to protect the data. |
| Q: You actually assumed no dial-up?!? Nice neighborhood. A: There will be dial-up, but just not from the schools. Students can dial into their ISPs or connect via DSL or cable modem and get access to the environment remotely. This means we will want to optimize the HDX protocol for low-bandwidth situations, like those dial-up users |
| Q: What RAID type for the Virtual Desktop servers? A: RAID 10 (1+0). We have 8 spindles on each hypervisor that will support the virtual desktops. This allows us to not require the use of a SAN because 8 spindles should allow for enough IOPS to support the expected virtual desktop load. RAID 10 gives us fault tolerance, but without the huge write penalties we would get with RAID 5. |
Building a virtual desktop is simply a matter of installing the Windows operating system. Right? Slow down… although this will work, it won’t give you the best performance and scalability. One of the items that many people mistakenly forget to accomplish is to optimize the base operating system. This is the 7th mistake out of the top 10 mistakes made with virtual desktops:
10. Not calculating user bandwidth requirements
9. Not considering the user profile
8. Lack of Application Virtualization Strategy
7. Improper Resource Allocation
5. Managing the incoming storm
Most people spend time creating a customized standard operating environment for their desktop operating systems. This often involves specific location settings, default application settings, and desktop descriptions. However, when delivering an operating system into a virtual desktop, many organizations do not go far enough to optimize the desktop for the virtualized environment. Whether the desktop is a hosted VM-based VDI desktop, a local streamed desktop or a hosted shared desktop, certain optimizations allow the hardware to focus on user-related tasks as opposed to extraneous system-related tasks. The following are examples of virtual desktop optimizations:
- Disable Last Access Timestamp: Each time a file is accessed within an operating system, a time stamp is updated to identify when that file was last accessed. Booting up an operating system accesses hundreds and thousands of files, all of which must be updated. Each action requires disk and CPU time that would be better used for user-related tasks. Also, if Provisioning services is used to deliver the desktop image, those changes are removed when the desktop is rebooted.
- Disable Screen Saver: Utilizing a graphical screen saver consumes precious memory and CPU cycles when the user is not even using the desktop. Those processes should be freed and used by other users. If screen savers are required for security purposes, then simply blanking the screen should be invoked as this does not impact the memory and CPU consumption.
- Disable Unneeded Features: Windows 7 contains many valuable components like Media Center, Windows DVD Maker, Tablet PC Components, and Games. These applications are memory, CPU and graphics intensive and are often not required in most organizations. If these components are made available to users, they will be used. It is advisable to remove unneeded services before deploying the first images.
These are only a few recommendations, but it is obvious that optimizations have a major impact on the virtual desktop environment. I’ve started building a list of optimizations for virtual Windows 7 desktops, which can be found in the [Windows 7 â€] section of the Virtualize My Desktop site. If you are looking to optimize Windows XP, then you can find that in the Windows XP Optimizationdocument.
Stay tuned for more.
Daniel – Lead Architect – Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
My Blog: Virtualize My Desktop
Questions, then email Ask The Architect
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.
All I want is a list of documents that will help me design my XenDesktop environment. Who else wants the same thing? I bet many of you are saying “Yes, Me too!!” That’s great and everything but how do you know when a new white paper is released that relates to XenDesktop design? Do you keep your own personal library of white papers for XenDesktop design? And even more, how do you keep informed when updates are made to previously released white papers?
I’ve got a special treat for you, the NEW XenDesktop Design Handbook. Instead of trying to create a 1,000 page document that discusses all of the different design options and best practices, we are creating a kit for XenDesktop architects. In the kit you will find some goodies:
- Reference Architectures
- Reference Designs
- Implementation Guides
- Planning Guides
This is just the start. If you subscribe to the kit, you will be able to receive notifications when updates are made to the Design Handbook. We are in the process of developing many new best practice documents focused on different design areas that you won’t want to miss. Interested yet? Then how about I give you the link to the NEW XenDesktop Design Handbook (you must log on to MyCitrix).
Daniel – Lead Architect – Worldwide Consulting Solutions
Twitter: @djfeller
Blog: Virtualize My Desktop
Questions? Email Ask The Architect
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.
Someone save me from antivirus. Did you read that correctly? I said save me from antivirus.
Odd isn’t it? Anti-virus is there to protect us, but we also need to be protected from antivirus. Antivirus solutions are critical, even in a virtual desktop environment. Many people believe that because a hosted VM-based virtual desktop image is created from a real-only image that they are immune from virus. That is only partially true. When you reboot, the virus goes away because the changes to the base image are destroyed (including the virus), but what about that time period between getting infected and the next reboot? Those few hours are dangerous and it is why antivirus is takes up the number 6 spot in the Top 10 Mistakes to Avoid with Desktop Virtualization:
10. Not calculating user bandwidth requirements
9. Not considering the user profile
8. Lack of Application Virtualization Strategy
7. Improper Resource Allocation
If using hosted shared desktops or hosted VM-based VDI desktops, those virtual desktops are located within the data center with other critical systems. If a virus made it into the data center, the entire infrastructure is at serious risk. However, simply adding an antivirus solution to the virtual desktop can protect the environment. So what’s the big deal? Just do it right? Well, nothing is as simple as one expects it to be. Antivirus can have a major impact on the virtualization infrastructure, and even cause users to experience poor virtual desktop performance, if done improperly.
If the virtual desktops are streamed with Provisioning services, and those desktops start a full system scan at roughly the same time. Provisioning services only streams the portions of the disk image that are required. However, if a full system scan is done, those virtual desktops will eventually request the entire vDisk image. This not only overwhelms the network and Provisioning services, but also impacts the storage infrastructure as the write cache is utilized and explodes in size. Overcoming these issues is a fairly easy matter and is based on the following recommendations:
- The desktop image must be free from viruses. It is recommended to do a full system scan in private image (read/write) mode. This guarantees the image is clean.
- When the desktop image is in standard mode (read-only), the antivirus should be configured as follows:
- Only scan create/modify activities of files
- Scan on write events only
- Scan local drives only
- Exclusions
- Pagefile
- Print Spooler directory
- Write cache file
- EdgeSight database
- ICA client’s bitmap cache directory
- Remove the antivirus configurations from the HKEY_LOCAL_MACHINE\Software\Microsoft\Windows
\Current Version\Run registry key
- Reconfigure antivirus so that the virus definitions file is stored on a persistent diskso antivirus doens’t have to download the entire definition file on each startup.
These will help overcome antivirus headaches.
Daniel – Lead Architect – Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
My Blog: Virtualize My Desktop
Questions, then email Ask The Architect
Over the last year, you’ve probably heard a lot about how Citrix and Microsoft are working together to on desktop virtualization and also how Citrix and Intel are partnering in this space. Have you wondered how the three companies are working together?
Get your answer to this question and many more at this upcoming webinar featuring speakers from Citrix, Microsoft and Intel. The webinar will discuss desktop virtualization strategies from thethree companies and introduce the benefits of our joint solutions.
Register for the webinar today!
Date: Wednesday, June 30, 2010
Time: 8:00 AM – 9:30 AM PDT
What would you say if I were to tell you that migrating to a virtual desktop was no different than if you were going to migrate to Windows 7? I’m being serious. Migrating a user to a virtual desktop has many similarities to migrating a user to Windows 7 on a traditional desktop. With a Windows 7 migration, we are concerned with hardware, operating system, applications, personalization, and more. With a virtual desktop migration, we are focused on hardware, operating system, applications, personalization and more. Same focus areas. Interesting
Of course there are some differences. For example, regardless of the path you are taking, most organizations will create their “Corporate Desktop Image”. At its core, the standard desktop image would have similar configurations like removing games, disabling Media Center, adding anti-virus software, etc. This would be done if Windows 7 were on a traditional desktop or on a virtual desktop. But on the virtual desktop we will likely do more. We will likely do things like:
- Disable unused Windows services
- Modify the behavior of the De-fragmentation subsystem
- Disable the Background Layout Service after it has executed once
- Clean and optimize the image before deployment
Not only that, but with a virtualized Windows 7 environment we will also modify certain aspects to provide greater responsiveness for the user. These are important in certain FlexCast instances where the user is not sitting in front of the Windows 7 desktop. What optimizations am I talking about? How about the shadow of your mouse? Did you even know your mouse had a shadow. Honestly, I didn’t. But simply disabling this little feature can provide greater responsiveness for the user.
These are the things I’ve been gathering from our Windows 7 deployments. These lessons learned will help you on your way to Windows 7. These are the things I am excited to be discussing during my BriForum session next week in Chicago. I hope to see you there. If you can’t make it, then we will have to continue the Windows 7 migration on this community site or on the Virtualize My Desktop site where I’ll have a Windows 7 Migration Resource Center that will cover lessons learned, tips/tricks, and best practices.
Daniel
Lead Architect – Worldwide Consulting Solutions
Follow Me on twitter: @djfeller
My Blog: Virtualize My Desktop
Questions, then email Ask The Architect
Facebook Fan Page: Ask The Architect



