Datastore ‘{name}’ is not accessible. “No connected and accessible host is attached to the datastore.”

At a client’s we encountered a rather classical error, a dismounted datastore that couldn’t be removed/distroyed. So the customer just deleted the LUN from the storagebox expecting the datastore to disappear from the inventory. That didn’t happen. Neither did the datastore get removed after a reboot of the VCSA.

The customer was adament that everything from the datastore was moved to other datastores prior to the unmounting. The filesystem seems empty (except for the default folders (.naa.XXXXXXXXXX and .ssd.sf) And all of the VMs were XvMotioned to other datastores.

Two other datastores were assigned to be used by vSphere HA as Heartbeat Datastores

So why couldn’t it be removed?

I’ve tried searching for harddisks or iso’s being mounted from the datastore, but no results. So indeed no VM seemed to have any connection to the datastore.

If you already figured out, what we missed, skip ahead,  you probably didn’t need this article at all. If you still have the same issue, continue…

“Let’s just delete the datastore from the inventory database”

So I decided to try to remove the object from the database, I’ve removed some VMs from a MS SQL database in the past, but this was the VCSA using the vPostgres database.

With the help of these articles I figured out how to connect to the database and the necessary SQL statements:

So to connect to the database, first make sure that you can connect with an SSH client to the VCSA.

Browse to: https://yourvcsa.domain.tld:5480

  1. Click Access
  2. Click the Edit button
  3. Toggle to enable “Enable SSH Logon” (Optional: toggle Enable BASH Shell)
  4. Click the OK Button

Now using your favorite SSH client connect to the VCSA. If you didn’t toggle the Enable BASH Shell, you’ll be greeted with the Appliance Shell.

Type shell

You’ll be taken to a BASH shell.

At the root@vcenter [ ~ ]#  prompt type:

/opt/vmware/vpostgres/current/bin/psql -d VCDB -U postgres

We should now enter the psql tool

At the VCDB=# prompt you can type \d to list all tables. To check if everything is working.

After I could see the tables (such as vpx_entity), I tried to find the datastore:

Make sure you substitute all names, and id’s with the correct values! Shown, in purple, blue, green and orange in the examples below.

VCDB=# SELECT id FROM vpx_entity WHERE name = 'MyStubbornDatastore';

It gave me 1 result, just how we like it.

   id
--------
162667
(1 row)

So now we knew the Id of the datastore, lets find out if it is being connected to something:

VCDB=# SELECT * FROM vpx_ds_assignment WHERE ds_id=162667;

ds_id   | entity_id | accessible | mount_path | mount_id | mount_mode | mounted
--------+-----------+------------+------------+----------+------------+---------
162667  |    165936 |            |            |          |            |
162667  |    165348 |            |            |          |            |
(2 rows)

So apparently it is not one object, there are two objects in the inventory that are still connected to this datastore…

But which objects are these:

VCDB=# SELECT * FROM vpx_entity WHERE id=165936;
   id   |       name        | type_id | parent_id
--------+-------------------+---------+-----------
165936  | Win10-Tmpl-VMware |       0 |    163490
(1 row)
VCDB=# SELECT * FROM vpx_entity WHERE id=165348;
   id   |      name        | type_id | parent_id
--------+------------------+---------+-----------
165348  | Win7-Tmpl-VMware |       0 |    163490
(1 row)

Ok, so there are two templates still connected. Templates that were already somewhat removed, since there was no data left on the datastore before the LUN got destroyed. So just ‘Remove from Inventoried’ those using the H5 client. So no actual database hacking involved.

After the last template was removed the datastore disappeared from the inventory.

When the links can’t be removed using the GUI, you might want to try removing the datastore from the tables:

DELETE FROM vpx_ds_assignment WHERE ds_id=162667;
DELETE FROM vpx_datastore WHERE id=162667;
DELETE FROM vpx_vm_ds_space WHERE ds_id=162667;

Do this on your own risk, and be sure to create a snapshot or backup of the VCSA before deleting or changing anything directly in the database.