Budge up VMware, array upstart Tintri's ramming in Red Hat Linux KVM Hybrid flash-disk array startup Tintri is adding Red Hat-flavoured virtualisation to its storage gear – which already supports VMware-powered virtual machines. Tintri will demonstrate support for Red Hat Enterprise Virtualization using Linux's Kernel-based Virtual Machine (KVM) at the Red Hat Summit 2014, which will be held in …
I love Tintri but...
“Red Hat customers can now benefit from the only hypervisor-neutral storage platform with VM-awareness and adaptive learning capabilities to support hundreds of mixed workloads – servers, VDI, dev and test – concurrently on a single Tintri VMstore. Customers can also deploy both vSphere and Red Hat Enterprise Virtualisation on a single VMstore at the same time."
Translates to "our software is able to tell if a folder contains KVM images or VMware images, even when they use the same NFS share. This sounds about as thrilling as "I added a line into my PowerShell script to detect extensions" to the technical nerd, but that's a hell of a great bit of marketing blather.
I mean, I could cheerfully abscond with the label of "smart cross-hypervisor storage" for my mates at Proximal Data and at least feel like I'm being a little more honest in using it. Autocache supports Hyper-V and VMware both, with the "smarts" being "it automatically resizes flash utilization to optimally fit the available flash and the workloads presented". That, and I don't have to redesign my networks to make it go faster. Add flash, install Autocache, walk away. It's a heck of a lot cheaper than the forklift upgrade of a Tintri!
Again, this isn't to say Tintri's bad. They're not. Tintri is amazing, and once you have one you'll soon have another. They have repeat customers for a reason...but I am distinctly not impressed with the marketing philosophy that turns "we can detect which hypervisor generated the virtual image when they use the same NFS share" into 54 words. No! Bad Tintri! Get down, and don't chew on the couch!
To paraphrase Storagebod, are you inexpensive and are you easy to use? Them's the bits we actually care about.
. . . but the marketing guys have to justify their existence somehow. "It's fucking awesome, and now it works with Red Hat!" doesn't make good marketing copy. Also, it seems pretty clear that Tintri is doing something with the hypervisor (probably pulling in latency stats and other metadata about the VMs), so it's not as simple as just presenting an NFS export, and Tintri does have to make it clear that you can use a single VMStore with multiple hypervisors.
I would like to see Tintri make more of a big deal about the fact that they tell you how much capacity you can use instead of telling how raw capacity you get. One of the things that drives me nuts about certain incumbent storage vendors is that their cost per gigabyte is grossly understated when you figure out how much of that capacity you actually get use out of.
Oh, hey, I'm not knocking the integration with KVM at all. They talk to the hypervisor, pull in stats, marry up the image on their datastore with information from the hypervisor. Someone spent a lot of time in a dark room with a bunch of APIs and they should be proud of what they've accomplished.
My issue is with that one very specific statement. The ability to - for all intents and purposes - recognize extensions on their own datastore tarted up as though it were some kind of superpower. If that is an example of the breathtaking innovation coming out Silicon Valley today that should be getting us all hot-and-bothered, it's time to scour everything within 50km of the 101 right back to bedrock and start over.
... then vmware data stores. The concept of having plainly labelled disk images in a folder doesn't apply.
What this sounds like is the Tintri guys are either using RHEV's API's from their storage side, or they've created a plugin for RHEV manager. In other words, storage integration for RHEV, which is actually a pretty big deal for a new virtualization platform without massive market share.
Let´s talk about hardware/software. Tintri people don´t tell me what filesystem they use. According to them they invented(?) their own.
But when I watched their presentation with their 3 different appliances. So, what do we have: gigabytes of RAM, some gigabyte of SSD, two SAS controller, some SAS drives. And wow, that SSD drives are used for caching from begin on. Plus kind of plug and play i.e. easy management. NFS... some auto magic copying VMs based on some black boxed algorithm, some nice looking VM performance monitoring...
And of course you can mirror the content of one appliance to the other one. Of course, according to them Tintri is best for VDI, because of IOPS, IOPS, IOPS, ... "You can boot 400 virtual machines within 10 minutes on our boxes. Try this with other vendors", It´s about cost per IOPS and not cost per gigabyte, yada yada yada ...
While listening I thought. Stop, we already have those things: Solaris/FreeBSD and ZFS for equal or less costs with many many many other vendors doing the same thing.
It's a good move on their part to support other hypervisors as they are about to be put under pressure by the existence of their very own partner now turned competitor, vmware. Of course they won't be the only ones, but this whole vsan thing will have material effect mostly on the likes of Tintris, Nimbles, Tegiles etc. who compete head to head in that MSB space.
Tintri are a serious pain in the arse, the so called sales people are worse than the oik who knocks on your door to flog double glazing. They have been repleatedly harrassing us, not tkaing NO!!! for an answer. It has reached the point where no matter how good the wretched product might be we simply will not have anything to do with them. Tintri are not unique by a long shot and they have a huge amount to learn about business. Just because we have a storage tender out does not mean that everyone and there pet dog is welcome. There is more to storage than a bit of flash to run some VMs.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
