Layering is the “flavor of month” it seems. There has been a steady up-tick in articles being posted about the concept so this one is no exception. But when we talk about layering,what are we really discussing? Applications, user persona or both? Are we discussing some sort of streaming technology or virtual disks? Regardless, what we are really discussing is a new layer of abstraction for virtual machines. Therefore, we must take a step back and ask ourselves where the value resides in “layering” and what would we expect to see in any solution. Currently there are several companies developing in and around this concept. Many involve the techniques I just mentioned but when we apply the premise that layering is abstraction, then the answer to the question I posed would be a solution that utilizes the underlying hypervisor and infrastructure to the fullest extent so as to eliminate variables and provide for a flexible, scalable and predictable solution.
Case in point. I recently attended a demo from a new company in stealth mode whose solution is meant to address these questions head on. SnapVolumes is a start-up with the potential to the make the fundamental change we are looking for. It was no coincidence there motto is “Simple is better”. When I attend the demo I was surprised with what I saw. The founder, Matt Conover formerly with Symantec
, has taken the idea that all that we truly need to resolve this question was a solution that uses the built-in capabilities of the existing hypervisor and a dash of common sense. I should also mention that there were a few other folks invited to see the demo including some from VMware
. No doubt, something like this would appeal to the app virt guy in all of us.
The demo was rather straightforward. There are two main components to the solution. A local agent for the Windows OS that runs as a service and a virtual appliance that it communicates with.
The basic concept is that the administrator can create virtual disks (VHD or VMDK) that, via the web-interface for the SnapVolumes Manager, configure these disks to mount for individual users based on AD credentials or the server/workstations themselves. The latter has an interesting twist that we’ll discuss in a moment. For the first demo, Matt showed a virtual desktop running Windows 7
. He logged in as a user and demonstrated how, based on the users AD account, two volumes were mounted. One was a personal disk (Persona) and the other was an application volume. The persona disk was writable as you can imagine and would store all changes that occur to the local OS and the attached application volumes just as they would to a native profile. The application volume was read-only, a nice surprise, and could be shared with other virtual machines. The local agent slipstreams the persona and application volumes into the C: drive so that to the user, the OS and everything appears to be part of the non-persistent pooled base image.
One of the cool technical things I saw was that the desktop he used had no virtual SCSI adapter configured for it. The agent and manager saw that and configured the virtual machine with one prior to mounting the volumes, a nice little feature if you ask me. The other notable feature was the ability for the Manager to assign and un-assign volumes in real-time to the VM and have multiple users leverage the same SnapVolume. Matt mentioned that in the case of servers and the cloud, the ability to provide this level of integration with virtual machines that are already running was critical. On this note, we should explore the idea of machine specific disks I mentioned earlier. Matt commented that there were three primary use cases for this technology, Desktop, Enterprise Servers and the Cloud. Desktops were my first inclination for something like this but he mentioned that Cloud providers could likely benefit the most. For example nearly all virtual appliances today are Linux based for licensing reasons. But with the majority of business applications still being Windows based, it makes it very difficult for ISVs and customers to fully realize the true benefits of a virtual appliance methodology without something that can provide this kind of flexible assembly with Windows based servers.
SnapVolumes doesn’t directly do any of the work related to the virtual volumes being used. Instead, it manages the requests and instructs the hypervisor layer to perform the action. He also mentions that this offloads the work to the infrastructure in such a way as to make the solution highly scalable and hypervisor agnostic. To highlight his point, he showed a demo of this running on Amazon EC2. Now that was a nice touch! Any solution that looks to solve the layering questions must not only be agnostic to the hypervisor but must also be so flexible that providers like Amazon or Terremark could implement the solution easily or allow customers to use it within those services.
The entire demo opened up discussions that would take days to talk out. Like all emerging products that look to transform the way we look at a technology, history shows us that the most successful are the simplest and most direct to use. SnapVolumes looks to be on the right track. Their approach makes full use of the current virtual infrastructure while also providing a very simple interface in which to control the environment. They allow users to share application volumes simplifying administration and increasing scale. Users and/or customers will never know that their virtual machines are in fact several virtual disks “Snapped” together and managed in such a way as to provide unparalleled flexibility and control. I look forward to seeing more from SnapVolumes as they emerge from stealth-mode and see how VMware, Citrix and Microsoft view this technology given their own limitations in this area. Least we forget, SnapVolumes merely adds the intelligence to the environment to provide this capability. It wouldn’t surprise me if that were why the VMware and Citrix folks accepted the invitation to see the demo.