Let’s use a few diagrams to explain this situation a little better. Here we have a very simplified representation of a resource group. (L is short for Lock, M is short for Metadata, and R is short for Resource)
In the resource cluster, lets assume that there are two thin provisioned VMs, A & B. Both reside on the same host, and already have a number of blocks/resources consumed.
Now let’s assume that VM B gets migrated to another host (perhaps due to some DRS load balancing). Now VM A is on host A, and VM B is on host B. But the VMs continue to share the same resource cluster. At the same point in time, there is a requirement to grow both VMs A & B. Host A will try to consume the next resource (R9) at the same time as Host B tries to consume the same resource. They both race to lock L9 to modify the metadata M9 for resource R9, and thus contention arises.
Again, this is a very simplified representation, but hopefully you get the idea. Of course there could very many hosts contending for resources, not just 2, if we take a worse case scenario. The bottom line is that in VMFS-5, resource clusters tend to have host affinity, which avoids contention until such as time as a VM is migrated to another host. This can then lead to contention issues. In VMFS-6, we take a different approach. When a new file is created, we examine the existing resource clusters. If a resource cluster has any active users, meaning there is already a file using this resource cluster, that resource cluster will not be picked for the allocation of resource for this new file. Instead, the block allocation logic now looks for inactive resource clusters that are not in use by any other files. Essentially, what we have done is moved from a host affinity model for resource clusters to a VM affinity model for resource clusters. This should also mean that even in the event if a vMotion of a VM to a different host from where its file were created, VMFS-6 should not have multiple hosts contending for resources within the same resource cluster, since we are aiming to have the resource cluster only used by a single VM/file.
Of course, if all of the resource clusters become active/have files consuming resources, then we look for resource clusters with the least number of users (we are using a simple reference count mechanism to track this). This should also help keep the number of lock contention issues to a minimum, if they arise at all, on VMFS-6.