We’re only changing our name. The Moose Logic team will not be changing. This means that our customers will be working with the same sales team and the same professional services team that they’ve come to know and trust. We will have the same dedication to providing excellent solutions based on Microsoft and Citrix technologies, built to recognized industry best practice standards, and supported by world-class engineering talent. There will be no changes to any service contract that is already in place with us: the services we’re delivering will be the same and so will the cost.

Our phone numbers will remain the same and shortly we will switch to VirtualQube.com email and web addresses. Please visit our new Web site at www.VirtualQube.com.

Now don’t get me wrong – the ability to live migrate a running VM from one virtualization host to another across the network with no shared storage behind it is pretty cool. But if you read through the blog post, you’ll also see that it took 8 minutes and 40 seconds to migrate a 16 Gb VM. (And I don’t know about you, but many of our customers have VMs that are substantially larger than that!) On the other hand, it took only 11 seconds to live migrate that same VM running on the same hardware when it was in a cluster with shared storage.

So I will submit that the answer to the question posed in the title of this post is “No” – clearly, having shared storage behind your virtualization hosts brings a level of resilience and agility far beyond what Shared Nothing migration brings. Still, for an SMB that has a small virtualization infrastructure with only two or three hosts and no shared storage, it’s a significant improvement over what they’ve historically had to go through to move a VM from one host to another: That has typically meant shutting the VM down, then exporting it to a storage repository that can be accessed by the other host (e.g., an external USB or network-attached hard drive), then importing it into the other host’s local storage, then booting it up…that can easily take an hour or more, during which time the VM is shut down and unavailable.

So Shared Nothing migration is pretty cool, but, as Rob Waggoner writes in the TechNet post linked above, don’t throw your SANs out just yet.

Note that nothing has changed for XenApp on Server 2003. If you’re still running Presentation Server v4.5 or XenApp v5.0 on Server 2003, you should be planning to upgrade as soon as possible, because we’ve already moved past the “End of Maintenance” date (which was September 30). That means that no code maintenance is being done other than for serious security vulnerabilities. “End of Life” hits next March 31, at which time there will be no support available at all from Citrix unless you want to buy “Extended Support” – and, trust me, you really don’t want to buy Extended Support.

Extended support is a cool $100,000 for six months, regardless of how many licenses you have, and that’s in addition to a Premier Support agreement, which you must also have on your XenApp licenses (at a cost of $35/year/license) before you can buy Extended Support. It is deliberately priced at such a painful level to discourage you from buying it. Citrix really, really doesn’t want to support products that are beyond their End of Life dates.

The good news is that End of Maintenance for XenApp v5.0 on Server 2008 has now been extended to July 13, 2014, and End of Life to January 13, 2015. (Why the dates fall in the middle of the month seems puzzling, but there it is.) That’s good for customers who still need to support apps that just won’t run on a 64-bit platform – you’ve got a little more time to plan your transition.

The same dates apply to XenApp v6.0 on Server 2008 R2…but if you’re running Server 2008 R2, there’s really no reason why you shouldn’t be on XenApp v6.5, and we’d recommend that you go there as soon as possible.

If you want to see the full announcement with all the dates, you can find it in the Citrix Knowledge base – it’s article CTX122442.

Dedicating a VM to every user consumes a lot of storage space – and, even though local storage on a ViaB server is not as expensive as SAN storage, it’s still more expensive than the storage on a desktop PC. Plus you still have the same headaches of managing and updating every individual PC. That’s why we prefer to provision virtual desktops from a common master image. It takes up far less disk space, and when you update your master image, all of the virtual desktops that are provisioned from that master image get updated the next time they reboot.

On the other hand, since the master image is a read-only image, the user has no ability to make persistent changes to the VM. In a Citrix environment, we generally handle this by using the Citrix Profile Management tool (which is included with ViaB), which allows us to write user profile changes to a shared folder somewhere else on the network, so that unique user profile data will survive changes to the underlying master provisioning image.

But there’s only so much you can do with user profiles – and one of the things you can’t do is allow users to install their own applications. Personal vDisks, which were first introduced in XenDesktop v5.6, are intended to give you the best of both worlds, by creating a persistent virtual disk that is unique to the user and that is, in simplistic terms, merged with the provisioned image at logon time. The PVD can be used to store user-installed applications, user profile data, and even user files, if you wish. So you get to provision from a common master image and give users the personalization they want.

But there’s an interesting wrinkle in the way PVDs work in ViaB v5.1. One of the major selling points of ViaB is simplicity: you don’t need all the supporting server infrastructure that a full-blown XenDesktop deployment requires, and you don’t need shared storage. That, in turn, keeps the cost down. But while ViaB is smart enough to replicate your master desktop images to all of the servers in your ViaB grid, PVDs are not replicated across the grid. Instead, a given user’s PVD gets created on the local storage of whichever server in the grid that user happens to land on at first logon – and it stays there. ViaB will then insure that, for all subsequent logons, that user will be directed to the specific server that contains the PVD.

That’s a great solution…unless that server fails, in which case the PVDs on that server are no longer available, and their associated personal desktops are broken. In all of their presentations on ViaB v5.1, Citrix glosses over this point by stating that they recommend that you periodically back up the users’ PVDs, and that they have documented the steps required to do so. And they have. Here is the process for backing up and restoring PVDs, assuming that you’re running XenServer as your underlying hypervisor, straight from CTX134792 in the Citrix Knowledge Base:

• From the ViaB management console, look up the personal desktop that you want to back up. Note which server in your ViaB grid is hosting this desktop.
• Note the personal disk name of the personal desktop you are backing up. This will have an intuitive name like “Windows7x64p1386d2eaab7.”
• Insure that the personal desktop is shut down.
• Move to XenCenter (the management tool that comes with XenServer). From within XenCenter, navigate to the XenServer in your grid that is hosting the desktop, and use the XenCenter “Export” function to export a copy of that VM. Where will you export it to? Well, assuming that you don’t have shared storage, you’re going to have to export it to some kind of storage repository that the XenServer can see which you can later move to a different XenServer in your grid…like an external USB-attached hard disk.
• If the ultimate bad happens, and you have to restore the backed up PVD, you need to again fire up XenCenter, and navigate to a surviving server in your grid that you plan to use to restore service. Use the XenCenter “Import” function to import the VM from your backup storage repository.
• Once it’s imported, select the VM in XenCenter, and select the Storage tab. You will see that the VM consists of two disks, one of which will match the name that you made note of way back in step 2. “Detach” that disk from the VM, and then delete the VM. That will leave you with a virtual disk (your PVD) that is not associated with any VM.
• Now go back to the ViaB management console, select the “User Sessions” tab, and, under the “Actions” link for the non-functional desktop, select “Repair.” ViaB will scan the data stores of each server in the grid until it finds the PVD, and prompt you for confirmation that this is what you really want to do. When you confirm, ViaB will destroy the remains of the non-functional desktop, create a new linked clone on the server that now contains the associated PVD, and attach the PVD to the new linked clone. The user can now log in again.

Bear in mind that you will have to follow this manual backup procedure for every individual PVD that you have in your environment, and, likewise, if you ever have to restore PVDs, you will have to manually restore them one at a time.

Show of hands: anybody else out there think that this might be just a tiny bit onerous?

Now, if you do happen to have a SAN, you could attach a unique LUN to each server in your ViaB grid, and, provided you’re using Hyper-V or VMware as the underlying hypervisor, use that LUN for storing your master images and PVDs. (ViaB on XenServer does not support multiple datastores, according to http://forums.citrix.com/thread.jspa?threadID=312411&tstart=0.) Then you could conceivably move that LUN to a different server in your grid in the event of a server failure, and have all your PVDs back…although you still need to do periodic backups of the PVDs (maybe with SAN snapshots?), because it is possible that a PVD could get corrupted if the ViaB host goes down while the desktop OS is in the process of writing to the PVD. And, as we’ve said earlier, you’ve now negated one of the big advantages of ViaB – no shared storage requirement.

Here’s the bottom line, in my opinion: Until they come up with a way to automate the backup and restore process for PVDs, or, better yet, find a way to replicate PVDs across the grid, PVDs should be used sparingly (if at all) with ViaB. And do not use PVDs to store user profile data or user-generated files. Instead, use the Citrix Profile Manager to handle the profile data, and standard policy tools like “My Documents” redirection to direct user-generated files to a shared folder outside of your ViaB grid. That way, your worst-case scenario is that your user may have to reinstall whatever user-installed applications may have been lost when the PVD disappeared.

Finally, please note that these concerns are not applicable to a full XenDesktop deployment. With XenDesktop, you will have some kind of shared storage, and your PVDs will live on that shared storage. So: XenDesktop, PVDs are great; ViaB, not so much.

• Personal vDisks – This feature was introduced in the most recent release of XenDesktop, but until now was not available in ViaB. It pretty much eliminates the need to ever provision dedicated virtual desktops for anyone, because the personal vDisk can store user data, personalization information, and even user-installed applications that then get merged at logon time with the VM that’s provisioned from your master image. You can update your master provisioning image at will without affecting what’s stored in the users’ personal vdisks.
• Virtual IP – In prior versions of ViaB, users needed to explicitly point a browser at the IP address of one of the servers in your ViaB grid. If that server failed, they needed to explicitly point a browser at a different server in the grid. That obviously creates an opportunity for user confusion. The only way around it was to have some kind of load-balancer (e.g., NetScaler) in front of your ViaB grid. But with v5.1, your grid now has a virtual IP address. That virtual IP address is initially serviced by one of the servers in the grid, but if that server fails, another server will automatically take over.

There are several other feature enhancements, including tighter integration with the NetScaler-powered CAG Enterprise, support for HDX v5.6 Feature Pack 1, support for virtual desktops with multiple virtual CPUs, etc., and you can read all about them at the documentation link provided above. But the addition of personal vDisks and a grid-wide virtual IP address take care of what were, in our opinion, the two biggest things that ViaB was lacking compared to its big brother, XenDesktop. Well played, Citrix.

The LE1700 has been my primary computing system now for at least four years. It’s got an Intel Core2 L7400 CPU (1.5 GHz), and 4 Gb of RAM. It came with Vista pre-installed, but when Win7 was released, I was able to upgrade it with a minimum of driver hassles. The LE1700 has a completely detachable keyboard, and I have a docking station in the office and a docking station at home with full-size keyboards and monitors in each location, so the ability to move back and forth has been great.

The only down side is that it only has a 70 Gb hard disk. As time has gone by, that’s become more and more difficult to live with – and I finally bought a 32 Gb SD card (fortunately, it does have an SD memory slot) and moved a lot of infrequently-accessed files off the hard disk. This also made it difficult to do the Win8 upgrade, in that I had to move a bunch of additional data off the hard disk to free up enough space, then upgrade, then get rid of the resulting Windows.old folder, then move stuff back.

Other than that, the upgrade went pretty smoothly. There were a couple of older apps that I needed to uninstall before I could upgrade, but they weren’t apps that I particularly cared about. One surprise, though, was that it suggested that I uninstall iTunes. I did so, as I may be the only person left on the planet who has not purchased any music through iTunes – I installed it only so I could load music onto my infrequently-used iPod nano – so there was no down side for me in doing the uninstall.

One oddity had to do with the license key. Based on what I had read, I expected to be prompted to enter a license key as part of the installation – but I wasn’t. Then, once the installation was complete, I couldn’t find any way to install a license key so I could activate the OS. Ultimately, I had to go to a command prompt and use the “slmgr” (Software License Manager) utility. The syntax is “slmgr /ipk [your product key]” – that’s “ipk” as in “install product key.” Once that was done, the system activated just fine. I do not know whether this is an anomaly that is specific to the MS Partner internal-use version of the product, or whether it will crop up in other volume license versions.

As I said, the upgrade went smoothly. Even though I was not connected to the Moose Logic network when I did the upgrade, it did not disrupt the domain membership, and I was able to authenticate with my domain credentials when I was done. So far, everything I’ve tried to run has run fine. As far as I can tell, even my AVG anti-virus is still functional.

I am a bit annoyed that Microsoft dropped the “Aero Glass” interface, but I guess I’ll get used to that. I’m also annoyed at the absence of a “Start” button on the desktop task bar, but I found a solution for that: the good folks at Stardock have a utility called “Start 8” that puts the Start button back, and gives you both a “Run” and a “Shutdown” option if you right-click on it. (At your option, it can also take you straight to a desktop when you log on.) The version of Start8 that is currently available for download was designed for the Consumer Preview of Win8, but appears to install and run just fine on the released version as well. I’m sure that Stardock will release an update for it soon.

I was also very pleased to discover that my two favorite Win7 utilities, “Fences” (also by Stardock) and “Display Fusion,” also still functioned within the Win8 desktop. In particular, the Fences utility eases some of the inconvenience of having to look for applications that aren’t on the new Win8 Start screen. Since I had used Fences to group application icons on my Win7 desktop for my most frequently-used apps, all I have to do is jump to a desktop, and those icons are still right there.

I suspect that, for the foreseeable future, I will still do most of what I do within the context of a traditional desktop, which begs the question of why I should have upgraded in the first place. One reason, of course, is so I can write posts like this one. Another is that, as a Microsoft Partner, I felt that I needed to be familiar with the new OS. Also, my LE1700 is touch-capable, although it requires the use of a stylus, so I’m curious to see how well things will work when I undock the system and actually use it as a tablet. Finally, I’ve got my sights set on a Surface Pro tablet when they become available (I’m due for a system upgrade anyway), so the more exposure I get to Win8 the more prepared I’ll be.

I’ll be writing more about my adventures with Windows 8 as time goes on…

So, let’s discuss Citrix licensing first, then move on to the Microsoft licensing.

First of all, if all you want to do is to deploy VDI (Virtual Desktop Infrastructure), and you have a limited number of users, then you should probably purchase VDI-in-a-Box. You can read more about this in our April Moose Views article about XenDesktop vs. VDI-in-a-Box.

If you decide that VDI-in-a-Box is not the right fit foryou, the next question you need to answer is whether to use XenApp licenses or XenDesktop licenses. Beginning with the introduction of XenDesktop v4.0, Citrix concluded, reasonably enough, that an organization that was deploying VDI probably wouldn’t get much leverage from a concurrent-use licensing model, because their concurrency ratio (by which I mean the ratio of total users to concurrent users) would be pretty close to 1:1. So XenDesktop v4.0 was introduced with a per-named-user or per-device license model. These licenses were roughly half the cost of the comparable XenApp concurrent-use license: XenApp Enterprise Edition, for example, carries an MSRP of $450 per concurrent user. XenDesktop Enterprise Edition carries an MSRP of $225 per user/device.

At the same time, Citrix made the decision to include XenApp rights in the XenDesktop license. So if you buy XenApp, you get only XenApp. But if you buy XenDesktop, you get both XenDesktop and XenApp – so you can use XenApp to stream applications to your virtual desktops, or have your virtual desktops function as client devices that run published applications that execute on the XenApp servers, or simply deploy a mixture of XenDesktop and XenApp to your user community depending on what delivery method is best for a particular use case. This is what Citrix refers to as the “FlexCast” delivery model.

This created the interesting situation where, because of the difference in license cost, if your concurrency ratio was less than 2:1, you were better off financially to purchase XenDesktop licenses even if all you really wanted to run was XenApp. And, since delivering what Citrix calls “hosted shared” desktops from XenApp servers makes more efficient use of the underlying hardware and storage infrastructure, the bias should probably be toward XenApp unless there is a clear use case for why users need to connect to individual desktop OS instances rather than a shared XenApp desktop (and it isn’t just appearance, because with XenApp v6.5 on Windows Server 2008 R2 we can deliver a XenApp desktop that looks and feels like a Windows 7 desktop). But, for the sake of this discussion, let’s move on down the XenDesktop trail.

Citrix has re-introduced a concurrent-use license option for XenDesktop, which is a better choice for organizations who want to deploy both XenDesktop and XenApp, but have a concurrency ratio greater than 2:1, but so far, I haven’t seen very many use cases where that license model made sense.

If you already have XenApp licenses, and want the ability to deliver VDI as well, you can take advantage of the Citrix trade-up program to transform your XenApp licenses into XenDesktop licenses. And if you trade up all of your XenApp licenses, you can get two XenDesktop user/device licenses for each XenApp license. So 250 XenApp licenses would become 500 XenDesktop user/device licenses. If you want more information on how the trade-up program works, and what your trade-up options are, check out the handy Citrix Trade-Up Calculator.

As of the release of XenDesktop v5.0 Feature Release 1, the license service got pretty smart in terms of how it managed those user/device licenses. This is good news for, say, a hospital, which may have devices that are used by multiple users and other users who use multiple devices. The license server can intelligently and dynamically reassign licenses between users and devices to make the most efficient use of the available licenses. For example, consider the following scenario for a brand-new environment where no licenses have yet been assigned:

• User 1 logs on from client Device 1. The license server will, by default, check out a license to User 1.
• User 1 logs off, and User 2 logs on from the same client device. The license server, now sensing that two different users have logged on from the same device, will take the license that was assigned to User 1, and reassign it to Device 1. Any subsequent users who log in from Device 1 will not cause any action by the license server, because Device 1 is already licensed.
• If User 1 logs on again from a different client device, the license server will again check out a license to User 1 (so, at this point, two licenses are checked out: one to Device 1 and one to User 1). Since User 1 has logged on from two different devices, the license will remain assigned to User 1 unless/until manually released by an administrator (e.g., in the case of the employee leaving the organization), or unless User 1 doesn’t log on for a period of 90 days, in which case it will be automatically released due to inactivity.
• Likewise, since two different users have logged on from Device 1, that license will remain assigned to that device unless manually released or automatically released due to 90 days of inactivity.

So…how do you know how many licenses you really need? There is actually a formula that will tell you that. You need to know how many total users you have (let’s call that number “A”), how many shared devices you have (let’s call that “B”), and how many of your users will use only shared devices (let’s call that “C”). The formula is A – C + B. So, if you have 1,000 total users, 300 shared devices, and 600 of your users will use only shared devices, you need 1,000 – 600 + 300 = 700 total licenses.

For more information on exactly how this works, see the Citrix Community Blog post by Christophe Catesson, which in turn links to a recorded session from Synergy 2011 that was a deep dive discussion of XenDesktop licensing.

Now for the Microsoft licensing component.

If you have users who will be executing applications on a XenApp server, you will need a Remote Desktop Services (RDS) CAL for that user, or for the client device that user is using. It is very difficult to manage a mixture of user CALs and device CALs in a Remote Desktop Services environment, so, in most cases, you’re going to be better off purchasing user CALs.

If you have users who will be attaching to a virtual desktop instance, the licensing requirements are different, depending on the client device. If the client device is a Windows PC whose Operation System is covered by Software Assurance, you do not have to purchase any additional Microsoft license to use that PC to connect to a virtual desktop. If the client device is not a Windows PC, or that copy of Windows is not covered by Software Assurance, you need a Virtual Desktop Access (VDA) license for that client device. VDA licenses are only available under the Open Value Subscription license model at present, meaning that you will continue to pay for them every year. Forever.

But wait! That’s not all! As Gabe Knuth outlines in a recent article on Techtarget.com, there is a very strange loophole in the VDA license terms. If you have a VDA license for your primary device (or if it’s covered by Software Assurance), you have what Microsoft calls “Extended Roaming Rights,” which allow you to also use your home computer to access your virtual desktop, or use your iPad when you’re at home or traveling. But, technically, it does not entitle you to bring your iPad into the office and use it there! To solve that (using the term “solve” loosely), Microsoft recently announced something called a “Companion Device License” (CDL) which allows you to use up to four other devices (in addition to the primary licensed device) to access your virtual desktop. No word yet on what the CDL will cost.

So let’s see if we can summarize what our client would need for a deployment of “zero client” devices (like, for example, the Wyse Xenith thin client).

• You’re going to need some kind of Citrix license, either VDI-in-a-Box, XenDesktop, or XenApp.
• Since the thin client is not a Windows PC, and therefore cannot be covered by Software Assurance, you would need to purchase a Microsoft VDA license for it.
• If the thin client will be used only to attach to a virtual PC desktop and execute applications within that desktop OS environment, no additional Microsoft license is needed. However, if the thin client will also be used to attach to applications that are executing on a XenApp server – either directly or indirectly by having the Citrix client baked into the virtual PC desktop – you will also need a Microsoft RDS CAL.
• You do not need an RDS CAL if you are only using XenApp to stream packaged applications to a virtual (or physical, for that matter) desktop for execution there. Since you are not actually utilizing Remote Desktop Services by executing code remotely on a Remote Desktop Server, no RDS CAL is required.
• If you want to institute a BYOD program, where users can bring whatever client device they wish into the office and use it to access your VDI, you’ll probably need some of the new Microsoft CDL licenses.

If I’ve overlooked anything, feel free to submit questions via comments on this post, and we’ll try to get them answered. Let the discussion begin!

Apparently Citrix has been feeling some heat from customers who weren’t too happy about that, so they have announced something new called “Extended Support,” that will be available after EOL for an additional fee – which was not specified. The “End of Extended Support” (EOES) dates have been aligned with the comparable Microsoft dates for the underlying server Operating System.

The odd thing about this is that the EOL dates have not changed (except for XenApp v6.0, which will now hit EOL on January 2, 2015). It’s just that EOL doesn’t mean what it used to mean. Previously, when a Citrix product hit EOL, that meant there was no support available for it whatsoever. Now, apparently, “End of Life” means “End of Life Unless You Pay Us More Money to Keep Supporting You.”

For the record, the EOES dates for the versions of XenApp that run on Server 2003 have been set to July 14, 2015, and the EOES dates for the versions that run on Server 2008 (and 2008 R2) have been set to July 10, 2018.

You can read more about this on the Citrix Product Matrix Web page.

As of now, the Extended Support program for XenDesktop is still being defined…

First of all, I’m going to assume that we are building a system that will support Windows 7 virtual desktops – because I can’t see any valid reason why someone would invest in a virtual desktop infrastructure that couldn’t support Windows 7. There are two important data points that follow from this: (1) We should allow at least 1.5 Gb per virtual PC, and preferably 2 Gb per virtual PC. (2) We should design for an average of about 15 IOPS per Windows 7 virtual PC, because, depending on the user, a Windows 7 desktop will generate 10 – 20 IOPS. Let’s tackle the IOPS issue first.

Thanks to Dan Feller of Citrix, we know how to calculate the “functional IOPS” of a given disk subsystem. Here are the significant factors that go into that formula:

• A desktop Operating System – unlike a server Operating System – has a read/write ratio of roughly 80% writes and 20% reads.
• A 15K SAS drive will support approximately 175 IOPS. The total “raw IOPS” of a disk array built from 15K SAS drives is simply 175 x the number of drives in the array.
• A RAID 10 array, which probably offers the best balance of performance and reliability, has a “write penalty” of 2.

With that in mind, the formula is:

Functional IOPS=((Total Raw IOPS x Write %)/(RAID Penalty)) + (Total Raw IOPS x Read %)

If we put eight 15K SAS drives into a RAID 10 array, the formula becomes:

Raw IOPS = 175 x 8 = 1,400

Functional IOPS = ((1,400x.8)/2)+(1,400x.2) = 560 + 280 = 840

If we are assuming an average of 15 IOPS per Win7 virtual PC, this suggests that the array in question will support roughly 56 virtual PCs. So this array should be able to comfortably support our 50 Win7 virtual PCs, unless all 50 are assigned to power users.

That’s all well and good, but we haven’t talked yet about how much actual storage space this array needs. That depends on the size of our Win7 master image, how many different Win7 master images we’re going to be using, and whether we can use “linked clones” for VDI provisioning, in which case each virtual PC will consume an average of 15% of the size of the master, or whether we’re permanently assigning desktops to users, in which case each virtual PC will consume 100% of the size of the master. For the sake of this exercise, let’s assume we’re using linked clones, and that we have three different master images, each of which is 20 Gb in size. According to the Citrix best practice, we need to reserve 120 Gb for our master images (2 x master image size x number of master images). We then need to reserve 3 Gb per virtual PC (15% of 20 Gb), which totals another 150 Gb. The ViaB virtual appliance will require 70 Gb. We also need room for the hypervisor itself (unless we’re provisioning another set of disks just for that) and for swap file, transient activity, etc., so let’s throw in another 150 Gb. That’s 490 Gb minimum. So we need to use, at a minimum, 146 Gb drives in our array, which would give us 584 Gb in our RAID 10 array.

How about RAM? If we allow 1.5 Gb per Win7 desktop, then 50 virtual desktops will consume 75 Gb. We need at least 1 Gb for the ViaB appliance, at least 1 Gb for the hypervisor, plus some overhead for server operations, so let’s just call it 96 Gb.

We can handle 6 to 10 virtual desktops per CPU core – more if the cores are hyper-threaded – so we’re probably OK with a dual-proc, quad-core server.

Now, I don’t know about you, but if I’m going to put 50 users onto a single server, I’m going to want some redundancy. I will at least want hot-plug redundant power supplies, and hot-plug disk drives. Ideally, I would provision “N+1″ redundancy, i.e., I would have one more server in my ViaB array than I need to support my users. I’m also going to want a remote access card, and probably an uplift on the manufacturer’s Warranty so if it breaks, the manufacturer will come on site and fix it.

By now, you’ve probably figured out that we are not talking about a $4,000 server here. I priced out a Dell R710 – using their public-facing configuration and quoting tool – with the following configuration, and it came out to roughly $11,000:

• Two Intel E5640 quad-core, hyper-threaded processors, 2.66 GHz
• 96 Gb RAM
• Eight 146 Gb, 15K SAS drives
• PERC H700 controller with 512 Mb cache
• Redundant hot-plug power supplies
• iDRAC Enterprise remote access card
• Warranty uplift to 3-year, 24×7, 4-hour response, on-site Warranty

(NOTE: This is a point-in-time price, and hardware prices are subject to change at any time.)

The ViaB licenses themselves will cost you $195 each. Be careful of the comparisons that show the price as $160 each. ViaB is unique among Citrix products in that the base cost of the license does not include the first year of Subscription Advantage – yet the purchase of that first year is required (although you don’t necessarily have to renew it in future years). That adds $35 each to the cost of the licenses.

Finally, If you don’t have Microsoft Software Assurance on your PC desktops – and my experience is that most SMBs do not – you need to factor in the Microsoft Virtual Desktop Access (VDA) license for every user. This license is only available as an annual subscription, and will cost you approximately $100/year.

So, your up-front acquisition cost for the system we’ve been discussing looks like this:

• Dell R710 server – $11,000
• 50 ViaB licenses @ $195 – $9,750
• 50 Microsoft VDA licenses @ $100 – $5,000

Total aquisition cost: $25,750, or $515/user. Not bad.

But wait – if we’re going to compare this to the cost of buying new PC, shouldn’t we look at the cost of ViaB over the same period of time that we would expect that new PC to last? If we assume, like many companies do, that a PC has a useful life of about 3 years, then we should actually factor in another two years of VDA licenses, and two years of Subscription Advantage renewal for the ViaB licenses. That pushes the 3-year cost of the ViaB licenses to $13,250, and the cost of the VDA licenses to $15,000. So the total 3-year cost of our solution is $39,250, or $785/user.

If you want N+1 redundancy, you’re going to need to buy a second server. That would push the cost to $50,250, or $1,005/user.

What conclusions can we draw from all this? Well, first, that VDI-in-a-Box is not going to be significantly less expensive than buying new PCs, if you actually do it right. However, it is competitive with the price of new PCs, which is worth noting. As long as the price is comparable, which it is, we can then start talking about the business advantages of VDI, such as being able to remotely access your virtual desktop from anywhere, with just about any device, including iPad and Android tablets, and about the ongoing management advantages of having a single point of control over multiple desktops.

Also, as you scale up the environment, the incremental cost of that extra server that’s required for N+1 redundancy gets spread over more and more users, and becomes less significant. For example, if we’re building an infrastructure that will support 150 virtual desktops, we would need four servers. Total 3-year cost: $128,750, or $858.33/user for a robust, highly redundant virtual desktop infrastructure. In my opinion, that’s a pretty compelling price point, and you won’t be able to hit that price point with a 150-user XenDesktop deployment, because of the other server and storage infrastructure components that you need to build a complete solution. On the other hand, XenDesktop does include more functionality, like the rights to use XenApp for virtual application delivery, ability to stream a desktop OS to a blade PC or a desktop PC, rights to use XenClient for client-side virtualization, etc.

But if all you want is a VDI solution, ViaB is, in my opinion, the obvious choice. It’s clear that Citrix wants to position VDI-in-a-Box as the preferred VDI solution for SMBs, meaning anyone with 250 or fewer users…and there’s no reason why ViaB can’t scale much larger than that.

For more information on ViaB, check out this video from Citrix TV, then head on over to the Citrix TV site to view the entire ViaB series…

**** EDIT April 12, 2012 ****
You may already be aware of this, but Dell has announced a ViaB appliance that comes pre-configured, with both XenServer and the ViaB virtual appliance already installed. Oddly enough, even though Moose Logic is a Dell partner, I couldn’t get Dell to tell me what one would cost. Their answer was that I should call back when I had a specific customer need, and they would work up a specific configuration and quote it. I considered calling back with a fictitious customer requirement, but decided that I didn’t want to know badly enough to play that game.

They did, however, tell me what the basic server configuration was – and it was very close to the configuration I’ve outlined above: two X5675 processors, 96 Gb of RAM, eight 146 Gb drives in a RAID 10 array, Perc H700 array controller (don’t know how much cache, though), and iDRAC Enterprise remote access card. I do not know whether it has redundant power supplies (although I would certainly hope so), nor exactly what Warranty is included…perhaps that option is left up to the customer.

That gave me at least enough information to run a sanity check on the configuration. The array would provide 960 functional IOPS, which should be adequate for an 80 user system – which is how the appliance is advertised – depending, of course, on the percentage of power users. Also, the array should provide enough storage to handle the needs of most SMBs, unless they have an unusually large number of images to maintain.

One of my Citrix contacts recently told me that the Dell appliance was priced at $440/desktop for an 80 concurrent user configuration, which is very much in line with the cost per user in the post above, considering that $100 of my $515/user number was for the first year of Microsoft VDA licenses, which, to my knowledge, are not included with the Dell appliance.