Is VMware tricking customers into using VDI when RDSH would meet their needs for a lower cost?

Earlier this week I went down to San Jose for a briefing with Nimble Storage about what they're doing in the VDI space. I was blown away by how many of their VDI reference clients were on VMware Horizon View using shared non-persistent images based on linked clones.

Earlier this week I went down to San Jose for a briefing with Nimble Storage about what they're doing in the VDI space. I was blown away by how many of their VDI reference clients were on VMware Horizon View using shared non-persistent images based on linked clones. I just couldn't believe how many of these projects could have been handled no problem with RDSH / Terminal Server infrastructures.

So what the hell is going on here?

I don't want to get into the whole "persistent versus non-persistent" debate again as we covered that ad-naseum (here and here) a month ago on this site. But regardless of which side of that debate you're on, you have to admit that there are plenty of non-persistent VDI environments in the world that would work perfectly fine (and be much cheaper) with RDSH. When I dig further into this phenomena and talk to actual customers about why they're using VDI instead of RDSH, many of them are unable to provide a good reason. (Well, they can't provide a "good reason" based on my opinion.) I can't get over how many of them have preconceived biases against RDSH, with many citing "facts" about RDSH that haven't actually been true in years.

So again, what the hell is going on here?

I point the blame at VMware, who even today in 2013 is spreading FUD about RDSH. For example, from VMware's 2103 document titled "Why Choose VMware Horizon View over Microsoft RDS 2012?" they wrote:

In comparing VDI and sessions, VDI offers the following advantages over sessions:

  • Eliminates application-compatibility issues
  • User or OS resets do not impact other users (sessions require resetting entire server)
  • Provides better native-application compatibility
  • Eliminates application-to-application conflicts in a multi-session environment 
  • Applications do not have to be written with TS or RDSH in mind (i.e., desktop applications are supported)
Really this is just two points, as Items 1, 3, 4, and 5 are just different ways of saying the same thing. But in Server 2012, how much is application compatibility really an issue? And of course VMware doesn't mention that the hardware needed to run 175 VDI desktops is several times more expensive than the hardware needed to run 175 RDS sessions. (Not to mention the fact that VDI requires SA, is not available with SPLA, and requires one license per client device, while RDS sessions require a simple one-time purchase of a perpetual RDS CAL that can be bought per user and is available via SPLA.) And for "user or OS resets," what exactly are they talking about? Shared VDI requires resetting the OS every time you recompose the desktops, and doing that blows away any changes the user has made. (So if your users are doing anything that require an OS reset, then you're going to lose those changes when you recompose anyway.)

Later in that same document, VMware also writes:

If you are considering a choice between VDI and RDSH, consider the following questions:

  1. Do you have users that require constant up time?
  2. Are you concerned about your application licensing agreements being valid in a multi-user environment?
  3. Do your users need a full desktop experience, i.e., admins of their own machines, unique application requirements, and varied and broad USB device support? 
  4. Do you want or need the flexibility to easily migrate users between servers?

An answer of “yes” to any of these questions indicates that VMware Horizon View is a better solution for your environment than RDSH.

Again, more hogwash. Users that require constant uptime? What's the advantage that VDI has over RDS sessions? That you can live migrate a VDI VM? Yeah, you can live migrate an RDS host too. Application licensing concerns? Total bullshit that we put to bed in 1998. Microsoft and the other app vendors have stated over and over that if you use permissions to restrict access to applications, then that complies with licensing. (Otherwise you'd have to license every user for every computer in your company, because technically a user with a domain account could walk up to any workstation and login.) USB support? Seriously? That was solved back in RDP 7.1 in Server 2008 R2. And the flexibility to easily migrate users between servers? In RDSH, the user just logs out and then logs back in to a different server. Or if they're talking about live migration, you can live migrate an entire RDSH VM. (Okay, if they're talking about session-level live migration, you can't do that in RDSH. But do you want to pay 3x hardware costs for VDI to do this? VMware should point that out.)

As far as I can tell, most of the people using VDI where RDSH makes sense are VMware environments. This makes sense because VMware Horizon View only fully supports VDI. (VMware can broker connections to RDSH sessions, but then only via RDP and without many of the additional benefits like View Persona and advanced printing. So no VMware View customers really use that because if they did then why are they paying for View?

The other reason these scenarios tend to be VMware customers is because Citrix XenDesktop customers also have the option to use XenApp. So most XenDesktop environments are really XenDesktop / XenApp combinations, whereas most Horizon View environments would have to buy additional licenses to use RDSH or they'd have to fall-back to the "in box" Microsoft technologies to deliver RDSH.

I'll say it again for the thousandth time: There are many very legitimate use cases where delivering Windows desktops from the datacenter makes sense. Some of those require the full workstation experience of VDI, and others are fine with RDS sessions. In 99% of the cases where VDI "wins," it's because the customer needs 1-to-1 / persistent disk image models since most environments where linked clones and non-persistent VDI is feasible can simply use RDSH for about one-third the cost.

Based on all that, and based on talking to several actual VMware Horizon View VDI customers, it's my belief that the vast majority of environments based on shared VDI would also work perfectly fine with RDS sessions. Sure, we can come up with very tactical reasons why shared VDI makes sense over RDS sessions (like the one-in-a-thousand app that doesn't work on RDSH), but for 99% of shared VDI environments out there, that is NOT the reason they're using VDI. They're using VDI out of ignorance or because they love VMware or because VMware gave them free View licenses with their vSphere purchase. If you don't believe me, take a serious look at the VMware View customers you know and count up how many of them really need VDI versus how many would work fine on RDSH. It's a shame.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

I think you cite an important point here.

In my experience existing Citrix customers tend to leverage their existing Citrix relationship. So if they have had XenApp before, and now see a good usage for desktops as well, they pick XenDesktop - although 60% of them do it on vSphere :-). It's regarded as less political and easy way to silo responsibility.

If the customer is a VMware shop, with no really previous engagement with Citrix then they tend to use VMware View. There has to be something REALLY compelling to bring in another vendor. And as you say, VMware offers terrific deals on View, that squeeze out the competition.

I imagine that the technical differences that are important to you and me, don't really figure in the customers - they see an easy option to provide a hosted desktop in the datacenter with minimal effort. And from a management perspective it becomes a system the "VMware Admins" (if such a thing exists!) manage.


As for RDP/RDSH. No-one seriously uses that junk with end-users do they? It's horrible...


I was under the same thought until I saw the Login VSI  presentation during Briforum.  It showed that if we take out disk IOPS out of the picture, a Physical server can run as many sessions with VDI as RDSH.  This makes this conversation moot.  I would rather give users isolated VMs that can be modified and controlled separately than bunch up users to windows servers.  I can then distribute GPOs, memory and cpu better to users that way.


Restrepoj, here's the thing, you CAN'T take IOPS out of the picture for VDI.  Any attempt to do so is just hogwash.  I'm a big VDI supporter (it pays the bills) but Login VSI is full of it if they are making a comparison that way.  


Rick I totally disagree.  in 2013, we have many solutions that can give the IOPS that VDI needs without breaking the bank.  O would also say that IOPS should also be a conversation to have with RDSH and that the numbers are not far off in their comparison.  you can use SSDs solutions like Atlantis ILIO that you can use without rebuilding an environment


i meant to say SSD solutions AND/OR Atlantis ILIO


Brian, since I have no dog in the race, I’ll share some of my thoughts intermingled with what I have learned talking with customers and competing in deals. Essentially what you are saying is the following:

- RDS is better/cheaper than shared non-persistent VDI.

- App compatibility and user session isolation advantages are not there for non-persistent VDI.

- HW and license costs are higher for VDI.

- Uptime/License/USB/Migration arguments don’t hold water.

- People pick based upon current infrastructure status quo biases and 1-1 persistent VDI is when VDI makes the most sense today.

Lot’s of valid points, and I’m a big fan of RDS. However, here is what I have learned/observed over the years.

- There is only so much user density that people want on hardware before the risk of failure is greater than the benefit.

- Modern approaches allow for far greater density of VDI on hosts with commodity hardware at an attractive price/risk point. This makes it good enough from a price and capability POV in many cases.

- The OS reset argument in my mind is less about persisting state; it’s more about sharing a kernel, users stepping on each other etc.

- SA for enterprise customers is becoming far more common and is negotiated in EA deals. So less of a barrier and the license barriers are mostly at smaller SME type customers who lean towards RDS or for service providers wishing to offer SPLA. However with VDI becoming easier and cheaper with modern approaches the argument there also gets weaker and IMHO further pushes RDS to an edge case for many.

- Personally I’m interested to see if the DaaS model evolves to disrupt this segment of the market.  I think attempts to date have been half-baked and as a result many write off DaaS prematurely.

- Customers WANT non-persistent VDI as a better way to manage their desktop estate amongst other reasons, while providing a full desktop experience vs. RDS, which implies silos of apps or desktops. Granted that capability, as your links above point to in my previous articles is not quite there. However the salient point is, that is what a lot of people aspire to get to and they know RDS is the wrong approach to achieve that. In short they want to solve the pain they live with PC life cycle management. RDS doesn’t achieve that, since an enterprise desktop environment is very diverse.

I also believe that the investment being made by the industry incumbents and their respective eco system is heavily focused on enabling VDI as opposed to RDS, which is considered mature. So when customers see that, coupled with what they really want and a healthy dose of marketing. It is no surprise to me that many try to make VDI work as a forward-looking strategy.

So while I agree with you that many use non-persistent VDI blindly when RDS would suffice for their use case. I think it is super important to look at new approaches and disconfirming evidence to appreciate why RDS also sucks as an architecture for the future to get to truth about when to use one vs. the other.  


Couple of points: I would suggest that Vmware "tricking" customers into buying VDI vs RDS is bit of an exaggeration. They are selling "what's on the truck" to informed consumers. Tricking implies underhanded sales staff and gullible consumers. With the level of access to information today, I would be surprised to find uninformed customers. It's easy to get information that balances VMware's marketing. Call Microsoft or Citrix. Simple.

Frankly, the statement is not fair to either party. Good headline though.

Harry suggests that customers "want" VDI. Lets clarify that statement to mean that "IT admins" want VDI .....for its proposed cost savings, improved security and better management. I will not argue the merit of those marketing statements here.

But, let's agree that end users do not want VDI. They want a reliable full featured personalized desktop experience. And that usually means a desktop/laptop PC with local processing power  and mobility. VDI is still limited by IOPS, graphics and network constraints, not to mention off-line capabilities.


Marketing is marketing...

But a few points regarding Non-P VDI vs. RDS:

1. Cost of Non-P VDI is close to par with RDS when using the free tuCloud DaaS Engine and SSDs. If you even want to avoid the SA or VDA license you can use WS 2012 and a perpetual RDS CAL as the Non-P VDI OS so now it's apples to apples licensing costs. Harry knows this one all to well. ;)

2. Persistency can be enabled on non-P VDI which allows application installations/deployments in a variety of ways using scripts, GPO, app publishing, and even user installed applications (which our users require). RDS cannot acheive this.

3. In my environment, users not only want a reliable full featured personalized desktop experience, they also want to use it from home and have access to our online applications and databases. VPN is no good because the application needs to be close to the data for performance otherwise data is transferred and computed over the WAN. This results in a bad user experience therefore virtual desktop is better than a local physical desktop.


Bottom line:

Don't stereotype a technology, the use and cons/benefits are dependent on the requirements and use cases.

VMware is guilty of this.

Citrix is guilty of this.

Brian is guilty of this.


I'd argue that Brian's not stereotyping anything. He's simply stating that most of the View installations could get away with using RDSH because most View installations are using non-persistent VDI.

VDI compared to RDSH is great if you want the flexibility of VDI. I think it's fine to make the correlation, as Restrepoj did, that the density numbers between VDI and RDSH are very close to one another, while disregarding IOPS for the moment. Storage is still a cost…nobody is saying that it should be ignored, but when looking at one solution over another simply based on density, they are almost the same.

The question is now to weigh whether or not the added cost of storage is worth the extra flexibility you get. If I'm using persistent VDI, I'd be happy to spend the extra money to get the added flexibility of a persistent VDI environment.

That majority of that flexibility, though, goes away when you use non-persistent VDI, and if you ask me whether I'd rather use RDSH or the similarly-featured, more expensive, more complex non-persistent VDI, I'm picking RDSH unless the use case dictates otherwise. Keep in mind, too, that we're not talking about RDSH by itself…it could be any of the solutions out there like XenApp, vWorkspace, Server 2012, or even Teradici Arch (if you've committed entirely to PCoIP).

It's a simple matter of use cases and tools. VMware is trying to make it look like View is the tool to solve everything, and even though it might be able to solve a specific problem, that doesn't mean it's the best way. VMware's main competition in the space is Citrix, who has an RDSH solution. Of course they'll have a plan to attack that as an option and try to convince people that VDI is the only way to go. If they had an RDSH product, you can damn well bet that literature wouldn't exist.


Ughh!!! I am glad it's after hours and I am having a beer enjoying this thread.

OK here's the thing. I am blown away how organizations jump on the non-persistent VDI band wagon yet have avoided an RDS solution for the last decade because it is too hard.

Organizations avoided RDS because it was too difficult to know what users were using, what they were doing. But non-persistent VDI avoids this? NOT!!!!

Understanding the user activity is the challenge to implementing a dictated workspace. Figure that out and then deploy on the cheapest solution that meets the requirements...COUGH COUGH RDS...


I think Harry Labana has a point in stating that you can more or less provide as many Non-P VDI users as RDSH on the same hardware. So where points can be gained (in my opinion) is in the ability to combine those models, and also add streaming to bare-metal, remote-pc, etc. (you guess which certifications I hold). But having built I-don't-know-how-many "traditional" SBC environments it still baffles me that the 'offline VDI' solutions like MokaFive, NxTop/XenClient aren't adopted - I really think that it would beat VDI AND RDSH for lots and lots of customers. More difficult maybe, but users get to use their own local resources. Much better....



Fair enough. I thought Brian's statement regarding nonP VDI can be mostly replaced with RDSH was stereotyping nonP as never persisting when it can be enabled and in some cases with no added cost. Unfortunately there is an added cost to get the storage savings that nonP provides in P virtual desktops.

Here's my stereotype:

RDSH = legacy model lock-in



By definition, nonP *is* never persisting, because it it persisted then it would be called "persistent" instead of non-persistent. (And persistent I like.)

So I still stand behind my original point, that many nonP environments can be replaced at RDSH. As for me liking persistent, that still applies, regardless of whether they start out as persistent or non-persistent.



Who's paying you now, MSFT? They covering your bar tab for the 40 attendees at the Madden forum?

As usual you're the one spreading FUD.Why no mention of Citrix "tricking" customers?



Is MSFT covering the tab again for the 40 attendees at the Madden Forum? As usual, you're the one spreading the FUD...

You've had an issue with VMware for years, I'm just pissed I actually wasted 10 minutes of my life (will never get back) reading your post.


This is a typical reaction: Assume that I'm paid by whichever vendor I haven't written anything negative about most recently. So yeah, instead of looking at the facts about what I'm writing about, it's easier to jump on the "Brian is shady" bandwagon. Good move!

I stand behind my views, though perhaps I should have chosen an article title that wasn't so provocative. (Though if I did I doubt we'd have 17 comments.) The facts remains that (1) I have spoken to several customers who are running nonP VDI where RDSH would be fine (and cheaper), and (2) every scenario where I've seen that has been a View shop (probably because Citrix has an RDSH option, so if you're running XenDesktop for VDI and you also can use RDSH, then you'll also add-in some XenApp).

That said, I'm always interested to hear more. What do you think that VMware is doing right, and in what ways is Citrix tricking customers?



I believe the definition of Persistent is 1-1 as in describing a technology that distributes one OS disk image to one user. Non-Persistent is 1-n as in describing a technology that distributes one OS disk image to many users. Non-P desktops can have personalization but this should not make them Persistent by definition unless they are 1-1.

Having non-persistent desktops even if they are used without personalization still enables a business to explore other technologies that add onto the stack to enable personalization. If the businesses went with RDSH they will be stuck.

Use case dicates which technology but tomorrow's problems are not solved with today's solutions.

I am sorry to digress from the original point of the article which I agree with. VMware is ignorant and passing that ignorance onto potential customers.



I was referring to these links which define the Persistent and Non-Persistent models. You are actually the author of one of them.

I will try to further solidify my point with this analogy:

If I bought a 10 year bus pass for work it would be useless if I got a new job at a location where there are no bus stops.

I stand by my stereotype:

RDSH = legacy model lock-in

Why lock yourself into a legacy model if price points can be nearly identical to better future proof your organization?


The argument that "RDSH is too old" is funny,sobering,market-driven,silly,understandable,and somewhat accurate. There's a wide range of delivery vehicles, and RDSH is still drivable. And whenever anyone uses "future-proof" as criteria, I immediately check to see if my wallet is still there.


Everyone seems to be missing one point. With VDI you are all assuming that windows desktops will be around forever?? I am sure everyone agrees that the desktop O/S is becoming less relevant so it comes back to the million dollar question "aren't apps more important"?? and if so why are we making such a fuss about delivering windows desktops using VDI? Many enterprises need Windows Apps but sure as hell don't need windows desktops (go and speak to a Google customer, there are plenty of them!)


After reading this thread, here are things that come to mind:

- Most enterprise organizations that are actually using VDI are still trying to figure out how to get their users to adopt it.

- The users that are adopting it are using persistent desktops.

- If an application works in a non-persistent image, it's best to deliver it from RDSH as a seamless windows app.

- If an application is mission critical or needs to be delivered to the masses, it's best to deliver the application as a seamless windowed app using XenApp and PVS an an application silo.  

- Who wants to update 40 non-persistent VDI "golden images" to roll out an update or roll back an application, along with rebooting thousands of machines.  This doesn't allow the business to be more agile, it makes it more confusing and cumbersome.

-  Nobody wants to bring down a mission critical application (Manufacturing, Inventory, EMR, Bank Teller Systems, etc,) just to update or install a non-mission critical application into a desktop golden image, when it requires a recompose or any form of reboot.

-  When the business unit wants to roll out an application, they don't want to hear that you have to create a new VDI image or sort through which images the app has to be managed in.  They just want the icon to appear on the desktop with no downtime.  Why put the cart in front of the horse?  (Desktop before Apps)

-  Though hardware acquisition costs for VDI are getting closer to what they are with RDSH, the amount of complexity involved in achieving those cost models are at least 3 times the complexities of RDSH.  (Each VDI is it's own OS to manage, think 5,000 users = 5,000 additional IP addresses, 5,000 additional VMDKs, 5,000 objects in the management console, 5,000 VMs to care and feed for.  (vs 300 XenApp VMs and 3 PVS servers ?)

-  Nobody wants 40+ images with different application sets, that come with additional complex technologies like Atlantis ILIO, Liquidware FlexApp, and POD architecture to keep in sync.

I think we all get caught up in how easy it is to build something and how cheap it is to aquire the technology versus how much it takes to keep it running and the complexities in managing an architecture that doesn't make any sense.  

Storage technologies require a storage team to manage the fabric, the spinning disks, the configuration of disks and LUNs as well as all the software technologies on the storage infrastructure as well as the hypervisor side like Atlantis Ilio.  The ongoing management costs and complexities are often overlooked.

RDSH, XenApp and PVS (and now MCS in XD7) are always going to be 3 times better than non-persistent VDI.  As Rene mentioned, non persistent images makes more sense in client side technologies like XenClient and MokaFive, where the apps are moving away from being managed there.

I'm not sure what my point is here, but I don't think there is a very big market for non-persistent VDI that RDSH technologies like XenApp hasn't already solved in a big way.


@Icelus I'm not sure I get your point re lock-in with RDS?  If you go down the RDS path you are no more locked in than going down a particular vendor's VDI path - less so as you don't need to invest in Atlantis, FusionIO, SSDs or other tech to negate the IOPS penalty of VDI.

My personal experience lately is a big swing away from straight VDI to XenApp or XenApp/VDI combo as users look for ways to deliver Windows apps to tablets and BYOD devices.


The general idea Brian is getting at is that most organizations using VDI might have a 100/0 or even 50/50 split with RDSH, when it could be more like a 30/70 or 20/80 VDI-to-RDSH ratio. This becomes especially prevalent in the SMB space.

Basically, just don’t be too hasty to assign a VDI solution to customers without checking first if an RDSH solution will suffice.

In all organizations, SMBs especially, the Cost-to-Functionality ratio (or “Value”) is critical to determining a solution’s true efficacy. If they can get the same thing achieved for a third of the cost, why wouldn’t they?

Sometimes the solutions and marketing terms can get mixed up, which is why it all comes down to what the customer needs and wants. They have work that needs to be completed, and they need technology to help them get that work done. They don’t care what solution they use, but they do care how it behaves as a solution. Cost included.

I just wrote a longer blog piece about "VDI, can it eliminate RDS?"; you can find it on our website at .