Re: [ovirt-users] ISO_DOMAIN issue

2014-06-29 Thread Vered Volansky 
What do you have in the host under /rhev/data-center/ ?

- Original Message -
> From: "Koen Vanoppen" 
> 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

2014-06-27 Thread Dafna Ron 

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 
)]# 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 >:


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






--
Dafna Ron
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] ISO_DOMAIN issue

2014-06-25 Thread Sven Kieske 


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

2014-06-24 Thread Koen Vanoppen 

progress.brusselsairport.aero
nfs/media/ISO_DOMAIN

??


2014-06-25 6:54 GMT+02:00 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
>
> 
>
>
> 2014-06-24 15:53 GMT+02:00 Dafna Ron :
>
>> 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

2014-06-24 Thread 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




2014-06-24 15:53 GMT+02:00 Dafna Ron :

> 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

2014-06-24 Thread Dafna Ron 
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

2014-06-24 Thread Sven Kieske 
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

2014-06-24 Thread Koen Vanoppen 
By "destroying" it in ovirt management interface...


2014-06-24 14:03 GMT+02:00 Sven Kieske :

> 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 :
> >
> >> I have to guess now, maybe someone else from the devs

Re: [ovirt-users] ISO_DOMAIN issue

2014-06-24 Thread Sven Kieske 
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 :
> 
>> 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
>

Re: [ovirt-users] ISO_DOMAIN issue

2014-06-24 Thread 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 :

> 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

2014-06-24 Thread Sven Kieske 
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

2014-06-24 Thread Sven Kieske 


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

[ovirt-users] ISO_DOMAIN issue

2014-06-24 Thread 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:

Thread-2362176::WARNING::2014-06-24
10:24:34,803::fileSD::636::scanDomains::(collectMetaFiles) Metadata
collection for domain path
/rhev/data-center/mnt/vega.brusselsairport.aero:_var_lib_exports_iso
timedout
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/fileSD.py", line 625, in collectMetaFiles
sd.DOMAIN_META_DATA))
  File "/usr/share/vdsm/storage/remoteFileHandler.py", line 297, in
callCrabRPCFunction
*args, **kwargs)
  File "/usr/share/vdsm/storage/remoteFileHandler.py", line 184, in
callCrabRPCFunction
rawLength = self._recvAll(LENGTH_STRUCT_LENGTH, timeout)
  File "/usr/share/vdsm/storage/remoteFileHandler.py", line 150, in _recvAll
raise Timeout()
Timeout
Thread-23::ERROR::2014-06-24
10:24:34,804::sdc::143::Storage.StorageDomainCache::(_findDomain) domain
50cf24a4-d1ef-4105-a9a5-b81d91339175 not found
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/sdc.py", line 141, in _findDomain
dom = findMethod(sdUUID)
  File "/usr/share/vdsm/storage/nfsSD.py", line 132, in findDomain
return NfsStorageDomain(NfsStorageDomain.findDomainPath(sdUUID))
  File "/usr/share/vdsm/storage/nfsSD.py", line 122, in findDomainPath
raise se.StorageDomainDoesNotExist(sdUUID)
StorageDomainDoesNotExist: Storage domain does not exist:
(u'50cf24a4-d1ef-4105-a9a5-b81d91339175',)
Thread-23::ERROR::2014-06-24
10:24:34,805::domainMonitor::225::Storage.DomainMonitorThread::(_monitorDomain)
Error while collecting domain 50cf24a4-d1ef-4105-a9a5-b81d91339175
monitoring information
Traceback (most recent call last):
  File "/usr/share/vdsm/storage/domainMonitor.py", line 201, in
_monitorDomain
self.domain.selftest()
  File "/usr/share/vdsm/storage/sdc.py", line 49, in __getattr__
return getattr(self.getRealDomain(), attrName)
  File "/usr/share/vdsm/storage/sdc.py", line 52, in getRealDomain
return self._cache._realProduce(self._sdUUID)
  File "/usr/share/vdsm/storage/sdc.py", line 122, in _realProduce
domain = self._findDomain(sdUUID)
  File "/usr/share/vdsm/storage/sdc.py", line 141, in _findDomain
dom = findMethod(sdUUID)
  File "/usr/share/vdsm/storage/nfsSD.py", line 132, in findDomain
return NfsStorageDomain(NfsStorageDomain.findDomainPath(sdUUID))
  File "/usr/share/vdsm/storage/nfsSD.py", line 122, in findDomainPath
raise se.StorageDomainDoesNotExist(sdUUID)
StorageDomainDoesNotExist: Storage domain does not exist:
(u'50cf24a4-d1ef-4105-a9a5-b81d91339175',)

How can I remove this completely?

Kind regards,

Koen
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users