What’s new in ESXi 6.5 Storage Part II: Resignaturing

My second post in my vSphere 6.5 series, the first being:

What’s new in ESXi 6.5 Storage Part I: UNMAP

One of the new features from a core storage perspective is a new version of VMFS. In vSphere 6.5, VMware has released VMFS 6, the first major update of VMFS in year (VMFS 5 in 2011). Not earth shattering changes, a lot of pain points have been removed and there has been A LOT of work put into VMFS 6 to improve concurrency of operations and speed up certain procedures. The first thing I want to mention is unresolved volume handling.

Unresolved volume handling has always been a little frustrating. The presence of unresolved VMFS volumes slowed a lot of things down, such as listing new volumes in the create new datastore wizard.

One of the many improvements they made in VMFS was around parallelism of access and dealing with VMFS-wide metadata changes. This has led to, among other things, a rather significant decrease in duration of resignature-related operations.

Additional reading about what an unresolved VMFS is.

The first example of this is  simply listing available unresolved volumes. The time it takes to do this is directly correlated with the number of unsolved volumes present. This affects not only this command, but also anything that issues that command, like the add new datastore wizard.

The ESXCFG-VOLUMES –l command shows unresolved VMFS extents. This is analogous to the SDK method queryUnresolvedVmfsVolume().

Let’s look at an example with 8 unresolved volumes in 6.0 U2. It takes 1 minute and 53 seconds to complete:


A long time for a CLI command. Now let’s look at 6.5:


With ESXi 6.5 and VMFS 6, it takes less than a second. Much faster! So what about actually resignaturing?

Well I ran a test with snapshotting 8 VMFS volumes and then presenting those copies back to an ESXi host and then resignaturing all of them at once, using the SDK method resolveMultipleUnresolvedVmfsVolumesEx_Task. This allows you to pass an array of unresolved volumes at once. To do this, I used my vRO workflow package, since I already had a workflow built that uses that SDK call. Of course you can use PowerCLI or whatever else.

So i created some VMFS volumes:


They were added into a FlashArray protection group (which is basically a consistency group for replication or for creating snapshots). I then ran a workflow to create snapshots of all of the VMFS volumes I created:


You can see the individual snapshots in the FlashArray GUI below:snapshots

I then run my workflow that allows you to choose a protection group and create a VMFS volume for every snapshot by choosing a point-in-time. It:

  1. Takes all of the snapshots
  2. Creates a volume from all of them
  3. Connects them to a host group for a VMware cluster
  4. Rescans and then resignatures all of the volumes in the group


When I did this with VMFS 5, it took 19 minutes, 43 seconds. Ugh.


With VMFS 6, it took 15 seconds! Much faster.65resigna

So there is another great change in vSphere 6.5!  I see quite a bit of our customers cranking out a lot of VMFS copies daily, so this will be very helpful. Many more blogs to come!

5 Replies to “What’s new in ESXi 6.5 Storage Part II: Resignaturing”

  1. I just installed ESXi 6.5 on a 10GB Pure boot LUN, and was surprised to see that the VMFS version is 5.81. In comparison, on a 10GB NetApp boot LUN, the VMFS version is 6.81. What gives?

    Also worth noting is that on a NetApp 8GB boot LUN, ESXi 6.5 would not install, but works ok on 10GB. Minimum size for boot from FC is supposed to be 5.2GB. I have cases open with both VMware and NetApp, and so far it’s been a finger-pointing game.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.