vSAN File services, they are finally here. However in my nested lab, after rebooting the vSAN cluster, often the file services do start but the shares remain unavailable.
A good state of the File Services look like this:
When all goes well, your File Services Shares should have been created at about the same time. In my test example, I have setup 2 different File Shares. So far so good.
However, when I shutdown my vSAN cluster, going through the motions of putting my nested hosts into Maintenance Mode and shutting down the hosts, and then boot the hosts up again and get them out of maintenance mode, the File Services do come back up, but somehow the File Shares are not accessible.
SO I decided to peak into these vSAN File Services using vRLI and to define an alert in vRLI for this type of events. For sure we should be able to find out exactly what to monitor for.
After some tinkering, with vRLI and triggering this event a couple of time, I found something that actually work for me to report on share issues.
filter text on:
OSError: [Errno 19] No such device: '/vmfs/volumes/vdfsDatastore/
Filter at the same time for the following event:
v4_2a236d9a
So know you know also that the File share is not created because vsanfs does not find the device for the share.
To solve this, disable the File Services and wait for all tasks in relation to this have been completed. Then enable the file Services again. After this the shares should be visible and accessible again.
Oh yeah, to create an alert and forward the events to vROps, use the query in the interactive analysis and configure an alert from this query.
Kim
Leave a Reply