vSAN Health Service – Online Health – Multiple VMs share the same VM home namespace

Products

• VMware vSAN

Issue/Introduction

This article explains the Online Health - Multiple VMs share the same VM home namespace check in the vSAN Health Service and provides details on why it might report a warning.

Environment

VMware vSAN 6.5.x
VMware vSAN 6.7.x
VMware vSAN 7.0.x

Cause

VMs uploaded to the same namespace on the vSAN datastore
Files copied to the wrong namespace folder

Resolution

Q: What does the Online Health - Multiple VMs share the same VM home namespace check do?

vSAN doesn't recommend multiple VMs placed in the same VM home namespace. There are the following potential issues 

    - This would mean the namespace is actively accessed on each ESX host where the VMX is running. This will lead to increased contention on VMFS as the number of VMs scale.

    - VM Home Namespace objects are sized to support a single VM, as the number of VMs sharing the VM Home Namespace increases there is a risk of running out of capacity.

    - A single inaccessible object will now impact many VMs

This check is to validate if there are any VMs in the vSAN cluster running in this unrecommended configuration.

Q: What does it mean when it is in a warning state?

If this check shows a warning, it means there's more than 1 VM placed in the same VM home namespace which is not recommended by vSAN.

Q: How does one troubleshoot and fix the warning state?

It's recommended to move each VM to a dedicated VM home namespace. 

There are several options to fix the problem. Option 1 is highly recommended as it won't introduce workload downtime. If the cluster only has a vSAN datastore, option 2 also works.

1. Migrate the VM to a non-vSAN datastore and then move it back. You can select "Change storage only". This is the recommended way to fix the health check warning. If the cluster only has a vSAN datastore, suggest mounting an NFS datastore for VM migration. Note, it won't impact the running workload during VM migration but slight performance degradation would be expected.
2. Shut down and unregister the VM. Then create a new folder on the vSAN datastore, move all the VM files to the new folder and register it again. Note, the VM's instance UUID won't be changed, so the performance stats will be reserved after registering the VM back. But user workload downtime is expected as the VM will be shut down.
   • Create a new folder

                    

1. • Select all the VM files and move to the new folder by following the instructions   

                   

• • Register the VM

                    Select the *.vmx file and click "REGISTER VM".

                     

Once the remediation steps are completed, you can try to retest the health summary with online health toggled.

Additional Information

Impact/Risks:

• The namespace objects can grow to a max of 255 GB. They are thin provisioned and small in practice, but as the number of VMs grows we're more likely to run out of space
• A single inaccessible object will now impact many VMs