date:20160606

Re: [ovirt-users] virt-in-virt problem: DHCP failing for a container in a oVirt VM

2016-06-06 Thread Will Dennis

Sorry, got away from this for a while attending to other work, but back at it 
now... Anyone have any ideas on how I may further troubleshoot this issue?

Thanks

-Original Message-
From: Will Dennis 
Sent: Wednesday, May 18, 2016 11:39 AM
To: 'Michal Skrivanek'; 'Yedidyah Bar David'
Cc: 'users@ovirt.org'
Subject: RE: [ovirt-users] virt-in-virt problem: DHCP failing for a container 
in a oVirt VM

Sadly, having set the 'macspoof' key to 'true' in Custom Properties in the VM 
Edit dialog, then restarting the VM thereafter, I'm still not seeing the 
container's MAC address in the relevant bridge's MAC table in oVirt, and the 
container is failing to lease a DHCP address from the external network... 

Looked at the ebtables filter table, nothing there...
[root@ovirt-node-03 ~]# ebtables -t filter -L Bridge table: filter

Bridge chain: INPUT, entries: 0, policy: ACCEPT

Bridge chain: FORWARD, entries: 0, policy: ACCEPT

Bridge chain: OUTPUT, entries: 0, policy: ACCEPT

Anyone know where else I could look to troubleshoot?

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

Re: [ovirt-users] strange API parameters default in python SDK

2016-06-06 Thread Jamie Lawrence

> On Jun 6, 2016, at 1:59 AM, Fabrice Bacchella  
> wrote:

> I'm surprised, because in my mind, the default value are the least usefull 
> version of each options. Why don't set them to good, useful values and let 
> the user changed them to the opposite if there is some problems ?

I’m not a developer, but it looks to me like the defaults are chosen to be the 
safe out of the box.

Defaults are tricky, because everyone’s needs are different. (Otherwise if 
everyone wants the same setting, why make it an option?) So not everyone gets 
what they want out of the box, and when choosing them, there needs to be some 
principle guiding the choice, otherwise it is hard for users to develop a 
“feel” for the software and the lack of consistency causes everyone problems. 

The guiding principle you want seems to be ease of use. That’s valid, but with 
software like this, I think it is likely that a lot of folks would prefer 
safety out of the box. Imagine if you had requirements to install and lock 
Ovirt down to some meet specific criteria. If it shipped with a wide-open 
security policy and you were not yet fluent in using it, you’re going to have 
trouble locking it down and probably continue to wonder if you found every 
relevant knob.

The reverse - opening it up - is generally much easier (especially when you’re 
new to complex software) and at least sometimes less dangerous if you get it 
wrong (if it isn’t as open as you’d like), so at least in my view, defaulting 
to locked-down makes more sense.

My $.02,

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

Re: [ovirt-users] qemu cgroup_controllers

2016-06-06 Thread Martin Polednik


On 06/06/16 16:15 +0300, Дмитрий Глушенок wrote:

So, libvirt behaves differently with custom partition? My assumption was that 
it will perform the same changes. I will have in mind in case oVirt 4 will be 
released too late.
May be I wrote incorrectly - in oVirt 4.0 RC1 scsi pass-through already working.


It should be working.


--
Dmitry Glushenok
Jet Infosystems
http://www.jet.msk.su +7-495-411-7601 (ext. 1237)


6 июня 2016 г., в 13:35, Martin Polednik  написал(а):

On 06/06/16 13:26 +0300, Дмитрий Глушенок wrote:

Hello Martin,

Thank you for your time. It is clear how to create partition and assign it to a 
VM. But libvirt manipulates with contents of devices.list and I didn't find a 
way to put my devices into devices.list and stop libvirt from removing them.


That is, by the way, pretty interesting. I have tried it right now and
when using custom partition, libvirt doesn't touch my devices.list.

It might make sense to file a libvirt bug.


Anyway, it looks like that the best solution will be using oVirt 4.0 where scsi 
pass-through have been fixed.


Hoping so!


--
Dmitry Glushenok
Jet Infosystems
http://www.jet.msk.su +7-495-411-7601 (ext. 1237)


6 июня 2016 г., в 12:33, Martin Polednik  написал(а):

On 03/06/16 14:05 +0300, Дмитрий Глушенок wrote:

Thank you Martin!

Actually I tried the workaround hook, provided in [2], but then VDSM (oVirt 
3.6.6) tries to interpret hostdev in XML as PCI device, which leads to:

::The vm start process failed
Traceback (most recent call last):
File "/usr/share/vdsm/virt/vm.py", line 703, in _startUnderlyingVm
 self._run()
File "/usr/share/vdsm/virt/vm.py", line 1949, in _run
 self._domDependentInit()
File "/usr/share/vdsm/virt/vm.py", line 1797, in _domDependentInit
 self._getUnderlyingVmDevicesInfo()
File "/usr/share/vdsm/virt/vm.py", line 1738, in _getUnderlyingVmDevicesInfo
 self._getUnderlyingHostDeviceInfo()
File "/usr/share/vdsm/virt/vm.py", line 4277, in _getUnderlyingHostDeviceInfo
 **self._getUnderlyingDeviceAddress(source))
TypeError: pci_address_to_name() got an unexpected keyword argument 'target'

XML part was:














As of creating custom partition - by default machine.slice has "a *:* rwm" in 
devices.list. But for every new VM libvirt removes *:* mask and fills the list with 
actually needed devices (as I understand the process). For example:

c 136:* rw
c 1:3 rw
c 1:7 rw
c 1:5 rw
c 1:8 rw
c 1:9 rw
c 5:2 rw
c 10:232 rw
c 253:0 rw
c 10:228 rw
c 10:196 rw

What I'm looking for is a way to tell libvirt about my additional devices 
without breaking oVirt.


The solution would be creating your own partition and somehow (e.g.
VDSM hook) appending


 /machine/custom


to the libvirt's  element. I'm not sure how feasible creating
your own partition is though. I've tried the process as follows:

$ cat ~/create-partition.sh
# sh ~/create-partition.sh
for i in blkio cpu,cpuacct cpuset devices freezer memory net_cls perf_event
do
 mkdir /sys/fs/cgroup/$i/machine.slice/custom.partition
done

for i in cpuset.cpus cpuset.mems
do
 cat /sys/fs/cgroup/cpuset/machine.slice/$i > 
/sys/fs/cgroup/cpuset/machine.slice/custom.partition/$i
done

(creates /machine/custom partition).
Now, we can create vdsm before_vm_start hook that will set given partition
for the VM:

$ pwd /usr/libexec/vdsm/hooks/before_vm_start
$ cat 10_cgroups

#!/usr/bin/python

import hooking


def custom_partition(domxml):
 resource = domxml.createElement('resource')
 partition = domxml.createElement('partition')
 partition_text = domxml.createTextNode('/machine/custom')
 partition.appendChild(partition_text)
 resource.appendChild(partition)

 return resource

domxml = hooking.read_domxml()
domain = domxml.getElementsByTagName('domain')[0]
domain.appendChild(custom_partition(domxml))
hooking.write_domxml(domxml)


--
Dmitry Glushenok
Jet Infosystems
http://www.jet.msk.su
+7-495-411-7601 (ext. 1237)


3 июня 2016 г., в 12:24, Martin Polednik  написал(а):

On 03/06/16 11:48 +0300, Дмитрий Глушенок wrote:

Hello!

Is it possible to tell libvirt to add specific devices to qemu cgroup? By 
somehow enumerating the devices in XML using a hook for example.
I'm passing scsi-generic disks (/dev/sgX) to VM using qemucmdline hook and it doesn't 
work until I remove "devices" from cgroup_controllers in qemu.conf.


One way to achieve this is creating a hook to generate the scsi device
XML instead of modifying qemu cmdline directly. Libvirt assumes
ownership of all devices created in the XML and therefore adds them to
the machine cgroup.

Example of the XML taken from [1]:











There is slight issue with this approach outlined in [2].

If you want to keep the qemu approach, I think creating a custom
partition and moving devices there would be the

Re: [ovirt-users] qemu cgroup_controllers

2016-06-06 Thread Дмитрий Глушенок

So, libvirt behaves differently with custom partition? My assumption was that 
it will perform the same changes. I will have in mind in case oVirt 4 will be 
released too late.
May be I wrote incorrectly - in oVirt 4.0 RC1 scsi pass-through already working.

--
Dmitry Glushenok
Jet Infosystems
http://www.jet.msk.su +7-495-411-7601 (ext. 1237)

> 6 июня 2016 г., в 13:35, Martin Polednik  написал(а):
> 
> On 06/06/16 13:26 +0300, Дмитрий Глушенок wrote:
>> Hello Martin,
>> 
>> Thank you for your time. It is clear how to create partition and assign it 
>> to a VM. But libvirt manipulates with contents of devices.list and I didn't 
>> find a way to put my devices into devices.list and stop libvirt from 
>> removing them.
> 
> That is, by the way, pretty interesting. I have tried it right now and
> when using custom partition, libvirt doesn't touch my devices.list.
> 
> It might make sense to file a libvirt bug.
> 
>> Anyway, it looks like that the best solution will be using oVirt 4.0 where 
>> scsi pass-through have been fixed.
> 
> Hoping so!
> 
>> --
>> Dmitry Glushenok
>> Jet Infosystems
>> http://www.jet.msk.su +7-495-411-7601 (ext. 1237)
>> 
>>> 6 июня 2016 г., в 12:33, Martin Polednik  написал(а):
>>> 
>>> On 03/06/16 14:05 +0300, Дмитрий Глушенок wrote:
 Thank you Martin!
 
 Actually I tried the workaround hook, provided in [2], but then VDSM 
 (oVirt 3.6.6) tries to interpret hostdev in XML as PCI device, which leads 
 to:
 
 ::The vm start process failed
 Traceback (most recent call last):
 File "/usr/share/vdsm/virt/vm.py", line 703, in _startUnderlyingVm
  self._run()
 File "/usr/share/vdsm/virt/vm.py", line 1949, in _run
  self._domDependentInit()
 File "/usr/share/vdsm/virt/vm.py", line 1797, in _domDependentInit
  self._getUnderlyingVmDevicesInfo()
 File "/usr/share/vdsm/virt/vm.py", line 1738, in 
 _getUnderlyingVmDevicesInfo
  self._getUnderlyingHostDeviceInfo()
 File "/usr/share/vdsm/virt/vm.py", line 4277, in 
 _getUnderlyingHostDeviceInfo
  **self._getUnderlyingDeviceAddress(source))
 TypeError: pci_address_to_name() got an unexpected keyword argument 
 'target'
 
 XML part was:
 




 
 




 
 
 
 As of creating custom partition - by default machine.slice has "a *:* rwm" 
 in devices.list. But for every new VM libvirt removes *:* mask and fills 
 the list with actually needed devices (as I understand the process). For 
 example:
 
 c 136:* rw
 c 1:3 rw
 c 1:7 rw
 c 1:5 rw
 c 1:8 rw
 c 1:9 rw
 c 5:2 rw
 c 10:232 rw
 c 253:0 rw
 c 10:228 rw
 c 10:196 rw
 
 What I'm looking for is a way to tell libvirt about my additional devices 
 without breaking oVirt.
>>> 
>>> The solution would be creating your own partition and somehow (e.g.
>>> VDSM hook) appending
>>> 
>>> 
>>>  /machine/custom
>>> 
>>> 
>>> to the libvirt's  element. I'm not sure how feasible creating
>>> your own partition is though. I've tried the process as follows:
>>> 
>>> $ cat ~/create-partition.sh
>>> # sh ~/create-partition.sh
>>> for i in blkio cpu,cpuacct cpuset devices freezer memory net_cls perf_event
>>> do
>>>  mkdir /sys/fs/cgroup/$i/machine.slice/custom.partition
>>> done
>>> 
>>> for i in cpuset.cpus cpuset.mems
>>> do
>>>  cat /sys/fs/cgroup/cpuset/machine.slice/$i > 
>>> /sys/fs/cgroup/cpuset/machine.slice/custom.partition/$i
>>> done
>>> 
>>> (creates /machine/custom partition).
>>> Now, we can create vdsm before_vm_start hook that will set given partition
>>> for the VM:
>>> 
>>> $ pwd /usr/libexec/vdsm/hooks/before_vm_start
>>> $ cat 10_cgroups
>>> 
>>> #!/usr/bin/python
>>> 
>>> import hooking
>>> 
>>> 
>>> def custom_partition(domxml):
>>>  resource = domxml.createElement('resource')
>>>  partition = domxml.createElement('partition')
>>>  partition_text = domxml.createTextNode('/machine/custom')
>>>  partition.appendChild(partition_text)
>>>  resource.appendChild(partition)
>>> 
>>>  return resource
>>> 
>>> domxml = hooking.read_domxml()
>>> domain = domxml.getElementsByTagName('domain')[0]
>>> domain.appendChild(custom_partition(domxml))
>>> hooking.write_domxml(domxml)
>>> 
 --
 Dmitry Glushenok
 Jet Infosystems
 http://www.jet.msk.su
 +7-495-411-7601 (ext. 1237)
 
> 3 июня 2016 г., в 12:24, Martin Polednik  
> написал(а):
> 
> On 03/06/16 11:48 +0300, Дмитрий Глушенок wrote:
>> Hello!
>> 
>> Is it possible to tell libvirt to add specific devices to qemu cgroup? 
>> By somehow enumerating the devices in XML using a hook for example.
>> I'm passing scsi-generic disks (/dev/sgX) to VM using qemucmdline hook 
>> and it doesn't work until I remove

Re: [ovirt-users] free-IPA Multi-Master Authentication Problem

2016-06-06 Thread Ondra Machacek


It looks fine, thanks.
Looking at the oVirt log I see IPA server FQDN:

 auth02.intern.customer-virt.eu.intern.customer-virt.eu

Looking at krb realm, I guess this should be - 
auth02.intern.customer-virt.eu


Do you use SRV records or did you pass --ldap-servers to manage-domains?
If SRV, then you maybe misconfigured DNS, if --ldap-servers, you should 
edit configuration with proper FQDN.


On 06/06/2016 11:00 AM, Kilian Ries wrote:

Hello,

here is the krb5kdc log from IPA2:


###
Jun 03 17:18:22 auth02.intern.customer-virt.eu krb5kdc[1283](info): AS_REQ (1 
etypes {23}) 192.168.210.45: NEEDED_PREAUTH: kr...@intern.customer-virt.eu for 
krbtgt/intern.customer-virt...@intern.customer-virt.eu, Additional 
pre-authentication required
Jun 03 17:18:22 auth02.intern.customer-virt.eu krb5kdc[1283](info): closing 
down fd 12
Jun 03 17:18:22 auth02.intern.customer-virt.eu krb5kdc[1283](info): AS_REQ (1 
etypes {23}) 192.168.210.45: ISSUE: authtime 1464967102, etypes {rep=23 tkt=18 
ses=23}, kr...@intern.customer-virt.eu for 
krbtgt/intern.customer-virt...@intern.customer-virt.eu
Jun 03 17:18:22 auth02.intern.customer-virt.eu krb5kdc[1283](info): closing 
down fd 12
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1283](info): AS_REQ (1 
etypes {23}) 192.168.210.45: NEEDED_PREAUTH: kr...@intern.customer-virt.eu for 
krbtgt/intern.customer-virt...@intern.customer-virt.eu, Additional 
pre-authentication required
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1283](info): closing 
down fd 12
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1284](info): AS_REQ (1 
etypes {23}) 192.168.210.45: ISSUE: authtime 1464967120, etypes {rep=23 tkt=18 
ses=23}, kr...@intern.customer-virt.eu for 
krbtgt/intern.customer-virt...@intern.customer-virt.eu
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1284](info): closing 
down fd 12
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1283](info): AS_REQ (1 
etypes {23}) 192.168.210.45: NEEDED_PREAUTH: kr...@intern.customer-virt.eu for 
krbtgt/intern.customer-virt...@intern.customer-virt.eu, Additional 
pre-authentication required
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1283](info): closing 
down fd 12
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1284](info): AS_REQ (1 
etypes {23}) 192.168.210.45: ISSUE: authtime 1464967120, etypes {rep=23 tkt=18 
ses=23}, kr...@intern.customer-virt.eu for 
krbtgt/intern.customer-virt...@intern.customer-virt.eu
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1284](info): closing 
down fd 12
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1283](info): TGS_REQ (6 
etypes {18 17 16 23 1 3}) 192.168.210.45: ISSUE: authtime 1464967120, etypes 
{rep=23 tkt=18 ses=18}, kr...@intern.customer-virt.eu for 
ldap/auth02.intern.customer-virt...@intern.customer-virt.eu
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1283](info): closing 
down fd 12
###

Thanks for the hint with the LDAP-Provider, i'm trying to migrate as soon as 
possible.

Greets
Kilian


Von: Ondra Machacek 
Gesendet: Montag, 6. Juni 2016 09:48
An: Kilian Ries; users@ovirt.org
Betreff: Re: [ovirt-users] free-IPA Multi-Master Authentication Problem

On 06/03/2016 05:44 PM, Kilian Ries wrote:

Hi,


i have two free-IPA directories setup in multi-master replication. Both
are running on CentOS 7.2 with latest Software installed. Replication
between both IPAs is setup correctly and i am able to authenticate
against each of the two manually.


However, if i shutdown IPA1 and try to authenticate from oVirt 3.5.6.2
against IPA2 i can't login. Login is only working if IPA1 is
running (keep in mind that manual authentication against IPA2 is working).


In the dirSRV Error-Logfile nothing is logged, however i can see the
authentication in the access log from IPA2:



###


filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/intern.customer-virt...@intern.customer-virt.eu)(krbPrincipalName=krbtgt/intern.customer-virt...@intern.customer-virt.eu)))"
attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias
krbUPEnabled krbPrincipalKey krbTicketPolicyReference
krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference
krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases
krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData
krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife
krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData
ipaUserAuthType ipatokenRadiusConfigLink objectClass"

[03/Jun/2016:17:18:39 +0200] conn=5 op=758 RESULT err=0 tag=101
nentries=1 etime=0

[03/Jun/2016:17:18:39 +0200] conn=5 op=759 SRCH
base="cn=global_policy,cn=INTERN.CUSTOMER-VIRT.EU,cn=kerberos,dc=intern,dc=customer-virt,dc=eu"
scope=0 filter="(objectClass=*)" attrs="krbMaxPwdLife krbMinPwdLife
krbPwdMinDiffChars krbPwdMinLength

Re: [ovirt-users] qemu cgroup_controllers

2016-06-06 Thread Martin Polednik


On 06/06/16 13:26 +0300, Дмитрий Глушенок wrote:

Hello Martin,

Thank you for your time. It is clear how to create partition and assign it to a 
VM. But libvirt manipulates with contents of devices.list and I didn't find a 
way to put my devices into devices.list and stop libvirt from removing them.


That is, by the way, pretty interesting. I have tried it right now and
when using custom partition, libvirt doesn't touch my devices.list.

It might make sense to file a libvirt bug.


Anyway, it looks like that the best solution will be using oVirt 4.0 where scsi 
pass-through have been fixed.


Hoping so!


--
Dmitry Glushenok
Jet Infosystems
http://www.jet.msk.su +7-495-411-7601 (ext. 1237)


6 июня 2016 г., в 12:33, Martin Polednik  написал(а):

On 03/06/16 14:05 +0300, Дмитрий Глушенок wrote:

Thank you Martin!

Actually I tried the workaround hook, provided in [2], but then VDSM (oVirt 
3.6.6) tries to interpret hostdev in XML as PCI device, which leads to:

::The vm start process failed
Traceback (most recent call last):
File "/usr/share/vdsm/virt/vm.py", line 703, in _startUnderlyingVm
  self._run()
File "/usr/share/vdsm/virt/vm.py", line 1949, in _run
  self._domDependentInit()
File "/usr/share/vdsm/virt/vm.py", line 1797, in _domDependentInit
  self._getUnderlyingVmDevicesInfo()
File "/usr/share/vdsm/virt/vm.py", line 1738, in _getUnderlyingVmDevicesInfo
  self._getUnderlyingHostDeviceInfo()
File "/usr/share/vdsm/virt/vm.py", line 4277, in _getUnderlyingHostDeviceInfo
  **self._getUnderlyingDeviceAddress(source))
TypeError: pci_address_to_name() got an unexpected keyword argument 'target'

XML part was:














As of creating custom partition - by default machine.slice has "a *:* rwm" in 
devices.list. But for every new VM libvirt removes *:* mask and fills the list with 
actually needed devices (as I understand the process). For example:

c 136:* rw
c 1:3 rw
c 1:7 rw
c 1:5 rw
c 1:8 rw
c 1:9 rw
c 5:2 rw
c 10:232 rw
c 253:0 rw
c 10:228 rw
c 10:196 rw

What I'm looking for is a way to tell libvirt about my additional devices 
without breaking oVirt.


The solution would be creating your own partition and somehow (e.g.
VDSM hook) appending


  /machine/custom


to the libvirt's  element. I'm not sure how feasible creating
your own partition is though. I've tried the process as follows:

$ cat ~/create-partition.sh
# sh ~/create-partition.sh
for i in blkio cpu,cpuacct cpuset devices freezer memory net_cls perf_event
do
  mkdir /sys/fs/cgroup/$i/machine.slice/custom.partition
done

for i in cpuset.cpus cpuset.mems
do
  cat /sys/fs/cgroup/cpuset/machine.slice/$i > 
/sys/fs/cgroup/cpuset/machine.slice/custom.partition/$i
done

(creates /machine/custom partition).
Now, we can create vdsm before_vm_start hook that will set given partition
for the VM:

$ pwd /usr/libexec/vdsm/hooks/before_vm_start
$ cat 10_cgroups

#!/usr/bin/python

import hooking


def custom_partition(domxml):
  resource = domxml.createElement('resource')
  partition = domxml.createElement('partition')
  partition_text = domxml.createTextNode('/machine/custom')
  partition.appendChild(partition_text)
  resource.appendChild(partition)

  return resource

domxml = hooking.read_domxml()
domain = domxml.getElementsByTagName('domain')[0]
domain.appendChild(custom_partition(domxml))
hooking.write_domxml(domxml)


--
Dmitry Glushenok
Jet Infosystems
http://www.jet.msk.su
+7-495-411-7601 (ext. 1237)


3 июня 2016 г., в 12:24, Martin Polednik  написал(а):

On 03/06/16 11:48 +0300, Дмитрий Глушенок wrote:

Hello!

Is it possible to tell libvirt to add specific devices to qemu cgroup? By 
somehow enumerating the devices in XML using a hook for example.
I'm passing scsi-generic disks (/dev/sgX) to VM using qemucmdline hook and it doesn't 
work until I remove "devices" from cgroup_controllers in qemu.conf.


One way to achieve this is creating a hook to generate the scsi device
XML instead of modifying qemu cmdline directly. Libvirt assumes
ownership of all devices created in the XML and therefore adds them to
the machine cgroup.

Example of the XML taken from [1]:

 
 
 
 
 
 
 
 


There is slight issue with this approach outlined in [2].

If you want to keep the qemu approach, I think creating a custom
partition and moving devices there would be the cleanest approach. In
this case, [3] could help but I'm not entirely sure if that would
solve the issue.

[1] https://libvirt.org/formatdomain.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1325485
[3] https://libvirt.org/cgroups.html

--
Dmitry Glushenok
Jet Infosystems
http://www.jet.msk.su
+7-495-411-7601 (ext. 1237)

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



___

Re: [ovirt-users] qemu cgroup_controllers

2016-06-06 Thread Дмитрий Глушенок

Hello Martin,

Thank you for your time. It is clear how to create partition and assign it to a 
VM. But libvirt manipulates with contents of devices.list and I didn't find a 
way to put my devices into devices.list and stop libvirt from removing them.

Anyway, it looks like that the best solution will be using oVirt 4.0 where scsi 
pass-through have been fixed.

--
Dmitry Glushenok
Jet Infosystems
http://www.jet.msk.su +7-495-411-7601 (ext. 1237)

> 6 июня 2016 г., в 12:33, Martin Polednik  написал(а):
> 
> On 03/06/16 14:05 +0300, Дмитрий Глушенок wrote:
>> Thank you Martin!
>> 
>> Actually I tried the workaround hook, provided in [2], but then VDSM (oVirt 
>> 3.6.6) tries to interpret hostdev in XML as PCI device, which leads to:
>> 
>> ::The vm start process failed
>> Traceback (most recent call last):
>> File "/usr/share/vdsm/virt/vm.py", line 703, in _startUnderlyingVm
>>   self._run()
>> File "/usr/share/vdsm/virt/vm.py", line 1949, in _run
>>   self._domDependentInit()
>> File "/usr/share/vdsm/virt/vm.py", line 1797, in _domDependentInit
>>   self._getUnderlyingVmDevicesInfo()
>> File "/usr/share/vdsm/virt/vm.py", line 1738, in _getUnderlyingVmDevicesInfo
>>   self._getUnderlyingHostDeviceInfo()
>> File "/usr/share/vdsm/virt/vm.py", line 4277, in _getUnderlyingHostDeviceInfo
>>   **self._getUnderlyingDeviceAddress(source))
>> TypeError: pci_address_to_name() got an unexpected keyword argument 'target'
>> 
>> XML part was:
>> 
>>  
>>  
>>  
>>  
>> 
>> 
>>  
>>  
>>  
>>  
>> 
>> 
>> 
>> As of creating custom partition - by default machine.slice has "a *:* rwm" 
>> in devices.list. But for every new VM libvirt removes *:* mask and fills the 
>> list with actually needed devices (as I understand the process). For example:
>> 
>> c 136:* rw
>> c 1:3 rw
>> c 1:7 rw
>> c 1:5 rw
>> c 1:8 rw
>> c 1:9 rw
>> c 5:2 rw
>> c 10:232 rw
>> c 253:0 rw
>> c 10:228 rw
>> c 10:196 rw
>> 
>> What I'm looking for is a way to tell libvirt about my additional devices 
>> without breaking oVirt.
> 
> The solution would be creating your own partition and somehow (e.g.
> VDSM hook) appending
> 
> 
>   /machine/custom
> 
> 
> to the libvirt's  element. I'm not sure how feasible creating
> your own partition is though. I've tried the process as follows:
> 
> $ cat ~/create-partition.sh
> # sh ~/create-partition.sh
> for i in blkio cpu,cpuacct cpuset devices freezer memory net_cls perf_event
> do
>   mkdir /sys/fs/cgroup/$i/machine.slice/custom.partition
> done
> 
> for i in cpuset.cpus cpuset.mems
> do
>   cat /sys/fs/cgroup/cpuset/machine.slice/$i > 
> /sys/fs/cgroup/cpuset/machine.slice/custom.partition/$i
> done
> 
> (creates /machine/custom partition).
> Now, we can create vdsm before_vm_start hook that will set given partition
> for the VM:
> 
> $ pwd /usr/libexec/vdsm/hooks/before_vm_start
> $ cat 10_cgroups
> 
> #!/usr/bin/python
> 
> import hooking
> 
> 
> def custom_partition(domxml):
>   resource = domxml.createElement('resource')
>   partition = domxml.createElement('partition')
>   partition_text = domxml.createTextNode('/machine/custom')
>   partition.appendChild(partition_text)
>   resource.appendChild(partition)
> 
>   return resource
> 
> domxml = hooking.read_domxml()
> domain = domxml.getElementsByTagName('domain')[0]
> domain.appendChild(custom_partition(domxml))
> hooking.write_domxml(domxml)
> 
>> --
>> Dmitry Glushenok
>> Jet Infosystems
>> http://www.jet.msk.su
>> +7-495-411-7601 (ext. 1237)
>> 
>>> 3 июня 2016 г., в 12:24, Martin Polednik  написал(а):
>>> 
>>> On 03/06/16 11:48 +0300, Дмитрий Глушенок wrote:
 Hello!
 
 Is it possible to tell libvirt to add specific devices to qemu cgroup? By 
 somehow enumerating the devices in XML using a hook for example.
 I'm passing scsi-generic disks (/dev/sgX) to VM using qemucmdline hook and 
 it doesn't work until I remove "devices" from cgroup_controllers in 
 qemu.conf.
>>> 
>>> One way to achieve this is creating a hook to generate the scsi device
>>> XML instead of modifying qemu cmdline directly. Libvirt assumes
>>> ownership of all devices created in the XML and therefore adds them to
>>> the machine cgroup.
>>> 
>>> Example of the XML taken from [1]:
>>> 
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>>  
>>> 
>>> 
>>> There is slight issue with this approach outlined in [2].
>>> 
>>> If you want to keep the qemu approach, I think creating a custom
>>> partition and moving devices there would be the cleanest approach. In
>>> this case, [3] could help but I'm not entirely sure if that would
>>> solve the issue.
>>> 
>>> [1] https://libvirt.org/formatdomain.html
>>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1325485
>>> [3] https://libvirt.org/cgroups.html
 --
 Dmitry Glushenok
 Jet Infosystems
 http://www.jet.msk.su
 +7-495-411-7601 (ext.

Re: [ovirt-users] qemu cgroup_controllers

2016-06-06 Thread Martin Polednik


On 03/06/16 14:05 +0300, Дмитрий Глушенок wrote:

Thank you Martin!

Actually I tried the workaround hook, provided in [2], but then VDSM (oVirt 
3.6.6) tries to interpret hostdev in XML as PCI device, which leads to:

::The vm start process failed
Traceback (most recent call last):
 File "/usr/share/vdsm/virt/vm.py", line 703, in _startUnderlyingVm
   self._run()
 File "/usr/share/vdsm/virt/vm.py", line 1949, in _run
   self._domDependentInit()
 File "/usr/share/vdsm/virt/vm.py", line 1797, in _domDependentInit
   self._getUnderlyingVmDevicesInfo()
 File "/usr/share/vdsm/virt/vm.py", line 1738, in _getUnderlyingVmDevicesInfo
   self._getUnderlyingHostDeviceInfo()
 File "/usr/share/vdsm/virt/vm.py", line 4277, in _getUnderlyingHostDeviceInfo
   **self._getUnderlyingDeviceAddress(source))
TypeError: pci_address_to_name() got an unexpected keyword argument 'target'

XML part was:














As of creating custom partition - by default machine.slice has "a *:* rwm" in 
devices.list. But for every new VM libvirt removes *:* mask and fills the list with 
actually needed devices (as I understand the process). For example:

c 136:* rw
c 1:3 rw
c 1:7 rw
c 1:5 rw
c 1:8 rw
c 1:9 rw
c 5:2 rw
c 10:232 rw
c 253:0 rw
c 10:228 rw
c 10:196 rw

What I'm looking for is a way to tell libvirt about my additional devices 
without breaking oVirt.


The solution would be creating your own partition and somehow (e.g.
VDSM hook) appending

 
   /machine/custom
 

to the libvirt's  element. I'm not sure how feasible creating
your own partition is though. I've tried the process as follows:

$ cat ~/create-partition.sh
# sh ~/create-partition.sh
for i in blkio cpu,cpuacct cpuset devices freezer memory net_cls perf_event
do
   mkdir /sys/fs/cgroup/$i/machine.slice/custom.partition
done

for i in cpuset.cpus cpuset.mems
do
   cat /sys/fs/cgroup/cpuset/machine.slice/$i > 
/sys/fs/cgroup/cpuset/machine.slice/custom.partition/$i
done

(creates /machine/custom partition).
Now, we can create vdsm before_vm_start hook that will set given partition
for the VM:

$ pwd /usr/libexec/vdsm/hooks/before_vm_start
$ cat 10_cgroups

#!/usr/bin/python

import hooking


def custom_partition(domxml):
   resource = domxml.createElement('resource')
   partition = domxml.createElement('partition')
   partition_text = domxml.createTextNode('/machine/custom')
   partition.appendChild(partition_text)
   resource.appendChild(partition)

   return resource

domxml = hooking.read_domxml()
domain = domxml.getElementsByTagName('domain')[0]
domain.appendChild(custom_partition(domxml))
hooking.write_domxml(domxml)


--
Dmitry Glushenok
Jet Infosystems
http://www.jet.msk.su
+7-495-411-7601 (ext. 1237)


3 июня 2016 г., в 12:24, Martin Polednik  написал(а):

On 03/06/16 11:48 +0300, Дмитрий Глушенок wrote:

Hello!

Is it possible to tell libvirt to add specific devices to qemu cgroup? By 
somehow enumerating the devices in XML using a hook for example.
I'm passing scsi-generic disks (/dev/sgX) to VM using qemucmdline hook and it doesn't 
work until I remove "devices" from cgroup_controllers in qemu.conf.


One way to achieve this is creating a hook to generate the scsi device
XML instead of modifying qemu cmdline directly. Libvirt assumes
ownership of all devices created in the XML and therefore adds them to
the machine cgroup.

Example of the XML taken from [1]:

  
  
  
  
  
  
  
  


There is slight issue with this approach outlined in [2].

If you want to keep the qemu approach, I think creating a custom
partition and moving devices there would be the cleanest approach. In
this case, [3] could help but I'm not entirely sure if that would
solve the issue.

[1] https://libvirt.org/formatdomain.html
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1325485
[3] https://libvirt.org/cgroups.html

--
Dmitry Glushenok
Jet Infosystems
http://www.jet.msk.su
+7-495-411-7601 (ext. 1237)

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



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

Re: [ovirt-users] free-IPA Multi-Master Authentication Problem

2016-06-06 Thread Kilian Ries

Hello,

here is the krb5kdc log from IPA2:


###
Jun 03 17:18:22 auth02.intern.customer-virt.eu krb5kdc[1283](info): AS_REQ (1 
etypes {23}) 192.168.210.45: NEEDED_PREAUTH: kr...@intern.customer-virt.eu for 
krbtgt/intern.customer-virt...@intern.customer-virt.eu, Additional 
pre-authentication required
Jun 03 17:18:22 auth02.intern.customer-virt.eu krb5kdc[1283](info): closing 
down fd 12
Jun 03 17:18:22 auth02.intern.customer-virt.eu krb5kdc[1283](info): AS_REQ (1 
etypes {23}) 192.168.210.45: ISSUE: authtime 1464967102, etypes {rep=23 tkt=18 
ses=23}, kr...@intern.customer-virt.eu for 
krbtgt/intern.customer-virt...@intern.customer-virt.eu
Jun 03 17:18:22 auth02.intern.customer-virt.eu krb5kdc[1283](info): closing 
down fd 12
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1283](info): AS_REQ (1 
etypes {23}) 192.168.210.45: NEEDED_PREAUTH: kr...@intern.customer-virt.eu for 
krbtgt/intern.customer-virt...@intern.customer-virt.eu, Additional 
pre-authentication required
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1283](info): closing 
down fd 12
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1284](info): AS_REQ (1 
etypes {23}) 192.168.210.45: ISSUE: authtime 1464967120, etypes {rep=23 tkt=18 
ses=23}, kr...@intern.customer-virt.eu for 
krbtgt/intern.customer-virt...@intern.customer-virt.eu
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1284](info): closing 
down fd 12
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1283](info): AS_REQ (1 
etypes {23}) 192.168.210.45: NEEDED_PREAUTH: kr...@intern.customer-virt.eu for 
krbtgt/intern.customer-virt...@intern.customer-virt.eu, Additional 
pre-authentication required
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1283](info): closing 
down fd 12
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1284](info): AS_REQ (1 
etypes {23}) 192.168.210.45: ISSUE: authtime 1464967120, etypes {rep=23 tkt=18 
ses=23}, kr...@intern.customer-virt.eu for 
krbtgt/intern.customer-virt...@intern.customer-virt.eu
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1284](info): closing 
down fd 12
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1283](info): TGS_REQ (6 
etypes {18 17 16 23 1 3}) 192.168.210.45: ISSUE: authtime 1464967120, etypes 
{rep=23 tkt=18 ses=18}, kr...@intern.customer-virt.eu for 
ldap/auth02.intern.customer-virt...@intern.customer-virt.eu
Jun 03 17:18:40 auth02.intern.customer-virt.eu krb5kdc[1283](info): closing 
down fd 12
###

Thanks for the hint with the LDAP-Provider, i'm trying to migrate as soon as 
possible.

Greets
Kilian


Von: Ondra Machacek 
Gesendet: Montag, 6. Juni 2016 09:48
An: Kilian Ries; users@ovirt.org
Betreff: Re: [ovirt-users] free-IPA Multi-Master Authentication Problem

On 06/03/2016 05:44 PM, Kilian Ries wrote:
> Hi,
>
>
> i have two free-IPA directories setup in multi-master replication. Both
> are running on CentOS 7.2 with latest Software installed. Replication
> between both IPAs is setup correctly and i am able to authenticate
> against each of the two manually.
>
>
> However, if i shutdown IPA1 and try to authenticate from oVirt 3.5.6.2
> against IPA2 i can't login. Login is only working if IPA1 is
> running (keep in mind that manual authentication against IPA2 is working).
>
>
> In the dirSRV Error-Logfile nothing is logged, however i can see the
> authentication in the access log from IPA2:
>
>
>
> ###
>
>
> filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/intern.customer-virt...@intern.customer-virt.eu)(krbPrincipalName=krbtgt/intern.customer-virt...@intern.customer-virt.eu)))"
> attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias
> krbUPEnabled krbPrincipalKey krbTicketPolicyReference
> krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference
> krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases
> krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData
> krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife
> krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData
> ipaUserAuthType ipatokenRadiusConfigLink objectClass"
>
> [03/Jun/2016:17:18:39 +0200] conn=5 op=758 RESULT err=0 tag=101
> nentries=1 etime=0
>
> [03/Jun/2016:17:18:39 +0200] conn=5 op=759 SRCH
> base="cn=global_policy,cn=INTERN.CUSTOMER-VIRT.EU,cn=kerberos,dc=intern,dc=customer-virt,dc=eu"
> scope=0 filter="(objectClass=*)" attrs="krbMaxPwdLife krbMinPwdLife
> krbPwdMinDiffChars krbPwdMinLength krbPwdHistoryLength krbPwdMaxFailure
> krbPwdFailureCountInterval krbPwdLockoutDuration"
>
> [03/Jun/2016:17:18:39 +0200] conn=5 op=759 RESULT err=0 tag=101
> nentries=1 etime=0
>
> [03/Jun/2016:17:18:39 +0200] conn=5 op=760 SRCH
> base="uid=kries,cn=users,cn=accounts,dc=intern,dc=customer-virt,dc=eu"
> scope=0 filter="(objectClass=*)" attrs="objectClass uid cn fqdn
> gidNumber

[ovirt-users] strange API parameters default in python SDK

2016-06-06 Thread Fabrice Bacchella

When I'm looking the RHEV's documentation about the API class in the python 
SDK, I see :

persistent_auth
Specifies whether persistent authentication is enabled for this connection. 
Valid values are True and False. This parameter is optional and defaults to 
False.

filter
Specifies whether or not user permission based filter is on or off. Valid 
values are True and False. If the filter parameter is set to False - which is 
the default - then the authentication credentials provided must be those of an 
administrative user. If the filter parameter is set to True then any user can 
be used and the Manager will filter the actions available to the user based on 
their permissions.

I'm surprised, because in my mind, the default value are the least usefull 
version of each options. Why don't set them to good, useful values and let the 
user changed them to the opposite if there is some problems ?
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Getting SPICE connection parameters with Python-SDK

2016-06-06 Thread Fabrice Bacchella


Le 5 juin 2016 à 13:22, Michal Skrivanek  a écrit :


On 05 Jun 2016, at 12:37, nico...@devels.es wrote:

Hi,

On user portal, when users click on the "Connect" link of a VM that is 
configured to be run with "Native client" and SPICE protocol, a .vv file is 
generated with the connection parameters so the SPICE client knows where to 
connect: host, port, password, ...

Currently, is there a way to generate those parameters with the Python SDK? 
Especially the session password so it's possible to connect to the VM directly 
with a SPICE client.

Yes, you can either get either only the password/ticket or the whole vv file, 
which was introduced by https://bugzilla.redhat.com/show_bug.cgi?id=1128763

But this call is missing from the python SDK 3.6.5.2.

In the example, I see :
curl -k -u admin@internal:1 ... -H "Accept: application/x-virt-viewer"

But in ovirtsdk/infrastructure/connectionspool.py, line 106, I see:

header_lines.append("Accept: application/xml")

The Accept parameter is hard coded, the python SDK doesn't not allow to get the 
vv file, because that's the only settings that make a difference betwen getting 
the object and getting the vv file, as it's indicated in the rsdl :


Get active graphics console of a VM.

GET


Content-Type
application/xml|json|x-virt-viewer





current
true|false






GraphicsConsole






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

Re: [ovirt-users] free-IPA Multi-Master Authentication Problem

2016-06-06 Thread Ondra Machacek


On 06/03/2016 05:44 PM, Kilian Ries wrote:

Hi,


i have two free-IPA directories setup in multi-master replication. Both
are running on CentOS 7.2 with latest Software installed. Replication
between both IPAs is setup correctly and i am able to authenticate
against each of the two manually.


However, if i shutdown IPA1 and try to authenticate from oVirt 3.5.6.2
against IPA2 i can't login. Login is only working if IPA1 is
running (keep in mind that manual authentication against IPA2 is working).


In the dirSRV Error-Logfile nothing is logged, however i can see the
authentication in the access log from IPA2:



###


filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/intern.customer-virt...@intern.customer-virt.eu)(krbPrincipalName=krbtgt/intern.customer-virt...@intern.customer-virt.eu)))"
attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias
krbUPEnabled krbPrincipalKey krbTicketPolicyReference
krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference
krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases
krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData
krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife
krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData
ipaUserAuthType ipatokenRadiusConfigLink objectClass"

[03/Jun/2016:17:18:39 +0200] conn=5 op=758 RESULT err=0 tag=101
nentries=1 etime=0

[03/Jun/2016:17:18:39 +0200] conn=5 op=759 SRCH
base="cn=global_policy,cn=INTERN.CUSTOMER-VIRT.EU,cn=kerberos,dc=intern,dc=customer-virt,dc=eu"
scope=0 filter="(objectClass=*)" attrs="krbMaxPwdLife krbMinPwdLife
krbPwdMinDiffChars krbPwdMinLength krbPwdHistoryLength krbPwdMaxFailure
krbPwdFailureCountInterval krbPwdLockoutDuration"

[03/Jun/2016:17:18:39 +0200] conn=5 op=759 RESULT err=0 tag=101
nentries=1 etime=0

[03/Jun/2016:17:18:39 +0200] conn=5 op=760 SRCH
base="uid=kries,cn=users,cn=accounts,dc=intern,dc=customer-virt,dc=eu"
scope=0 filter="(objectClass=*)" attrs="objectClass uid cn fqdn
gidNumber krbPrincipalName krbCanonicalName krbTicketPolicyReference
krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference
krbPrincipalType krbLastPwdChange krbPrincipalAliases
krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount
krbLastAdminUnlock krbTicketFlags ipaNTSecurityIdentifier
ipaNTLogonScript ipaNTProfilePath ipaNTHomeDirectory
ipaNTHomeDirectoryDrive"

[03/Jun/2016:17:18:39 +0200] conn=5 op=760 RESULT err=0 tag=101
nentries=1 etime=0

[03/Jun/2016:17:18:39 +0200] conn=5 op=761 MOD
dn="uid=kries,cn=users,cn=accounts,dc=intern,dc=customer-virt,dc=eu"

[03/Jun/2016:17:18:39 +0200] conn=5 op=761 RESULT err=0 tag=103
nentries=0 etime=0 csn=5751a1820001000d

[03/Jun/2016:17:18:39 +0200] conn=95 fd=109 slot=109 connection from
192.168.210.45 to 192.168.210.181

[03/Jun/2016:17:18:39 +0200] conn=6 op=937 SRCH
base="dc=intern,dc=customer-virt,dc=eu" scope=2
filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=krbtgt/intern.customer-virt...@intern.customer-virt.eu)(krbPrincipalName=krbtgt/intern.customer-virt...@intern.customer-virt.eu)))"
attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias
krbUPEnabled krbPrincipalKey krbTicketPolicyReference
krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference
krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases
krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData
krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife
krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData
ipaUserAuthType ipatokenRadiusConfigLink objectClass"

[03/Jun/2016:17:18:39 +0200] conn=6 op=937 RESULT err=0 tag=101
nentries=1 etime=0

[03/Jun/2016:17:18:39 +0200] conn=6 op=938 SRCH
base="dc=intern,dc=customer-virt,dc=eu" scope=2
filter="(&(|(objectClass=krbprincipalaux)(objectClass=krbprincipal)(objectClass=ipakrbprincipal))(|(ipaKrbPrincipalAlias=ldap/auth02.intern.customer-virt...@intern.customer-virt.eu)(krbPrincipalName=ldap/auth02.intern.customer-virt...@intern.customer-virt.eu)))"
attrs="krbPrincipalName krbCanonicalName ipaKrbPrincipalAlias
krbUPEnabled krbPrincipalKey krbTicketPolicyReference
krbPrincipalExpiration krbPasswordExpiration krbPwdPolicyReference
krbPrincipalType krbPwdHistory krbLastPwdChange krbPrincipalAliases
krbLastSuccessfulAuth krbLastFailedAuth krbLoginFailedCount krbExtraData
krbLastAdminUnlock krbObjectReferences krbTicketFlags krbMaxTicketLife
krbMaxRenewableAge nsAccountLock passwordHistory ipaKrbAuthzData
ipaUserAuthType ipatokenRadiusConfigLink objectClass"

[03/Jun/2016:17:18:39 +0200] conn=6 op=938 RESULT err=0 tag=101
nentries=1 etime=0

[03/Jun/2016:17:18:39 +0200] conn=6 op=939 SRCH
base="cn=INTERN.CUSTOMER-VIRT.EU,cn=kerberos,dc=intern,dc=customer-virt,dc=eu"
scope=0 filter="(objectClass=krbticketpolicyaux)"
attrs="krbMaxTicketLife

Re: [ovirt-users] virt-in-virt problem: DHCP failing for a container in a oVirt VM

Re: [ovirt-users] strange API parameters default in python SDK

Re: [ovirt-users] qemu cgroup_controllers

Re: [ovirt-users] qemu cgroup_controllers

Re: [ovirt-users] free-IPA Multi-Master Authentication Problem

Re: [ovirt-users] qemu cgroup_controllers

Re: [ovirt-users] qemu cgroup_controllers

Re: [ovirt-users] qemu cgroup_controllers

Re: [ovirt-users] free-IPA Multi-Master Authentication Problem

[ovirt-users] strange API parameters default in python SDK

Re: [ovirt-users] Getting SPICE connection parameters with Python-SDK

Re: [ovirt-users] free-IPA Multi-Master Authentication Problem

12 matches

Site Navigation

Mail list logo

Footer information