The first “real” layering product? MokaFive’s new v2.0 looks pretty good!

Last week MokaFive released version 2 of their desktop virtualization product (which I don’t think really has a name apart from just “MokaFive.”).

Last week MokaFive released version 2 of their desktop virtualization product (which I don’t think really has a name apart from just “MokaFive.”). If you’re not familiar with MokaFive, they’re a desktop virtualization software company that’s focused on managing client-side virtual machines. (If you’d like to see a quick demo, they were our random vendor of the week on the April 2 episode of Brian Madden TV.)

MokaFive’s v2 release is a big deal because it’s quite possible the first real implementation of a “layering” style of management for a virtual desktops.

“Layering” is the concept of dividing Windows into several layers, for example, the system, applications, and user personality. Redirecting disk changes to specific layers would allow you to update one layer without affecting another. For example, users could install applications into the “user layer,” while admins could patch and update the “OS layer.” As long as your layers were built right, each one of these could be updated on its own. (We first discussed this “layer” concept back in April 2008.)

Trying to solve this layering problem in tough, and unfortunately it looks like Microsoft is not going to do it for us. Companies like Atlantis are trying to solve the problem from the disk image creation standpoint. AppSense is approaching it from the user environment standpoint. InstallFree and Viewfinity are approaching it from the application standpoint. And now MokaFive is approaching it by intercepting the way a VM writes to its disk.

To really understand this, it’s important to know a bit about MokaFive. As I wrote, MokaFive’s sole focus is virtual machine management for end users. Right now they’re all about running VMs on client devices in Type 2 virtualization environments, be it Fusion, Virtual PC, VMware Workstation, or Virtual Box. What’s interesting about MokaFive is what they’re doing in those environments, specifically, how they’re focused on how disk images are built, distributed, and updated.

For instance, one of the early things MokaFive was known for was that they could make a VM run off of a USB stick. (e.g. you pop the USB stick in any computer, it has the VMware player, some config info, and the disk image, and you can run the VM without touching the local PC.)

If you’ve never tried this, you’re probably thinking, “So what? I can do that now. Just run the free vmplayer from the stick. Point it to a vmdk on the stick. And boom. I’m done. Very simple. Totally free!”

If that’s you, go ahead and try that and let me know if you can get Windows to boot in less than 5 minutes. It is NOT a good experience. MokaFive tore into Windows to figure out how it works: What data MUST reside in the disk image? What can be safely cached to the local disk? What must be thrown away after each session? What must be securely deleted after each session? How can we run this on a host with no install and no residual risks?

MokaFive also worked out a way to centrally create, deploy, and update the disk images. Unfortunately in doing so, they ran into the same problem that most desktop virtualization vendors run into, namely, if an administrator makes an update to an image, the act of pushing out the update destroys any customizations or personalizations the user has made outside of his profile.

And herein lies the reason for building this “layerization” technology into their v2 release.

So MokaFive’s v2 product lets you slice-and-dice Windows to specify which files, folders, keys, and locations belong to which “layer.” Then updates and changes are saved to the appropriate layer which makes incorporating multiple layers easier later on.

This also has the effect of enabling “user installed applications,” which means that users can install their own apps, and admins can update the baseline apps (or Windows image) without breaking anything the user did. And while this concept has been around for awhile, it hasn’t really been put into practice yet due to technical challenges. (MokaFive believes they can overcome past challenges because they’re starting with the presumption that all users are sharing the same baseline image. In other words, they don’t have to figure out how to make all user-installed apps work for all images on all hardware—they only have to make it work from one instance to another of the same Windows VM.

What’s most interesting about MokaFive moving forward is that there’s absolutely nothing holding them Type 2 virtualization environments. Since they just ride on-top of other environments, it seems like a no-brainer that they’d start working with companies like Virtual Computer and Neocleus to bring the MokaFrive disk image management platform to their client hypervisors. So while MokaFive v2 is only a week old, I’m excited about the prospects of this company and the product!

Join the conversation

13 comments

Send me notifications when other members comment.

Please create a username to comment.

Brian, finally you get it almost :-) good write up, I have been a huge product fan for ages. This is a very cool product and makes a massive difference if you understand the value. Some other key points are.


1) Due to the layering approach, you can apply patches as updates to an image remotely without disrupting a user, which offers a huge benefit for remote management which is a massive headache. All those who suffer through remote management know exactly what I mean. This powerful feature is so poorly understood, one should not underestimate it's value.


2) MAC, they provide TODAY the ability to manage VM's on a MAC! Management corp image on a MAC is very powerful!


3) Security policy, they provide the richest policy engine that I have seen on the market. Kills ACE hands down, no comment on MS killing this for Kidaro/Med V :-( and why this is a great MAC solution for an Enterprise.


4)  There is no reason for this MANAGEMENT technology not to port to Type 1 over time when the hardware is refreshed etc etc. No reason to lock into Type 1 now, and Type 1 solutions have no mgmt around them today making them not secure as the hype presented by the vendors, so this is the only game in town that provides the greatest device flexibilty NOW.


Would love to learn and debate if anybody thinks there is any other viable enterprise class solution on the market that they are serious about implementing NOW.


Cancel

It is great to see further innovation in this area, since I think end-user personalization is one of the big remaining dominos that needs to fall before client-side virtualization really takes off.  The big win of client virtualization is lower TCO for the IT team through one-to-many management of the OS, but if it comes at the expense of end-user experience it is never going to go anywhere.


I’d definitely welcome the opportunity to take a fresh look at Moka5’s latest stuff to see if it’s a complement to Virtual Computer.   However, our company is really defined by the management features we enable more so than our hypervisor, and I personally view clever virtual desk management and user personalization layers as table stakes for being in the client virtualization game.   This is not to say that it is an easy problem to solve.  I am not convinced that anyone (including us) has reached nirvana yet around end-user personalization.  However, NxTop has some significant personalization layering capabilities out of the box, including:


- Ability to map Windows disk writes into three top level layers: system data, user data, and local data.  (System and user data are pretty self-explanatory.  Local data is anything that is user or PC specific but that doesn’t need to be backed up, such as Windows search index files or Outlook OST caches - very big and rebuilt automatically through other means if we migrate the user’s VM to a new machine.)  At the same time, if you did for whatever reason just want to put this stuff into retained layers, you can do that too.


- The system layer is updated centrally by IT using our NxTop Center console, and deltas are applied to each endpoint in the background.  By default, the system layer reverts to clean state on reboot or system update, shedding malware and overcoming the “Windows just keeps getting slower the longer I use it” phenomenon.  However, any baseline user personalization (profile, application settings, docs, etc.) remains safely tucked away in the user layer.


- The user layer is snapshotted periodically (frequency based on IT-defined policy) on each endpoint, ensuring that all end-user documents, settings, profiles, etc. are backed up centrally through upstream delta transmission to NxTop Center.


- The local layer gives us place to among other things park any “bad sub-layers” like really big, frequently changing indexes, caches, temporary Internet files into the local layer, so we are not clogging up the client’s bandwidth and storage with a bunch of stuff that isn’t actually needed to recover the user’s personalized envrionment to a new machine.


We recently announced a new feature called System Workbench that is really the framework for the IT team to manage all these options centrally in an orderly way.  We have talked to hundreds of IT folks, and most told us that “locked down” desktops with no persistently retained user-installed apps will not fly.  At the same time, they also generally don’t want the wild west where a user can install any app they want into the corporate image.  What we ultimately arrived at is a policy framework where the IT admin can grant users personalization capabilities at whatever level is right for their organizaiton.


As a basic example, maybe I have Internet Explorer as the only browser option in my base shared image, but I have a situation where either everyone is allowed to install other browers or only certain people are allowed to install other browsers.  As an admin, I can create a policy on NxTop Center called “User-Installed Browsers Bundle” that includes specifications for number of additional browser options like Firefox, Chrome, etc.  At the admin’s option, this policy can be applied to (a) all users of the shared image, (b) a group of users, or (c) a single user of the shared image.  If a user doesn’t have the policy, they can install Firefox into the shared image (assuming they have rights in the OS itself), but this layer is shed on reboot.  If they do have the policy, the user can install Firefox (or any other browser included in the bundle) into the shared image and the resulting sub-layer is retained across reboots.


This is not a perfect approach, and we are by no means done innovating in this area.  However, until we (and others trying to solve this problem) can guarantee that layering will either work (or minimally fail gracefully) with any conceivable app that a user could try to install, having the IT admin let a little bit of rope out at a time is the way to go in my opinion.


Cancel

Brian, thanks for the writeup.  Some additional points I think your readers would be interested in:


1. Assuming an organization allows users to install their own applications, users can do it on their own, without administrator intervention. When system updates happen they are dynamically applied while persisting the user personalization layer (including the applications).  Administrators can disallow this feature by policy.


2. Our layering supports any application, including kernel-mode apps, as users would expect.  MokaFive layering approach does work gracefully with any application that user can conceivably install.


3. Users can return themselves back to the original image state and remove the apps they’ve installed by clicking a “rejuvenate” button.  Their data and settings will not be affected.


4. Administrators can also granularly “whitelist” or “blacklist” (selectively allow or disallow) certain applications or components.


5. Administrators can deliver any application as a separate layer including applications that are deployed by standard software distribution tools such as Microsoft SMS or Altiris. These apps do not have to be virtualized applications – they can be standard MSI packages.


6. Our layering works with all application virtualization solutions that we have tested with including Xenapp, Thinapp, and Appv and all anti virus solutions.


With these capabilities you can truly achieve at least one of the holy grails of virtual desktop management: central control and updates while enabling mass customization.


Cancel

Mokafive is one of those companies I wish I could get some seed money from management to really throw this at some use cases. I participated in a demo of theirs a month or so ago and the staff was very helpful, friendly, and extremely knowledgeable and the technology really worked. Plus, the red head on their site is really hot!


Cancel

@ Purnima -


I have a question as to why Moka5 chose to support  Type 2 and not Type 1 with the release?  (And I mean Type 1 as in ESX not xenClient)


Is this because of


1. historical reasons (Moka 5 started as a consumer play) or


2. are there   architectural reasons  - you're using OS specific  Block based Copy on Write capabilities   ([Q]COW/linked clone) that are enabled by/on  the host OSs filesystem. That would mean you cant "just port" and work on type 1  or


3. is this what customers want from Moka 5 - the ability to provision corp images to employee owned desktops/notebooks (and as appdetective points out macs) which already have a pre-provisioned OS on them without needing a new generation of notebooks shipping with Type1 enabled?


thanks!


Chetan Venkatesh


www.atlantiscomputing.com


twitter.com/chetan_


Cancel

Hmm, the title of this article suggests that Brian hasn't been evaulating and testing as many products as he should if he believe the first "real" layering product is v2.0 of MokaFive.


RingCube vDesk had this basic concept available when we launched v1.0 back in Sept 2008.  But there were several other companies who have offered non-virtualized layers through profile mgmt for years (AppSense, RES, etc.). Granted it's not as extensive a layer mechanism as a virtualized layer but it still has value.


Layering, particularly for personalizing non-persitent VM pools for VDI deployments, is still a very important issue that hasn't been solved by traditional VDI vendors.


There's been more extensive research done in this area by Gartner which really strikes at the heart of why "LAYERING" is important. On June 18, 2009, they released a report titled "Why, How and When to Personalize Hosted Virtual Desktops" ID Number: G00168186


It states "The vast majority of [VDI] pooled images are standardized and locked to permit automated management. Although personalization is technically possible [on VDI], it complicates management processes, adds to cost and is rarely (if ever) permitted. Gartner has spoken with over 400 organizations about pooled HVD deployments since mid-2007 — less than 1% of these had deployed or intended to deploy pooled images in which personalization was allowed to persist.”


Layering is one of the crucial components to allow VDI to expand beyond the basic task worker.


Workspace Virtualization, which can be deployed as a "layering" mechanism for VDI, will likely be the key ingredients to broader adoption of VDI.


Cancel

@chetan - My guess is that they went with Type-2 because it eliminates most of the driver difficulties.  Type-1 is great from a performance and security perspective, but it's also much harder as you need to have driver compatibility with a billion different types of hardware, etc.  Or you just keep a limited HCL.  Hey it worked for VMware in the server space.  But PC/laptop market is a bit harder.


@doug - While you are correct that MokaFive isn't the first layering approach, I wouldn't go so far as to directly compare MokaFive to RingCube.  MokaFive is built on top of VMware Player and therefore is an instruction set or hardware virtualization layer.  RingCube is a bit closer to an Application / OS Virtualization layer whereby it's still dependent on a common underlying OS (i.e. you can't run a MojoPac virtual environment on top of a different operating system version).  MojoPac also has limitations from a security perspective in that you're at the mercy of the integrity of the underlying OS.  While MokaFive and any other type-2 solution has somewhat of a similar security risk, they are somewhat insulated by the nature of the VM running instruction set virtualization (well a little isolated as there's still several points of security concern).  Anyway, keep in mind that layering and user customization isn't low hanging fruit in the VDI space.  There's plenty of ways to achieve user customization in VDI.  Where the real value of a managed Type-1 or Type-2 solution is frequently disconnected remote users (aka laptops).  This is where you'll see many companies adopt a Type-1/Type-2 solution.  Me?  I've still got reservations in several areas, but that's a topic a BriForum session in three weeks ;)


Shawn


Cancel

1) Great to see Chetan on here bringing another view and asking questions


2) Doug Dooley's name and avatar scares me but man the guy does make some good points


3) @ Shawn, Where do you see a technology vendor like MokaFive providing the most benefit to your customers?


Cancel

@shanetech,


"Where the real value of a managed Type-1 or Type-2 solution is frequently disconnected remote users (aka laptops).  This is where you'll see many companies adopt a Type-1/Type-2 solution."


Couldn't have said it better myself.  No wait ;)


Cancel

@ Shawn,


Thats cool, just was wondering if there were any real implementations you have done and what the primary focus of that business unit might have been because I have been thinking about where that might fit at the company I work at.


Cheers,


Shane


Cancel

@Shane -


No implementations yet.  I just like to keep my eyes on all the players in this industry.  Still having a heck of a time getting to work with some of them though (not MokaFive).


Shawn


Cancel

@Shanetech


OK, I changed my avatar to something less scary (I hope). BTW, that other cartoon avatar was one of the stock ones that everyone can choose from when you create a profile here.


That said, I can see why you might be creeped out by it. When I was a kid, I was scared of Mr. Rogers (non-threating but yet still creepy). That avatar was like the Mr. Rogers of avatars.


;-)


Cancel

@Chetan


MokaFive key value proposition is in providing central cloud based management with the power of local execution, therefore the focus on client based hypervisors. Architecturally, the MokaFive solution is designed to be platform and hypervisor agnostic, be it Type 1 client hypervisor, Type 2 client hypervisor, baremetal or a server hypervisor (such as ESX). We have focused initially on Type 2 since it addresses the immediate customer needs around secure mobile access and enabling platform choice for users.


We will be blogging more on this topic in the coming weeks. Stay tuned at http://mokafive.blogspot.com


Cancel

-ADS BY GOOGLE

SearchVirtualDesktop

SearchEnterpriseDesktop

SearchServerVirtualization

SearchVMware

Close