WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

Quick Tip - Steps to shutdown/startup VSAN Cluster w/vCenter running on VSAN Datastore

07.08.2014 by William Lam // 11 Comments

I know Cormac Hogan already wrote about this topic awhile ago, but there was a question that was recently brought up that included a slight twist which I thought it would be useful to share some additional details. The question that was raised: How do you properly shutdown an entire VSAN Cluster when vCenter Server itself is also running on the VSAN Datastore? One great use case for VSAN in my opinion is a vSphere Management Cluster that would contain all your basic infrastructure VMs including vCenter Server which can be bootstrapped onto a VSAN Datastore. In the event that you need to shutdown the entire VSAN Cluster which may also include your vCenter Server, what is the exact procedure?

To help answer this question, I decided to perform this operation in my own lab which contains a 3-Node (physical) VSAN Cluster that had several VMs running on the VSAN Datastore including the vCenter Server VM that was managing the VSAN Cluster.

stutdown-vsan-cluster-with-vcenter-on-vsan-datastore-0
Below are the steps that I took to properly shutdown down a VSAN Cluster as well as powering everything back on.

UPDATE (4/27) - Added instructions for shutting down a VSAN 6.0 Cluster when vCenter Server is running on top of VSAN.

Shutdown VSAN Cluster (VSAN 6.0)

Step 1 - Shutdown all Virtual Machines running on the VSAN Cluster except for the vCenter Server VM, that will be the last VM you shutdown.

stutdown-vsan-cluster-with-vcenter-on-vsan-datastore-1
Step 2 - To help simplify the startup process, I recommend migrating the vCenter Server VM to the first ESXi host so you can easily find the VM when powering back on your VSAN Cluster.

Step 3 - Ensure that there are no vSAN Components being resync'ed before proceeding to the next step. You can find this information by going to the vSAN Cluster and under Monitor->vSAN->Resyncing Components as shown in the screenshot below.

Step 4 - Shutdown the vCenter Server VM which will now make the vSphere Web Client unavailable.

stutdown-vsan-cluster-with-vcenter-on-vsan-datastore-4
Step 5 - Next, you will need to place ALL ESXi hosts into Maintenance Mode. However, you must perform this operation through one of the CLI methods that supports setting the VSAN mode when entering Maintenance Mode. You can either do this by logging directly into the ESXi Shell and running ESXCLI locally or you can invoke this operation on a remote system using ESXCLI.

Here is the ESXCLI command that you will need to run and ensure that "No Action" option is selected when entering Maintenance Mode:

esxcli system maintenanceMode set -e true -m noAction

Step 5 - Finally, you can now shutdown all ESXi hosts. You can login to each ESXi hosts using either the vSphere C# Client / ESXi Shell or you can also perform this operation remotely using the vSphere API such as leveraging PowerCLI as an example.

Shutdown VSAN Cluster (VSAN 1.0)

Step 1 - Shutdown all Virtual Machines running on the VSAN Cluster except for the vCenter Server VM.

stutdown-vsan-cluster-with-vcenter-on-vsan-datastore-1
Step 2 - To help simplify the startup process, I recommend migrating the vCenter Server VM to the first ESXi host so you can easily find the VM when powering back on your VSAN Cluster.

stutdown-vsan-cluster-with-vcenter-on-vsan-datastore-2
Step 3 - Place all ESXi hosts into Maintenance Mode except for the ESXi host that is currently running the vCenter Server. Ensure you de-select "Move powered-off and suspend virtual machines to other hosts in the Cluster" as well as selecting the "No Data Migration" option since we do not want any data to be migrated as we are shutting down the entire VSAN Cluster.

Note: Make sure you do not shutdown any of the ESXi hosts during this step because the vCenter Server VSAN Components are distributed across multiple hosts. If you do this, you will be unable to properly shutdown the vCenter Server VM because its VSAN components will not available.

stutdown-vsan-cluster-with-vcenter-on-vsan-datastore-3
Step 4 - Shutdown the vCenter Server VM which will now make the vSphere Web Client unavailable.

stutdown-vsan-cluster-with-vcenter-on-vsan-datastore-4
Step 6 - Finally, you can now shutdown all ESXi hosts. You can login to each ESXi hosts using either the vSphere C# Client / ESXi Shell or you can also perform this operation remotely using the vSphere API such as leveraging PowerCLI as an example.

Startup VSAN Cluster

Step 1 - Power on all the ESXi hosts that is part of the VSAN Cluster.

Step 2 - Once all the ESXi hosts have been powered on, you can then login to the ESXi host that contains your vCenter Server. If you took my advice earlier from the shutdown procedure, then you can login to the first ESXi host and power on your vCenter Server VM.

Note: You can perform steps 2-4 using the vSphere C# Client but you can also do this using either the API or simply calling vim-cmd from the ESXi Shell. To use vim-cmd, you need to first search for the vCenter Server VM by running the following command:

vim-cmd vmsvc/getallvms

startup-vsan-cluster-with-vcenter-on-vsan-datastore-0
You will need to make a note of the Vmid and in this example, our vCenter Server has Vmid of 6

Step 3 - To power on the VM, you can run the following command and specify the Vmid:

vim-cmd vmsvc/power.on [VMID]

startup-vsan-cluster-with-vcenter-on-vsan-datastore-1
Step 4 - If you would like to know when the vCenter Server is ready, you can check the status of VMware Tools as that should give you an indication that system is up and running. To do so, you can run the following command and look for the VMware Tools status:

vim-cmd vmsvc/get.guest [VMID]

startup-vsan-cluster-with-vcenter-on-vsan-datastore-2
Step 5 - At this point, you can now login to the vSphere Web Client and take all of your ESXi hosts out of Maintenance Mode and then power on the rest of your VMs.

startup-vsan-cluster-with-vcenter-on-vsan-datastore-3
As you can see the process to shutdown an entire VSAN Cluster even with vCenter Server running on the VSAN Datastore is fairly straight forward. Once you are comfortable with the procedure, you can even automate this entire process using the vSphere API/CLI, so you do not even need a GUI to perform these steps. This might even be a good idea if you are monitoring a UPS and have an automated way of sending remote commands to shutdown your infrastructure.

Categories // ESXi, VSAN, vSphere 5.5, vSphere 6.0 Tags // ESXi 5.5, vCenter Server, VSAN, vsanDatastore, vSphere 5.5, vSphere 6.0

VMware Fusion Tech Preview 2 can now connect to ESXi & vCenter Server!

07.04.2014 by William Lam // 4 Comments

There was a lot of buzz this week on the announcement of the first vSphere Beta that is available for anyone to sign up for (still a private Beta with NDA rules), however one announcement that was probably missed is that the folks over on the VMware Fusion team just released their second Tech Preview of VMware Fusion (Build 1943533). Why is this such a big deal? Well, it includes one very exciting new feature that I have been asking for a awhile now, which is the ability to connect to an ESXi host or vCenter Server using VMware Fusion! VMware Workstation has had this feature for awhile now and I have been hoping the Fusion team would eventually implement something similar and It looks like they have finally answered 🙂

fusion-connect-to-vsphere-1
You now can connect either a Workstation, ESXi host or vCenter Server using VMware Fusion! If you are like me who primary uses a Mac and you do not want to run a single Windows VM just to be able to use the vSphere C# Client, you can now use VMware Fusion to connect to a vSphere system and perform some basic VM operations, which includes managing Virtual Hardware 10 VMs. You can even use this latest version to connect to the beta version of ESXi host.

Under the File menu, there is now a new option called "Connect to Server" or you can use Command+K for keyboard shortcut.
fusion-connect-to-vsphere-0
Here is a screenshot of connecting to a Mac Mini running ESXi 5.5:

fusion-connect-to-vsphere-2
Here is screenshot of connecting to one of my remote vCenter Servers:

fusion-connect-to-vsphere-4
As you can see this is a super handy feature and you can also have multiple connections to various vCenter Servers, ESXi hosts including Free ESXi! This alone is worth grabbing the latest Tech Preview of VMware Fusion! I can not wait for this feature to be officially released with VMware Fusion, this is going to be a must have feature for any VMware/Apple user!

If you have any feedback on this particular feature or others, please leave a comment on the VMware Fusion Tech Preview community forums!

Categories // Apple, ESXi, vSphere Tags // apple, fusion, mac

What happens when Virtual Machines have duplicate instanceUUID's on ESXi?

07.03.2014 by William Lam // 8 Comments

While catching up on some email this morning, I received an interesting question from an internal engineer regarding the behavior when a duplicate instanceUUID is encountered on an ESXi host. An instanceUUID is a unique identifier that is used by vCenter Server to uniquely identify a Virtual Machine within a vCenter Server instance, I have written extensively about this topic here and here. The question that was brought up was what happens when a duplicate instanceUUID is encountered on a standalone/un-managed ESXi host and then it is added to vCenter Server?

I had theory on how this might work, but I figured I might as well try this out in the lab to be sure. I created two standalone ESXi hosts and created a Virtual Machine on each host and made sure that both had the same instanceUUID (yes, the ESXi host will actually generate the instanceUUID property regardless of being connected to a vCenter Server, I suspect this is mainly for a placeholder). I then add ESXi #1 to a vCenter Server and confirmed that the instanceUUID is still the same using the vSphere MOB. I then continue to add ESXi #2 to the vCenter Server and because a duplicate instanceUUID has been detected, vCenter Server automatically updates the second Virtual Machine with a new instanceUUID.

Before adding to vCenter Server:

  • ESXi-1
    • VM1 - InstanceUUID: 52b5e420-9d79-6095-cfdf-dfdd998d205e
  • ESXI-2
    • VM2 - InstanceUUID: 52b5e420-9d79-6095-cfdf-dfdd998d205e

After adding to vCenter Server:

  • ESXi-1
    • VM1 - InstanceUUID: 52b5e420-9d79-6095-cfdf-dfdd998d205e
  • ESXI-2
    • VM2 - InstanceUUID: 502db26b-c32d-6c32-cd6c-1ffc1549d269

An interesting observation that was made by the engineer while testing a similar scenario was that instead of having two ESXi hosts, he just had one. He was a bit surprised to see that the ESXi host actually allowed both Virtual Machines to be powered on even with a duplicate instanceUUID. The reason I believe this was allowed is that both Virtual Machines still had a unique MoRef Identifier along with unique BIOS UUID and more importantly, the instanceUUID property is ONLY used with vCenter Server. From the ESXi host point of view, it does not care if it has a duplicate instanceUUID as it is not used but will try to generate a unique one to begin. This was actually pretty interesting to know and the reason for the initial question was to ensure that the instanceUUID of a Virtual Machine is still the right property to uniquely identify a Virtual Machine within vCenter Server, which it is.

Categories // Automation, ESXi Tags // instanceUUID

  • « Previous Page
  • 1
  • …
  • 398
  • 399
  • 400
  • 401
  • 402
  • …
  • 561
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VMware Flings is now available in Free Downloads of Broadcom Support Portal (BSP) 05/19/2025
  • VMUG Connect 2025 - Minimal VMware Cloud Foundation (VCF) 5.x in a Box  05/15/2025
  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...