vSphere 6.5 can't delete datastore

[DKramkowski]

To Preface - I've been working with VMWare since around the 3.5 days. I'm very much a 'fan' of the C# client, and really hate the 'new' Flash based Web client. Well, here's my first real major issue with the web client (other than it's slow, clunky, and has various crashes/faults that require a reload orders of magnitude more often than the C# client's NEVER... Other than cases where a host that the client was directly connected to rebooted, I can't recall ANY time it had ANY issue).. Anyway, back on track - I want to remove a VMFS5 datastore and then re-create it as a VMFS6 datastore, since VMFS5 can't be migrated to VMFS6 like previous VMFS versions. I've removed and deleted datastores many times in the past. Put the datastore offline, and if for some reason something was missed that would prevent that, it'll tell you before you can ever put it offline. Otherwise, the store goes offline, and from there, delete it and have a nice day.

With the web client, however, I have absolutely no idea what it's complaining about. There is literally NOTHING on the datastore. I can put it offline, for both my hosts that access it, and it goes offline/inactive with no warnings or issues - I went so far as to look at all the machines that were originally on the datastore (prior to moving them off it) for machines with snapshots and removed them all - still no bueno.

So I'm at a point where there is NOTHING on the datastore and there are NO snapshots of any kind even remotely associated with the datastore (even though 'in theory', a storage vMotioned machines snapshots shouldn't care about the previous datastore), but yet the junky web client is not letting me delete the store, and not giving me the slightest clue what it's complaining about.

So anyone have any ideas how I can delete this datastore, since it sees to think it's in use, despite the fact that I manually deleted everything that was remaining on the DS, and after which there's NOHTING on it, and ALL snapshots that MIGHT be able to cause issues are consolidated into the VMs?

Side 'plea' : Bring back the C# client!!! The web client just plain sucks. Bad. Beyond bad. The C# client was flat out reliable. The Web Client is hit or miss. At best. And dismally slow in comparison, coming from someone that has been working with VMWare since the 3.5 days. I simply can't stress how much better, faster and more RELIABLE the C# client was than the web client. And I personally know of others that WILL NOT 'upgrade' to 6.5 due to the termination of the C# client. The Web client is an OK option for day to day simple stuff, but at the and of the day, the C# client is beyond orders of magnitude better than the web client for anything other than the simplest console (and console is debatable with how it interacts with firefox), shutdown or reboot of VMs. At this point, I have zero intention of 'upgrading' my production, customer facing environment from 6.0 to 6.5 (at this point, I'd need some insanely ridiculous enhancements in 7.0, INCLUDING the return of the C# client, to go beyond 6.0) - and the performance and reliability of the web client vs the C# client is just... NO. The performance ''suggestions' of VMFS 6 over VMS5 are 'enticing', but considering the drawbacks... Nope. So bring back the C# client. As it was. Forever (and as far as I'm concerned, leave the web client as an option). But let the vastly superior management option continue.

[paramoyoo]

Hi

Check if SIOC is disabled on that datastore.

BTW: to find more details first you should check vpxd.log.

[DKramkowski]

Storage I/O control isn't enabled in my cluster.

I looked through the logs and the only thing that stood out related to trying to remove the datastore was this:

datastoreSystem-145 -- vim.host.DatastoreSystem.removeDatastore: vim.fault.ResourceInUse:

--> Result:

--> (vim.fault.ResourceInUse) {

-->    faultCause = (vmodl.MethodFault) null,

-->    faultMessage = <unset>,

-->    type = "vim.Datastore",

-->    name = "VMWare1"

-->    msg = ""

--> }

--> Args:

-->

--> Arg datastore:

--> 'vim.Datastore:c0647406-94e5-426b-a697-db5c37d782ff:datastore-18'

Still doesn't say a whole lot.

What really gets me is when a datastore is actually in use, it doesn't let you unmount it as it fails the checks - but it's unmounting just fine.

[paramoyoo]

Hi again

if  vim.fault.ResourceInUse so it has to be in use:)

check on all esxi hosts scratch location (ScratchConfig.ConfiguredScratchLocation) and syslog configuration (Syslog.Local.DatastorePath).

[DKramkowski]

Scratch is set to '/tmp/scratch' on both hosts, and the global syslog was already moved to another datastore.

This is what's on the DS now. The eui folder can be deleted and it comes back when the datastore is re-mounted.

Unless there are hidden files that the browser isn't showing, there is that one directory containing one 0.38KB 'slotsfile'. That's it.

Like I said, usually, when there's something actually in use, it'll either warn you that there's something using it still before taking it offline, or flat out refuse to take it offline.

I did have a vSphere replication job replicating to that DS, but all replication jobs have been cleared out, so 'Total Replications' are now zero in vCenter.

I'm at a loss here.

[DKramkowski · Accepted solution]

So I finally figured it out. vSphere seemed to think there was a template still on the datastore (don't know how, but it did). As you can see from the screen clip I posted, there were no VM files on the datastore. The files for the template appeared to have been moved some time back, and when I told it to delete the template (I've never seen it before, but maybe vSphere somehow could have hid the files *shrug*), it returned a 'files not found' error. That's when I poked around and found where the files really were (on another datastore - for at least a month, it seems), and I was able to remove it from inventory, after which I was finally able to delete the datastore.

[StaiertJ]

This condition can also occur if you had a VM attached to a Datastore ISO and you still have a snapshot if that virtual machine.  Once you delete/consolidate the snapshot(s), you should be able to remove the datastore.