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(a)mittwald.de&gt;: > >> 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...

Ok, thanx. Now when I try to remove the connection I get this: [oVirt shell (connected(a)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(a)redhat.com&gt;: > 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 >

From: "Koen Vanoppen" <vanoppen.koen(a)gmail.com&gt; To: dron(a)redhat.com Cc: users(a)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(a)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(a)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(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/users