Thoughts on VMware project Meteor, Fargo and APP Volumes
Thoughts on VMware project Meteor
Today I did two presentations about VMworld 2014, one for a sales group and one for Consultants. Interesting were the different discussions and questions you get from both groups. The discussions got me thinking about what I was presenting…Thought I share these with you.
Project Meteor is a combination of Project Fargo and the acquisition of Cloud volumes, renamed App volumes at VMworld 2014 Europe. The idea behind project Meteor is that you can provision a desktop in seconds and assign applications to it while the user logs on. All actions has to happen Just-In-Time when requested.
Fargo is a very interesting project that is all about Forking which is pretty interesting but also very difficult to understand. So what is Forking? Forking is an operation where the process creates a copy of itself (According to Wikipedia)
Sure I hear you think, and what has that to do with my virtual machines?
Well what VMware intends to do with this is that they want to fork a virtual machine for you.
When they fork this virtual machine they create a copy of it while still sharing the memory pages and so on. Once you logon to that virtual machine it will be start using resources and drift away from the parent virtual machine.
So I got the question what the benefit was?
There are some benefits that we can talk about, resource usage and flexibility being two of them.
Flexibility is the biggest gain from my point of view. With project we always have the issue that you need to schedule a maintenance window to update the virus scanner and Microsoft updates. With Project Fargo the virtual machine, instead of now, the golden image is running all the time.
The biggest difference from that point of view is that the golden image is running when being forked. So all the maintenance windows are dropped and this would be the best solution for any 24/7 organisation.
Let’s go a bit deeper in that topic.. 24/7 organisations like hospitals are always struggling with how to find time to update the image. Citrix has a similar kind of solution with Citrix Provisioning Services that allows to offline update the image but it doesn’t allow for a running golden image that is streamed instantly when someone requests a desktop.
VMware however, when they get this done, will have a live running golden image that is updated throughout the day 24/7, always up-to-date when being forked and deployed for a user.
The second benefit is that you don’t need all the hosts and the virtual machines running all the time saving resources. Virtual machines will be made available the minute a user requests a desktop so you don’t need to deploy all machines on forehand. This would bring out the possibility of Green IT where you power on the hosts that are needed and leave the rest off.
App volumes is all about applying read-only application volumes to a desktop. App volumes can be used with VMDK’s or VHD’s but only VMDK’s will be assigned through a vCenter call. when you use VHD you will have to stream them over the network, losing most of the benefits.
Got several questions what the use case was for App Volumes, of course it sounded interesting but especially sales people had a hard time seeing the benefits.
One of the use cases that I explained to them is that of multiple base layers of applications. Let’s get into that for a moment. With all current projects all desktops have a common base layer of applications. These applications are Office applications, Adobe reader and apps like that. Because building more base layers would mean we need to deploy multiple desktop pools, one pool and one layer is used now.
For many customers this is not the ideal situation for not all departments are the same and we would like to differentiate.
With App Volumes this would be a very good option, for each department a different application volume could be assigned. This would lead to one stateless desktop pool being deployed and multiple base layers holding the applications each department needs.
One extra benefit is that it might even be a benefit for the application licenses for if the application is not accessible you don’t need the license. Of course you need to be able to prove users can access the application and that area is still open.
Persistent – non-persistent desktop
The second benefit of App volumes is that you can assign a write-able volume next to the read-only application volume. Users can use this write-able volume to install applications is or store files. These applications will be kept there when the user logs off.
When the user logs on again at a newly created desktop this write-able volume is connected again and the applications are available instantly.
This brings out a very wanted possibility and that is creating a state-full desktop experience with a stateless desktop. State-full desktops provide users freedom allowing them to install applications and store files while stateless desktop are not fit for this. State-full desktop have a downside where they need much more storage for they all are full desktops.
So when you have a stateless desktop where attach a write-able volume to allow that freedom of installing application you create a state-full experience for the users.
Together is better
Putting these both together bring you project Meteor, a fast virtual machine deployment with much benefits for 24/7 environment and a flexible application deployment solution to bring state-full experience to users.
I’m pretty interested where this is going and when we can play with all this..