VMware acquires CloudVolumes

Yesterday VMware announced the acquisition of CloudVolumes, a product which enable real-time desktop application delivery. Delivering desktop applications to users, especially in Windows environments, can be very challenging. Adding or removing applications based on the user context,  incompatibilities or conflicts with existing apps, all problems that interfere with successful application delivery.  Preventing these problems often results in complex workarounds, either through scripting or manual intervention. CloudVolumes should solve all that.

CloudVolumes is changing the way how virtual machines are managed and updated. With the click of a button, you can deliver any number of applications and any amount of data to any number of virtual machines within milliseconds or seconds. Updating applications and virtual machines is just as simple. This is true even for large, multi-tier applications that are several gigabytes in size. Best of all, CloudVolumes will seamlessly integrate into your existing virtual infrastructure. There is no need to replace your storage, hypervisor, network, or virtual machines.

So, what is CloudVolumes?

CloudVolumes is based on a technology called layering.  Layering is a method of decomposing a Windows instance into a set of discrete pieces.  These pieces can be things like the base OS, one or more applications, and user data.  Once these pieces are placed into separate layers, they can be easily added and removed from a system.  The big difference here is that the applications in the layer are no longer being installed.  Instead the layer is simply being delivered.  This makes adding and removing applications much simpler and less error prone.  Given the speed at which CloudVolumes can add and remove applications, it is called real-time application delivery.

How does CloudVolumes work?

With CloudVolume it is is no longer necessary to revert to scripting or manual intervention. The otherwise monolithic virtual machine, where everything is tightly locked together, is turned into a modular virtual machine in which components can be shared or swapped in and out.  The sharable components, such as application binaries and read-only data, is only stored once that all virtual machines can simultaneously share. This is achieved by leveraging a read-only volume that is concurrently attached to each virtual machine.

Parts of the virtual machine which are specific to that workload or user like configuration, customization, license keys, log files, and data, can remain within the virtual machine or be placed into a separate writable volume. A writable volume is optional, but there are several benefits to using a separate writable volume:

1. All changes to the system covered by the writable volume’s policy are put onto the writable volume rather than the virtual machine’s base disk.
2. For virtual desktops, having a user writable volume means the user isn’t tethered to a specific virtual machine—the user can log into any virtual machine and see all his/her applications and data. Essentially, this gives the ease of management and cost savings of non-persistent virtual machine but with the look-and-feel of a persistent virtual machine.
3. For servers, having a server writable volume means that the specific virtual machine a workload is running in doesn’t matter. If the virtual machine crashes, the workload can quickly detached from the failed virtual machine and attached to another virtual machine. The second benefit is migration. A workload can be relocated to another cloud or datacenter without moving the entire virtual machine.

CloudVolumes works in both virtual and physical environments.  It stores its layers on vmdks for virtual and VHDs for physical.  When a vmdk or VHD is mounted, the CloudVolumes agent will query it to see if there’s a layer inside.  If so, it will merge the application or user data as appropriate in seconds.

What makes CloudVolumes unique?

My first reaction to the announcement was “Ok, but what about VMware Horizon Mirage? Mirage does layering and application delivery too”. From what I understand, Mirage is positioned for FAT client/slow links, where CloudVoluems is primarily used for desktops solutions with datacenter connectivity, like physical, RDSH, and persistent and non-persistent VDI desktops.. Why? What makes CloudVolumes unique to position it this way?

This architecture is extremely cool and technically savvy for a few reasons.  First, there is no copy of data.  CloudVolumes can map the vmdk or VHD in and immediately start operating on the layer inside of it.  In fact, CloudVolumes can attach the same layer to multiple desktops simultaneously.  This is important because it allows a single layer instance to scale seamlessly, serving multiple desktops and/or users without all the overhead of other approaches.

Second, the truly powerful aspect of CloudVolumes’ technology is that a layer can be added while a desktop is running.  In fact, it can even be done while a user is logged in to that desktop.  This means that when a user is entitled to an application, that application immediately appears in their Windows desktop.  Again, talk about powerful simplification.  No longer does the admin need to coordinate an outage window to install an app or do an update.  Now the new or updated app can be delivered to a running, logged in desktop in a completely transparent fashion.

Third, the best part about it all is that the application isn’t actually installed.  Instead, CloudVolumes uses advanced techniques to make it appear as though it is.  This ‘last mile virtualization’ enables CloudVolumes to avoid all the problems with installation-based delivery methods.  No files are copied, no settings are changed, and desktops no longer need to be powered on for IT to manage applications.  Instead, CloudVolumes leverages an innovative filesystem filter driver and, on Windows, a registry virtualization driver to make it appear to the guest operating system and other applications as if an application is installed, when in reality it resides on the layer that was added to the desktop.  This also adds an extra layer of security, because the layer is read-only, meaning the user (or a virus!) can’t modify or corrupt the application.

CloudVolumes integration & scalability

CloudVolumes enables all files, data, and applications used by more than one virtual machine to be placed into shared virtual volumes (i.e., VMDK files in the case of VMware) and CloudVolumes does the magic to make this shared data accessible to all virtual machines that need it in a way that is transparent to the virtual machine.

These volumes can be placed on any type of storage that the hypervisor supports (i.e., SAN accessed via Fiber Channel or iSCSI, NFS, locally attached storage, etc.). CloudVolumes Manager will place the shared volumes or writable volumes on any datastore of your choosing. CloudVolumes is not inline in the storage path, it operates as more of a broker which attaches or detaches volumes from virtual machines in response to certain events. Reads and writes are sent directly from the virtual machine (where the volumes appear as local disks) to the datastore’s underlying storage through the hypervisor.

This approach enables storage tiering. Shared volumes (which receive only read requests) can be placed on a datastore optimized for read operations. As an example, it would not be cost effective to put entire virtual machines on an SSD datastore because of the cost of SSD. However, because CloudVolumes requires only a single copy of applications and shared data, those shared volumes can be placed on an SSD datastore and provide better application performance with only a marginal increase in storage cost.

One CloudVolumes Manager can easily serve 10,000 virtual machines which is as many virtual machines as one VMware vCenter support. The CloudVolumes Manager is a stateless web server that stores all of its session state and information into a shared database. So you can operate as many CloudVolumes Managers as you’d like for load balancing or high availability. If the database shared by all of the CloudVolumes Managers is put onto a SQL Server cluster, then there is no single point of failure.

If the number of virtual machines supported per hypervisor (VM density) in your existing environment is bound by RAM or CPU, CloudVolumes will make the virtual machines and applications easier to manage, but it won’t likely improve your VM density. However if your VM density is bound by IOPS, CloudVolumes will likely enable you to increase your VM density by enabling you to put shared content on faster, read-optimized storage. Similarly, CloudVolumes shared volumes can be easily cached at the hypervisor level so that the I/O doesn’t leave the physical box. If the applications are shared and the VM’s base disks are shared (using linked clones or using “fast provisioning” in VMware vCloud), then most IOPS from the VMs can be serviced from the cache without ever reaching the shared storage.

CloudVolumes simplification

CloudVolumes enables radically simplified VDI and RDSH architectures through its dynamic injection of apps and data.  For RDSH this means no more siloing of application groups.  You can now provision generic RDSH images and change application entitlements in real-time, simplifying your RDSH infrastructure.  CloudVolumes can also enable VDI non-persistent desktops to have all the persistence properties of today’s persistent desktops because they support user data and user-installed apps even on non-persistent desktops.  This is an opportunity to wipe away the distinctions between persistent and non-persistent VDI pools, focusing instead on VDI deployments that can now always be architected in a non-persistent fashion, with CloudVolumes delivering the customization and personalization of the desktop at login time, like shown in the picture below.

In these new models for RDSH and VDI, users don’t see any difference, but for IT, it can simplify management and reduce costs.  Simplification of management is driven through a single VDI or RDSH architecture serving all users, supporting knowledge workers and task workers from a single shared image with fully dynamic policy-based application access and personalization. Costs can be reduced for RDSH through application silo consolidation and for VDI by leveraging non-persistent architectures for all use cases while consolidating the number of pools and images under management.   Non-persistent virtual desktop architectures are cheaper due to resource sharing (linked clones for storage and sharing a pool of desktops for compute), but previously couldn’t support all use cases (e.g. power users or knowledge workers).  With user-state abstracted from the base image by CloudVolumes technology, even power-users demanding full flexibility can now be accommodated with a non-persistent pool, lowering TCO and broadening VDI’s appeal.  Very powerful stuff!

CloudVolumes, the bigger vision

But what does VMware want with CloudVolumes? They already have an application layering and delivery product, Mirage.

Well CloudVolumes allows VMware to unify management across all devices, both desktop and mobile. Delivery on both platforms should be very easy, simple and with a mobility management style, much like an AppStore. Just import the application from the AppStore or from a file and entitle users to that application.  The application is then automatically delivered to those users’ devices.  It’s a simple point and click affair. CloudVolumes allows VMware to extend that same simple, mobile-like process to the desktop. VMware EUC technology now offers admins a consistent way to manage both desktop and mobile apps which helps drive down operational costs.

VMware Mirage focuses on delivering layers efficiently to roaming or sometimes offline physical machines which minimizes bandwidth consumption, while CloudVolumes focuses on delivering layers to desktops in the always-on and high-bandwidth context of modern datacenters. While Mirage and CloudVolumes layering are similar at a conceptual level, their implementations are optimized for roaming (Mirage) vs always-on (CloudVolumes) use cases, respectively. Mirage delivers layers through the network while conserving bandwidth, whereas CloudVolumes delivers layers primarily using the vmdk/VHD-attach mechanism that avoids needless copying of information in the datacenter where CPU & I/O resources are shared.  With Mirage and CloudVolumes together, VMware has the industry’s most comprehensive application layer delivery solution with uncompromised efficiency for all types of desktops.

I just hope VMware quickly merges Mirage and CloudVolumes to a single product which can be managed using a single VMware Horizon console.