Along with other improvements to VMFS-6, there is also a new block allocation mechanism which aims to reduce lock contention between hosts sharing the same VMFS-6 filesystem. To understand how lock contention could arise, it is important to understand that resources on VMFS are grouped into resource clusters; this is the same for VMFS-6 and earlier versions on VMFS. Resources could be file descriptors, sub-block, file block, pointer blocks, and so on. Historically, we have always tried to allocate different resource clusters to different ESXi hosts, which meant that only VMs running on the same host shared resources within the…
Something that I only just recently noticed is that we have made a change to the sub-blocks structure on VMFS-6, compared to VMFS-5. Sub-blocks are small allocations on a VMFS volume, and they are used to back small files. They were introduced as a space-saving measure to prevent using a full file block to back a very small file. To put this simply, when a file is created on VMFS, it is initially backed by a sub-block, and when the file grows above the size of a sub-block, it is switched to being backed by a file block (this has…
When vSphere 6.5 released towards the end of 2016, it introduced a brand new version of VMFS, VMFS-6. VMFS probably needs little in the way of introduction at this stage, it being VMware’s flagship filesystem for over 10 years at this point. There is an older VMFS whitepaper available here if you are new to VMFS and want to get more of an overview. Now VMFS-6 introduces two new internal block sizes concept for file creation. These are referred to as LFB (Large File Blocks) and SFB (Small File Blocks) and are used to back files on the VMFS-6 volume.…
Last week, I was rolling out Horizon View v7.1 on my new vSAN 6.6.1 all-flash configuration in the lab. Now, one of the pet peeves a few of us have had with this configuration was that a warning was always reported around read cache reservations on all-flash vSAN. Of course, read cache is irrelevant to all-flash (AF) configurations as it does not use a read cache; this is only applicable to hybrid vSAN configurations. This is why it was such as annoyance.
Many regular readers will be aware of new encryption features added recently to VMware’s portfolio, such as vSAN data-at-reset encryption and vSphere VM encryption in vSphere 6.5. I had to return to a configuration task that I hadn’t done in a while, which was the deployment of a new Key Management Server (KMS) on my vSphere 6.5 / vSAN 6.6.1 setup. I had done this a few times before, but it has been a while and I’d forgotten what exactly I’d needed to do, so I decided to document the steps in this post for future reference. Those of you…
For those of you who may have missed it, vSphere 6.5U1 was released very recently. This new release of vSphere also brought along a new release of vSAN, version 6.6.1. Included in this release are a few really nice features that did not make it into the major 6.6 release of vSAN that we had earlier this year. However some of these features are quite significant, especially as we work to make HCI (hyper-converged infrastructure) more and more easy to deploy, configure and manage.
vSAN 6.6 shipped earlier this year. It comes with a new on-disk format to support, among other things, data at rest encryption (also known as DARE). This is version 5 of the on-disk format. I’ve been asked this question a number of times over the past week, so I thought I would quickly write a few words on whether or not enabling encryption on vSAN 6.6 requires an on-disk format change, more commonly referred to as a DFC. Now this post is not going to cover vSAN encryption in any great detail; I just want to answer this one question…