I attended an interesting session at Citrix Synergy earlier today. It was conducted by Ron Oglesby, Chief Solution Architect of Unidesk, and the subject was why desktop virtualization has not taken off like server virtualization has. This is something I’ve wondered about myself, so I was eager to hear someone else’s view on the subject. Since a lot of the points he made could also be classified as “things to watch out for,” I thought others might also find it interesting.

First of all, it is important to recognize that “Virtual Desktop” does not equal “VDI.” (And by “VDI,” I mean turning your physical PCs into virtual machines that are running on some kind of hosting infrastructure, such as VMware, XenServer, or Hyper-V.) VMware has done a pretty good job in many cases of framing the conversation as though these terms were equivalent, because VDI is what they do, and it’s in their best interests to frame the conversation that way. Hats off to them for the degree to which they’ve accomplished that.

But VDI is just one form of desktop virtualization. The fact is that we’ve been virtualizing desktops since the debut of WinFrame a decade and a half ago. And it can be argued that XenApp is still the most cost-effective way to virtualize a desktop. I can pretty much guarantee that, on a given piece of server hardware, I can support more concurrent users with XenApp than I can by building individual virtual PCs.

But what seems to be happening in some cases is that management has seen the tremendous cost savings that have been achieved through server virtualization, so they decide that they should virtualize desktops the same way they virtualized servers, expecting that they will see the same kind of dramatic cost savings. Often, they are painfully disappointed.

Dramatic cost reduction through server virtualization is a no-brainer. You take a bunch of servers that are already in the data center, most of which are probably idling along at less than 10% processor utilization (if that), and consolidate them onto a smaller number of servers. You save space. You save power (both the power it takes to run the servers and the power it takes to cool them). You gain agility and fault tolerance through things like live motion technology. The CAPEX (capital expenditure) savings are obvious. You can probably show a positive return on investment in the first year.

Near-term CAPEX savings are almost impossible to show in a VDI project, because of the back-end infrastructure you have to put in place to host your virtual desktops. (Note that we’re talking here specifically about VDI as I defined it earlier in this post.) Your savings are primarily in ongoing operating expenses, and (according to the Burton Group in a different session I attended) it may take as long as 3 – 5 years to see a significant ROI. Beyond that, you’re talking about things that are very hard to quantify at all, such as the benefit of giving your employees the flexibility to be productive from anywhere. Great idea, difficult to quantify.

Unless you are using some kind of tool that will let you provision multiple virtual desktops from a single shared image, your storage costs are going to skyrocket, because you’re replacing cheap SATA storage on the desktop with expensive SAN storage in the data center – and a Windows 7 image with all the apps on it can easily run 30 Gb. Moreover, the way a desktop OS uses storage is completely different from the way a server uses storage. Your typical Windows server probably averages about 5 IOPS (Input/Output Operations Per Second), with a read/write ratio of 2:1 to 3:1 (more reads than writes). A Win7 system averages more like 30 IOPS, and the read/write ratio is just the opposite.

In other words, workstations aren’t servers, and they won’t behave like servers just because you move them into your data center and put them on a SAN, and therefore you can’t treat them as though they were servers. If you do, you probably won’t be happy with the result.

Finally, although IT guys love standardization, users don’t. They’re used to being able to personalize their personal computers, and they won’t easily give that up. And they definitely won’t be happy if all of the personalization they’ve done suddenly disappears when you replace their PCs with virtual desktops. Unfortunately, there is no magic wand you can wave that will transform a bunch of diverse PCs that have been highly personalized into a single shared image while still preserving all of the personalization. There are some tools that will help you with this, but you have to plan, you have to test, you have to be careful, and you need to have a roll-back plan.

So does this mean that desktop virtualization is a bad idea? No, not at all. It does mean that you need to take the time to understand your users, and come up with a desktop strategy that encompasses all of your use cases. And you need to recognize that classic VDI is probably not a “one-size-fits-all” solution for all of your users:

• Task-based workers (e.g., call centers) are probably very well served by “Hosted Shared Desktops,” a.k.a., virtual desktops running on XenApp servers.
• Remote workers may also be covered by Hosted Shared Desktops, although those who need more power, or need the flexibility of a dedicated OS, may be well served by a hosted virtual PC – traditional VDI. For example, a contract programmer may be a continent away, and may need the ability to do things that cannot be done on a shared server OS, like modifying the registry or rebooting the system, but the employer may also want the security of knowing that the code never leaves the datacenter. VDI is a perfect solution for this use case.
• Office workers may be served by hosted virtual desktops (VDI), but could also be served by streaming the PC operating system from a central shared image directly to the PC hardware on their desks. Managing that central image beats running around to all the desktops with a backpack full of CDs to do your upgrades!
• Power users who might, for example, need the power of a dedicated 3D graphics processor might be best served by streaming a central shared image to a blade PC in the datacenter, which the user then accesses via a thin-client desktop device.
• Mobile users, by definition, need to work when they’re not connected to the corporate network. This is the use case addressed by XenClient.
• In all of the cases above, having a provisioning tool that allows you to boot and run multiple systems from a single shared image is going to save you a bundle on storage.

The cool thing about XenDesktop 4 is that you can handle all of these use cases, and mix and match the best virtual desktop deployment method to each group of users, and they’re all included in your XenDesktop 4 Enterprise or Platinum license. No other vendor offers that flexibility.

I am a big fan of Storage Area Network (“SAN”) technology. SAN technology offers high performance, highly flexible storage for Physical and Virtual Systems and is particularly valuable to empower advanced features for virtualization solutions such as VMWare, XENServer, and Hyper-V Virtual Hosts to name a few. 

The moral of this story is that you need to know that SANs have some very different management requirements compared to traditional Direct Attached Storage (“DAS”).  Many if not most IT Staff in small to medium size organizations are most familiar with throwing hard disks into physical servers in single or RAID configurations.  Now that they are are purchasing and deploying SAN technology we find that many problems occur if they do not fully understand how to implement and manage these new beasts. 

I would suggest that the difference between DAS and SAN technology is similar in spirit to the difference between a passenger car and a high performance race car.  Most passenger cars are designed to be slower and more forgiving than race cars, if you get into trouble it’s much easier for the average driver to recover.  Race cars will do many things that passenger cars won’t, but if you push them too far you will require very specific skills to recover or you will spin out of control.  SANs are in my opinion similar to this analogy, they will do many things that DAS won’t but if you don’t design and manage them properly you may quickly find yourself in spinning out of control. 

Here are a couple of things you need to know.

1. Most popular SAN’s offer some impressive features such as “Thin Provisioning.”  Thin provisioning is one of those features that you will absolutely love, that is, until you don’t.  Thin Provisioning is a feature that allows you to provision gobs of storage – more, in fact, than you actually have – to Physical and Virtual Systems.  For example, you might have a SAN with 2 terabytes of physical storage, but then “provision” 10 individual 2 terabyte “volumes" and present them to your physical and virtual servers.  Your servers will see this as a combined total of 20 terabytes of storage. This is great but requires you to be very careful.  The reason is that you have offered 20 terabytes of “Virtual Storage” but of course you really only have 2TB of actual or “physical” storage.  So while your systems believe there is 20TB of available storage you have to insure that you do not attempt to put more than 2TB of physical data on this system or bad things will happen. 

   What bad things? Well in most cases once you fill up the physical space the volume will become unusable.  You must make sure you carefully monitor the system and pay close attention to it so that if you start reaching capacity, you’ll know in time to do something about it.  Our own SANs alert us when total available free space reaches 20%.  We have from time to time been between 70% and 90% utilization of our total capacity, and while everything is running just fine we know we have to watch this carefully.  If we hit 100% (intentionally or otherwise), the result could be catastrophic: the storage could immediately shut down and the recovery might not be quick. 

   This happened to a client last week. They started a backup, and when they realized that this was causing one of their thinly-provisioned SAN volumes to fill up to capacity, they immediately stopped the backup and deleted the data.  Unfortunately this caused the volume to fill to 100% and immediately shut down.  Fortunately this volume was mirrored to a second SAN and since there was a little more room on the mirror volume the workload actually stayed online until we could assist the client in recovering from this problem.  If the mirrored side had filled to 100% as well, the result would have been an immediate failure of a critical SQL server workload. 

   The client didn’t realize that copying all this backup data to a Windows Server VM would fill up the SAN volume, nor did they realize that simply deleting that data from the VM would not necessarily delete it from the SAN.  We were able to configure a new volume and replace the full half of the mirror with an empty volume, but only because their was some un-provisioned space available to use for this purpose.

2. And that brings me to my second point – which is that deleting data from a Physical or Virtual server that is using SAN storage may not in many cases free the physical space on the SAN.  Again, DAS is like the passenger car, if you over-commit your storage you can simply press the brake (a.k.a. delete key) and recover immediately. With SAN storage it is common that once the space is committed you may have to perform specific tasks to free up this space.  This task might require special tools or utilities, or even require adding more physical disks.  In extreme cases it may require that you remove and recreate the over-committed SAN Volumes, and that is time consuming and painful.  In this scenario an ounce of prevention is worth a hundred pounds of cure. 

   We have been running our SAN over-provisioned for years with no ill affects or degradation in performance…but we know we are “on the bubble” and we carefully monitor and maintain this situation.

So please be aware that SAN technology is wonderful, but its important to learn some new skills to keep the systems performing their best.

Tomorrow (May 5), at 17:00 GMT, all 13 root DNS servers on the Internet will begin using DNSSEC (Domain Name System Security Extensions) to reply to user requests. Here’s why you might care about this.

As most of our readers know, DNS is what translates the URL you type into your browser (like “www.manage-ops.com”) into an IP address (like “216.9.9.164”) that your computer can actually use to send packets of data across the Internet. If you have a Windows Server-based network, one (or more) of your Windows Servers is probably providing DNS services to the users on your network. But the DNS server on your network doesn’t automatically know where everything is. If it needs to resolve an address that doesn’t happen to already be in its local cache, it has to ask some other DNS server out on the Internet. Sometimes those queries go all the way to one of the root servers.

It’s been recognized for quite some time that the existing protocol used for DNS queries isn’t entirely secure. Therefore, the international standards bodies have been working on a more secure standard, which is DNSSEC. DNSSEC uses digital signatures to authenticate DNS responses, so your computer knows the response actually came from an authoritative DNS server.

So what’s the problem? The potential problem is that those DNS responses will arrive in significantly larger data packets than before. Specifically, rather than using UDP packets that are smaller than 512 bytes, the responses will not only be longer, but may be broken into multiple TCP packets. Some routers and firewalls specifically inspect DNS traffic to look for anomalies, and if you have older equipment that doesn’t know about the DNSSEC standard, these changes may very well look like anomalies, and be blocked. That would mean that your DNS clients or DNS server would not be able to communicate with the public root DNS servers, and that would mean that you would start having problems resolving DNS.

These problems may be intermittent in nature at first, because some DNS requests may be able to be resolved by using locally cached information…but DNS records typically have a “time to live” built into them, so eventually the cached information will expire and have to be refreshed. So if you do have a problem, it’s likely to get worse with time.

There are some tools available to help you determine whether you’re likely to have a problem. If you’re comfortable using a DNS query tool like dig (which is a command-line query that can be run from most unix or linux systems), you can find instructions on using it at https://www.dns-oarc.net/oarc/services/replysizetest. If you don’t have access to a unix or linux host, or don’t feel comfortable using such a tool, you can download a Java utility from http://labs.ripe.net/content/testing-your-resolver-dns-reply-size-issues, and run it on any system with Java run-time installed (which includes most Windows systems). Just download and save the file, then double-click it.

Watchguard customers should note that if you have a Watchguard Firebox or XTM appliance with current firmware, you should not have any issues with these new DNSSEC packets.

I recently implemented both the new Citrix Access Gateway (CAG) VPX and the Branch Repeater VPX within our development lab. Both are “virtual appliances” designed to run directly on a XenServer host. Both are impressive products and work great – in fact, we can use “live motion” to move the CAG between XenServers while running video in a XenDesktop session with not even a pause in the video playback. The CAG moves with no interruption in service. NONE!

But this isn’t just a post to sing the praises of the virtual appliances. Rather, it’s about LICENSING!!! Specifically, licensing the Branch Repeater VPX.

As with many Citrix products, obtaining the license and getting it properly installed is not necessarily easy and intuitive…and in many cases (particularly with new products), we’ve found that the Citrix licensing support team does not know all the ins and outs of licensing a specific product either. That is not intended as a slam on this team. They do the best they can – but Citrix is a big company now, and sometimes it takes a while for information on new products to filter down to the front-line troops. In this case they worked with me for quite some time until we got this figured out (so there is at least one guy on the Citrix support team who now knows how this works).

So…now that I’ve gone through the pain, I thought I’d try to spare you from it if I can. (You’re welcome.)

One complication you’ll encounter is that, depending upon what you’re attempting to accomplish, these appliances may require one license or two. For example, with the CAG, if you are only going to use it for running secured sessions to a web interface (the equivalent of the legacy Citrix Secure Gateway) then you only need a “platform license.” However, if you also plan to run SSL VPN sessions though the CAG, you will need Access Gateway Universal licenses for your users, which will be rolled into a second license file.

Access Gateway licensing isn’t new and it’s pretty well understood. But what about the Branch Repeater? Just as with the CAG, the Branch Repeater may require one license or two, depending upon the functionality you need. If you are going to use the Branch Repeater VPX to connect to another (physical or virtual) Branch Repeater then you only need a platform license. However, if you want to take advantage of its ability to support client PCs that use the Branch Repeater Plug-in, you will need a second license to enable that feature. So we finally come to the topic of this post: how do you get the license file(s) onto your new Branch Repeater VPX?

First, you must log onto the “MyCitrix” web site with your account credentials, and access the Licensing Tool Box to activate and allocate the license. That part of the process is well documented, and if you’re a Citrix customer, you’ve probably done it at least once. The tricky part is what you have to do to download the VPX license file, what you need to enter in the Repeater itself, where to put it, and what you should see.

Here’s what we learned (NOTE: Click on any graphic to view full-sized):

1. On the Branch Repeater VPX Web-based management interface, access the “Manage Licenses” screen, and in the right panel, choose “local” as shown below, and click the “Apply” button.
   
   

   License Server Configuration

2. Then click on the “License Information” tab and you will see something similar to this next image. What you will need from this screen is the “Local License Server Host Id:” Write down this information – you will need it in the next step.
   
   

   Information Used for License Management

3. Now you can download the license file from your “MyCitrix” portal. Save it to your PC, and make a note of where you saved it. As part of the process of downloading the license, you must enter the license server ID. Traditionally, you would enter the name of the Citrix license server in this field (and it was case-sensitive, which tripped up a lot of users). But in this case, the system is expecting the MAC address of the Branch Repeater VPX itself…which is what you just copied in Step 2. Another difference is that in the past the License Server Host Type was always set to “HostName.” However, there is now a drop down box with a second choice, “ETHERNET.” For the Branch Repeater VPX, you want to select “ETHERNET,” and then enter the host id that you wrote down in Step 2:
   
   

   Downloading the License File from MyCitrix

   
   In case you’re wondering, the MAC address we’re using is the address of the first interface on the Branch Repeater VPX, as displayed in XenCenter. If you want to find it in XenCenter click on the VM in the left column and then select the Network tab in the right window and you should see it there:
   
   

   XenCenter Display

4. Now that you have your license downloaded to your local PC, you need to add it to your Branch Repeater. Access the “Local Licenses” tab and click the Add button (note that you will not see all the content in the window as shown here until you’ve added your license):
   
   

   Local Licenses Display

   
   After you click Add, this screen will appear and you will need to browse to the location where you saved your license file, and click the “Install” button:
   
   

   Add License

   
   Now the “Local Licenses” tab should be populated with content:
   
   

   Local Licenses Display

   
   Next, go to the “Licensed Features” tab. You should see your features listed as shown below:
   
   

   Licensed Features

5. As mentioned earlier, if you plan to support client PCs that have the Branch Repeater Plug-in, you will need another license to enable this feature. Once again you will need to go to your MyCitrix portal and follow the same procedure as you did for your platform license to obtain the Plug-in license. Once you have the Plug-in license you will need to add it to the Virtual Appliance in the same manner as you added the platform license. Once that’s done, if you click the down arrow under “Local Licenses” you will see both licenses:
   
   

   Manage Licenses Screen

   
   Finally, if you click the “Licensed Features” tab, both licenses should show up with the number of licenses available:
   
   

   Licensed Features

This should be all you need to get the Branch Repeater VPX licensed. Now you just need to get it configured correctly… but that’s another blog post.