Thursday, July 30, 2009

Back from Briforum

Back from last week’s Briforum conference in Chicago, and I must say it was an enriching experience. How many people can say they rode to dinner in a stretch Hummer with 30 other geeks?

The amazing thing about Briforum was the content-rich discussions. Unlike other shows I’ve been to, Briforum was a super concentration of the leading practitioners and researchers in the virtual desktop space. Moreover, there was a candid, open sharing of ideas -- and a sense that no one has this figured out, so let’s all push it ahead together. Very refreshing.

In particular, I really enjoyed Ruben Spruijt (Twitter, blog) and Shawn Bass’ (Twitter, blog) overview on application and desktop delivery solutions. Impressively, in 75 minutes, it covered the full expanse of virtual desktops and applications. I left with a much better sense of the “lay of the land”.

IMGP8287.JPG

For MokaFive’s part, John Whaley (Twitter) and I held a session on the huge promise of layering in virtual desktops, and it’s ability to greatly improve manageability of VMs for IT on the one hand and the customizability of VMs for users on the other. We had a terrific turnout and many great questions from the audience, even though we started at 5:30pm and lasted way into the dinner hour. A testament to dedication and fortitude of Briforum attendees!


IMGP8160.JPG

Update: John just posted a short video demo where he gives an inside view of our layering technology. This is a "short and sweet" clip of what we showed during Briforum.



For more photos of BriForum, check out Brian Madden's Flickr stream and the fan section of MokaFive's page on Facebook.

Burt Toma

Wednesday, July 29, 2009

Tachibana teams up with MokaFive in Japan

Today we announced Tachibana Eletech Co. Ltd as a MokaFive distributor in Japan. With nearly 90 years under its belt, Tachibana is one of the most respected and well-established Japanese technology firms and will be a solid partner to bring MokaFive solutions to market.

Security and cost are two of the most important factors influencing the deal, according to Masao Hamamura, operating officer, Information & Communication Systems at Tachibana. His statement for our press release today was, "Security is a top concern for our enterprise clients, and MokaFive provides the best solution to secure desktop environments in a wide variety of secure remote computing scenarios. Another major factor that makes MokaFive Suite platform superior to competitive products is that it does not require our customers to invest in new hardware."

This is MokaFive's first major international channel partner announcement and with MokaFive Suite available as an easy-to-install platform, building out the channel network will be a primary focus for us. In addition to consulting, reselling, and developing systems using MokaFive, Tachibana will also use MokaFive technology to develop new products to extend its thin-client business unit, TC Cube.

Wednesday, July 15, 2009

USB drive testing at MokaFive

The USB flash memory drive market has been changing very fast. A few years ago, a couple hundred dollars would get you a slow 4G drive. Now, the same capacity costs less than $20. However, not all drives perform the same and we have tested a lot of them at MokaFive.

We test USB drives for performance and reliability and have found that more expensive drives do not necessarily mean they are faster or more reliable. Although USB drives look simple, there is a lot of science behind building a good drive and it's not easy for the average consumer to get product specs without digging through reviews or actually running tests firsthand. We found that drives from same vendor may perform differently since performance depends on the flash memory and the USB controller that the drives use. Our CTO, John Whaley, discussed the nuances of USB drive performance with Robert Scheier from Computerworld last summer. Here are a couple of excerpts from the article:
The single biggest factor in USB drive performance is whether it contains one of two types of memory: SLC (single-level cell) or MLC (multilevel cell). SLC stores one bit, and MLC stores two bits of data in each memory cell. SLC is twice as fast as MLC, says [Pat] Wilkison [vice president of marketing and business development at STEC Inc.], with maximum read speeds of about 14 MB/sec. and write speeds of about 10-12MB/sec. Not surprisingly, almost all current USB flash drives are built using MLC memory, since SLC costs about twice as much as MLC.
Users would see the greatest performance difference between SLC and MLC if they were performing many operations involving small files, rather than relatively few read/write operations on larger files, says John Whaley, principal engineer at MokaFive Inc., whose virtualization software makes it possible for virtual machines to be stored on USB flash drives.

Beside basic manual testing and normal day-to-day use, we also set up automated tests to run on these drives. We test our client software on them and we also run various performance benchmarks. We want to make sure they perform well when our customers run their virtual desktop off the drives. We also test for reliability by plugging and unplugging the drives continuously.

Here is a photo of a device we put together to automate testing.

In addition to the standard benchmarks of MB written and read per second, we have some custom tools which more accurately measure how a drive will perform when running Mokafive LivePCs. These tests give us two “scores,” one of which correlates to speed, and one which correlates to responsiveness. Read and write operations to a drive can have varying delays. We’ve found that measuring how many of these delays take more than 100 ms gives us a good idea of how responsive the drive will feel when running a LivePC. We’ve found that sometimes even drives with higher overall read and write speeds will have more delays, and that when running a LivePC, that drive will feel more sluggish to the user than a drive with fewer delayed operations.

At Mokafive we’ve also developed some technology to make running LivePCs on USB drives faster, more robust, more user-friendly, and more secure. We also run our tests on this software to measure the improvements that we’re able to make. As an example, a particular drive got a “speed” score of 8.2 and a “responsiveness” score of 6.7. When running our USB drive acceleration software, the same drive got a “speed” score of 9.4 and a “responsiveness” score of 8.6.

A couple of years ago, we even custom made our own drives, so we could control the quality of the drives.


The following table shows some of the results from our latest round of testing:



























USB drivesMaxWrite (higher is better)MaxRead (higher is better)MokaFive rating(higher is better)
OCZ Throttle22506350359.4
Patriot Xporter XT5798303936.8
SuperTalent 16GB7821181046.2



We have more results available upon request. And if you are planning to deploy your virtual desktop using USB drives and need some recommendations, please feel free to contact us. I am sure our experience in USB flash memory drives will save you a lot of time and money.

Friday, July 10, 2009

The Basics of Image Management: Targeting & Policy Control of Virtual Desktops

In the world of server virtualization, one of the challenges is to manage all those virtual machine images. An enterprise may have a couple hundred servers but they may have a couple THOUSAND virtual machine images to manage. The reason for having so many images is that IT needs to support different OSes, different software stacks and different applications, etc. There are image management tools for server virtualization that sell for thousands of dollars just to keep track of the images.

If an enterprise is going to virtualize their desktops, the images management may become an even bigger problem. Is IT going to set up one VM image per user? Probably not. But what if different users need different applications or different access control policies? Is IT going to set up one VM image per difference? Maybe. But should they?

There is a better approach - achieved through two management concepts related to targeting and policy control.

The idea behind targeting is to allow an IT admin to "target" a particular version of an image to a particular group of users along with a unique set of access control policies. For example, Group A will use Image X and their policies are set so that they cannot paste copied data outside of the VM.

For the same Image X, IT can target it to Group B with a different set of policies. Targeting makes this possible with just a few clicks in the management software and doesn't require the creation or cloning of any images.

Different group of users can also be targeted with different version of the same image. This is great for quickly and easily testing changes to an image without a lot of fuss. For example, if the IT admin adds an application to an image but wants only a few people to test it before it is released to everyone, he or she can target the update version to a smaller group while everyone else stays in the current version.

Once everything is tested, the admin can switch the update version to become the release version and everyone would automatically get the update. It's important that only the changes to the image be sent out to users, so that users don't have to download the entire image again. When just the differential is sent the image can be updated in the background without disrupting the user at all, saving a lot of time and bandwidth.

Another way to simplify image management is to make sure that when IT updates an image, all the access policy settings remain unchanged, avoiding major headaches and time sinks. For instance, if IT has one Image X targeted to Group A with Policy 1 and the same Image X is targeted to Group B with Policy 2. When IT releases an update to the image, both groups will get the update while keeping their respective policy settings.

Of course, MokaFive's 2.0 technology and the MokaFive Suite incorporates the sophisticated image management functionality of targeting and persistant policy settings.

Here is a video that demonstrate these management features. Take a look and let us know if you have any feedback.

Monday, July 6, 2009

v2.2 is available!

You may be wondering why we are releasing 2.2 so quickly. Didn't we just announce 2.0?

Good question. The truth is, v2.0 has been available to our existing v1.7 customers for over a month. They have been using it and giving us a lot of valuable feedback. Last week, we announced v2.0 publicly along with a new Website. Now anyone can purchase the MokaFive Suite v2.0.

Today, we released v2.2. It includes a few bug fixes plus the following new features:
  • RSA SecureID support
  • Co-branding support
  • Using Amazon S3 as the Primary Image Store
If you haven't checked out our v2.x product yet, please contact us to schedule a demo or a trial.

Wednesday, July 1, 2009

The nitty gritty: Brian Madden notes MokaFive has the first "real" layering product

Brian Madden has just written up an article on our 2.0 product titled "The first “real” layering product? MokaFive’s new v2.0 looks pretty good!" and I would like to follow up on it by providing a few additional details.
As Brian mentions in his article, our technology separates the system state, application state, user installed applications, user data and preferences transparently. To the end users, when they use a Windows XP LivePC, they will just use it the same way as they are using their Windows laptop.

An important point is that we allow the IT administrator to customize and control the policies. An IT admin can enable or disable user installed applications from the centralized console and also edit the layering policy file and determine what the system should or should not preserve. For example, IT can choose to only approve use of MSN instant messenger but not Yahoo IM. He can edit the layering policy file to only preserve all the settings and files related to MSN IM. If the user downloads and installs Yahoo IM on the corporate LivePC, it will be wiped clean when the user reboots the LivePC.

There is a misconception that layering is easy. When scrutinized, it is clear that it's quite a complex proposition. Our first implementation three years ago was similar to other offerings today. Originally we used junction point to separate the Windows "Documents and Settings" folder to a separate disk and then preserved that disk. However, we learned that does not work for all applications and system preferences. Some times applications or the system needs to put data in locations other than the user folder. That's why we spent time developing this advanced system for dealing with sophisticated requirements for the broad variety of applications a user could choose to install.

The layering technology is cool but what makes it very powerful is the flexibility it provides to the IT admin to customize for your organization's needs. In the upcoming weeks, we will be writing more articles on how to configure and deploy Windows XP LivePC using this new feature.