[ovirt-users] Re: Problem with snapshots in illegal status
teDiskFinishVDSCommand]
(EE-ManagedThreadFactory-engineScheduled-Thread-9)
[f24bee33-3e0d-4726-a9f0-9ee1c4caf063] FINISH,
VmReplicateDiskFinishVDSCommand, log id: 36f598e9
2019-02-25 11:58:56,131+01 ERROR
[org.ovirt.engine.core.bll.storage.lsm.LiveMigrateDiskCommand]
(EE-ManagedThreadFactory-engineScheduled-Thread-9)
[f24bee33-3e0d-4726-a9f0-9ee1c4caf063] Replication end of disk
'0d9b635d-22ef-4456-9b10-20be027baa7a' in vm
'0e7e53c6-ad15-484a-b084-4647b50a2567' back to the source failed, skipping
deletion of the target disk
2019-02-25 11:58:56,142+01 WARN
[org.ovirt.engine.core.bll.lock.InMemoryLockManager]
(EE-ManagedThreadFactory-engineScheduled-Thread-9)
[f24bee33-3e0d-4726-a9f0-9ee1c4caf063] Trying to release exclusive lock
which does not exist, lock key:
'0e7e53c6-ad15-484a-b084-4647b50a2567LIVE_STORAGE_MIGRATION'
2019-02-25 11:58:56,142+01 INFO
[org.ovirt.engine.core.bll.storage.lsm.LiveMigrateDiskCommand]
(EE-ManagedThreadFactory-engineScheduled-Thread-9)
[f24bee33-3e0d-4726-a9f0-9ee1c4caf063] Lock freed to object
'EngineLock:{exclusiveLocks='[0e7e53c6-ad15-484a-b084-4647b50a2567=LIVE_STORAGE_MIGRATION]',
sharedLocks=''}'
2019-02-25 11:58:56,176+01 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedThreadFactory-engineScheduled-Thread-9)
[f24bee33-3e0d-4726-a9f0-9ee1c4caf063] EVENT_ID:
USER_MOVED_DISK_FINISHED_FAILURE(2,011), User admin@internal-authz have
failed to move disk vm.example.com_Disk1 to domain PreproductionStorage01.
2019-02-25 11:59:33,685+01 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedThreadFactory-engine-Thread-23)
[b257b938-4a81-4c21-a53e-e346510d9430] EVENT_ID:
USER_REMOVE_DISK_SNAPSHOT(373), Disk 'vm.example.com_Disk1' from
Snapshot(s) 'backup_snapshot_20190217-010004' of VM 'vm.example.com'
deletion was initiated by admin@internal-authz.
2019-02-25 12:00:07,063+01 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedThreadFactory-engineScheduled-Thread-20)
[b257b938-4a81-4c21-a53e-e346510d9430] EVENT_ID:
USER_REMOVE_DISK_SNAPSHOT_FINISHED_SUCCESS(375), Disk
'vm.example.com_Disk1' from Snapshot(s) 'backup_snapshot_20190217-010004'
of VM 'vm.example.com' deletion has been completed (User:
admin@internal-authz).
You have new mail in /var/spool/mail/root
On Mon, Feb 25, 2019 at 11:52 AM Bruno Rodriguez wrote:
> Thank you very much, Shani
>
> I've got what you asked and some good news as well. I'll start with the
> good news: the snapshots status changes to OK if I try to live-migrate the
> disk to another storage domain in the same cabin. Then I can delete them.
> Just tried with two illegal snapshots and it worked, I'll send you the
> engine logs as soon as I can check them.
>
> If I go with the query to the database (the following one) I get 0 rows
>
> # select * from images where vm_snapshot_id IN
> ('f649d9c1-563e-49d4-9fad-6bc94abc279b',
> '5734df23-de67-41a8-88a1-423cecfe7260',
> 'f649d9c1-563e-49d4-9fad-6bc94abc279b',
> '2929df28-eae8-4f27-afee-a984fe0b07e7',
> '4bd4360e-e0f4-4629-ab38-2f0d80d3ae0f',
> 'fbaff53b-30ce-4b20-8f10-80e70becb48c',
> 'c628386a-da6c-4a0d-ae7d-3e6ecda27d6d',
> 'e9ddaa5c-007d-49e6-8384-efefebb00aa6',
> '5b6db52a-bfe3-45f8-b7bb-d878c4e63cb4',
> '7efe2e7e-ca24-4b27-b512-b42795c79ea4');
>
> BTW, the dump-volume-chains is here. I deleted the disks with no snapshots
> in illegal status
>
> Images volume chains (base volume first)
>
>image:4dab82be-7068-4234-8478-45ec51a29bc0
>
> - 04f7bafd-aa56-4940-9c4e-e4055972284e
>status: OK, voltype: INTERNAL, format: COW, legality:
> LEGAL, type: SPARSE
>
> - 0fe7e3bf-24a9-45b3-9f33-9d93349b2ac1
>status: ILLEGAL, voltype: LEAF, format: COW, legality:
> ILLEGAL, type: SPARSE
>
>
>image:7428f6fd-ae2e-4691-b718-1422b1150798
>
> - a81b454e-17b1-4c6a-a7bc-803a0e3b2b03
>status: ILLEGAL, voltype: LEAF, format: COW, legality:
> ILLEGAL, type: SPARSE
>
>
>image:c111cb15-5465-4056-b0bb-bd94565d6060
>
> - 2443c7f2-9ee3-4a92-a80e-c3ee1a481311
>status: ILLEGAL, voltype: LEAF, format: COW, legality:
> ILLEGAL, type: SPARSE
>
>
>image:2900bc6b-3345-42a4-9533-667fb4009deb
>
> - e9ddaa5c-007d-49e6-8384-efefebb00aa6
>status: OK, voltype: INTERNAL, format: COW, legality:
> LEGAL, type: SPARSE
>
> - 8be46861-3d44-4dd3-9216-a2817f9d0db9
>status: ILLEGAL, voltype: LEAF, format: COW, legality:
> ILLEGAL, type: SPA
[ovirt-users] Re: Problem with snapshots in illegal status
status: OK, voltype: INTERNAL, format: COW, legality: LEGAL,
type: SPARSE
- fa154782-0dbb-45b5-ba62-d6937259f097
status: ILLEGAL, voltype: LEAF, format: COW, legality:
ILLEGAL, type: SPARSE
image:ded89dac-ce57-4c09-8ca5-dd131e0776df
- fbaff53b-30ce-4b20-8f10-80e70becb48c
status: OK, voltype: INTERNAL, format: COW, legality: LEGAL,
type: SPARSE
- 2feae690-0301-4ec3-9277-57ad3168141b
status: ILLEGAL, voltype: LEAF, format: COW, legality:
ILLEGAL, type: SPARSE
image:f2e35007-ff0f-4f74-90ec-1a28d342d564
- 096faec2-e0e0-47a5-9a24-9332de963bfb
status: ILLEGAL, voltype: LEAF, format: COW, legality:
ILLEGAL, type: SPARSE
image:0d9b635d-22ef-4456-9b10-20be027baa7a
- 2929df28-eae8-4f27-afee-a984fe0b07e7
status: OK, voltype: INTERNAL, format: RAW, legality: LEGAL,
type: PREALLOCATED
- f65be7d6-d1bf-4db3-aa04-fd59265d5ebc
status: ILLEGAL, voltype: LEAF, format: COW, legality:
ILLEGAL, type: SPARSE
image:1fd83784-dc53-4f40-ac13-ac2f046aa81f
- b413-1671-416c-bebc-3415ee7e61b2
status: ILLEGAL, voltype: LEAF, format: COW, legality:
ILLEGAL, type: SPARSE
image:145e5438-b7e8-45fd-81ea-3eb10a07acb6
- baa84312-8c4e-4ac1-aa50-27836b67e5f6
status: OK, voltype: INTERNAL, format: COW, legality: LEGAL,
type: SPARSE
- 2a95e1fb-7e42-4589-836b-76b45f03f854
status: ILLEGAL, voltype: LEAF, format: COW, legality:
ILLEGAL, type: SPARSE
image:dc856555-bfef-4bfa-8351-59b5a4f04331
- 7efe2e7e-ca24-4b27-b512-b42795c79ea4
status: OK, voltype: INTERNAL, format: COW, legality: LEGAL,
type: SPARSE
- a3f715c2-efc4-4421-aa4b-efce5a853e9e
status: ILLEGAL, voltype: LEAF, format: COW, legality:
ILLEGAL, type: SPARSE
Thank you very much!!!
Bruno
On Mon, Feb 25, 2019 at 11:32 AM Shani Leviim wrote:
> Hi Bruno,
> Can you please share the output of:
> vdsm-tool dump-volume-chains
>
> Also, can you see those images on the 'images' table?
>
>
> *Regards,*
>
> *Shani Leviim*
>
>
> On Mon, Feb 25, 2019 at 9:32 AM Bruno Rodriguez wrote:
>
>> Good morning, Shani
>>
>> I'm not trying to deactivate any disk because the VM using it is working.
>> I can't turn it off because I'm pretty sure if I do I won't be able to turn
>> it on again, in fact the web interface is telling me that if I turn it off
>> possibly it won't restart :(
>>
>> For what I can check I have no information about any of the the snapshots
>> I provided in the database
>>
>> engine=# select * from snapshots where snapshot_id IN
>> ('f649d9c1-563e-49d4-9fad-6bc94abc279b',
>> '5734df23-de67-41a8-88a1-423cecfe7260',
>> 'f649d9c1-563e-49d4-9fad-6bc94abc279b',
>> '2929df28-eae8-4f27-afee-a984fe0b07e7',
>> '4bd4360e-e0f4-4629-ab38-2f0d80d3ae0f',
>> 'fbaff53b-30ce-4b20-8f10-80e70becb48c',
>> 'c628386a-da6c-4a0d-ae7d-3e6ecda27d6d',
>> 'e9ddaa5c-007d-49e6-8384-efefebb00aa6',
>> '5b6db52a-bfe3-45f8-b7bb-d878c4e63cb4',
>> '7efe2e7e-ca24-4b27-b512-b42795c79ea4');
>> snapshot_id | vm_id | snapshot_type | status | description |
>> creation_date | app_list | vm_configuration | _create_date | _update_date |
>> memory_volume | memory_metadata_disk_id | memory_dump_disk_id | vm_conf
>> iguration_broken
>>
>> -+---+---++-+---+--+--+--+--+---+-+-+
>> -
>> (0 rows)
>>
>>
>> Thank you
>>
>>
>> On Sun, Feb 24, 2019 at 12:16 PM Shani Leviim wrote:
>>
>>> Hi Bruno,
>>>
>>> It seems that the disk you're trying to deactivate is in use ( Logical
>>> volume
>>> e655abce-c5e8-44f3-8d50-9fd76edf05cb/fa154782-0dbb-45b5-ba62-d6937259f097
>>> in use).
>>> Is there any task that uses that disk?
>>>
>>> Also, did you try to verify the snapshot's creation date with the DB?
>>> ( select * from snapshots; )
>>>
>>>
>>> *Regards*
>>>
>>> *Shani Leviim*
>>>
>>>
>>> On Fri, Feb 22, 2019 at 6:08 PM Bruno Rodriguez wrote:
>>>
>>>> Hello,
>>>>
>>>> We are experiencing some problems with some snapshots in illegal status
>>>> generated with the python API. I think I
[ovirt-users] Re: Problem with snapshots in illegal status
Good morning, Shani
I'm not trying to deactivate any disk because the VM using it is working. I
can't turn it off because I'm pretty sure if I do I won't be able to turn
it on again, in fact the web interface is telling me that if I turn it off
possibly it won't restart :(
For what I can check I have no information about any of the the snapshots I
provided in the database
engine=# select * from snapshots where snapshot_id IN
('f649d9c1-563e-49d4-9fad-6bc94abc279b',
'5734df23-de67-41a8-88a1-423cecfe7260',
'f649d9c1-563e-49d4-9fad-6bc94abc279b',
'2929df28-eae8-4f27-afee-a984fe0b07e7',
'4bd4360e-e0f4-4629-ab38-2f0d80d3ae0f',
'fbaff53b-30ce-4b20-8f10-80e70becb48c',
'c628386a-da6c-4a0d-ae7d-3e6ecda27d6d',
'e9ddaa5c-007d-49e6-8384-efefebb00aa6',
'5b6db52a-bfe3-45f8-b7bb-d878c4e63cb4',
'7efe2e7e-ca24-4b27-b512-b42795c79ea4');
snapshot_id | vm_id | snapshot_type | status | description | creation_date
| app_list | vm_configuration | _create_date | _update_date | memory_volume
| memory_metadata_disk_id | memory_dump_disk_id | vm_conf
iguration_broken
-+---+---++-+---+--+--+--+--+---+-+-+
-
(0 rows)
Thank you
On Sun, Feb 24, 2019 at 12:16 PM Shani Leviim wrote:
> Hi Bruno,
>
> It seems that the disk you're trying to deactivate is in use ( Logical
> volume
> e655abce-c5e8-44f3-8d50-9fd76edf05cb/fa154782-0dbb-45b5-ba62-d6937259f097
> in use).
> Is there any task that uses that disk?
>
> Also, did you try to verify the snapshot's creation date with the DB?
> ( select * from snapshots; )
>
>
> *Regards*
>
> *Shani Leviim*
>
>
> On Fri, Feb 22, 2019 at 6:08 PM Bruno Rodriguez wrote:
>
>> Hello,
>>
>> We are experiencing some problems with some snapshots in illegal status
>> generated with the python API. I think I'm not the only one, and that is
>> not a relief but I hope someone can help about it.
>>
>> I'm a bit scared because, for what I see, the creation date in the engine
>> for every snapshot is way different from the date when it was really
>> created. The name of the snapshot is in the format
>> backup_snapshot_MMDD-HHMMSS, but as you can see in the following
>> examples, the stored date is totally random...
>>
>> Size
>> Creation Date
>> Snapshot Description
>> Status
>> Disk Snapshot ID
>>
>> 33 GiB
>> Mar 2, 2018, 5:03:57 PM
>> backup_snapshot_20190217-011645
>> Illegal
>> 5734df23-de67-41a8-88a1-423cecfe7260
>>
>> 33 GiB
>> May 8, 2018, 10:02:56 AM
>> backup_snapshot_20190216-013047
>> Illegal
>> f649d9c1-563e-49d4-9fad-6bc94abc279b
>>
>> 10 GiB
>> Feb 21, 2018, 11:10:17 AM
>> backup_snapshot_20190217-010004
>> Illegal
>> 2929df28-eae8-4f27-afee-a984fe0b07e7
>>
>> 43 GiB
>> Feb 2, 2018, 12:55:51 PM
>> backup_snapshot_20190216-015544
>> Illegal
>> 4bd4360e-e0f4-4629-ab38-2f0d80d3ae0f
>>
>> 11 GiB
>> Feb 13, 2018, 12:51:08 PM
>> backup_snapshot_20190217-010541
>> Illegal
>> fbaff53b-30ce-4b20-8f10-80e70becb48c
>>
>> 11 GiB
>> Feb 13, 2018, 4:05:39 PM
>> backup_snapshot_20190217-011207
>> Illegal
>> c628386a-da6c-4a0d-ae7d-3e6ecda27d6d
>>
>> 11 GiB
>> Feb 13, 2018, 4:38:25 PM
>> backup_snapshot_20190216-012058
>> Illegal
>> e9ddaa5c-007d-49e6-8384-efefebb00aa6
>>
>> 11 GiB
>> Feb 13, 2018, 10:52:09 AM
>> backup_snapshot_20190216-012550
>> Illegal
>> 5b6db52a-bfe3-45f8-b7bb-d878c4e63cb4
>>
>> 55 GiB
>> Jan 22, 2018, 5:02:29 PM
>> backup_snapshot_20190217-012659
>> Illegal
>> 7efe2e7e-ca24-4b27-b512-b42795c79ea4
>>
>>
>> When I'm getting the logs for the first one, to check what happened to
>> it, I get the following
>>
>> 2019-02-17 01:16:45,839+01 INFO
>> [org.ovirt.engine.core.vdsbroker.irsbroker.CreateVolumeVDSCommand] (default
>> task-100) [96944daa-c90a-4ad7-a556-c98e66550f87] START,
>> CreateVolumeVDSCommand(
>> CreateVolumeVDSCommandParameters:{storagePoolId='fa64792e-73b3-4da2-9d0b-f334422aaccf',
>> ignoreFailoverLimit='false',
>> storageDomainId='e655abce-c5e8-44f3-8d50-9fd76edf05cb',
>> imageGroupId='c5cc464e-eb71-4edf-a780-60180c592a6f',
>> imageSizeInBytes='32212254720', volumeFormat='COW',
>> newImageId='fa154782-0dbb-45b5-ba62
[ovirt-users] Problem with snapshots in illegal status
Hello,
We are experiencing some problems with some snapshots in illegal status
generated with the python API. I think I'm not the only one, and that is
not a relief but I hope someone can help about it.
I'm a bit scared because, for what I see, the creation date in the engine
for every snapshot is way different from the date when it was really
created. The name of the snapshot is in the format
backup_snapshot_MMDD-HHMMSS, but as you can see in the following
examples, the stored date is totally random...
Size
Creation Date
Snapshot Description
Status
Disk Snapshot ID
33 GiB
Mar 2, 2018, 5:03:57 PM
backup_snapshot_20190217-011645
Illegal
5734df23-de67-41a8-88a1-423cecfe7260
33 GiB
May 8, 2018, 10:02:56 AM
backup_snapshot_20190216-013047
Illegal
f649d9c1-563e-49d4-9fad-6bc94abc279b
10 GiB
Feb 21, 2018, 11:10:17 AM
backup_snapshot_20190217-010004
Illegal
2929df28-eae8-4f27-afee-a984fe0b07e7
43 GiB
Feb 2, 2018, 12:55:51 PM
backup_snapshot_20190216-015544
Illegal
4bd4360e-e0f4-4629-ab38-2f0d80d3ae0f
11 GiB
Feb 13, 2018, 12:51:08 PM
backup_snapshot_20190217-010541
Illegal
fbaff53b-30ce-4b20-8f10-80e70becb48c
11 GiB
Feb 13, 2018, 4:05:39 PM
backup_snapshot_20190217-011207
Illegal
c628386a-da6c-4a0d-ae7d-3e6ecda27d6d
11 GiB
Feb 13, 2018, 4:38:25 PM
backup_snapshot_20190216-012058
Illegal
e9ddaa5c-007d-49e6-8384-efefebb00aa6
11 GiB
Feb 13, 2018, 10:52:09 AM
backup_snapshot_20190216-012550
Illegal
5b6db52a-bfe3-45f8-b7bb-d878c4e63cb4
55 GiB
Jan 22, 2018, 5:02:29 PM
backup_snapshot_20190217-012659
Illegal
7efe2e7e-ca24-4b27-b512-b42795c79ea4
When I'm getting the logs for the first one, to check what happened to it,
I get the following
2019-02-17 01:16:45,839+01 INFO
[org.ovirt.engine.core.vdsbroker.irsbroker.CreateVolumeVDSCommand] (default
task-100) [96944daa-c90a-4ad7-a556-c98e66550f87] START,
CreateVolumeVDSCommand(
CreateVolumeVDSCommandParameters:{storagePoolId='fa64792e-73b3-4da2-9d0b-f334422aaccf',
ignoreFailoverLimit='false',
storageDomainId='e655abce-c5e8-44f3-8d50-9fd76edf05cb',
imageGroupId='c5cc464e-eb71-4edf-a780-60180c592a6f',
imageSizeInBytes='32212254720', volumeFormat='COW',
newImageId='fa154782-0dbb-45b5-ba62-d6937259f097', imageType='Sparse',
newImageDescription='', imageInitialSizeInBytes='0',
imageId='5734df23-de67-41a8-88a1-423cecfe7260',
sourceImageGroupId='c5cc464e-eb71-4edf-a780-60180c592a6f'}), log id:
497c168a
2019-02-17 01:18:26,506+01 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.GetVolumeInfoVDSCommand]
(default task-212) [19f00d3e-5159-48aa-b3a0-615a085b62d9] START,
GetVolumeInfoVDSCommand(HostName = hood13.pic.es,
GetVolumeInfoVDSCommandParameters:{hostId='0a774472-5737-4ea2-b49a-6f0ea4572199',
storagePoolId='fa64792e-73b3-4da2-9d0b-f334422aaccf',
storageDomainId='e655abce-c5e8-44f3-8d50-9fd76edf05cb',
imageGroupId='c5cc464e-eb71-4edf-a780-60180c592a6f',
imageId='5734df23-de67-41a8-88a1-423cecfe7260'}), log id: 111a34cf
2019-02-17 01:18:26,764+01 INFO
[org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand]
(default task-212) [19f00d3e-5159-48aa-b3a0-615a085b62d9] Successfully
added Download disk 'vm.example.com_Disk1' (id
'5734df23-de67-41a8-88a1-423cecfe7260') for image transfer command
'11104d8c-2a9b-4924-96ce-42ef66725616'
2019-02-17 01:18:27,310+01 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.AddImageTicketVDSCommand]
(default task-212) [19f00d3e-5159-48aa-b3a0-615a085b62d9] START,
AddImageTicketVDSCommand(HostName = hood11.pic.es,
AddImageTicketVDSCommandParameters:{hostId='79cbda85-35f4-44df-b309-01b57bc2477e',
ticketId='0d389c3e-5ea5-4886-8ea7-60a1560e3b2d', timeout='300',
operations='[read]', size='35433480192',
url='file:///rhev/data-center/mnt/blockSD/e655abce-c5e8-44f3-8d50-9fd76edf05cb/images/c5cc464e-eb71-4edf-a780-60180c592a6f/5734df23-de67-41a8-88a1-423cecfe7260',
filename='null'}), log id: f5de141
2019-02-17 01:22:28,898+01 INFO
[org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand]
(EE-ManagedThreadFactory-engineScheduled-Thread-100)
[19f00d3e-5159-48aa-b3a0-615a085b62d9] Renewing transfer ticket for
Download disk 'vm.example.com_Disk1' (id
'5734df23-de67-41a8-88a1-423cecfe7260')
2019-02-17 01:26:33,588+01 INFO
[org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand]
(EE-ManagedThreadFactory-engineScheduled-Thread-100)
[19f00d3e-5159-48aa-b3a0-615a085b62d9] Renewing transfer ticket for
Download disk 'vm.example.com_Disk1' (id
'5734df23-de67-41a8-88a1-423cecfe7260')
2019-02-17 01:26:49,319+01 INFO
[org.ovirt.engine.core.bll.storage.disk.image.TransferDiskImageCommand]
(EE-ManagedThreadFactory-engineScheduled-Thread-6)
[19f00d3e-5159-48aa-b3a0-615a085b62d9] Finalizing successful transfer for
Download disk 'vm.example.com_Disk1' (id
'5734df23-de67-41a8-88a1-423cecfe7260')
2019-02-17 01:27:17,771+01 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(EE-ManagedThreadFactory-engineScheduled-Thread-6)
[19f00d3e-5159-48aa-b3a0-615a085b62d9] EVENT_ID:
VDS_BROKER_COMMAND_FAILURE(10,
Re: [ovirt-users] Unable to rename disks via REST API
Finally I was able to rename the disks, the problem was about handling that put request and my inability to check libcurl documentation (I was treating the XML I was sending as a string instead of a file). Sorry because I needed this script to be working as fast as I could, so I didn't try to reproduce the 500 error, but I wouldn't be suprised if it was because of a totally wrong URL. Sorry again :( On Wed, Jun 28, 2017 at 1:56 PM, Juan Hernández wrote: > On 06/28/2017 01:34 PM, Bruno Rodriguez wrote: > > Shit, I got it. Sorry > > > > The problem is that I was accessing to the v4 disk-attachment id and I > > was getting everything quite messed up. I was doing all of this while > > creating a machine, so I was trying to rename the disk at the same time > > it's being created. > > > > I'll delete all the "if ($ovirt_major == 3)" I have in my code. If I > > have any problem I'll let you know. > > > > Thank you > > > > If what you want to do is set the name of the disk for a VM that you are > creating then you can just set it when adding the disk: > > POST /ovirt-engine/api/vms/123/diskattachments > > > > yourfavoritename > ... > > ... > > > That way you don't need to modify it later. > > Also, in general, try to wait till the objects are completely created > before trying to use or update them. For disks in particular, it is good > idea to repeatedly retrieve the disk till the 'status' is 'OK': > > > https://github.com/oVirt/ovirt-engine-sdk/blob/master/ > sdk/examples/add_vm_disk.py#L73-L80 > > (This is an example from the Python SDK, but you get the idea. There are > SDKs for Ruby and Java as well.) > > Finally, if you get a 500 error then there is most probably a bug. The > API should never return that, even if you try to do something that > doesn't make sense it should respond with a reasonable error message. If > you keep getting that 500 error please share the details. > > > On Wed, Jun 28, 2017 at 1:03 PM, Juan Hernández > <mailto:jhern...@redhat.com>> wrote: > > > > On 06/28/2017 12:55 PM, Bruno Rodriguez wrote: > > > I'm sorry about bothering you again, but after trying it some > times I'm > > > still getting a "500 Internal Server Error". I'm using a REST > client > > > instead of CURL and I tried adding a "Version: 3" to headers and > used > > > the URL with the v3 as well. > > > > > > I'm issuing a PUT of > > > > > > Alias_for_disk > > > > > > To the URL > > > > > > https://myserver/ovirt-engine/api/v3/vms/62498f51-0203-48b9- > 83c8-4c6f3bdfe05c/disks/583ed952-46a8-4bc5-8a27-8660e4a24ea2 > > <https://myserver/ovirt-engine/api/v3/vms/62498f51- > 0203-48b9-83c8-4c6f3bdfe05c/disks/583ed952-46a8-4bc5-8a27-8660e4a24ea2> > > > > > > I mean, I can live without it but we are using oVirt as a "static > > > virtualization" environment and is quite useful for us being able > to > > > recognize easily each disk by its server name. In case I have to > wait > > > until the 4.2 API version to automatize this I'll do :( > > > > > > > That should work. Can you please check if you get any useful message > in > > /var/log/ovirt-engine/server.log or /var/log/ovirt-engine/engine. > log? > > > > > > > > > > > On Wed, Jun 28, 2017 at 11:18 AM, Bruno Rodriguez <mailto:br...@pic.es> > > > <mailto:br...@pic.es <mailto:br...@pic.es>>> wrote: > > > > > > Thank you very much !!! > > > > > > I expected I was missing something like that. Thanks again! > > > > > > On Wed, Jun 28, 2017 at 11:12 AM, Juan Hernández > > > mailto:jhern...@redhat.com> > > <mailto:jhern...@redhat.com <mailto:jhern...@redhat.com>>> wrote: > > > > > > On 06/28/2017 10:43 AM, Bruno Rodriguez wrote: > > > > Thank you, Daniel > > > > > > > > I tried a PUT with the same XML body, I got a "405 > > Method Not Allowed". > > > > It's quite strange, there must be someting I'm missing > > > > > > > > > > The operation to update a disk will be introduced
Re: [ovirt-users] Unable to rename disks via REST API
Shit, I got it. Sorry
The problem is that I was accessing to the v4 disk-attachment id and I was
getting everything quite messed up. I was doing all of this while creating
a machine, so I was trying to rename the disk at the same time it's being
created.
I'll delete all the "if ($ovirt_major == 3)" I have in my code. If I have
any problem I'll let you know.
Thank you
On Wed, Jun 28, 2017 at 1:03 PM, Juan Hernández wrote:
> On 06/28/2017 12:55 PM, Bruno Rodriguez wrote:
> > I'm sorry about bothering you again, but after trying it some times I'm
> > still getting a "500 Internal Server Error". I'm using a REST client
> > instead of CURL and I tried adding a "Version: 3" to headers and used
> > the URL with the v3 as well.
> >
> > I'm issuing a PUT of
> >
> > Alias_for_disk
> >
> > To the URL
> >
> > https://myserver/ovirt-engine/api/v3/vms/62498f51-0203-48b9-
> 83c8-4c6f3bdfe05c/disks/583ed952-46a8-4bc5-8a27-8660e4a24ea2
> >
> > I mean, I can live without it but we are using oVirt as a "static
> > virtualization" environment and is quite useful for us being able to
> > recognize easily each disk by its server name. In case I have to wait
> > until the 4.2 API version to automatize this I'll do :(
> >
>
> That should work. Can you please check if you get any useful message in
> /var/log/ovirt-engine/server.log or /var/log/ovirt-engine/engine.log?
>
> >
> >
> > On Wed, Jun 28, 2017 at 11:18 AM, Bruno Rodriguez > <mailto:br...@pic.es>> wrote:
> >
> > Thank you very much !!!
> >
> > I expected I was missing something like that. Thanks again!
> >
> > On Wed, Jun 28, 2017 at 11:12 AM, Juan Hernández
> > mailto:jhern...@redhat.com>> wrote:
> >
> > On 06/28/2017 10:43 AM, Bruno Rodriguez wrote:
> > > Thank you, Daniel
> > >
> > > I tried a PUT with the same XML body, I got a "405 Method Not
> Allowed".
> > > It's quite strange, there must be someting I'm missing
> > >
> >
> > The operation to update a disk will be introduced in version 4
> > of the
> > API with version 4.2 of the engine. Meanwhile the way to update
> > the disk
> > is to use version 3 of the API and the disks sub-collection of
> the
> > virtual machine. That means that if you have a VM with id 123
> > and a disk
> > with id 456 you can send a request like this:
> >
> > PUT /ovirt-engine/api/v3/vms/123/disks/456
> >
> > With a request body like this:
> >
> >
> > newalias
> >
> >
> > Note that you can use the above "v3" prefix in the URL or else
> the
> > "Version: 3" header. A complete example using curl:
> >
> > ---8<---
> > #!/bin/bash -ex
> >
> > url="https://.../ovirt-engine/api";
> > user="admin@internal"
> > password="..."
> > vm_id="..."
> > disk_id="..."
> >
> > curl \
> > --verbose \
> > --cacert "ca.pem" \
> > --header "Version: 3" \
> > --header "Content-Type: application/xml" \
> > --user "${user}:${password}" \
> > --request PUT \
> > --data "
> >
> > newalias
> >
> > " \
> > "${url}/vms/${vm_id}/disks/${disk_id}"
> > --->8---
> >
> > >
> > > On Wed, Jun 28, 2017 at 10:07 AM, Daniel Erez <
> de...@redhat.com <mailto:de...@redhat.com>
> > > <mailto:de...@redhat.com <mailto:de...@redhat.com>>> wrote:
> > >
> > > Hi,
> > >
> > > Updating is done using the PUT method.
> > > Please try that with the same XML body.
> > >
> > > Thanks,
> > > Daniel
> > >
> > > On Wed, Jun 28, 2017 at 10:26 AM Bruno Rodriguez <
> br...@pic.es <mailto:br...@pic.es>
> > > <mailto:br...@pic.es <mailto:br...@pic.es>>> wrote:
> > >
> > > Hello everyone,
> > >
>
Re: [ovirt-users] Unable to rename disks via REST API
I'm sorry about bothering you again, but after trying it some times I'm
still getting a "500 Internal Server Error". I'm using a REST client
instead of CURL and I tried adding a "Version: 3" to headers and used the
URL with the v3 as well.
I'm issuing a PUT of
Alias_for_disk
To the URL
https://myserver/ovirt-engine/api/v3/vms/62498f51-0203-48b9-83c8-4c6f3bdfe05c/disks/583ed952-46a8-4bc5-8a27-8660e4a24ea2
I mean, I can live without it but we are using oVirt as a "static
virtualization" environment and is quite useful for us being able to
recognize easily each disk by its server name. In case I have to wait until
the 4.2 API version to automatize this I'll do :(
On Wed, Jun 28, 2017 at 11:18 AM, Bruno Rodriguez wrote:
> Thank you very much !!!
>
> I expected I was missing something like that. Thanks again!
>
> On Wed, Jun 28, 2017 at 11:12 AM, Juan Hernández
> wrote:
>
>> On 06/28/2017 10:43 AM, Bruno Rodriguez wrote:
>> > Thank you, Daniel
>> >
>> > I tried a PUT with the same XML body, I got a "405 Method Not Allowed".
>> > It's quite strange, there must be someting I'm missing
>> >
>>
>> The operation to update a disk will be introduced in version 4 of the
>> API with version 4.2 of the engine. Meanwhile the way to update the disk
>> is to use version 3 of the API and the disks sub-collection of the
>> virtual machine. That means that if you have a VM with id 123 and a disk
>> with id 456 you can send a request like this:
>>
>> PUT /ovirt-engine/api/v3/vms/123/disks/456
>>
>> With a request body like this:
>>
>>
>> newalias
>>
>>
>> Note that you can use the above "v3" prefix in the URL or else the
>> "Version: 3" header. A complete example using curl:
>>
>> ---8<---
>> #!/bin/bash -ex
>>
>> url="https://.../ovirt-engine/api";
>> user="admin@internal"
>> password="..."
>> vm_id="..."
>> disk_id="..."
>>
>> curl \
>> --verbose \
>> --cacert "ca.pem" \
>> --header "Version: 3" \
>> --header "Content-Type: application/xml" \
>> --user "${user}:${password}" \
>> --request PUT \
>> --data "
>>
>> newalias
>>
>> " \
>> "${url}/vms/${vm_id}/disks/${disk_id}"
>> --->8---
>>
>> >
>> > On Wed, Jun 28, 2017 at 10:07 AM, Daniel Erez > > <mailto:de...@redhat.com>> wrote:
>> >
>> > Hi,
>> >
>> > Updating is done using the PUT method.
>> > Please try that with the same XML body.
>> >
>> > Thanks,
>> > Daniel
>> >
>> > On Wed, Jun 28, 2017 at 10:26 AM Bruno Rodriguez > > <mailto:br...@pic.es>> wrote:
>> >
>> > Hello everyone,
>> >
>> > I'm having some problems about renaming some disks (setting a
>> > different alias, name or description) for VMs disks created from
>> > a template. When I get this URL
>> >
>> > https://ovirt-manager/ovirt-engine/api/disks/0123
>> > <https://ovirt-manager/ovirt-engine/api/disks/0123>
>> >
>> > I can see are the methods sparsify, export, move and copy. I
>> > tried to POST the following XML to the previous URL with no
>> > result (as expected, it won't work)
>> >
>> >
>> > my_machine_Disk1
>> >
>> >
>> > I'm quite sure I'm thinking about it in a wrong way (as usual).
>> > Any help would be welcome...
>> >
>> > Thank you in advance
>> >
>> > --
>> > Bruno Rodríguez Rodríguez
>> >
>> > *Port d'Informació Científica (PIC)*
>> >
>> > ___
>> > Users mailing list
>> > Users@ovirt.org <mailto:Users@ovirt.org>
>> > http://lists.ovirt.org/mailman/listinfo/users
>> > <http://lists.ovirt.org/mailman/listinfo/users>
>> >
>> >
>> >
>> >
>> > --
>> > Bruno Rodríguez Rodríguez
>> >
>> > *Port d'Informació Científica (PIC)*
>> > Campus UAB - Edificio D,
>> > C / Albareda, s / n
>> > 08193-Bellaterra (Barcelona), España
>> > Telf. +34 93 170 27 30
>> > GPS coordenadas: 41.500850 2.110628
>> >
>> > "Si algo me ha enseñado el tetris, es que los errores se acumulan y los
>> > triunfos desaparecen"
>> >
>> >
>> > ___
>> > Users mailing list
>> > Users@ovirt.org
>> > http://lists.ovirt.org/mailman/listinfo/users
>> >
>>
>>
>
>
> --
> Bruno Rodríguez Rodríguez
>
> *Port d'Informació Científica (PIC)*
> Campus UAB - Edificio D,
> C / Albareda, s / n
> 08193-Bellaterra (Barcelona), España
> Telf. +34 93 170 27 30
> GPS coordenadas: 41.500850 2.110628
>
> "Si algo me ha enseñado el tetris, es que los errores se acumulan y los
> triunfos desaparecen"
>
--
Bruno Rodríguez Rodríguez
*Port d'Informació Científica (PIC)*
Campus UAB - Edificio D,
C / Albareda, s / n
08193-Bellaterra (Barcelona), España
Telf. +34 93 170 27 30
GPS coordenadas: 41.500850 2.110628
"Si algo me ha enseñado el tetris, es que los errores se acumulan y los
triunfos desaparecen"
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Unable to rename disks via REST API
Thank you very much !!!
I expected I was missing something like that. Thanks again!
On Wed, Jun 28, 2017 at 11:12 AM, Juan Hernández
wrote:
> On 06/28/2017 10:43 AM, Bruno Rodriguez wrote:
> > Thank you, Daniel
> >
> > I tried a PUT with the same XML body, I got a "405 Method Not Allowed".
> > It's quite strange, there must be someting I'm missing
> >
>
> The operation to update a disk will be introduced in version 4 of the
> API with version 4.2 of the engine. Meanwhile the way to update the disk
> is to use version 3 of the API and the disks sub-collection of the
> virtual machine. That means that if you have a VM with id 123 and a disk
> with id 456 you can send a request like this:
>
> PUT /ovirt-engine/api/v3/vms/123/disks/456
>
> With a request body like this:
>
>
> newalias
>
>
> Note that you can use the above "v3" prefix in the URL or else the
> "Version: 3" header. A complete example using curl:
>
> ---8<---
> #!/bin/bash -ex
>
> url="https://.../ovirt-engine/api";
> user="admin@internal"
> password="..."
> vm_id="..."
> disk_id="..."
>
> curl \
> --verbose \
> --cacert "ca.pem" \
> --header "Version: 3" \
> --header "Content-Type: application/xml" \
> --user "${user}:${password}" \
> --request PUT \
> --data "
>
> newalias
>
> " \
> "${url}/vms/${vm_id}/disks/${disk_id}"
> --->8---
>
> >
> > On Wed, Jun 28, 2017 at 10:07 AM, Daniel Erez > <mailto:de...@redhat.com>> wrote:
> >
> > Hi,
> >
> > Updating is done using the PUT method.
> > Please try that with the same XML body.
> >
> > Thanks,
> > Daniel
> >
> > On Wed, Jun 28, 2017 at 10:26 AM Bruno Rodriguez > <mailto:br...@pic.es>> wrote:
> >
> > Hello everyone,
> >
> > I'm having some problems about renaming some disks (setting a
> > different alias, name or description) for VMs disks created from
> > a template. When I get this URL
> >
> > https://ovirt-manager/ovirt-engine/api/disks/0123
> > <https://ovirt-manager/ovirt-engine/api/disks/0123>
> >
> > I can see are the methods sparsify, export, move and copy. I
> > tried to POST the following XML to the previous URL with no
> > result (as expected, it won't work)
> >
> >
> > my_machine_Disk1
> >
> >
> > I'm quite sure I'm thinking about it in a wrong way (as usual).
> > Any help would be welcome...
> >
> > Thank you in advance
> >
> > --
> > Bruno Rodríguez Rodríguez
> >
> > *Port d'Informació Científica (PIC)*
> >
> > ___
> > Users mailing list
> > Users@ovirt.org <mailto:Users@ovirt.org>
> > http://lists.ovirt.org/mailman/listinfo/users
> > <http://lists.ovirt.org/mailman/listinfo/users>
> >
> >
> >
> >
> > --
> > Bruno Rodríguez Rodríguez
> >
> > *Port d'Informació Científica (PIC)*
> > Campus UAB - Edificio D,
> > C / Albareda, s / n
> > 08193-Bellaterra (Barcelona), España
> > Telf. +34 93 170 27 30
> > GPS coordenadas: 41.500850 2.110628
> >
> > "Si algo me ha enseñado el tetris, es que los errores se acumulan y los
> > triunfos desaparecen"
> >
> >
> > ___
> > Users mailing list
> > Users@ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/users
> >
>
>
--
Bruno Rodríguez Rodríguez
*Port d'Informació Científica (PIC)*
Campus UAB - Edificio D,
C / Albareda, s / n
08193-Bellaterra (Barcelona), España
Telf. +34 93 170 27 30
GPS coordenadas: 41.500850 2.110628
"Si algo me ha enseñado el tetris, es que los errores se acumulan y los
triunfos desaparecen"
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Unable to rename disks via REST API
Thank you, Daniel I tried a PUT with the same XML body, I got a "405 Method Not Allowed". It's quite strange, there must be someting I'm missing On Wed, Jun 28, 2017 at 10:07 AM, Daniel Erez wrote: > Hi, > > Updating is done using the PUT method. > Please try that with the same XML body. > > Thanks, > Daniel > > On Wed, Jun 28, 2017 at 10:26 AM Bruno Rodriguez wrote: > >> Hello everyone, >> >> I'm having some problems about renaming some disks (setting a different >> alias, name or description) for VMs disks created from a template. When I >> get this URL >> >> https://ovirt-manager/ovirt-engine/api/disks/0123 >> >> I can see are the methods sparsify, export, move and copy. I tried to >> POST the following XML to the previous URL with no result (as expected, it >> won't work) >> >> >> my_machine_Disk1 >> >> >> I'm quite sure I'm thinking about it in a wrong way (as usual). Any help >> would be welcome... >> >> Thank you in advance >> >> -- >> Bruno Rodríguez Rodríguez >> >> *Port d'Informació Científica (PIC)* >> >> ___ >> Users mailing list >> Users@ovirt.org >> http://lists.ovirt.org/mailman/listinfo/users >> > -- Bruno Rodríguez Rodríguez *Port d'Informació Científica (PIC)* Campus UAB - Edificio D, C / Albareda, s / n 08193-Bellaterra (Barcelona), España Telf. +34 93 170 27 30 GPS coordenadas: 41.500850 2.110628 "Si algo me ha enseñado el tetris, es que los errores se acumulan y los triunfos desaparecen" ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] Unable to rename disks via REST API
Hello everyone, I'm having some problems about renaming some disks (setting a different alias, name or description) for VMs disks created from a template. When I get this URL https://ovirt-manager/ovirt-engine/api/disks/0123 I can see are the methods sparsify, export, move and copy. I tried to POST the following XML to the previous URL with no result (as expected, it won't work) my_machine_Disk1 I'm quite sure I'm thinking about it in a wrong way (as usual). Any help would be welcome... Thank you in advance -- Bruno Rodríguez Rodríguez *Port d'Informació Científica (PIC)* ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Problem while adding a VM NIC via REST API
On Fri, Jun 2, 2017 at 4:09 PM, Juan Hernández wrote: > On 06/02/2017 03:56 PM, Bruno Rodriguez wrote: > > Hello everyone, > > > > I have some scripts that create VMs, which are in perl using libcurl and > > oVirt REST API. They work quite fine but I'm experiencing something > unusual. > > > > After I create the machine (let's suppose it's called server.pic.es > > <http://server.pic.es>) with UUID 123abc I post the following REST API > > call to https://... /vms/123abc/nics > > > > > > server.pic.es_nic1 > > virtio > > VLANXXX > > > > > > The NIC is created and attached to the VM but it's network field is > > empty, not in the VLANXXX. I don't know if I'm missing something but > > this worked flawlessly with 3.6.9 REST API. > > > > Some people could say: "it's because you're using Perl". Yup, that's > > probably a mental issue of mine and I should visit a doctor about using > > it, but it doesn't work even using a fancy REST browser extension to > > send requests (ARC for chromium), anyways the REST reply is a "201: > > Created" that looks OK... > > > > Any idea or suggestion will be welcome. Thanks in advance! > > > > It is not because of Perl :-) . > > In version 4 of the API it is mandatory to specify the NIC profile, as > the network may have multiple profiles. So you need to find the > identifier of that NIC profile and then send a request like this: > > > server.pic.es_nic1 > virtio > > > > You can find the identifiers of the profiles like this: > > GET /ovirt-engine/api/networks/the_identifier_of_the_network/ > vnicprofildes > > If you want the old behavior, the behavior of version 3 of the API, you > can just add to your request the 'Version: 3' HTTP header. But note that > version 3 of the API is deprecated since version 4.0 of the engine, and > it will be removed with version 4.2 of the engine. > Thank you very much, I'll probably have to check that and add an "if" because I already was having problems with the APIv4 disks creation... Thanks again! ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
[ovirt-users] Problem while adding a VM NIC via REST API
Hello everyone, I have some scripts that create VMs, which are in perl using libcurl and oVirt REST API. They work quite fine but I'm experiencing something unusual. After I create the machine (let's suppose it's called server.pic.es) with UUID 123abc I post the following REST API call to https://... /vms/123abc/nics server.pic.es_nic1 virtio VLANXXX The NIC is created and attached to the VM but it's network field is empty, not in the VLANXXX. I don't know if I'm missing something but this worked flawlessly with 3.6.9 REST API. Some people could say: "it's because you're using Perl". Yup, that's probably a mental issue of mine and I should visit a doctor about using it, but it doesn't work even using a fancy REST browser extension to send requests (ARC for chromium), anyways the REST reply is a "201: Created" that looks OK... Any idea or suggestion will be welcome. Thanks in advance! -- Bruno Rodríguez Rodríguez *Port d'Informació Científica (PIC)* Campus UAB - Edificio D, C / Albareda, s / n 08193-Bellaterra (Barcelona), España Telf. +34 93 170 27 30 GPS coordenadas: 41.500850 2.110628 "Si algo me ha enseñado el tetris, es que los errores se acumulan y los triunfos desaparecen" ___ Users mailing list Users@ovirt.org http://lists.ovirt.org/mailman/listinfo/users
Re: [ovirt-users] Error authenticating bind using the AAA OpenLDAP module
Thanks ! Now it's working!
The problem was the absence of the line:
pool.default.auth.type = simple
It's strange, I thought that the default auth type was set to simple and I
didn't check it twice. After setting that the problem has to do about a
user/password incorrect, which is our problem because of the schema we are
using (migrated from a NIS some time ago).
The openldap_example.properties actually was a copy of openldap.properties,
I did it that way to customize it to our schema, but in a first instance
it was a carbon copy of the original.
Thanks again !
Bruno
On Thu, Jan 15, 2015 at 10:43 AM, Ondra Machacek
wrote:
> On 01/15/2015 10:36 AM, Alon Bar-Lev wrote:
>
>>
>>
>> - Original Message -
>>
>>> From: "Bruno Rodriguez"
>>> To: "Ondra Machacek"
>>> Cc: "Esther Accion" , users@ovirt.org
>>> Sent: Thursday, January 15, 2015 11:20:57 AM
>>> Subject: Re: [ovirt-users] Error authenticating bind using the AAA
>>> OpenLDAP module
>>>
>>> Thank you very much,
>>>
>>> using the following ldap.example.org file:
>>>
>>> -
>>>
>>> include =
>>> include =
>>>
>>
>> what do you have in openldap_example.properties?
>>
>
> It seems you have specified anonymous bind in openldap_example.properties.
> You should probably try it with original one (openldap.properties).
>
>
>
>> vars.server = ldap1.example.org
>>> #vars.user = cn=authenticate,ou=System,dc=example,dc=org
>>> #vars.password = X
>>>
>>
>> why have you commented out the vars?
>> you should have just removed the quotes from vars.password and keep
>> bellow as-is.
>>
>> pool.default.serverset.single.server = ${global:vars.server}
>>> pool.default.auth.simple.bindDN = cn=authenticate,ou=System,dc=
>>> example,dc=org
>>> pool.default.auth.simple.password = X
>>>
>>> pool.default.ssl.startTLS = true
>>> pool.default.ssl.truststore.file =
>>> /etc/ovirt-engine/extensions.d/ldap.example.org_keystore.jks
>>> pool.default.ssl.truststore.password = X
>>>
>>> -
>>>
>>> Then I get the following in the engine log:
>>>
>>>
>>> 2015-01-15 10:04:15,250 ERROR
>>> [org.ovirt.engine.core.bll.aaa.LoginAdminUserCommand]
>>> (ajp--127.0.0.1-8702-3) Error during CanDoActionFailure.: Class: class
>>> org.ovirt.engine.core.extensions.mgr.ExtensionInvokeCommandFailedEx
>>> ception
>>> Input:
>>> {Extkey[name=AAA_AUTHN_CREDENTIALS;type=class
>>> java.lang.String;uuid=AAA_AUTHN_CREDENTIALS[03b96485-
>>> 4bb5-4592-8167-810a5c909706];]=***,
>>> Extkey[name=EXTENSION_INVOKE_CONTEXT;type=class
>>> org.ovirt.engine.api.extensions.ExtMap;uuid=EXTENSION_INVOKE_CONTEXT[
>>> 886d2ebb-312a-49ae-9cc3-e1f849834b7d];]={Extkey[name=
>>> EXTENSION_INTERFACE_VERSION_MAX;type=class
>>> java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_
>>> MAX[f4cff49f-2717-4901-8ee9-df362446e3e7];]=0,
>>> Extkey[name=EXTENSION_LICENSE;type=class
>>> java.lang.String;uuid=EXTENSION_LICENSE[8a61ad65-
>>> 054c-4e31-9c6d-1ca4d60a4c18];]=ASL
>>> 2.0, Extkey[name=EXTENSION_NOTES;type=class
>>> java.lang.String;uuid=EXTENSION_NOTES[2da5ad7e-185a-
>>> 4584-aaff-97f66978e4ea];]=Display
>>> name: ovirt-engine-extension-aaa-ldap-1.0.0-1.el6,
>>> Extkey[name=EXTENSION_HOME_URL;type=class
>>> java.lang.String;uuid=EXTENSION_HOME_URL[4ad7a2f4-
>>> f969-42d4-b399-72d192e18304];]=
>>> http://www.ovirt.org ,Extkey[name=EXTENSION_LOCALE;type=class
>>> java.lang.String;uuid=EXTENSION_LOCALE[0780b112-
>>> 0ce0-404a-b85e-8765d778bb29];]=en_US,
>>> Extkey[name=EXTENSION_NAME;type=class
>>> java.lang.String;uuid=EXTENSION_NAME[651381d3-f54f-
>>> 4547-bf28-b0b01a103184];]=ovirt-engine-extension-aaa-ldap.authn,
>>> Extkey[name=EXTENSION_INTERFACE_VERSION_MIN;type=class
>>> java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_
>>> MIN[2b84fc91-305b-497b-a1d7-d961b9d2ce0b];]=0,
>>> Extkey[name=EXTENSION_CONFIGURATION;type=class
>>> java.util.Properties;uuid=EXTENSION_CONFIGURATION[
>>> 2d48ab72-f0a1-4312-b4ae-5068a226b0fc];]=***,
>>> Extkey[name=EXTENSION_AUTHOR;type=class
>>> java.lang.String;uuid=EXTENSION_AUTHOR[ef242f7a-
>>> 2dad-4bc5-9aad-e07018b7fbcc];]=The
>>> oVirt Project, Extkey[name=EXTENSION_INSTANCE_NAME;type=class
>
Re: [ovirt-users] Error authenticating bind using the AAA OpenLDAP module
revious message),
Bruno
On Thu, Jan 15, 2015 at 10:20 AM, Bruno Rodriguez wrote:
> Thank you very much,
>
> using the following ldap.example.org file:
>
> -
>
> include =
> include =
>
> vars.server = ldap1.example.org
> #vars.user = cn=authenticate,ou=System,dc=example,dc=org
> #vars.password = X
>
> pool.default.serverset.single.server = ${global:vars.server}
> pool.default.auth.simple.bindDN =
> cn=authenticate,ou=System,dc=example,dc=org
> pool.default.auth.simple.password = X
>
> pool.default.ssl.startTLS = true
> pool.default.ssl.truststore.file =
> /etc/ovirt-engine/extensions.d/ldap.example.org_keystore.jks
> pool.default.ssl.truststore.password = X
>
> -
>
> Then I get the following in the engine log:
>
>
> 2015-01-15 10:04:15,250 ERROR
> [org.ovirt.engine.core.bll.aaa.LoginAdminUserCommand]
> (ajp--127.0.0.1-8702-3) Error during CanDoActionFailure.: Class: class
> org.ovirt.engine.core.extensions.mgr.ExtensionInvokeCommandFailedException
> Input:
> {Extkey[name=AAA_AUTHN_CREDENTIALS;type=class
> java.lang.String;uuid=AAA_AUTHN_CREDENTIALS[03b96485-4bb5-4592-8167-810a5c909706];]=***,
> Extkey[name=EXTENSION_INVOKE_CONTEXT;type=class
> org.ovirt.engine.api.extensions.ExtMap;uuid=EXTENSION_INVOKE_CONTEXT[886d2ebb-312a-49ae-9cc3-e1f849834b7d];]={Extkey[name=EXTENSION_INTERFACE_VERSION_MAX;type=class
> java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_MAX[f4cff49f-2717-4901-8ee9-df362446e3e7];]=0,
> Extkey[name=EXTENSION_LICENSE;type=class
> java.lang.String;uuid=EXTENSION_LICENSE[8a61ad65-054c-4e31-9c6d-1ca4d60a4c18];]=ASL
> 2.0, Extkey[name=EXTENSION_NOTES;type=class
> java.lang.String;uuid=EXTENSION_NOTES[2da5ad7e-185a-4584-aaff-97f66978e4ea];]=Display
> name: ovirt-engine-extension-aaa-ldap-1.0.0-1.el6,
> Extkey[name=EXTENSION_HOME_URL;type=class
> java.lang.String;uuid=EXTENSION_HOME_URL[4ad7a2f4-f969-42d4-b399-72d192e18304];]=
> http://www.ovirt.org,Extkey[name=EXTENSION_LOCALE;type=class
> java.lang.String;uuid=EXTENSION_LOCALE[0780b112-0ce0-404a-b85e-8765d778bb29];]=en_US,
> Extkey[name=EXTENSION_NAME;type=class
> java.lang.String;uuid=EXTENSION_NAME[651381d3-f54f-4547-bf28-b0b01a103184];]=ovirt-engine-extension-aaa-ldap.authn,
> Extkey[name=EXTENSION_INTERFACE_VERSION_MIN;type=class
> java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_MIN[2b84fc91-305b-497b-a1d7-d961b9d2ce0b];]=0,
> Extkey[name=EXTENSION_CONFIGURATION;type=class
> java.util.Properties;uuid=EXTENSION_CONFIGURATION[2d48ab72-f0a1-4312-b4ae-5068a226b0fc];]=***,
> Extkey[name=EXTENSION_AUTHOR;type=class
> java.lang.String;uuid=EXTENSION_AUTHOR[ef242f7a-2dad-4bc5-9aad-e07018b7fbcc];]=The
> oVirt Project, Extkey[name=EXTENSION_INSTANCE_NAME;type=class
> java.lang.String;uuid=EXTENSION_INSTANCE_NAME[65c67ff6-aeca-4bd5-a245-8674327f011b];]=
> authn-ldap.example.org,
> Extkey[name=EXTENSION_BUILD_INTERFACE_VERSION;type=class
> java.lang.Integer;uuid=EXTENSION_BUILD_INTERFACE_VERSION[cb479e5a-4b23-46f8-aed3-56a4747a8ab7];]=0,
> Extkey[name=EXTENSION_CONFIGURATION_SENSITIVE_KEYS;type=interface
> java.util.Collection;uuid=EXTENSION_CONFIGURATION_SENSITIVE_KEYS[a456efa1-73ff-4204-9f9b-ebff01e35263];]=[],
> Extkey[name=AAA_AUTHN_CAPABILITIES;type=class
> java.lang.Long;uuid=AAA_AUTHN_CAPABILITIES[9d16bee3-10fd-46f2-83f9-3d3c54cf258d];]=12,
> Extkey[name=EXTENSION_GLOBAL_CONTEXT;type=class
> org.ovirt.engine.api.extensions.ExtMap;uuid=EXTENSION_GLOBAL_CONTEXT[9799e72f-7af6-4cf1-bf08-297bc8903676];]=*skip*,
> Extkey[name=EXTENSION_VERSION;type=class
> java.lang.String;uuid=EXTENSION_VERSION[fe35f6a8-8239-4bdb-ab1a-af9f779ce68c];]=1.0.0,
> Extkey[name=EXTENSION_MANAGER_TRACE_LOG;type=interface
> org.slf4j.Logger;uuid=EXTENSION_MANAGER_TRACE_LOG[863db666-3ea7-4751-9695-918a3197ad83];]=org.slf4j.impl.Slf4jLogger(
> org.ovirt.engine.core.extensions.mgr.ExtensionsManager.trace.ovirt-engine-extension-aaa-ldap.authn.authn-ldap.example.org),
> Extkey[name=EXTENSION_PROVIDES;type=interface
> java.util.Collection;uuid=EXTENSION_PROVIDES[8cf373a6-65b5-4594-b828-0e275087de91];]=[org.ovirt.engine.api.extensions.aaa.Authn]},
> Extkey[name=AAA_AUTHN_USER;type=class
> java.lang.String;uuid=AAA_AUTHN_USER[1ceaba26-1bdc-4663-a3c6-5d926f9dd8f0];]=bruno,
> Extkey[name=EXTENSION_INVOKE_COMMAND;type=class
> org.ovirt.engine.api.extensions.ExtUUID;uuid=EXTENSION_INVOKE_COMMAND[485778ab-bede-4f1a-b823-77b262a2f28d];]=AAA_AUTHN_AUTHENTICATE_CREDENTIALS[d9605c75-6b43-4b00-b32c-06bdfa80244c]}
> Output:
> {Extkey[name=EXTENSION_INVOKE_RESULT;type=class
> java.lang.Integer;uuid=EXTENSION_INVOKE_RESULT[0909d91d-8bde-40fb-b6c0-099c772ddd4e];]=2,
> Extkey[name=EXTENSION_INVOKE_MESSAGE;type=class
> java.lang.String;uuid=EXTENSION_INVOKE_MESSAGE[b7b053de-dc73-4bf7
Re: [ovirt-users] Error authenticating bind using the AAA OpenLDAP module
]: conn=1671350 op=0
RESULT oid= err=0 text=
/var/log/ldap.log:Jan 15 10:04:15 ldap1 slapd[6712]: conn=1671350 fd=114
TLS established tls_ssf=128 ssf=128
/var/log/ldap.log:Jan 15 10:04:15 ldap1 slapd[6712]: conn=1671350 op=1 BIND
dn="cn=authenticate,ou=System,dc=example,dc=org" method=128
/var/log/ldap.log:Jan 15 10:04:15 ldap1 slapd[6712]: conn=1671350 op=1 BIND
dn="cn=authenticate,ou=System,dc=example,dc=org" mech=SIMPLE ssf=0
/var/log/ldap.log:Jan 15 10:04:15 ldap1 slapd[6712]: conn=1671350 op=1
RESULT tag=97 err=0 text=
---
It looks like it got the dn correctly but it's unable to bind anyway ...
Thank you,
Bruno
On Wed, Jan 14, 2015 at 5:50 PM, Ondra Machacek wrote:
> Hi,
>
> On 01/14/2015 04:53 PM, Bruno Rodriguez wrote:
>
>> Good afternoon,
>>
>> We cannot access to Ovirt using LDAP authentication against our openldap
>> server. We created the following files in /etc/ovirt-engine/extensions.d
>> (the organization name is not example.org <http://example.org> and the
>> passwords are not , obviously) :
>>
>> --- /etc/ovirt-engine/extensions.d/ldap.example.org
>> <http://ldap.example.org> ---
>>
>> include =
>>
>> vars.server = ldap1.example.org <http://ldap1.example.org>
>> vars.user = cn=authenticate,ou=System,dc=example,dc=org
>> vars.password = ""
>>
>> pool.default.serverset.single.server = ${global:vars.server}
>> pool.default.auth.simple.bindDN = ${global:vars.user}
>> pool.default.auth.simple.password = ${global:vars.password}
>>
>> pool.default.ssl.startTLS = true
>> pool.default.ssl.truststore.file =
>> /etc/ovirt-engine/extensions.d/ldap.example.org_keystore.jks
>> pool.default.ssl.truststore.password =
>>
>> ---
>> /etc/ovirt-engine/extensions.d/authn-ldap.example.org.properties
>> ---
>>
>> ovirt.engine.extension.name <http://ovirt.engine.extension.name> =
>> authn-ldap.example.org <http://authn-ldap.example.org>
>> ovirt.engine.extension.bindings.method = jbossmodule
>> ovirt.engine.extension.binding.jbossmodule.module =
>> org.ovirt.engine-extensions.aaa.ldap
>> ovirt.engine.extension.binding.jbossmodule.class =
>> org.ovirt.engineextensions.aaa.ldap.AuthnExtension
>> ovirt.engine.extension.provides = org.ovirt.engine.api.
>> extensions.aaa.Authn
>>
>> ovirt.engine.aaa.authn.profile.name
>> <http://ovirt.engine.aaa.authn.profile.name> = ldap.example.org
>> <http://ldap.example.org>
>> ovirt.engine.aaa.authn.authz.plugin = authz-ldap.example.org
>> <http://authz-ldap.example.org>
>>
>> config.profile.file.1 = /etc/ovirt-engine/extensions.d/ldap.example.org
>> <http://ldap.example.org>
>>
>> ---
>> /etc/ovirt-engine/extensions.d/authz-ldap.example.org.properties
>> ---
>>
>> ovirt.engine.extension.name <http://ovirt.engine.extension.name> =
>> authz-ldap.example.org <http://authz-ldap.example.org>
>> ovirt.engine.extension.bindings.method = jbossmodule
>> ovirt.engine.extension.binding.jbossmodule.module =
>> org.ovirt.engine-extensions.aaa.ldap
>> ovirt.engine.extension.binding.jbossmodule.class =
>> org.ovirt.engineextensions.aaa.ldap.AuthzExtension
>>
>> ovirt.engine.extension.provides = org.ovirt.engine.api.
>> extensions.aaa.Authz
>> config.profile.file.1 = /etc/ovirt-engine/extensions.d/ldap.example.org
>> <http://ldap.example.org>
>>
>>
>>
>> After all of this we restarted the service and tried to access via the
>> administration portal. The JKS has the right permissions and contains
>> the TLS CA, the password is correct and the user "esthera" exists. But
>> when we try to log in, we obtain the following error in the engine.log
>> (we already set the verbosity to ALL):
>>
>>
>>
>> 2015-01-14 16:35:25,750 ERROR
>> [org.ovirt.engine.core.bll.aaa.LoginAdminUserCommand]
>> (ajp--127.0.0.1-8702-6) Error during CanDoActionFailure.: Class: class
>> org.ovirt.engine.core.extensions.mgr.ExtensionInvokeCommandFailedEx
>> ception
>> Input:
>> {Extkey[name=AAA_AUTHN_CREDENTIALS;type=class
>> java.lang.String;uuid=AAA_AUTHN_CREDENTIALS[03b96485-
>> 4bb5-4592-8167-810a5c909706];]=***,
>> Extkey[name=EXTENSION_INVOKE_CONTEXT;type=class
>> org.ovirt.engine.api.extensions.ExtMap;uuid=EXTENSION_INVOKE_CONTEXT[
>> 886d2ebb-312a-49ae-9cc3-e1f849834b7d
Re: [ovirt-users] Error authenticating bind using the AAA OpenLDAP module
Thank you very much for the fast reply !
I grepped "org.ovirt.engineextensions.aaa.ldap" in the engine log file, but
I wasn't able to get enough information for me to know which was the
problem...
2015-01-14 16:04:18,575 INFO
[org.ovirt.engineextensions.aaa.ldap.Framework] (MSC service thread 1-3)
[ovirt-engine-extension-aaa-ldap.authz::authz-ldap.example.org] Creating
LDAP pool 'authz'
2015-01-14 16:04:18,648 ERROR
[org.ovirt.engineextensions.aaa.ldap.AuthzExtension] (MSC service thread
1-3) [ovirt-engine-extension-aaa-ldap.authz::authz-ldap.example.org] Cannot
initialize LDAP framework, deferring initialization. Error: invalid
credentials
2015-01-14 16:04:36,913 INFO
[org.ovirt.engineextensions.aaa.ldap.Framework] (ajp--127.0.0.1-8702-2)
[ovirt-engine-extension-aaa-ldap.authn::authn-ldap.example.org] Creating
LDAP pool 'authz'
2015-01-14 16:08:34,521 INFO
[org.ovirt.engineextensions.aaa.ldap.Framework] (ajp--127.0.0.1-8702-1)
[ovirt-engine-extension-aaa-ldap.authn::authn-ldap.example.org] Creating
LDAP pool 'authz'
2015-01-14 16:35:25,670 INFO
[org.ovirt.engineextensions.aaa.ldap.Framework] (ajp--127.0.0.1-8702-6)
[ovirt-engine-extension-aaa-ldap.authn::authn-ldap.example.org] Creating
LDAP pool 'authz'
2015-01-14 17:44:19,769 INFO
[org.ovirt.engineextensions.aaa.ldap.Framework] (MSC service thread 1-4)
[ovirt-engine-extension-aaa-ldap.authn::authn-ldap.example.org] Creating
LDAP pool 'authz'
2015-01-14 17:44:20,096 ERROR
[org.ovirt.engineextensions.aaa.ldap.AuthnExtension] (MSC service thread
1-4) [ovirt-engine-extension-aaa-ldap.authn::authn-ldap.example.org] Cannot
initialize LDAP framework, deferring initialization. Error: invalid
credentials
2015-01-14 17:44:20,105 INFO
[org.ovirt.engineextensions.aaa.ldap.Framework] (MSC service thread 1-4)
[ovirt-engine-extension-aaa-ldap.authz::authz-ldap.example.org] Creating
LDAP pool 'authz'
2015-01-14 17:44:20,178 ERROR
[org.ovirt.engineextensions.aaa.ldap.AuthzExtension] (MSC service thread
1-4) [ovirt-engine-extension-aaa-ldap.authz::authz-ldap.example.org] Cannot
initialize LDAP framework, deferring initialization. Error: invalid
credentials
Thanks again.
On Wed, Jan 14, 2015 at 5:08 PM, Alon Bar-Lev wrote:
> Hi!
>
> Great information!
>
> I really need you to add the log for org.ovirt.engineextensions.aaa.ldap,
> see [1] so I can see the entire sequence.
>
> You are trying to authenticate the esthera user, this result in bind
> request using this user, so you should really try to see if bind succeeds
> with this user and passwod.
>
> $ ldapsearch -ZZ -D replace_with_esthera_DN -W -b 'dc=example,dc=org'
>
> It may be that the password of the user is not set or different than what
> you expect, or the schema is not openldap but rfc2307.
>
> Alon
>
> [1]
> http://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob;f=README;hb=HEAD#l270
>
> - Original Message -
> > From: "Bruno Rodriguez"
> > To: users@ovirt.org, "Esther Accion"
> > Sent: Wednesday, January 14, 2015 5:53:06 PM
> > Subject: [ovirt-users] Error authenticating bind using the AAA OpenLDAP
> module
> >
> > Good afternoon,
> >
> > We cannot access to Ovirt using LDAP authentication against our openldap
> > server. We created the following files in /etc/ovirt-engine/extensions.d
> > (the organization name is not example.org and the passwords are not
> > , obviously) :
> >
> > --- /etc/ovirt-engine/extensions.d/ ldap.example.org ---
> >
> > include =
> >
> > vars.server = ldap1.example.org
> > vars.user = cn=authenticate,ou=System,dc=example,dc=org
> > vars.password = ""
> >
> > pool.default.serverset.single.server = ${global:vars.server}
> > pool.default.auth.simple.bindDN = ${global:vars.user}
> > pool.default.auth.simple.password = ${global:vars.password}
> >
> > pool.default.ssl.startTLS = true
> > pool.default.ssl.truststore.file =
> > /etc/ovirt-engine/extensions.d/ldap.example.org_keystore.jks
> > pool.default.ssl.truststore.password =
> >
> > ---
> /etc/ovirt-engine/extensions.d/authn-ldap.example.org.properties
> > ---
> >
> > ovirt.engine.extension.name = authn-ldap.example.org
> > ovirt.engine.extension.bindings.method = jbossmodule
> > ovirt.engine.extension.binding.jbossmodule.module =
> > org.ovirt.engine-extensions.aaa.ldap
> > ovirt.engine.extension.binding.jbossmodule.class =
> > org.ovirt.engineextensions.aaa.ldap.AuthnExtension
> > ovirt.engine.extension.provides =
> org.ovirt.engine.api.extensions.aaa.Authn
>
[ovirt-users] Error authenticating bind using the AAA OpenLDAP module
Good afternoon,
We cannot access to Ovirt using LDAP authentication against our openldap
server. We created the following files in /etc/ovirt-engine/extensions.d
(the organization name is not example.org and the passwords are not
, obviously) :
--- /etc/ovirt-engine/extensions.d/ldap.example.org ---
include =
vars.server = ldap1.example.org
vars.user = cn=authenticate,ou=System,dc=example,dc=org
vars.password = ""
pool.default.serverset.single.server = ${global:vars.server}
pool.default.auth.simple.bindDN = ${global:vars.user}
pool.default.auth.simple.password = ${global:vars.password}
pool.default.ssl.startTLS = true
pool.default.ssl.truststore.file =
/etc/ovirt-engine/extensions.d/ldap.example.org_keystore.jks
pool.default.ssl.truststore.password =
---
/etc/ovirt-engine/extensions.d/authn-ldap.example.org.properties ---
ovirt.engine.extension.name = authn-ldap.example.org
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module =
org.ovirt.engine-extensions.aaa.ldap
ovirt.engine.extension.binding.jbossmodule.class =
org.ovirt.engineextensions.aaa.ldap.AuthnExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn
ovirt.engine.aaa.authn.profile.name = ldap.example.org
ovirt.engine.aaa.authn.authz.plugin = authz-ldap.example.org
config.profile.file.1 = /etc/ovirt-engine/extensions.d/ldap.example.org
---
/etc/ovirt-engine/extensions.d/authz-ldap.example.org.properties ---
ovirt.engine.extension.name = authz-ldap.example.org
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module =
org.ovirt.engine-extensions.aaa.ldap
ovirt.engine.extension.binding.jbossmodule.class =
org.ovirt.engineextensions.aaa.ldap.AuthzExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz
config.profile.file.1 = /etc/ovirt-engine/extensions.d/ldap.example.org
After all of this we restarted the service and tried to access via the
administration portal. The JKS has the right permissions and contains the
TLS CA, the password is correct and the user "esthera" exists. But when we
try to log in, we obtain the following error in the engine.log (we already
set the verbosity to ALL):
2015-01-14 16:35:25,750 ERROR
[org.ovirt.engine.core.bll.aaa.LoginAdminUserCommand]
(ajp--127.0.0.1-8702-6) Error during CanDoActionFailure.: Class: class
org.ovirt.engine.core.extensions.mgr.ExtensionInvokeCommandFailedException
Input:
{Extkey[name=AAA_AUTHN_CREDENTIALS;type=class java.lang.String;uuid=AAA_
AUTHN_CREDENTIALS[03b96485-4bb5-4592-8167-810a5c909706];]=***,
Extkey[name=EXTENSION_INVOKE_CONTEXT;type=class org.ovirt.engine.api.
extensions.ExtMap;uuid=EXTENSION_INVOKE_CONTEXT[886d2ebb-312a-49ae-9cc3-
e1f849834b7d];]={Extkey[name=EXTENSION_INTERFACE_VERSION_MAX;type=class
java.lang.Integer;uuid=EXTENSION_INTERFACE_VERSION_
MAX[f4cff49f-2717-4901-8ee9-df362446e3e7];]=0,
Extkey[name=EXTENSION_LICENSE;type=class java.lang.String;uuid=
EXTENSION_LICENSE[8a61ad65-054c-4e31-9c6d-1ca4d60a4c18];]=ASL 2.0,
Extkey[name=EXTENSION_NOTES;type=class java.lang.String;uuid=
EXTENSION_NOTES[2da5ad7e-185a-4584-aaff-97f66978e4ea];]=Display name:
ovirt-engine-extension-aaa-ldap-1.0.0-1.el6,
Extkey[name=EXTENSION_HOME_URL;type=class
java.lang.String;uuid=EXTENSION_HOME_URL[4ad7a2f4-
f969-42d4-b399-72d192e18304];]=http://www.ovirt.org,
Extkey[name=EXTENSION_LOCALE;type=class java.lang.String;uuid=
EXTENSION_LOCALE[0780b112-0ce0-404a-b85e-8765d778bb29];]=en_US,
Extkey[name=EXTENSION_NAME;type=class java.lang.String;uuid=
EXTENSION_NAME[651381d3-f54f-4547-bf28-b0b01a103184];]=
ovirt-engine-extension-aaa-ldap.authn, Extkey[name=EXTENSION_
INTERFACE_VERSION_MIN;type=class java.lang.Integer;uuid=
EXTENSION_INTERFACE_VERSION_MIN[2b84fc91-305b-497b-a1d7-d961b9d2ce0b];]=0,
Extkey[name=EXTENSION_CONFIGURATION;type=class java.util.Properties;uuid=
EXTENSION_CONFIGURATION[2d48ab72-f0a1-4312-b4ae-5068a226b0fc];]=***,
Extkey[name=EXTENSION_AUTHOR;type=class java.lang.String;uuid=
EXTENSION_AUTHOR[ef242f7a-2dad-4bc5-9aad-e07018b7fbcc];]=The oVirt Project,
Extkey[name=EXTENSION_INSTANCE_NAME;type=class java.lang.String;uuid=
EXTENSION_INSTANCE_NAME[65c67ff6-aeca-4bd5-a245-8674327f011b];]=authn-ldap.
