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 />
Handling a vCenter Server Failure<br />
When moving hosts from one vCenter server to a new vCenter server, particularly if<br />
the original vCenter server has failed, there are 3 main considerations:<br />
1. Order of adding hosts to new Virtual SAN cluster object on new vCenter<br />
server<br />
2. Missing policies on new vCenter server<br />
3. Handling distributed switch issues (if these are used in the environment)<br />
My colleague, William Lam, in this blog post, eloquently describes the procedure.<br />
http://www.virtuallyghetto.com/2014/09/how-to-move-a-vsan-cluster-from-onevcenter-server-to-another.html.<br />
Let’s discuss these in more detail.<br />
The first point relates to trying to add all of the ESXi hosts from the existing Virtual<br />
SAN Cluster to the new Virtual SAN Cluster at once. This method results in an error<br />
regarding UUID mismatch. To avoid this, add one host first to the cluster and once<br />
that task has been done, add the remaining ESXi hosts to the cluster. This avoids this<br />
issue.<br />
The second point relates to the VM Storage Policies associated with the virtual<br />
machines. The VMs will continue to run with these policies, but unfortunately the<br />
new vCenter server will not know about them. There is an RVC command that can<br />
help to create these policies on the new vCenter Server. The command is<br />
vsan.recover_spbm. Not only will it detect VMs that are missing policy settings,<br />
but it will also provide the option to recreate policies on the new vCenter server, as<br />
shown here:<br />
vsan.recover_spbm<br />
/localhost/vsan-dc/computers> vsan.recover_spbm 0<br />
2014-12-02 14:54:02 +0000: Fetching Host info<br />
2014-12-02 14:54:02 +0000: Fetching Datastore info<br />
2014-12-02 14:54:02 +0000: Fetching VM properties<br />
2014-12-02 14:54:02 +0000: Fetching policies used on <strong>VSAN</strong> from CMMDS<br />
2014-12-02 14:54:03 +0000: Fetching SPBM profiles<br />
2014-12-02 14:54:04 +0000: Fetching VM SPBM profile association<br />
2014-12-02 14:54:04 +0000: Computing which VMs do not have a SPBM Profile ...<br />
2014-12-02 14:54:04 +0000: Fetching additional info about some VMs<br />
2014-12-02 14:54:04 +0000: Got all info, computing after 1.92 sec<br />
2014-12-02 14:54:04 +0000: Done computing<br />
SPBM Profiles used by <strong>VSAN</strong>:<br />
+-------------------------------------------+---------------------------+<br />
| SPBM ID | policy |<br />
+-------------------------------------------+---------------------------+<br />
| Existing SPBM Profile: | stripeWidth: 1 |<br />
| Virtual SAN Default Storage Policy | cacheReservation: 0 |<br />
| | proportionalCapacity: 0 |<br />
| | hostFailuresToTolerate: 1 |<br />
| | forceProvisioning: 0 |<br />
+-------------------------------------------+---------------------------+<br />
| Existing SPBM Profile: | stripeWidth: 1 |<br />
| Virtual SAN Default Storage Policy | cacheReservation: 0 |<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 / 1 9 1
Change language