Your are here: Home > Blog

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?

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…

Back in the old days of minicomputers and mainframes, we used to joke about IBM’s ability to, for all intents and purposes, get the customer to sign a blank check. They were better than anybody I’ve ever seen at getting people to commit to a solution when they really had no idea what the ultimate cost would be – and they were successful because of another cliche (which became a cliche because it was so accurate): “Nobody ever got fired for buying from IBM.” The message was basically, “Yes, we may be more expensive than everybody else, but we’ll take care of you.”

For the most part, those days are long gone, which made it all the more amazing to me to read that VMware is adopting per-VM licensing for most of its management products.

The article nails the basic problem with this licensing approach:

You know how many processors you have on a system, and that’s a fixed number. But the number of VMs on one host — let alone throughout your entire infrastructure — is regularly in flux. How do you plan your purchasing around that? And how do you make sure you don’t violate your licensing terms?

Hey, it’s easy – you just let VMware tell you what to put on your check at the end of the year:

You estimate your needs for the next year and buy licenses to meet those needs. Over the course of those 12 months, vCenter Server calculates the average number of concurrently powered-on VMs running the software. And if you end up needing more licenses to cover what you used, you just reconcile with VMware at the end of the year.

And, before you ask, no, you don’t get money back if you use fewer licenses than you originally purchased.

Sounds to me like a sweet deal – for VMware.

By comparison, the most expensive version of XenServer is $5,000 per server (not per processor, not per VM), and all of the management functionality is included. And the basic version of XenServer, which includes live motion, is free, and still includes the XenCenter distributed management software. (Here’s a helpful comparison chart of which features are included in which version of XenServer.)

A number of years ago, I attended a seminar that discussed the product adoption curve, and how products moved from the “innovation” phase to the “commodity” phase. The inflection point for a particular market was referred to as the “point of most” – where most of the products met most of the needs of most of the customers most of the time. When this point is reached, additional feature innovation no longer justifies a premium price.

The fact is that XenServer and Hyper-V are rapidly achieving feature parity with VMware. If we haven’t reached the “point of most” yet, we certainly will before much more time goes by. So even if you have a substantial investment in VMware already, at some point you have to re-examine what it’s costing every year, don’t you? Or are you OK with just signing a check and letting them fill in the amount later?

Some folks out there are still scratching their heads over the Citrix decision to change the name of Presentation Server to XenApp. There were actually several reasons for that change. For one thing, we’ve all seen Remote Desktop Services (formerly known as Terminal Services) get better and better with every release of Windows Server – and don’t think for a minute that Citrix didn’t see that coming. As closely as they work with Microsoft, of course they did. So it became obvious to Citrix long ago that they needed a better value proposition for their product than “something that I add to Terminal Services to get better performance.”

In point of fact, Citrix does have a considerably better value proposition than that – but not everyone was “getting it.” One way to help people get it is to re-frame the conversation by repositioning the product, and sometimes changing the product name can help make that happen.

But why XenApp? Well, that goes back to the acquisition of XenSource a few years ago. It seems that, after making that aquisition, Citrix decided that, in their vocabulary, “Xen” = “Virtualization.” Therefore…

  • “XenServer” = “Server Virtualization”
  • “XenDesktop” = “Desktop Virtualization”
  • “XenApp” = “Application Virtualization”

But does it, really? (XenApp, I mean.) Well, sort of. These days, application virtualization is a component of XenApp, but XenApp is more than just application virtualization.

Which brings me back to the question: What is application virtualization? I would suggest, as a good working definition, that, just as server virtualization is the abstraction of a server operating system from the underlying hardware, application virtualization is the abstraction of an application from the operating system it’s executing on.

We virtualize servers by interposing a layer of software – the hypervisor – between the hardware and the operating system. Although some operating systems, like Windows Server 2008, are virtualization-aware, meaning that they know when they’re running on a hypervisor and modify their behavior accordingly, earlier OS versions had to be fooled into thinking that they were running directly on server hardware when in fact they were not.

Applications today are still at the stage of development where they have to be fooled into thinking that they’ve been installed normally when in fact they have not. When they’re installed, applications typically write specific information to specific locations in the Windows registry. They place .DLL files into specific folders (most frequently into C:\Windows\System32) – and sometimes these .DLL files overwrite or conflict with others, which is why you can’t, for example, run two different versions of Microsoft Access on the same PC workstation without some kind of application virtualization. Application virtualization places a sort of “software wrapper” around the application – sometimes referred to as an “isolation environment,” or a “sandbox.” It causes these Registry keys and files to be written to an application specific location, and redirects the application calls so they can be found when the application executes.

By contrast, when an application is executed via Remote Desktop Services (with or without the involvement of XenApp), you’re really virtualizing the presentation of the application. The application is executing on the server, and the user interface is being presented remotely at a client device, using a protocol such as RDP (Microsoft) or ICA (Citrix) to transport keystrokes and mouse movements from the client to the server, and screen updates from the server to the client.

In the old days – and often today as well – that application was installed directly on the Remote Desktop server. Today, we can instead use application virtualization to deliver the application to the server for execution on demand rather than installing the application in advance in the traditional way. But it’s important to understand that presentation virtualization – running the application in one place and displaying the user interface in another – is not the same thing as application virtualization, which, as we have defined it, has to do with how that application is installed on the desired execution platform and how it behaves when it executes.

The first product to do application virtualization on a large scale for Windows apps was Softricity, by a company called SoftGrid. Softricity evolved into App-V after Microsoft acquired SoftGrid. App-V not only virtualizes the application as described above, it also allows the application to be streamed on demand to the computer that needs to execute it. Application streaming works better than you might think, because it turns out that for most Windows apps, most of the code is seldom (if ever) used. (Just think of all the arcane features in Word or Excel that the average user will probably never use.) So we can stream down just enough code to get the user interface up and running, and continue to stream additional code in the background as features are actually required.

The combination of (1) not having to explicitly install applications on workstations (or Citrix servers, for that matter), and (2) not having to worry about applications conflicting with one another can make life much easier for the IT staff:

  • You no longer have to run around from workstation to workstation with a backpack full of installation CDs.
  • It can potentially eliminate the old practice of having multiple “silos” of servers within a Citrix server farm to run applications that would not play nicely with one another.
  • It makes image management for both workstations and XenApp servers much simpler, because if all of your applications are baked into your OS image, then any application change requires that you change (and regression test) your OS image – but if a streamed application changes, all you have to change is that application.

Meanwhile, back in Fort Lauderdale, Citrix had been working on its own approach to application isolation, which was added to the Enterprise and Platinum editions of Presentation Server when v4.0 was released. This “Application Isolation Environment” then evolved into application streaming with the release of Presentation Server v4.5. For those who are familiar with the Citrix application publishing paradigm, you can now:

  • Run the application through the Citrix packaging utility
  • Park the resulting package on a shared folder that’s accessible by your target machines
  • Step through the process of publishing the application, with a new twist: “I want to make this application available to this group of users, on this set of XenApp servers, and here’s the path to the application package.”

NOTE: Yes, I know that not all applications can be successfully packaged for streaming. But most modern Windows applications can be. Yes, you’ll have to test your apps, or, if you have a lot of apps, use a tool like AppDNA to analyze them for compatibility.

Administrative options allow you to specify whether an application package will be streamed to a XenApp server to be executed there, or streamed directly to the client PC to be executed there, or conditionally streamed (e.g., stream to the client PC if a particular set of criteria is satisfied, otherwise execute the app via XenApp). You can also stream it and cache it on the client PC so, in the case of a laptop, it can be disconnected from the network and continue to run the app for a specified period of time.

So, in a sense, the application virtualization component of XenApp competes with App-V. Prior to the release of XenApp 6, our advice would have been to use XenApp to package and stream apps if your need was primarily to serve up apps to Citrix users, and use App-V if Citrix represented only a small piece of your infrastructure and you primarily needed to package and stream apps to Windows-based workstations. This was mostly based on the fact that App-V needed its own servers to control publishing and streaming of the applications – so if your primary need was to deliver apps to XenApp users, it didn’t make sense to build that App-V control infrastructure when your Citrix farm already had everything you needed to stream apps via XenApp.

One of the features of XenApp 6, however, is the ability to deliver App-V packages through the Citrix application publishing infrastructure, without having to build out the App-V back-end server infrastructure. So now you can use whichever packaging tool you prefer with your Citrix infrastructure. If your staff is more familiar with – or just prefers – App-V, it’s not a problem, because XenApp will support those packages natively.

A discussion of application virtualization wouldn’t be complete without mentioning VMware’s ThinApp. A while back, VMware, seeing which way the competitive winds were blowing, realized it needed an application virtualization solution of its own, so it went out and bought one. In addition to packaging and streaming, ThinApp can also wrap an application up as a free-standing executable, meaning that you could theoretically carry the entire Microsoft Office suite with you on a USB stick, and plug it into any Windows PC anywhere regardless of whether (or which version of) Office was installed on that PC. Of course, if you actually did that with a PC that wasn’t already legally licensed for Office, you’re violating your Microsoft Office license, but I digress.

There are other application virtualization products in the marketplace, but at the moment, the “big three” are App-V, ThinApp, and XenApp. However, as I said way back in the beginning of this post, XenApp is more than just application virtualization. And that will be the subject of my next post.

The big Webcast just wrapped up, and will be available for replay shortly at http://www.desktopvirtualizationhour.com. Click on the “videos” tab to get to the selection of recorded videos. Several changes were announced. Unfortunately, they don’t become effective until July 1, but you can’t have everything.

  • VECD is dead, long live the VDA. For all practical purposes, the VECD license is history. Effective July 1, if your client desktop is a PC that’s covered by Software Assurance, you will no longer have to purchase a VECD license to access a virtual Windows Desktop. That saves you about $23/device/year.

    If your client device is not covered by SA (e.g., a thin-client device), you will now be required to purchase the new “Virtual Desktop Access” (“VDA”) license, which will cost about $100/device/year. That also represents a savings of $20/year or so compared to the old VECD pricing model.

    In both scenarios, the “primary user” of that client device now has the rights to access corporate VDI desktops and Microsoft Office applications from other client devices, such as home PCs, Internet cafes, hotel business centers, etc.

  • Windows Server 2008 R2 SP1 will have a couple of new features that will make VDI a friendlier place to go:
    • Dynamic Memory – Provided your guest operating systems support “hot add” for memory, you will be able to configure your Hyper-V host with minimum and maximum memory limits for the guests. So if a VM that’s serving a power user needs more RAM, more RAM will be dynamically allocated from the host server’s memory pool. When that additional RAM is no longer needed, it will be returned to the pool. Note that this assumes that there is unallocated RAM available – this is not the same thing as “memory overcommit.” This should increase VM density and require fewer Hyper-V hosts to support a given number of virtual desktops. Note also that Windows XP does not support “hot add,” so that’s just another reason to make the move to Win7 when you virtualize.
    • RemoteFX – This is a set of technologies that have evolved from Microsoft’s acquisition of Calista Technologies a couple of years ago. It’s primarily a set of enhancements to the RDP protocol, but the graphics virtualization enhancements will also benefit virtual Win7 PCs that are running on a 2008 R2 SP1 Hyper-V host. The performance that was demonstrated during the Webcast was pretty impressive, but in addition, Citrix announced that the “HDX” technology in XenDesktop would be enhanced so it could detect when the RemoteFX technology was present, and leverage it to make graphics performance even better. You’ll find more information on RemoteFX over at the Windows Virtualization Team Blog.
  • The Citrix/Microsoft Partnership is still going strong, and a couple of new promotions were also announced today:
    • “Rescue for VMware VDI” – which is targeted squarely at people who have started to deploy VMware View, and ran headlong into problems with scalability, user experience over WAN links, etc. These customers will be able to trade in up to 500 VMware licenses for the same number of Microsoft VDI Standard Suite subscription and Citrix XenDesktop VDI Edition annual licenses at no cost. Note, however, that these are annual, subscription-based licenses, so they are going to start costing you money after the first year.
    • “VDI Kick Start” – Eligible customers can pay only $28 per device for up to 250 devices to license the Microsoft VDI Standard Suite subscription and the Citrix XenDesktop VDI Edition annual licenses, allowing you to roll out a 250-seat VDI deployment for only $7,000 in licensing costs – roughly a 50% savings. Again, note that these are annual subscription-based licenses, so you’ll start paying the regular price after the first year. Still, that’s a pretty aggressive offer.

The big loser in today’s announcements? VMware. In addition to the trade-in offer, Microsoft made it very clear where they stood. I submit for your consideration a screen cap of the Q&A thread from the Webcast:

If there was any doubt before about where the battle lines are drawn, there shouldn’t be anymore.

In closing, here are a couple of other links you may want to check out:

Bottom line: While I didn’t get everything I’ve complained about in the last couple of blog posts, and I’ve got to wait a few months for some of the announcements to be effective (nothing new about that), it was not a bad day at all. Definitely a step in the right direction.

The TechTarget family of blog sites has a lot of great information. That’s why we have several of their sites linked in our Blogroll (under “Virtualization” in the right sidebar). But one thing that I don’t like about their sites is that – unlike this blog – there is no way to directly comment on their posts. That makes it difficult to respond to posts like the one last week on VMware’s High Availability (VMHA).

In that post, author David Davis opens by stating:

VMware’s High Availability (VMHA) provides high availability to any guest operating system at a potentially much lower cost than other HA options (as you don’t have to pay per virtual machines [VMs] or per server; VMHA is included in the price of vSphere).

I have a couple of problems with this statement.

First, I don’t know what “a potentially much lower cost” means. Is it less expensive than other HA options, or isn’t it? If it is, which other HA options are you comparing it to? If you’re going to throw that line out there, shouldn’t you give us the data on which the statement is based?

Second, it appears that the “lower cost” claim is primarily based on the fact that VMHA is included in the price of vSphere, rather than requiring a separate license. That’s a little like claiming that the high-end German sound system is less expensive if you get it in a Mercedes – because it’s standard equipment – whereas if you want one in your Malibu you have to buy it separately. What matters is the total amount of money I have to spend to get all the functionality I need, isn’t it?

It is true that with, say, Citrix XenServer, you have to purchase a Citrix Essentials for XenServer license to get HA functionality. That will cost you, at the suggested retail price (which nobody actually pays), $2,500 per XenServer for the Enterprise Edition. But the copy of XenServer you’re putting it on is free. On the other hand, vSphere 4 lists for $2,875 per processor, so if I’m using dual-processor servers, I’m looking at $5,750 for vSphere 4 compared to $2,500 for that copy of Essentials for XenServer. If I’m using quad-processor servers, vSphere 4 is going to run $11,500, but I still only need that single license for Essentials. And don’t forget the cost of VirtualCenter to control my vSphere environment, whereas XenCenter is, again, free, and runs on a workstation rather than requiring a dedicated server.

The point of this post is not to argue the relative merits of vSphere vs. XenServer, nor of whose HA feature is better. In fact, if you follow this blog, you’ll know that we’ve raised some red flags regarding how to properly deploy XenServer HA without risking potentially “career-altering” disasters. The point is simply that the old adage “don’t believe everything you read” is particularly appropriate for stuff you read on the Internet. (But you already knew that, right?)

People who throw out unsubstantiated generalized statements need to be challenged. If the TechTarget site allowed comments, I would have challenged the statement there. Since they don’t, I’m challenging it here. If I’m missing something, David Davis (or anyone else, for that matter) is welcome to comment on this post and point out what it is.

Which App Streaming Is Best?

October 28th, 2009 | Posted by Sid Herron in Citrix | Microsoft | VMware - (0 Comments)

For quite some time now, Citrix has had the ability to stream applications on demand, either to XenApp servers, or to desktop/laptop PCs. If you own current versions of XenApp, you can use it. Microsoft also has an application streaming product called App-V, which it evolved from its acquisition of Softricity a few years back. They recently announced that they were going to discontinue the App-V for Terminal Services licenses, and just bundle the rights into what is now (in Windows 2008 R2) called the Remote Desktop Services (“RDS”) CAL. So if you own Server 2008 TS CALs or 2008 R2 RDS CALs, you’ve got the rights to use App-V to stream apps to your Remote Desktop Servers a.k.a. Terminal Servers.

Not wanting to be left out of the application streaming game, VMware went shopping a while back, and bought ThinApp. They maintain that ThinApp is better – or at least safer – because it runs exclusively in user mode, whereas both App-V and Citrix App Streaming require the explicit installation of an agent that contains kernel components.

So what’s the real story? Which application streaming technology should you use? Which is really best? As is so often the case with IT, the answer is a resounding, “It depends.” It’s sometime frustrating, but the fact is that we work in an industry where there is often no single “right way” to do something. But today I ran across a blog entry over in the Citrix Community Blog area that did such a great job of delving into the differences that I thought it was worth linking to here.

Check it out and let us know what you think.