High capacity usage of the vSAN Datastore on target site due to large PSF files for VMs replicated with vSphere Replication
searchcancel
High capacity usage of the vSAN Datastore on target site due to large PSF files for VMs replicated with vSphere Replication
book
Article ID: 375312
calendar_today
Updated On: 04-18-2025
Products
VMware Live RecoveryVMware vSAN
Issue/Introduction
PSF file (vSphere Replication persistent state file) capacity value for "used capacity" is equal or greater than the size of the base VMDK for VMs replicated using vSphere Replication on vSAN
vSAN skyline capacity display screen shows the below:
Environment
VMware vSAN
VMware vSphere Replication
VMware Live Recovery
Cause
This is caused when the VM Home Directory Policy is Thick Provisioned
By default PSF file is deployed with a "Thin" flag.
The PSF file only contains information of the changed blocks of the disks
Once the block changes are replicated to the target site, they are discarded and new set of block changes are active - This cycle continues
This works well on VMFS
However, in vSAN, the "Thin" flag for the PSF is prevailed over by the Storage Policy of the namespace (VM Home Directory)
Therefore, whenever a VM is configured for replication, information regarding all the blocks of all the disks are added into the file
This bloats the PSF file to a huge uncontrollable size.
Example:
#esxcli vsan debug object list -u e669b361-8a91-7200-1ced-xxxxxxxxxxxx
structtype: ObjectInfo Health: healthy Object UUID: e669b361-8a91-7200-1ced-xxxxxxxxxxxx Version: 15 Owner: esxi.xxxx.net Policy: stripeWidth: 1 cacheReservation: 0 proportionalCapacity: 100 <---------------- meaning all of the capacity assigned to the object is allocated (thick) hostFailuresToTolerate: 1 forceProvisioning: 1 spbmProfileId: c9eb54d4-c849-4af0-b7b6-xxxxxxxxxxx spbmProfileGenerationNumber: 0 replicaPreference: Performance iopsLimit: 0 checksumDisabled: 0 CSN: 20183 SCSN: 17893 spbmProfileName: Thick_Policy
Resolution
This behavior is changed in ESXi 8.0 P05 and above.
Workaround:
Re-configure the VMs with a Storage Policy "Thin" for the namespace of the VM (VM Home Directory).