- Users - oVirt List Archives

python sdk create vm to specific target storage domain from template
by Dobó László 28 Mar '16

28 Mar '16

Hi, Here is one of my system setup: Data Centers dc01 Storage storagedomain01 storagedomain02 storagedomain03 Clusters cl01 When i making vm from template on webgui, under the resource allocation i can choose which target storagedomain like to provision. The question is how can i set this target parameter when i'm using python sdk for vm creation? regards enax

2 1

Re: [ovirt-users] ovirt - unsupported GFS config ??
by Sahina Bose 28 Mar '16

28 Mar '16

This is a multi-part message in MIME format. --------------060409020502060901040200 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 03/27/2016 10:24 PM, paf1(a)email.cz wrote: > What's the recommended shard size for databases ( espacially Oracle ) > , I'm afraid that 512M is too large. > I found that someones using about 16MB , but it generate a lot of > files for healing if volumes splitted. (eg. for 500GB DB in worse case ) Would the database be running within the guest VM? Did you run into any specific issue with 512M shard size? What we have noticed is that with smaller shard sizes , like 4MB, the number of entries in the .shard directory is too high, and hence affects the performance when it comes to healing entries in directory. The 256M/512M shard size is a good balance between the number of entries created and data size to heal. > > Pa. > > On 27.3.2016 16:57, Sahina Bose wrote: >> Stripe is not supported. >> >> What you need to do instead is turn on sharding for the volume. >> >> So: >> >> gluster volume create 12HP12-S2R3A1P2 replica 3 arbiter 1 >> 1hp1:/STORAGES/P2/GFS 1hp2:/STORAGES/P2/GFS >> kvmarbiter:/STORAGES/P2-1/GFS force >> >> gluster volume set 12HP12-S2R3A1P2 features.shard on >> gluster volume set 12HP12-S2R3A1P2 features.shard-block-size 512MB >> >> If you want to utilize the additional nodes as well, you can change >> this to a distributed replicate volume - instead of the volume >> creation in step above , use below >> >> gluster volume create 12HP12-S2R3A1P2 replica 3 arbiter 1 >> 1hp1:/STORAGES/P2/GFS 1hp2:/STORAGES/P2/GFS >> kvmarbiter:/STORAGES/P2-1/GFS 2hp1:/STORAGES/P2/GFS >> 2hp2:/STORAGES/P2/GFS kvmarbiter:/STORAGES/P2-2/GFS force >> >> >> On 03/24/2016 07:49 PM, paf1(a)email.cz wrote: >>> Hello, >>> I tried create stripe 2 replica 3 arbiter1 gluster volume for testing. >>> So , glusterFS such type from commandline was successfull, but >>> domain creation looks to be unsupported. with oVirt message "Error >>> while executing action AddGlusterFsStorageDomain: Storage Domain >>> target is unsupported". >>> Cam U tell me if is it error or really unsuported ?? >>> >>> exam: >>> gluster volume create 12HP12-S2R3A1P2 stripe 2 replica 3 arbiter 1 >>> 1hp1:/STORAGES/P2/GFS 1hp2:/STORAGES/P2/GFS >>> kvmarbiter:/STORAGES/P2-1/GFS 2hp1:/STORAGES/P2/GFS >>> 2hp2:/STORAGES/P2/GFS kvmarbiter:/STORAGES/P2-2/GFS force >>> >>> >>> RHEL 7-2.1511 >>> vdsm - vdsm-4.17.23-1.el7 >>> gluster - glusterfs-3.7.9-1.el7 >>> ovirt - 3.5.6.2-1 >>> >>> regs.Pavel >>> >>> >>> _______________________________________________ >>> Users mailing list >>> Users(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/users >> > --------------060409020502060901040200 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit <html> <head> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#FFFFFF"> <br> <br> <br> <div class="moz-cite-prefix">On 03/27/2016 10:24 PM, <a class="moz-txt-link-abbreviated" href="mailto:paf1@email.cz">paf1(a)email.cz</a> wrote:<br> </div> <blockquote cite="mid:56F81046.3070200@email.cz" type="cite"> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> What's the recommended shard size for databases ( espacially Oracle ) , I'm afraid that 512M is too large.<br> I found that someones using about 16MB , but it generate a lot of files for healing if volumes splitted. (eg. for 500GB DB in worse case )<br> </blockquote> <br> Would the database be running within the guest VM?<br> <br> Did you run into any specific issue with 512M shard size?<br> What we have noticed is that with smaller shard sizes , like 4MB, the number of entries in the .shard directory is too high, and hence affects the performance when it comes to healing entries in directory. The 256M/512M shard size is a good balance between the number of entries created and data size to heal.<br> <br> <blockquote cite="mid:56F81046.3070200@email.cz" type="cite"> <br> Pa.<br> <br> <div class="moz-cite-prefix">On 27.3.2016 16:57, Sahina Bose wrote:<br> </div> <blockquote cite="mid:56F7F4C0.2020408@redhat.com" type="cite"> <meta content="text/html; charset=windows-1252" http-equiv="Content-Type"> Stripe is not supported.<br> <br> What you need to do instead is turn on sharding for the volume.<br> <br> So:<br> <br> gluster volume create 12HP12-S2R3A1P2 replica 3 arbiter 1 1hp1:/STORAGES/P2/GFS 1hp2:/STORAGES/P2/GFS kvmarbiter:/STORAGES/P2-1/GFS force<br> <br> gluster volume set 12HP12-S2R3A1P2 features.shard on<br> gluster volume set 12HP12-S2R3A1P2 features.shard-block-size 512MB<br> <br> If you want to utilize the additional nodes as well, you can change this to a distributed replicate volume - instead of the volume creation in step above , use below<br> <br> gluster volume create 12HP12-S2R3A1P2 replica 3 arbiter 1 1hp1:/STORAGES/P2/GFS 1hp2:/STORAGES/P2/GFS kvmarbiter:/STORAGES/P2-1/GFS 2hp1:/STORAGES/P2/GFS 2hp2:/STORAGES/P2/GFS kvmarbiter:/STORAGES/P2-2/GFS force<br> <br> <br> <div class="moz-cite-prefix">On 03/24/2016 07:49 PM, <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:paf1@email.cz"><a class="moz-txt-link-abbreviated" href="mailto:paf1@email.cz">paf1(a)email.cz</a></a> wrote:<br> </div> <blockquote cite="mid:56F3F75D.8060201@email.cz" type="cite"> <meta http-equiv="content-type" content="text/html; charset=windows-1252"> Hello, <br> I tried create stripe 2 replica 3 arbiter1 gluster volume for testing.<br> So , glusterFS such type from commandline was successfull, but domain creation looks to be unsupported. with oVirt message "Error while executing action AddGlusterFsStorageDomain: Storage Domain target is unsupported".<br> Cam U tell me if is it error or really unsuported ??<br> <br> exam: <br> gluster volume create 12HP12-S2R3A1P2 stripe 2 replica 3 arbiter 1 1hp1:/STORAGES/P2/GFS 1hp2:/STORAGES/P2/GFS kvmarbiter:/STORAGES/P2-1/GFS 2hp1:/STORAGES/P2/GFS 2hp2:/STORAGES/P2/GFS kvmarbiter:/STORAGES/P2-2/GFS force<br> <br> <br> RHEL 7-2.1511<br> vdsm - vdsm-4.17.23-1.el7<br> gluster - glusterfs-3.7.9-1.el7<br> ovirt - 3.5.6.2-1<br> <br> regs.Pavel<br> <br> <fieldset class="mimeAttachmentHeader"></fieldset> <br> <pre wrap="">_______________________________________________ Users mailing list <a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:Users@ovirt.org">Users(a)ovirt.org</a> <a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.ovirt.org/mailman/listinfo/users">http://lists.ovirt.org/mailman/listinfo/users</a> </pre> </blockquote> <br> </blockquote> <br> </blockquote> <br> </body> </html> --------------060409020502060901040200--

2 1

engine.log messages in cycle
by paf1＠email.cz 27 Mar '16

27 Mar '16

This is a multi-part message in MIME format. --------------000109010407050908020106 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello, can anybody explain why is engine.log filled with following messages, even thought this is fresh installation ?? Especially START / FINISH rows in cycle, ... in cycle, .... in cycle ???? - it takes a lot of space and is really needed ?? RHEL 7-2.1511 vdsm - vdsm-4.17.23-1.el7 gluster - glusterfs-3.7.9-1.el7 ovirt - 3.5.6.2-1 regs.Pavel 2016-03-24 13:39:10,758 INFO [org.ovirt.engine.core.vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand] (DefaultQuartzScheduler_Worker-89) START, GetGlusterVolumeAdvancedDetailsVDSCommand(HostName = 2hp1, HostId = 45f76a0f-9616-420a-be1d-afbed2954562), log id: 3d6b27fd 2016-03-24 13:39:13,243 INFO [org.ovirt.engine.core.vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand] (DefaultQuartzScheduler_Worker-89) FINISH, GetGlusterVolumeAdvancedDetailsVDSCommand, return: org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeAdvancedDetails@11d55805, log id: 3d6b27fd 2016-03-24 13:39:13,278 INFO [org.ovirt.engine.core.vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand] (DefaultQuartzScheduler_Worker-89) START, GetGlusterVolumeAdvancedDetailsVDSCommand(HostName = 2hp1, HostId = 45f76a0f-9616-420a-be1d-afbed2954562), log id: 3ae0e479 2016-03-24 13:39:13,349 INFO [org.ovirt.engine.core.bll.lock.InMemoryLockManager] (DefaultQuartzScheduler_Worker-43) Failed to acquire lock and wait lock EngineLock [exclusiveLocks= key: 00000001-0001-0001-0001-00000000022e value: GLUSTER , sharedLocks= ] 2016-03-24 13:39:13,444 INFO [org.ovirt.engine.core.bll.lock.InMemoryLockManager] (DefaultQuartzScheduler_Worker-43) Failed to acquire lock and wait lock EngineLock [exclusiveLocks= key: 00000001-0001-0001-0001-00000000022e value: GLUSTER , sharedLocks= ] 2016-03-24 13:39:13,801 INFO [org.ovirt.engine.core.bll.lock.InMemoryLockManager] (DefaultQuartzScheduler_Worker-43) Failed to acquire lock and wait lock EngineLock [exclusiveLocks= key: 00000001-0001-0001-0001-00000000022e value: GLUSTER , sharedLocks= ] 2016-03-24 13:39:14,646 INFO [org.ovirt.engine.core.bll.lock.InMemoryLockManager] (DefaultQuartzScheduler_Worker-43) Failed to acquire lock and wait lock EngineLock [exclusiveLocks= key: 00000001-0001-0001-0001-00000000022e value: GLUSTER , sharedLocks= ] 2016-03-24 13:39:15,630 INFO [org.ovirt.engine.core.vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand] (DefaultQuartzScheduler_Worker-89) FINISH, GetGlusterVolumeAdvancedDetailsVDSCommand, return: org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeAdvancedDetails@cab5100f, log id: 3ae0e479 2016-03-24 13:39:15,656 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand] (DefaultQuartzScheduler_Worker-43) START, GlusterVolumesListVDSCommand(HostName = 1hp2, HostId = 184ebfaa-51a9-43e4-a57b-9d4f03e85b47), log id: 5756f325 2016-03-24 13:39:16,105 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand] (DefaultQuartzScheduler_Worker-43) FINISH, GlusterVolumesListVDSCommand, return: {e4121610-6128-4ecc-86d3-1429ab3b8356=org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeEntity@edd4741e, d3d260cd-455f-42d6-9580-d88ae6df0519=org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeEntity@84ea7412}, log id: 5756f325 2016-03-24 13:39:21,161 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand] (DefaultQuartzScheduler_Worker-81) START, GlusterVolumesListVDSCommand(HostName = 1hp2, HostId = 184ebfaa-51a9-43e4-a57b-9d4f03e85b47), log id: 6e2f6c69 2016-03-24 13:39:21,667 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand] (DefaultQuartzScheduler_Worker-81) FINISH, GlusterVolumesListVDSCommand, return: {e4121610-6128-4ecc-86d3-1429ab3b8356=org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeEntity@2ad03bfa, d3d260cd-455f-42d6-9580-d88ae6df0519=org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeEntity@6a99fa09}, log id: 6e2f6c69 --------------000109010407050908020106 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000066" bgcolor="#FFFFFF"> Hello, <br> can anybody explain why is engine.log filled with following messages, even thought this is fresh installation ??<br> Especially START / FINISH rows in cycle, ... in cycle, .... in cycle ???? - it takes a lot of space and is really needed ??<br> <br> RHEL 7-2.1511<br> vdsm - vdsm-4.17.23-1.el7<br> gluster - glusterfs-3.7.9-1.el7<br> ovirt - 3.5.6.2-1<br> <br> regs.Pavel<br> <br> <br> 2016-03-24 13:39:10,758 INFO [org.ovirt.engine.core.vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand] (DefaultQuartzScheduler_Worker-89) START, GetGlusterVolumeAdvancedDetailsVDSCommand(HostName = 2hp1, HostId = 45f76a0f-9616-420a-be1d-afbed2954562), log id: 3d6b27fd<br> 2016-03-24 13:39:13,243 INFO [org.ovirt.engine.core.vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand] (DefaultQuartzScheduler_Worker-89) FINISH, GetGlusterVolumeAdvancedDetailsVDSCommand, return: org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeAdvancedDetails@11d55805, log id: 3d6b27fd<br> 2016-03-24 13:39:13,278 INFO [org.ovirt.engine.core.vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand] (DefaultQuartzScheduler_Worker-89) START, GetGlusterVolumeAdvancedDetailsVDSCommand(HostName = 2hp1, HostId = 45f76a0f-9616-420a-be1d-afbed2954562), log id: 3ae0e479<br> 2016-03-24 13:39:13,349 INFO [org.ovirt.engine.core.bll.lock.InMemoryLockManager] (DefaultQuartzScheduler_Worker-43) Failed to acquire lock and wait lock EngineLock [exclusiveLocks= key: 00000001-0001-0001-0001-00000000022e value: GLUSTER<br> , sharedLocks= ]<br> 2016-03-24 13:39:13,444 INFO [org.ovirt.engine.core.bll.lock.InMemoryLockManager] (DefaultQuartzScheduler_Worker-43) Failed to acquire lock and wait lock EngineLock [exclusiveLocks= key: 00000001-0001-0001-0001-00000000022e value: GLUSTER<br> , sharedLocks= ]<br> 2016-03-24 13:39:13,801 INFO [org.ovirt.engine.core.bll.lock.InMemoryLockManager] (DefaultQuartzScheduler_Worker-43) Failed to acquire lock and wait lock EngineLock [exclusiveLocks= key: 00000001-0001-0001-0001-00000000022e value: GLUSTER<br> , sharedLocks= ]<br> 2016-03-24 13:39:14,646 INFO [org.ovirt.engine.core.bll.lock.InMemoryLockManager] (DefaultQuartzScheduler_Worker-43) Failed to acquire lock and wait lock EngineLock [exclusiveLocks= key: 00000001-0001-0001-0001-00000000022e value: GLUSTER<br> , sharedLocks= ]<br> 2016-03-24 13:39:15,630 INFO [org.ovirt.engine.core.vdsbroker.gluster.GetGlusterVolumeAdvancedDetailsVDSCommand] (DefaultQuartzScheduler_Worker-89) FINISH, GetGlusterVolumeAdvancedDetailsVDSCommand, return: org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeAdvancedDetails@cab5100f, log id: 3ae0e479<br> 2016-03-24 13:39:15,656 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand] (DefaultQuartzScheduler_Worker-43) START, GlusterVolumesListVDSCommand(HostName = 1hp2, HostId = 184ebfaa-51a9-43e4-a57b-9d4f03e85b47), log id: 5756f325<br> 2016-03-24 13:39:16,105 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand] (DefaultQuartzScheduler_Worker-43) FINISH, GlusterVolumesListVDSCommand, return: {e4121610-6128-4ecc-86d3-1429ab3b8356=org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeEntity@edd4741e, d3d260cd-455f-42d6-9580-d88ae6df0519=org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeEntity@84ea7412}, log id: 5756f325<br> 2016-03-24 13:39:21,161 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand] (DefaultQuartzScheduler_Worker-81) START, GlusterVolumesListVDSCommand(HostName = 1hp2, HostId = 184ebfaa-51a9-43e4-a57b-9d4f03e85b47), log id: 6e2f6c69<br> 2016-03-24 13:39:21,667 INFO [org.ovirt.engine.core.vdsbroker.gluster.GlusterVolumesListVDSCommand] (DefaultQuartzScheduler_Worker-81) FINISH, GlusterVolumesListVDSCommand, return: {e4121610-6128-4ecc-86d3-1429ab3b8356=org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeEntity@2ad03bfa, d3d260cd-455f-42d6-9580-d88ae6df0519=org.ovirt.engine.core.common.businessentities.gluster.GlusterVolumeEntity@6a99fa09}, log id: 6e2f6c69<br> <br> </body> </html> --------------000109010407050908020106--

2 1

ovirt - unsupported GFS config ??
by paf1＠email.cz 27 Mar '16

27 Mar '16

This is a multi-part message in MIME format. --------------060206050809050705030905 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hello, I tried create stripe 2 replica 3 arbiter1 gluster volume for testing. So , glusterFS such type from commandline was successfull, but domain creation looks to be unsupported. with oVirt message "Error while executing action AddGlusterFsStorageDomain: Storage Domain target is unsupported". Cam U tell me if is it error or really unsuported ?? exam: gluster volume create 12HP12-S2R3A1P2 stripe 2 replica 3 arbiter 1 1hp1:/STORAGES/P2/GFS 1hp2:/STORAGES/P2/GFS kvmarbiter:/STORAGES/P2-1/GFS 2hp1:/STORAGES/P2/GFS 2hp2:/STORAGES/P2/GFS kvmarbiter:/STORAGES/P2-2/GFS force RHEL 7-2.1511 vdsm - vdsm-4.17.23-1.el7 gluster - glusterfs-3.7.9-1.el7 ovirt - 3.5.6.2-1 regs.Pavel --------------060206050809050705030905 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000066" bgcolor="#FFFFFF"> Hello, <br> I tried create stripe 2 replica 3 arbiter1 gluster volume for testing.<br> So , glusterFS such type from commandline was successfull, but domain creation looks to be unsupported. with oVirt message "Error while executing action AddGlusterFsStorageDomain: Storage Domain target is unsupported".<br> Cam U tell me if is it error or really unsuported ??<br> <br> exam: <br> gluster volume create 12HP12-S2R3A1P2 stripe 2 replica 3 arbiter 1 1hp1:/STORAGES/P2/GFS 1hp2:/STORAGES/P2/GFS kvmarbiter:/STORAGES/P2-1/GFS 2hp1:/STORAGES/P2/GFS 2hp2:/STORAGES/P2/GFS kvmarbiter:/STORAGES/P2-2/GFS force<br> <br> <br> RHEL 7-2.1511<br> vdsm - vdsm-4.17.23-1.el7<br> gluster - glusterfs-3.7.9-1.el7<br> ovirt - 3.5.6.2-1<br> <br> regs.Pavel<br> </body> </html> --------------060206050809050705030905--

2 1

Using REST API to get a proxyticket
by Ollie Armstrong 26 Mar '16

26 Mar '16

Hi all, I'm attempting to use the REST API to get a proxy ticket as BZ1181030 [0] has added support for, but I am unable to find _any_ documentation on how to use this new API call. All I've found is the git commit message in gerrit [1]. Not quite understanding how to interpret this, I've attempted to POST the following: <action/> As well as: <action> <proxy_ticket> <value>ticket_content</value> </proxy_ticket> </action> Both of these, and indeed using any other data I can think of, results in an NPE being logged in engine.log. I've uploaded my engine.log [2] which is produced when I POST "<action/>" to the endpoint. Is anyone able to tell me how to use this endpoint? I'm assuming I get the NPE because I'm not POSTing the correct data. The overall goal of this is to be able to embed a NoVNC console in our own web UI, this is the last piece of the puzzle for me to implement this. Thanks, Ollie [0] https://bugzilla.redhat.com/show_bug.cgi?id=1181030 [1] https://gerrit.ovirt.org/#/c/42412/ [2] http://ix.io/uVP

3 6

Re: [ovirt-users] oVirt 3.6 AAA LDAP cannot not log in when end of UPN is different from domain base
by Karli Sjöberg 25 Mar '16

25 Mar '16

--_000_b78ced6864174864b04ccacdb481eac8exch24sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMjQgbWFycyAyMDE2IDExOjI2IGVtIHNrcmV2IE9uZHJhIE1hY2hhY2VrIDxvbWFjaGFj ZUByZWRoYXQuY29tPjoNCj4NCj4gT24gMDMvMjQvMjAxNiAxMToxNCBQTSwgS2FybGkgU2rDtmJl cmcgd3JvdGU6DQo+ID4NCj4gPiBEZW4gMjQgbWFycyAyMDE2IDc6MjYgZW0gc2tyZXYgT25kcmEg TWFjaGFjZWsgPG9tYWNoYWNlQHJlZGhhdC5jb20+Og0KPiA+ICA+DQo+ID4gID4gT24gMDMvMjQv MjAxNiAwNjoxNiBQTSwgS2FybGkgU2rDtmJlcmcgd3JvdGU6DQo+ID4gID4gPiBIaSENCj4gPiAg PiA+DQo+ID4gID4gPg0KPiA+ICA+ID4gU3RhcnRpbmcgbmV3IHRocmVhZCBpbnN0ZWFkIG9mIGph Y2tpbmcgc29tZW9uZSBlbHNlwrRzLg0KPiA+ICA+ID4NCj4gPiAgPiA+DQo+ID4gID4gPiBNYW5h Z2VkIHRvIG1pZ3JhdGUgZnJvbSBvbGQgJ2VuZ2luZS1tYW5hZ2UtZG9tYWlucycgYXV0aCB0bw0K PiA+IGFhYS1sZGFwIHVzaW5nOg0KPiA+ICA+ID4NCj4gPiAgPiA+ICN8IG92aXJ0LWVuZ2luZS1r ZXJibGRhcC1taWdyYXRpb24tdG9vbCAtLWRvbWFpbiBiYXouZm9vLmJhciAtLWNhY2VydA0KPiA+ ICA+ID4gL3RtcC9jYS5jcnQgLS1hcHBseQ0KPiA+ICA+ID4gfA0KPiA+ICA+ID4NCj4gPiAgPiA+ DQo+ID4gID4gPiBBbGwgT0ssIG5vIGVycm9ycywgYnV0IGNhbm5vdCBsb2cgaW46DQo+ID4gID4g Pg0KPiA+ICA+ID4gIyBvdmlydC1lbmdpbmUtZXh0ZW5zaW9ucy10b29sIGFhYSBsb2dpbi11c2Vy IC0tcHJvZmlsZT1iYXouZm9vLmJhci1uZXcNCj4gPiAgPiA+IC0tdXNlci1uYW1lPXVzZXI6DQo+ ID4gID4NCj4gPiAgPiBJZiB5b3Ugd2FudCB0byBsb2dpbiB3aXRoIHVzZXIgd2l0aCBkaWZmZXJl bnQgdXBuIHN1ZmZpeCwgdGhlbiBqdXN0DQo+ID4gID4gYXBwZW5kIHRoYXQgc3VmZml4DQo+ID4g ID4NCj4gPiAgPiAkIG92aXJ0LWVuZ2luZS1leHRlbnNpb25zLXRvb2wgYWFhIGxvZ2luLXVzZXIg LS1wcm9maWxlPWJhei5mb28uYmFyLW5ldw0KPiA+ICA+IC0tdXNlci1uYW1lPXVzZXJAZm9vLmJh cg0KPiA+DQo+ID4gT0ssIHNvbWUgcHJvZ3Jlc3MsIHRoYXQgd29ya3MhDQo+ID4NCj4gPiAgPg0K PiA+ICA+IElmIHlvdSBoYXZlIG1vcmUgc3VmZml4ZXMgYW5kIHdhbnQgdG8gaGF2ZSBzb21lIGFz IGRlZmF1bHQgeW91IGNhbiB1c2UNCj4gPiAgPiBmb2xsb3dpbmcgYXBwcm9hY2g6DQo+ID4gID4N Cj4gPiAgPiAxKSBpbnN0YWxsIG92aXJ0LWVuZ2luZS1leHRlbnNpb24tYWFhLW1pc2MNCj4gPiAg Pg0KPiA+ICA+IDIpIGNyZWF0ZSBuZXcgbWFwcGluZyBleHRlbnNpb24gbGlrZSB0aGlzOg0KPiA+ ICA+IC9ldGMvb3ZpcnQtZW5naW5lL2V4dGVuc2lvbnMuZC9tYXBwaW5nLXN1ZmZpeC5wcm9wZXJ0 aWVzDQo+ID4gID4NCj4gPiAgPiBvdmlydC5lbmdpbmUuZXh0ZW5zaW9uLm5hbWUgPSBtYXBwaW5n LXN1ZmZpeA0KPiA+ICA+IG92aXJ0LmVuZ2luZS5leHRlbnNpb24uYmluZGluZ3MubWV0aG9kID0g amJvc3Ntb2R1bGUNCj4gPiAgPiBvdmlydC5lbmdpbmUuZXh0ZW5zaW9uLmJpbmRpbmcuamJvc3Nt b2R1bGUubW9kdWxlID0NCj4gPiAgPiBvcmcub3ZpcnQuZW5naW5lLWV4dGVuc2lvbnMuYWFhLm1p c2MNCj4gPiAgPiBvdmlydC5lbmdpbmUuZXh0ZW5zaW9uLmJpbmRpbmcuamJvc3Ntb2R1bGUuY2xh c3MgPQ0KPiA+ICA+IG9yZy5vdmlydC5lbmdpbmVleHRlbnNpb25zLmFhYS5taXNjLm1hcHBpbmcu TWFwcGluZ0V4dGVuc2lvbg0KPiA+ICA+IG92aXJ0LmVuZ2luZS5leHRlbnNpb24ucHJvdmlkZXMg PQ0KPiA+ICA+IG9yZy5vdmlydC5lbmdpbmUuYXBpLmV4dGVuc2lvbnMuYWFhLk1hcHBpbmcNCj4g PiAgPiBjb25maWcubWFwVXNlci50eXBlID0gcmVnZXgNCj4gPiAgPiBjb25maWcubWFwVXNlci5w YXR0ZXJuID0gXig/PHVzZXI+W15AXSopJA0KPiA+DQo+ID4gSXMgdGhhdCBzdXBwb3NlZCB0byBy ZWFsbHkgc2F5ICc8dXNlcj4nIG9yIHNob3VsZCBpdCBiZSBjaGFuZ2VkIHRvIGENCj4gPiByZWFs IHVzZXIgbmFtZT8gRWl0aGVyIHdheSwgaXQgZG9lc24ndCB3b3JrLCBJIHRyaWVkIGl0IGFsbC4N Cj4NCj4gJz88dXNlcj4nIGlzIGp1c3QgYSBuYW1lZCBncm91cCBpbiB0aGF0IHJlZ2V4IHNvIHlv dSBjYW4gbGF0ZXIgdXNlIGl0IGluDQo+ICdjb25maWcubWFwVXNlci5yZXBsYWNlbWVudCcgIG9w dGlvbi4gSXQgc2hvdWxkIHRha2UgZXZlcnl0aGluZyB1bnRpbA0KPiBmaXJzdCAnQCcuDQo+DQo+ ID4NCj4gPiAgPiBjb25maWcubWFwVXNlci5yZXBsYWNlbWVudCA9ICR7dXNlcn1AZm9vLmJhcg0K PiA+ICA+IGNvbmZpZy5tYXBVc2VyLm11c3RNYXRjaCA9IGZhbHNlDQo+ID4gID4NCj4gPiAgPiAz KSBzZWxlY3QgYSBtYXBwaW5nIHBsdWdpbiBpbiBhdXRobiBjb25maWd1cmF0aW9uOg0KPiA+ICA+ DQo+ID4gID4gb3ZpcnQuZW5naW5lLmFhYS5hdXRobi5tYXBwaW5nLnBsdWdpbiA9IG1hcHBpbmct c3VmZml4DQo+ID4gID4NCj4gPiAgPiBXaXRoIGFib3ZlIGNvbmZpZ3VyYXRpb24gaW4gdXNlLCB5 b3VyIHVzZXIgJ3VzZXInIHdpdGxsIGJlIG1hcHBlZCB0bw0KPiA+ICA+IHVzZXIgJ3VzZXJAZm9v LmJhcicNCj4gPiAgPiBhbmQgdXNlcnMgJ3VzZXJAYW5vdGhlcmRvbWFpbi5mb28uYmFyJyB3aWxs IHJlbWFpbg0KPiA+ICA+ICd1c2VyQGFub3RoZXJkb21haW4uZm9vLmJhcicuDQo+ID4NCj4gPiBU aGlzIGhvd2V2ZXIgZG9lcyBub3QsIGl0IGRvZXNuJ3QgcmVwbGFjZSB0aGUgc3VmZml4IGFzIGl0 J3Mgc3VwcG9zZWQNCj4gPiB0by4gSSB0cmllZCB3aXRoIG1hbnkgZGlmZmVyZW50IHR5cGVzIG9m IHRoZSAnbWFwVXNlci5wYXR0ZXJuJyBidXQgaXQNCj4gPiBzaW1wbHkgd29uJ3QgY2hhbmdlIGl0 LCBldmVuIGlmIEkgdHlwZSBpbiAnPSBedXNlckBiYXouZm9vLmJhciQnLCB0aGUNCj4gPiBlcnJv ciBpcyB0aGUgc2FtZTooDQo+DQo+IEhtbSwgaGFyZCB0byBzYXkgd2hhdCdzIHdyb25nLCB0cnkg dG8gcnVuOg0KPiAkIG92aXJ0LWVuZ2luZS1leHRlbnNpb25zLXRvb2wgLS1sb2ctbGV2ZWw9RklO RVNUIGFhYSBsb2dpbi11c2VyDQo+IC0tcHJvZmlsZT1iYXouZm9vLmJhci1uZXcgLS11c2VyLW5h bWU9dXNlcg0KPg0KPiBhbmQgc2VhcmNoIGZvciBhIG1hcHBpbmcgcGFydCBpbiBsb2cuDQoNCldv dyB3aGF0IGEgbW91dGhmdWxsOikgQ2FuIHlvdSBtYWtlIGFueXRoaW5nIG91dCBvZiBpdD8NCg0K aHR0cHM6Ly9kcm9wb2ZmLnNsdS5zZS9pbmRleC5waHAvcy9FTWUyTlBtT2ZzV0NOVHYvZG93bmxv YWQNCg0KL0sNCg0KPg0KPiA+DQo+ID4gL0sNCj4gPg0KPiA+ICA+DQo+ID4gID4gPg0KPiA+ICA+ ID4gQVBJOiA8LS1BdXRobi5JbnZva2VDb21tYW5kcy5BVVRIRU5USUNBVEVfQ1JFREVOVElBTFMg cmVzdWx0PVNVQ0NFU1MNCj4gPiAgPiA+DQo+ID4gID4gPg0KPiA+ICA+ID4gYnV0Og0KPiA+ICA+ ID4NCj4gPiAgPiA+IEFQSTogLS0+QXV0aHouSW52b2tlQ29tbWFuZHMuRkVUQ0hfUFJJTkNJUEFM X1JFQ09SRA0KPiA+ICA+ID4gcHJpbmNpcGFsPSd1c2VyQGJhei5mb28uYmFyJw0KPiA+ICA+ID4g U0VWRVJFICBDYW5ub3QgcmVzb2x2ZSBwcmluY2lwYWwgJ3VzZXJAYmF6LmZvby5iYXInDQo+ID4g ID4gPg0KPiA+ICA+ID4NCj4gPiAgPiA+IFNvIGl0IGZhaWxzLg0KPiA+ICA+ID4NCj4gPiAgPiA+ DQo+ID4gID4gPiAjIGxkYXBzZWFyY2ggLXggLUggbGRhcDovL2Jhei5mb28uYmFyIC1EIHVzZXJA Zm9vLmJhciAtVyAtYg0KPiA+ICA+ID4gREM9YmF6LERDPWZvbyxEQz1iYXIgLXMgc3ViICIoc2Ft QWNjb3VudE5hbWU9dXNlcikiIHVzZXJQcmluY2lwYWxOYW1lIHwNCj4gPiAgPiA+IGdyZXAgJ3Vz ZXJQcmluY2lwYWxOYW1lOicNCj4gPiAgPiA+DQo+ID4gID4gPiB1c2VyUHJpbmNpcGFsTmFtZTog dXNlckBmb28uYmFyDQo+ID4gID4gPg0KPiA+ICA+ID4NCj4gPiAgPiA+IHxIb3cgZG8geW91IGNv bmZpZ3VyZSBBQUEgd2l0aCBiYXNlICdEQz1iYXosREM9Zm9vLERDPWJhcicgd2hlbg0KPiA+ICA+ ID4gdXNlclByaW5jaXBhbE5hbWUgZW5kcyBvbmx5IG9uICdAZm9vLmJhcic/DQo+ID4gID4gPg0K PiA+ICA+ID4gL0sNCj4gPiAgPiA+IHwNCj4gPiAgPiA+DQo+ID4gID4gPg0KPiA+ICA+ID4NCj4g PiAgPiA+DQo+ID4gID4gPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KPiA+ICA+ID4gVXNlcnMgbWFpbGluZyBsaXN0DQo+ID4gID4gPiBVc2Vyc0Bvdmly dC5vcmcNCj4gPiAgPiA+IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91 c2Vycw0KPiA+ICA+ID4NCj4gPg0K --_000_b78ced6864174864b04ccacdb481eac8exch24sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <798DF3446B171847806BCF00AA9DD793(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAyNCBtYXJzIDIwMTYgMTE6MjYgZW0gc2tyZXYgT25kcmEgTWFjaGFjZWsgJmx0 O29tYWNoYWNlQHJlZGhhdC5jb20mZ3Q7Ojxicj4NCiZndDs8YnI+DQomZ3Q7IE9uIDAzLzI0LzIw MTYgMTE6MTQgUE0sIEthcmxpIFNqw7ZiZXJnIHdyb3RlOjxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyBEZW4gMjQgbWFycyAyMDE2IDc6MjYgZW0gc2tyZXYgT25kcmEgTWFjaGFjZWsgJmx0 O29tYWNoYWNlQHJlZGhhdC5jb20mZ3Q7Ojxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZndDsgT24gMDMvMjQvMjAxNiAwNjoxNiBQTSwgS2FybGkgU2rDtmJl cmcgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0OyBIaSE8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDsgU3RhcnRpbmcgbmV3IHRocmVhZCBpbnN0ZWFkIG9mIGph Y2tpbmcgc29tZW9uZSBlbHNlwrRzLjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0 OyBNYW5hZ2VkIHRvIG1pZ3JhdGUgZnJvbSBvbGQgJ2VuZ2luZS1tYW5hZ2UtZG9tYWlucycgYXV0 aCB0bzxicj4NCiZndDsgJmd0OyBhYWEtbGRhcCB1c2luZzo8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0OyAjfCBvdmlydC1lbmdpbmUt a2VyYmxkYXAtbWlncmF0aW9uLXRvb2wgLS1kb21haW4gYmF6LmZvby5iYXIgLS1jYWNlcnQ8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7IC90bXAvY2EuY3J0IC0tYXBwbHk8YnI+DQomZ3Q7 ICZndDsmbmJzcDsgJmd0OyAmZ3Q7IHw8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZn dDsgQWxsIE9LLCBubyBlcnJvcnMsIGJ1dCBjYW5ub3QgbG9nIGluOjxicj4NCiZndDsgJmd0OyZu YnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7ICMgb3ZpcnQtZW5n aW5lLWV4dGVuc2lvbnMtdG9vbCBhYWEgbG9naW4tdXNlciAtLXByb2ZpbGU9YmF6LmZvby5iYXIt bmV3PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0OyAtLXVzZXItbmFtZT11c2VyOjxicj4N CiZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgSWYgeW91IHdh bnQgdG8gbG9naW4gd2l0aCB1c2VyIHdpdGggZGlmZmVyZW50IHVwbiBzdWZmaXgsIHRoZW4ganVz dDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IGFwcGVuZCB0aGF0IHN1ZmZpeDxicj4NCiZndDsg Jmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJCBvdmlydC1lbmdpbmUt ZXh0ZW5zaW9ucy10b29sIGFhYSBsb2dpbi11c2VyIC0tcHJvZmlsZT1iYXouZm9vLmJhci1uZXc8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAtLXVzZXItbmFtZT11c2VyQGZvby5iYXI8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgT0ssIHNvbWUgcHJvZ3Jlc3MsIHRoYXQgd29ya3MhPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJmd0OyBJZiB5b3UgaGF2ZSBtb3JlIHN1ZmZpeGVzIGFuZCB3YW50IHRvIGhhdmUgc29tZSBh cyBkZWZhdWx0IHlvdSBjYW4gdXNlPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgZm9sbG93aW5n IGFwcHJvYWNoOjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsgMSkgaW5zdGFsbCBvdmlydC1lbmdpbmUtZXh0ZW5zaW9uLWFhYS1taXNjPGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAyKSBjcmVhdGUgbmV3 IG1hcHBpbmcgZXh0ZW5zaW9uIGxpa2UgdGhpczo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAv ZXRjL292aXJ0LWVuZ2luZS9leHRlbnNpb25zLmQvbWFwcGluZy1zdWZmaXgucHJvcGVydGllczxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgb3ZpcnQu ZW5naW5lLmV4dGVuc2lvbi5uYW1lID0gbWFwcGluZy1zdWZmaXg8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJmd0OyBvdmlydC5lbmdpbmUuZXh0ZW5zaW9uLmJpbmRpbmdzLm1ldGhvZCA9IGpib3NzbW9k dWxlPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgb3ZpcnQuZW5naW5lLmV4dGVuc2lvbi5iaW5k aW5nLmpib3NzbW9kdWxlLm1vZHVsZSA9PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgb3JnLm92 aXJ0LmVuZ2luZS1leHRlbnNpb25zLmFhYS5taXNjPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsg b3ZpcnQuZW5naW5lLmV4dGVuc2lvbi5iaW5kaW5nLmpib3NzbW9kdWxlLmNsYXNzID08YnI+DQom Z3Q7ICZndDsmbmJzcDsgJmd0OyBvcmcub3ZpcnQuZW5naW5lZXh0ZW5zaW9ucy5hYWEubWlzYy5t YXBwaW5nLk1hcHBpbmdFeHRlbnNpb248YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBvdmlydC5l bmdpbmUuZXh0ZW5zaW9uLnByb3ZpZGVzID08YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBvcmcu b3ZpcnQuZW5naW5lLmFwaS5leHRlbnNpb25zLmFhYS5NYXBwaW5nPGJyPg0KJmd0OyAmZ3Q7Jm5i c3A7ICZndDsgY29uZmlnLm1hcFVzZXIudHlwZSA9IHJlZ2V4PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsgY29uZmlnLm1hcFVzZXIucGF0dGVybiA9IF4oPyZsdDt1c2VyJmd0O1teQF0qKSQ8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSXMgdGhhdCBzdXBwb3NlZCB0byByZWFsbHkgc2F5 ICcmbHQ7dXNlciZndDsnIG9yIHNob3VsZCBpdCBiZSBjaGFuZ2VkIHRvIGE8YnI+DQomZ3Q7ICZn dDsgcmVhbCB1c2VyIG5hbWU/IEVpdGhlciB3YXksIGl0IGRvZXNuJ3Qgd29yaywgSSB0cmllZCBp dCBhbGwuPGJyPg0KJmd0Ozxicj4NCiZndDsgJz8mbHQ7dXNlciZndDsnIGlzIGp1c3QgYSBuYW1l ZCBncm91cCBpbiB0aGF0IHJlZ2V4IHNvIHlvdSBjYW4gbGF0ZXIgdXNlIGl0IGluPGJyPg0KJmd0 OyAnY29uZmlnLm1hcFVzZXIucmVwbGFjZW1lbnQnJm5ic3A7IG9wdGlvbi4gSXQgc2hvdWxkIHRh a2UgZXZlcnl0aGluZyB1bnRpbCA8YnI+DQomZ3Q7IGZpcnN0ICdAJy48YnI+DQomZ3Q7PGJyPg0K Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgY29uZmlnLm1hcFVzZXIucmVwbGFj ZW1lbnQgPSAke3VzZXJ9QGZvby5iYXI8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBjb25maWcu bWFwVXNlci5tdXN0TWF0Y2ggPSBmYWxzZTxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZndDsgMykgc2VsZWN0IGEgbWFwcGluZyBwbHVnaW4gaW4gYXV0aG4g Y29uZmlndXJhdGlvbjo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsgJmd0OyZu YnNwOyAmZ3Q7IG92aXJ0LmVuZ2luZS5hYWEuYXV0aG4ubWFwcGluZy5wbHVnaW4gPSBtYXBwaW5n LXN1ZmZpeDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsgV2l0aCBhYm92ZSBjb25maWd1cmF0aW9uIGluIHVzZSwgeW91ciB1c2VyICd1c2VyJyB3aXRs bCBiZSBtYXBwZWQgdG88YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyB1c2VyICd1c2VyQGZvby5i YXInPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgYW5kIHVzZXJzICd1c2VyQGFub3RoZXJkb21h aW4uZm9vLmJhcicgd2lsbCByZW1haW48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAndXNlckBh bm90aGVyZG9tYWluLmZvby5iYXInLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGlz IGhvd2V2ZXIgZG9lcyBub3QsIGl0IGRvZXNuJ3QgcmVwbGFjZSB0aGUgc3VmZml4IGFzIGl0J3Mg c3VwcG9zZWQ8YnI+DQomZ3Q7ICZndDsgdG8uIEkgdHJpZWQgd2l0aCBtYW55IGRpZmZlcmVudCB0 eXBlcyBvZiB0aGUgJ21hcFVzZXIucGF0dGVybicgYnV0IGl0PGJyPg0KJmd0OyAmZ3Q7IHNpbXBs eSB3b24ndCBjaGFuZ2UgaXQsIGV2ZW4gaWYgSSB0eXBlIGluICc9IF51c2VyQGJhei5mb28uYmFy JCcsIHRoZTxicj4NCiZndDsgJmd0OyBlcnJvciBpcyB0aGUgc2FtZTooPGJyPg0KJmd0Ozxicj4N CiZndDsgSG1tLCBoYXJkIHRvIHNheSB3aGF0J3Mgd3JvbmcsIHRyeSB0byBydW46PGJyPg0KJmd0 OyAkIG92aXJ0LWVuZ2luZS1leHRlbnNpb25zLXRvb2wgLS1sb2ctbGV2ZWw9RklORVNUIGFhYSBs b2dpbi11c2VyIDxicj4NCiZndDsgLS1wcm9maWxlPWJhei5mb28uYmFyLW5ldyAtLXVzZXItbmFt ZT11c2VyPGJyPg0KJmd0Ozxicj4NCiZndDsgYW5kIHNlYXJjaCBmb3IgYSBtYXBwaW5nIHBhcnQg aW4gbG9nLjwvcD4NCjxwIGRpcj0ibHRyIj5Xb3cgd2hhdCBhIG1vdXRoZnVsbDopIENhbiB5b3Ug bWFrZSBhbnl0aGluZyBvdXQgb2YgaXQ/PC9wPg0KPHAgZGlyPSJsdHIiPmh0dHBzOi8vZHJvcG9m Zi5zbHUuc2UvaW5kZXgucGhwL3MvRU1lMk5QbU9mc1dDTlR2L2Rvd25sb2FkPC9wPg0KPHAgZGly PSJsdHIiPi9LPC9wPg0KPHAgZGlyPSJsdHIiPiZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7 ICZndDsgL0s8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZn dDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7IEFQ STogJmx0Oy0tQXV0aG4uSW52b2tlQ29tbWFuZHMuQVVUSEVOVElDQVRFX0NSRURFTlRJQUxTIHJl c3VsdD1TVUNDRVNTPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0 OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7IGJ1dDo8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0 OyBBUEk6IC0tJmd0O0F1dGh6Lkludm9rZUNvbW1hbmRzLkZFVENIX1BSSU5DSVBBTF9SRUNPUkQ8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7IHByaW5jaXBhbD0ndXNlckBiYXouZm9vLmJh cic8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7IFNFVkVSRSZuYnNwOyBDYW5ub3QgcmVz b2x2ZSBwcmluY2lwYWwgJ3VzZXJAYmF6LmZvby5iYXInPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJmd0OyAmZ3Q7IFNvIGl0IGZhaWxzLjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsg Jmd0OyAjIGxkYXBzZWFyY2ggLXggLUggbGRhcDovL2Jhei5mb28uYmFyIC1EIHVzZXJAZm9vLmJh ciAtVyAtYjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDsgREM9YmF6LERDPWZvbyxEQz1i YXIgLXMgc3ViICZxdW90OyhzYW1BY2NvdW50TmFtZT11c2VyKSZxdW90OyB1c2VyUHJpbmNpcGFs TmFtZSB8PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0OyBncmVwICd1c2VyUHJpbmNpcGFs TmFtZTonPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNw OyAmZ3Q7ICZndDsgdXNlclByaW5jaXBhbE5hbWU6IHVzZXJAZm9vLmJhcjxicj4NCiZndDsgJmd0 OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0OyB8SG93IGRvIHlvdSBjb25maWd1cmUgQUFBIHdpdGggYmFz ZSAnREM9YmF6LERDPWZvbyxEQz1iYXInIHdoZW48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAm Z3Q7IHVzZXJQcmluY2lwYWxOYW1lIGVuZHMgb25seSBvbiAnQGZvby5iYXInPzxicj4NCiZndDsg Jmd0OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7IC9LPGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0OyB8PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsg Jmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZu YnNwOyAmZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX188YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7IFVzZXJzIG1haWxpbmcgbGlzdDxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDsgVXNlcnNAb3ZpcnQub3JnPGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZndDsgJmd0OyBodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGlu Zm8vdXNlcnM8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KPC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_b78ced6864174864b04ccacdb481eac8exch24sluse_--

1 0

Re: [ovirt-users] oVirt 3.6 AAA LDAP cannot not log in when end of UPN is different from domain base
by Karli Sjöberg 24 Mar '16

24 Mar '16

--_000_af85ac88d3754905aa58276556a94cceexch24sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMjQgbWFycyAyMDE2IDc6MjYgZW0gc2tyZXYgT25kcmEgTWFjaGFjZWsgPG9tYWNoYWNl QHJlZGhhdC5jb20+Og0KPg0KPiBPbiAwMy8yNC8yMDE2IDA2OjE2IFBNLCBLYXJsaSBTasO2YmVy ZyB3cm90ZToNCj4gPiBIaSENCj4gPg0KPiA+DQo+ID4gU3RhcnRpbmcgbmV3IHRocmVhZCBpbnN0 ZWFkIG9mIGphY2tpbmcgc29tZW9uZSBlbHNlwrRzLg0KPiA+DQo+ID4NCj4gPiBNYW5hZ2VkIHRv IG1pZ3JhdGUgZnJvbSBvbGQgJ2VuZ2luZS1tYW5hZ2UtZG9tYWlucycgYXV0aCB0byBhYWEtbGRh cCB1c2luZzoNCj4gPg0KPiA+ICN8IG92aXJ0LWVuZ2luZS1rZXJibGRhcC1taWdyYXRpb24tdG9v bCAtLWRvbWFpbiBiYXouZm9vLmJhciAtLWNhY2VydA0KPiA+IC90bXAvY2EuY3J0IC0tYXBwbHkN Cj4gPiB8DQo+ID4NCj4gPg0KPiA+IEFsbCBPSywgbm8gZXJyb3JzLCBidXQgY2Fubm90IGxvZyBp bjoNCj4gPg0KPiA+ICMgb3ZpcnQtZW5naW5lLWV4dGVuc2lvbnMtdG9vbCBhYWEgbG9naW4tdXNl ciAtLXByb2ZpbGU9YmF6LmZvby5iYXItbmV3DQo+ID4gLS11c2VyLW5hbWU9dXNlcjoNCj4NCj4g SWYgeW91IHdhbnQgdG8gbG9naW4gd2l0aCB1c2VyIHdpdGggZGlmZmVyZW50IHVwbiBzdWZmaXgs IHRoZW4ganVzdA0KPiBhcHBlbmQgdGhhdCBzdWZmaXgNCj4NCj4gJCBvdmlydC1lbmdpbmUtZXh0 ZW5zaW9ucy10b29sIGFhYSBsb2dpbi11c2VyIC0tcHJvZmlsZT1iYXouZm9vLmJhci1uZXcNCj4g LS11c2VyLW5hbWU9dXNlckBmb28uYmFyDQoNCk9LLCBzb21lIHByb2dyZXNzLCB0aGF0IHdvcmtz IQ0KDQo+DQo+IElmIHlvdSBoYXZlIG1vcmUgc3VmZml4ZXMgYW5kIHdhbnQgdG8gaGF2ZSBzb21l IGFzIGRlZmF1bHQgeW91IGNhbiB1c2UNCj4gZm9sbG93aW5nIGFwcHJvYWNoOg0KPg0KPiAxKSBp bnN0YWxsIG92aXJ0LWVuZ2luZS1leHRlbnNpb24tYWFhLW1pc2MNCj4NCj4gMikgY3JlYXRlIG5l dyBtYXBwaW5nIGV4dGVuc2lvbiBsaWtlIHRoaXM6DQo+IC9ldGMvb3ZpcnQtZW5naW5lL2V4dGVu c2lvbnMuZC9tYXBwaW5nLXN1ZmZpeC5wcm9wZXJ0aWVzDQo+DQo+IG92aXJ0LmVuZ2luZS5leHRl bnNpb24ubmFtZSA9IG1hcHBpbmctc3VmZml4DQo+IG92aXJ0LmVuZ2luZS5leHRlbnNpb24uYmlu ZGluZ3MubWV0aG9kID0gamJvc3Ntb2R1bGUNCj4gb3ZpcnQuZW5naW5lLmV4dGVuc2lvbi5iaW5k aW5nLmpib3NzbW9kdWxlLm1vZHVsZSA9DQo+IG9yZy5vdmlydC5lbmdpbmUtZXh0ZW5zaW9ucy5h YWEubWlzYw0KPiBvdmlydC5lbmdpbmUuZXh0ZW5zaW9uLmJpbmRpbmcuamJvc3Ntb2R1bGUuY2xh c3MgPQ0KPiBvcmcub3ZpcnQuZW5naW5lZXh0ZW5zaW9ucy5hYWEubWlzYy5tYXBwaW5nLk1hcHBp bmdFeHRlbnNpb24NCj4gb3ZpcnQuZW5naW5lLmV4dGVuc2lvbi5wcm92aWRlcyA9DQo+IG9yZy5v dmlydC5lbmdpbmUuYXBpLmV4dGVuc2lvbnMuYWFhLk1hcHBpbmcNCj4gY29uZmlnLm1hcFVzZXIu dHlwZSA9IHJlZ2V4DQo+IGNvbmZpZy5tYXBVc2VyLnBhdHRlcm4gPSBeKD88dXNlcj5bXkBdKikk DQoNCklzIHRoYXQgc3VwcG9zZWQgdG8gcmVhbGx5IHNheSAnPHVzZXI+JyBvciBzaG91bGQgaXQg YmUgY2hhbmdlZCB0byBhIHJlYWwgdXNlciBuYW1lPyBFaXRoZXIgd2F5LCBpdCBkb2Vzbid0IHdv cmssIEkgdHJpZWQgaXQgYWxsLg0KDQo+IGNvbmZpZy5tYXBVc2VyLnJlcGxhY2VtZW50ID0gJHt1 c2VyfUBmb28uYmFyDQo+IGNvbmZpZy5tYXBVc2VyLm11c3RNYXRjaCA9IGZhbHNlDQo+DQo+IDMp IHNlbGVjdCBhIG1hcHBpbmcgcGx1Z2luIGluIGF1dGhuIGNvbmZpZ3VyYXRpb246DQo+DQo+IG92 aXJ0LmVuZ2luZS5hYWEuYXV0aG4ubWFwcGluZy5wbHVnaW4gPSBtYXBwaW5nLXN1ZmZpeA0KPg0K PiBXaXRoIGFib3ZlIGNvbmZpZ3VyYXRpb24gaW4gdXNlLCB5b3VyIHVzZXIgJ3VzZXInIHdpdGxs IGJlIG1hcHBlZCB0bw0KPiB1c2VyICd1c2VyQGZvby5iYXInDQo+IGFuZCB1c2VycyAndXNlckBh bm90aGVyZG9tYWluLmZvby5iYXInIHdpbGwgcmVtYWluDQo+ICd1c2VyQGFub3RoZXJkb21haW4u Zm9vLmJhcicuDQoNClRoaXMgaG93ZXZlciBkb2VzIG5vdCwgaXQgZG9lc24ndCByZXBsYWNlIHRo ZSBzdWZmaXggYXMgaXQncyBzdXBwb3NlZCB0by4gSSB0cmllZCB3aXRoIG1hbnkgZGlmZmVyZW50 IHR5cGVzIG9mIHRoZSAnbWFwVXNlci5wYXR0ZXJuJyBidXQgaXQgc2ltcGx5IHdvbid0IGNoYW5n ZSBpdCwgZXZlbiBpZiBJIHR5cGUgaW4gJz0gXnVzZXJAYmF6LmZvby5iYXIkJywgdGhlIGVycm9y IGlzIHRoZSBzYW1lOigNCg0KL0sNCg0KPg0KPiA+DQo+ID4gQVBJOiA8LS1BdXRobi5JbnZva2VD b21tYW5kcy5BVVRIRU5USUNBVEVfQ1JFREVOVElBTFMgcmVzdWx0PVNVQ0NFU1MNCj4gPg0KPiA+ DQo+ID4gYnV0Og0KPiA+DQo+ID4gQVBJOiAtLT5BdXRoei5JbnZva2VDb21tYW5kcy5GRVRDSF9Q UklOQ0lQQUxfUkVDT1JEDQo+ID4gcHJpbmNpcGFsPSd1c2VyQGJhei5mb28uYmFyJw0KPiA+IFNF VkVSRSAgQ2Fubm90IHJlc29sdmUgcHJpbmNpcGFsICd1c2VyQGJhei5mb28uYmFyJw0KPiA+DQo+ ID4NCj4gPiBTbyBpdCBmYWlscy4NCj4gPg0KPiA+DQo+ID4gIyBsZGFwc2VhcmNoIC14IC1IIGxk YXA6Ly9iYXouZm9vLmJhciAtRCB1c2VyQGZvby5iYXIgLVcgLWINCj4gPiBEQz1iYXosREM9Zm9v LERDPWJhciAtcyBzdWIgIihzYW1BY2NvdW50TmFtZT11c2VyKSIgdXNlclByaW5jaXBhbE5hbWUg fA0KPiA+IGdyZXAgJ3VzZXJQcmluY2lwYWxOYW1lOicNCj4gPg0KPiA+IHVzZXJQcmluY2lwYWxO YW1lOiB1c2VyQGZvby5iYXINCj4gPg0KPiA+DQo+ID4gfEhvdyBkbyB5b3UgY29uZmlndXJlIEFB QSB3aXRoIGJhc2UgJ0RDPWJheixEQz1mb28sREM9YmFyJyB3aGVuDQo+ID4gdXNlclByaW5jaXBh bE5hbWUgZW5kcyBvbmx5IG9uICdAZm9vLmJhcic/DQo+ID4NCj4gPiAvSw0KPiA+IHwNCj4gPg0K PiA+DQo+ID4NCj4gPg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4gVXNlcnMgbWFpbGluZyBsaXN0DQo+ID4gVXNlcnNAb3ZpcnQub3JnDQo+ ID4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo+ID4NCg== --_000_af85ac88d3754905aa58276556a94cceexch24sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <51B0C4ED7F656947BE8D44AC9BB2A263(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAyNCBtYXJzIDIwMTYgNzoyNiBlbSBza3JldiBPbmRyYSBNYWNoYWNlayAmbHQ7 b21hY2hhY2VAcmVkaGF0LmNvbSZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gMDMvMjQvMjAx NiAwNjoxNiBQTSwgS2FybGkgU2rDtmJlcmcgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IEhpITxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBTdGFydGluZyBuZXcgdGhy ZWFkIGluc3RlYWQgb2YgamFja2luZyBzb21lb25lIGVsc2XCtHMuPGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IE1hbmFnZWQgdG8gbWlncmF0ZSBmcm9tIG9sZCAn ZW5naW5lLW1hbmFnZS1kb21haW5zJyBhdXRoIHRvIGFhYS1sZGFwIHVzaW5nOjxicj4NCiZndDsg Jmd0Ozxicj4NCiZndDsgJmd0OyAjfCBvdmlydC1lbmdpbmUta2VyYmxkYXAtbWlncmF0aW9uLXRv b2wgLS1kb21haW4gYmF6LmZvby5iYXIgLS1jYWNlcnQ8YnI+DQomZ3Q7ICZndDsgL3RtcC9jYS5j cnQgLS1hcHBseTxicj4NCiZndDsgJmd0OyB8PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IEFsbCBPSywgbm8gZXJyb3JzLCBidXQgY2Fubm90IGxvZyBpbjo8YnI+ DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgIyBvdmlydC1lbmdpbmUtZXh0ZW5zaW9ucy10b29s IGFhYSBsb2dpbi11c2VyIC0tcHJvZmlsZT1iYXouZm9vLmJhci1uZXc8YnI+DQomZ3Q7ICZndDsg LS11c2VyLW5hbWU9dXNlcjo8YnI+DQomZ3Q7PGJyPg0KJmd0OyBJZiB5b3Ugd2FudCB0byBsb2dp biB3aXRoIHVzZXIgd2l0aCBkaWZmZXJlbnQgdXBuIHN1ZmZpeCwgdGhlbiBqdXN0IDxicj4NCiZn dDsgYXBwZW5kIHRoYXQgc3VmZml4PGJyPg0KJmd0Ozxicj4NCiZndDsgJCBvdmlydC1lbmdpbmUt ZXh0ZW5zaW9ucy10b29sIGFhYSBsb2dpbi11c2VyIC0tcHJvZmlsZT1iYXouZm9vLmJhci1uZXcg PGJyPg0KJmd0OyAtLXVzZXItbmFtZT11c2VyQGZvby5iYXI8L3A+DQo8cCBkaXI9Imx0ciI+T0ss IHNvbWUgcHJvZ3Jlc3MsIHRoYXQgd29ya3MhPC9wPg0KPHAgZGlyPSJsdHIiPiZndDs8YnI+DQom Z3Q7IElmIHlvdSBoYXZlIG1vcmUgc3VmZml4ZXMgYW5kIHdhbnQgdG8gaGF2ZSBzb21lIGFzIGRl ZmF1bHQgeW91IGNhbiB1c2UgPGJyPg0KJmd0OyBmb2xsb3dpbmcgYXBwcm9hY2g6PGJyPg0KJmd0 Ozxicj4NCiZndDsgMSkgaW5zdGFsbCBvdmlydC1lbmdpbmUtZXh0ZW5zaW9uLWFhYS1taXNjPGJy Pg0KJmd0Ozxicj4NCiZndDsgMikgY3JlYXRlIG5ldyBtYXBwaW5nIGV4dGVuc2lvbiBsaWtlIHRo aXM6PGJyPg0KJmd0OyAvZXRjL292aXJ0LWVuZ2luZS9leHRlbnNpb25zLmQvbWFwcGluZy1zdWZm aXgucHJvcGVydGllczxicj4NCiZndDs8YnI+DQomZ3Q7IG92aXJ0LmVuZ2luZS5leHRlbnNpb24u bmFtZSA9IG1hcHBpbmctc3VmZml4PGJyPg0KJmd0OyBvdmlydC5lbmdpbmUuZXh0ZW5zaW9uLmJp bmRpbmdzLm1ldGhvZCA9IGpib3NzbW9kdWxlPGJyPg0KJmd0OyBvdmlydC5lbmdpbmUuZXh0ZW5z aW9uLmJpbmRpbmcuamJvc3Ntb2R1bGUubW9kdWxlID0gPGJyPg0KJmd0OyBvcmcub3ZpcnQuZW5n aW5lLWV4dGVuc2lvbnMuYWFhLm1pc2M8YnI+DQomZ3Q7IG92aXJ0LmVuZ2luZS5leHRlbnNpb24u YmluZGluZy5qYm9zc21vZHVsZS5jbGFzcyA9IDxicj4NCiZndDsgb3JnLm92aXJ0LmVuZ2luZWV4 dGVuc2lvbnMuYWFhLm1pc2MubWFwcGluZy5NYXBwaW5nRXh0ZW5zaW9uPGJyPg0KJmd0OyBvdmly dC5lbmdpbmUuZXh0ZW5zaW9uLnByb3ZpZGVzID0gPGJyPg0KJmd0OyBvcmcub3ZpcnQuZW5naW5l LmFwaS5leHRlbnNpb25zLmFhYS5NYXBwaW5nPGJyPg0KJmd0OyBjb25maWcubWFwVXNlci50eXBl ID0gcmVnZXg8YnI+DQomZ3Q7IGNvbmZpZy5tYXBVc2VyLnBhdHRlcm4gPSBeKD8mbHQ7dXNlciZn dDtbXkBdKikkPC9wPg0KPHAgZGlyPSJsdHIiPklzIHRoYXQgc3VwcG9zZWQgdG8gcmVhbGx5IHNh eSAnJmx0O3VzZXImZ3Q7JyBvciBzaG91bGQgaXQgYmUgY2hhbmdlZCB0byBhIHJlYWwgdXNlciBu YW1lPyBFaXRoZXIgd2F5LCBpdCBkb2Vzbid0IHdvcmssIEkgdHJpZWQgaXQgYWxsLjwvcD4NCjxw IGRpcj0ibHRyIj4mZ3Q7IGNvbmZpZy5tYXBVc2VyLnJlcGxhY2VtZW50ID0gJHt1c2VyfUBmb28u YmFyPGJyPg0KJmd0OyBjb25maWcubWFwVXNlci5tdXN0TWF0Y2ggPSBmYWxzZTxicj4NCiZndDs8 YnI+DQomZ3Q7IDMpIHNlbGVjdCBhIG1hcHBpbmcgcGx1Z2luIGluIGF1dGhuIGNvbmZpZ3VyYXRp b246PGJyPg0KJmd0Ozxicj4NCiZndDsgb3ZpcnQuZW5naW5lLmFhYS5hdXRobi5tYXBwaW5nLnBs dWdpbiA9IG1hcHBpbmctc3VmZml4PGJyPg0KJmd0Ozxicj4NCiZndDsgV2l0aCBhYm92ZSBjb25m aWd1cmF0aW9uIGluIHVzZSwgeW91ciB1c2VyICd1c2VyJyB3aXRsbCBiZSBtYXBwZWQgdG8gPGJy Pg0KJmd0OyB1c2VyICd1c2VyQGZvby5iYXInPGJyPg0KJmd0OyBhbmQgdXNlcnMgJ3VzZXJAYW5v dGhlcmRvbWFpbi5mb28uYmFyJyB3aWxsIHJlbWFpbiA8YnI+DQomZ3Q7ICd1c2VyQGFub3RoZXJk b21haW4uZm9vLmJhcicuPC9wPg0KPHAgZGlyPSJsdHIiPlRoaXMgaG93ZXZlciBkb2VzIG5vdCwg aXQgZG9lc24ndCByZXBsYWNlIHRoZSBzdWZmaXggYXMgaXQncyBzdXBwb3NlZCB0by4gSSB0cmll ZCB3aXRoIG1hbnkgZGlmZmVyZW50IHR5cGVzIG9mIHRoZSAnbWFwVXNlci5wYXR0ZXJuJyBidXQg aXQgc2ltcGx5IHdvbid0IGNoYW5nZSBpdCwgZXZlbiBpZiBJIHR5cGUgaW4gJz0gXnVzZXJAYmF6 LmZvby5iYXIkJywgdGhlIGVycm9yIGlzIHRoZSBzYW1lOig8L3A+DQo8cCBkaXI9Imx0ciI+L0s8 L3A+DQo8cCBkaXI9Imx0ciI+Jmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBBUEk6 ICZsdDstLUF1dGhuLkludm9rZUNvbW1hbmRzLkFVVEhFTlRJQ0FURV9DUkVERU5USUFMUyByZXN1 bHQ9U1VDQ0VTUzxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBi dXQ6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IEFQSTogLS0mZ3Q7QXV0aHouSW52b2tl Q29tbWFuZHMuRkVUQ0hfUFJJTkNJUEFMX1JFQ09SRDxicj4NCiZndDsgJmd0OyBwcmluY2lwYWw9 J3VzZXJAYmF6LmZvby5iYXInPGJyPg0KJmd0OyAmZ3Q7IFNFVkVSRSZuYnNwOyBDYW5ub3QgcmVz b2x2ZSBwcmluY2lwYWwgJ3VzZXJAYmF6LmZvby5iYXInPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFNvIGl0IGZhaWxzLjxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyAjIGxkYXBzZWFyY2ggLXggLUggbGRhcDovL2Jhei5mb28u YmFyIC1EIHVzZXJAZm9vLmJhciAtVyAtYjxicj4NCiZndDsgJmd0OyBEQz1iYXosREM9Zm9vLERD PWJhciAtcyBzdWIgJnF1b3Q7KHNhbUFjY291bnROYW1lPXVzZXIpJnF1b3Q7IHVzZXJQcmluY2lw YWxOYW1lIHw8YnI+DQomZ3Q7ICZndDsgZ3JlcCAndXNlclByaW5jaXBhbE5hbWU6Jzxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyB1c2VyUHJpbmNpcGFsTmFtZTogdXNlckBmb28uYmFyPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IHxIb3cgZG8geW91IGNv bmZpZ3VyZSBBQUEgd2l0aCBiYXNlICdEQz1iYXosREM9Zm9vLERDPWJhcicgd2hlbjxicj4NCiZn dDsgJmd0OyB1c2VyUHJpbmNpcGFsTmFtZSBlbmRzIG9ubHkgb24gJ0Bmb28uYmFyJz88YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgL0s8YnI+DQomZ3Q7ICZndDsgfDxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsg Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CiZndDsgJmd0OyBVc2VycyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgVXNlcnNAb3ZpcnQu b3JnPGJyPg0KJmd0OyAmZ3Q7IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5m by91c2Vyczxicj4NCiZndDsgJmd0Ozxicj4NCjwvcD4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_af85ac88d3754905aa58276556a94cceexch24sluse_--

2 1

oVirt 3.6 AAA LDAP cannot not log in when end of UPN is different from domain base
by Karli Sjöberg 24 Mar '16

24 Mar '16

Hi! Starting new thread instead of jacking someone else´s. Managed to migrate from old 'engine-manage-domains' auth to aaa-ldap using: # ovirt-engine-kerbldap-migration-tool --domain baz.foo.bar --cacert /tmp/ca.crt --apply All OK, no errors, but cannot log in: # ovirt-engine-extensions-tool aaa login-user --profile=baz.foo.bar-new --user-name=user: API: <--Authn.InvokeCommands.AUTHENTICATE_CREDENTIALS result=SUCCESS but: API: -->Authz.InvokeCommands.FETCH_PRINCIPAL_RECORD principal='user(a)baz.foo.bar' SEVERE Cannot resolve principal 'user(a)baz.foo.bar' So it fails. # ldapsearch -x -H ldap://baz.foo.bar -D user(a)foo.bar -W -b DC=baz,DC=foo,DC=bar -s sub "(samAccountName=user)" userPrincipalName | grep 'userPrincipalName:' userPrincipalName: user(a)foo.bar How do you configure AAA with base 'DC=baz,DC=foo,DC=bar' when userPrincipalName ends only on '@foo.bar'? /K

2 1

Re: [ovirt-users] Active Directory (LDAP) user auth is slow
by Karli Sjöberg 24 Mar '16

24 Mar '16

--_000_0d09312977a3465882bf2a2bace95cb0exch24sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMjQgbWFycyAyMDE2IDEzOjQ5IHNrcmV2IE9uZHJhIE1hY2hhY2VrIDxvbWFjaGFjZUBy ZWRoYXQuY29tPjoNCj4NCj4gSGksDQo+DQo+IGlmIHlvdSByZW1vdmUgdXNlciwgdGhlbiBhbHNv IHBlcm1pc3Npb25zIG9mIHRoYXQgdXNlciB0byB2bXMgd2lsbCBiZQ0KPiByZW1vdmVkLg0KPiBB bmQgeWVzLCB5b3Ugd2lsbCBoYXZlIHRvIGFkZCBhbGwgdGhvc2UgcGVybWlzc2lvbnMgYmFjayB0 byB1c2VycyBmcm9tDQo+IG5ldyBwcm9maWxlLg0KPg0KPiBCdXQsIHlvdSBjYW4gdHJ5IG1pZ3Jh dGlvbiB0b29sWzFdLCB0byBtaWdyYXRlIGFsbCB1c2VycyB0byBuZXcgQUFBIHByb2ZpbGUuDQo+ IElmIHlvdSBoYXZlIGFueSBwcm9ibGVtIHdpdGggaXQsIHlvdSBjYW4gYXNrLg0KDQpFaG0sIGhv dyBkbyB5b3UgaW5zdGFsbCBpdD8gKGVsNikNCg0KL0sNCg0KPg0KPiBPbmRyYQ0KPg0KPiBbMV0N Cj4gaHR0cHM6Ly9naXRodWIuY29tL21hY2hhY2Vrb25kcmEvb3ZpcnQtZW5naW5lLWtlcmJsZGFw LW1pZ3JhdGlvbi9ibG9iL21hc3Rlci9SRUFETUUubWQNCj4NCj4gT24gMDMvMjQvMjAxNiAwMTow NiBQTSwgV2lsbCBEZW5uaXMgd3JvdGU6DQo+ID4gSW4gdGhlIFJIRVYgQWRtaW4gR3VpZGUgdGhh dCBNYXJ0aW4gbWVudGlvbmVkLCBpdCBzYXlzOg0KPiA+DQo+ID4gIkxvZyBpbiB0byB0aGUgQWRt aW5pc3RyYXRpb24gUG9ydGFsLCBhbmQgcmVtb3ZlIGFsbCB1c2VycyBhbmQgZ3JvdXBzIHJlbGF0 ZWQgdG8gdGhlIG9sZCBwcm9maWxlLiBVc2VycyBkZWZpbmVkIGluIHRoZSByZW1vdmVkIGRvbWFp biB3aWxsIG5vIGxvbmdlciBiZSBhYmxlIHRvIGF1dGhlbnRpY2F0ZSB3aXRoIHRoZSBSZWQgSGF0 IEVudGVycHJpc2UgVmlydHVhbGl6YXRpb24gTWFuYWdlci4gVGhlIGVudHJpZXMgZm9yIHRoZSBh ZmZlY3RlZCB1c2VycyB3aWxsIHJlbWFpbiBkZWZpbmVkIGluIHRoZSBSZWQgSGF0IEVudGVycHJp c2UgVmlydHVhbGl6YXRpb24gTWFuYWdlciB1bnRpbCB0aGV5IGFyZSBleHBsaWNpdGx5IHJlbW92 ZWQgZnJvbSB0aGUgQWRtaW5pc3RyYXRpb24gUG9ydGFsLuKAnQ0KPiA+DQo+ID4gSSBoYXZlIHNv bWUgVk1zIHJ1bm5pbmcgdW5kZXIgc29tZSBBRCBkb21haW4gdXNlcnM7IGlmIEkgcmVtb3ZlIHRo ZSB1c2VycyBmcm9tIHRoZSBzeXN0ZW0gYXMgYWJvdmUsIHdpbGwgSSBuZWVkIHRvIHJlbW92ZSB0 aGVtIGZyb20gdGhlIFZNIHBlcm1pc3Npb25zLCBvciBpcyB0aGF0IGNsZWFuZWQgdXAgYXMgd2Vs bD8gQW5kIEkgZ3Vlc3MgSeKAmWxsIG5lZWQgdG8gbWFudWFsbHkgcmUtYWRkIHRoZSBwZXJtcyBi YWNrIGFmdGVyIHRoZSBuZXcgZGlyZWN0b3J5IGNvbmZpZyBpcyBpbiBwbGFjZT8gUGxlYXNlIGFk dmlzZS4NCj4gPg0KPiA+IFRoYW5rcywNCj4gPiBXaWxsDQo+ID4NCj4gPiBPbiBNYXIgMjEsIDIw MTYsIGF0IDQ6MjkgQU0sIE1hcnRpbiBQZXJpbmEgPG1wZXJpbmFAcmVkaGF0LmNvbTxtYWlsdG86 bXBlcmluYUByZWRoYXQuY29tPj4gd3JvdGU6DQo+ID4NCj4gPg0KPiA+DQo+ID4gT24gTW9uLCBN YXIgMjEsIDIwMTYgYXQgODoyMCBBTSwgWWVkaWR5YWggQmFyIERhdmlkIDxkaWRpQHJlZGhhdC5j b208bWFpbHRvOmRpZGlAcmVkaGF0LmNvbT4+IHdyb3RlOg0KPiA+IE9uIE1vbiwgTWFyIDIxLCAy MDE2IGF0IDQ6NDcgQU0sIFdpbGwgRGVubmlzIDx3ZGVubmlzQG5lYy1sYWJzLmNvbTxtYWlsdG86 d2Rlbm5pc0BuZWMtbGFicy5jb20+PiB3cm90ZToNCj4gPj4gSGkgYWxsLA0KPiA+Pg0KPiA+PiBJ IGhhdmUgZW5hYmxlZCBBY3RpdmUgRGlyZWN0b3J5IGF1dGhlbnRpY2F0aW9uIGZvciB0aGUgdXNl cnMgaW4gb1ZpcnQgKHZpYSBlbmdpbmUtbWFuYWdlLWRvbWFpbnMgY29tbWFuZCB1c2luZyAtLXBy b3ZpZGVyPWFkKSBhbmQsIGFsdGhvdWdoIGl0IHdvcmtzLCBpdCB0YWtlcyBhYm91dCB+NTAgc2Vj 4oCZcyB0byBwcm9jZXNzIGEgbG9naW4uIEkgaGF2ZSBvdGhlciBPU1Mgc29mdHdhcmUgdGhhdCB1 dGlsaXplcyBBRCBhdXRoLCBhbmQgdGhlcmUgaXMgbm8gc3VjaCBsYWcgd2hlbiBwcm9jZXNzaW5n IGxvZ2lucywgc28gSeKAmW0gZ3Vlc3NpbmcgaXTigJlzIGEgcHJvYmxlbSB3aXRoIHRoZSBvVmly dCBpbXBsZW1lbnRhdGlvbuKApiBBbnkgd2F5IHRvIGRlYnVnIHdoeSB0aGUgYXV0aCBwcm9jZXNz IGlzIHRha2luZyBzbyBsb25nPw0KPiA+DQo+ID4gVGhpcyBpcyBhbiBvbGQsIHVubWFpbnRhaW5l ZCBjb21wb25lbnQuIFlvdSBzaG91bGQgdXNlIHRoZSBuZXcgYWFhLWxkYXAgb25lLg0KPiA+IFNl YXJjaCB0aGUgbGlzdCBhcmNoaXZlcyBmb3IgImFhYS1sZGFwIiBhbmQvb3IgcmVhZCB0aGUgUkVB RE1FIGZpbGUgaW4gdGhlDQo+ID4gc291cmNlcyBbMV0uIEJlc3QsDQo+ID4NCj4gPiBbMV0gaHR0 cHM6Ly9nZXJyaXQub3ZpcnQub3JnL2dpdHdlYj9wPW92aXJ0LWVuZ2luZS1leHRlbnNpb24tYWFh LWxkYXAuZ2l0O2E9YmxvYjtmPVJFQURNRQ0KPiA+DQo+ID4g4oCLWW91IGNvdWxkIGFsc28gdGFr ZSBhIGxvb2sgYXQgUkhFViAzLjYgQWRtaW5pc3RyYXRpb24gR3VpZGUsIGNoYXB0ZXIgMTMgVXNl cnMgYW5kIFJvbGVzIFsyXQ0KPiA+IHdoZXJlIHlvdSBjYW4gZmluZCBkZXRhaWxlZCBzdGVwcyBm b3IgY29tbW9uIGNvbmZpZ3VyYXRpb25zLg0KPiA+DQo+ID4gTWFydGluIFBlcmluYQ0KPiA+DQo+ ID4gWzJdIGh0dHBzOi8vYWNjZXNzLnJlZGhhdC5jb20vZG9jdW1lbnRhdGlvbi9lbi1VUy9SZWRf SGF0X0VudGVycHJpc2VfVmlydHVhbGl6YXRpb24vMy42L2h0bWwvQWRtaW5pc3RyYXRpb25fR3Vp ZGUvY2hhcC1Vc2Vyc19hbmRfUm9sZXMuaHRtbA0KPiA+IOKAiw0KPiA+DQo+ID4NCj4gPj4NCj4g Pj4gV2lsbA0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiA+PiBVc2VycyBtYWlsaW5nIGxpc3QNCj4gPj4gVXNlcnNAb3ZpcnQub3JnPG1haWx0 bzpVc2Vyc0BvdmlydC5vcmc+DQo+ID4+IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9s aXN0aW5mby91c2Vycw0KPiA+DQo+ID4NCj4gPg0KPiA+IC0tDQo+ID4gRGlkaQ0KPiA+IF9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gVXNlcnMgbWFp bGluZyBsaXN0DQo+ID4gVXNlcnNAb3ZpcnQub3JnPG1haWx0bzpVc2Vyc0BvdmlydC5vcmc+DQo+ ID4gaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo+ID4NCj4g Pg0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4gVXNlcnMgbWFpbGluZyBsaXN0DQo+ID4gVXNlcnNAb3ZpcnQub3JnDQo+ID4gaHR0cDovL2xp c3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo+ID4NCj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gVXNlcnMgbWFpbGluZyBsaXN0 DQo+IFVzZXJzQG92aXJ0Lm9yZw0KPiBodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlz dGluZm8vdXNlcnMNCg== --_000_0d09312977a3465882bf2a2bace95cb0exch24sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <12358A6FAB67B045BC2134D23CE9A03D(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAyNCBtYXJzIDIwMTYgMTM6NDkgc2tyZXYgT25kcmEgTWFjaGFjZWsgJmx0O29t YWNoYWNlQHJlZGhhdC5jb20mZ3Q7Ojxicj4NCiZndDs8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDs8 YnI+DQomZ3Q7IGlmIHlvdSByZW1vdmUgdXNlciwgdGhlbiBhbHNvIHBlcm1pc3Npb25zIG9mIHRo YXQgdXNlciB0byB2bXMgd2lsbCBiZSA8YnI+DQomZ3Q7IHJlbW92ZWQuPGJyPg0KJmd0OyBBbmQg eWVzLCB5b3Ugd2lsbCBoYXZlIHRvIGFkZCBhbGwgdGhvc2UgcGVybWlzc2lvbnMgYmFjayB0byB1 c2VycyBmcm9tIDxicj4NCiZndDsgbmV3IHByb2ZpbGUuPGJyPg0KJmd0Ozxicj4NCiZndDsgQnV0 LCB5b3UgY2FuIHRyeSBtaWdyYXRpb24gdG9vbFsxXSwgdG8gbWlncmF0ZSBhbGwgdXNlcnMgdG8g bmV3IEFBQSBwcm9maWxlLjxicj4NCiZndDsgSWYgeW91IGhhdmUgYW55IHByb2JsZW0gd2l0aCBp dCwgeW91IGNhbiBhc2suPC9wPg0KPHAgZGlyPSJsdHIiPkVobSwgaG93IGRvIHlvdSBpbnN0YWxs IGl0PyAoZWw2KTwvcD4NCjxwIGRpcj0ibHRyIj4vSzwvcD4NCjxwIGRpcj0ibHRyIj4mZ3Q7PGJy Pg0KJmd0OyBPbmRyYTxicj4NCiZndDs8YnI+DQomZ3Q7IFsxXSA8YnI+DQomZ3Q7IGh0dHBzOi8v Z2l0aHViLmNvbS9tYWNoYWNla29uZHJhL292aXJ0LWVuZ2luZS1rZXJibGRhcC1taWdyYXRpb24v YmxvYi9tYXN0ZXIvUkVBRE1FLm1kPGJyPg0KJmd0Ozxicj4NCiZndDsgT24gMDMvMjQvMjAxNiAw MTowNiBQTSwgV2lsbCBEZW5uaXMgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IEluIHRoZSBSSEVWIEFk bWluIEd1aWRlIHRoYXQgTWFydGluIG1lbnRpb25lZCwgaXQgc2F5czo8YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDsgJnF1b3Q7TG9nIGluIHRvIHRoZSBBZG1pbmlzdHJhdGlvbiBQb3J0YWws IGFuZCByZW1vdmUgYWxsIHVzZXJzIGFuZCBncm91cHMgcmVsYXRlZCB0byB0aGUgb2xkIHByb2Zp bGUuIFVzZXJzIGRlZmluZWQgaW4gdGhlIHJlbW92ZWQgZG9tYWluIHdpbGwgbm8gbG9uZ2VyIGJl IGFibGUgdG8gYXV0aGVudGljYXRlIHdpdGggdGhlIFJlZCBIYXQgRW50ZXJwcmlzZSBWaXJ0dWFs aXphdGlvbiBNYW5hZ2VyLiBUaGUgZW50cmllcyBmb3IgdGhlIGFmZmVjdGVkDQogdXNlcnMgd2ls bCByZW1haW4gZGVmaW5lZCBpbiB0aGUgUmVkIEhhdCBFbnRlcnByaXNlIFZpcnR1YWxpemF0aW9u IE1hbmFnZXIgdW50aWwgdGhleSBhcmUgZXhwbGljaXRseSByZW1vdmVkIGZyb20gdGhlIEFkbWlu aXN0cmF0aW9uIFBvcnRhbC7igJ08YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgSSBoYXZl IHNvbWUgVk1zIHJ1bm5pbmcgdW5kZXIgc29tZSBBRCBkb21haW4gdXNlcnM7IGlmIEkgcmVtb3Zl IHRoZSB1c2VycyBmcm9tIHRoZSBzeXN0ZW0gYXMgYWJvdmUsIHdpbGwgSSBuZWVkIHRvIHJlbW92 ZSB0aGVtIGZyb20gdGhlIFZNIHBlcm1pc3Npb25zLCBvciBpcyB0aGF0IGNsZWFuZWQgdXAgYXMg d2VsbD8gQW5kIEkgZ3Vlc3MgSeKAmWxsIG5lZWQgdG8gbWFudWFsbHkgcmUtYWRkIHRoZSBwZXJt cyBiYWNrIGFmdGVyIHRoZSBuZXcNCiBkaXJlY3RvcnkgY29uZmlnIGlzIGluIHBsYWNlPyBQbGVh c2UgYWR2aXNlLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBUaGFua3MsPGJyPg0KJmd0 OyAmZ3Q7IFdpbGw8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgT24gTWFyIDIxLCAyMDE2 LCBhdCA0OjI5IEFNLCBNYXJ0aW4gUGVyaW5hICZsdDttcGVyaW5hQHJlZGhhdC5jb20mbHQ7bWFp bHRvOm1wZXJpbmFAcmVkaGF0LmNvbSZndDsmZ3Q7IHdyb3RlOjxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBPbiBNb24sIE1hciAyMSwg MjAxNiBhdCA4OjIwIEFNLCBZZWRpZHlhaCBCYXIgRGF2aWQgJmx0O2RpZGlAcmVkaGF0LmNvbSZs dDttYWlsdG86ZGlkaUByZWRoYXQuY29tJmd0OyZndDsgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7IE9u IE1vbiwgTWFyIDIxLCAyMDE2IGF0IDQ6NDcgQU0sIFdpbGwgRGVubmlzICZsdDt3ZGVubmlzQG5l Yy1sYWJzLmNvbSZsdDttYWlsdG86d2Rlbm5pc0BuZWMtbGFicy5jb20mZ3Q7Jmd0OyB3cm90ZTo8 YnI+DQomZ3Q7ICZndDsmZ3Q7IEhpIGFsbCw8YnI+DQomZ3Q7ICZndDsmZ3Q7PGJyPg0KJmd0OyAm Z3Q7Jmd0OyBJIGhhdmUgZW5hYmxlZCBBY3RpdmUgRGlyZWN0b3J5IGF1dGhlbnRpY2F0aW9uIGZv ciB0aGUgdXNlcnMgaW4gb1ZpcnQgKHZpYSBlbmdpbmUtbWFuYWdlLWRvbWFpbnMgY29tbWFuZCB1 c2luZyAtLXByb3ZpZGVyPWFkKSBhbmQsIGFsdGhvdWdoIGl0IHdvcmtzLCBpdCB0YWtlcyBhYm91 dCB+NTAgc2Vj4oCZcyB0byBwcm9jZXNzIGEgbG9naW4uIEkgaGF2ZSBvdGhlciBPU1Mgc29mdHdh cmUgdGhhdCB1dGlsaXplcyBBRCBhdXRoLCBhbmQgdGhlcmUNCiBpcyBubyBzdWNoIGxhZyB3aGVu IHByb2Nlc3NpbmcgbG9naW5zLCBzbyBJ4oCZbSBndWVzc2luZyBpdOKAmXMgYSBwcm9ibGVtIHdp dGggdGhlIG9WaXJ0IGltcGxlbWVudGF0aW9u4oCmIEFueSB3YXkgdG8gZGVidWcgd2h5IHRoZSBh dXRoIHByb2Nlc3MgaXMgdGFraW5nIHNvIGxvbmc/PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAm Z3Q7IFRoaXMgaXMgYW4gb2xkLCB1bm1haW50YWluZWQgY29tcG9uZW50LiBZb3Ugc2hvdWxkIHVz ZSB0aGUgbmV3IGFhYS1sZGFwIG9uZS48YnI+DQomZ3Q7ICZndDsgU2VhcmNoIHRoZSBsaXN0IGFy Y2hpdmVzIGZvciAmcXVvdDthYWEtbGRhcCZxdW90OyBhbmQvb3IgcmVhZCB0aGUgUkVBRE1FIGZp bGUgaW4gdGhlPGJyPg0KJmd0OyAmZ3Q7IHNvdXJjZXMgWzFdLiBCZXN0LDxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0OyBbMV0gaHR0cHM6Ly9nZXJyaXQub3ZpcnQub3JnL2dpdHdlYj9wPW92 aXJ0LWVuZ2luZS1leHRlbnNpb24tYWFhLWxkYXAuZ2l0O2E9YmxvYjtmPVJFQURNRTxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyDigItZb3UgY291bGQgYWxzbyB0YWtlIGEgbG9vayBhdCBS SEVWIDMuNiBBZG1pbmlzdHJhdGlvbiBHdWlkZSwgY2hhcHRlciAxMyBVc2VycyBhbmQgUm9sZXMg WzJdPGJyPg0KJmd0OyAmZ3Q7IHdoZXJlIHlvdSBjYW4gZmluZCBkZXRhaWxlZCBzdGVwcyBmb3Ig Y29tbW9uIGNvbmZpZ3VyYXRpb25zLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBNYXJ0 aW4gUGVyaW5hPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IFsyXSBodHRwczovL2FjY2Vz cy5yZWRoYXQuY29tL2RvY3VtZW50YXRpb24vZW4tVVMvUmVkX0hhdF9FbnRlcnByaXNlX1ZpcnR1 YWxpemF0aW9uLzMuNi9odG1sL0FkbWluaXN0cmF0aW9uX0d1aWRlL2NoYXAtVXNlcnNfYW5kX1Jv bGVzLmh0bWw8YnI+DQomZ3Q7ICZndDsg4oCLPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZndDsgJmd0OyZndDsgV2lsbDxicj4NCiZndDsgJmd0 OyZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+ DQomZ3Q7ICZndDsmZ3Q7IFVzZXJzIG1haWxpbmcgbGlzdDxicj4NCiZndDsgJmd0OyZndDsgVXNl cnNAb3ZpcnQub3JnJmx0O21haWx0bzpVc2Vyc0BvdmlydC5vcmcmZ3Q7PGJyPg0KJmd0OyAmZ3Q7 Jmd0OyBodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4vbGlzdGluZm8vdXNlcnM8YnI+DQom Z3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgLS08 YnI+DQomZ3Q7ICZndDsgRGlkaTxicj4NCiZndDsgJmd0OyBfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgJmd0OyBVc2VycyBtYWlsaW5nIGxp c3Q8YnI+DQomZ3Q7ICZndDsgVXNlcnNAb3ZpcnQub3JnJmx0O21haWx0bzpVc2Vyc0BvdmlydC5v cmcmZ3Q7PGJyPg0KJmd0OyAmZ3Q7IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0 aW5mby91c2Vyczxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg Jmd0OyBVc2VycyBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7ICZndDsgVXNlcnNAb3ZpcnQub3JnPGJy Pg0KJmd0OyAmZ3Q7IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vy czxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IFVzZXJzIG1haWxpbmcgbGlzdDxicj4NCiZndDsg VXNlcnNAb3ZpcnQub3JnPGJyPg0KJmd0OyBodHRwOi8vbGlzdHMub3ZpcnQub3JnL21haWxtYW4v bGlzdGluZm8vdXNlcnM8YnI+DQo8L3A+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_0d09312977a3465882bf2a2bace95cb0exch24sluse_--

3 3

Re: [ovirt-users] Active Directory (LDAP) user auth is slow
by Karli Sjöberg 24 Mar '16

24 Mar '16

--_000_e68eb5719d7a4784b4b46753e2e0cbf1exch24sluse_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 DQpEZW4gMjQgbWFycyAyMDE2IDM6MDYgZW0gc2tyZXYgT25kcmEgTWFjaGFjZWsgPG9tYWNoYWNl QHJlZGhhdC5jb20+Og0KPg0KPiBPbiAwMy8yNC8yMDE2IDAzOjAyIFBNLCBLYXJsaSBTasO2YmVy ZyB3cm90ZToNCj4gPg0KPiA+IERlbiAyNCBtYXJzIDIwMTYgMTM6NDkgc2tyZXYgT25kcmEgTWFj aGFjZWsgPG9tYWNoYWNlQHJlZGhhdC5jb20+Og0KPiA+ICA+DQo+ID4gID4gSGksDQo+ID4gID4N Cj4gPiAgPiBpZiB5b3UgcmVtb3ZlIHVzZXIsIHRoZW4gYWxzbyBwZXJtaXNzaW9ucyBvZiB0aGF0 IHVzZXIgdG8gdm1zIHdpbGwgYmUNCj4gPiAgPiByZW1vdmVkLg0KPiA+ICA+IEFuZCB5ZXMsIHlv dSB3aWxsIGhhdmUgdG8gYWRkIGFsbCB0aG9zZSBwZXJtaXNzaW9ucyBiYWNrIHRvIHVzZXJzIGZy b20NCj4gPiAgPiBuZXcgcHJvZmlsZS4NCj4gPiAgPg0KPiA+ICA+IEJ1dCwgeW91IGNhbiB0cnkg bWlncmF0aW9uIHRvb2xbMV0sIHRvIG1pZ3JhdGUgYWxsIHVzZXJzIHRvIG5ldyBBQUENCj4gPiBw cm9maWxlLg0KPiA+ICA+IElmIHlvdSBoYXZlIGFueSBwcm9ibGVtIHdpdGggaXQsIHlvdSBjYW4g YXNrLg0KPiA+DQo+ID4gRWhtLCBob3cgZG8geW91IGluc3RhbGwgaXQ/IChlbDYpDQo+DQo+IHl1 bSBpbnN0YWxsIC15DQo+IGh0dHBzOi8vZ2l0aHViLmNvbS9tYWNoYWNla29uZHJhL292aXJ0LWVu Z2luZS1rZXJibGRhcC1taWdyYXRpb24vcmVsZWFzZXMvZG93bmxvYWQvb3ZpcnQtZW5naW5lLWtl cmJsZGFwLW1pZ3JhdGlvbi0xLjAuNC9vdmlydC1lbmdpbmUta2VyYmxkYXAtbWlncmF0aW9uLTEu MC40LTEuZWw2ZXYubm9hcmNoLnJwbQ0KDQpBd2Vzb21lLCB0aGFua3MhDQoNCi9LDQoNCj4NCj4g Pg0KPiA+IC9LDQo+ID4NCj4gPiAgPg0KPiA+ICA+IE9uZHJhDQo+ID4gID4NCj4gPiAgPiBbMV0N Cj4gPiAgPg0KPiA+IGh0dHBzOi8vZ2l0aHViLmNvbS9tYWNoYWNla29uZHJhL292aXJ0LWVuZ2lu ZS1rZXJibGRhcC1taWdyYXRpb24vYmxvYi9tYXN0ZXIvUkVBRE1FLm1kDQo+ID4gID4NCj4gPiAg PiBPbiAwMy8yNC8yMDE2IDAxOjA2IFBNLCBXaWxsIERlbm5pcyB3cm90ZToNCj4gPiAgPiA+IElu IHRoZSBSSEVWIEFkbWluIEd1aWRlIHRoYXQgTWFydGluIG1lbnRpb25lZCwgaXQgc2F5czoNCj4g PiAgPiA+DQo+ID4gID4gPiAiTG9nIGluIHRvIHRoZSBBZG1pbmlzdHJhdGlvbiBQb3J0YWwsIGFu ZCByZW1vdmUgYWxsIHVzZXJzIGFuZA0KPiA+IGdyb3VwcyByZWxhdGVkIHRvIHRoZSBvbGQgcHJv ZmlsZS4gVXNlcnMgZGVmaW5lZCBpbiB0aGUgcmVtb3ZlZCBkb21haW4NCj4gPiB3aWxsIG5vIGxv bmdlciBiZSBhYmxlIHRvIGF1dGhlbnRpY2F0ZSB3aXRoIHRoZSBSZWQgSGF0IEVudGVycHJpc2UN Cj4gPiBWaXJ0dWFsaXphdGlvbiBNYW5hZ2VyLiBUaGUgZW50cmllcyBmb3IgdGhlIGFmZmVjdGVk IHVzZXJzIHdpbGwgcmVtYWluDQo+ID4gZGVmaW5lZCBpbiB0aGUgUmVkIEhhdCBFbnRlcnByaXNl IFZpcnR1YWxpemF0aW9uIE1hbmFnZXIgdW50aWwgdGhleSBhcmUNCj4gPiBleHBsaWNpdGx5IHJl bW92ZWQgZnJvbSB0aGUgQWRtaW5pc3RyYXRpb24gUG9ydGFsLuKAnQ0KPiA+ICA+ID4NCj4gPiAg PiA+IEkgaGF2ZSBzb21lIFZNcyBydW5uaW5nIHVuZGVyIHNvbWUgQUQgZG9tYWluIHVzZXJzOyBp ZiBJIHJlbW92ZSB0aGUNCj4gPiB1c2VycyBmcm9tIHRoZSBzeXN0ZW0gYXMgYWJvdmUsIHdpbGwg SSBuZWVkIHRvIHJlbW92ZSB0aGVtIGZyb20gdGhlIFZNDQo+ID4gcGVybWlzc2lvbnMsIG9yIGlz IHRoYXQgY2xlYW5lZCB1cCBhcyB3ZWxsPyBBbmQgSSBndWVzcyBJ4oCZbGwgbmVlZCB0bw0KPiA+ IG1hbnVhbGx5IHJlLWFkZCB0aGUgcGVybXMgYmFjayBhZnRlciB0aGUgbmV3IGRpcmVjdG9yeSBj b25maWcgaXMgaW4NCj4gPiBwbGFjZT8gUGxlYXNlIGFkdmlzZS4NCj4gPiAgPiA+DQo+ID4gID4g PiBUaGFua3MsDQo+ID4gID4gPiBXaWxsDQo+ID4gID4gPg0KPiA+ICA+ID4gT24gTWFyIDIxLCAy MDE2LCBhdCA0OjI5IEFNLCBNYXJ0aW4gUGVyaW5hDQo+ID4gPG1wZXJpbmFAcmVkaGF0LmNvbTxt YWlsdG86bXBlcmluYUByZWRoYXQuY29tPj4gd3JvdGU6DQo+ID4gID4gPg0KPiA+ICA+ID4NCj4g PiAgPiA+DQo+ID4gID4gPiBPbiBNb24sIE1hciAyMSwgMjAxNiBhdCA4OjIwIEFNLCBZZWRpZHlh aCBCYXIgRGF2aWQNCj4gPiA8ZGlkaUByZWRoYXQuY29tPG1haWx0bzpkaWRpQHJlZGhhdC5jb20+ PiB3cm90ZToNCj4gPiAgPiA+IE9uIE1vbiwgTWFyIDIxLCAyMDE2IGF0IDQ6NDcgQU0sIFdpbGwg RGVubmlzDQo+ID4gPHdkZW5uaXNAbmVjLWxhYnMuY29tPG1haWx0bzp3ZGVubmlzQG5lYy1sYWJz LmNvbT4+IHdyb3RlOg0KPiA+ICA+ID4+IEhpIGFsbCwNCj4gPiAgPiA+Pg0KPiA+ICA+ID4+IEkg aGF2ZSBlbmFibGVkIEFjdGl2ZSBEaXJlY3RvcnkgYXV0aGVudGljYXRpb24gZm9yIHRoZSB1c2Vy cyBpbg0KPiA+IG9WaXJ0ICh2aWEgZW5naW5lLW1hbmFnZS1kb21haW5zIGNvbW1hbmQgdXNpbmcg LS1wcm92aWRlcj1hZCkgYW5kLA0KPiA+IGFsdGhvdWdoIGl0IHdvcmtzLCBpdCB0YWtlcyBhYm91 dCB+NTAgc2Vj4oCZcyB0byBwcm9jZXNzIGEgbG9naW4uIEkgaGF2ZQ0KPiA+IG90aGVyIE9TUyBz b2Z0d2FyZSB0aGF0IHV0aWxpemVzIEFEIGF1dGgsIGFuZCB0aGVyZSBpcyBubyBzdWNoIGxhZyB3 aGVuDQo+ID4gcHJvY2Vzc2luZyBsb2dpbnMsIHNvIEnigJltIGd1ZXNzaW5nIGl04oCZcyBhIHBy b2JsZW0gd2l0aCB0aGUgb1ZpcnQNCj4gPiBpbXBsZW1lbnRhdGlvbuKApiBBbnkgd2F5IHRvIGRl YnVnIHdoeSB0aGUgYXV0aCBwcm9jZXNzIGlzIHRha2luZyBzbyBsb25nPw0KPiA+ICA+ID4NCj4g PiAgPiA+IFRoaXMgaXMgYW4gb2xkLCB1bm1haW50YWluZWQgY29tcG9uZW50LiBZb3Ugc2hvdWxk IHVzZSB0aGUgbmV3DQo+ID4gYWFhLWxkYXAgb25lLg0KPiA+ICA+ID4gU2VhcmNoIHRoZSBsaXN0 IGFyY2hpdmVzIGZvciAiYWFhLWxkYXAiIGFuZC9vciByZWFkIHRoZSBSRUFETUUgZmlsZQ0KPiA+ IGluIHRoZQ0KPiA+ICA+ID4gc291cmNlcyBbMV0uIEJlc3QsDQo+ID4gID4gPg0KPiA+ICA+ID4g WzFdDQo+ID4gaHR0cHM6Ly9nZXJyaXQub3ZpcnQub3JnL2dpdHdlYj9wPW92aXJ0LWVuZ2luZS1l eHRlbnNpb24tYWFhLWxkYXAuZ2l0O2E9YmxvYjtmPVJFQURNRQ0KPiA+ICA+ID4NCj4gPiAgPiA+ IOKAi1lvdSBjb3VsZCBhbHNvIHRha2UgYSBsb29rIGF0IFJIRVYgMy42IEFkbWluaXN0cmF0aW9u IEd1aWRlLA0KPiA+IGNoYXB0ZXIgMTMgVXNlcnMgYW5kIFJvbGVzIFsyXQ0KPiA+ICA+ID4gd2hl cmUgeW91IGNhbiBmaW5kIGRldGFpbGVkIHN0ZXBzIGZvciBjb21tb24gY29uZmlndXJhdGlvbnMu DQo+ID4gID4gPg0KPiA+ICA+ID4gTWFydGluIFBlcmluYQ0KPiA+ICA+ID4NCj4gPiAgPiA+IFsy XQ0KPiA+IGh0dHBzOi8vYWNjZXNzLnJlZGhhdC5jb20vZG9jdW1lbnRhdGlvbi9lbi1VUy9SZWRf SGF0X0VudGVycHJpc2VfVmlydHVhbGl6YXRpb24vMy42L2h0bWwvQWRtaW5pc3RyYXRpb25fR3Vp ZGUvY2hhcC1Vc2Vyc19hbmRfUm9sZXMuaHRtbA0KPiA+ICA+ID4g4oCLDQo+ID4gID4gPg0KPiA+ ICA+ID4NCj4gPiAgPiA+Pg0KPiA+ICA+ID4+IFdpbGwNCj4gPiAgPiA+PiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ICA+ID4+IFVzZXJzIG1haWxp bmcgbGlzdA0KPiA+ICA+ID4+IFVzZXJzQG92aXJ0Lm9yZzxtYWlsdG86VXNlcnNAb3ZpcnQub3Jn Pg0KPiA+ICA+ID4+IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vy cw0KPiA+ICA+ID4NCj4gPiAgPiA+DQo+ID4gID4gPg0KPiA+ICA+ID4gLS0NCj4gPiAgPiA+IERp ZGkNCj4gPiAgPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gID4gPiBVc2VycyBtYWlsaW5nIGxpc3QNCj4gPiAgPiA+IFVzZXJzQG92aXJ0Lm9y ZzxtYWlsdG86VXNlcnNAb3ZpcnQub3JnPg0KPiA+ICA+ID4gaHR0cDovL2xpc3RzLm92aXJ0Lm9y Zy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo+ID4gID4gPg0KPiA+ICA+ID4NCj4gPiAgPiA+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4gID4gPiBV c2VycyBtYWlsaW5nIGxpc3QNCj4gPiAgPiA+IFVzZXJzQG92aXJ0Lm9yZw0KPiA+ICA+ID4gaHR0 cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo+ID4gID4gPg0KPiA+ ICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4g ID4gVXNlcnMgbWFpbGluZyBsaXN0DQo+ID4gID4gVXNlcnNAb3ZpcnQub3JnDQo+ID4gID4gaHR0 cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzDQo+ID4NCg== --_000_e68eb5719d7a4784b4b46753e2e0cbf1exch24sluse_ Content-Type: text/html; charset="utf-8" Content-ID: <1D4E2E0ECA1F4D43850876A6527A6444(a)ad.slu.se> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5Pg0KPHAgZGlyPSJsdHIi Pjxicj4NCkRlbiAyNCBtYXJzIDIwMTYgMzowNiBlbSBza3JldiBPbmRyYSBNYWNoYWNlayAmbHQ7 b21hY2hhY2VAcmVkaGF0LmNvbSZndDs6PGJyPg0KJmd0Ozxicj4NCiZndDsgT24gMDMvMjQvMjAx NiAwMzowMiBQTSwgS2FybGkgU2rDtmJlcmcgd3JvdGU6PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7IERlbiAyNCBtYXJzIDIwMTYgMTM6NDkgc2tyZXYgT25kcmEgTWFjaGFjZWsgJmx0O29t YWNoYWNlQHJlZGhhdC5jb20mZ3Q7Ojxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7PGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZndDsgSGksPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDs8YnI+DQomZ3Q7 ICZndDsmbmJzcDsgJmd0OyBpZiB5b3UgcmVtb3ZlIHVzZXIsIHRoZW4gYWxzbyBwZXJtaXNzaW9u cyBvZiB0aGF0IHVzZXIgdG8gdm1zIHdpbGwgYmU8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBy ZW1vdmVkLjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IEFuZCB5ZXMsIHlvdSB3aWxsIGhhdmUg dG8gYWRkIGFsbCB0aG9zZSBwZXJtaXNzaW9ucyBiYWNrIHRvIHVzZXJzIGZyb208YnI+DQomZ3Q7 ICZndDsmbmJzcDsgJmd0OyBuZXcgcHJvZmlsZS48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0Ozxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IEJ1dCwgeW91IGNhbiB0cnkgbWlncmF0aW9uIHRvb2xb MV0sIHRvIG1pZ3JhdGUgYWxsIHVzZXJzIHRvIG5ldyBBQUE8YnI+DQomZ3Q7ICZndDsgcHJvZmls ZS48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBJZiB5b3UgaGF2ZSBhbnkgcHJvYmxlbSB3aXRo IGl0LCB5b3UgY2FuIGFzay48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgRWhtLCBob3cg ZG8geW91IGluc3RhbGwgaXQ/IChlbDYpPGJyPg0KJmd0Ozxicj4NCiZndDsgeXVtIGluc3RhbGwg LXkgPGJyPg0KJmd0OyBodHRwczovL2dpdGh1Yi5jb20vbWFjaGFjZWtvbmRyYS9vdmlydC1lbmdp bmUta2VyYmxkYXAtbWlncmF0aW9uL3JlbGVhc2VzL2Rvd25sb2FkL292aXJ0LWVuZ2luZS1rZXJi bGRhcC1taWdyYXRpb24tMS4wLjQvb3ZpcnQtZW5naW5lLWtlcmJsZGFwLW1pZ3JhdGlvbi0xLjAu NC0xLmVsNmV2Lm5vYXJjaC5ycG08L3A+DQo8cCBkaXI9Imx0ciI+QXdlc29tZSwgdGhhbmtzITwv cD4NCjxwIGRpcj0ibHRyIj4vSzwvcD4NCjxwIGRpcj0ibHRyIj4mZ3Q7PGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7IC9LPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZn dDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyBPbmRyYTxicj4NCiZndDsgJmd0OyZuYnNwOyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgWzFdPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZn dDs8YnI+DQomZ3Q7ICZndDsgaHR0cHM6Ly9naXRodWIuY29tL21hY2hhY2Vrb25kcmEvb3ZpcnQt ZW5naW5lLWtlcmJsZGFwLW1pZ3JhdGlvbi9ibG9iL21hc3Rlci9SRUFETUUubWQ8YnI+DQomZ3Q7 ICZndDsmbmJzcDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7IE9uIDAzLzI0LzIwMTYg MDE6MDYgUE0sIFdpbGwgRGVubmlzIHdyb3RlOjxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZn dDsgSW4gdGhlIFJIRVYgQWRtaW4gR3VpZGUgdGhhdCBNYXJ0aW4gbWVudGlvbmVkLCBpdCBzYXlz Ojxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0 OyAmZ3Q7ICZxdW90O0xvZyBpbiB0byB0aGUgQWRtaW5pc3RyYXRpb24gUG9ydGFsLCBhbmQgcmVt b3ZlIGFsbCB1c2VycyBhbmQ8YnI+DQomZ3Q7ICZndDsgZ3JvdXBzIHJlbGF0ZWQgdG8gdGhlIG9s ZCBwcm9maWxlLiBVc2VycyBkZWZpbmVkIGluIHRoZSByZW1vdmVkIGRvbWFpbjxicj4NCiZndDsg Jmd0OyB3aWxsIG5vIGxvbmdlciBiZSBhYmxlIHRvIGF1dGhlbnRpY2F0ZSB3aXRoIHRoZSBSZWQg SGF0IEVudGVycHJpc2U8YnI+DQomZ3Q7ICZndDsgVmlydHVhbGl6YXRpb24gTWFuYWdlci4gVGhl IGVudHJpZXMgZm9yIHRoZSBhZmZlY3RlZCB1c2VycyB3aWxsIHJlbWFpbjxicj4NCiZndDsgJmd0 OyBkZWZpbmVkIGluIHRoZSBSZWQgSGF0IEVudGVycHJpc2UgVmlydHVhbGl6YXRpb24gTWFuYWdl ciB1bnRpbCB0aGV5IGFyZTxicj4NCiZndDsgJmd0OyBleHBsaWNpdGx5IHJlbW92ZWQgZnJvbSB0 aGUgQWRtaW5pc3RyYXRpb24gUG9ydGFsLuKAnTxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7IEkgaGF2ZSBzb21lIFZNcyBydW5uaW5n IHVuZGVyIHNvbWUgQUQgZG9tYWluIHVzZXJzOyBpZiBJIHJlbW92ZSB0aGU8YnI+DQomZ3Q7ICZn dDsgdXNlcnMgZnJvbSB0aGUgc3lzdGVtIGFzIGFib3ZlLCB3aWxsIEkgbmVlZCB0byByZW1vdmUg dGhlbSBmcm9tIHRoZSBWTTxicj4NCiZndDsgJmd0OyBwZXJtaXNzaW9ucywgb3IgaXMgdGhhdCBj bGVhbmVkIHVwIGFzIHdlbGw/IEFuZCBJIGd1ZXNzIEnigJlsbCBuZWVkIHRvPGJyPg0KJmd0OyAm Z3Q7IG1hbnVhbGx5IHJlLWFkZCB0aGUgcGVybXMgYmFjayBhZnRlciB0aGUgbmV3IGRpcmVjdG9y eSBjb25maWcgaXMgaW48YnI+DQomZ3Q7ICZndDsgcGxhY2U/IFBsZWFzZSBhZHZpc2UuPGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDsg VGhhbmtzLDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDsgV2lsbDxicj4NCiZndDsgJmd0 OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7IE9uIE1hciAy MSwgMjAxNiwgYXQgNDoyOSBBTSwgTWFydGluIFBlcmluYTxicj4NCiZndDsgJmd0OyAmbHQ7bXBl cmluYUByZWRoYXQuY29tJmx0O21haWx0bzptcGVyaW5hQHJlZGhhdC5jb20mZ3Q7Jmd0OyB3cm90 ZTo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJmd0OyAmZ3Q7IE9uIE1vbiwgTWFyIDIxLCAyMDE2IGF0IDg6MjAgQU0sIFllZGlkeWFoIEJh ciBEYXZpZDxicj4NCiZndDsgJmd0OyAmbHQ7ZGlkaUByZWRoYXQuY29tJmx0O21haWx0bzpkaWRp QHJlZGhhdC5jb20mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7 IE9uIE1vbiwgTWFyIDIxLCAyMDE2IGF0IDQ6NDcgQU0sIFdpbGwgRGVubmlzPGJyPg0KJmd0OyAm Z3Q7ICZsdDt3ZGVubmlzQG5lYy1sYWJzLmNvbSZsdDttYWlsdG86d2Rlbm5pc0BuZWMtbGFicy5j b20mZ3Q7Jmd0OyB3cm90ZTo8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7Jmd0OyBIaSBh bGwsPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0OyZndDs8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJmd0OyAmZ3Q7Jmd0OyBJIGhhdmUgZW5hYmxlZCBBY3RpdmUgRGlyZWN0b3J5IGF1dGhlbnRp Y2F0aW9uIGZvciB0aGUgdXNlcnMgaW48YnI+DQomZ3Q7ICZndDsgb1ZpcnQgKHZpYSBlbmdpbmUt bWFuYWdlLWRvbWFpbnMgY29tbWFuZCB1c2luZyAtLXByb3ZpZGVyPWFkKSBhbmQsPGJyPg0KJmd0 OyAmZ3Q7IGFsdGhvdWdoIGl0IHdvcmtzLCBpdCB0YWtlcyBhYm91dCB+NTAgc2Vj4oCZcyB0byBw cm9jZXNzIGEgbG9naW4uIEkgaGF2ZTxicj4NCiZndDsgJmd0OyBvdGhlciBPU1Mgc29mdHdhcmUg dGhhdCB1dGlsaXplcyBBRCBhdXRoLCBhbmQgdGhlcmUgaXMgbm8gc3VjaCBsYWcgd2hlbjxicj4N CiZndDsgJmd0OyBwcm9jZXNzaW5nIGxvZ2lucywgc28gSeKAmW0gZ3Vlc3NpbmcgaXTigJlzIGEg cHJvYmxlbSB3aXRoIHRoZSBvVmlydDxicj4NCiZndDsgJmd0OyBpbXBsZW1lbnRhdGlvbuKApiBB bnkgd2F5IHRvIGRlYnVnIHdoeSB0aGUgYXV0aCBwcm9jZXNzIGlzIHRha2luZyBzbyBsb25nPzxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAm Z3Q7IFRoaXMgaXMgYW4gb2xkLCB1bm1haW50YWluZWQgY29tcG9uZW50LiBZb3Ugc2hvdWxkIHVz ZSB0aGUgbmV3PGJyPg0KJmd0OyAmZ3Q7IGFhYS1sZGFwIG9uZS48YnI+DQomZ3Q7ICZndDsmbmJz cDsgJmd0OyAmZ3Q7IFNlYXJjaCB0aGUgbGlzdCBhcmNoaXZlcyBmb3IgJnF1b3Q7YWFhLWxkYXAm cXVvdDsgYW5kL29yIHJlYWQgdGhlIFJFQURNRSBmaWxlPGJyPg0KJmd0OyAmZ3Q7IGluIHRoZTxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDsgc291cmNlcyBbMV0uIEJlc3QsPGJyPg0KJmd0 OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDsgWzFd PGJyPg0KJmd0OyAmZ3Q7IGh0dHBzOi8vZ2Vycml0Lm92aXJ0Lm9yZy9naXR3ZWI/cD1vdmlydC1l bmdpbmUtZXh0ZW5zaW9uLWFhYS1sZGFwLmdpdDthPWJsb2I7Zj1SRUFETUU8YnI+DQomZ3Q7ICZn dDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0OyDigItZb3Ug Y291bGQgYWxzbyB0YWtlIGEgbG9vayBhdCBSSEVWIDMuNiBBZG1pbmlzdHJhdGlvbiBHdWlkZSw8 YnI+DQomZ3Q7ICZndDsgY2hhcHRlciAxMyBVc2VycyBhbmQgUm9sZXMgWzJdPGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZndDsgJmd0OyB3aGVyZSB5b3UgY2FuIGZpbmQgZGV0YWlsZWQgc3RlcHMgZm9y IGNvbW1vbiBjb25maWd1cmF0aW9ucy48YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0OyBNYXJ0aW4gUGVyaW5hPGJyPg0KJmd0OyAmZ3Q7 Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDsgWzJdPGJyPg0K Jmd0OyAmZ3Q7IGh0dHBzOi8vYWNjZXNzLnJlZGhhdC5jb20vZG9jdW1lbnRhdGlvbi9lbi1VUy9S ZWRfSGF0X0VudGVycHJpc2VfVmlydHVhbGl6YXRpb24vMy42L2h0bWwvQWRtaW5pc3RyYXRpb25f R3VpZGUvY2hhcC1Vc2Vyc19hbmRfUm9sZXMuaHRtbDxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7 ICZndDsg4oCLPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZu YnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7Jmd0Ozxicj4NCiZn dDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDsmZ3Q7IFdpbGw8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0 OyAmZ3Q7Jmd0OyBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xzxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDsmZ3Q7IFVzZXJzIG1haWxpbmcgbGlzdDxi cj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDsmZ3Q7IFVzZXJzQG92aXJ0Lm9yZyZsdDttYWls dG86VXNlcnNAb3ZpcnQub3JnJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDsmZ3Q7 IGh0dHA6Ly9saXN0cy5vdmlydC5vcmcvbWFpbG1hbi9saXN0aW5mby91c2Vyczxicj4NCiZndDsg Jmd0OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7PGJyPg0K Jmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDsg LS08YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7IERpZGk8YnI+DQomZ3Q7ICZndDsmbmJz cDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0OyBVc2VycyBtYWlsaW5nIGxpc3Q8YnI+ DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7IFVzZXJzQG92aXJ0Lm9yZyZsdDttYWlsdG86VXNl cnNAb3ZpcnQub3JnJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDsgaHR0cDovL2xp c3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7 ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZuYnNwOyAmZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsm bmJzcDsgJmd0OyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0OyBVc2VycyBtYWlsaW5nIGxpc3Q8 YnI+DQomZ3Q7ICZndDsmbmJzcDsgJmd0OyAmZ3Q7IFVzZXJzQG92aXJ0Lm9yZzxicj4NCiZndDsg Jmd0OyZuYnNwOyAmZ3Q7ICZndDsgaHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3VzZXJzPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyZu YnNwOyAmZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f PGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsgVXNlcnMgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAm Z3Q7Jm5ic3A7ICZndDsgVXNlcnNAb3ZpcnQub3JnPGJyPg0KJmd0OyAmZ3Q7Jm5ic3A7ICZndDsg aHR0cDovL2xpc3RzLm92aXJ0Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3VzZXJzPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KPC9wPg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_e68eb5719d7a4784b4b46753e2e0cbf1exch24sluse_--

1 0

Disks Snapshot
by Marcelo Leandro 24 Mar '16

24 Mar '16

Good morning I have a doubt, when i do a snapshot, a new lvm is generated, however when I delete this snapshot the lvm not off, that's right? [root@srv-qemu03 93633835-d709-4ebb-9317-903e62064c43]# ls 27a8bca3-f984-4f67-9dd2-9e2fc5a5f366 7d9b6ed0-1125-4215-ab76-37bcda3f6c2d 3fba372c-4c39-4843-be9e-b358b196331d b47f58e0-d576-49be-b8aa-f30581a0373a 5097df27-c676-4ee7-af89-ecdaed2c77be c598bb22-a386-4908-bfa1-7c44bd764c96 5aaf9ce9-d7ad-4607-aab9-2e239ebaed51 [root@srv-qemu03 93633835-d709-4ebb-9317-903e62064c43]# ls -l total 0 lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 09:28 27a8bca3-f984-4f67-9dd2-9e2fc5a5f366 -> /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/27a8bca3-f984-4f67-9dd2-9e2fc5a5f366 lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 09:31 3fba372c-4c39-4843-be9e-b358b196331d -> /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/3fba372c-4c39-4843-be9e-b358b196331d lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 08:44 5097df27-c676-4ee7-af89-ecdaed2c77be -> /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/5097df27-c676-4ee7-af89-ecdaed2c77be lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 09:23 5aaf9ce9-d7ad-4607-aab9-2e239ebaed51 -> /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/5aaf9ce9-d7ad-4607-aab9-2e239ebaed51 lrwxrwxrwx. 1 vdsm kvm 78 Mar 12 09:12 7d9b6ed0-1125-4215-ab76-37bcda3f6c2d -> /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/7d9b6ed0-1125-4215-ab76-37bcda3f6c2d lrwxrwxrwx. 1 vdsm kvm 78 Nov 27 22:30 b47f58e0-d576-49be-b8aa-f30581a0373a -> /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/b47f58e0-d576-49be-b8aa-f30581a0373a lrwxrwxrwx. 1 vdsm kvm 78 Mar 11 22:01 c598bb22-a386-4908-bfa1-7c44bd764c96 -> /dev/c2dc0101-748e-4a7b-9913-47993eaa52bd/c598bb22-a386-4908-bfa1-7c44bd764c96 disks snapshot: [root@srv-qemu03 93633835-d709-4ebb-9317-903e62064c43]# qemu-img info 27a8bca3-f984-4f67-9dd2-9e2fc5a5f366 image: 27a8bca3-f984-4f67-9dd2-9e2fc5a5f366 file format: qcow2 virtual size: 112G (120259084288 bytes) disk size: 0 cluster_size: 65536 backing file: ../93633835-d709-4ebb-9317-903e62064c43/b47f58e0-d576-49be-b8aa-f30581a0373a backing file format: raw Format specific information: compat: 0.10 refcount bits: 16 [root@srv-qemu03 93633835-d709-4ebb-9317-903e62064c43]# qemu-img info 3fba372c-4c39-4843-be9e-b358b196331d image: 3fba372c-4c39-4843-be9e-b358b196331d file format: qcow2 virtual size: 112G (120259084288 bytes) disk size: 0 cluster_size: 65536 backing file: ../93633835-d709-4ebb-9317-903e62064c43/b47f58e0-d576-49be-b8aa-f30581a0373a backing file format: raw Format specific information: compat: 0.10 refcount bits: 16 [root@srv-qemu03 93633835-d709-4ebb-9317-903e62064c43]# qemu-img info 5aaf9ce9-d7ad-4607-aab9-2e239ebaed51 image: 5aaf9ce9-d7ad-4607-aab9-2e239ebaed51 file format: qcow2 virtual size: 112G (120259084288 bytes) disk size: 0 cluster_size: 65536 backing file: ../93633835-d709-4ebb-9317-903e62064c43/b47f58e0-d576-49be-b8aa-f30581a0373a backing file format: raw Format specific information: compat: 0.10 refcount bits: 16 disk base: [root@srv-qemu03 93633835-d709-4ebb-9317-903e62064c43]# qemu-img info b47f58e0-d576-49be-b8aa-f30581a0373a image: b47f58e0-d576-49be-b8aa-f30581a0373a file format: raw virtual size: 112G (120259084288 bytes) disk size: 0 Thanks.

3 10

Active Directory (LDAP) user auth is slow
by Will Dennis 24 Mar '16

24 Mar '16

Hi all, I have enabled Active Directory authentication for the users in oVirt (via engine-manage-domains command using --provider=ad) and, although it works, it takes about ~50 sec’s to process a login. I have other OSS software that utilizes AD auth, and there is no such lag when processing logins, so I’m guessing it’s a problem with the oVirt implementation… Any way to debug why the auth process is taking so long? Will

4 4

delete storage definition
by paf1＠email.cz 24 Mar '16

24 Mar '16

This is a multi-part message in MIME format. --------------060909030807010004040503 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi folks, how can I delete the last storage definition from oVirt database if the last volume has been deleted from bricks commandline ( rm -rf < path to that volume > ) directly ? In oVirt DB exists this storage last record and blocking create new storage operation ( ovirt offering " delete datacenter", but this is not the right way for me, now ) regs. Pavel --------------060909030807010004040503 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit <html> <head> <meta http-equiv="content-type" content="text/html; charset=utf-8"> </head> <body text="#000066" bgcolor="#FFFFFF"> Hi folks,<br> how can I delete the last storage definition from oVirt database if the last volume has been deleted from bricks commandline ( rm -rf < path to that volume > ) directly ?<br> In oVirt DB exists this storage last record and blocking create new storage operation ( ovirt offering " delete datacenter", but this is not the right way for me, now )<br> regs. Pavel<br> </body> </html> --------------060909030807010004040503--

2 2

Re: [ovirt-users] Delete Failed to update OVF disks, OVF data
by Nikolai Sednev 24 Mar '16

24 Mar '16

------=_Part_24992860_1266289793.1458819135011 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hello Paul,=20 Any chance you may rename the HE Storage Domain name of to hosted_storage a= nd retry the auto-import of it?=20 You might find the auto-import worked as described in https://bugzilla.redh= at.com/show_bug.cgi?id=3D1269768 .=20 Thanks in advance.=20 Best regards,=20 Nikolai=20 ____________________=20 Nikolai Sednev=20 Senior Quality Engineer at Compute team=20 Red Hat Israel=20 34 Jerusalem Road,=20 Ra'anana, Israel 43501=20 Tel: +972 9 7692043=20 Mobile: +972 52 7342734=20 Email: nsednev(a)redhat.com=20 IRC: nsednev=20 ----- Original Message ----- From: users-request(a)ovirt.org=20 To: users(a)ovirt.org=20 Sent: Thursday, March 24, 2016 12:29:37 PM=20 Subject: Users Digest, Vol 54, Issue 113=20 Send Users mailing list submissions to=20 users(a)ovirt.org=20 To subscribe or unsubscribe via the World Wide Web, visit=20 http://lists.ovirt.org/mailman/listinfo/users=20 or, via email, send a message with subject or body 'help' to=20 users-request(a)ovirt.org=20 You can reach the person managing the list at=20 users-owner(a)ovirt.org=20 When replying, please edit your Subject line so it is more specific=20 than "Re: Contents of Users digest..."=20 Today's Topics:=20 1. Re: Delete Failed to update OVF disks, OVF data isn't=20 updated on those OVF stores (Data Center Default, Storage Domain=20 hostedengine_nfs). (Maor Lipchuk)=20 2. libvirt failed to read spice key (Fabrice Bacchella)=20 3. Re: VM get stuck randomly (Christophe TREFOIS)=20 4. delete storage definition (paf1(a)email.cz)=20 5. Re: [ANN] oVirt 3.6.4 Second Release Candidate is now=20 available for testing (Ond?ej Svoboda)=20 ----------------------------------------------------------------------=20 Message: 1=20 Date: Thu, 24 Mar 2016 11:01:32 +0200=20 From: Maor Lipchuk <mlipchuk(a)redhat.com>=20 To: "Paul Groeneweg | Pazion" <paul(a)pazion.nl>=20 Cc: users(a)ovirt.org=20 Subject: Re: [ovirt-users] Delete Failed to update OVF disks, OVF data=20 isn't updated on those OVF stores (Data Center Default, Storage Domain=20 hostedengine_nfs).=20 Message-ID:=20 <CAJ1JNOd0RxCfEYDv8jKdd2HZ+StGmyFySNcwyjfOqp1-GAxBrw(a)mail.gmail.com>=20 Content-Type: text/plain; charset=3D"utf-8"=20 On Thu, Mar 24, 2016 at 12:12 AM, Paul Groeneweg | Pazion <paul(a)pazion.nl>= =20 wrote:=20 >=20 > After the 3.6 updates ( which didn't went without a hitch )=20 >=20 > I get the following errors in my event log:=20 >=20 > Failed to update OVF disks 18c50ea6-4654-4525-b241-09e15acf5e99, OVF data= =20 > isn't updated on those OVF stores (Data Center Default, Storage Domain=20 > hostedengine_nfs).=20 >=20 > VDSM command failed: Could not acquire resource. Probably resource factor= y=20 > threw an exception.: ()=20 >=20 > http://screencast.com/t/S8cfXMsdGM=20 >=20 > When I check on file there is some data, but not updated:=20 > http://screencast.com/t/hbXQFlou=20 >=20 > When I check in the web interface I see 2 OVF files listed. What are thes= e=20 > for, can I delete them? http://screencast.com/t/ymnzsNHj7e=20 >=20 > Hopefully someone knows what to do about these warnings/erros and whether= =20 > I can delete the OVF files.=20 >=20 > Best Regards,=20 > Paul Groeneweg=20 >=20 >=20 > _______________________________________________=20 > Users mailing list=20 > Users(a)ovirt.org=20 > http://lists.ovirt.org/mailman/listinfo/users=20 >=20 >=20 Hi Paul,=20 The OVF_STORE disks are disks which preserve all the VMs and Templates OVF= =20 data and are mostly use for disaster recovery scenarios.=20 Those disks can not be deleted.=20 Regarding the audit log which you got, can you try to detach and attach the= =20 Storage once again and let me know if you still get this even log.=20 Regards,=20 Maor=20 -------------- next part --------------=20 An HTML attachment was scrubbed...=20 URL: <http://lists.ovirt.org/pipermail/users/attachments/20160324/e1109a36/= attachment-0001.html>=20 ------------------------------=20 Message: 2=20 Date: Thu, 24 Mar 2016 10:02:46 +0100=20 From: Fabrice Bacchella <fabrice.bacchella(a)orange.fr>=20 To: oVirt Userlist <Users(a)ovirt.org>=20 Subject: [ovirt-users] libvirt failed to read spice key=20 Message-ID: <734DEEBF-8845-4D8F-BDCC-139E50D9875D(a)orange.fr>=20 Content-Type: text/plain; charset=3Dus-ascii=20 I' m running on a brand new Centos 7.2 an up to date ovirt 3.6.3.4.=20 The host is new too and dedicated to ovirt.=20 When I try to launch a vm, I get :=20 Thread-9407::ERROR::2016-03-24 09:16:18,301::vm::759::virt.vm::(_startUnder= lyingVm) vmId=3D`a32e1043-a5a5-4e4c-8436-f7b7a4ff644c`::The vm start proces= s failed=20 Traceback (most recent call last):=20 File "/usr/share/vdsm/virt/vm.py", line 703, in _startUnderlyingVm=20 self._run()=20 File "/usr/share/vdsm/virt/vm.py", line 1941, in _run=20 self._connection.createXML(domxml, flags),=20 File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 124= , in wrapper=20 ret =3D f(*args, **kwargs)=20 File "/usr/lib/python2.7/site-packages/vdsm/utils.py", line 1313, in wrappe= r=20 return func(inst, *args, **kwargs)=20 File "/usr/lib64/python2.7/site-packages/libvirt.py", line 3611, in createX= ML=20 if ret is None:raise libvirtError('virDomainCreateXML() failed', conn=3Dsel= f)=20 libvirtError: internal error: process exited while connecting to monitor: (= (null):23672): Spice-Warning **: reds.c:3311:reds_init_ssl: Could not use p= rivate key file=20 2016-03-24T08:16:18.005359Z qemu-kvm: failed to initialize spice server=20 /var/log/libvirt/qemu/test.log says=20 2016-03-24 08:55:48.214+0000: starting up libvirt version: 1.2.17, package:= 13.el7_2.3 (CentOS BuildSystem <http://bugs.centos.org>, 2016-02-16-17:06:= 00, worker1.bsys.centos.org) qemu version: 2.3.0 (qemu-kvm-ev-2.3.0-31.el7= _2.7.1)=20 LC_ALL=3DC PATH=3D/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin QEMU_AU= DIO_DRV=3Dspice /usr/libexec/qemu-kvm -name test -S -machine pc-i440fx-rhel= 7.2.0,accel=3Dkvm,usb=3Doff -cpu Haswell-noTSX -m size=3D2097152k,slots=3D1= 6,maxmem=3D4294967296k -realtime mlock=3Doff -smp 2,maxcpus=3D16,sockets=3D= 16,cores=3D1,threads=3D1 -numa node,nodeid=3D0,cpus=3D0-1,mem=3D2048 -uuid = a32e1043-a5a5-4e4c-8436-f7b7a4ff644c -smbios type=3D1,manufacturer=3DoVirt,= product=3DoVirt Node,version=3D7-2.1511.el7.centos.2.10,serial=3D30373237-3= 132-5A43-3235-343233333937,uuid=3Da32e1043-a5a5-4e4c-8436-f7b7a4ff644c -no-= user-config -nodefaults -chardev socket,id=3Dcharmonitor,path=3D/var/lib/li= bvirt/qemu/domain-test/monitor.sock,server,nowait -mon chardev=3Dcharmonito= r,id=3Dmonitor,mode=3Dcontrol -rtc base=3D2016-03-24T08:55:46,driftfix=3Dsl= ew -global kvm-pit.lost_tick_policy=3Ddiscard -no-hpet -no-shutdown -boot m= enu=3Don,strict=3Don -device piix3-usb-uhci,id=3Dusb,bus=3Dpci.0,addr=3D0x1= .0x2 -device virtio-scsi-pci,id=3Dscsi0,bus=3Dpci.0,addr=3D0x4 -device virt= io-serial-pci,id=20 =3Dvirtio-serial0,max_ports=3D16,bus=3Dpci.0,addr=3D0x5 -drive if=3Dnone,id= =3Ddrive-ide0-1-0,readonly=3Don,format=3Draw,serial=3D -device ide-cd,bus= =3Dide.1,unit=3D0,drive=3Ddrive-ide0-1-0,id=3Dide0-1-0 -drive file=3D/rhev/= data-center/00000001-0001-0001-0001-00000000022a/85d19e93-ee08-41bb-94c9-56= adf17287b4/images/da6f49dd-8662-418b-a859-3523b4360c0e/930bbe74-7470-4b22-b= 096-fdb03276262d,if=3Dnone,id=3Ddrive-scsi0-0-0-0,format=3Draw,serial=3Dda6= f49dd-8662-418b-a859-3523b4360c0e,cache=3Dnone,werror=3Dstop,rerror=3Dstop,= aio=3Dnative,iops=3D300 -device scsi-hd,bus=3Dscsi0.0,channel=3D0,scsi-id= =3D0,lun=3D0,drive=3Ddrive-scsi0-0-0-0,id=3Dscsi0-0-0-0,bootindex=3D1 -netd= ev tap,fd=3D27,id=3Dhostnet0,vhost=3Don,vhostfd=3D28 -device virtio-net-pci= ,netdev=3Dhostnet0,id=3Dnet0,mac=3D00:1a:4a:16:01:51,bus=3Dpci.0,addr=3D0x3= ,bootindex=3D2 -chardev socket,id=3Dcharserial0,path=3D/var/run/ovirt-vmcon= sole-console/a32e1043-a5a5-4e4c-8436-f7b7a4ff644c.sock,server,nowait -devic= e isa-serial,chardev=3Dcharserial0,id=3Dserial0 -chardev socket,id=3Dcharch= annel0,path=3D/var/lib/libvirt/qemu=20 /channels/a32e1043-a5a5-4e4c-8436-f7b7a4ff644c.com.redhat.rhevm.vdsm,server= ,nowait -device virtserialport,bus=3Dvirtio-serial0.0,nr=3D1,chardev=3Dchar= channel0,id=3Dchannel0,name=3Dcom.redhat.rhevm.vdsm -chardev socket,id=3Dch= archannel1,path=3D/var/lib/libvirt/qemu/channels/a32e1043-a5a5-4e4c-8436-f7= b7a4ff644c.org.qemu.guest_agent.0,server,nowait -device virtserialport,bus= =3Dvirtio-serial0.0,nr=3D2,chardev=3Dcharchannel1,id=3Dchannel1,name=3Dorg.= qemu.guest_agent.0 -chardev spicevmc,id=3Dcharchannel2,name=3Dvdagent -devi= ce virtserialport,bus=3Dvirtio-serial0.0,nr=3D3,chardev=3Dcharchannel2,id= =3Dchannel2,name=3Dcom.redhat.spice.0 -spice port=3D5900,tls-port=3D5901,ad= dr=3D0,x509-dir=3D/etc/pki/vdsm/libvirt-spice,seamless-migration=3Don -devi= ce qxl-vga,id=3Dvideo0,ram_size=3D67108864,vram_size=3D8388608,vgamem_mb=3D= 16,bus=3Dpci.0,addr=3D0x2 -device virtio-balloon-pci,id=3Dballoon0,bus=3Dpc= i.0,addr=3D0x6 -msg timestamp=3Don=20 ((null):29166): Spice-Warning **: reds.c:3311:reds_init_ssl: Could not use = private key file=20 2016-03-24T08:55:48.329252Z qemu-kvm: failed to initialize spice server=20 2016-03-24 08:55:48.479+0000: shutting down=20 and indeed, when I try to strace libvirt :=20 open("/etc/pki/vdsm/libvirt-spice/server-key.pem", O_RDONLY) =3D -1 EACCES = (Permission denied)=20 chmod a+r /etc/pki/vdsm/libvirt-spice/server-key.pem solved the problem, bu= t it's obviously not a solution.=20 ------------------------------=20 Message: 3=20 Date: Thu, 24 Mar 2016 09:45:34 +0000=20 From: Christophe TREFOIS <christophe.trefois(a)uni.lu>=20 To: Nir Soffer <nsoffer(a)redhat.com>=20 Cc: users <users(a)ovirt.org>=20 Subject: Re: [ovirt-users] VM get stuck randomly=20 Message-ID: <2EBB29CB9A8F494FB5253F6AF2E6A1981D6B8F66(a)hoshi.uni.lux>=20 Content-Type: text/plain; charset=3D"utf-8"=20 Hi,=20 We finally upgraded to 3.6.3 across the whole data center and will now see = if this issue reappears.=20 The upgrade went quite smooth, first from 3.5.4 to 3.5.6 and then to 3.6.3.= =20 Thank you,=20 --=20 Christophe=20 > -----Original Message-----=20 > From: Nir Soffer [mailto:nsoffer@redhat.com]=20 > Sent: dimanche 13 mars 2016 12:51=20 > To: Christophe TREFOIS <christophe.trefois(a)uni.lu>=20 > Cc: users <users(a)ovirt.org>=20 > Subject: Re: [ovirt-users] VM get stuck randomly=20 >=20 > On Sun, Mar 13, 2016 at 9:46 AM, Christophe TREFOIS=20 > <christophe.trefois(a)uni.lu> wrote:=20 > > Dear all,=20 > >=20 > > I have a problem since couple of weeks, where randomly 1 VM (not always= =20 > the same) becomes completely unresponsive.=20 > > We find this out because our Icinga server complains that host is down.= =20 > >=20 > > Upon inspection, we find we can?t open a console to the VM, nor can we= =20 > login.=20 > >=20 > > In oVirt engine, the VM looks like ?up?. The only weird thing is that R= AM=20 > usage shows 0% and CPU usage shows 100% or 75% depending on number of=20 > cores.=20 > > The only way to recover is to force shutdown the VM via 2-times shutdow= n=20 > from the engine.=20 > >=20 > > Could you please help me to start debugging this?=20 > > I can provide any logs, but I?m not sure which ones, because I couldn?t= see=20 > anything with ERROR in the vdsm logs on the host.=20 >=20 > I would inspect this vm on the host when it happens.=20 >=20 > What is vdsm cpu usage? what is the qemu process (for this vm) cpu usage?= =20 >=20 > strace output of this qemu process (all threads) or a core dump can help= =20 > qemu developers to understand this issue.=20 >=20 > >=20 > > The host is running=20 > >=20 > > OS Version: RHEL - 7 - 1.1503.el7.centos.2.8=20 > > Kernel Version: 3.10.0 - 229.14.1.el7.x86_64=20 > > KVM Version: 2.1.2 - 23.el7_1.8.1=20 > > LIBVIRT Version: libvirt-1.2.8-16.el7_1.4=20 > > VDSM Version: vdsm-4.16.26-0.el7.centos=20 > > SPICE Version: 0.12.4 - 9.el7_1.3=20 > > GlusterFS Version: glusterfs-3.7.5-1.el7=20 >=20 > You are running old versions, missing lot of fixes. Nothing specific to y= our=20 > problem but this lower the chance to get a working system.=20 >=20 > It would be nice if you can upgrade to ovirt-3.6 and report if it made an= y=20 > change.=20 > Or at lest latest ovirt-3.5.=20 >=20 > > We use a locally exported gluster as storage domain (eg, storage is on = the=20 > same machine exposed via gluster). No replica.=20 > > We run around 50 VMs on that host.=20 >=20 > Why use gluster for this? Do you plan to add more gluster servers in the= =20 > future?=20 >=20 > Nir=20 ------------------------------=20 Message: 4=20 Date: Thu, 24 Mar 2016 11:20:07 +0100=20 From: "paf1(a)email.cz" <paf1(a)email.cz>=20 To: users <users(a)ovirt.org>=20 Subject: [ovirt-users] delete storage definition=20 Message-ID: <56F3BF57.7070009(a)email.cz>=20 Content-Type: text/plain; charset=3D"utf-8"; Format=3D"flowed"=20 Hi folks,=20 how can I delete the last storage definition from oVirt database if the=20 last volume has been deleted from bricks commandline ( rm -rf < path to=20 that volume > ) directly ?=20 In oVirt DB exists this storage last record and blocking create new=20 storage operation ( ovirt offering " delete datacenter", but this is not=20 the right way for me, now )=20 regs. Pavel=20 -------------- next part --------------=20 An HTML attachment was scrubbed...=20 URL: <http://lists.ovirt.org/pipermail/users/attachments/20160324/9a9a23c7/= attachment-0001.html>=20 ------------------------------=20 Message: 5=20 Date: Thu, 24 Mar 2016 11:24:26 +0100=20 From: Ond?ej Svoboda <ondrej(a)svobodasoft.cz>=20 To: Sandro Bonazzola <sbonazzo(a)redhat.com>=20 Cc: users <users(a)ovirt.org>=20 Subject: Re: [ovirt-users] [ANN] oVirt 3.6.4 Second Release Candidate=20 is now available for testing=20 Message-ID: <56F3C05A.2000208(a)svobodasoft.cz>=20 Content-Type: text/plain; charset=3D"utf-8"; Format=3D"flowed"=20 Thank you very much, Sandro!=20 centos-ovirt36 now works for me.=20 On 24.3.2016 09:00, Sandro Bonazzola wrote:=20 >=20 >=20 > On Wed, Mar 23, 2016 at 4:22 PM, Ond?ej Svoboda <ondrej(a)svobodasoft.cz=20 > <mailto:ondrej@svobodasoft.cz>> wrote:=20 >=20 > Hi Sandro,=20 >=20 > I just ran yum -y install=20 > http://plain.resources.ovirt.org/pub/yum-repo/ovirt-release36.rpm=20 > <http://www.google.com/url?q=3Dhttp%3A%2F%2Fplain.resources.ovirt.org%2Fp= ub%2Fyum-repo%2Fovirt-release36.rpm&sa=3DD&sntz=3D1&usg=3DAFQjCNHQ3_R-I3QwE= v9bTQHIIfj5FJpCQg>=20 > on my fresh EL7 (not CentOS) system.=20 >=20 > In /etc/yum.repos.d/ovirt-3.6-dependencies.repo, there was a=20 > broken centos-ovirt36 source:=20 >=20 >=20 > http://mirror.centos.org/centos/7Server/virt/x86_64/ovirt-3.6/repodata/re= pomd.xml:=20 > [Errno 14] HTTP Error 404 - Not Found=20 >=20 >=20 > Fixed pointing to=20 > http://mirror.centos.org/centos/7/virt/x86_64/ovirt-3.6/repodata/repomd.x= ml=20 >=20 > Released a new ovirt-release36 package including the fix.=20 >=20 >=20 >=20 >=20 > I had to disable this repo before I was even able to update my system.=20 >=20 > [centos-ovirt36]=20 > name=3DCentOS-$releasever - oVirt 3.6=20 > baseurl=3Dhttp://mirror.centos.org/centos/$releasever/virt/$basearch/ovir= t-3.6/=20 > gpgcheck=3D0=20 > enabled=3D1=20 > skip_if_unavailable =3D 1=20 > keepcache =3D 0=20 >=20 > Then I managed to install ovirt-engine all right, so I think the=20 > above repo should simply not be enabled in ovirt-release36.rpm=20 > <http://www.google.com/url?q=3Dhttp%3A%2F%2Fplain.resources.ovirt.org%2Fp= ub%2Fyum-repo%2Fovirt-release36.rpm&sa=3DD&sntz=3D1&usg=3DAFQjCNHQ3_R-I3QwE= v9bTQHIIfj5FJpCQg>.=20 >=20 > Thanks for your reply.=20 > Ondra=20 >=20 > On 22.3.2016 18:28, Sandro Bonazzola wrote:=20 >> The oVirt Project is pleased to announce the availability of the=20 >> Second Release Candidate of oVirt 3.6.4 for testing, as of March=20 >> 22nd, 2016=20 >>=20 >> This release is available now for:=20 >> * Fedora 22=20 >> * Red Hat Enterprise Linux 6.7=20 >> * CentOS Linux 6.7 (or similar)=20 >> * Red Hat Enterprise Linux 7.2 or later=20 >> * CentOS Linux (or similar) 7.2 or later=20 >>=20 >> This release supports Hypervisor Hosts running:=20 >> * Red Hat Enterprise Linux 7.2 or later=20 >> * CentOS Linux (or similar) 7.2 or later=20 >> * Fedora 22=20 >>=20 >> This release is also available with experimental support for:=20 >> * Debian 8.3 Jessie=20 >>=20 >> This release candidate includes the following updated packages:=20 >>=20 >> * ovirt-engine=20 >>=20 >> * ovirt-hosted-engine-ha=20 >>=20 >>=20 >> See the release notes [1] for installation / upgrade instructions=20 >> and a list of new features and bugs fixed.=20 >>=20 >> Notes:=20 >> * A new oVirt Live ISO will be available soon [2].=20 >> * Mirrors[3] might need up to one day to synchronize.=20 >>=20 >> Additional Resources:=20 >> * Read more about the oVirt 3.6.3 release=20 >> highlights:http://www.ovirt.org/release/3.6.4/=20 >> * Get more oVirt Project updates on Twitter:=20 >> https://twitter.com/ovirt=20 >> * Check out the latest project news on the oVirt blog:=20 >> http://www.ovirt.org/blog/=20 >>=20 >> [1] http://www.ovirt.org/release/3.6.4/=20 >> [2] http://resources.ovirt.org/pub/ovirt-3.6-pre/iso/=20 >> [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors=20 >>=20 >>=20 >> --=20 >> Sandro Bonazzola=20 >> Better technology. Faster innovation. Powered by community=20 >> collaboration.=20 >> See how it works at redhat.com <http://redhat.com>=20 >>=20 >>=20 >> _______________________________________________=20 >> Users mailing list=20 >> Users(a)ovirt.org <mailto:Users@ovirt.org>=20 >> http://lists.ovirt.org/mailman/listinfo/users=20 >=20 >=20 > _______________________________________________=20 > Users mailing list=20 > Users(a)ovirt.org <mailto:Users@ovirt.org>=20 > http://lists.ovirt.org/mailman/listinfo/users=20 >=20 >=20 >=20 >=20 > --=20 > Sandro Bonazzola=20 > Better technology. Faster innovation. Powered by community collaboration.= =20 > See how it works at redhat.com <http://redhat.com>=20 -------------- next part --------------=20 An HTML attachment was scrubbed...=20 URL: <http://lists.ovirt.org/pipermail/users/attachments/20160324/71e6b117/= attachment.html>=20 ------------------------------=20 _______________________________________________=20 Users mailing list=20 Users(a)ovirt.org=20 http://lists.ovirt.org/mailman/listinfo/users=20 End of Users Digest, Vol 54, Issue 113=20 **************************************=20 ------=_Part_24992860_1266289793.1458819135011 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><body><div style=3D"font-family: georgia,serif; font-size: 12pt; colo= r: #000000"><div>Hello Paul,<br></div><div>Any chance you may rename the HE= Storage Domain name of to hosted_storage and retry the auto-import of it?<= br></div><div>You might find the auto-import worked as described in <a href= =3D"https://bugzilla.redhat.com/show_bug.cgi?id=3D1269768">https://bugzilla= .redhat.com/show_bug.cgi?id=3D1269768</a>  .<br></div><div><span name= =3D"x"></span><br>Thanks in advance.<br><div><br></div>Best regards,<br>Nik= olai<br>____________________<br>Nikolai Sednev<br>Senior Quality Engineer a= t Compute team<br>Red Hat Israel<br>34 Jerusalem Road,<br>Ra'anana, Israel = 43501<br><div><br></div>Tel:       +972   9 7692043<br>= Mobile: +972 52 7342734<br>Email: nsednev(a)redhat.com<br>IRC: nsednev<span n= ame=3D"x"></span><br></div><div><br></div><hr id=3D"zwchr"><div style=3D"co= lor:#000;font-weight:normal;font-style:normal;text-decoration:none;font-fam= ily:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>users-request@= ovirt.org<br><b>To: </b>users(a)ovirt.org<br><b>Sent: </b>Thursday, March 24,= 2016 12:29:37 PM<br><b>Subject: </b>Users Digest, Vol 54, Issue 113<br><di= v><br></div>Send Users mailing list submissions to<br>   &nb= sp;    users(a)ovirt.org<br><div><br></div>To subscribe o= r unsubscribe via the World Wide Web, visit<br>    &nbs= p;   http://lists.ovirt.org/mailman/listinfo/users<br>or, vi= a email, send a message with subject or body 'help' to<br>  &nbsp= ;     users-request(a)ovirt.org<br><div><br></div>Yo= u can reach the person managing the list at<br>    &nbs= p;   users-owner(a)ovirt.org<br><div><br></div>When replying, = please edit your Subject line so it is more specific<br>than "Re: Contents = of Users digest..."<br><div><br></div><br>Today's Topics:<br><div><br></div= >   1. Re:  Delete Failed to update OVF disks, OVF data isn'= t<br>      updated on those OVF stores (Data Center Def= ault, Storage Domain<br>      hostedengine_nfs). (Maor = Lipchuk)<br>   2.  libvirt failed to read spice key (Fabrice= Bacchella)<br>   3. Re:  VM get stuck randomly (Christophe = TREFOIS)<br>   4.  delete storage definition (paf1(a)email.cz)= <br>   5. Re:  [ANN] oVirt 3.6.4 Second Release Candidate is= now<br>      available for testing (Ond?ej Svoboda)<br= ><div><br></div><br>-------------------------------------------------------= ---------------<br><div><br></div>Message: 1<br>Date: Thu, 24 Mar 2016 11:0= 1:32 +0200<br>From: Maor Lipchuk <mlipchuk(a)redhat.com><br>To: "Paul G= roeneweg | Pazion" <paul(a)pazion.nl><br>Cc: users(a)ovirt.org<br>Subject= : Re: [ovirt-users] Delete Failed to update OVF disks, OVF data<br> &n= bsp;      isn't updated on those OVF stores (= Data Center Default, Storage Domain<br>      =   hostedengine_nfs).<br>Message-ID:<br>    &n= bsp;   <CAJ1JNOd0RxCfEYDv8jKdd2HZ+StGmyFySNcwyjfOqp1-GAxB= rw(a)mail.gmail.com><br>Content-Type: text/plain; charset=3D"utf-8"<br><di= v><br></div>On Thu, Mar 24, 2016 at 12:12 AM, Paul Groeneweg | Pazion <p= aul(a)pazion.nl><br>wrote:<br><div><br></div>><br>> After the 3.6 up= dates ( which didn't went without a hitch )<br>><br>> I get the follo= wing errors in my event log:<br>><br>> Failed to update OVF disks 18c= 50ea6-4654-4525-b241-09e15acf5e99, OVF data<br>> isn't updated on those = OVF stores (Data Center Default, Storage Domain<br>> hostedengine_nfs).<= br>><br>> VDSM command failed: Could not acquire resource. Probably r= esource factory<br>> threw an exception.: ()<br>><br>> http://scre= encast.com/t/S8cfXMsdGM<br>><br>> When I check on file there is some = data, but not updated:<br>> http://screencast.com/t/hbXQFlou<br>><br>= > When I check in the web interface I see 2 OVF files listed. What are t= hese<br>> for, can I delete them? http://screencast.com/t/ymnzsNHj7e<br>= ><br><div><br></div>> Hopefully someone knows what to do about these = warnings/erros and whether<br>> I can delete the OVF files.<br>><br><= div><br></div>> Best Regards,<br>> Paul Groeneweg<br>><br>><br>= > _______________________________________________<br>> Users mailing = list<br>> Users(a)ovirt.org<br>> http://lists.ovirt.org/mailman/listinf= o/users<br>><br>><br>Hi Paul,<br><div><br></div>The OVF_STORE disks a= re disks which preserve all the VMs and Templates OVF<br>data and are mostl= y use for disaster recovery scenarios.<br>Those disks can not be deleted.<b= r>Regarding the audit log which you got, can you try to detach and attach t= he<br>Storage once again and let me know if you still get this even log.<br= ><div><br></div>Regards,<br>Maor<br>-------------- next part --------------= <br>An HTML attachment was scrubbed...<br>URL: <http://lists.ovirt.org/p= ipermail/users/attachments/20160324/e1109a36/attachment-0001.html><br><d= iv><br></div>------------------------------<br><div><br></div>Message: 2<br= >Date: Thu, 24 Mar 2016 10:02:46 +0100<br>From: Fabrice Bacchella <fabri= ce.bacchella(a)orange.fr><br>To: oVirt Userlist <Users(a)ovirt.org><br= >Subject: [ovirt-users] libvirt failed to read spice key<br>Message-ID: &lt= ;734DEEBF-8845-4D8F-BDCC-139E50D9875D(a)orange.fr><br>Content-Type: text/p= lain; charset=3Dus-ascii<br><div><br></div>I' m running on a brand new Cent= os 7.2 an up to date ovirt 3.6.3.4.<br><div><br></div>The host is new too a= nd dedicated to ovirt.<br><div><br></div>When I try to launch a vm, I get := <br><div><br></div>Thread-9407::ERROR::2016-03-24 09:16:18,301::vm::759::vi= rt.vm::(_startUnderlyingVm) vmId=3D`a32e1043-a5a5-4e4c-8436-f7b7a4ff644c`::= The vm start process failed<br>Traceback (most recent call last):<br> =  File "/usr/share/vdsm/virt/vm.py", line 703, in _startUnderlyingVm<br= >    self._run()<br>  File "/usr/share/vdsm/virt/v= m.py", line 1941, in _run<br>    self._connection.createXML(= domxml, flags),<br>  File "/usr/lib/python2.7/site-packages/vdsm/= libvirtconnection.py", line 124, in wrapper<br>    ret =3D f= (*args, **kwargs)<br>  File "/usr/lib/python2.7/site-packages/vds= m/utils.py", line 1313, in wrapper<br>    return func(inst, = *args, **kwargs)<br>  File "/usr/lib64/python2.7/site-packages/li= bvirt.py", line 3611, in createXML<br>    if ret is None:rai= se libvirtError('virDomainCreateXML() failed', conn=3Dself)<br>libvirtError= : internal error: process exited while connecting to monitor: ((null):23672= ): Spice-Warning **: reds.c:3311:reds_init_ssl: Could not use private key f= ile<br>2016-03-24T08:16:18.005359Z qemu-kvm: failed to initialize spice ser= ver<br><div><br></div><br>/var/log/libvirt/qemu/test.log says<br><div><br><= /div>2016-03-24 08:55:48.214+0000: starting up libvirt version: 1.2.17, pac= kage: 13.el7_2.3 (CentOS BuildSystem <http://bugs.centos.org>, 2016-0= 2-16-17:06:00, worker1.bsys.centos.org) qemu version: 2.3.0 (qemu-kvm-ev-2= .3.0-31.el7_2.7.1)<br>LC_ALL=3DC PATH=3D/usr/local/sbin:/usr/local/bin:/usr= /sbin:/usr/bin QEMU_AUDIO_DRV=3Dspice /usr/libexec/qemu-kvm -name test -S -= machine pc-i440fx-rhel7.2.0,accel=3Dkvm,usb=3Doff -cpu Haswell-noTSX -m siz= e=3D2097152k,slots=3D16,maxmem=3D4294967296k -realtime mlock=3Doff -smp 2,m= axcpus=3D16,sockets=3D16,cores=3D1,threads=3D1 -numa node,nodeid=3D0,cpus= =3D0-1,mem=3D2048 -uuid a32e1043-a5a5-4e4c-8436-f7b7a4ff644c -smbios type= =3D1,manufacturer=3DoVirt,product=3DoVirt Node,version=3D7-2.1511.el7.cento= s.2.10,serial=3D30373237-3132-5A43-3235-343233333937,uuid=3Da32e1043-a5a5-4= e4c-8436-f7b7a4ff644c -no-user-config -nodefaults -chardev socket,id=3Dchar= monitor,path=3D/var/lib/libvirt/qemu/domain-test/monitor.sock,server,nowait= -mon chardev=3Dcharmonitor,id=3Dmonitor,mode=3Dcontrol -rtc base=3D2016-03= -24T08:55:46,driftfix=3Dslew -global kvm-pit.lost_tick_policy=3Ddiscard -no= -hpet -no-shutdown -boot menu=3Don,strict=3Don -device piix3-usb-uhci,id=3D= usb,bus=3Dpci.0,addr=3D0x1.0x2 -device virtio-scsi-pci,id=3Dscsi0,bus=3Dpci= .0,addr=3D0x4 -device virtio-serial-pci,id<br> =3Dvirtio-serial0,max_p= orts=3D16,bus=3Dpci.0,addr=3D0x5 -drive if=3Dnone,id=3Ddrive-ide0-1-0,reado= nly=3Don,format=3Draw,serial=3D -device ide-cd,bus=3Dide.1,unit=3D0,drive= =3Ddrive-ide0-1-0,id=3Dide0-1-0 -drive file=3D/rhev/data-center/00000001-00= 01-0001-0001-00000000022a/85d19e93-ee08-41bb-94c9-56adf17287b4/images/da6f4= 9dd-8662-418b-a859-3523b4360c0e/930bbe74-7470-4b22-b096-fdb03276262d,if=3Dn= one,id=3Ddrive-scsi0-0-0-0,format=3Draw,serial=3Dda6f49dd-8662-418b-a859-35= 23b4360c0e,cache=3Dnone,werror=3Dstop,rerror=3Dstop,aio=3Dnative,iops=3D300= -device scsi-hd,bus=3Dscsi0.0,channel=3D0,scsi-id=3D0,lun=3D0,drive=3Ddriv= e-scsi0-0-0-0,id=3Dscsi0-0-0-0,bootindex=3D1 -netdev tap,fd=3D27,id=3Dhostn= et0,vhost=3Don,vhostfd=3D28 -device virtio-net-pci,netdev=3Dhostnet0,id=3Dn= et0,mac=3D00:1a:4a:16:01:51,bus=3Dpci.0,addr=3D0x3,bootindex=3D2 -chardev s= ocket,id=3Dcharserial0,path=3D/var/run/ovirt-vmconsole-console/a32e1043-a5a= 5-4e4c-8436-f7b7a4ff644c.sock,server,nowait -device isa-serial,chardev=3Dch= arserial0,id=3Dserial0 -chardev socket,id=3Dcharchannel0,path=3D/var/lib/li= bvirt/qemu<br> /channels/a32e1043-a5a5-4e4c-8436-f7b7a4ff644c.com.redh= at.rhevm.vdsm,server,nowait -device virtserialport,bus=3Dvirtio-serial0.0,n= r=3D1,chardev=3Dcharchannel0,id=3Dchannel0,name=3Dcom.redhat.rhevm.vdsm -ch= ardev socket,id=3Dcharchannel1,path=3D/var/lib/libvirt/qemu/channels/a32e10= 43-a5a5-4e4c-8436-f7b7a4ff644c.org.qemu.guest_agent.0,server,nowait -device= virtserialport,bus=3Dvirtio-serial0.0,nr=3D2,chardev=3Dcharchannel1,id=3Dc= hannel1,name=3Dorg.qemu.guest_agent.0 -chardev spicevmc,id=3Dcharchannel2,n= ame=3Dvdagent -device virtserialport,bus=3Dvirtio-serial0.0,nr=3D3,chardev= =3Dcharchannel2,id=3Dchannel2,name=3Dcom.redhat.spice.0 -spice port=3D5900,= tls-port=3D5901,addr=3D0,x509-dir=3D/etc/pki/vdsm/libvirt-spice,seamless-mi= gration=3Don -device qxl-vga,id=3Dvideo0,ram_size=3D67108864,vram_size=3D83= 88608,vgamem_mb=3D16,bus=3Dpci.0,addr=3D0x2 -device virtio-balloon-pci,id= =3Dballoon0,bus=3Dpci.0,addr=3D0x6 -msg timestamp=3Don<br>((null):29166): S= pice-Warning **: reds.c:3311:reds_init_ssl: Could not use private key file<= br>2016-03-24T08:55:48.329252Z qemu-kvm: failed to initialize spice server<= br>2016-03-24 08:55:48.479+0000: shutting down<br><div><br></div>and indeed= , when I try to strace libvirt :<br> open("/etc/pki/vdsm/libvirt-spice= /server-key.pem", O_RDONLY) =3D -1 EACCES (Permission denied)<br><div><br><= /div>chmod a+r /etc/pki/vdsm/libvirt-spice/server-key.pem solved the proble= m, but it's obviously not a solution.<br><div><br></div><br><div><br></div>= <br><div><br></div><br>------------------------------<br><div><br></div>Mes= sage: 3<br>Date: Thu, 24 Mar 2016 09:45:34 +0000<br>From: Christophe TREFOI= S <christophe.trefois(a)uni.lu><br>To: Nir Soffer <nsoffer(a)redhat.co= m><br>Cc: users <users(a)ovirt.org><br>Subject: Re: [ovirt-users] VM= get stuck randomly<br>Message-ID: <2EBB29CB9A8F494FB5253F6AF2E6A1981D6B= 8F66(a)hoshi.uni.lux><br>Content-Type: text/plain; charset=3D"utf-8"<br><d= iv><br></div>Hi,<br><div><br></div>We finally upgraded to 3.6.3 across the = whole data center and will now see if this issue reappears.<br><div><br></d= iv>The upgrade went quite smooth, first from 3.5.4 to 3.5.6 and then to 3.6= .3.<br><div><br></div>Thank you,<br><div><br></div>--<br>Christophe<br><div= ><br></div>> -----Original Message-----<br>> From: Nir Soffer [mailto= :nsoffer@redhat.com]<br>> Sent: dimanche 13 mars 2016 12:51<br>> To: = Christophe TREFOIS <christophe.trefois(a)uni.lu><br>> Cc: users <= users(a)ovirt.org><br>> Subject: Re: [ovirt-users] VM get stuck randoml= y<br>> <br>> On Sun, Mar 13, 2016 at 9:46 AM, Christophe TREFOIS<br>&= gt; <christophe.trefois(a)uni.lu> wrote:<br>> > Dear all,<br>>= ><br>> > I have a problem since couple of weeks, where randomly 1= VM (not always<br>> the same) becomes completely unresponsive.<br>> = > We find this out because our Icinga server complains that host is down= .<br>> ><br>> > Upon inspection, we find we can?t open a consol= e to the VM, nor can we<br>> login.<br>> ><br>> > In oVirt e= ngine, the VM looks like ?up?. The only weird thing is that RAM<br>> usa= ge shows 0% and CPU usage shows 100% or 75% depending on number of<br>> = cores.<br>> > The only way to recover is to force shutdown the VM via= 2-times shutdown<br>> from the engine.<br>> ><br>> > Could = you please help me to start debugging this?<br>> > I can provide any = logs, but I?m not sure which ones, because I couldn?t see<br>> anything = with ERROR in the vdsm logs on the host.<br>> <br>> I would inspect t= his vm on the host when it happens.<br>> <br>> What is vdsm cpu usage= ? what is the qemu process (for this vm) cpu usage?<br>> <br>> strace= output of this qemu process (all threads) or a core dump can help<br>> = qemu developers to understand this issue.<br>> <br>> ><br>> &gt= ; The host is running<br>> ><br>> > OS Version:     &= nbsp;       RHEL - 7 - 1.1503.el7.centos.2.8<br>> > Ke= rnel Version: 3.10.0 - 229.14.1.el7.x86_64<br>> > KVM Version:  =          2.1.2 - 23.el7_1.8.1<br>> > LIBVIR= T Version:        libvirt-1.2.8-16.el7_1.4<br>> >= VDSM Version:   vdsm-4.16.26-0.el7.centos<br>> > SPICE Version:=  0.12.4 - 9.el7_1.3<br>> > GlusterFS Version:     &nb= sp;glusterfs-3.7.5-1.el7<br>> <br>> You are running old versions, mis= sing lot of fixes. Nothing specific to your<br>> problem but this lower = the chance to get a working system.<br>> <br>> It would be nice if yo= u can upgrade to ovirt-3.6 and report if it made any<br>> change.<br>&gt= ; Or at lest latest ovirt-3.5.<br>> <br>> > We use a locally expor= ted gluster as storage domain (eg, storage is on the<br>> same machine e= xposed via gluster). No replica.<br>> > We run around 50 VMs on that = host.<br>> <br>> Why use gluster for this? Do you plan to add more gl= uster servers in the<br>> future?<br>> <br>> Nir<br><div><br></div= >------------------------------<br><div><br></div>Message: 4<br>Date: Thu, = 24 Mar 2016 11:20:07 +0100<br>From: "paf1(a)email.cz" <paf1(a)email.cz><b= r>To: users <users(a)ovirt.org><br>Subject: [ovirt-users] delete storag= e definition<br>Message-ID: <56F3BF57.7070009(a)email.cz><br>Content-Ty= pe: text/plain; charset=3D"utf-8"; Format=3D"flowed"<br><div><br></div>Hi f= olks,<br>how can I delete the last storage  definition from oVirt data= base if the <br>last  volume has been deleted from bricks commandline = ( rm -rf < path to <br>that volume > ) directly ?<br>In oVirt DB exis= ts this storage last record and blocking create new <br>storage operation (= ovirt offering " delete datacenter", but this is not <br>the right way for= me, now )<br>regs. Pavel<br>-------------- next part --------------<br>An = HTML attachment was scrubbed...<br>URL: <http://lists.ovirt.org/pipermai= l/users/attachments/20160324/9a9a23c7/attachment-0001.html><br><div><br>= </div>------------------------------<br><div><br></div>Message: 5<br>Date: = Thu, 24 Mar 2016 11:24:26 +0100<br>From: Ond?ej Svoboda <ondrej@svobodas= oft.cz><br>To: Sandro Bonazzola <sbonazzo(a)redhat.com><br>Cc: users= <users(a)ovirt.org><br>Subject: Re: [ovirt-users] [ANN] oVirt 3.6.4 Se= cond Release Candidate<br>        i= s now available for testing<br>Message-ID: <56F3C05A.2000208@svobodasoft= .cz><br>Content-Type: text/plain; charset=3D"utf-8"; Format=3D"flowed"<b= r><div><br></div>Thank you very much, Sandro!<br><div><br></div>centos-ovir= t36 now works for me.<br><div><br></div>On 24.3.2016 09:00, Sandro Bonazzol= a wrote:<br>><br>><br>> On Wed, Mar 23, 2016 at 4:22 PM, Ond?ej Sv= oboda <ondrej(a)svobodasoft.cz <br>> <mailto:ondrej@svobodasoft.cz&g= t;> wrote:<br>><br>>     Hi Sandro,<br>><br>> &nbs= p;   I just ran yum -y install<br>>     http://plain.reso= urces.ovirt.org/pub/yum-repo/ovirt-release36.rpm<br>>     <= http://www.google.com/url?q=3Dhttp%3A%2F%2Fplain.resources.ovirt.org%2Fpub%= 2Fyum-repo%2Fovirt-release36.rpm&sa=3DD&sntz=3D1&usg=3DAFQjCNHQ= 3_R-I3QwEv9bTQHIIfj5FJpCQg><br>>     on my fresh EL7 (not C= entOS) system.<br>><br>>     In /etc/yum.repos.d/ovirt-3.6-= dependencies.repo, there was a<br>>     broken centos-ovirt36 = source:<br>><br>><br>>     http://mirror.centos.org/cent= os/7Server/virt/x86_64/ovirt-3.6/repodata/repomd.xml:<br>>    = [Errno 14] HTTP Error 404 - Not Found<br>><br>><br>> Fixed pointi= ng to <br>> http://mirror.centos.org/centos/7/virt/x86_64/ovirt-3.6/repo= data/repomd.xml<br>><br>> Released a new ovirt-release36 package incl= uding the fix.<br>><br>><br>><br>><br>>     I had = to disable this repo before I was even able to update my system.<br>><br= >>     [centos-ovirt36]<br>>     name=3DCentOS-$r= eleasever - oVirt 3.6<br>>     baseurl=3Dhttp://mirror.centos.= org/centos/$releasever/virt/$basearch/ovirt-3.6/<br>>     gpgc= heck=3D0<br>>     enabled=3D1<br>>     skip_if_un= available =3D 1<br>>     keepcache =3D 0<br>><br>> &nbsp= ;   Then I managed to install ovirt-engine all right, so I think the<b= r>>     above repo should simply not be enabled in ovirt-relea= se36.rpm<br>>     <http://www.google.com/url?q=3Dhttp%3A%2F= %2Fplain.resources.ovirt.org%2Fpub%2Fyum-repo%2Fovirt-release36.rpm&sa= =3DD&sntz=3D1&usg=3DAFQjCNHQ3_R-I3QwEv9bTQHIIfj5FJpCQg>.<br>>= <br>>     Thanks for your reply.<br>>     Ondra<b= r>><br>>     On 22.3.2016 18:28, Sandro Bonazzola wrote:<br= >>>     The oVirt Project is pleased to announce the availa= bility of the<br>>>     Second Release Candidate of oVirt 3= .6.4 for testing, as of March<br>>>     22nd, 2016<br>>&= gt;<br>>>     This release is available now for:<br>>&gt= ;     * Fedora 22<br>>>     * Red Hat Enterprise = Linux 6.7<br>>>     * CentOS Linux 6.7 (or similar)<br>>= >     * Red Hat Enterprise Linux 7.2 or later<br>>> &nbs= p;   * CentOS Linux (or similar) 7.2 or later<br>>><br>>> =     This release supports Hypervisor Hosts running:<br>>> &= nbsp;   * Red Hat Enterprise Linux 7.2 or later<br>>>   &nb= sp; * CentOS Linux (or similar) 7.2 or later<br>>>     * Fe= dora 22<br>>><br>>>     This release is also availabl= e with experimental support for:<br>>>     * Debian 8.3 Jes= sie<br>>><br>>>     This release candidate includes t= he following updated packages:<br>>><br>>>      = * ovirt-engine<br>>><br>>>       * ovirt-hosted= -engine-ha<br>>><br>>><br>>>     See the releas= e notes [1] for installation / upgrade instructions<br>>>   &nbs= p; and a list of new features and bugs fixed.<br>>><br>>> &nbsp= ;   Notes:<br>>>     * A new oVirt Live ISO will be av= ailable soon [2].<br>>>     * Mirrors[3] might need up to o= ne day to synchronize.<br>>><br>>>     Additional Res= ources:<br>>>     * Read more about the oVirt 3.6.3 release= <br>>>     highlights:http://www.ovirt.org/release/3.6.4/<b= r>>>     * Get more oVirt Project updates on Twitter:<br>&g= t;>     https://twitter.com/ovirt<br>>>     * = Check out the latest project news on the oVirt blog:<br>>>   &nb= sp; http://www.ovirt.org/blog/<br>>><br>>>     [1] ht= tp://www.ovirt.org/release/3.6.4/<br>>>     [2] http://reso= urces.ovirt.org/pub/ovirt-3.6-pre/iso/<br>>>     [3] http:/= /www.ovirt.org/Repository_mirrors#Current_mirrors<br>>><br>>><b= r>>>     -- <br>>>     Sandro Bonazzola<br>= >>     Better technology. Faster innovation. Powered by com= munity<br>>>     collaboration.<br>>>     S= ee how it works at redhat.com <http://redhat.com><br>>><br>>= ><br>>>     ____________________________________________= ___<br>>>     Users mailing list<br>>>     = Users(a)ovirt.org <mailto:Users@ovirt.org><br>>>     ht= tp://lists.ovirt.org/mailman/listinfo/users<br>><br>><br>>   =   _______________________________________________<br>>   &nbsp= ; Users mailing list<br>>     Users(a)ovirt.org <mailto:Users= @ovirt.org><br>>     http://lists.ovirt.org/mailman/listinf= o/users<br>><br>><br>><br>><br>> -- <br>> Sandro Bonazzol= a<br>> Better technology. Faster innovation. Powered by community collab= oration.<br>> See how it works at redhat.com <http://redhat.com><b= r><div><br></div>-------------- next part --------------<br>An HTML attachm= ent was scrubbed...<br>URL: <http://lists.ovirt.org/pipermail/users/atta= chments/20160324/71e6b117/attachment.html><br><div><br></div>-----------= -------------------<br><div><br></div>_____________________________________= __________<br>Users mailing list<br>Users(a)ovirt.org<br>http://lists.ovirt.o= rg/mailman/listinfo/users<br><div><br></div><br>End of Users Digest, Vol 54= , Issue 113<br>**************************************<br></div><div><br></d= iv></div></body></html> ------=_Part_24992860_1266289793.1458819135011--

1 0

[ANN] oVirt 3.6.4 Second Release Candidate is now available for testing
by Sandro Bonazzola 24 Mar '16

24 Mar '16

The oVirt Project is pleased to announce the availability of the Second Release Candidate of oVirt 3.6.4 for testing, as of March 22nd, 2016 This release is available now for: * Fedora 22 * Red Hat Enterprise Linux 6.7 * CentOS Linux 6.7 (or similar) * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later This release supports Hypervisor Hosts running: * Red Hat Enterprise Linux 7.2 or later * CentOS Linux (or similar) 7.2 or later * Fedora 22 This release is also available with experimental support for: * Debian 8.3 Jessie This release candidate includes the following updated packages: - ovirt-engine - ovirt-hosted-engine-ha See the release notes [1] for installation / upgrade instructions and a list of new features and bugs fixed. Notes: * A new oVirt Live ISO will be available soon [2]. * Mirrors[3] might need up to one day to synchronize. Additional Resources: * Read more about the oVirt 3.6.3 release highlights: http://www.ovirt.org/release/3.6.4/ * Get more oVirt Project updates on Twitter: https://twitter.com/ovirt * Check out the latest project news on the oVirt blog: http://www.ovirt.org/blog/ [1] http://www.ovirt.org/release/3.6.4/ [2] http://resources.ovirt.org/pub/ovirt-3.6-pre/iso/ [3] http://www.ovirt.org/Repository_mirrors#Current_mirrors -- Sandro Bonazzola Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com

2 3

Storage Diversity Options oVirt 3.6
by Clint Boggio 23 Mar '16

23 Mar '16

Greetings all, and Happy Friday; I'm running oVirt 3.6 management engine that is currently overseeing 4 compute nodes, attached to iSCSI storage over Infiniband. The compute nodes have 8 hot-swap hard drive slots, with each only having 2 slots occupied in a hardware RAID array level one for the hypervisor to live on. Would it be possible for me to set up each compute node with a second array in the remaining 6 hot-swap slots, and utilize that new space for a nice fault tolerant GlusterFS storage array ? 1. Would the system allow me to add the Gluster storage to the existing datacenter/cluster that is currently using iSCSI ? 2. Would I be able to configure all aspects of the Gluster environment(except the hardware RAID array)through the GUI ? 3. What hardware RAID level would be optimal for this configuration ? (RHEV documentation says RAID 6 is "Mandatory") 4. Will the system support live migration between storage domains ? I'm reading through the gluster documentation now to get a better understanding of it's inner workings. Is there a good source for Gluster on oVirt that i can reference as well ?

2 2

[hosted-engine] The VDSM host was found in a failed state
by Wee Sritippho 23 Mar '16

23 Mar '16

Hi, I'm installing oVirt hosted-engine using a fibre channel storage. During the deployment I found this error: [ ERROR ] The VDSM host was found in a failed state. Please check engine and bootstrap installation logs. [ ERROR ] Unable to add hosted_engine_1 to the manager Tried to reinstall the host via web GUI, but got this error: Host hosted_engine_1 installation failed. Host is not reachable. How do I fix this? P.S. The log files were about 10 MB so I zipped it all Thank you, Wee --- ซอฟต์แวร์ Avast แอนตี้ไวรัสตรวจสอบหาไวรัสจากอีเมลนี้แล้ว https://www.avast.com/antivirus

2 2

glusterfs public key failure for rpm
by Fabrice Bacchella 23 Mar '16

23 Mar '16

--Apple-Mail=_14AE05D8-7DD7-4F82-A644-49C6A05FC3E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I tried to add a new host on a RHEL7, but it fails. In the ovirt-host-deploy-20160322171347-XXX-6ba9d4a3.log file, I found: warning: = /var/cache/yum/x86_64/7/ovirt-3.6-glusterfs-epel/packages/glusterfs-libs-3= .7.9-1.el7.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID d5dc52dc: = NOKEY Retrieving key from = https://download.gluster.org/pub/gluster/glusterfs/LATEST/pub.key 2016-03-22 17:13:41 ERROR otopi.plugins.otopi.packagers.yumpackager = yumpackager.error:100 Yum GPG key retrieval failed: [Errno 14] HTTPS = Error 404 - Not Found 2016-03-22 17:13:41 DEBUG otopi.context context._executeMethod:156 = method exception Traceback (most recent call last): File "/tmp/ovirt-6ocubrsLfP/pythonlib/otopi/context.py", line 146, in = _executeMethod method['method']() File = "/tmp/ovirt-6ocubrsLfP/otopi-plugins/otopi/packagers/yumpackager.py", = line 274, in _packages self._miniyum.processTransaction() File "/tmp/ovirt-6ocubrsLfP/pythonlib/otopi/miniyum.py", line 1054, in = processTransaction rpmDisplay=3Dself._RPMCallback(sink=3Dself._sink) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 6500, in = processTransaction self._checkSignatures(pkgs,callback) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 6543, in = _checkSignatures self.getKeyForPackage(po, self._askForGPGKeyImport) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 6194, in = getKeyForPackage keys =3D self._retrievePublicKey(keyurl, repo) File "/usr/lib/python2.7/site-packages/yum/__init__.py", line 6091, in = _retrievePublicKey exception2msg(e)) YumBaseError: GPG key retrieval failed: [Errno 14] HTTPS Error 404 - Not = Found In /etc/yum.repos.d/ovirt-3.6-dependencies.repo, I found : [ovirt-3.6-glusterfs-epel] name=3DGlusterFS is a clustered file-system capable of scaling to = several petabytes. = baseurl=3Dhttp://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.re= po/epel-$releasever/$basearch/ enabled=3D1 skip_if_unavailable=3D1 gpgcheck=3D1 gpgkey=3Dhttps://download.gluster.org/pub/gluster/glusterfs/LATEST/pub.key= This file is up to date I think : $ rpm -qf /etc/yum.repos.d/ovirt-3.6-dependencies.repo ovirt-release36-005-1.noarch $ yum update ... No packages marked for update If I try to download it : $ curl -ORLv = https://download.gluster.org/pub/gluster/glusterfs/LATEST/pub.key = <https://download.gluster.org/pub/gluster/glusterfs/LATEST/pub.key> ... < HTTP/1.1 404 Not Found I think the explanation are here : = https://download.gluster.org/pub/gluster/glusterfs/LATEST/NEW_PUBLIC_KEY.R= EADME = <https://download.gluster.org/pub/gluster/glusterfs/LATEST/NEW_PUBLIC_KEY.= README> Any thing I can do ? I don't even use glusterfs, I will be happy to disable it if I knew how. --Apple-Mail=_14AE05D8-7DD7-4F82-A644-49C6A05FC3E6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" = class=3D"">I tried to add a new host on a RHEL7, but it fails.<div = class=3D""><br class=3D""></div><div class=3D"">In the <span = style=3D"font-family: Menlo; font-size: 11px;" = class=3D"">ovirt-host-deploy-20160322171347-XXX-6ba9d4a3.log file, I = found:</span></div><div class=3D""><br class=3D""></div><div = class=3D""><div style=3D"margin: 0px; font-size: 11px; font-family: = Menlo;" class=3D"">warning: = /var/cache/yum/x86_64/7/ovirt-3.6-glusterfs-epel/packages/glusterfs-libs-3= .7.9-1.el7.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID d5dc52dc: = NOKEY</div><div style=3D"margin: 0px; font-size: 11px; font-family: = Menlo;" class=3D"">Retrieving key from <a = href=3D"https://download.gluster.org/pub/gluster/glusterfs/LATEST/pub.key"= = class=3D"">https://download.gluster.org/pub/gluster/glusterfs/LATEST/pub.k= ey</a></div><div style=3D"margin: 0px; font-size: 11px; font-family: = Menlo;" class=3D"">2016-03-22 17:13:41 ERROR = otopi.plugins.otopi.packagers.yumpackager yumpackager.error:100 Yum GPG = key retrieval failed: [Errno 14] HTTPS Error 404 - Not Found</div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D"">2016-03-22 17:13:41 DEBUG otopi.context = context._executeMethod:156 method exception</div><div style=3D"margin: = 0px; font-size: 11px; font-family: Menlo;" class=3D"">Traceback (most = recent call last):</div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">  File = "/tmp/ovirt-6ocubrsLfP/pythonlib/otopi/context.py", line 146, in = _executeMethod</div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">    = method['method']()</div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">  File = "/tmp/ovirt-6ocubrsLfP/otopi-plugins/otopi/packagers/yumpackager.py", = line 274, in _packages</div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">    = self._miniyum.processTransaction()</div><div style=3D"margin: 0px; = font-size: 11px; font-family: Menlo;" class=3D"">  File = "/tmp/ovirt-6ocubrsLfP/pythonlib/otopi/miniyum.py", line 1054, in = processTransaction</div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">    = rpmDisplay=3Dself._RPMCallback(sink=3Dself._sink)</div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D"">  File = "/usr/lib/python2.7/site-packages/yum/__init__.py", line 6500, in = processTransaction</div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">    = self._checkSignatures(pkgs,callback)</div><div style=3D"margin: 0px; = font-size: 11px; font-family: Menlo;" class=3D"">  File = "/usr/lib/python2.7/site-packages/yum/__init__.py", line 6543, in = _checkSignatures</div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">    self.getKeyForPackage(po, = self._askForGPGKeyImport)</div><div style=3D"margin: 0px; font-size: = 11px; font-family: Menlo;" class=3D"">  File = "/usr/lib/python2.7/site-packages/yum/__init__.py", line 6194, in = getKeyForPackage</div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">    keys =3D = self._retrievePublicKey(keyurl, repo)</div><div style=3D"margin: 0px; = font-size: 11px; font-family: Menlo;" class=3D"">  File = "/usr/lib/python2.7/site-packages/yum/__init__.py", line 6091, in = _retrievePublicKey</div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">    = exception2msg(e))</div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">YumBaseError: GPG key retrieval failed: = [Errno 14] HTTPS Error 404 - Not Found</div><div class=3D""><br = class=3D""></div><div class=3D""><br class=3D""></div><div = class=3D"">In <span style=3D"font-family: Menlo; font-size: 11px;" = class=3D"">/etc/yum.repos.d/</span><span style=3D"font-family: Menlo; = font-size: 11px;" class=3D"">ovirt-3.6-dependencies.repo, I found = :</span></div><div class=3D""><span style=3D"font-family: Menlo; = font-size: 11px;" class=3D""><br class=3D""></span></div><div = class=3D""><div style=3D"margin: 0px; font-size: 11px; font-family: = Menlo;" class=3D"">[ovirt-3.6-glusterfs-epel]</div><div style=3D"margin: = 0px; font-size: 11px; font-family: Menlo;" class=3D"">name=3DGlusterFS = is a clustered file-system capable of scaling to several = petabytes.</div><div style=3D"margin: 0px; font-size: 11px; font-family: = Menlo;" class=3D"">baseurl=3D<a = href=3D"http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.repo= /epel-$releasever/$basearch/" = class=3D"">http://download.gluster.org/pub/gluster/glusterfs/LATEST/EPEL.r= epo/epel-$releasever/$basearch/</a></div><div style=3D"margin: 0px; = font-size: 11px; font-family: Menlo;" class=3D"">enabled=3D1</div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D"">skip_if_unavailable=3D1</div><div style=3D"margin: 0px; = font-size: 11px; font-family: Menlo;" class=3D"">gpgcheck=3D1</div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D"">gpgkey=3D<a = href=3D"https://download.gluster.org/pub/gluster/glusterfs/LATEST/pub.key"= = class=3D"">https://download.gluster.org/pub/gluster/glusterfs/LATEST/pub.k= ey</a></div></div><div class=3D""><br class=3D""></div><div = class=3D"">This file is up to date I think :</div><div class=3D""><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" class=3D"">$ = rpm -qf /etc/yum.repos.d/ovirt-3.6-dependencies.repo</div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" = class=3D"">ovirt-release36-005-1.noarch</div></div><div style=3D"margin: = 0px; font-size: 11px; font-family: Menlo;" class=3D""><br = class=3D""></div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D""><div style=3D"margin: 0px;" class=3D"">$ = yum update</div><div style=3D"margin: 0px;" class=3D"">...</div><div = style=3D"margin: 0px;" class=3D""><div style=3D"margin: 0px;" = class=3D"">No packages marked for update</div><div class=3D""><br = class=3D""></div></div></div><div class=3D""><br class=3D""></div><div = class=3D"">If I try to download it :</div><div class=3D""><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;" class=3D"">$ = curl -ORLv <a = href=3D"https://download.gluster.org/pub/gluster/glusterfs/LATEST/pub.key"= = class=3D"">https://download.gluster.org/pub/gluster/glusterfs/LATEST/pub.k= ey</a></div></div><div style=3D"margin: 0px; font-size: 11px; = font-family: Menlo;" class=3D"">...</div><div style=3D"margin: 0px;" = class=3D""><div style=3D"font-family: Menlo; font-size: 11px; margin: = 0px;" class=3D"">< HTTP/1.1 404 Not Found</div><div = style=3D"font-family: Menlo; font-size: 11px;" class=3D""><br = class=3D""></div><div style=3D"font-family: Menlo; font-size: 11px;" = class=3D"">I think the explanation are here :</div><div class=3D""><font = face=3D"Menlo" class=3D""><span style=3D"font-size: 11px;" class=3D""><a = href=3D"https://download.gluster.org/pub/gluster/glusterfs/LATEST/NEW_PUBL= IC_KEY.README" = class=3D"">https://download.gluster.org/pub/gluster/glusterfs/LATEST/NEW_P= UBLIC_KEY.README</a></span></font></div><div class=3D""><font = face=3D"Menlo" class=3D""><span style=3D"font-size: 11px;" class=3D""><br = class=3D""></span></font></div><div class=3D""><font face=3D"Menlo" = class=3D""><span style=3D"font-size: 11px;" class=3D"">Any thing I can = do ?</span></font></div><div class=3D""><font face=3D"Menlo" = class=3D""><span style=3D"font-size: 11px;" class=3D""><br = class=3D""></span></font></div><div class=3D""><font face=3D"Menlo" = class=3D""><span style=3D"font-size: 11px;" class=3D"">I don't even use = glusterfs, I will be happy to disable it if I knew = how.</span></font></div><div class=3D""><font face=3D"Menlo" = class=3D""><span style=3D"font-size: 11px;" class=3D""><br = class=3D""></span></font></div><div class=3D""><font face=3D"Menlo" = class=3D""><span style=3D"font-size: 11px;" class=3D""><br = class=3D""></span></font></div><div style=3D"font-family: Menlo; = font-size: 11px;" class=3D""><br class=3D""></div></div><div = class=3D""><div class=3D""><br class=3D""></div><div class=3D""><br = class=3D""></div></div></div></body></html>= --Apple-Mail=_14AE05D8-7DD7-4F82-A644-49C6A05FC3E6--

4 4

NFS firewall rule
by Bill James 23 Mar '16

23 Mar '16

How do I make it that when ever I add or reinstall a hardware node that oVirt creates a rule for NFS, port 2049? I have to either add it manually after ovirt removes it, or just tell ovirt not to touch firewall rules. Our ISO domain is not hosted by the ovirt-engine, fyi. ovirt-engine-3.6.3.4-1.el7.centos.noarch

2 3

Re: [ovirt-users] Where to add NFS Data Storage
by Taste-Of-IT 22 Mar '16

22 Mar '16

Hello Joop, thanks for help. I tried now with fresh installation, but i have to enter a first storage domain to the nfs path i created. So the question is which path i have to add in engine? Create a new one on host and add in engine? thx Am 2016-03-20 14:34, schrieb Joop: > On 20-3-2016 11:49, Taste-Of-IT wrote: >> Hello Joop, >> >> actually right after the installation i have no storage domain. so >> what have i to do in detail? my installation path at installation are >> /var/ovirt/exports/data and /var/ovirt/exports/iso. the data i added >> at installation for the host. at engine installation i say no to >> storage domain. as far as i see and understand i have no storage >> domain in cluster, also for default and those i added in installation >> process of host. >> >> so what have i todo in detail? > What I did was the following (probably missing quite a few steps) > - create (minimum) two folders, one for hosted-engine storage, one for > data storage, iso and export optional > - create exports in /etc/exports > - start nfs server > - make sure permissions are 36:36 on the exports > - start the nfs server > - check if the mounts work (problem areas are: iptables/selinux) > > - install ovirt repo > - install hosted-engine > - run 'hosted-engine --deploy' > - I installed from centos-7 iso but appliance should work too, no > experience with it > - enter the correct path when asked for the hosted storage, nfs and > fqdn:/path-to-nfs-he-share > - follow the instruction, not much needs changing from the default > - Networkmanager still seems a problem, use static ip, don't try to > bridge wifi :-) > - If the engine is started using the ha-agent/broker it can take a > while > before the webui is available > - If everything goes OK engine will claim and insert the hosted storage > domain in the database and make it visible in the webui > - DONT use it for VMs > - create a new data domain on fqdn:/nfs/ovirt/data (or whatever your > path is) > - wait until its up > - start creating VMs > > My case is a laptop running F22 with hosted-engine on it using a nfs > server provided by my F22 host, engine itself is Centos7. > So all storage is on my host but if I want I can move it somewhere > else, > add storage from somewhere else because I'm nog using local storage > domain. Only thing is the overhead of the network filesystem that being > either NFS/GlusterFS/ISCSI. > > There are some guides on how to setup oVirt using hosted-engine but to > be honest its hard to find on the current site and searching on > old.ovirt-.org doesn't work :-( > > Let me know how far you get and maybe I can help you further if you get > stuck. > > Joop

2 4

Windows 2012 R2 VM on OVIRT
by Bill Michelon 22 Mar '16

22 Mar '16

This is a multi-part MIME message. --=_reb-r6510EC4B-t56E95ECE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksIEkgaGF2ZSBzZXQgdXAgYSBXaW5kb3dzIDIwMTIgUjIgdm0gaW4gT1ZJUlQuICBJIGhh dmUgdHJpZWQgdXNpbmcgZTEwMDAgYW5kIHZpcnRpbyBkcml2ZXJzIGZvciBuZXR3b3JrIGNv bm5lY3Rpb24uICBJIGFtIGFibGUgdG8gZXN0YWJsaXNoIGEgY29ubmVjdGlvbiwgaG93ZXZl ciwgY2Fubm90IGFjY2VzcyBpbnRlcm5ldC4gIERlc3BpdGUgdGhlIGZhY3QgdGhlIGNvbm5l Y3Rpb24gc2hvd3MgSW50ZXJuZXQsIHJlY2VpdmVkIGFuZCBzZW50IGJ5dGVzIHNlZW0gdmVy eSBsb3cuDQoNCkhhcyBhbnlvbmUgc2VlbiB0aGlzIGlzc3VlIGFuZCBjYW4gaGVscD8NCg0K VGhhbmsgeW91Lg0KDQoNCkJpbGwgTWljaGVsb24NCkdsb2JhbCBJVCAmIExvZ2lzdGljcyBN YW5hZ2VyDQpBY2NlcnRpZnksIEluYy4NCg0KDQoNCg0KDQoiVGhpcyBtZXNzYWdlIGFuZCBh bnkgYXR0YWNobWVudHMgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLiBJ ZiB5b3UNCmhhdmUgcmVjZWl2ZWQgdGhpcyAgbWVzc2FnZSBpbiBlcnJvciwgYW55IHVzZSBv ciBkaXN0cmlidXRpb24gaXMgcHJvaGliaXRlZC4gDQpQbGVhc2Ugbm90aWZ5IHVzIGJ5IHJl cGx5IGUtbWFpbCBpZiB5b3UgaGF2ZSBtaXN0YWtlbmx5IHJlY2VpdmVkIHRoaXMgbWVzc2Fn ZSwNCmFuZCBpbW1lZGlhdGVseSBhbmQgcGVybWFuZW50bHkgZGVsZXRlIGl0IGFuZCBhbnkg YXR0YWNobWVudHMuIFRoYW5rIHlvdS4i --=_reb-r6510EC4B-t56E95ECE Content-Type: text/html; charset="utf-8" Content-ID: <F07624AB918DC244A0F0C08A7F62A1D8(a)sh11.lan> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3 b3JkLXdyYXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtp dC1saW5lLWJyZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsg Zm9udC1zaXplOiAxNHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0K PGRpdj5IaSwgSSBoYXZlIHNldCB1cCBhIFdpbmRvd3MgMjAxMiBSMiB2bSBpbiBPVklSVC4g Jm5ic3A7SSBoYXZlIHRyaWVkIHVzaW5nIGUxMDAwIGFuZCB2aXJ0aW8gZHJpdmVycyBmb3Ig bmV0d29yayBjb25uZWN0aW9uLiAmbmJzcDtJIGFtIGFibGUgdG8gZXN0YWJsaXNoIGEgY29u bmVjdGlvbiwgaG93ZXZlciwgY2Fubm90IGFjY2VzcyBpbnRlcm5ldC4gJm5ic3A7RGVzcGl0 ZSB0aGUgZmFjdCB0aGUgY29ubmVjdGlvbiBzaG93cyBJbnRlcm5ldCwgcmVjZWl2ZWQgYW5k IHNlbnQNCiBieXRlcyBzZWVtIHZlcnkgbG93LjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+SGFzIGFueW9uZSBzZWVuIHRoaXMgaXNzdWUgYW5kIGNhbiBoZWxwPzwvZGl2Pg0K PGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+VGhhbmsgeW91LjwvZGl2Pg0KPGRpdj48YnI+DQo8 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdiBpZD0iIj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAxcHQ7IGZvbnQtc2l6 ZTogMTFwdDsiPjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6 IEFyaWFsLCBzYW5zLXNlcmlmOyBjb2xvcjogcmdiKDMxLCA3MywgMTI1KTsiPkJpbGwgTWlj aGVsb248L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDE0cHQ7IGNvbG9yOiBy Z2IoMzEsIDczLCAxMjUpOyI+PGJyPg0KPC9zcGFuPjxiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6IDEwcHQ7IGZvbnQtZmFtaWx5OiBBcmlhbCwgc2Fucy1zZXJpZjsgY29sb3I6IHJnYigz OCwgMzgsIDM4KTsiPkdsb2JhbCBJVCAmYW1wOyBMb2dpc3RpY3MgTWFuYWdlcjwvc3Bhbj48 L2I+PHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+PGJyPg0KPC9zcGFu PjxiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6IDlwdDsgZm9udC1mYW1pbHk6IEFyaWFsLCBz YW5zLXNlcmlmOyBjb2xvcjogcmdiKDE5MiwgMCwgMCk7Ij5BY2NlcnRpZnksIEluYy48bzpw PjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h cmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXplOiAxMXB0OyI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZTogOXB0OyBmb250LWZhbWlseTogQXJpYWwsIHNhbnMtc2VyaWY7IGNv bG9yOiByZ2IoMTkyLCAwLCAwKTsiPiZuYnNwOzwvc3Bhbj48L2I+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsgZm9udC1zaXpl OiAxMXB0OyI+PGJyPg0KPHNwYW4gc3R5bGU9ImNvbG9yOiByZ2IoMzEsIDczLCAxMjUpOyI+ PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQoNCg0KPHBy ZT4NCg0KIlRoaXMgbWVzc2FnZSBhbmQgYW55IGF0dGFjaG1lbnRzIG1heSBjb250YWluIGNv bmZpZGVudGlhbCBpbmZvcm1hdGlvbi4gSWYgeW91DQpoYXZlIHJlY2VpdmVkIHRoaXMgIG1l c3NhZ2UgaW4gZXJyb3IsIGFueSB1c2Ugb3IgZGlzdHJpYnV0aW9uIGlzIHByb2hpYml0ZWQu IA0KUGxlYXNlIG5vdGlmeSB1cyBieSByZXBseSBlLW1haWwgaWYgeW91IGhhdmUgbWlzdGFr ZW5seSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UsDQphbmQgaW1tZWRpYXRlbHkgYW5kIHBlcm1h bmVudGx5IGRlbGV0ZSBpdCBhbmQgYW55IGF0dGFjaG1lbnRzLiBUaGFuayB5b3UuIjwvcHJl Pg0K --=_reb-r6510EC4B-t56E95ECE--

3 6

can't add new host because gluster key file name changed
by Robert Story 21 Mar '16

21 Mar '16

--Sig_/xu2kUSt=2MxpNT++Hm/Hx_s Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Hello, I'm trying to add a host to a 3.5 cluster, and it's failing because gluster folks apparently created a new key and renamed the file... warning: /var/cache/yum/x86_64/7/ovirt-3.5-glusterfs-epel/packages/glusterf= s-libs-3.7.9-1.el7.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID d5dc5= 2dc: NOKEY Retrieving key from https://download.gluster.org/pub/gluster/glusterfs/LATE= ST/pub.key see https://download.gluster.org/pub/gluster/glusterfs/LATEST/NEW_PUBLIC_KEY.R= EADME and https://download.gluster.org/pub/gluster/glusterfs/LATEST/rsa.pub Is there a workaround? Robert --=20 Senior Software Engineer @ Parsons --Sig_/xu2kUSt=2MxpNT++Hm/Hx_s Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAlbwGzgACgkQ7/fVLLY1mnjBWgCffWFrSLiHhK0xpT9zZe1ItSBZ thQAn3/YrQlylorTOGKdb+6/wTyE7T5C =duNk -----END PGP SIGNATURE----- --Sig_/xu2kUSt=2MxpNT++Hm/Hx_s--

3 3

Shared storage
by Maton, Brett 21 Mar '16

21 Mar '16

Hello list, I was wondering if any one could tell me if a Dell MD1400 Direct Attached Storage unit is suitable for shared storage between ovirt hosts? I really don't want to buy something that isn't going to work :) Regards, Brett

4 3

How to use /etc/ovirt-hosted-engine-setup.env.d/ ?
by Pat Riehecky 21 Mar '16

21 Mar '16

I'd like to pre-seed answers to several of the hosted-engine setup question, but can't seem to find any instructions on how to pass answers into hosted-engine. I tried the same tactics as with engine-setup, but those netted no results. Pat -- Pat Riehecky Scientific Linux developer Fermi National Accelerator Laboratory www.fnal.gov www.scientificlinux.org

2 1

Trouble configuring ISO domain on oVirt 3.5
by Hal Martin 21 Mar '16

21 Mar '16

Hello everyone, Please excuse me if this question has been asked before, I've searched the mailing list archives and can't find someone having the same problem as I am. I have a new oVirt installation that I'm trying to configure, and I cannot get the ISO domain I configured during engine-setup to show in the UI at all. Installation layout: # Engine CentOS 7 - oVirt Engine 3.5 (VM on different, non-oVirt cluster) # Nodes de-fra-p-hv05 - oVirt Node 3.5 de-fra-p-hv06 - oVirt Node 3.5 I installed and configured the engine, but the node that runs the engine is a VM, and will not be running VMs itself. I intend to use it only as a management node (in the VMWare world this would be analogous to the vCenter server). I don't want to run hosted engine because that requires me to install Fedora/CentOS on the blades. I would much rather have the engine live on a different cluster and just run oVirt node on the blades. I am able to install the nodes successfully, and configure them from within the engine UI. I am using an iSCSI SAN for VM storage. As per the Quick Setup guide, I have configured my iSCSI network on the nodes and created an iSCSI storage domain for VMs. Where I am utterly stuck is the creation of the ISO domain: http://www.ovirt.org/documentation/quickstart/quickstart-guide/#Attach_an_I… Since the server running oVirt engine is not participating in the cluster, it doesn't appear in my data center. This might be my problem, but I'm not sure. Here's a summary of the data center I have configured thus far: System |- Data Centers |- Default |- Storage |- sanQA |- Networks |- ovirtmgmt |- hpmsa |- vmnet128 |- Clusters |- QA |- Hosts |- de-fra-p-hv05 |- de-fra-p-hv06 I have edited the ACL on the server running oVirt engine to allow rw access on /var/lib/exports/iso to nodes de-fra-p-hv05 and de-fra-p-hv06. $ cat /etc/exports.d/ovirt-engine-iso-domain.exports /var/lib/exports/iso de-fra-p-ove01.domain.xyz(rw) /var/lib/exports/iso 172.20.102.215(rw) /var/lib/exports/iso 172.20.102.216(rw) When I try to import an ISO domain in the Data Center -> Storage tab, I get the following error: "Error while executing action: Cannot add Storage Connection. Storage connection already exists." Attached is the engine log from attempting to import the ISO domain. I don't have any ISO domain visible in the Storage tab of my data center. Since I cannot see the ISO domain in the UI, I cannot create new virtual machines on my cluster. Please help me understand what I've done wrong. I've also attached a screenshot of the management interface. As you can see, I've configured an iSCSI domain. I see no button in the UI to "Attach ISO" http://www.ovirt.org/documentation/quickstart/quickstart-guide/#Attach_an_I… Thank you, Hal

2 2