VMware have just released a new build for customers who are on the 6.7 release (7.0 is already out!)

If you take a look at the release notes (https://docs.vmware.com/en/VMware-vSphere/6.7/rn/esxi670-202004002.html) it contains many fixes, some that are very important!

 

PR 2504887: Setting space reclamation priority on a VMFS datastore might not work for all ESXi hosts using the datastore

You can change the default space reclamation priority of a VMFS datastore by running the following ESXCLI command esxcli storage vmfs reclaim config set with a value for the –reclaim-priority parameter. For example,

esxcli storage vmfs reclaim config set –volume-label datastore_name –reclaim-priority none
changes the priority of space reclamation, which is unmapping unused blocks from the datastore to the LUN backing that datastore, to none from the default low rate. However, the change might only take effect on the ESXi host on which you run the command and not on other hosts that use the same datastore.

This issue is resolved in this release.

  • PR 2512739: A rare race condition in a VMFS workflow might cause unresponsiveness of ESXi hosts

    A rare race condition between the volume close and unmap paths in the VMFS workflow might cause a deadlock, eventually leading to unresponsiveness of ESXi hosts.

    This issue is resolved in this release. (i have seen this issue happening many times and i highly encourage you to install this fix asap)

  • PR 2387296: VMFS6 datastores fail to open with space error for journal blocks and virtual machines cannot power on

    When a large number of ESXi hosts access a VMFS6 datastore, in case of a storage or power outage, all journal blocks in the cluster might experience a memory leak. This results in failures to open or mount VMFS volumes.

    This issue is resolved in this release.

    If VMFS volumes are frequently opened and closed, this might result in a spew of VMkernel logs such as does not support unmap when a volume is opened and Exiting async journal replay manager world when a volume is closed

PR 2462098: XCOPY requests to Dell/EMC VMAX storage arrays might cause VMFS datastore corruption

Following XCOPY requests to Dell/EMC VMAX storage arrays for migration or cloning of virtual machines, the destination VMFS datastore might become corrupt and go offline.

This issue is resolved in this release. For more information, see VMware knowledge base article 74595.

 

 

 

 

Leave a Reply