Re: [ovirt-users] ISO_DOMAIN issue
I have to guess now, maybe someone else from the devs knows more, maybe there is still an active storage connection somehow? can you check that? Docs on how to do so, are here: http://www.ovirt.org/Features/Manage_Storage_Connections Am 24.06.2014 11:27, schrieb Koen Vanoppen:
Ok, thanx. I manually went through all the VM's-->edit--> unchecked "attach cd"-->ok But he keeps giving the error. Do I need to restart something or... Is there a way to see why the error keeps coming?
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
Database info: engine=# select * from storage_server_connections; id | connection | user_name | password | iqn | port | portal | storage_type | mount_options | vfs_type | nfs_version | nfs_timeo | nfs_retrans --------------------------------------+----------------------------------------------------+-----------+----------+-----+------+--------+--------------+---------------+----------+-------------+-----------+------------- 732405ec-6c3e-45ac-aeac-c9fbedf3c983 | saturnus1.brusselsairport.aero:/media/NFSSaturns | | | | | | 1 | | | | | f7458694-1d03-45ed-87ca-9f2cf72deaa3 | saturnus1.brusselsairport.aero:/media/NfsSaturnus | | | | | | 1 | | | | | fd7c4d90-5bbe-41b1-b294-84e8269dd8c6 | saturnus1.brusselsairport.aero:/media/NfsSaturnus1 | | | | | | 1 | | | | | ee1e3e5f-28ae-45cc-a13c-e77244f08c83 | buran:/root/NfsStorageBuran | | | | | | 1 | | | | | fca163d6-6bf7-488b-bc63-896cd126eb7a | buran.brusselsairport.aero:/root/NfsStorageBuran | | | | | | 1 | | | | | 4dd8434c-e63d-48c4-9e46-68391bcbdae2 | buran.brusselsairport.aero:/NfsExportOvirt | | | | | | 1 | | | | | 341d9f52-aa4c-42ab-92d3-c67a8e8847b5 | buran.brusselsairport.aero://NfsExportOvirt | | | | | | 1 | | | | | 88c4573f-819c-4573-b1c0-3d40b5ec081a | buran.brusselsairport.aero:/ExportStorageDomain | | | | | | 1 | | | | | bbaab55d-3859-4a6d-86c0-9f8465f4e78e | buran.brusselsairport.aero:/ExportDomainBuran | | | | | | 1 | | | | | 5caf2b82-ad4d-418f-871f-c5187fb805c2 | progress.brusselsairport.aero:/media/NfsProgress | | | | | | 1 | | | | | 91fca941-d9f3-496c-908f-92d31bce6a64 | progress.brusselsairport.aero:/media/ISO_DOMAIN | | | | | 1 | 1 | | | | | (11 rows) engine=# select storage from storage_domain_static; storage ---------------------------------------- xnxCbi-Dbj2-MMpq-vYcG-MJU7-WRYG-AmhiXb I6Tx7M-CgPq-A23s-ixpk-vNTr-A6Nk-0RO9RA pKWBtU-KmYS-ZS6S-3Wtu-g1e9-rPtn-wgnflj KD01Sk-exBV-0dG9-bFzx-m5YP-vH3f-ykwpBn U7CpHl-YdQ2-v2QL-lyXS-Ta3l-QAXJ-sdFsII N7wm36-uh0L-kvee-vfuH-wdLF-TikC-bAdfZi fd7c4d90-5bbe-41b1-b294-84e8269dd8c6 ppuvqb-zjKr-9un0-JQK8-Wbha-LuRY-8ORbKS 5caf2b82-ad4d-418f-871f-c5187fb805c2 ceab03af-7220-4d42-8f5c-9b557f5d29af 7ZqEl9-14by-Rpms-prrd-FjGc-jG3Q-d1Z3Qt Q9H2ty-CQyd-D6Is-XnnZ-nnTh-6NkW-ndxlG2 ddAOPb-Je1e-HaKU-tu3T-eJTQ-Bxnb-3bozGg (13 rows) [oVirt shell (connected@vega. brusselsairport)]# list storageconnections id : 732405ec-6c3e-45ac-aeac-c9fbedf3c983 id : f7458694-1d03-45ed-87ca-9f2cf72deaa3 id : fd7c4d90-5bbe-41b1-b294-84e8269dd8c6 id : ee1e3e5f-28ae-45cc-a13c-e77244f08c83 id : fca163d6-6bf7-488b-bc63-896cd126eb7a id : 4dd8434c-e63d-48c4-9e46-68391bcbdae2 id : 341d9f52-aa4c-42ab-92d3-c67a8e8847b5 id : 88c4573f-819c-4573-b1c0-3d40b5ec081a id : bbaab55d-3859-4a6d-86c0-9f8465f4e78e id : 5caf2b82-ad4d-418f-871f-c5187fb805c2 id : 91fca941-d9f3-496c-908f-92d31bce6a64 I'm lost... 2014-06-24 11:39 GMT+02:00 Sven Kieske <S.Kieske@mittwald.de>:
I have to guess now, maybe someone else from the devs knows more, maybe there is still an active storage connection somehow? can you check that? Docs on how to do so, are here: http://www.ovirt.org/Features/Manage_Storage_Connections
Am 24.06.2014 11:27, schrieb Koen Vanoppen:
Ok, thanx. I manually went through all the VM's-->edit--> unchecked "attach cd"-->ok But he keeps giving the error. Do I need to restart something or... Is there a way to see why the error keeps coming?
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
Well, to my understanding there is still an active storage connection to this non existent iso domain: 91fca941-d9f3-496c-908f-92d31bce6a64 maybe this can be deleted, and the error disappears but I would really check with someone from redhat before doing this, because I'm really not sure if this is a good idea on a production machine. Another question: how did you remove the iso domain in ovirt? Am 24.06.2014 13:48, schrieb Koen Vanoppen:
Database info: engine=# select * from storage_server_connections; id | connection | user_name | password | iqn | port | portal | storage_type | mount_options | vfs_type | nfs_version | nfs_timeo | nfs_retrans --------------------------------------+----------------------------------------------------+-----------+----------+-----+------+--------+--------------+---------------+----------+-------------+-----------+------------- 732405ec-6c3e-45ac-aeac-c9fbedf3c983 | saturnus1.brusselsairport.aero:/media/NFSSaturns | | | | | | 1 | | | | | f7458694-1d03-45ed-87ca-9f2cf72deaa3 | saturnus1.brusselsairport.aero:/media/NfsSaturnus | | | | | | 1 | | | | | fd7c4d90-5bbe-41b1-b294-84e8269dd8c6 | saturnus1.brusselsairport.aero:/media/NfsSaturnus1 | | | | | | 1 | | | | | ee1e3e5f-28ae-45cc-a13c-e77244f08c83 | buran:/root/NfsStorageBuran | | | | | | 1 | | | | | fca163d6-6bf7-488b-bc63-896cd126eb7a | buran.brusselsairport.aero:/root/NfsStorageBuran | | | | | | 1 | | | | | 4dd8434c-e63d-48c4-9e46-68391bcbdae2 | buran.brusselsairport.aero:/NfsExportOvirt | | | | | | 1 | | | | | 341d9f52-aa4c-42ab-92d3-c67a8e8847b5 | buran.brusselsairport.aero://NfsExportOvirt | | | | | | 1 | | | | | 88c4573f-819c-4573-b1c0-3d40b5ec081a | buran.brusselsairport.aero:/ExportStorageDomain | | | | | | 1 | | | | | bbaab55d-3859-4a6d-86c0-9f8465f4e78e | buran.brusselsairport.aero:/ExportDomainBuran | | | | | | 1 | | | | | 5caf2b82-ad4d-418f-871f-c5187fb805c2 | progress.brusselsairport.aero:/media/NfsProgress | | | | | | 1 | | | | | 91fca941-d9f3-496c-908f-92d31bce6a64 | progress.brusselsairport.aero:/media/ISO_DOMAIN | | | | | 1 | 1 | | | | | (11 rows)
engine=# select storage from storage_domain_static; storage ---------------------------------------- xnxCbi-Dbj2-MMpq-vYcG-MJU7-WRYG-AmhiXb I6Tx7M-CgPq-A23s-ixpk-vNTr-A6Nk-0RO9RA pKWBtU-KmYS-ZS6S-3Wtu-g1e9-rPtn-wgnflj KD01Sk-exBV-0dG9-bFzx-m5YP-vH3f-ykwpBn U7CpHl-YdQ2-v2QL-lyXS-Ta3l-QAXJ-sdFsII N7wm36-uh0L-kvee-vfuH-wdLF-TikC-bAdfZi fd7c4d90-5bbe-41b1-b294-84e8269dd8c6 ppuvqb-zjKr-9un0-JQK8-Wbha-LuRY-8ORbKS 5caf2b82-ad4d-418f-871f-c5187fb805c2 ceab03af-7220-4d42-8f5c-9b557f5d29af 7ZqEl9-14by-Rpms-prrd-FjGc-jG3Q-d1Z3Qt Q9H2ty-CQyd-D6Is-XnnZ-nnTh-6NkW-ndxlG2 ddAOPb-Je1e-HaKU-tu3T-eJTQ-Bxnb-3bozGg (13 rows)
[oVirt shell (connected@vega. brusselsairport)]# list storageconnections
id : 732405ec-6c3e-45ac-aeac-c9fbedf3c983
id : f7458694-1d03-45ed-87ca-9f2cf72deaa3
id : fd7c4d90-5bbe-41b1-b294-84e8269dd8c6
id : ee1e3e5f-28ae-45cc-a13c-e77244f08c83
id : fca163d6-6bf7-488b-bc63-896cd126eb7a
id : 4dd8434c-e63d-48c4-9e46-68391bcbdae2
id : 341d9f52-aa4c-42ab-92d3-c67a8e8847b5
id : 88c4573f-819c-4573-b1c0-3d40b5ec081a
id : bbaab55d-3859-4a6d-86c0-9f8465f4e78e
id : 5caf2b82-ad4d-418f-871f-c5187fb805c2
id : 91fca941-d9f3-496c-908f-92d31bce6a64
I'm lost...
2014-06-24 11:39 GMT+02:00 Sven Kieske <S.Kieske@mittwald.de>:
I have to guess now, maybe someone else from the devs knows more, maybe there is still an active storage connection somehow? can you check that? Docs on how to do so, are here: http://www.ovirt.org/Features/Manage_Storage_Connections
Am 24.06.2014 11:27, schrieb Koen Vanoppen:
Ok, thanx. I manually went through all the VM's-->edit--> unchecked "attach cd"-->ok But he keeps giving the error. Do I need to restart something or... Is there a way to see why the error keeps coming?
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
By "destroying" it in ovirt management interface... 2014-06-24 14:03 GMT+02:00 Sven Kieske <S.Kieske@mittwald.de>:
Well, to my understanding there is still an active storage connection to this non existent iso domain: 91fca941-d9f3-496c-908f-92d31bce6a64
maybe this can be deleted, and the error disappears but I would really check with someone from redhat before doing this, because I'm really not sure if this is a good idea on a production machine.
Another question: how did you remove the iso domain in ovirt?
Database info: engine=# select * from storage_server_connections; id | connection | user_name | password | iqn | port |
Am 24.06.2014 13:48, schrieb Koen Vanoppen: portal
| storage_type | mount_options | vfs_type | nfs_version | nfs_timeo | nfs_retrans
--------------------------------------+----------------------------------------------------+-----------+----------+-----+------+--------+--------------+---------------+----------+-------------+-----------+-------------
732405ec-6c3e-45ac-aeac-c9fbedf3c983 | saturnus1.brusselsairport.aero:/media/NFSSaturns | | | | | | 1 | | | | | f7458694-1d03-45ed-87ca-9f2cf72deaa3 | saturnus1.brusselsairport.aero:/media/NfsSaturnus | | | | | | 1 | | | | | fd7c4d90-5bbe-41b1-b294-84e8269dd8c6 | saturnus1.brusselsairport.aero:/media/NfsSaturnus1 | | | | | | 1 | | | | | ee1e3e5f-28ae-45cc-a13c-e77244f08c83 | buran:/root/NfsStorageBuran | | | | | | 1 | | | | | fca163d6-6bf7-488b-bc63-896cd126eb7a | buran.brusselsairport.aero:/root/NfsStorageBuran | | | | | | 1 | | | | | 4dd8434c-e63d-48c4-9e46-68391bcbdae2 | buran.brusselsairport.aero:/NfsExportOvirt | | | | | | 1 | | | | | 341d9f52-aa4c-42ab-92d3-c67a8e8847b5 | buran.brusselsairport.aero://NfsExportOvirt | | | | | | 1 | | | | | 88c4573f-819c-4573-b1c0-3d40b5ec081a | buran.brusselsairport.aero:/ExportStorageDomain | | | | | | 1 | | | | | bbaab55d-3859-4a6d-86c0-9f8465f4e78e | buran.brusselsairport.aero:/ExportDomainBuran | | | | | | 1 | | | | | 5caf2b82-ad4d-418f-871f-c5187fb805c2 | progress.brusselsairport.aero:/media/NfsProgress | | | | | | 1 | | | | | 91fca941-d9f3-496c-908f-92d31bce6a64 | progress.brusselsairport.aero:/media/ISO_DOMAIN | | | | | 1 | 1 | | | | | (11 rows)
engine=# select storage from storage_domain_static; storage ---------------------------------------- xnxCbi-Dbj2-MMpq-vYcG-MJU7-WRYG-AmhiXb I6Tx7M-CgPq-A23s-ixpk-vNTr-A6Nk-0RO9RA pKWBtU-KmYS-ZS6S-3Wtu-g1e9-rPtn-wgnflj KD01Sk-exBV-0dG9-bFzx-m5YP-vH3f-ykwpBn U7CpHl-YdQ2-v2QL-lyXS-Ta3l-QAXJ-sdFsII N7wm36-uh0L-kvee-vfuH-wdLF-TikC-bAdfZi fd7c4d90-5bbe-41b1-b294-84e8269dd8c6 ppuvqb-zjKr-9un0-JQK8-Wbha-LuRY-8ORbKS 5caf2b82-ad4d-418f-871f-c5187fb805c2 ceab03af-7220-4d42-8f5c-9b557f5d29af 7ZqEl9-14by-Rpms-prrd-FjGc-jG3Q-d1Z3Qt Q9H2ty-CQyd-D6Is-XnnZ-nnTh-6NkW-ndxlG2 ddAOPb-Je1e-HaKU-tu3T-eJTQ-Bxnb-3bozGg (13 rows)
[oVirt shell (connected@vega. brusselsairport)]# list storageconnections
id : 732405ec-6c3e-45ac-aeac-c9fbedf3c983
id : f7458694-1d03-45ed-87ca-9f2cf72deaa3
id : fd7c4d90-5bbe-41b1-b294-84e8269dd8c6
id : ee1e3e5f-28ae-45cc-a13c-e77244f08c83
id : fca163d6-6bf7-488b-bc63-896cd126eb7a
id : 4dd8434c-e63d-48c4-9e46-68391bcbdae2
id : 341d9f52-aa4c-42ab-92d3-c67a8e8847b5
id : 88c4573f-819c-4573-b1c0-3d40b5ec081a
id : bbaab55d-3859-4a6d-86c0-9f8465f4e78e
id : 5caf2b82-ad4d-418f-871f-c5187fb805c2
id : 91fca941-d9f3-496c-908f-92d31bce6a64
I'm lost...
2014-06-24 11:39 GMT+02:00 Sven Kieske <S.Kieske@mittwald.de>:
I have to guess now, maybe someone else from the devs knows more, maybe there is still an active storage connection somehow? can you check that? Docs on how to do so, are here: http://www.ovirt.org/Features/Manage_Storage_Connections
Am 24.06.2014 11:27, schrieb Koen Vanoppen:
Ok, thanx. I manually went through all the VM's-->edit--> unchecked "attach cd"-->ok But he keeps giving the error. Do I need to restart something or... Is there a way to see why the error keeps coming?
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
-- Mit freundlichen Grüßen / Regards
Sven Kieske
Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
well as far as I know you should put any domain first into maintenance, then detach from all DCs and then remove it. by force destroying you get what you now have: old connections which are dead and log spam. So I assume it would be safe to delete the connection to this storage domain, but ymmv. Am 24.06.2014 14:45, schrieb Koen Vanoppen:
By "destroying" it in ovirt management interface...
-- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
the destroy should clean the db only and any cleanup on the storage/hosts side should be done manually by the user. cleaning the iso domain from the vms would be a nice addition if not done today - can you please open a bug on this? Please check if your hosts have old mount to the iso side and umount it. restart of vdsm service on the hosts and engine service should clean any leftovers after that. if not, please file a bug since old connection should be clean from the db. Dafna On 06/24/2014 01:53 PM, Sven Kieske wrote:
well as far as I know you should put any domain first into maintenance, then detach from all DCs and then remove it.
by force destroying you get what you now have: old connections which are dead and log spam.
So I assume it would be safe to delete the connection to this storage domain, but ymmv.
Am 24.06.2014 14:45, schrieb Koen Vanoppen:
By "destroying" it in ovirt management interface...
-- Dafna Ron
Ok, thanx. Now when I try to remove the connection I get this: [oVirt shell (connected@vega.brusselsairport.aero)]# remove storageconnection 91fca941-d9f3-496c-908f- 92d31bce6a64 ====================================================== ERROR =================================================== status: 404 reason: Not Found detail: Entity not found: null ================================================================================================================ 2014-06-24 15:53 GMT+02:00 Dafna Ron <dron@redhat.com>:
the destroy should clean the db only and any cleanup on the storage/hosts side should be done manually by the user. cleaning the iso domain from the vms would be a nice addition if not done today - can you please open a bug on this?
Please check if your hosts have old mount to the iso side and umount it. restart of vdsm service on the hosts and engine service should clean any leftovers after that. if not, please file a bug since old connection should be clean from the db.
Dafna
On 06/24/2014 01:53 PM, Sven Kieske wrote:
well as far as I know you should put any domain first into maintenance, then detach from all DCs and then remove it.
by force destroying you get what you now have: old connections which are dead and log spam.
So I assume it would be safe to delete the connection to this storage domain, but ymmv.
Am 24.06.2014 14:45, schrieb Koen Vanoppen:
By "destroying" it in ovirt management interface...
-- Dafna Ron
<storage_connection href="/api/storageconnections/91fca941-d9f3-496c-908f-92d31bce6a64" id="91fca941-d9f3-496c-908f-92d31bce6a64"><address> progress.brusselsairport.aero </address><type>nfs</type><path>/media/ISO_DOMAIN</path></storage_connection> ?????? 2014-06-25 6:54 GMT+02:00 Koen Vanoppen <vanoppen.koen@gmail.com>:
Ok, thanx. Now when I try to remove the connection I get this:
[oVirt shell (connected@vega.brusselsairport.aero)]# remove storageconnection 91fca941-d9f3-496c-908f- 92d31bce6a64 ====================================================== ERROR =================================================== status: 404 reason: Not Found detail: Entity not found: null
================================================================================================================
2014-06-24 15:53 GMT+02:00 Dafna Ron <dron@redhat.com>:
the destroy should clean the db only and any cleanup on the storage/hosts side should be done manually by the user.
cleaning the iso domain from the vms would be a nice addition if not done today - can you please open a bug on this?
Please check if your hosts have old mount to the iso side and umount it. restart of vdsm service on the hosts and engine service should clean any leftovers after that. if not, please file a bug since old connection should be clean from the db.
Dafna
On 06/24/2014 01:53 PM, Sven Kieske wrote:
well as far as I know you should put any domain first into maintenance, then detach from all DCs and then remove it.
by force destroying you get what you now have: old connections which are dead and log spam.
So I assume it would be safe to delete the connection to this storage domain, but ymmv.
Am 24.06.2014 14:45, schrieb Koen Vanoppen:
By "destroying" it in ovirt management interface...
-- Dafna Ron
Am 25.06.2014 06:54, schrieb Koen Vanoppen:
Ok, thanx. Now when I try to remove the connection I get this:
[oVirt shell (connected@vega.brusselsairport.aero)]# remove storageconnection 91fca941-d9f3-496c-908f- 92d31bce6a64 ====================================================== ERROR =================================================== status: 404 reason: Not Found detail: Entity not found: null
which ovirt and which ovirt shell version are you running? the deletion of storage connections was one of the last features to be completed for the management of storage connection and there where some bugs regarding the returned status codes. I can't remember the exact version where it worked but with ovirt 3.4. you should be save (should also work in latest 3.3.z, but ymmv). -- Mit freundlichen Grüßen / Regards Sven Kieske Systemadministrator Mittwald CM Service GmbH & Co. KG Königsberger Straße 6 32339 Espelkamp T: +49-5772-293-100 F: +49-5772-293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
What do you have in the host under /rhev/data-center/ ? ----- Original Message -----
From: "Koen Vanoppen" <vanoppen.koen@gmail.com> To: dron@redhat.com Cc: users@ovirt.org Sent: Wednesday, June 25, 2014 7:54:21 AM Subject: Re: [ovirt-users] ISO_DOMAIN issue
Ok, thanx. Now when I try to remove the connection I get this:
[oVirt shell ( connected@vega.brusselsairport.aero )]# remove storageconnection 91fca941-d9f3-496c-908f- 92d31bce6a64 ====================================================== ERROR =================================================== status: 404 reason: Not Found detail: Entity not found: null ================================================================================================================
2014-06-24 15:53 GMT+02:00 Dafna Ron < dron@redhat.com > :
the destroy should clean the db only and any cleanup on the storage/hosts side should be done manually by the user. cleaning the iso domain from the vms would be a nice addition if not done today - can you please open a bug on this?
Please check if your hosts have old mount to the iso side and umount it. restart of vdsm service on the hosts and engine service should clean any leftovers after that. if not, please file a bug since old connection should be clean from the db.
Dafna
On 06/24/2014 01:53 PM, Sven Kieske wrote:
well as far as I know you should put any domain first into maintenance, then detach from all DCs and then remove it.
by force destroying you get what you now have: old connections which are dead and log spam.
So I assume it would be safe to delete the connection to this storage domain, but ymmv.
Am 24.06.2014 14 :45, schrieb Koen Vanoppen:
By "destroying" it in ovirt management interface...
-- Dafna Ron
_______________________________________________ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
participants (4)
-
Dafna Ron -
Koen Vanoppen -
Sven Kieske -
Vered Volansky