WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple
You are here: Home / VSAN / Additional steps required to completely disable VSAN on ESXi host

Additional steps required to completely disable VSAN on ESXi host

09.26.2013 by William Lam // 11 Comments

Something that I had noticed while working with VSAN in my lab is that when you disable VSAN on your vSphere Cluster, the disks that were used for VSAN in each of the ESXi hosts were no longer available for use afterwards. If you want to use one of the disks for creating a regular VMFS volume or even use it for for vSphere Flash Read Cache, the disks would not show up as an available device. The reason this is occurring is that the disks still contains a VSAN partition and this is not automatically removed when disabling VSAN.

You can view the partition details by using the partedUtil and specifying the "getptbl" option and the device.

Now I could use partedUtil to clear the partition, but there is actually a nice ESXCLI command that can be used to remove the disks used in a VSAN disk group and this will automatically clear the VSAN partition. The ESXCLI command is:

esxcli vsan storage remove -s [SSD-DEVICE-ID]

When I tried to run the command, I was surprised to get the following error message:

Unable to remove device: Can not destroy disk group for SSD naa.6000c29c581358c23dcd2ca6284eec79 : storage auto claim mode is enabled

It turns out when you use "Automatic" claiming mode when enabling VSAN on your vSphere Cluster, that configuration is left enabled on the ESXi host even when disabling VSAN. This then prevents you from destroying the disk group. So there is an extra step required if you choose automatic mode and you will need to run the following ESXCLI command to disable it:

esxcli vsan storage automode set --enabled false

If you are not sure, you can always perform a "get" operation to check whether automatic claim mode is enabled. Once that has been disabled, you will now be able to destroy the diskgroup by running the original command above:

The remove operation only requires the SSD device front-ending the VSAN disk group and you can identify the SSD by running "esxcli vsan storage list". I did find it odd that disabling VSAN in your vSphere Cluster did not completely disable the automatic mode on the ESXi host and I have already filed a bug request to get that fix.

More from my site

  • How to bootstrap vCenter Server onto a single VSAN node Part 2?
  • How to bootstrap vCenter Server onto a single VSAN node Part 1?
  • Restoring VSAN VM Storage Policy without vCenter Part 2: Using vSphere API
  • Restoring VSAN VM Storage Policies without vCenter Part 1: Using cmmds-tool
  • How to run Nested ESXi on top of a VSAN datastore?

Categories // VSAN, vSphere 5.5 Tags // esxcli, ESXi 5.5, Virtual SAN, VSAN, vSphere 5.5

Comments

  1. *protectedLevi Spears says

    03/26/2015 at 7:12 pm

    Hello -

    I have an interesting twist on this - I had an eval VSAN license deployed in my cluster that expired. I removed the VSAN datastore and storage from all hosts and from VCenter, however the cluster still shows a warning that the VSAN datastore has no storage allocated. Have you seen this, and is there a way to determine where the configuration is hung up? All of my hosts show no vsan storage enabled, automode is disabled, etc. Appreciate any suggestions.

    Regards,
    Levi

    Reply
    • William Lam says

      03/30/2015 at 11:37 pm

      Did you disable VSAN from the vSphere Cluster, that's the only thing I can think of that would cause the message to still appear

      Reply
  2. *protectedBrno says

    08/09/2015 at 11:13 pm

    with vSphere 6

    esxcli vsan storage automode set --enable false
    Error: Invalid option --enable

    Reply
    • *protectedBruno says

      08/09/2015 at 11:36 pm

      Automatic to manual setting on the cluster solved it

      Reply
  3. *protectedSteffan R. says

    10/27/2015 at 4:26 am

    Disabling automode and manually removing the SSD with esxcli did the trick! Thanks 🙂

    Reply
  4. *protectedRostislav Soukup says

    12/28/2016 at 4:03 am

    Hi William, just quick update
    instead of:
    esxcli vsan storage remove –s naa.xx
    this works for me:
    esxcli vsan storage diskgroup unmount -s naa.xx
    (on VSAN 6.2)

    Reply
  5. *protectedMike says

    06/08/2017 at 10:37 am

    I just wanted to say this article helped me clear up some things from testing out vsan in my environment. Thanks!

    Reply
  6. *protectedBobb says

    09/06/2019 at 7:17 am

    I had the same thing but for a re-built vSAN node. It wouldn't add back into vCenter with the message "A general system error occurred: unable to push CA certificates and CRLS to host"

    I just found this article as I did a hardware wipe of the vSAN disks after which the host to joined the cluster.

    Reply

Trackbacks

  1. Welcome to vSphere-land! » VSAN Links says:
    03/01/2014 at 12:46 am

    […] Additional steps required to completely disable VSAN on ESXi host (Virtually Ghetto) VMware VSAN - Virtual SAN - How to configure (Virtual-blog) Configure Disk Redundancy VMware VSAN - Virtual SAN (Virtual-blog) […]

    Reply
  2. Consolidated list of all Virtual SAN (VSAN) deep dive resources. | says:
    04/09/2014 at 1:32 am

    […] Additional steps required to completely disable VSAN on ESXi host (William Lam) […]

    Reply
  3. VMWARE vSAN 6.0 trial and instalation | otorbus says:
    10/08/2016 at 6:56 am

    […] http://www.virtuallyghetto.com/2013/09/additional-steps-required-to-completely.html […]

    Reply

Thanks for the comment!Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

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

  • 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
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/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