Showing posts with label server virtualization. Show all posts
Showing posts with label server virtualization. Show all posts

Thursday, June 24, 2010

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

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.