vSphere Basics: Correctly decommissioning a vSphere Datastore

Written by

Published on 14/8/2013 - Read in about 4 min (784 words)

Published under VMware and vSphere #Storage #ESX and ESXi #SIOC #vCenter Server

This article is now 9 years old! It is highly likely that this information is out of date and the author will have completely forgotten about it. Please take care when following any guidance to ensure you have up-to-date recommendations.

vmware logo You’d be surprised how many times I see datastore that’s just been un-presented from hosts rather than decommissioned correctly – in one notable case I saw a distributed switch crippled for a whole cluster because the datastore in question was being used to store the VDS configuration.

This is the process that I follow to ensure datastores are decommissioned without any issues – they need to comply with these requirements

No virtual machine resides on the datastore
The datastore is not part of a Datastore Cluster
The datastore is not managed by storage DRS
Storage I/O control is disabled for this datastore
The datastore is not used for vSphere HA heartbeat

Check the datastore for requirements

Datastore Clusters and Storage DRS

If the datastore is part of a Datastore Cluster then you can simply drag it out of the cluster to remove it. Once outside of the cluster Storage DRS will be disabled since you can’t use SDRS without being part of a cluster. Not sure why the requirements state both of these, but that sorts “The datastore is not part of a Datastore Cluster” and “The datastore is not managed by storage DRS”

Storage I/O Control

If Storage I/O is enabled you’ll see a folder with the LUN ID in the root of the datastore:

Storage I/O Control can be manually enabled on a datastore without actually using SDRS or Datastore Clusters, so check that it is disabled by selecting the datastore in the Datastores and Datastore Clusters and going to the Configuration tab. Click properties to open the properties of the datastore and you’ll see the Storage I/O Control checkbox. Make sure it’s un-ticked and this will take care of the “Storage I/O control is disabled for this datastore” pre-requisite.

vSphere HA Heartbeat and dvsData

If you right-click and browse a datastore to be decommissioned you can see that there are potentially several components stored on a datastore, in my screenshot below “.dvsData” is the Distributed Switch configuration data (for more detail see http://www.virtual-blog.com/2010/07/what-is-the-purpose-of-dvsdata/), “.vSphere-HA” contains HA configuration (for more detail see http://www.vladan.fr/what-is-vmware-vsphere-ha-folder-for/).

In the case of vSphere HA it will depend on your clusters’ settings (vSphere HA > Datastore Heartbeating) as to which datastores it uses – if you manually select datastores using “Select only my preferred datastores” then you need to go in and select new datastores. As far as I can tell the only way you will fail the “The datastore is not used for vSphere HA heartbeat” check is if you manually specify only 2 datastores then try and decommission one of them. Personally, I’ve yet to see a really good argument for specifying datastores to be used with HA.

The .vdsData folder is created on any VMFS store that has a Virtual Machine on it that also participates in the VDS – so by migrating your VMs off the datastore you’ll be ensuring the configuration data is elsewhere.

VMs and Templates

You can also see in my screenshot below a template folder and two virtual machines that haven’t been migrated across to a new datastore. An easy step is to migrate the VMs and move the template – pretty standard Storage vMotions. That qualifies you for the “No virtual machine resides on the datastore” pre-requisite. VMs or Templates that have been removed from Inventory will not block an unmount of a datastore - so move it or lose it!.

Unmounting the Datastore

Once the datastore is fully evacuated you can browse to “Datastores and Datastore Clusters”, right click the datastore and select Unmount

The wizard then presents you with a list of hosts that can access the datastore, and the option to remove access from some or all of them. This datastore needs to be decommissioned, so remove access from all hosts:

Ensure you’ve got all the green ticks for the re-requisites

Finish the wizard and you should see the unmount tasks complete on each host that can see the datastore:

And the datastore is marked as inactive:

Detaching the unmounted datastores

This can be a bit of a manual process, going to each host in turn and detaching the storage device that backs the datastore (select the host > Configuration > Storage > Devices > Select device and right click > Detach). Or you could download @alanrenouf’s PowerCLI script to help make it a bit easier! It’s available here - https://communities.vmware.com/docs/DOC-18008.

Using the Detach-Datastore function is dead easy:

Get-Datastore “Datastore Name” | Detach-Datastore

(You can ignore the DEBUG messages – you won’t see them unless you have set $DebugPreference=”Continue”)

Once this is done it’s now safe to un-present the LUNs from your hosts! Thanks for reading and I hope it saves you some time and hassle!