New vSAN Cluster has 0 Bytes in Datastore | LAB2PROD
A quick tip to resolve a new vSAN Datastore having 0 bytes in it.
If you have just created a new vSAN cluster and notice the vSAN Datastore has 0 bytes, head over to disk management under Configure (when the cluster is selected in Hosts and Clusters) > vSAN > Disk Management.
You may notice something similar to the below, where none of the disks have been claimed for use from the physical hosts.
Retrying this process whilst tailing the logs with “tail -f /var/log vsan*.log” doesn’t provide in any useful information, rebooting the hosts or destroying and recreating the cluster has no benefit.
If you do some Googling around, you may happen to stumble over some cli commands that you may be able to run. I have previously had to clean up vSAN disk group UUID’s off disks prior to re-imaging hosts so thought I would attempt to clean up this way.. mind you…this was after about the 5th cluster destruction.  I ran “esxcli vsan storage list” resulted in no vSAN disk UUID’s being listed, which from previous experience let me know that they were ready to be claimed for vSAN. Â
Â
This time I took a different approach to create the cluster, rather than create the disk group in the UI, I decided to do it via cli.. as can be seen below… and presto, I now have my reason for it not working!
Â
It turns out I had not assigned a vSAN license to the cluster, this license can be added under the Cluster configuration > Licensing.
If you look carefully you may also notice banner messages on the host that will indicate the same… but being my lab and having gotten used to random warnings I ignored them!
This could be one of many situations where you face a similar issue, if you have encountered another issue that you need assistance with, feel free to either leave a comment below or get in contact.
The author did a very good work explaining a complex subject, in an easy way!
If you're a beginner who wants to start working with nsx, or a professional who wants deepen some parts of it, this is a very good choice to go for!
Contains information related to marketing campaigns of the user. These are shared with Google AdWords / Google Ads when the Google Ads and Google Analytics accounts are linked together.
90 days
__utma
ID used to identify users and sessions
2 years after last activity
__utmt
Used to monitor number of Google Analytics server requests
10 minutes
__utmb
Used to distinguish new sessions and visits. This cookie is set when the GA.js javascript library is loaded and there is no existing __utmb cookie. The cookie is updated every time data is sent to the Google Analytics server.
30 minutes after last activity
__utmc
Used only with old Urchin versions of Google Analytics and not with GA.js. Was used to distinguish between new sessions and visits at the end of a session.
End of session (browser)
__utmz
Contains information about the traffic source or campaign that directed user to the website. The cookie is set when the GA.js javascript is loaded and updated when data is sent to the Google Anaytics server
6 months after last activity
__utmv
Contains custom information set by the web developer via the _setCustomVar method in Google Analytics. This cookie is updated every time new data is sent to the Google Analytics server.
2 years after last activity
__utmx
Used to determine whether a user is included in an A / B or Multivariate test.
18 months
_ga
ID used to identify users
2 years
_gali
Used by Google Analytics to determine which links on a page are being clicked
30 seconds
_ga_
ID used to identify users
2 years
_gid
ID used to identify users for 24 hours after last activity
24 hours
_gat
Used to monitor number of Google Analytics server requests when using Google Tag Manager