Urgent Patch (8.0U1c) Available to Prevent Inaccessible Data Risk for VMs on vSAN ESA (Version 8.0, 8.0 P01, 8.0 U1, 8.0U1a (EP1))
search cancel

Urgent Patch (8.0U1c) Available to Prevent Inaccessible Data Risk for VMs on vSAN ESA (Version 8.0, 8.0 P01, 8.0 U1, 8.0U1a (EP1))

book

Article ID: 326664

calendar_today

Updated On:

Products

VMware vSAN

Issue/Introduction

This article provides information regarding a potential risk of inaccessible data, which is rare and specific to vSAN ESA. VMware publishes this KB to strongly recommend upgrading to 8.0U1c to prevent the data risk.

Symptoms:

VMs running on vSAN ESA with version 8.0 / 8.0 P01 / 8.0 U1 / 8.0U1a (EP1) which currently have or have previously had snapshots face a risk of encountering inaccessible data over a certain period, manifested as following:

  • VMs unable to power on
  • Hosts not responding
  • In some cases, PSOD

vSAN OSA of the same version does not have this issue.


Environment

VMware vSAN 8.0.x

Cause

The likelihood of encountering this issue is low and limited to vSAN ESA with version 8.0, 8.0 P01, 8.0 U1, or 8.0U1a (EP1) only. However, the possibility of encountering it might gradually increase over time. The presence of a high frequency of snapshot creations and deletions (typically through frequent backup schedule) of more than twice a day increases the likelihood of encountering this. Changing the snapshot or backup schedule to be less frequent will reduce the chances of encountering this until upgrade can be performed.

Resolution

VMware strongly recommends all vSAN ESA clusters with versions 8.0, 8.0 P01, 8.0 U1, or 8.0U1a (EP1) be upgraded to 8.0U2 or later releases as soon as possible to prevent this issue.

Note: vSAN ESA clusters running with version 8.0U1c are not exposed to the issue but it's recommended to upgrade to 8.0U2 as a best practice.

Until the patch can be applied, it is recommended to take the following measures to reduce the risk of encountering the issue:
- Temporarily adjust the snapshot schedule (typically through respective backup schedule) of concerned VMs to no more than twice a day.