"INVALID" machines after vSAN shutdown.

 In some business environments or homelabs it may be necessary to shutdown a vSAN cluster entirely.

VMware has a proper procedure outlined on the documents site.

Shutting Down and Restarting the vSAN Cluster (vmware.com)

Once you have completed your maintenance tasks and fire everything up, you may be startled when you login to each of the hosts and attempt to verify your VMs....

They will probably all display as an "INVALID" status with the GUID Path in the "name" field.

fig.1 - Host 1 - 2 "invalid" machines

fig.2 - Host 2 - 2 "Invalid" machines

This message certainly caught one of my peers off guard during a recent datacenter update. That quick rush of butterflies in your gut that tells you all of your data is now corrupt.

However, I quickly reassured him that nothing was lost and the issue was simply that all of the hosts were still in maintenance mode.

When the vSAN nodes are in maintenance mode after a reboot, none of the stats are correct since none of the vSAN components are allowed to work together. 

fig.3 - 0Byte vsanDatastore

If you have powered on all of the vSAN nodes in the cluster and waited a sufficient amount of time for all the vSAN nodes to communicate, the remediation is actually quite swift.

Remove all the Hosts from Maintenance mode.

fig.4 - Host 2 - Still in Maintenance Mode!

The names will re-appear for each of the Guest objects.

fig.5 - Host 1 - Proper names!

fig.6 - Host 2 - Proper names again!

If all of your workload is on these hosts, you can start your DNS server, then the vCenter server.

fig.7 - vCenter operational again.

Before you know it , you are back in business.

Probably a bright spot for HomeLabs in the ESXi 7.0 U1C release.

 I was looking up the release notes for the 7.0U1C update and spotted this bit of good news.

"With ESXi 7.0 Update 1c, you can use the installer boot option systemMediaSize to limit the size of system storage partitions on the boot media."

https://docs.vmware.com/en/VMware-vSphere/7.0/rn/vsphere-esxi-70u1c.html

I remember this being a design consideration for the new stack that I was deploying at work. I needed to have more than 150GB for the boot media.

Considering that I have 512GB per host there, it probably doesn't make sense to use this new option...

but on my homelab with 24GB of RAM per host, or an embedded deployment in VMware workstation... this could save money and space.

Jason