VMware releases App Volumes (formerly CloudVolumes). Hello overlapping product confusion!

Earlier this week VMware released App Volumes, the new name for the CloudVolumes product they bought in August. If you're not familiar with App Volumes, it's essentially a read-only VMDK disk that's mounted into a desktop (virtual / VDI, RDSH, or physical) which is then merged into the existing desktop's disk image.

Earlier this week VMware released App Volumes, the new name for the CloudVolumes product they bought in August. 

If you're not familiar with App Volumes, it's essentially a read-only VMDK disk that's mounted into a desktop (virtual / VDI, RDSH, or physical) which is then merged into the existing desktop's disk image. Any apps in the volume (with they call an "AppStack") look like native apps, and they can use contain per-user data and settings for the apps in each specific volume.

The key is that App Volumes does not do isolation of "problem" apps—for that you'd still use ThinApp. Instead App Volumes is one of the "new style" app delivery products (along with others from vendors like FSLogix, Liquidware Labs, and Unidesk) that I wrote about back in October which offer darn near 100% application compatibility and allow non-persistent / shared images to be a reality today.

App Volumes is not without its limitations. VMware recommends that no more than 15 individual volumes be used per virtual desktop, so enterprises with hundreds of apps will still have to get smart about grouping related apps together into individual volumes (AppStacks) and/or put some apps in the base image. So it's not like you can just blindly use this for every app in your enterprise. Also any AppStacks you assign to users won't actually be loaded until the user logs in, so there are some thing that won't work (like services, though you can get around this by assigning the AppStack to a machine or virtual desktop rather than to a user).

VMware posted a 20-page deployment guide (PDF link) on App Volumes which has more detailed information about how App Volumes and AppStacks work. Reading through it you'll notice that App Volumes has its own web-based management console which is most definitely *not* the same console you use to manage Horizon View. It's funny that VMware used to make fun of Citrix for having so many different solutions and management consoles while VMware had one. But of course it's easy to only have one console when you only have one product.

Now in the desktop personality and app management department, VMware has App Volumes, ThinApp, Horizon View published apps, Mirage, and Persona. The Venn Diagram of these overlapping features looks like the Olympic rings. It will be interesting to see which of these products VMware kills off, which they integrate, and how they will position each of them.

For example, we're already seeing them say things like "AppVolumes can be leveraged for non-virtual (i.e. physical) desktops, but the focus is on VDI use cases." WTF?!? So... should we use it for physical or not? VMware also says that App Volumes is for "dynamically delivered apps" while Mirage is for "image management to physical PCs through static image composition." But I thought Mirage worked with View now? And if I want App Volumes to work with all apps (like those with services), then I need to assign them to machines rather than users, which means it's "static, right?" So which do I use when?

And then of course the App Volumes' AppStacks are not compatible with Mirage images which are not compatible with Horizon images... so yeah, it's still kind of a mess. (To be clear, I'm not saying that App Volumes is bad. I'm just pointing out that it's funny how VMware was all high and mighty about having a simple EUC environment with a single console, but now that they've bought a few different products we find that's suddenly not the case. Welcome to the EUC big leagues!)

Will any Citrix customers use App Volumes?

VMware App Volumes is now included as part of Horizon 6 Enterprise (for no extra cost), which is great. What's interesting is that it's also available in a standalone version for non-Horizon (i.e. "Citrix") customers.

VMware specifically calls out Citrix XenDesktop and XenApp as use cases and targets for App Volumes. I wonder what the story is behind this? I mean publicly of course they're going to say, "We want to support everyone, we believe in rainbows, etc." but privately they've got to be annoyed that they have this technology which will be sold into their biggest competitor's environment. Maybe they view this as a wedge that can show existing Citrix customers how awesome VMware is with the hopes that they switch over to Horizon View? Maybe CloudVolumes had Citrix customers before VMware bought them and they have to honor those support agreements?

If you were a Citrix customer, would you actually go out and buy an app delivery product from VMware versus just using FSLogix or Liquidware Labs or Unidesk?

Overall I'm a big fan of these new-style app delivery products—App Volumes included. And it's great that VMware was able to re-brand the product in three months and get it bundled into Horizon View. But man, there's still a long road ahead for VMware to cull their app and profile products and to get the real integration done.

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

We are a citrix shop and we were also a cloud volumes customer before they were acquired by vmware.  I would not go with FSLogix as their product has more limitations than App Volumes.  The features of app volumes and the upcoming features are still a great benefit to our environment.


its not uncommon to have overlap. Its a buy vs build thing.  If you built everything yourself there are neat little boxes and groups that dont step on each other. But overlap is almost unavoidable (FOR ANYONE) when buying new tech to fit into an existing market they are already in. For sure something so broad as "desktops" and so basic as app delivery you are going to have overlap. would happen to anyone... Dint MS have "overlap" with Softricity and SMS Sure one isolated the app, but both did app delivery (of a sort) and I am sure there was some confusion from those that didnt know the difference.

No biggie. But the console lines are funny. You are right, that was a key point for VMW reps. Single console, simplicity, Xen Hard, too many consoles, etc.


I can tell you that many of our Citrix customers are on board with AppVolumes.  Many already use it.  


I hope that Citrix can change PvD to be more like App Volumes.  The backend technology is similar, just the execution of the technology is different.

Also App Volumes has some neat features, like mounting from a CIFs share, instead of being a live vmdk tied to the machine.  And support physical and non-vmware hypervisors.

Was kind of sad when vmware picked them up.  They say they won't be limited, but you never know what the future will bring......


@Brian Holy misinformation and chest thumping :-) Next time perhaps just ask me for the technical details...

Curious why you think we don't deal with Windows services? Have you been talking to people who have never used the product? We deal with services and drivers, but leave the lowest level drivers like AV in the base image, because our philosophy is not to shoe horn our technology into every layer of the stack. Our point of view is that you are better of using best of breed technologies to give maximum flexibility, else you end up being SMB focused because you can't scale to enterprise needs and won't be able to leverage innovation like VMFork to enable JIT desktops. It's why we are winning in big enterprise, vs. walking in and saying rip out everything you have every done and use a single technology approach to solve all your problems.  Enterprise customers laugh have lot's of sunk cost in what they do and only change when there is a compelling reason to do so. In our case those customers want a new way to deal with application lifecycle management only. Hence AppVolumes focuses on just that.

Why do you think we recommend 15 or so AppStacks at the top end? We can do as many as anybody else and face the same limits they do, as these are OS and hypervisor limits. Our view is not to over complicate the management model. All players in this space can add many AppStacks, but there are other tradeoffs. Most big customers are quiet happy with- Core Apps, Country Apps, Regional Apps, BU apps, User apps. That's 5 AppStacks to keep things simple. Anything beyond that, they can still add more AppStacks, use streaming apps, published apps etc. The key point is that the 80% use case is addressed this way in a simpler more scalable model. In future we will make this even simpler. Simplicity is the point as opposed to number of AppStacks, which often is used as competitive FUD by people who don't understand the technology or the practical enterprise implications as they have never worked in a large enterprise or sold to one...

You are correct we are not in the isolation game for the most part. First, technically it's not quiet correct as we can achieve some based on search order for a file within and across AppStacks and manage via policy. However, in general we want to increase app compat and focus on native installation. The combination of classic app-virt with App Volumes gives us the unique ability to address a broader set of use cases without the overhead of streaming.

WRT to physical. Yes you can use it, our recommendation is to use it for non-persistent use cases and we have folks who want to build non persistent physical desktops and use App Volumes to enable some cool use cases. I just visited the Mirage team this week, great team.  You will see us do more together in 2015, watch this space. In general Mirage are focused on physical use cases and App Volumes on non-persistent use cases. So Mirage is great for helping customers manage distributed physical devices that have been poorly managed in past, without all the complexity and infrastructure of SCCM and is great for backups etc.

Single console. I actually think that this one of great blogger myths fanned for far too long. Actually what people want is simplicity of experience. That does not have to mean one console and for many enterprises they want no console and just an API to fit into their custom console. In many cases I find people want common work flows between the products and ways to do things consistently once. Trying to do that in a single pane is not always simple or the best approach and can lead to confusion. But I agree we need to do more, to simplify our experience with all these cool assets we have. That I promise you will happen over time. The alternative is to be like the other guys, have no capability and keep telling the world that remoting bits over a wire, is application lifecycle management and try to sustain legacy...

I think you have know for a while, that CloudVolumes supports Citrix, most of our customers were on Citrix. We will continue to support Citrix and do even more for Citrix customers. It makes a lot of sense to bring our value to as many customers as possible, it's a worthy problem to solve. We will build a deep and robust solution and Citrix customers that we have today and will have tomorrow should have confidence in our commitment to support them.

VMware EUC is very different to what you have perceived it to be in the past. There is a renewed focus and we have a lot of smart people who get what needs to be done and are very enterprise focused. There is plenty more to do we know, but by golly we are chomping at the bits to push every day and certainly offer a unique set of capabilities that others can't match and are being reflected in the market share numbers.


For the misinformation, everything I wrote was what I pulled from the docs on vmware.com that I linked to, so if anything is wrong then you need to get those updated.

For services I wrote that you can't assign AppStacks with services to users but you can if you assign them to computers. I got that information from here: www.vmware.com/.../vmware-horizon-view-app-volumes-deployment-guide.pdf. In the Best Practices section, it says: "Install applications intended to run after a user has logged out into the base image, as opposed to installing them into an AppStack. AppStacks assigned to users are not attached when the user is not logged in, and therefore are not available to execute as a service."

In that same section of the document is also says, "Limit each virtual desktop to no more than 15 attached AppStack volumes," so that's where I got that number from. My understanding is that yes, this is due to limits in Windows and the underlying disk drivers, but this is absolutely *not* something that affects every new-style app delivery vendor. If you're building only 5 AppStacks (core, country, regional, dept, user), that's a pretty different philosophy than using this for every app. (Well, I guess that's where the name comes from.. app "volumes" and not just "apps"). I'm not saying it's bad, but it means that App Volumes is something more like image management and deciding which apps go together versus a pure "just wrap all your apps and never worry about them again."

For the comments about a single console being a blogger-fanned myth, oh I can tell you that is absolutely not a myth. I was personally at the VMworld where VMware made fun of the "other guys" for having too many consoles, and for VMware having one console. They had a slide where everyone laughed when they said they just had one console. (Obviously this is something they've moved away from recently.)

"Holy misinformation and chest thumping" <-- I'm adding that as a LinkedIn endorsement!


I should add, "Good thing that only this chest-thumping blogger is confused!" I'm sure all these overlapping products and features are totally clear to all these customers with actual enterprise experience, to those who have used the products, etc.

It's probably just me who's a dumbass.


Granted, the way Unidesk and AppVolumes does things is different but Unidesk does allow for 50 layers per desktop on the vSphere platform.


I haven't personally reviewed the doc, and it could be an error in the doc. But I can tell you with 100% certainty that services in AppStacks work. The attach time at user login or machine assigned depends on the app. So best practice would be, if app requires services to be running before user login then put it in the base. Else attach as user login. Common sense best practices for the most part, but fair if the document is confusing confusion. I'll get it edited.

Regarding number of AppStacks, I'm not sure how you make the claim that others are different. Can you explain why you think so? There are a finite number of iSCI controllers or in guest mounts you can use. Same limit for everybody. Our point of view is, the management model is too complex for most people to deal with then you build too high in terms of AppStacks. Hence experience has shown 5-7 logical groupings with app isolation deal with 90% of the use cases, rest in base and 2% exceptions delivered another way. Our enterprise customers tell us AppStack per app is a model they don't want. At thousands of apps, it's too complex even for them, hence they want to scale horizontally more and we are working on a few things to give them even more control to do that. So yes you can treat it like image management, or you can treat it like per app management. Our view is pick the simpler one for the majority and use individual app stacks as an exception.

WRT to console, I think you are making a different point. You are pointing to a marketing position of what was said at time X. I'm talking about what I hear from enterprise customers. For example I have a customer currently who does not want to use our console and directly via API attaches AppStacks to the client via their custom workflow. So number of consoles to them is not relevant. They want rich and well documents APIs. Others for sure want a more unified console, and there I agree as we add capability and continue to integrate will be something we make better. The danger that you are perhaps missing is that you could end up with one really big complex console, and this is not what was really wanted. Hence I think the single console thing, whether it's a marketing position or a blogger assertion, missed the point of the goal that the customer is trying to achieve and assumes single console is the solution to meet the goal, without understanding the true problem and root cause. These mental biases can lead to really bad products.

It's pretty simple actually, focus on the customer goal. Want app isolation, use ThinApp. Want real time delivery and lifecycle management use App Volumes. Want to do complete central image management for physical devices use Mirage. Can we provide deeper integration of workflows between these products, maybe a single console, sure and we will continue to do more in that space. Dumbass, no. Are you confused and jumping to conclusions perhaps. Do we need to do more to educate and clarify docs, yes.


@Jeff, so can we, and go to something like 256  with in guest VHD mount mode to support physical and Hyper-v use cases. It's a management model that is overly complex, simplicity wins IMO. Talk to a paying large scale enterprise customer and it will become clear very quickly.


Harry, so what's the new name for VMware FlexCast going to be? The way it's looking from where I sit is instead of VMware building EUC differently than Citrix they have pretty much carbon copied it.

Yes AppVolumes is awesome technology but to think for a second that Citrix will sit idle watching VMware eat their lunch is crazy. An FSlogix or similar acquisition is inevitable.

I'm with Brian on this one, great post.



this article pleases me greatly


@Elias Not sure what lunch you are talking about. Microsoft ate Citrix's app anything lunch with App-V when Citrix gave up on App Streaming. Too much field conflict with Microsoft, so instead of building out a solution, they caved. So I see what we have as value add to customers to solve a big problem who want to stay with Citrix. I make no apology for that. In fact when we were still CloudVolumes, a Citrix person that I won't name told us during a fairly high level meeting, that if customers wanted to solve this problem they would have already built a solution. So I guess when you believe pixel remoting is a silver bullet and Microsoft won't give you permission to do much more than sell app-v and SCCM it's understandable.

That's what I love about VMware. We're not concerned what Microsoft dictates.  Due to our size and strength of our portfolio, we can invest and solve problems in new unique ways. So I'd welcome Citrix getting into this space, I have friends there whom I have a lot of respect for. The challenge they will find is it's not that easy and the continuing investment levels mean you really have to want to change the game here and ignore status quo Microsoft. Adding a simple feature or making PVD do late binding is got going to bring home the bacon. There are a lot of other things to do, a lot... There is also a poor categorization in the market. Folks like to lump everything into one bucket as new ways to do apps, but don't understand under the covers what it takes to achieve this. Perhaps a good BriForum session for somebody independent to explain the differences in approaches.

Ha Flexcast. It's really a function of what the market wants. As our share grows, no doubt we will have to build out capability to match Citrix and in many cases exceed. The goal is  customer success and addressing their needs. As a result we are rapidly growing our market share. So say what you want, shareholders and customers like it. :-)


@Harry you are someone whose opinion I have always respected and enjoyed reading but changing your opinion radically as you change hats does not help reinforce that opinion. I still remember those tweets when you were Insistently and persistently challenging VMware CTO at the time Steve Herrod on EUC> Now that you are at VMware it seems that Citrix is doing everything wrong?

The App-V example you gave is not any indication and I don't believe for a second that Citrix made the wrong choice by stopping development of Application Streaming technology. The penetration of that product within the customer base was very low and I know first hand as I deal with these customers every day. Second, even application virtualization in GENERAL as a market does not have that big of a market penetration so what is the point for Citrix to pursue development of a product that not only has very limited penetration within its customer base but also in general? Citrix was spot on with that move.

I am a huge fan of VMware and as a disclaimer I am a multi-year vEpert, I have written over 4 books on vSphere and have done several video training on it as well. I am a fan, BUT, let's be honest here, what has VMware done with ThinApp? what improvements or development effort has VMware put in ThinApp? I will venture to say that App-V 5 is much better, at least MS invested in App-V what has VMware done with ThinApp?

As far as mu FlexCast comment it came after reading what you said: "It's pretty simple actually, focus on the customer goal. Want app isolation, use ThinApp. Want real time delivery and lifecycle management use App Volumes. Want to do complete central image management for physical devices use Mirage. Can we provide deeper integration of workflows between these products, maybe a single console, sure and we will continue to do more in that space. Dumbass, no. Are you confused and jumping to conclusions perhaps. Do we need to do more to educate and clarify docs, yes. "

that just felt like FlexCast and sure it is always about what the customer wants, but I expect VMware to be innovative, App Blast was innovative, carbon copying the Citrix message is not innovative. Sure you are taking market share, but you are taking that share because there are many Citrix clients that are disgruntled with bad implementations and frankly Citrix's arrogance. Citrix never had competition so they never needed to care THAT MUCH, now VMware is delivering EXACTLY Citrix's message with a polished name and hopefully learning from the CItrix mistakes. Frankly? good for VMware, but I would still ike to see some innovation.



@Elias Don’t think my opinion has radically changed. Remember at the time VMware was a VDI only company and since then a lot has changed for the better. My broader point is that Microsoft won't allow Citrix to innovate on things that impact them due to field conflict and that kills innovation. It's an unfortunate truth and it's a delicate dance for Citrix. At the same time, it's also hugely disappointing that Microsoft has never made App-V a part of the platform to allow the eco system to extend. Instead Microsoft uses it to sell MDOP and that's what causes conflict in the field.

WRT App-V vs. ThinApp. I think the core isolation engine in ThinApp is very mature and pretty much can virtualize as much as App-V can. App-V has done more in terms of shared cache, dynamic sweeting etc. However with ThinApp plus App Volumes the need goes away, and nothing stops customers using App-V with App Volumes if they want to. The reality is that application isolation or application virtualization, is not a technology that is going to be main stream. Hence App Volumes focuses on native installation to overcome a lot of the limitations for a much broader market.

We can never afford to be arrogant or sit on our hands. But I am not sure you can claim we are not innovating. Innovation happens on many dimensions, including building out new capability like RDSH for us. We've acquired a few innovative companies and continue to develop their capabilities.. We'll certainly be doing more, you'll hear more through 2015 and that will underscore how we think about EUC differently. However, I am always interested in hearing from folks with good suggestions. Also WRT market share, the latest analyst market share numbers I saw, showed us the market is growing again after a dip over the last few years. That growth plus our portfolio is driving our increased market share. The overall market growing is good for all. Competition in a growing market will drive innovation vs. just swapping dollars.


I won't get into the technical arguments, but I will answer Brian's question about Citrix users.  The answer is absolutely yes.  It's why I spent an hour at VMWorld talking with Kit Colbert while wearing a Citrix tshirt (yes, I am that kind of guy).  Let's all be honest here, Citrix PVD is a god-awful product at any scale.  For years they have promised increased functionality and true layer segmentation, giving us the ability to roam PVDs across a pool rather than create static assignments.  I think that was the very first question I asked our sales team when they first presented the technology.  And nothing has been delivered since.

As far as the competing technologies like Unidesk, AppVolumes, FSLogix and FlexApp the truth is that in a lot of ways choosing one becomes a matter of your needs.  A valid argument can be made for any of the major players.  In fact talk to FSLogix and one of their sales pitch items is that it can enhance AppVolumes delivery, which I found interesting.  And conversely, all have their weaknesses.  But all of them are markedly better than PVD.  

My major concern quite honestly though is price.  Prior to the VMWare acquisition CloudVolumes was in what I thought was a reasonable price space.  At real volume it could get downright cheap ;)  Now... not so much.  List price on it makes it prohibitively expensive to tack on to your overall per user cost.  I've tried to make that point clear to VMWare as well.  It has to be cheap enough that Citrix admins can afford to run it on top of ESX licensing, Citrix licensing, OS licensing, Office licensing... you get my drift.  Otherwise it prices the main use case (non-persistent VDI) right out of the market.


@Elias, There is no way Citrix is going to get into this space in anger. Just look at the fact Brad Anderson is speaking at Citrix Summit next month (although video). Citrix has bigger fish to fry- building on top of remote app to help Microsoft sell Azure and retain top *** status. In fact there is no need for Citrix to do more, than simply confuse the market by selling Unidesk into accounts where App Volumes is trying to get traction and keep saying App-V with SCCM is their preferred MS suck d1ck management play. Unidesk are more mature at the layers thing, but they are VDI only so that's a weakness that others will point out, although they are doing more now with Hyper-V and RDSH. Citrix will also likely tread carefully with Unidesk because that would be seen as SCCM compete by Microsoft. LWL are a waste of time, crap tech and company, and FSLogix, with app hiding and unhidding is not even a comparison, but could be a neutral feature that solves a different problem and helps with remote app.

@Paul, agree PVD sucks, warrants some investment, but geez it's so bad, it will not get the love it needs to compete. That's why I believe Citrix will partner as opposed to piss off Microsoft and focus all efforts on CWS to enable Azure and ease XenApp/XenDesktop deployment. I suspect that will be the big Summit announcement, XenApp/XenDesktop managed from Azure and lot's of partner love.

@Brian, I like the FU Microsoft stance being taken by VMware here, and I actually have more confidence in VMware doing something in this space vs. Citrix. The only question I have is, does VMware have the stamina to evolve the technology to do more for enterprise customers? Something Microsoft and Citrix don't. Do that, and I think it's worth people's time even if they are on Citrix. Make it just a feature to sell more enterprise and VMware will fail. Time will tell, as the I suspect App Volumes still has to mature over a few releases. @Harry I assume you work with App-V anyway as it's just a file in your volume, so embrace Microsoft is also just as valid an approach.