Re: [ovirt-users] ISO_DOMAIN issue
What do you have in the host under /rhev/data-center/ ? - Original Message - From: Koen Vanoppen vanoppen.k...@gmail.com To: d...@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 ( connec...@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 d...@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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] ISO_DOMAIN issue
did you restart ovirt-engine service? On 06/25/2014 05:54 AM, Koen Vanoppen wrote: Ok, thanx. Now when I try to remove the connection I get this: [oVirt shell (connec...@vega.brusselsairport.aero mailto:connec...@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 d...@redhat.com mailto:d...@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 tel:24.06.2014%2014:45, schrieb Koen Vanoppen: By destroying it in ovirt management interface... -- Dafna Ron -- Dafna Ron ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] ISO_DOMAIN issue
Am 25.06.2014 06:54, schrieb Koen Vanoppen: Ok, thanx. Now when I try to remove the connection I get this: [oVirt shell (connec...@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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] ISO_DOMAIN issue
Am 24.06.2014 10:27, schrieb Koen Vanoppen: Hi all, We have a small problem with a recently removed iso_domain. The domain ahs been removed in the ovirt but in the vdsm he keeps complaining about this Did you make sure there are no vms running with attached isos from this domain? -- 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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] ISO_DOMAIN issue
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.kie...@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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] ISO_DOMAIN issue
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.kie...@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
Re: [ovirt-users] ISO_DOMAIN issue
By destroying it in ovirt management interface... 2014-06-24 14:03 GMT+02:00 Sven Kieske s.kie...@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? 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.kie...@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
Re: [ovirt-users] ISO_DOMAIN issue
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 ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] ISO_DOMAIN issue
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
Re: [ovirt-users] ISO_DOMAIN issue
Ok, thanx. Now when I try to remove the connection I get this: [oVirt shell (connec...@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 d...@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
Re: [ovirt-users] ISO_DOMAIN issue
storage_connection href=/api/storageconnections/91fca941-d9f3-496c-908f-92d31bce6a64 id=91fca941-d9f3-496c-908f-92d31bce6a64address progress.brusselsairport.aero /addresstypenfs/typepath/media/ISO_DOMAIN/path/storage_connection ?? 2014-06-25 6:54 GMT+02:00 Koen Vanoppen vanoppen.k...@gmail.com: Ok, thanx. Now when I try to remove the connection I get this: [oVirt shell (connec...@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 d...@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
