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:

Bit more information...

[oVirt shell (connected)]# list storagedomains

id : 2b6d2e60-6cfb-45cd-a6e1-8cf38ad2bf34 name : Datastore_02

This is the new domain that failed, since the master was not 100% up/initialized, but does NOT appear in the UI of course. When I try to remove it..

[oVirt shell (connected)]# remove storagedomain Datastore_02 =========================================================================== ERROR ======================================================================== status: 400 reason: Bad Request detail: ==========================================================================================================================================================

Not sure why this error results. So looked for a connection? Was surprised to find one, given nothing in the UI...

]# 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 =========================================================================== ERROR ======================================================================== status: 409 reason: Conflict detail: Cannot remove Storage Connection. Storage connection parameters are used by the following storage domains : Datastore_02. ==========================================================================================================================================================

This is really a nasty catch 22? I can't delete the storage domain, because there is a storage connection active? But I can't delete the connection because the storage domain exists? Any suggestions how resolve this?

Thanks

On 08/07/2017 19:48, Schorschi . wrote:

...

Domain name in use? After failed domain setup?

I attempted to create a new domain, but I did not realize the master domain was 100% initialized. The new domain creation failed. But it appears the new domain 'name' was used. Now I cannot create the new domain as expected. I get UI error that states, "" which can only be true if the domain name is in the database, because it is definitely no visible in the UI. This is quite frustrated, because it appears the new domain 'creation' logic is broken, if the new domain fails to be created, the database should not have junk domain name, right? I call this an ugly bug. That said, I really need to remove this junk domain name so I can use the correct name as expected.

Thanks.