Datastore heartbeating allows vSphere HA to monitor hosts when a management network partition occurs and to continue to respond to failures that occur. Use the Configure Datastore Heartbeating dialog box to specify the datastores that you want to be used for this purpose.
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
- Had my special time with the VMware Storage Support engineer. I think it was good for both of us to spend some private time, together. What we found to be hosing things up was that pesky sys folder, and the fact that it was on the first DS (datastore) created after I nuked the physical arrays.
- What is VMware vCenter Server Heartbeat? VMware vCenter Server Heartbeat is a software product that protects vCenter Server against outages–from application, operating system, hardware and network failures to external events–regardless of whether vCenter Server is deployed on a physical or virtual machine.
- 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
Vmware Datastore Path
(You can ignore the DEBUG messages – you won’t see them unless you have set $DebugPreference=”Continue”)
Add Nfs Datastore Vmware
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!
Share this post
Please enable JavaScript to view the comments powered by Disqus.