Last year I published a list of storage vendors and partners that I was planning to check out at VMworld 2013. This year is no different, with a number of new arrivals on the storage scene, as well as some super new cool products from many of VMware’s partners. Whilst this is no means a definitive list of what’s on show, these are the ones that I am particularly interested in checking out this year.
On a recent trip to VMware in Palo Alto, I found some time to visit with a good pal of mine, Vinay Gaonkar, who is now the Product Manager for XtremIO over at EMC. Vinay used to be a storage PM at VMware (he worked on the initial phases of VVols), and we worked together on a number of storage items in various vSphere releases. It’s been almost 2 years since I last spoke to the XtremIO folks (VMworld 2012 in fact, when the product still had not become generally available), so I thought that this would be a good time to catch up with them, as we are in the run up to VMworld 2014.
Although I didn’t attend EMC World this year, there were a lot of interesting announcements. I managed to catch up with Matt Cowger (who sorts of sits between both the EMC & VMware camps) and ran through some of the main highlights from this year’s conference. There has been a lot written about EMC World already (and I mean a lot) so I’m going to try to keep the highlights to a minimum, and provide links to where you can read more.
In this post, we talk about a particular behaviour with using the default (or None) policy with VSAN. I have stated many times in the past that when a VM is deployed on the VSAN datastore, it behaves like it is thinly provisioned unless the capability ‘Object Space Reservation’ (OSR) is specified in the VM Storage Policy. The OSR will pre-allocate space on the VSAN datastore for the virtual machine’s storage objects, and is specified as a percentage of the actual VMDK size. However, there is a slightly different behaviour when the default policy is used. Once again, I was in a conversation with a customer who stated that when he used the default policy of “None”, he could see space being consumed on the VSAN datastore was equal to the size of the VMDK * FTT (Number of Failures To Tolerate). He wondered why this was the case when the default policy clearly did not contain an Object Space Reservation capability.
Pure Storage are all over the news at the moment. They just secured another round of funding (225 million to be precise), and are now valued at over 3 billion. You can read more about that here. However, even before this announcement, I had already arranged to have a catch up chat with Pure’s primary evangelist (and a good pal of mine), Vaughn Stewart. I was surprised to see that it had been 18 months since I last did a piece on Pure so I really did want to see what changes they had made in the meantime as there were a few vSphere interoperability pieces still to be completed when we last spoke.
Those of you familiar with VSAN will know that one of the capabilities which can be placed in a VM Storage Policy is Number of Disk Stripes Per Object (stripe width for short). I covered this in an earlier post which looked at the various VSAN capabilities. Recently, a customer who had not specified a stripe width in the VM Storage Policy was perplexed to find that his storage objects had indeed been striped across a number of disks. He reached out to me if I could provide an explanation.
Well, VSAN is finally GA today. Check out Duncan’s blog post which has lots of good links about where to get the GA bits.
In this post, I am going to address a question about the VM Home Namespace object on VSAN which has come up a number of times recently and has caused a little bit of confusion. If you’ve been following my series of Virtual SAN articles, you may recall that virtual machines deployed on a VSAN datastore are now made up as a set of objects (as opposed to the set of files that we’ve been used to traditionally). These objects may be virtual machine disk (VMDKs), snapshot deltas, VM swap space and of course the VM Home Namespace. The VM Home Namespace is where we store all the virtual machine configuration files, such as the .vmx, .log, digest files, memory snapshots, etc. Now what a number of folks have noticed is that even though they set a VM Storage Policy with various VSAN capabilities, the VM Home Namespace object does not seem to implement the policy settings when viewed via the vSphere web client. This post will aim to explain why.