vSAN ESA Storage Policy and Encryption FAQ - VCF 9.0
search cancel

vSAN ESA Storage Policy and Encryption FAQ - VCF 9.0

book

Article ID: 437757

calendar_today

Updated On:

Products

VMware vSAN VMware Cloud Foundation

Issue/Introduction

This article provides a technical guide addressing specific customer concerns in a greenfield VCF 9.0 deployment regarding vSAN ESA storage policies and encryption, including avoiding the "Dual encryption applied to VMs on vSAN" Skyline Health alert.

Environment

  • VMware Cloud Foundation 9.0.x (On-Premise)
  • VMware Cloud Foundation 9.0.x (VCF+ / SaaS)
  • vSAN Express Storage Architecture (ESA)

Resolution

1. What is the difference between vSAN Data-at-Rest Encryption and the "Encrypt VM" setting in a vSphere Storage Policy?

  • vSAN Data-at-Rest Encryption: This is a cluster-level feature that encrypts all data natively at the storage layer (cache and capacity tiers). It operates transparently to the virtual machines, requires no VM downtime to enable, and fully supports vSAN storage efficiencies such as deduplication and compression. Management VMs and vCenter can and should reside on this datastore, as it is the standard, supported architecture for VCF.

  • vSphere Virtual Machine Encryption: Triggered via the "Encrypt VM" toggle in a storage policy, this encrypts data at the ESXi host level before it is written to the datastore. Changing a policy to "Encrypt VM" may require a power cycle of the virtual machine for the change to take effect.

2. Is it recommended to use both vSAN Data-at-Rest Encryption and vSphere Virtual Machine Encryption simultaneously? No. Unless dictated by a strict regulatory compliance mandate requiring double encryption, Broadcom strongly recommends against forcing VM-level encryption via a storage policy when vSAN Data-at-Rest Encryption is already enabled.

Utilizing both methods results in data being encrypted by the host and then encrypted again by vSAN. This configuration causes several negative impacts:

3. Can the vCenter Server and VCF Management VMs be encrypted using a vSphere Storage Policy?

[!CAUTION] CRITICAL: Management Lockout Risk > Do not encrypt the vCenter Server appliance, VCF Operations, or core Management VMs using vSphere Virtual Machine Encryption (the "Encrypt VM" toggle in a storage policy).

  • vCenter Server acts as the critical broker between ESXi hosts and the Key Management Server (KMS).

  • If an ESXi host reboots, it requires an active vCenter instance to fetch the cryptographic keys needed to unlock and boot encrypted virtual machines.

  • If the vCenter Server itself is encrypted at the VM-level, the host cannot unlock it during the boot sequence, resulting in a permanent management lockout.

  • To ensure all management components are safely encrypted without circular dependencies, rely exclusively on cluster-level vSAN Data-at-Rest Encryption.

4. Should the default VCF Management VM storage policy be modified from Thick to Thin Provisioning? No. The Management VMs storage policy should remain Thick-provisioned (Object Space Reservation = 100%).

  • VCF deploys the Management Domain with a 100% space reservation as a critical safety mechanism.

  • This ensures that the core management plane (e.g., vCenter Server, VCF Operations, NSX Managers) always has dedicated storage capacity, preventing a management lockout if the vSAN datastore ever reaches full capacity.

  • Standard workload policies should utilize Thin-provisioned (Object Space Reservation = 0%) configurations.

5. Can vSAN ESA Global Deduplication be applied to a storage policy in a cluster using vSAN Data-at-Rest Encryption? No. Clusters utilizing vSAN Data-at-Rest Encryption are currently ineligible for Global Deduplication.

  • The two features are mutually exclusive in the current VCF 9.0 release.

  • Storage policies in this environment should be configured for Compression only.

  • vSAN ESA provides highly efficient, native, always-on compression at the top of the storage stack before encryption occurs, which is why it remains effective even when Data-at-Rest Encryption is enabled.

  • It offers up to an 8:1 space savings with minimal performance impact.

  • Reference: vSAN FAQs

6. Is it supported to change the logical sector size (e.g., 512n to 4Kn) of an existing VM with an installed operating system? No. Modifying the logical sector size of an existing virtual machine disk on the fly is fundamentally unsupported because it requires migrating the data to entirely new disks. You must leave existing VCF Management VMs at their default 512n sector size. The 4Kn setting can be safely enforced on new Standard storage policies for future VM deployments.

Powered by Wolken Software