A First Look at Mobile Virtualization
Mobile virtualization promises to greatly enhance mobile communications, but it's still in its early stages.
Over the last several years, hardware and software vendors have begun to virtualize just about anything you can imagine. Server virtualization, network virtualization, application virtualization and even desktop virtualization are all technologies that have become commonplace. More recently, though, companies like VMware Inc. and Red Bend Software Inc. have begun to introduce the concept of mobile virtualization.
What Is Mobile Virtualization?
Right now there are two different emerging mobile-virtualization models. One of these models is similar to server virtualization. The basic idea is that a mobile device, such as a smartphone or a tablet, is able to simultaneously run multiple mobile OSes. For example, a single device might run the Android OS alongside Windows Phone 7.
The other emerging model for mobile virtualization works in a way that's similar to application virtualization. The idea here is that each application runs within an isolated sandbox that shields the application from the mobile OS and from any other applications that may be installed.
In spite of the differences between the two different approaches to mobile virtualization, the two models offer similar benefits: security and flexibility. For the purposes of this article, I'll be focusing my discussion on OS-level virtualization.
Before we begin, let's explore the driving forces behind the development of mobile virtualization. One of the main reasons why mobile virtualization is going to be such a big deal is because it effectively solves a problem that IT professionals have been struggling with for several years.
Anyone who has worked as a network administrator over the last few years has undoubtedly encountered a situation in which an employee comes into the office with a brand-new smartphone that he acquired on his own. The employee inevitably wants to unleash the power of his new toy by connecting it to the corporate network. At the very least, he probably wants to be able to access his corporate e-mail, but he may also want access to mobile applications or SharePoint sites.
The problem with this is that IT professionals are under a tremendous amount of pressure to keep the network secure. In many industries there are also government regulations that must be followed. The end result is that network administrators are usually reluctant to allow employees to access the network through personal devices. In fact, the advice I usually give my clients is to only allow devices that have been purchased by the company for connection to the network. There are two main reasons why I give this advice.
First, it's impossible to adequately secure what you don't fully control. If someone is connecting to your network through a mobile device, then you need to be able to implement Group Policies and other security mechanisms that will control how the device can be used. If users have their own personal devices connected to the network, it's difficult to fully control these device configurations. For example, many organizations insist on disabling the camera that's built into mobile devices. However, your users would probably be upset if you disabled the camera on their personal smartphones.
Second, allowing the indiscriminate use of personal mobile devices inevitably turns into a technical support nightmare. After all, there are countless different smartphones on the market, and each one comes preloaded with its own OS and default application set. It's unrealistic to expect your help desk to be able to fully support every single mobile device that users bring into the office.
OS virtualization for mobile devices solves both of these problems. Mobile virtualization will make it possible for the user to run either the same or different parallel OSes. For instance, a single device might have two instances of Android installed. These instances would be completely separate from each other, and neither would know that the other instance exists. A mobile device could also theoretically run Android and Symbian side-by-side.
Having the ability to run multiple OSes on a mobile device benefits end users who want to connect their personal devices to the corporate network, but it also benefits the IT department. Rather than trying to adequately secure a user's personal device while also trying not to step on the user's toes, network administrators can simply deploy an alternate OS that fully complies with the corporate IT security policy. Network resources would be accessed solely through this OS, and wouldn't be exposed to the alternate OS (which is reserved for the user's personal use).
In addition to solving the problem of providing adequate security on a user's personal device, mobile virtualization also helps to reduce technical support costs. Even though it's theoretically possible for every user to have a different make and model of mobile device, mobile virtualization will render the physical hardware irrelevant, just as server virtualization products allow server OSes to be installed regardless of the underlying hardware (assuming, of course, that the hardware adheres to certain minimal specifications).
In other words, mobile virtualization platforms will allow IT departments to deploy a mobile OS and a fully provisioned set of applications on top of a hypervisor in a way that relieves the help desk staff from having to understand the nuances of every individual device. Instead, each user accesses the corporate network through a uniform guest OS that looks and behaves in exactly the same way, regardless of the make or model of the device on which it's installed.
How Does Mobile Virtualization Work?
Right now there are several different vendors that are developing mobile virtualization solutions. For example, VMware recently demoed its mobile virtualization platform on an LG smartphone at the Mobile World conference in Barcelona, Spain.
Another key player in the emerging mobile virtualization market is Red Bend Software, which has created a mobile hypervisor called VLX that's designed to work with ARM and x86 architectures. VLX is similar to server hypervisors and desktop hypervisors in function. Like any other Type-1 hypervisor, VLX is really nothing more than a thin abstraction layer that interacts with the device's hardware at the bare-metal layer. By doing so, VLX allows multiple guest OSes to simultaneously run on a single mobile device.
VLX works by allocating hardware resources to guest OSes. As with most other hypervisors, this is accomplished in two different ways: Some hardware resources are partitioned, while others are virtualized.
Memory is a classic example of a hardware resource that's partitioned. Two different OSes can't use the same memory range at the same time, so memory is partitioned so that each guest OS is allocated a specific amount of memory. The guest OS takes full ownership of this memory and has exclusive use of it.
Currently, CPU is a resource that can't be partitioned. Today's mobile devices only have a single CPU, making it impossible to partition the system's resources so that each guest OS has a dedicated CPU. However, the first generation of mobile devices with dual-core processors are beginning to make it onto the market, so it seems reasonable to assume that the hardware will eventually include enough CPU cores to make managing CPU affinity on a per-guest-OS basis practical. For now, however, VLX uses its own built-in scheduler to control how much CPU time each guest OS receives.
Being that mobile virtualization works similarly to server virtualization, and that companies such as Red Bend Software already have mobile virtualization solutions in place, you might be wondering why you don't yet see virtualization being used on consumer devices.
The reason why mobile virtualization has not yet seen widespread use has to do with hardware-access limitations. Consider the way that server virtualization products such as VMware ESXi and Microsoft Hyper-V work. If an administrator wants to set up some virtual machines (VMs), they start out by buying a physical server and a server virtualization product. From there, the virtualization product (Hyper-V, ESXi, Citrix XenServer and so on) is installed on the server. Once the virtualization product is in place, the administrator is free to begin creating VMs and installing OSes onto those VMs.
When it comes to mobile virtualization, things work a bit differently. After all, you can't just go to the store and buy a blank mobile device. Cell phones and tablets come pre-loaded with an OS such as Android or Windows Phone 7. Of course, the same thing could be said for PCs. Nearly all of the PCs sold in retail stores include an OS, but there's nothing stop-ping a consumer from formatting the hard drive and installing another OS of their choice.
Unfortunately, it's nearly impossible for the average consumer to replace a mobile device OS with one of their choosing. Mobile OS software is not readily available, and even if it were, every mobile device is different and requires a device-specific build of the OS. Herein lies the real problem.
VLX is a low-level hypervisor that must be installed by the device manufacturer. It isn't something the consumer can download and install later on. (The same limitation also applies to the VMware mobile virtualization product.)
Even with the VLX hypervisor in place, consumers won't be able to simply download a mobile OS. Every mobile device uses unique hardware, and mobile OSes are custom-tailored to each device's individual specifications. While it's true that VLX prevents guest OSes from interacting directly with most of the device's hardware, the guest OSes have to be able to run on top of the VLX software. Mobile OSes see VLX as physical hardware, therefore, a special build will be required for each mobile OS to make it compatible with VLX.
This raises the question of which OSes will be able to take advantage of VLX -- and the answer is, only open OSes will be able to be used with VLX. Red Bend Software has already created modified hardware-abstraction layers for Android, Linux and Symbian OSes that will allow them to work in a VLX environment. But you probably won't see virtualized instances of the iPad OS or Windows Phone 7 running on top of a VLX hypervisor anytime soon. Even so, Red Bend Software claims to have adapted seven different mobile OSes to work with VLX.
It will be interesting to see how well mobile virtualization ultimately works in the real world. Although the basic technology is solid, I suspect that early adopters may end up running into problems taking full advantage of their devices' hardware. For example, suppose that a particular mobile device comes equipped with a hardware keyboard. Unless the hypervisor is aware of the keyboard, the keyboard may not function within the guest OSes.
Of course, the mobile virtualization products that are available now require the hypervisor to be installed at the factory. Because of that, it's plausible that the hypervisor could be adapted to each individual mobile device to provide full support for that device's hardware. As such, hardware support issues would only be a problem if companies like VMware and Red Bend Software began offering a generic hypervisor, rather than one that's custom-tailored to each device's individual capabilities.