VMware buying Virsto is a big move and after considerable discussion a logical step for VMware in many technical areas as well. We previously mentioned that Virsto would add to VMware’s existing in Software Defined Data Center (SDDC), but there is more to this than just SDDC, which I believe is the end goal. Getting there absolutely requires a storage abstraction layer. So what does VMware gain other than SDDC with Virsto.
First let us look at Virsto’s product. What does it provide other than an abstraction layer?
- Works on multiple hypervisors, actually Virsto started out working on Hyper-V only, they transitioned to vSphere but keep their Hyper-V roots intact.
- Provides a high speed logging filesystem that uses system memory as a cache to improve performance across a cluster that can be optimized by workload type. Virsto spent many hours optimizing for virtual desktop workloads.
- The Virsto filesystem does not care the type of virtual disk in use, it provides a translation layer so that a Microsoft VHD, or vSphere VMDK can both live on the same filesystem and be accessible by either hypervisor regardless of disk type.
Virsto not only provides a storage abstraction layer for the underlying storage hardware that includes many of the functions of today’s virtual storage appliances such as optimization, replication, deduplication, etc. The higher end of storage functionality across multiple storage types and brands. But it provides a mechanism to abstract what is being read and written not just how it reads and writes. Perhaps this is the true definition of a storage hypervisor, it has to abstract both sides of the storage equation.
VMware’s path to SDDC is not well known outside of VMware but I feel Virsto will play big in this arena, there are several logical steps to go here:
- Integrate Virsto into the existing VMFS without loosing the optimization layer or the translation layer
- Integrate Virsto into VMware’s existing Storage Virtual Appliance (SVA) as a plugin storage layer to what already exists
- Upgrade VMware vCloud Connector to work across hypervisors if Virsto is integrated into the target storage
VMware’s path to SDDC must include multiple hypervisors and they have already started down that path with an add on to vCenter but it needs to be regardless of virtual disk type. VMware’s current stance is to import using OVF or OVA virtual machines, but this first implies you translated from Microsoft VHD to OVF/OVA and then using vCloud connector pushed it to your vCloud. That conversion process is time consuming, looses critical information, and not the best method to go for a software defined data center that just works regardless of hypervisor. We need to pull the hypervisor out of all SDDC discussions, unfoirtunately it really matters at the moment.
The hypervisor as a commodity is coming, VMware purchasing Virsto is a step in that direction.
Its going to be interesting to watch.
A side note: OVF/OVA are not specific to VMW and can describe VHD and VMFS images. OVF is the XML descriptor, OVA is just a compressed bundle of image file(s) and OVF XML. I’m guessing your intent was to state that VMW might wand to add either native VHD support or as part of import of a VHD/OVF convert the disk images to VMFS.
Come on Ed, don’t be such a fanbois. You’re making much ado about almost nothing. Virsto creates a local cache to improve storage efficiency. This is hardly revolutionary. In fact, it shows just how much vmw has lost their way. This SHOULD be a storage optimization for ESX. The fact that vmw had to buy this tech is a very bad sign.
By the way the hypervisor has been a commodity for a while now.