VSAN-Troubleshooting-Reference-Manual
VSAN-Troubleshooting-Reference-Manual
VSAN-Troubleshooting-Reference-Manual
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Diagnostics and <strong>Troubleshooting</strong> <strong>Reference</strong> <strong>Manual</strong> – Virtual SAN<br />
vsan.check_state<br />
There are 3 checks that this command does:<br />
<br />
<br />
<br />
Check for inaccessible Virtual SAN objects<br />
Check for invalid/inaccessible VMs<br />
Check for VMs for which VC/hostd/vmx are out of sync<br />
Inaccessible Virtual SAN objects are an indication that there is probably a failure<br />
somewhere in the cluster, but that Virtual SAN is still able to track the virtual<br />
machine. An invalid or inaccessible object is when the VM has objects that have lost<br />
the majority of its components or votes, again due to hardware failures. Note that<br />
for a VM’s object to be accessible, it must have a full, intact mirror and greater than<br />
50% of its components/votes available.<br />
The next check is for invalid or inaccessible VMs. These are VMs that, most likely<br />
due to the fact that the failure(s) that have occurred in the cluster, have been<br />
impacted so much that it is no longer accessible by the vCenter server or the ESXi<br />
hosts. This is likely be due to the fact that the VM Home Namespace, where the .vmx<br />
file resides, is no longer online. Common causes are clusters that have had multiple<br />
failures, but the virtual machines have been configured to tolerate only one failure,<br />
or network outages.<br />
Finally, we ensure that the vCenter Server and the ESXi hosts are in agreement with<br />
regards to the state of the cluster.<br />
If everything is ok, then the output should be similar to the following:<br />
/localhost/ie-datacenter-01/computers> ls<br />
0 ie-vsan-01 (cluster): cpu 109 GHz, memory 330 GB<br />
/localhost/ie-datacenter-01/computers> vsan.check_state 0<br />
2014-10-19 16:03:39 +0000: Step 1: Check for inaccessible <strong>VSAN</strong> objects<br />
Detected 0 objects to be inaccessible<br />
2014-10-19 16:03:39 +0000: Step 2: Check for invalid/inaccessible VMs<br />
2014-10-19 16:03:39 +0000: Step 3: Check for VMs for which VC/hostd/vmx are out of sync<br />
Did not find VMs for which VC/hostd/vmx are out of sync<br />
/localhost/ie-datacenter-01/computers><br />
For completeness, here is an example of such an output when there are inaccessible<br />
objects:<br />
/ie-vcsa-03.ie.local/vsan-dc/computers> ls<br />
0 vsan (cluster): cpu 109 GHz, memory 329 GB<br />
/ie-vcsa-03.ie.local/vsan-dc/computers> vsan.check_state vsan<br />
2014-11-27 14:51:24 +0000: Step 1: Check for inaccessible <strong>VSAN</strong> objects<br />
Detected 19 objects to be inaccessible<br />
Detected 34723e54-7840-c72e-42a5-0010185def78 on cs-ie-h02.ie.local to be inaccessible<br />
Detected 4a743e54-f452-4435-1d15-001f29595f9f on cs-ie-h02.ie.local to be inaccessible<br />
V M W A R E S T O R A G E B U D O C U M E N T A T I O N / 84
Change language