Hi !
I finally solved my problem by removing information related to broken storage
in the engine database.
I post below the sql queries I executed in postgres (with engine stopped while
executing them) in order to remove storage domain. Maybe it can be useful for
somebody else in the same situation.
Connect to database
# su - postgres
# psql engine
identify broken storage
engine=# select id, storage_name from storage_domain_static;
id | storage_name
--+
34c95a44-db7f-4d0f-ba13-5f06a7feefe7 | my-broken-storage-domain
identify ovf disks on this storage
engine=# select storage_domain_id, ovf_disk_id from storage_domains_ovf_info
where storage_domain_id = '34c95a44-db7f-4d0f-ba13-5f06a7feefe7';
storage_domain_id | ovf_disk_id
--+--
34c95a44-db7f-4d0f-ba13-5f06a7feefe7 | 033f8fba-5145-47e8-b3b5-32a34a39ad11
34c95a44-db7f-4d0f-ba13-5f06a7feefe7 | 2d9a6a40-1dd0-4180-b7c7-3829a443c825
engine=# delete from storage_domain_dynamic where id =
'34c95a44-db7f-4d0f-ba13-5f06a7feefe7';
engine=# delete from storage_domain_static where id =
'34c95a44-db7f-4d0f-ba13-5f06a7feefe7';
engine=# delete from base_disks where disk_id =
'033f8fba-5145-47e8-b3b5-32a34a39ad11';
engine=# delete from base_disks where disk_id =
'2d9a6a40-1dd0-4180-b7c7-3829a443c825';
engine=# delete from storage_domains_ovf_info where storage_domain_id =
'34c95a44-db7f-4d0f-ba13-5f06a7feefe7';
engine=# delete from storage_pool_iso_map where storage_id =
'34c95a44-db7f-4d0f-ba13-5f06a7feefe7';
identify and delete luns and connections related to storage (i did not take
notes of results of these ones, but it was easy to find the good lines). Also,
i noticed that lun_storage_server_connection_map only contained information
about iscsi storage, not fiber channel.
engine=# select * from luns;
engine=# delete from luns where physical_volume_id =
'IqOdm6-BWuT-9YBW-uvM1-q41E-a3Cz-zPnWHq';
engine=# delete from lun_storage_server_connection_map where
storage_server_connection='1b9f3167-3236-431e-93c2-ab5ee18eba04';
engine=# delete from lun_storage_server_connection_map where
storage_server_connection='ea5971f8-e1a0-42e3-826d-b95e9031ce53';
engine=# delete from storage_server_connections where
id='1b9f3167-3236-431e-93c2-ab5ee18eba04';
engine=# delete from storage_server_connections where
id='ea5971f8-e1a0-42e3-826d-b95e9031ce53';
delete remaining disk(s) ; I had 1 virtual disk on this storage
engine=# delete from base_disks where
disk_id='03d651eb-14a9-4dca-8c87-605f101a5e0c';
engine=# delete from permissions where
object_id='03d651eb-14a9-4dca-8c87-605f101a5e0c';
Then started engine and all is fine now.
- Mail original -----
> De: "Amit Aviram"
> À: "Olivier Navas"
> Envoyé: Mardi 6 Janvier 2015 17:24:19
> Objet: Re: [ovirt-users] Can't remove a storage domain related to a broken
> hardware
>
>
>
> ----- Original Message -----
> From: "Olivier Navas"
> Hi, can you please add the engine log?
>
> To: users@ovirt.org
> Sent: Tuesday, January 6, 2015 11:28:42 AM
> Subject: [ovirt-users] Can't remove a storage domain related to a broken
> hardware
>
>
> Hello Ovirt users !
>
> I experienced an hardware failure on a ISCSI storage making it unrecoverable,
> and I would like to remove it from storage domains.
>
> There was 1 disk on this storage domain, and this disk isn't attached to any
> VM anymore, but I still can't detach this storage domain from cluster.
>
> The storage domain is in "inactive" status and if I try to "detach" it from
> data center, ovirt tries to activate it. Obviously it can't activate it
> since hardware is broken, and it fails after several minutes with the event
> "Failed to detach Storage Domain my_storage_domain to Data Center Default.
> (User: admin)". I can post my engine.log if useful.
>
> I need a way to force removal of this storage domain. Any trick would be
> greatly appreciated.
>
> Perhaps does Ovirt miss some sort of "force detach, i know what i'm doing"
> button ?
>
> I am running an Ovirt 3.5 cluster (engine with CentOS 6.6, 4 nodes with
> CentOS 7) with FC and ISCSI storage domains.
>
> Thanks for your help.
>
>
>
>
> Ce courriel et tous les fichiers attachés qu'il contient sont confidentiels
> et destinés exclusivement à la personne à laquelle ils sont adressés. Si
> vous avez reçu ce courriel par erreur, merci de le retourner à s
