5.4.0 Release Notes

Release Notes for VMware Solutions
Audience
Public
Content Type
Release Notes
Technology Integrations
VMware
Source Type
Documentation

Release: May 2025

General

Version 5.4.0 of the Everpure vSphere HTML Remote Client Plugin supports vSphere (vCenter and ESXi) version 6.7U3 and later and Purity version 6.1.x and later. Users can upgrade to this version of the plugin via deploying the Everpure VMware Appliance. This version is certified with VMware.

Note: The remote plugin is supported with vSphere 6.7 U3 and later by Everpure, but is only certified by VMware for 7.0 and later. VMware does not certify remote plugins on releases prior to 7.0.
Note: VMware will not be certifying remote plugins with partners starting with vSphere 8.0 U3 and later. When VCF/VVF 9.0 is released there will not be a certification process for remote plugins. This does not mean that remote plugins are not supported or do not work with VCF 9.0, but that they are a partner validated and partner supported integration with vSphere.

Important notices regarding the vSphere Client Plugin:

  • Starting in vSphere 8.0, VMware no longer supports local plugins to be installed in vCenter (Everpure vSphere Plugin versions 4.5.2 and below). Please use the remote versions of Everpure's vSphere plugin (Everpure vSphere Plugin versions 5.0.0 and above). For more information please refer to this VMware KB.

  • This version of the plugin uses the VMware Remote Plugin Architecture

    • More information on the VMware Remote Plugin Architecture can be found

      here.

    • More information on why Everpure is using this can be found here.

  • Release notes for Everpure's VMware Appliance (OVA) can be found at this page. Everpure's remote vSphere plugin can be updated independently of the appliance. The VMware appliance can be downloaded here. The installation guide for the remote vSphere plugin can be found here

What's New

  • TMAN-20145: NFS Datastores Quality of Life improvements, new features and updates to creation wizard.
    • TMAN-20148: Mount NFS Datastore on Additional Hosts
    • TMAN-20149: Edit NFS Datastore Export Policies
    • TMAN-21319: Support for selecting the FlashArray Filevip to mount the NFS Datastore with.
    • TMAN-21320: Support for nconnect with NFS Datastore.
      • When creating the NFS Datastore or when mounting to additional hosts the user will have the option to specify the number of connections established which can increase performance.
    • TMAN-21322: Support NFS 4.1 multipath feature
      • When creating an NFS datastore or when mounting an NFS datastore to additional hosts, users will be able to select multiple filevips for the connections to be established with.
    • TMAN-22243: Support vmknic binding with with NFS 3 and NFS 4.1 datastores

      • When creating a new NFS Datastore or when mounting an NFS datastore to an additional hosts, users will be able to specify the vmk that the host establishes the connection with.

    • TMAN-22374: Enable Autodir in NFS datastore by default, the feature is no longer an optional export config on supported Purity//FA versions.
  • TMAN-21757: VM Teleport feature support

Fixed Issues

  • TMAN-22137: An issue was discovered when an NFS Datastore had it's export or file system renamed on the FlashArray, then the VM Capacity and Performance Views show an error VMs on the NFS datastore. This issue is now fixed.
  • TMAN-22358: When hosts in an ESXi cluster in a non-uniform configuration were connected to a stretched volume and issue was discovered where the host connections view would shows error and not display the host connection status and could impact other workflows as well. This issue is now fixed.
  • TMAN-22474: An issue was discovered where a race condition could occur when the vSphere plugin would attempt to rescan or discover a device before the ACL on the volume was fully established with the volume connection. Which would in turn cause the datastore creation wizard to return an error that the device was not found. This issue is now fixed.

Known Issues

The intended workflow when restoring a virtual machine from a point in time snapshot should require the virtual machine to be powered off. The revert VM should not be able to be executed with a powered on VM. This failsafe is in place with a vVols based VM, however for a NFS based VM this failsafe is not in place. Allowing users to revert an NFS based VM while powered on. This will cause the VM to be corrupted. While this issue is being resolved, please ensure that the VM is powered off before the VM is reverted. Thank you.