Well, not sure this legit to try, but did try it.. And it seemed to work, I was able to recreate the storage domain as needed... Access the database, and find the bogus storage domain. I figured out the table names from other discussions about accessing the database directly to clean up storage domains that are broken or bogus. # su - postgres $ psql engine engine=# select id, storage_name from storage_domain_static; id | storage_name --------------------------------------+------------------------ 072fbaa1-08f3-4a40-9f34-a5ca22dd1d74 | ovirt-image-repository 3e81b68f-5ddd-49a3-84e5-7209493b490a | Datastore_01 2b6d2e60-6cfb-45cd-a6e1-8cf38ad2bf34 | Datastore_02 66f9539a-d43a-4b0b-a823-c8dafa829804 | Datastore_03 1878bd36-7bca-4d6b-9d39-fe99ba347115 | Datastore_04 aa5542bd-b43a-4ae6-a996-208c10842878 | Datastore_05 (6 rows) Delete the 'Datastore_02' storage domain... Maybe someone can explain why the same id is in two different tables? That seems odd? engine=# delete from storage_domain_dynamic where id='2b6d2e60-6cfb-45cd-a6e1-8cf38ad2bf34'; DELETE 1 engine=# delete from storage_domain_static where id='2b6d2e60-6cfb-45cd-a6e1-8cf38ad2bf34'; DELETE 1 Then I was able to remove the connection... Still have no idea why I could not remove the domain and connection via ovirt shell, as noted before in previous mail discussion... [oVirt shell (connected)]# show storageconnection 21fbad73-f855-48fc-8949-e5d6b077eb83 id : 21fbad73-f855-48fc-8949-e5d6b077eb83 address : crazy nfs_version: auto path : /storage/nfs/datastore_02 type : nfs [oVirt shell (connected)]# remove storageconnection 21fbad73-f855-48fc-8949-e5d6b077eb83 job-id : ba9094ee-8d6e-438b-b774-601540320768 status-state: complete I also had to clean up the file system under the connection... since it appears the file system structure was created BEFORE the error resulted that kicked off this, that is also a bug, IMHO, since it should have cleaned up the files created, but the storage domain was never FULLY established. This is something oVirt has never done... cleaned up will after errors... I remember all the way back in version 3.0 if not before, how clean up is never done well. This is an example apparently. A suggestion... is the master is not 100% active, and a request to create a new domain is queued, does it not make sense, the failure should be graceful, clean up the database, and the file system below the storage domain? Would see to be a very 'user' friendly thing to do. I mean, this a way to protect both the environment and the user from a typical issue. The same should be done for attach of domain, i.e. the storage domain and storage connection clean up, if error results. If there still some junk in the database I need to cleanup, please let me know? On 08/07/2017 20:01, Schorschi . wrote: