VSI 8.5 – Snapshots + Manual UNMAP

We’ve dropped release 8.5 of Virtual Storage Integrator (VSI) today which brings snapshots into the plugin. My last post on VSI was for 8.3, because the 8.4 release was only for the introduction of the PowerStore platform and their team took care of that. The 8.5 release is more universal, including features for our multiple platforms. For PowerMax there are 2 major features, and 1 minor tweak. They are:

  • Array snapshots phase 1 (on PowerMax SnapVX)
  • Manual UNMAP
  • XCOPY rule change

Before I get into the detail, I did want to mention two VSI restrictions.

External PSC

An important change in the VSI implementation which began in the last version, 8.4, is that VSI no longer supports an external Platform Service Controller (PSC) implementation for the vCenter – only embedded. Now in vSphere 7, external is no longer available so no worries there, but we are supporting vSphere 6.7 which still has an option for external PSC, so please keep that in mind. BTW, VSI has no ability to check for an external PSC so it will still let you implement the plugin in those vCenters. Then you’ll have all sorts of problems. So this one’s on you to make sure you only use embedded PSCs.


This one is a bit simpler. VSI does not support FC-NVMe. I haven’t had any customers ask about supporting it so we are likely to wait on this until NVMeoF is more fully ported over (e.g. no support for RDMs).

Array Snapshots

You’ll note the qualifier of phase 1 for the array snapshots above indicating that there is more than a single release of the feature planned. This is due to the complexity involved. This first phase includes:

  • Enabling users to manage snapshots (disabled by default)
  • Manage on-demand creation of VMFS datastore snapshots
  • Link/unlink VMFS datastore snapshots
  • View, edit, and delete snapshots

For this feature I did a video rather than screenshots. The video has callouts (I rarely do voice over) but at a high level, the following tasks are completed:

    • Enable a user to manage snapshots on an array
      • Login as said user
    • Create a new datastore for use with the snapshot feature
    • Create a new snapshot of that datastore
    • Link that snapshot which will mount a resignatured datastore copy
    • Unlink the snapshot
    • Delete the snapshot

I want to cover one minor topic before the demo since you’ll see it called out there – snap source and target fields.

Snap Source/Target

This is a bit in the weeds, but you may find it of interest. There are two columns in the VSI datastore Storage Details called Snap Source and Snap Target. Usually I talk about these rows in terms of XCOPY, that being when there is an active XCOPY job they can be populated; but they are also useful for knowing if the device is associated with a snapshot as either source or target (and if so XCOPY cannot be used). Below I’ve taken a screenshot of the details after taking a snapshot of the datastore VSI_DELETE_01 and linking it to another device. Here you can see that the datastore with the snapshot is a Snap Source, while the snapshot linked target is a Snap Target. 

You’ll see this in the demo also so on we go.


Things to consider when using snapshots with VSI 

  • When you link a snapshot you can only do so to the same vCenter AND only to storage groups that are masked to the same host(s) of the source datastore. Now, theoretically you could have linked vCenters and a single masking view that presents storage to hosts in both vCenters and thus both vCenter hosts would see the linked datastore.
    • (Presentation to different hosts is a phase 2 endeavor)
  • If you plan on using the snapshot feature in VSI for a particular datastore, it is best to do all snapshot-related activities with it. For example, if you delete a snapshot datastore outside of the VSI interface you will be left with a device in the storage group until you unlink the snapshot from within VSI.
  • If you create snapshots of a storage group in another interface (Unisphere or REST) and then tell VSI to use it for a particular datastore, VSI will only link the chosen datastore even if the storage group has multiple devices. 
  • There is no secure snapshot integration. You would need to use Unisphere for that.
  • When unlinking a snapshot, if you have an existing VM on that copied datastore, it will fail. That isn’t us of course, that’s a VMware restriction. Note that it is sufficient to simply remove the VM from inventory, rather than delete it (which may take more time), since the datastore is being deleted anyway.

Since we are talking about local replication I’ll take a minute to address remote replication. VSI does not have support for SRDF to protect datastores remotely. It’s not on the roadmap yet. It’s important to understand that remote replication and VSI is a two-way street: We have no ability to add SRDF through VSI, and we have no knowledge of SRDF’s existence on the backend. For example, if you use VSI to create a datastore and then later your storage administrator adds SRDF to that underlying device, VSI is none the wiser. So if the VMware administrator then decides to expand that device through VSI, it will fail because it doesn’t know the device is protected by SRDF (an additional parameter would be required for expansion). I mean it makes sense that if we don’t support SRDF through VSI, we would not know about it on the backend, but just something to consider.

Manual UNMAP

This is one of those older features in VSI 7.x which they have brought forward. There was a need for it on the PowerStore platform, but it was easy enough to implement it for all platforms so development did so (yeah easy for the engineer to say). You might use manual UNMAP if you have a VMFS-5 datastore or if you like to closely manage this type of activity even on VMFS-6 by disabling auto UNMAP.

The feature is available via the Dell EMC VSI Actions menu as Run Space Reclamation. I’ve included this below with the subsequent screen.

For this one I also did a quick video walk through of the process. One note of caution about VSI’s free space reporting: In order to avoid too many REST calls, VSI will only update the free space of a datastore every 20 minutes. If you happen to run the reclaim right after the free space was updated, you would have to wait 20 minutes to get an accurate value in VSI. In my video I got lucky and the timings worked out. If you are in the former camp, however, you could do a quick check in Unisphere (or have the SA do it for you) that the space is actually reclaimed if you are unsure (or wait 20 minutes). In the next release we should have an “on demand” button option so you can get results immediately.

XCOPY Rule Change

This last one gets short shrift because it is all behind the scenes and has been done to satisfy a future. VMware is moving away from custom (i.e. vendor) VAAI plugins to their generic plugin. They have not yet said in what release this will happen (it actually was supposed to happen in vSphere 7 but got pushed), but it will. When it does, VMware will have a process by which the generic plugin will take over the duties of the custom plugin so you need not worry; however as we support the generic plugin now it just makes sense to use it when VSI creates the XCOPY rule. So instead of using our custom plugin, VMW_VAAIP_SYMM, we will use VMW_VAAIP_T10. Again, this is all behind the scenes. But if you wanted to check after creating the new rule through VSI, you can run the following CLI in the screenshot. I have a before and after here:

Well that’s it. Feel free to test it all out since, well, it’s free.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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

Website Powered by WordPress.com.

Up ↑

%d bloggers like this: