At Tintri, we built a VM-aware storage system with hypervisor neutrality in mind from the beginning. VMstore has been designed from the ground up to support multiple hypervisors concurrently providing the same level of per-VM data management and monitoring across all of them. It is easy to say that, of course, so we decided to put our money where our mouth is. We are proud to announce the technical preview of Red Hat Enterprise Virtualization (RHEV) support. Tintri VMstore’s architecture makes it easy for us to support per-VM performance visibility, snapshots, clones and replication functionality on RHEV just as we do for VMware.
While each hypervisor has its own unique capabilities and features, all VMs appear to be a similar set of properties to storage - they are a collection of disks (in similar formats) and configuration information.
Since Tintri breaks the VM down into these components, our VM-aware architecture allows us to accommodate different hypervisors easily, and treat VMs from one hypervisor the same way as the VMs from another hypervisor. This leads to a unified experience across multiple hypervisors. Rather than worrying about the differences, you can manage your infrastructure holistically.
As an example, let’s look at some of the similarities and the differences between RHEV and vSphere. At an architectural view RHEV looks very similar to vSphere, but there are some differences under the covers. Let’s start with a component by component comparison:
In terms of storage, there are a few key differences between RHEV and vSphere. In vSphere each VM is represented by a configuration file (a vmx file) which then references a number of other files (disks, descriptors, etc.). In general, all the information for a VM is placed in a single directory. VMs can be added or removed from inventory as desired. The same datastore can be mounted across multiple vCenters so long as each individual VM is only in inventory in one vCenter.
RHEV’s storage domains have structure imposed by RHEV itself. Each storage domain is a directory which contains a number of disks (each in their own directory) and then metadata about the domain. Each storage domain can only be mounted on one RHEV-M instance to avoid concurrency problems. In the RHEV world, VMs do not belong to any particular storage domain, but instead belong to a data center. Each disk of a VM is stored in one domain, but it is easy for a VM‘s disks to span storage domains by having disks in various domains.
Tintri’s integration with RHEV works very similarly to our integration with VMware. The appliance presents itself as an NFS storage domain, which RHEV can use to create and store data. In addition to the data path, we communicate directly to RHEV-M using the REST interface to associate the storage constructs with VMs and vDisks.
Tintri handles all of these storage differences for you under the cover. When you add a new RHEV VM to a Tintri VMstore, it shows up exactly the same way as a vSphere VM in our UI. You can see performance and capacity statistics, create and manage Tintri space-efficient snapshots, create zero space clones, and configure replication at a VM-level exactly the same way you do for vSphere VMs. The only differences are the host and hypervisor fields, which allow you to see which VMs are hosted on RHEV, and which are hosted on vSphere.
By unifying the experience for VMs across disparate hypervisors, Tintri provides a way to mix and match RHEV and VMware as you desire, rather than requiring you to statically assign appliances or volumes to a particular hypervisor up-front. In addition rather than having to relearn storage for different hypervisors, Tintri allows you to manage all your VMs in the same, simple fashion. We are excited for RHEV users to experience the same powerful, simple features that our VMware customers have already enjoyed. Tintri support for RHEV is currently in technology preview and will be generally available in August 2014.
Tintri all-flash storage and software controls each application automatically