I’ve been hit up this week by a number of folks asking about “ATS Miscompare detected between test and set HB images” messages after upgrading to vSphere 5.5U2 and 6.0. The purpose of this post is to give you some background on why this might have started to happen.
In vSphere 5.5U2, we started using ATS for maintaining the heartbeat. Prior to this release, we only used ATS when the heartbeat state changed. For example, referring to the older blog, we would use ATS in the following cases:
Acquire a heartbeat
Clear a heartbeat
Replay a heartbeat
Reclaim a heartbeat
We did not use ATS for maintaining the ‘liveness’ of a heartbeat. This is the change that was introduced in 5.5U2 and which appears to have led to issues for certain storage arrays.
A short note to clarify something that has come up a number of times in recent weeks here at VMware. There have been a number of discussions about whether or not we support NFS over IPv6 on vSphere 5.x, and again, on whether or not we support the VAAI-NAS primitives in the same context.
VAAI is an API for offloading tasks to the storage array, but for offloading tasks to NAS arrays, storage vendors need to create their own plugins for the ESXi hosts to achieve this. You can learn more about VAAI-NAS by clicking here. So what about IPv6 support and NFS? And VAAI-NAS?
I was in a conversation with one of my pals over at Tintri last week (Fintan), and he observed some strange behaviour when provisioning VMs from a catalog in vCloud Director (vCD). When he disabled Fast Provisioning, he expected that provisioning further VMs from the catalog would still be offloaded via the VAAI-NAS plugin. All the ESXi hosts have the VAAI-NAS plugin from Tintri installed. However, it seems that the provisioning/cloning operation was not being offloaded to the array, and the ESXi hosts resources were being used for the operation instead. Deployments of VMs from the catalogs were taking minutes rather than seconds. What was going on?
Continuing on the series of vSphere 5.5 Storage Enhancements, we now come to a feature that is close to many people’s hearts. The vSphere Storage API for Array Integration (VAAI) UNMAP primitive reclaims dead or stranded space on a thinly provisioned VMFS volume, something that we could not do before this primitive came into existence. However, it has a long and somewhat checkered history. Let me share the timeline with you before I get into what improvements we made in vSphere 5.5.
I get a lot of questions around how the vSphere APIs for Array Integration (VAAI) primitives compare from a protocol perspective. For instance, a common question is to describe the differences between the primitives for NAS storage arrays (NFS protocol) and the primitives for block storage arrays (Fibre Channel, iSCSI, Fibre Channel over Ethernet protocols). It is a valid question because, yes, there are significant differences and the purpose of this blog post is to detail them for you.
During VMworld 2012 in San Francisco, I had a chance to catch up once again with the team from Tintri. My first introduction to Tintri was at last year’s VMworld, where they received runner-up in the ‘Hardware for Virtualization’ category by TechTarget for best of VMworld 2011. Well this year they went one better, and won the Best of VMworld 2012 Gold award in Hardware for Virtualization. And for good reason. Let’s see the enhancements to the Tintri platform over the last 12 months have brought.
Pure Storage are an all-flash enterprise storage company. I first met these guys at VMworld 2011 and was quite impressed by their product. Like many Flash Array vendors at the time, there wasn’t a great amount of vSphere integration features. However, with this latest release of Purity v2.5, Pure Storage are addressing this and more. I had a chance to meet and discuss these new features with Matt Kixmoeller & Ravi Venkat of Pure Storage recently. Not only are they now VMware-Ready certified, but they’ve got a whole bunch of integration features. Let’s have a look at the features that they have added to their new release.