It’s Official: MokaFive Goes BareMetal

Regular readers of this blog will recall that in June, we blogged about MokaFive BareMetal Player, which we were taking the wrappers off for industry insiders at BriForum. At VMworld we made our bare-metal preview official and demoed it to an appreciative audience. 

This comes, of course, at an interesting time. Just last month in its earnings call, , VMware killed its bare-metal hypervisor.  And just last week, Citrix decided to package its long-awaited XenClient bare-metal hypervisor with XenDesktop in an effort to get it to market faster.

With all the news, our bare metal solution was received as a welcome change.  The sentiment was echoed by Timothy Prickett Morgan of The Register in his eloquent (and irreverent) coverage of VMware, Citrix,  MokaFive and more.

We developed MokaFive BareMetal Player because our customers are asking for a solution that lets them forget about everything except the VM. They want to be able to run directly on the hardware and they want the same management they’re used to already with MokaFive Suite. And that’s exactly what we have with bare-metal: it provides a thin management layer that sits on the baremetal hardware, thus eliminating the cost  burden of managing additional OS’s and licenses.

Best of all, MokaFive BareMetal adheres to our commitment to deliver “choice computing.” In the bare-metal world, that means supporting a broad range of hardware—not half a handful of narrow configurations, and certainly not hardware deals cut in the backroom to lock customers in.

We believe our BareMetal will be a real game-changer in the desktop virtualization space. Like MokaFive Suite, BareMetal is designed to fit into existing infrastructure and to always be OS- and hardware-agnostic.

Take a look at this link of John Whaley’s video chat with Brian Madden at our VMworld booth. Generally, the response to BareMetal has been on par with Brian’s reaction – great! NetworkWorld even listed us as one of the hottest Vendors at VMworld.

 Purnima Padmanabhan, VP of Products & Marketing

VDI post on Madden: good observations, different conclusions

Last month, I predicted that VDI will be just a niche play as the cloud matures. Yesterday Brian Madden posted a dramatically different perspective about the extent to which VDI will penetrate computing.

This perspective was not his own, but he thought it interesting enough to write about it. The problem though is that although the observations are reasonable, the conclusions are awful.

Let's look at specific examples.

First, the post notes that computing is changing rapidly, and of course I agree. More apps are moving toward the cloud for simplicity and portability reasons. The apps that will be left behind are rich applications that require local execution. The problem with VDI in this scenario is that you get the worst of both worlds: you get neither the simplicity of the cloud app, nor the functionality of a local app. It just doesn’t make sense to take your fat desktop and stick it into the cloud (except in niche scenarios), since VDI will only become more cumbersome as the cloud matures.

A second observation in the post invokes Moore’s law, saying that as servers become better and cheaper, the cost of VDI will drop. This might be true if users continue to use the same applications, but that’s not how computing works. Applications will continue to expand and consume the additional server bandwidth, negating any savings from Moore’s law.

Thirdly, the post goes on to describe deployment models. The primary pain point that desktop virtualization solves is desktop deployment and centralized management. With a client-based solution, IT can provision an additional VM simply by publishing an html link and sending an email. It’s cheaper, faster, and more resilient than provisioning additional boxes in the datacenter, as you do with VDI.

The post also completely ignores some fundamental issues with VDI. For example, a defining characteristic of VDI is the pooling of resources in the datacenter, but the downside to pooling is that you are magnifying the risks and complexity of desktops—the classic “eggs in one basket” problem. With VDI, you are taking inherently resilient, distributed desktops and turning them into a highly concentrated system that is vulnerable to malfunction. With VDI, if the system goes down, all your desktops go down. A related problem is that IT has to over-provision in order to prepare for peak capacity (e.g., 9:00am on Monday morning). But it’s difficult to predict group behavior, and your “over-provisioning” may prove inadequate, anyway.

Finally, the post fails to address Madden’s own Offline Paradox. Offline capability is at the core of VDI’s shortcomings. There are many times when a user finds himself without an Internet connection, such as on a plane or when the connection goes down for whatever reason. With VDI, users without a connection are unable to access their virtual desktops. This is a key area where a client-based approach excels.

What do you think the future holds? Will virtual desktops live in the datacenter or on the host machine?

Purnima Padmanabhan, VP of Products and Marketing

Back from BriForum 2010

Just got back from BriForum 2010, it was a great show as usual. This was the largest BriForum yet - both the attendee count and the exhibitor count were higher than ever. We had a table this year and got a lot of traffic. It was nice because most attendees were pretty knowledgeable about desktop virtualization and understood the benefits of client-side execution with central management, so we didn't need a lot of explaining for people to "get" the MokaFive solution. People loved our BareMetal demonstration and the fact you could manage both the BYOPC/work-from-home machines as well as BareMetal from the same management interface.

But without a doubt the best part of BriForum are the quality speakers and technical sessions. BriForum has a core of truly great presenters and speakers who talk technical and avoid FUD and marketing spin. People like Shawn Bass, Ruben Spruijt, Jeroen van de Kamp, Claudio Rodrigues, Steve Greenberg, Ron Oglesby, Tim Mangan, and Rick Dehlinger, just to name a few. And of course the man himself, Brian Madden. The presentations are great with a lot of technical meat behind them and mostly avoid the high-level fluffy marketing speak that you get at most other conferences. They are 75 minutes so you can actually get into some depth. The great presenters are what make BriForum a great event and I'm proud to have had the opportunity to present at the last two BriForums. The organizers also do a good job of treating the presenters well so I'm sure the trend will continue.

This year I did two sessions - one on BYOPC and another on Disk Workloads for Desktop VMs. The BYOPC one was in the first slot of the conference (8:45am!) and was completely full. There was a good mix of people, some of whom had deployed BYOPC, others who were interested in deploying it, and we had a good conversation. The key points were that BYOPC can reduce support costs and lead to happier users (if you do it right), and this change is happening whether you like it or not. Brian in his keynote had a great quote: "If you say there is no way you will allow it (BYOPC) in your organization, pretty soon you won't have to, because your employees will leave and go somewhere else." The other great quote I heard is: "If BYOPC is a competitive advantage today, it will be a requirement tomorrow."

The second one on Disk Workloads was much more technical. I did a deep dive into how I/O in a VM works and what a Desktop workload looks like. The desktop VM workload is quite different than server VM workloads - a typical server VM does 90% reads vs 10% writes, but a desktop is more like 60%/40% or even 50%/50%. Not only that, but the desktop VM workload is very latency-sensitive, and if you have any long latency writes, your user experience will suffer greatly. The load from a single desktop VM can peak at up to 8000 IOPS during certain operations. At the end of the session I did a demo that pitted a VM served from my Blackberry (15MB/sec read, 7MB/sec write, 10-30 IOPS) using MokaFive's optimized virtual disk format versus a normal VMDK on a much faster USB drive. The optimized one booted quickly and was very responsive, whereas the straight VMDK was sluggish, stuttering and unusable. It just goes to show that slow IO performance can make the user experience unbearable, and optimizations can make a big difference.

It was great to meet up again with the BriForum crowd and I'm looking forward to participating again next year!

John Whaley, CTO & Founder

What is the right virtual desktop model for BYOC?

A recent blog post by Brian Madden compares the security differences between Type 1 and Type 2 hypervisors. Brian writes that Type 1 bare-metal hypervisors are “possibly more secure due to the smaller attack surface of the hypervisor.” But he’s quick to point out that neither Type 1 nor Type 2 hypervisors are a one-size-fits-all solution.

After reading Brian’s blog, I thought about MokaFive’s approach to security. The problem with security is that you can’t talk in absolutes: the discussion depends on both the use case and its associated risk profile. If you are completely intolerant of risk, then you have to ignore the benefits of most Internet-based computing and keep your computer offline, locked up in a dark room. But in the real world, you have to support mobile and offline workers so they can be productive, and with that comes some risk. This is true of any computing model, but it’s important to mitigate that risk by choosing the best technology for your needs.

Let’s specifically look at the BYOC model where organizations want to enable computing on employee-owned machines. While there are many models to deliver specific applications from the cloud using technologies such as terminal services or even app streaming, these don’t provide the full usability of the entire desktop environment. So, what are the options for BYOC? There is VDI, but it provides no offline access and contrary to popular belief is not completely secure, either. While the VDI desktop lives in the datacenter, IT has no way to control the endpoint machine accessing the VDI session. Those endpoints could have keyloggers or screenscrapers that can siphon data from the VDI session.

In contrast, with the client-side models, a fully encapsulated VM is delivered to the endpoint, either directly on baremetal (with Type 1 hypervisor), or on top of an existing OS (with Type 2 hypervisor). There is almost unanimous agreement that a Type 1-based model will not work for BYOC, since no user will allow IT to forklift their personal machine. Only when Type 1s are shipped with OEM machines will this model will become viable for BYOC.

Net-net, a Type 2-based client-side model, where a fully managed, encapsulated VM is delivered on top of the user’s existing OS, is ideally suited for BYOC. It provides users access to the corporate environment anytime, online or offline, without impinging on their personal machine environment.

MokaFive supports a Type 2 model today while allowing you to grow to a Type 1 approach in the future. We leverage the MokaFive player residing on the client to provide additional protection against risks associated with BYOC. I have outlined below our approach with seven layers of security that protect against your concerns:

1. Host checker

• Checks for basic performance characteristics of the machine. It can also be extended to check for any other security characteristics of the host (such as configuration and execution status of anti-virus software) prior to the launch of the virtual desktop.

2. VM encapsulation

• Encapsulates a full, locked down OS controlled by IT. This allows IT to completely control the patch level and GPO security settings.

3. VM encryption

• Encrypts image with AES 256, including the base image and all user data. We also intercept all I/O that the hypervisor writes to disk or to memory, and this data is compressed and encrypted.

4. Tamper resistance of both code and policies, and copy protection

• Attempts to alter the executable or configuration will disallow the Player from running. Also, by policy, IT can disallow users from moving images from one machine to another.

5. AD authentication / Two-factor authentication (RSA or PKI)

• Integrates with Active Directory to enforce users’ authentication prior to virtual image access. Optionally, IT can configure RSA SecurID or PKI as a second authentication factor for additional security.

6. SSL

• Communicates with the server over SSL. Clients validate the server’s SSL certificates against a Certificate Authority.

7. Policies

• Enables administrators to have fine grained, centralized control of operational and security polices, such as peripheral access, and ability to drag and drop files from host to guest or vice versa.

Simply put, MokaFive is one of the few vendors that provides a secure, fully managed virtual desktop model for a BYOC model. Stay tuned: in an upcoming blog, we will talk about BYOC best practices.

Purnima Padmanabhan, VP of Products and Marketing