SAN, VDI and SMB


One of the big questions regarding virtual desktops is storage. In fact, I’ve discussed this numerous times (here and here and here). This has mostly been with a focus on IOPS. This time I want to focus on the high-availability aspect you get with shared storage, but with the focus of being on the SMB/SME space (small to medium business/enterprise). If you want to do live migration, you must have shared storage. So, let me get straight to the point… You don’t need it. You don’t need XenMotion, vMotion or live migration in a SMB hosted VM-based desktop model. Look at the XenDesktop architecture and let’s focus at the component-level.

  1. Virtual desktops: Desktops are not servers. They aren’t as critical and shouldn’t reflect a higher cost. If the physical server fails, users simply make a new desktop connection.
  2. XenDesktop controller: Always, always, always implement redundant controllers. XenDesktop is smart enough to use a second controller if the primary fails. Is also worthwhile to put intelligent load balancing in front to catch other types of issues that don’t result in complete failure.
  3. Web Interface: Again, use redundant servers, but you need to provide intelligent load balancing so if one fails or goes off into La La Land, you won’t be directed to a bad server.
  4. NetScaler VPX: This is providing our intelligent load balancing mentioned for XenDesktop controllers and Web Interface. Again, implement redundant VPX’s. If you configure these in HA mode, a failure in one means the other one takes over automatically.
  5. Data Store: You can function without the data store, but you can’t make changes. Why not simply create snapshots and revert if needed. Or backup the database and restore if needed. You can even automate this if you want.
  6. License Server: You can function without a license server for 30 days (grace period). If the server is blown up, just rebuild the server and download your licenses (I’d also suggest you figure out why your server is blowing up).
  7. Provisioning Services: If one server fails, the other one takes over the streams automatically. The target desktops might experience a delay during the failover, but they won’t lose anything.

So I ask you, why spend money on SAN storage for virtual desktops in the SMB world if it is just going to cost you more money? Keep it simple

Advertisements

Desktop Virtualization for the SMB


I’ve been part of quite a few desktop virtualization designs in my day. Most of these are for enterprise customers with over 10,000 desktops. When you get to this scale, you have to take into account so many different variables that you need many different options. What about the SMB organizations? The smaller organizations (500 or fewer desktops) probably don’t need as many options and flavors of virtual desktops. In fact, one can create an architecture that meets the needs of the SMB but without all of the components and features. See for yourself by accessing the XenDesktop Design Handbook.

Over the next few weeks, we will have a discussion on this exact topic. What are the design decisions? What are the ramifications of doing and not doing application virtualization? What is the critical path to success? Stay tuned and keep watching the SMB space on the Virtualize My Desktop blog for a great discussion.

Daniel – Lead Architect

Virtual Desktop Mistakes Conclusion


The virtual desktop top 10 list is complete! Of course there are numerous things people can do to mess up their environment, but the 10 discussed are probably the 10 most critical. If you get them wrong, you will struggle to survive.

But the list doesn’t end there. My colleagues (Tarkan Koçoglu, Nicholas Rintalan and Doug Demskis) and I couldn’t limit ourselves to just 10 mistakes which is why we have honorable mention status to a few more items J. It’s our way of keeping the top 10 list while allowing ourselves some leeway. Besides, Top 10 is so much better than Top 13 or Top 19 (top 10 has worked for David Letterman for years).

So what are these honorable mentions I speak of?

  • NIC Teaming: Provisioning services streams the desktop image to the virtual desktop. Provisioning services NICs should be teamed for throughput/aggregation and not just for failover/redundancy.
  • NIC Optimization: Although Provisioning services can run with the default NIC configurations, the environment can run faster with optimizations like Disable Large Send Offload
  • Common Image: Reducing the number of images helps simplify management and updates as fewer image updates are required. However, using a single image across multiple physical end point platforms can become difficult to maintain. Specific hardware drivers can potentially conflict and installing multiple device drivers results in image bloat. It is often better to create different images for different hardware (not applicable if the end point is virtualized).
  • VDI for Wrong Reason: Organizations should do virtual desktops because there is a business reason to provide users with a Windows XP/Windows 7 desktop interface. Without a business reason, the virtual desktop solution will be seen as extravagant and costing too much money for no value.

That completes the current Top 10 list and honorable mention for virtual desktop mistakes. If you want, you can see the entire blog series via the Top 10 Virtual Desktop Mistakes link. If you prefer documents, then sign up for the XenDesktop Design Handbook where you will get the Top 10 list plus so much more.

Enjoy and good luck

Daniel – Lead Architect

Virtual Desktop Bandwidth – Revisited


Back in May 2010, I started my Top 10 Mistakes Made with Virtual Desktops. I talked about how much bandwidth certain activities require when using XenDesktop and HDX. The table I provided is great, but it does pose the question, “What does a person do with this information?” Since then, I’ve been able to spend more time and have recently completed the bandwidth planning guide, which you can get by accessing the XenDesktop Design Handbook. But let’s take a closer look at what the planning guide says…

First, we have a list of bandwidth requirements for certain activities (Office work, Internet activities, Flash rendering, WMV videos, etc). I can simply use the following formula to create my average bandwidth consumption:

Estimated Bandwidth=(OfficeBW*%ofTime)+(InternetBW*%ofTime)+(PrintBW*%ofTime)+(FlashBW*%ofTime)+(StdVideoBW*%ofTime)+(HDVideoBW*%ofTime)

The formula works great, BUT it is an average for 1 user. The whole concept of averages is that most of your users will be doing activities that require smaller amounts of bandwidth while a few will consume more.  By averaging them all out, we create a buffer. Let me show you what I mean. First, think of a single user’s day and calculate how much time they spend doing certain activities:

  • Office-based: 4 hours
  • Internet: 1 hour
  • Printing: 15 minutes
  • Flash Video: 30 minutes
  • Standard WMV Video: 10 minutes
  • HD WMV Video: 5 minutes
  • Idle: 3 hours (one hour lunch and two, one hour meetings)

If I use this scenario, the user will require and average of 78Kbps of bandwidth, (43kbps or less for low end and 1812 kbps for high end). If I average this out across hundreds of users within a site, I have a small safety net for those few users who are watching videos.  Unfortunately, because the difference between low usage and high usage is so great, very few users can simulatanously consume high levels of bandwidth before the experience fails.

Hopefully, I’ve explained the dangers of using averages, but that begs the question of how to plan bandwidth requirements.

  1. Start with the averages. That is your baseline.
  2. Define a burst level of required bandwidth. Chances are high that not all users will be watching HD WMV video at the same time. So by creating a 20% safety net (just an example, your safety net will differ) on top of our average bandwidth calculation, we should be able to provide users with acceptable performance, even when watching videos.

Hopefully, this sheds some light onto planning your XenDesktop environment.

Don’t forget to get this planning guide and many others in the XenDesktop Design Handbook.


Daniel – Lead Architect

Optimize Windows 7 Visual Effects for Virtual Desktops


Some of you might be aware, others might not.  Did you know that the mouse icon in Windows 7 (and earlier versions) has a shadow?  I bet a bunch of you are looking for it now. It is hard to see, but it is there.  Something that most people wouldn’t recognize as being on or off can have an impact on how much bandwidth is required for a virtual desktop.

Citrix XenDesktop and HDX are smart enough to not send the screen updates for the mouse image to the endpoint, instead they just send coordinates.  Saves a lot of time if you think about how many pixels the mouse takes.  But if you enable the mouse shadow (which is enabled by default), we are talking a different story.  The shadow pixel changes must be sent across the wire because it isn’t just a shadow, it is a blending with the image on the screen.  If you truly are interested in optimizing your Windows 7 desktop virtualization images, then disable the mouse shadow.

It’s pretty easy to do Continue reading Optimize Windows 7 Visual Effects for Virtual Desktops

Improper Storage Design for Virtual Desktops is a Killer


I’ve spent the last month or so discussing the top 10 mistakes seen on desktop virtualization implementation so you can learn from other’s mistakes. I’ve discussed 9 different things so far and they were:

10.  Not calculating user bandwidth requirements

9.    Not considering the user profile

8.   Lack of Application Virtualization Strategy

7.  Improper Resource Allocation

6.  Protection from Anti-Virus

5. Managing the incoming storm

4. Not Optimizing the Desktop Image

3. Not using your Cache Wisely

2. Using VDI Defaults

And now it is time for the #1 thing that people mess up with desktop virtualization? Continue reading Improper Storage Design for Virtual Desktops is a Killer