You are here: Home > Blog

Does “Shared Nothing” Migration Mean the Death of the SAN?

November 30th, 2012 | Posted by Sid Herron in Best Practices | Hyper-V | Microsoft | Virtualization - (0 Comments)

You’ve probably heard that Hyper-V in Windows Server 2012 supports what Microsoft is calling “Shared Nothing” live migration. You can see a demo of that here, in a video that was posted on a TechNet blog back in July:

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.

, , ,

More on VDI-in-a-Box and Personal vDisks

September 7th, 2012 | Posted by Sid Herron in Best Practices | Citrix | VDI | VDI-in-a-Box | Virtualization - (2 Comments)

In my last post, I talked about the new release (v5.1) of VDI-in-a-Box (“ViaB”) and some of the new features. One of those new features is the addition of support for Personal vDisks (“PVDs”). But before we get any deeper into the subject, let’s take a step back, and make sure we’re clear on why you would want PVDs in the first place.

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.

, , ,

Citrix Releases VDI-in-a-Box v5.1

August 21st, 2012 | Posted by Sid Herron in Citrix | VDI | VDI-in-a-Box | Virtualization - (0 Comments)

We just learned that Citrix has released VDI-in-a-Box (“ViaB”) v5.1. There are a number of new features in ViaB v5.1, which you can read about in the Citrix on-line documentation library, but two of these features are particularly significant:

  • 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.

, , ,

What Licenses Do I Need….

May 16th, 2012 | Posted by Sid Herron in Application streaming | Application Virtualization | Citrix | Licensing | Microsoft | Remote Access | VDI | Virtualization | XenApp | XenDesktop - (25 Comments)

Earlier this week, I had a long discussion with a client (you know who you are) about what licenses they would need for a deployment of “zero client” devices. We’ve written a lot about Microsoft and Citrix licensing, about XenDesktop and XenApp, about the Citrix trade-up, etc., but it occurred to me that it might be beneficial to pull all the licensing information together into one post instead of expecting you, gentle reader, to have to sort through multiple posts to pull it all together.

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!

, , , , , , , , ,

Best Practices for Provisioning XenDesktop

May 11th, 2012 | Posted by Sid Herron in Citrix | Citrix Synergy | VDI | Virtualization | XenDesktop - (0 Comments)

We’ve written a lot here regarding XenDesktop’s two provisioning methods: Provisioning Services and Machine Creation Services. Earlier this week, at the Citrix Synergy Conference in San Francisco, there was a session specifically devoted to discussing those two provisioning methods, providing a high level overview of how they worked, the best practices for deploying each of them, and even some guidelines for how to determine which approach is best for your organization. For the benefit of those who couldn’t make it to Synergy – or those who did make it, but would like a better way to share that information with others in their organizations – that session was recorded and is available on Citrix TV. You can view it below:

, , , , , ,

What the Heck Is a “Storage Hypervisor?”

August 25th, 2011 | Posted by Sid Herron in DataCore | Storage | Virtualization - (0 Comments)

Our friends at DataCore ran a press release yesterday positioning the new release (v8.1) of SANsymphony-V as a “storage hypervisor.” On the surface, that may just sound like some nice marketing spin, but the more I thought about it, the more sense it made – because it highlights one of the major differences between DataCore’s products and most other SAN products out there.

To understand what I mean, let’s think for a moment about what a “hypervisor” is in the server virtualization world. Whether you’re talking about VSphere, Hyper-V, or XenServer, you’re talking about software that provides an abstraction layer between hardware resources and operating system instances. An individual VM doesn’t know – or care – whether it’s running on an HP Server, a Dell, an IBM, or a “white box.” It doesn’t care whether it’s running on an Intel or an AMD processor. You can move a VM from one host to another without worrying about changes in the underlying hardware, bios, drivers, etc. (Not talking about “live motion” – that’s a little different.) The hypervisor presents the VM with a consistent execution platform that hides the underlying complexity of the hardware.

So, back to DataCore. Remember that SANsymphony-V is a software application that runs on top of Windows Server 2008 R2. In most cases, people buy a couple of servers that contain a bunch of local storage, install 2008 R2 on them, install SANsymphony-V on them, and turn that bunch of local storage into full-featured iSCSI SAN nodes. (We typically run them in pairs so that we can do synchronous mirroring of the data across the two nodes, such that if one node completely fails, the data is still accessible.) But that’s not all we can do.

Because it’s running on a 2008 R2 platform, it can aggregate and present any kind of storage the underlying Server OS can access at the block level. Got a fibre channel SAN that you want to throw into the mix? Great! Put fiber channel Host Bus Adapters (HBAs) in your DataCore nodes, present that storage to the servers that SANsymphony-V is running on, and now you can manage the fibre channel storage right along with the local storage in your DataCore nodes. Got some other iSCSI SAN that you’d like to leverage? No problem. Just make sure you’ve got a couple of extra NICs in the DataCore nodes (or install iSCSI HBAs if you want even better performance), present that iSCSI storage to the DataCore nodes, and you can manage it as well. You can even create a storage pool that crosses resource boundaries! And now, with the new auto-tiering functionality of SANsymphony-V v8.1, you can let DataCore automatically migrate the most frequently accessed data to the highest-performing storage subsystems.

Or how about this: You just bought a brand new storage system from Vendor A to replace the system from Vendor B that you’ve been using for the past few years. You’d really like to move Vendor B’s system to your disaster-recovery site, but Vendor A’s product doesn’t know how to replicate data to Vendor B’s product. If you front-end both vendors’ products with DataCore nodes, the DataCore nodes can handle the asynchronous replication to your DR site. Alternately, maybe you bought Vendor A’s system because it offered higher performance than Vendor B’s system. Instead of using Vendor B’s product for DR, you can present both systems to SANsymphony-V and leverage its auto-tiering feature to automatically insure that the data that needs the highest performance gets migrated to Vendor A’s platform.

So, on the back end, you can have disparate SAN products (iSCSI, fibre channel, or both) and local storage (including “JBOD” expansion shelves), and a mixture of SSD, SAS, and SATA drives. The SANsymphony-V software masks all of that complexity, and presents a consistent resource – in the form of iSCSI virtual volumes – to the systems that need to consume storage, e.g., physical or virtual servers.

That really is analogous to what a traditional hypervisor does in the server virtualization world. So it is not unreasonable at all to call SANsymphony-V a “storage hypervisor.” In fact, it’s pretty darned clever positioning, and I take my hat off to the person who crafted the campaign.

, ,

Beware of Vendor-Sponsored “Analysis” Reports

June 16th, 2011 | Posted by Sid Herron in Citrix | VDI | Virtualization | VMware | XenDesktop - (2 Comments)

Mark Twain allegedly came up with the famous line: "Figures don’t lie, but liars figure." That’s a good thing to keep in mind any time you’re looking through a report that was sponsored ("sponsored" = "paid for") by a vendor that concludes that their product is better than the other guy’s.

Maybe it is better than the other guy’s. But you might want to look closely at what was tested, how it was tested, and whether they were, shall we say, selective in the facts they present.

Case in point: The Tolly Group’s report, released May 27, comparing VMware View 4.6 Premier Edition to Citrix XenDesktop 5 Platinum edition. There are several interesting aspects to this report, which are dealt with in detail in Tal Klein’s blog over on the Citrix Community blog site. Here are a few of the more egregious items:

  • VMware View 4.6 Premier licensing costs less than XenDesktop 5 Platinum. Absolutely true, and absolutely irrelevant. That’s like pointing out that if you load every possible dealer option onto your new car, it’s going to cost more than the basic model. Thank you, Captain Obvious. If you want an "apples-to-apples" comparison, you need to compare VMware View to the XenDesktop VDI Edition. But wait, if you do that, XenDesktop is actually less expensive, and that would be an awkward point to publish in a paper that’s being paid for by VMware.
  • VMware’s PCoIP provides a more consistent multi-media experience than XenDesktop 5. (Over a LAN. Using a single thin client device that did not support any of the Citrix HDX media acceleration features.) Sorry, guys, but once again this is not an apples-to-apples comparison. And did they publish any results of testing across a WAN link? Nope…and for the same reason they didn’t use XenDesktop VDI Edition for their price comparison.
  • It’s easier to upgrade View 4.5 to View 4.6 than it is to upgrade XenDesktop 4 to XenDesktop 5. Once again, both true and irrelevant. It’s easier to give your kitchen a new coat of paint than it is to rip out the cabinets and completely remodel it. Anybody surprised by that? There are significant architectural changes from XenDesktop 4 to XenDesktop 5. It shouldn’t be surprising to anyone that this will involve more effort than a "dot release" upgrade.

I’ve always been skeptical of vendor-sponsored "analysis" reports, and, to be fair, Citrix has used the Tolly Group in the past for its own sponsored reports – but it seems to me that this one is just over the top. Apparently, former Gartner analyst Simon Bramfitt agrees. His pithy assessment of the report: "There are undiscovered tribes lost in the darkest parts of the Amazon jungle that would know exactly what to do if a vendor airdropped a pile of competitive marketing literature authored by the Tolly Group; send it back, and asked [sic] that it be re-printed on more absorbent paper."

What do you think?

, , , , , ,

Thin Clients vs. Cheap PCs

June 1st, 2011 | Posted by Sid Herron in Licensing | Microsoft | VDI | Virtualization | Windows 7 - (3 Comments)

We have, for a long time, been fans of thin client devices. However, if you run the numbers, it turns out that thin-clients may not necessarily be the most cost-effective client devices for a VDI deployment.

Just before writing this post, I went to the Dell Web site and priced out a low-end Vostro Mini Tower system: 3.2 GHz Intel E5800 dual-core processor, 3 Gb RAM, 320 Gb disk drive, integrated Intel graphics, Windows 7 Professional 64-bit OS, 1 year next-business-day on-site service. Total price: $349.00.

When you buy a new PC with an OEM license of Windows on it, you have 90 days to add Microsoft Software Assurance to that PC. That will cost you $109.00 for two years of coverage. You’re now out of pocket $458.00. However, one of the benefits of Software Assurance is that you don’t need any other Microsoft license component to access a virtual desktop OS. You also have the rights, under SA, to install Windows Thin PC (WinTPC) on the system, which strips out a lot of non-essential stuff and allows you to administratively lock it down – think of WinTPC as Microsoft’s own tool kit for turning a PC into a thin client device.

Now consider the thin client option. A new Wyse Winterm built on Embedded Windows 7 carries an MSRP of $499. There are less expensive thin clients, but this one would be the closest to a Windows 7 PC in terms of the user experience (media redirection to a local Windows Media Player, Windows 7 user interface, etc.). However, having bought the thin client, you must now purchase a Microsoft Virtual Desktop Access (VDA) license to legally access your VDI environment. The VDA license is only available through the Open Value Subscription model, and will cost you $100/year forever. So your total cost over two years is $699 for the Wyse device vs. $458 for the Dell Vostro.

After the initial two year term, you’ll have to renew Software Assurance on the PC for another two years. That will continue to cost you roughly $54.50/year vs. $100/year to keep paying for that VDA license.

Arguably, the Wyse thin client is a better choice for some use cases. It will work better in a hostile environment – like a factory floor – because it has no fan to pull dust and debris into the case. In fact, it has no moving parts at all, and will likely last longer as a result…although PC hardware is pretty darned reliable these days, and at that price point, the low-end PC becomes every bit as disposable as a thin client device.

So, as much as we love our friends at Wyse, the bottom line is…well, it’s the bottom line. And if you’re looking at a significant VDI deployment, it might be worth running the numbers both ways before you decide for sure which way you’re going to go.

, , , ,

IntelliCache and the IOPS Problem

May 20th, 2011 | Posted by Sid Herron in Best Practices | Citrix | Provisioning Services | VDI | Virtualization | VMware | XenDesktop - (0 Comments)

If you’ve been following this blog for any length of time, you know that we’ve written extensively about XenDesktop, and spent a lot of time on best practices and problems to avoid. And one of the biggest problems to avoid is poor storage design resulting in poor VDI performance.

In a nutshell, the problem is that a Windows desktop OS uses disk far differently than a Windows server OS. Thanks to the way Windows uses the swap file, disk writes outnumber disk reads by about 2 to 1. You can build your virtual desktop infrastructure on the latest and greatest server hardware, with tons of processing power and insanely huge amounts of RAM, but if all of the disk I/O for all of those virtual desktops is hitting your SAN, you’ve got a scalability problem on your hands.

Provisioning Services (“PVS”) can help to mitigate this in two ways (assuming for sake of argument that you’re provisioning multiple virtual systems from a common, read-only image): First, if you build your Provisioning Servers correctly, you should be able to serve up most of the OS read operations from the Provisioning Server’s own cache memory. Second, you can use the virtualization host’s local disk storage as the required “write cache” – because all of those write operations have to go somewhere while the virtual system is running.

But XenDesktop 5 introduced a new way to provision desktops called “Machine Creation Services” (“MCS”). We wrote about this in the April edition of our Moose Views newsletter, so if you’re not familiar with all the pros and cons of MCS vs. PVS, I’d encourage you to take a brief time out and read that article. Suffice it to say that, despite all the advantages of MCS, the biggest downside of using MCS to provision pooled desktops was that all of the IOPS hit your SAN storage, which limited the scalability of an MCS-provisioned VDI deployment.

But all of that just changed, with the release of XenDesktop 5 Service Pack 1, which was made available for download a week ago (May 13). With SP1, XenDesktop 5 is now able to take advantage of the “IntelliCache” feature that was introduced as part of XenServer v5.6 Service Pack 2. Using MCS with the combination of XenDesktop 5 SP1 and XenServer SP2…

  • The first time a virtual desktop is booted on a given XenServer, the boot image is cached on that XenServer’s local storage.
  • Subsequent virtual desktops booted on that same XenServer will boot and run from that locally cached image.
  • You can use the XenServer’s local storage for the write cache as well.

The bottom line is that you can move as much as 90% of the IOPS off of the SAN and onto local XenServer storage, removing nearly all of the scalability limitations from an MCS-provisioned environment.

With most of the IOPS for running VMs taking place on local storage, it’s pretty straightforward to figure out how many VMs you can expect to support on a given virtualization host. Dan Feller’s blog post does a great job of walking through the process of calculating the functional IOPS that your local XenServer storage repository should be able to support, and inferring from that number how many light, normal, or power users you should be able to support as a result.

This also means that using XenServer as the hypervisor for your XenDesktop 5 deployment is going to yield a significant performance advantage over any other hypervisor, unless or until the other guys come out with similar local caching features. So, if you’re a VMware shop, my advice is this: Go ahead and virtualize all of the supporting XenDesktop server components on your VSphere infrastructure. Run your XenDesktop 5 VMs on XenServer hosts, and just don’t tell anyone! If you’re asked, just say, “Oh, yeah, these are my XenDesktop host systems – they’re completely separate from our VSphere infrastructure, because we don’t need the (insert favorite VSphere feature) function for these systems.” Your infrastructure will run better, and no one will know but you…

, , , , , , ,

How’s That “Cloud” Thing Working For You?

April 28th, 2011 | Posted by Sid Herron in Application Hosting | Best Practices | Business Continuity | Cloud Computing | Disaster Recovery | High Availability | Virtualization - (7 Comments)

Color me skeptical when it comes to the “cloud computing” craze. Well, OK, maybe my skepticism isn’t so much about cloud computing per se as it is about the way people seem to think it is the ultimate answer to Life, the Universe, and Everything (shameless Douglass Adams reference). In part, that’s because I’ve been around IT long enough that I’ve seen previous incarnations of this concept come and go. Application Service Providers were supposed to take the world by storm a decade ago. Didn’t happen. The idea came back around as “Software as a Service” (or, as Microsoft preferred to frame it, “Software + Services”). Now it’s cloud computing. In all of its incarnations, the bottom line is that you’re putting your critical applications and data on someone else’s hardware, and sometimes even renting their Operating Systems to run it on and their software to manage it. And whenever you do that, there is an associated risk – as several users of Amazon’s EC2 service discovered just last week.

I have no doubt that the forensic analysis of what happened and why will drag on for a long time. Justin Santa Barbara had an interesting blog post last Thursday (April 21) that discussed how the design of Amazon Web Services (AWS), and its segmentation into Regions and Availability Zones, is supposed to protect you against precisely the kind of failure that occurred last week…except that it didn’t.

Phil Wainewright has an interesting post over at ZDnet.com on the “Seven lessons to learn from Amazon’s outage.” The first two points he makes are particularly important: First, “Read your cloud provider’s SLA very carefully” – because it appears that, despite the considerable pain some of Amazon’s customers were feeling, the SLA was not breached, legally speaking. Second, “Don’t take your provider’s assurances for granted” – for reasons that should be obvious.

Wainewright’s final point, though, may be the most disturbing, because it focuses on Amazon’s “lack of transparency.” He quotes BigDoor CEO Keith Smith as saying, “If Amazon had been more forthcoming with what they are experiencing, we would have been able to restore our systems sooner.” This was echoed in Santa Barbara’s blog post where, in discussing customers’ options for failing over to a different cloud, he observes, “Perhaps they would have started that process had AWS communicated at the start that it would have been such a big outage, but AWS communication is – frankly – abysmal other than their PR.” The transparency issue was also echoed by Andrew Hickey in an article posted April 26 on CRN.com.

CRN also wrote about “lessons learned,” although they came up with 10 of them. Their first point is that “Cloud outages are going to happen…and if you can’t stand the outage, get out of the cloud.” They go on to talk about not putting “Blind Trust” in the cloud, and to point out that management and maintenance are still required – “it’s not a ‘set it and forget it’ environment.”

And it’s not like this is the first time people have been affected by a failure in the cloud:

  • Amazon had a significant outage of their S3 online storage service back in July, 2008. Their northern Virginia data center was affected by a lightning strike in July of 2009, and another power issue affected “some instances in its US-EAST-1 availability zone” in December of 2009.
  • Gmail experienced a system-wide outage for a period of time in August, 2008, then was down again for over 1 ½ hours in September, 2009.
  • The Microsoft/Danger outage in October, 2009, caused a lot of T-Mobile customers to lose personal information that was stored on their Sidekick devices, including contacts, calendar entries, to-do lists, and photos.
  • In January, 2010, failure of a UPS took several hundred servers offline for hours at a Rackspace data center in London. (Rackspace also had a couple of service-affecting failures in their Dallas area data center in 2009.)
  • Salesforce.com users have suffered repeatedly from service outages over the last several years.

This takes me back to a comment made by one of our former customers, who was the CIO of a local insurance company, and who later joined our engineering team for a while. Speaking of the ASPs of a decade ago, he stated, “I wouldn’t trust my critical data to any of them – because I don’t believe that any of them care as much about my data as I do. And until they can convince me that they do, and show me the processes and procedures they have in place to protect it, they’re not getting my data!”

Don’t get me wrong – the “Cloud” (however you choose to define it…and that’s part of the problem) has its place. Cloud services are becoming more affordable, and more reliable. But, as one solution provider quoted in the CRN “lessons learned” article put it, “Just because I can move it into the cloud, that doesn’t mean I can ignore it. It still needs to be managed. It still needs to be maintained.” Never forget that it’s your data, and no one cares about it as much as you do, no matter what they tell you. Forrester analyst Rachel Dines may have said it best in her blog entry from last week: “ASSUME NOTHING. Your cloud provider isn’t in charge of your disaster recovery plan, YOU ARE!” (She also lists several really good questions you should ask your cloud provider.)

Cloud technologies can solve specific problems for you, and can provide some additional, and valuable, tools for your IT toolbox. But you dare not assume that all of your problems will automagically disappear just because you put all your stuff in the cloud. It’s still your stuff, and ultimately your responsibility.

, , , , , ,

Latest Blog Feeds
Go to our Blog Page
Testimonials
“Our business is all about process and margins; we rely on Moose Logic to install and manage network solutions that enable us to control both. Moose Logic created solutions that transformed our business relationships and processes.”
Ron Horowitz
Birchwood Park Homes
Read our Newsletter
Copyright © 2010 All rights reserved.
Wordpress Delicate template designed by NattyWP