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
