Re: [ovirt-users] providing hosts with foreman

[ybronhei]

Hey Nathenael,

On 05/13/2015 06:28 PM, Nathanaël Blanchet wrote:

Hi all,

I've setup a foreman server, but when adding a new host by "discovered
hosts", I can't modify the address item which is default filled with a
built "mac-DNS".


Not exactly, it set the address field to be the name you choose for the 
host dot (.) the domain that related to the picked host-group



In ovirt setup, I want to identify my future hosts by their IP and not
their unknown DNS name like it is described here:
http://www.ovirt.org/Features/ForemanIntegration.


IP addresses can and should be dynamic based on your DHCP server 
configuration, but DNS name should stay the same. Adding the host that 
way to engine uses satellite to configure its DNS entry and other 
network configurations. That's why we lock the address field and fill it 
with the future FQDN.



How can I setup foreman to do such a thing? Is the setup of the DNS
proxy related?


Yes, the DNS setup is related to it. We depend on it. Using IP address 
might brake the integration between engine and satellite when the DHCP 
service is configured with address ttl option and can give the host 
different IP address in next boot. So currently we don't support address 
modification with Discovered\Provisioned Hosts






If that answer is not clear feel free to ping me in irc (ybronhei 
@freenode #ovirt) or reply here


Regards,

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

Re: [ovirt-users] Issue with vdsm on EL6 nodes

[ybronhei]

On 04/12/2015 12:17 PM, ybronhei wrote:

On 04/07/2015 04:45 PM, Alon Bar-Lev wrote:



- Original Message -

From: "knarra" 
To: "Alon Bar-Lev" 
Cc: users@ovirt.org
Sent: Tuesday, April 7, 2015 3:39:58 PM
Subject: Re: [ovirt-users] Issue with vdsm on EL6 nodes

On 04/07/2015 05:58 PM, Alon Bar-Lev wrote:


- Original Message -

From: "knarra" 
To: "Alon Bar-Lev" 
Cc: users@ovirt.org
Sent: Tuesday, April 7, 2015 3:25:07 PM
Subject: Re: [ovirt-users] Issue with vdsm on EL6 nodes

On 04/07/2015 05:50 PM, Alon Bar-Lev wrote:

- Original Message -

From: "knarra" 
To: users@ovirt.org
Sent: Tuesday, April 7, 2015 3:15:12 PM
Subject: [ovirt-users] Issue with vdsm on EL6 nodes





SSLError: [Errno 1] _ssl.c:1390: error:1409442E:SSL
routines:SSL3_READ_BYTES:tlsv1 alert protocol version

Can some one help me to resolve this issue.

your openssl is patched to disable ssv3, and engine is trying to
communicate using sslv3.

please upgrade engine to latest z-stream, it should be resolved.

Hi Alon,

   I checked the following value in my database and my engine
is using
TLSv1 and not sslv3 to comminucate. I am on 3.6 master branch.

engine=# select option_name,option_value from vdc_options where
option_name = 'VdsmSSLProtocol';
  option_name   | option_value
-+--
VdsmSSLProtocol | TLSv1
(1 row)

hmmm and you say you get this when you use vdsClient, so maybe
it tries
to connect using sslv3.

is engine working proberly?

yes, engine works fine, i have few other nodes where i have the same
vdsm version added to same engine and i do not hit this issue there. I
am just wondering how is this happening.



compare openssl version.

yaniv, please fix the vdsClient to use TLSv1


should it use v1 always (forcefully)? we can do that, but currently it
chooses the highest version both parties are able to use


Vdsm uses ssl.PROTOCOL_SSLv23 which chooses the right tls version in 
python 2.7. In el6 we have python 2.6 which picks sslv2 or sslv3 when 
using ssl.PROTOCOL_SSLv23 (the highest version both sides support) -


ovirt 3.6 (vdsm 4.17 and above) doesn't support el6 anymore therefore 
current 3.6 code works as expected in el7\fedora>20.


If we want to fix vdsm 4.16.x (ovirt 3.5 package) to use explicitly 
ssl.PROTOCOL_TLSv1 we can do so - but it will be ovirt-3.5 branch only


do we want that? if so we need bug for 3.5

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

Re: [ovirt-users] Issue with vdsm on EL6 nodes

[ybronhei]

On 04/07/2015 04:45 PM, Alon Bar-Lev wrote:



- Original Message -

From: "knarra" 
To: "Alon Bar-Lev" 
Cc: users@ovirt.org
Sent: Tuesday, April 7, 2015 3:39:58 PM
Subject: Re: [ovirt-users] Issue with vdsm on EL6 nodes

On 04/07/2015 05:58 PM, Alon Bar-Lev wrote:


- Original Message -

From: "knarra" 
To: "Alon Bar-Lev" 
Cc: users@ovirt.org
Sent: Tuesday, April 7, 2015 3:25:07 PM
Subject: Re: [ovirt-users] Issue with vdsm on EL6 nodes

On 04/07/2015 05:50 PM, Alon Bar-Lev wrote:

- Original Message -

From: "knarra" 
To: users@ovirt.org
Sent: Tuesday, April 7, 2015 3:15:12 PM
Subject: [ovirt-users] Issue with vdsm on EL6 nodes





SSLError: [Errno 1] _ssl.c:1390: error:1409442E:SSL
routines:SSL3_READ_BYTES:tlsv1 alert protocol version

Can some one help me to resolve this issue.

your openssl is patched to disable ssv3, and engine is trying to
communicate using sslv3.

please upgrade engine to latest z-stream, it should be resolved.

Hi Alon,

   I checked the following value in my database and my engine is using
TLSv1 and not sslv3 to comminucate. I am on 3.6 master branch.

engine=# select option_name,option_value from vdc_options where
option_name = 'VdsmSSLProtocol';
  option_name   | option_value
-+--
VdsmSSLProtocol | TLSv1
(1 row)

hmmm and you say you get this when you use vdsClient, so maybe it tries
to connect using sslv3.

is engine working proberly?

yes, engine works fine, i have few other nodes where i have the same
vdsm version added to same engine and i do not hit this issue there. I
am just wondering how is this happening.



compare openssl version.

yaniv, please fix the vdsClient to use TLSv1

should it use v1 always (forcefully)? we can do that, but currently it 
chooses the highest version both parties are able to use



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

Re: [ovirt-users] Modules sanlock are not configured

[ybronhei]

On 03/31/2015 09:46 PM, Bloemen, Jurriën wrote:

No worries!

I checked the scripts of the RPM and that line is in there.
I tried to reinstall it but no luck.

Then I began to run each line in the RPM script by hand.

What I found out is that there was already a KVM group but not in the
/etc/group file.
The system was connected to a IPA server and somebody had created the KVM
group for some reason. (Maybe me in the past :-))

I removed the KVM group from IPA and ran the installation again and it
works flawless!

So the KVM group in IPA was the reason why the installation was not
working correctly.

Thanks for your time and I feel a bit stupid that I did not check this
before sending a e-mail to this mailinglist.


Also no worries.. I don't think that was easy issue to figure, but with 
good collaboration every bug can be discovered. Keep using the users 
list for any future issues with ovirt.


Regards,
Yaniv.



On 31/03/15 15:23, "ybronhei"  wrote:


On 03/31/2015 03:34 PM, Bloemen, Jurriën wrote:

Hi,

Please see the inline answers.

Thanks in advance,

Jurriën



Sorry that he took me awhile to check that (I didn't have el7
installation in hand) but now when checking that -
please run: rpm -q --scripts qemu-kvm-common-rhev

you'll see that this package creates the kvm group - useradd -r -u 107
-g qemu -G kvm -d / -s /sbin/nologin \
-c "qemu user" qemu

something went wrong with your installation and its hard to tell what.
please try - yum reinstall qemu-kvm-common-rhev

then check again "egrep "kvm" /etc/group" , if exists run vdsm-tool
configure --force and start vdsm

Let me know how it goes..


On 31/03/15 14:18, "ybronhei"  wrote:


On 03/31/2015 02:07 PM, Bloemen, Jurriën wrote:

Hi all,

First of all thanks Yaniv for your reply!


Sure. Anytime

Basically kvm group should be created by qemu rpm installation,
so first check "egrep "kvm" /etc/group" - it should return
kvm:x:36:qemu,sanlock if your system is installed properly


"egrep "kvm" /etc/group"

No result




If not, please tell me the output of "rpm -qa | grep qemu-kvm"


# rpm -qa | grep qemu-kvm
qemu-kvm-rhev-1.5.3-60.el7_0.2.x86_64
qemu-kvm-tools-rhev-1.5.3-60.el7_0.2.x86_64
qemu-kvm-common-rhev-1.5.3-60.el7_0.2.x86_64




And just to be on the same side write me also what vdsm version you use
There


# rpm -qa | grep vdsm
vdsm-xmlrpc-4.16.10-8.gitc937927.el7.noarch
vdsm-jsonrpc-4.16.10-8.gitc937927.el7.noarch
vdsm-python-zombiereaper-4.16.10-8.gitc937927.el7.noarch
vdsm-python-4.16.10-8.gitc937927.el7.noarch
vdsm-yajsonrpc-4.16.10-8.gitc937927.el7.noarch
vdsm-4.16.10-8.gitc937927.el7.x86_64
vdsm-cli-4.16.10-8.gitc937927.el7.noarch




Yaniv.


This is a fresh new installed system. It was not registered to another
oVirt engine before.

So...

The output of "groups sanlock² is
sanlock : sanlock disk qemu

KVM is missing. There is no kvm group at all or user for that matter!?

I ran the command "vdsm-tool configure --module sanlock ‹force² and
after
that ³groups sanlock² but it shows the same output as above.

Do you have other ideas what to check?

Thanks in advance,

Jurriën

On 31/03/15 10:23, "ybronhei"  wrote:


Hey guys,

Probably the problem is that sanlock service cannot stop properly -
was
the host registered to another ovirt engine before and you missed to
put
it on maintenance before adding it to another system?

Such issue raised before when sanlock service fails to stop - can you
explicitly check if does - service sanlock stop - fail or pass?

If it fails it means that some leases are still locked and reboot
will
solve the issue.

If that is not the case please share the output of "groups sanlock" -
it
should be  - sanlock : sanlock disk kvm qemu after the call to -
vdsm-tool configure --module sanlock --force (fyi all this configure
call does is to add sanlock user to those groups in this case)

Hope the information helps. Please share your progress with the
issue.

Yaniv Bronhaim.

On 03/31/2015 10:15 AM, Bloemen, Jurriën wrote:

I did that also. I forgot to mention it because you only have to run
--force if you didn¹t stop the sanlock process of running.
The result of with and without is the same. Still the vdsmd process
cannot start.



From: Roy Golan mailto:rgo...@redhat.com>>
Date: Monday 30 March 2015 23:25
To: Jurriën Bloemen


mailto:jurrien.bloemen@dmc.amcne
tw
or
ks.com>>
Cc: "users@ovirt.org<mailto:users@ovirt.org>"
mailto:users@ovirt.org>>
Subject: Re: [ovirt-users] Modules sanlock are not configured


On Mar 30, 2015 10:45 PM, Jurriën


mailto:Jurrien.Bloemen@dmc.amcne
tw
or
ks.com>> wrote:


Hi all,

I have CentOS 7 running and I added the oVirt 3.5 repo to it. I
open
the oVirt Manager and added a new system to it.
The manager says installing and after that is fails to connect.
Looking on the system I see:

Mar 3

Re: [ovirt-users] Modules sanlock are not configured

[ybronhei]

On 03/31/2015 03:34 PM, Bloemen, Jurriën wrote:

Hi,

Please see the inline answers.

Thanks in advance,

Jurriën



Sorry that he took me awhile to check that (I didn't have el7 
installation in hand) but now when checking that -

please run: rpm -q --scripts qemu-kvm-common-rhev

you'll see that this package creates the kvm group - useradd -r -u 107 
-g qemu -G kvm -d / -s /sbin/nologin \

   -c "qemu user" qemu

something went wrong with your installation and its hard to tell what. 
please try - yum reinstall qemu-kvm-common-rhev


then check again "egrep "kvm" /etc/group" , if exists run vdsm-tool 
configure --force and start vdsm


Let me know how it goes..


On 31/03/15 14:18, "ybronhei"  wrote:


On 03/31/2015 02:07 PM, Bloemen, Jurriën wrote:

Hi all,

First of all thanks Yaniv for your reply!


Sure. Anytime

Basically kvm group should be created by qemu rpm installation,
so first check "egrep "kvm" /etc/group" - it should return
kvm:x:36:qemu,sanlock if your system is installed properly


"egrep "kvm" /etc/group"

No result




If not, please tell me the output of "rpm -qa | grep qemu-kvm"


# rpm -qa | grep qemu-kvm
qemu-kvm-rhev-1.5.3-60.el7_0.2.x86_64
qemu-kvm-tools-rhev-1.5.3-60.el7_0.2.x86_64
qemu-kvm-common-rhev-1.5.3-60.el7_0.2.x86_64




And just to be on the same side write me also what vdsm version you use
There


# rpm -qa | grep vdsm
vdsm-xmlrpc-4.16.10-8.gitc937927.el7.noarch
vdsm-jsonrpc-4.16.10-8.gitc937927.el7.noarch
vdsm-python-zombiereaper-4.16.10-8.gitc937927.el7.noarch
vdsm-python-4.16.10-8.gitc937927.el7.noarch
vdsm-yajsonrpc-4.16.10-8.gitc937927.el7.noarch
vdsm-4.16.10-8.gitc937927.el7.x86_64
vdsm-cli-4.16.10-8.gitc937927.el7.noarch




Yaniv.


This is a fresh new installed system. It was not registered to another
oVirt engine before.

So...

The output of "groups sanlock² is
sanlock : sanlock disk qemu

KVM is missing. There is no kvm group at all or user for that matter!?

I ran the command "vdsm-tool configure --module sanlock ‹force² and
after
that ³groups sanlock² but it shows the same output as above.

Do you have other ideas what to check?

Thanks in advance,

Jurriën

On 31/03/15 10:23, "ybronhei"  wrote:


Hey guys,

Probably the problem is that sanlock service cannot stop properly - was
the host registered to another ovirt engine before and you missed to
put
it on maintenance before adding it to another system?

Such issue raised before when sanlock service fails to stop - can you
explicitly check if does - service sanlock stop - fail or pass?

If it fails it means that some leases are still locked and reboot will
solve the issue.

If that is not the case please share the output of "groups sanlock" -
it
should be  - sanlock : sanlock disk kvm qemu after the call to -
vdsm-tool configure --module sanlock --force (fyi all this configure
call does is to add sanlock user to those groups in this case)

Hope the information helps. Please share your progress with the issue.

Yaniv Bronhaim.

On 03/31/2015 10:15 AM, Bloemen, Jurriën wrote:

I did that also. I forgot to mention it because you only have to run
--force if you didn¹t stop the sanlock process of running.
The result of with and without is the same. Still the vdsmd process
cannot start.



From: Roy Golan mailto:rgo...@redhat.com>>
Date: Monday 30 March 2015 23:25
To: Jurriën Bloemen

mailto:jurrien.bloemen@dmc.amcnetw
or
ks.com>>
Cc: "users@ovirt.org<mailto:users@ovirt.org>"
mailto:users@ovirt.org>>
Subject: Re: [ovirt-users] Modules sanlock are not configured


On Mar 30, 2015 10:45 PM, Jurriën

mailto:Jurrien.Bloemen@dmc.amcnetw
or
ks.com>> wrote:


Hi all,

I have CentOS 7 running and I added the oVirt 3.5 repo to it. I open
the oVirt Manager and added a new system to it.
The manager says installing and after that is fails to connect.
Looking on the system I see:

Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running mkdirs
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
configure_coredump
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
configure_vdsm_logs
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
wait_for_network
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
run_init_hooks
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
upgraded_version_check
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
check_is_configured
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: Error:
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: One of the modules is not
configured to work with VDSM.
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: To configure the module
use the following:
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: 'vdsm-tool configure
[--module module-name]'.
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: If all modules are not
configured try to use:
Mar 30 21:09:37 vdsmd_init_common.

Re: [ovirt-users] Modules sanlock are not configured

[ybronhei]

On 03/31/2015 02:07 PM, Bloemen, Jurriën wrote:

Hi all,

First of all thanks Yaniv for your reply!


Sure. Anytime

Basically kvm group should be created by qemu rpm installation,
so first check "egrep "kvm" /etc/group" - it should return 
kvm:x:36:qemu,sanlock if your system is installed properly


If not, please tell me the output of "rpm -qa | grep qemu-kvm"

And just to be on the same side write me also what vdsm version you use 
there


Yaniv.


This is a fresh new installed system. It was not registered to another
oVirt engine before.

So...

The output of "groups sanlock² is
sanlock : sanlock disk qemu

KVM is missing. There is no kvm group at all or user for that matter!?

I ran the command "vdsm-tool configure --module sanlock ‹force² and after
that ³groups sanlock² but it shows the same output as above.

Do you have other ideas what to check?

Thanks in advance,

Jurriën

On 31/03/15 10:23, "ybronhei"  wrote:


Hey guys,

Probably the problem is that sanlock service cannot stop properly - was
the host registered to another ovirt engine before and you missed to put
it on maintenance before adding it to another system?

Such issue raised before when sanlock service fails to stop - can you
explicitly check if does - service sanlock stop - fail or pass?

If it fails it means that some leases are still locked and reboot will
solve the issue.

If that is not the case please share the output of "groups sanlock" - it
should be  - sanlock : sanlock disk kvm qemu after the call to -
vdsm-tool configure --module sanlock --force (fyi all this configure
call does is to add sanlock user to those groups in this case)

Hope the information helps. Please share your progress with the issue.

Yaniv Bronhaim.

On 03/31/2015 10:15 AM, Bloemen, Jurriën wrote:

I did that also. I forgot to mention it because you only have to run
--force if you didn¹t stop the sanlock process of running.
The result of with and without is the same. Still the vdsmd process
cannot start.



From: Roy Golan mailto:rgo...@redhat.com>>
Date: Monday 30 March 2015 23:25
To: Jurriën Bloemen
mailto:jurrien.bloemen@dmc.amcnetwor
ks.com>>
Cc: "users@ovirt.org<mailto:users@ovirt.org>"
mailto:users@ovirt.org>>
Subject: Re: [ovirt-users] Modules sanlock are not configured


On Mar 30, 2015 10:45 PM, Jurriën
mailto:Jurrien.Bloemen@dmc.amcnetwor
ks.com>> wrote:


Hi all,

I have CentOS 7 running and I added the oVirt 3.5 repo to it. I open
the oVirt Manager and added a new system to it.
The manager says installing and after that is fails to connect.
Looking on the system I see:

Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running mkdirs
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
configure_coredump
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
configure_vdsm_logs
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
wait_for_network
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
run_init_hooks
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
upgraded_version_check
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running
check_is_configured
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: Error:
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: One of the modules is not
configured to work with VDSM.
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: To configure the module
use the following:
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: 'vdsm-tool configure
[--module module-name]'.
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: If all modules are not
configured try to use:
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: 'vdsm-tool configure
--force'
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: (The force flag will stop
the module's service and start it
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: afterwards automatically
to load the new configuration.)
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: libvirt is already
configured for vdsm
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: Modules sanlock are not
configured
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: stopped during
execute check_is_configured task (task returned with error code 1).

So I run vdsm-tool configure after I stop sanlock.

# vdsm-tool configure


Try adding --force (this is what the log suggests)



Checking configuration status...

libvirt is already configured for vdsm
SUCCESS: ssl configured to true. No conflicts

Running configure...
Reconfiguration of sanlock is done.

Done configuring modules to VDSM.

But when I want to start vdsmd it still gives the error that sanlock
is not configured.

Does somebody has a solution for this?

I am a bit lost on thisŠ Google only tells me that there was a bug in
3.4.

Thanks in advance,

Jurriën
This message (including any attachments) may contain information that
is privileged or confidential. If you are not the intended recipient,
please notify the sender and delete this email immedia

Re: [ovirt-users] Modules sanlock are not configured

[ybronhei]

Hey guys,

Probably the problem is that sanlock service cannot stop properly - was 
the host registered to another ovirt engine before and you missed to put 
it on maintenance before adding it to another system?


Such issue raised before when sanlock service fails to stop - can you 
explicitly check if does - service sanlock stop - fail or pass?


If it fails it means that some leases are still locked and reboot will 
solve the issue.


If that is not the case please share the output of "groups sanlock" - it 
should be  - sanlock : sanlock disk kvm qemu after the call to - 
vdsm-tool configure --module sanlock --force (fyi all this configure 
call does is to add sanlock user to those groups in this case)


Hope the information helps. Please share your progress with the issue.

Yaniv Bronhaim.

On 03/31/2015 10:15 AM, Bloemen, Jurriën wrote:

I did that also. I forgot to mention it because you only have to run --force if 
you didn’t stop the sanlock process of running.
The result of with and without is the same. Still the vdsmd process cannot 
start.



From: Roy Golan mailto:rgo...@redhat.com>>
Date: Monday 30 March 2015 23:25
To: Jurriën Bloemen 
mailto:jurrien.bloe...@dmc.amcnetworks.com>>
Cc: "users@ovirt.org" 
mailto:users@ovirt.org>>
Subject: Re: [ovirt-users] Modules sanlock are not configured


On Mar 30, 2015 10:45 PM, Jurriën 
mailto:jurrien.bloe...@dmc.amcnetworks.com>>
 wrote:


Hi all,

I have CentOS 7 running and I added the oVirt 3.5 repo to it. I open the oVirt 
Manager and added a new system to it.
The manager says installing and after that is fails to connect. Looking on the 
system I see:

Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running mkdirs
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running configure_coredump
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running configure_vdsm_logs
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running wait_for_network
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running run_init_hooks
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running upgraded_version_check
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: Running check_is_configured
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: Error:
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: One of the modules is not 
configured to work with VDSM.
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: To configure the module use the 
following:
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: 'vdsm-tool configure [--module 
module-name]'.
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: If all modules are not configured 
try to use:
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: 'vdsm-tool configure --force'
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: (The force flag will stop the 
module's service and start it
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: afterwards automatically to load 
the new configuration.)
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: libvirt is already configured for 
vdsm
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: Modules sanlock are not configured
Mar 30 21:09:37 vdsmd_init_common.sh[7106]: vdsm: stopped during execute 
check_is_configured task (task returned with error code 1).

So I run vdsm-tool configure after I stop sanlock.

# vdsm-tool configure


Try adding --force (this is what the log suggests)



Checking configuration status...

libvirt is already configured for vdsm
SUCCESS: ssl configured to true. No conflicts

Running configure...
Reconfiguration of sanlock is done.

Done configuring modules to VDSM.

But when I want to start vdsmd it still gives the error that sanlock is not 
configured.

Does somebody has a solution for this?

I am a bit lost on this… Google only tells me that there was a bug in 3.4.

Thanks in advance,

Jurriën
This message (including any attachments) may contain information that is 
privileged or confidential. If you are not the intended recipient, please 
notify the sender and delete this email immediately from your systems and 
destroy all copies of it. You may not, directly or indirectly, use, disclose, 
distribute, print or copy this email or any part of it if you are not the 
intended recipient




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




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

Re: [ovirt-users] Error during host deploy for 3.5.1, package installation

[ybronhei]

Hey Erik,
can you please ping me on irc (my nick is ybronhei in #ovirt 
irc.oftc.net) we will go through it together to understand what repos 
you have there and why your vdsm rpm doesn't find its requirements.

 btw, do you install the i686 arch version on purpose ?

Sandro, fyi - if you have any inputs to add .. maybe new updates in 
ovirt3.5 repo?


Thanks,
Yaniv.


On 03/10/2015 05:20 PM, Alon Bar-Lev wrote:


Yaniv, can you please assist, there seems to be a conflict and multilib issues 
of vdsm.

- Original Message -

From: "Erik Brakke" 
To: "Alon Bar-Lev" 
Cc: users@ovirt.org
Sent: Tuesday, March 10, 2015 4:21:53 PM
Subject: Re: [ovirt-users] Error during host deploy for 3.5.1, package 
installation

Hi Alon, thanks for replying.

When I:
yum update vdsm
No packages marked for update

When I:
yum update vdsm-xmlrpc
Error: package: vdsm-4.14.8.1-0.fc20.i686 (@updates)
Requires: vdsm-xmlrpc = 4.14.8.1-0.fc20.noarch (@updates)
Removing: vdsm-xmlrpc-4.14.8.1-0.fc20.noarch (@updates)
vdsm-xmlrpc-4.14.8.1-0.fc20
Updated By: vdsm-xmlrpc-4.16.10-8.gitc937927.fc20.noarch (ovirt-3.5)
vdsm-xmlrpc-4.16.10-8.gitc937927.fc20
Available: vdsm-xmlrpc-4.12.1-1.fc20.noarch (fedora)
vdsm-xmlrpc-4.12.1-1.fc20
Available: vdsm-xmlrpc-4.16.7-1.gitdb83943.fc20.noarch (ovirt-3.5)
vdsm-xmlrpc-4.16.7-1.gitdb83943.fc20
Available: vdsm-xmlrpc-4.16.10-0.fc20.noarch (ovirt-3.5)
vdsm-xmlrpc-4.16.10-0.fc20

I also get matching results for vdsm-python and vdsm-python-zombiereaper.

Do I need to disable the Fedora updates repo?

Thanks!
-Erik



On Tue, Mar 10, 2015 at 2:44 AM, Alon Bar-Lev  wrote:


Hi,

What do you get when you try to update vdsm manually?

# yum update vdsm

- Original Message -

From: "Erik Brakke" 
To: users@ovirt.org
Sent: Tuesday, March 10, 2015 4:25:53 AM
Subject: [ovirt-users] Error during host deploy for 3.5.1,package

installation


Hello,
When deploying a new host from the admin portal to FC20 target, the

package

dependency check fails (host-deploy log):

ERROR otopi.plugins.otopi.packagers.yumpackager yumpackager.error:97 Yum
[u'vdsm-4.14.8.1-0.fc20.i686 requires vdsm-xmlrpc = 4.14.8.1-0.fc20',
u'vdsm-4.14.8.1-0.fc20.i686 requires vdsm-python = 4.14.8.1-0.fc20',
u'vdsm-4.14.8.1-0.fc20.i686 requires vdsm-python-zombiereaper =
4.14.8.1-0.fc20']

I've tried the release 3.5 and 3.5-snapshot repos. Installing the

packages

manually does not satisfy host deploy. It appears vdsm 4.16 packages are
available in the repository.

Engine was previously running 3.5.0, updated to 3.5.1, no change. I was

able

to deploy hosts in January with 3.5.0.

Any assistance greatly appreciated!

Best - Erik

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








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

Re: [ovirt-users] VDSM memory consumption

[ybronhei]

On 03/10/2015 12:19 AM, Dan Kenigsberg wrote:

On Mon, Mar 09, 2015 at 12:17:00PM -0500, Chris Adams wrote:

Once upon a time, Dan Kenigsberg  said:

I'm afraid that we are yet to find a solution for this issue, which is
completly different from the horrible leak of supervdsm < 4.16.7.

Could you corroborate the claim of
 Bug 1147148 - M2Crypto usage in vdsm leaks memory
? Does the leak disappear once you start using plaintext transport?


So, to confirm, it looks like to do that, the steps would be:

- In the [vars] section of /etc/vdsm/vdsm.conf, set "ssl = false".
- Restart the vdsmd service.

Is that all that is needed?


No. You'd have to reconfigure libvirtd to work in plaintext

 vdsm-tool congfigure --force

and also set you Engine to work in plaintext (unfortunately, I don't
recall how's that done. surely Yaniv does)
if the host already managed by the engine you can move it to 
maintenance, set directly in vdc_options table by psql client to your 
db- update to False in vdc_options the value of 
'EncryptHostCommunication' 'SSLEnabled' options, then restart ovirt-engine.
expect the engine side, run also the changes on host (ssl=False and 
configure --force as Dan mentions above) and reactivate the host.



Is it safe to restart vdsmd on a node with
active VMs?


It's safe in the sense that I have not heard of a single failure to
reconnected to already-running VMs in years. However, this is still not
recommended for production environment, and particularly not if one of
the VMs is defined as highly-available. This can end up with your host
being fenced and all your VMs dead.

Dan.




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

[ovirt-users] DevConf talks about oVirt and Foreman integration

[ybronhei]

Hey guys,
Apparently DevConf uploaded records for my sessions last month at 
devConf, you are welcome to check that out


https://www.youtube.com/watch?v=XmF6kV73XRY
https://www.youtube.com/watch?v=D0nitrAKToM&spfreload=1

As users you probably familiar with most of what I say there, especially 
in the general overview, but it's still good for refreshment if you have 
spare 40 minutes.. jump directly to minute 5-7


Regards,

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

[ovirt-users] New Vdsm Build for oVirt 3.5

[ybronhei]

Hey all,

Vdsm-4.16.10 is just released for ovirt-3.5 (Async release).

f20 - http://koji.fedoraproject.org/koji/taskinfo?taskID=8495492
epel6 - http://koji.fedoraproject.org/koji/taskinfo?taskID=8556522
epel7 - http://koji.fedoraproject.org/koji/taskinfo?taskID=8479594
f21 - http://koji.fedoraproject.org/koji/taskinfo?taskID=8494079
f22 - http://koji.fedoraproject.org/koji/taskinfo?taskID=8494059

Enjoy.

Please give karma if tested, for good and bad

Regards

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

Re: [ovirt-users] http://www.ovirt.org/Features/ForemanIntegration

[ybronhei]

On 11/11/2014 05:43 PM, Daniel Helgenberger wrote:



On 11.11.2014 16:09, ybronhei wrote:

On 11/11/2014 03:25 PM, Daniel Helgenberger wrote:



On 11.11.2014 13:46, ybronhei wrote:

Hey Daniel,
Thanks for your comments.
First, I do mention the requirement for having ovirt_provision_plugin
installed in bullet 2:
"""Add oVirt Provision Plugin: "yum install
ruby193-rubygem-ovirt_provision_plugin" \ "foreman-installer
--enable-foreman-plugin-ovirt-provision" (Not available yet)
"""

Indeed, I read that. My reasoning at this point it might be too late in
the text. Users (me included) already have tried this at this point
using the pictured guide and failing because of the missing provider.

This is the point witch was entirely unclear for me in my first attempt
and it took me a while to find out.

While the discovery plugin is needed (only) for Bare-Metal Provisioning,
the ovirt provider is always needed for the integration to succeed.

I did think about a hint early on describing the workflow briefly in the
detailed description section:
- Make sure Foreman is running at version X
- Install RPMs in Foreman (see Bare-Metal Provisioning)
- Go to engine, "Adding foreman provider"

I don't see why the current way we arrange the page is misleading.

Sorry if this is unclear. But:

For the "Test" button in "Add external provider" in Engine GUI to work,
one *needs* do this on the Foreman host:
# yum install ruby193-rubygem-ovirt_provision_plugin


you don't need the plugin for that.. it works with any setup of foreman 
installation.




If this this assumption is true (it was for me reproducible)
Foreman/oVirt communication will fail.


please open a bug on that with the details. adding foreman provider 
without installing the ovirt_provision_plugin works for me if I 
understand correctly



Therefore I am still convinced it is reasonable to put this as the first
step before ever trying to add the provider in oVirt.*

The other things, like bare metal prov. and so on are optional.
Installing the oVirt - provider on the Foreman host is not.



We have under "Detailed Description" 3 levels which have different
prerequisites -
Adding installed Foreman hosts as oVirt hosts - which just requires
foreman setup,

To make this clear, this is not correct since the default foreman setup
does not have the oVirt provider module installed. There are some use
cases where Foreman is added because of oVirt, and some will have
Foreman already runningin their infra. In this case, foreman-installer
was already run.


* At least I was struggling with this requirement. Truth be told,
Foreman was one point on a (very long) check list of mine; so I might
not have paid proper attention to the details. OTOH the document
suggested a strait forward approach with nice details and icons on how
to do it oVirt. For instance, when I got to the section "Bare Metal
Provisioning" I looked briefly over the requirements and decided to do
this later on. Wrong here, since there is what I need to get it running
in the first place!
The other issue, having two different (one obsolete) ForemanIntegration
docs, is solved now.


Bare-Metal Provisioning - which requires many things. starts with the
ovirt plugin, discovery plugin, configuration of hostgroups
computeresource medias and ends with setting the provisioning templates
accordingly for node installation.

and last - Future Plans: VM provisioning which still in declaration phase.





next foreman build foreman-installer will include the
--enable-foreman-plugin-ovirt-provision option which will make it
easier. its already merged.

This is great to know!



Second, about the openjdk issue, I don't think it worth to mention. I'll
add to the "Current Status" section that the integration is supported
over rhel6.6 and above.

This will do here.



Yaniv Bronhaim.

On 11/11/2014 02:38 PM, Daniel Helgenberger wrote:

Hello Yaniv,

thank you!

On 10.11.2014 10:04, ybronhei wrote:

For those who interested, I merged the pages ForemanIntegration and
AdvancedForemanIntegration to ease the search.

The page includes full description about the current integration we have
with foreman [aka satellite\katello], the future plans, how to setup
environment for testing and production and more illustrations to make it
easier to follow

feel free to comment about that (directly to me or to the list) and you
more than welcome to try that at home :)

I think there might be still the issue I ran into:

A prerequisite to adding Foreman external provider in oVirt is (at least
for me) that Foreman has *ruby193-rubygem-ovirt_provision_plugin* rpm
installed. Otherwise the test will fail with:
"Failed with error PROVIDER_FAILURE and code 5050"

Sp, on the foreman host one needs to do:
yum install ruby193-rubygem-ovirt_provision_plugin

Also, please note there is an issue users might run into at 

Re: [ovirt-users] http://www.ovirt.org/Features/ForemanIntegration

[ybronhei]

On 11/11/2014 03:25 PM, Daniel Helgenberger wrote:



On 11.11.2014 13:46, ybronhei wrote:

Hey Daniel,
Thanks for your comments.
First, I do mention the requirement for having ovirt_provision_plugin
installed in bullet 2:
"""Add oVirt Provision Plugin: "yum install
ruby193-rubygem-ovirt_provision_plugin" \ "foreman-installer
--enable-foreman-plugin-ovirt-provision" (Not available yet)
"""

Indeed, I read that. My reasoning at this point it might be too late in
the text. Users (me included) already have tried this at this point
using the pictured guide and failing because of the missing provider.

This is the point witch was entirely unclear for me in my first attempt
and it took me a while to find out.

While the discovery plugin is needed (only) for Bare-Metal Provisioning,
the ovirt provider is always needed for the integration to succeed.

I did think about a hint early on describing the workflow briefly in the
detailed description section:
- Make sure Foreman is running at version X
- Install RPMs in Foreman (see Bare-Metal Provisioning)
- Go to engine, "Adding foreman provider"

I don't see why the current way we arrange the page is misleading.

We have under "Detailed Description" 3 levels which have different 
prerequisites -
Adding installed Foreman hosts as oVirt hosts - which just requires 
foreman setup,
Bare-Metal Provisioning - which requires many things. starts with the 
ovirt plugin, discovery plugin, configuration of hostgroups 
computeresource medias and ends with setting the provisioning templates 
accordingly for node installation.


and last - Future Plans: VM provisioning which still in declaration phase.





next foreman build foreman-installer will include the
--enable-foreman-plugin-ovirt-provision option which will make it
easier. its already merged.

This is great to know!



Second, about the openjdk issue, I don't think it worth to mention. I'll
add to the "Current Status" section that the integration is supported
over rhel6.6 and above.

This will do here.



Yaniv Bronhaim.

On 11/11/2014 02:38 PM, Daniel Helgenberger wrote:

Hello Yaniv,

thank you!

On 10.11.2014 10:04, ybronhei wrote:

For those who interested, I merged the pages ForemanIntegration and
AdvancedForemanIntegration to ease the search.

The page includes full description about the current integration we have
with foreman [aka satellite\katello], the future plans, how to setup
environment for testing and production and more illustrations to make it
easier to follow

feel free to comment about that (directly to me or to the list) and you
more than welcome to try that at home :)

I think there might be still the issue I ran into:

A prerequisite to adding Foreman external provider in oVirt is (at least
for me) that Foreman has *ruby193-rubygem-ovirt_provision_plugin* rpm
installed. Otherwise the test will fail with:
"Failed with error PROVIDER_FAILURE and code 5050"

Sp, on the foreman host one needs to do:
yum install ruby193-rubygem-ovirt_provision_plugin

Also, please note there is an issue users might run into at this step,
so it may be worth noting.
Foreman integration will fail altogether on Engines running =< El6.5
because of an too old jdk version not supporting DH keys larger then
1024 byte [1].
This is not an issue in oVirt and will never be resolved. Luckily,
upgrading to the latest openjdk
(java-1.7.0-openjdk-1.7.0.71-2.5.3.1.el6.x86_64) solves the issue (on
the ENGINE!)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1157749


Thanks











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

Re: [ovirt-users] http://www.ovirt.org/Features/ForemanIntegration

[ybronhei]

Hey Daniel,
Thanks for your comments.
First, I do mention the requirement for having ovirt_provision_plugin 
installed in bullet 2:
"""Add oVirt Provision Plugin: "yum install 
ruby193-rubygem-ovirt_provision_plugin" \ "foreman-installer 
--enable-foreman-plugin-ovirt-provision" (Not available yet)

"""

next foreman build foreman-installer will include the 
--enable-foreman-plugin-ovirt-provision option which will make it 
easier. its already merged.


Second, about the openjdk issue, I don't think it worth to mention. I'll 
add to the "Current Status" section that the integration is supported 
over rhel6.6 and above.


Yaniv Bronhaim.

On 11/11/2014 02:38 PM, Daniel Helgenberger wrote:

Hello Yaniv,

thank you!

On 10.11.2014 10:04, ybronhei wrote:

For those who interested, I merged the pages ForemanIntegration and
AdvancedForemanIntegration to ease the search.

The page includes full description about the current integration we have
with foreman [aka satellite\katello], the future plans, how to setup
environment for testing and production and more illustrations to make it
easier to follow

feel free to comment about that (directly to me or to the list) and you
more than welcome to try that at home :)

I think there might be still the issue I ran into:

A prerequisite to adding Foreman external provider in oVirt is (at least
for me) that Foreman has *ruby193-rubygem-ovirt_provision_plugin* rpm
installed. Otherwise the test will fail with:
"Failed with error PROVIDER_FAILURE and code 5050"

Sp, on the foreman host one needs to do:
yum install ruby193-rubygem-ovirt_provision_plugin

Also, please note there is an issue users might run into at this step,
so it may be worth noting.
Foreman integration will fail altogether on Engines running =< El6.5
because of an too old jdk version not supporting DH keys larger then
1024 byte [1].
This is not an issue in oVirt and will never be resolved. Luckily,
upgrading to the latest openjdk
(java-1.7.0-openjdk-1.7.0.71-2.5.3.1.el6.x86_64) solves the issue (on
the ENGINE!)

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1157749


Thanks






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

[ovirt-users] http://www.ovirt.org/Features/ForemanIntegration

[ybronhei]

For those who interested, I merged the pages ForemanIntegration and 
AdvancedForemanIntegration to ease the search.


The page includes full description about the current integration we have 
with foreman [aka satellite\katello], the future plans, how to setup 
environment for testing and production and more illustrations to make it 
easier to follow


feel free to comment about that (directly to me or to the list) and you 
more than welcome to try that at home :)


Thanks

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

Re: [ovirt-users] Adding foreman provider: Could not generate DH keypair (Failed with error PROVIDER_SSL_FAILURE and code 5052)

[ybronhei]

On 10/27/2014 05:23 PM, Daniel Helgenberger wrote:



On 26.10.2014 13:26, ybronhei wrote:
Thanks for getting back to me.


On 10/26/2014 08:52 AM, Oved Ourfali wrote:

Hi

What jdk version are you using?

I assume you need to know the engine;
I am using plan vanilla openjdk from the centos repos:
rpm -qa|grep jdk
java-1.7.0-openjdk-1.7.0.65-2.5.1.2.el6_5.x86_64
java-1.6.0-openjdk-1.6.0.0-7.1.13.4.el6_5.x86_64


According to 
http://stackoverflow.com/questions/10687200/java-7-and-could-not-generate-dh-keypair
 it might be related.

I am not really sure about the versioning: but the article states this
problem is gone with 1.7.0-21 - yet 1.7.0-65 is installed?




funny, thought only I encountered that issue and fought with it a day
due my out-of-date machine..

I assume foreman integration was not tested against CentOS 6.5 -
engines? Or, might this be foreman in the end? (I am using 1.6.2-stable).


sorry I didn't share (learned for next time) :/ all you need is to
upgrade your jdk, read more about it in the stackoverflow page.

Thanks for raising the issue.

No problem, I am happy to open a BZ - but how do I get the upgrade jdk;
more exactly to which package version? I do not want to break my engine ;)
yum update comes up negative.

I did "yum upgrade java-1.7.0-openjdk" and restarted ovirt-engine service.
the version I currently have is 
java-1.7.0-openjdk-1.7.0.71-2.5.3.0.fc19.x86_64





Thanks,
Oved

- Original Message -

From: "Daniel Helgenberger" 
To: users@ovirt.org
Sent: Friday, October 24, 2014 1:16:51 AM
Subject: [ovirt-users] Adding foreman provider: Could not generate DH keypair 
(Failed with error PROVIDER_SSL_FAILURE
and code 5052)

Hello,

I tried to add foreman as external provider - without successes.

Hosted Engine 3.5
CentOS6.5

The foreman is a plain vanilla install; working so far (can log in, do stuff,
local smart proxy registered)

foreman FQDN is resolvable via DNS

In the engine UI I enter:
https://foreman.lab.mbox.loc
user
pw

and press test.
The cert is shown and after clicking ok, the chain is imported. However, the
test fails with a SSL error. Please see engine log below:

2014-10-24 00:01:45,188 INFO
[org.ovirt.engine.core.bll.provider.ImportProviderCertificateChainCommand]
(ajp--127.0.0.1-8702-7) [710ac5c] Running command:
ImportProviderCertificateChainCommand internal: false. Entities affected :
ID: aaa0----123456789aaa Type: SystemAction group
CREATE_STORAGE_POOL with role type ADMIN
2014-10-24 00:01:45,296 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(ajp--127.0.0.1-8702-7) [710ac5c] Correlation ID: 710ac5c, Call Stack: null,
Custom Event ID: -1, Message: Certificate chain for provider foreman was
imported. (User: daniel)
2014-10-24 00:01:46,212 INFO
[org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand]
(ajp--127.0.0.1-8702-9) [6a77acf4] Running command:
TestProviderConnectivityCommand internal: false. Entities affected :  ID:
aaa0----123456789aaa Type: SystemAction group
CREATE_STORAGE_POOL with role type ADMIN
2014-10-24 00:01:46,662 ERROR
[org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand]
(ajp--127.0.0.1-8702-9) [6a77acf4] Command
org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand throw Vdc
Bll exception. With error message VdcBLLException:
java.lang.RuntimeException: Could not generate DH keypair (Failed with error
PROVIDER_SSL_FAILURE and code 5052)
2014-10-24 00:02:01,222 INFO
[org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand]
(ajp--127.0.0.1-8702-10) [2713e6dc] Running command:
TestProviderConnectivityCommand internal: false. Entities affected :  ID:
aaa0----123456789aaa Type: SystemAction group
CREATE_STORAGE_POOL with role type ADMIN
2014-10-24 00:02:01,625 ERROR
[org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand]
(ajp--127.0.0.1-8702-10) [2713e6dc] Command
org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand throw Vdc
Bll exception. With error message VdcBLLException:
java.lang.RuntimeException: Could not generate DH keypair (Failed with error
PROVIDER_SSL_FAILURE and code 5052)
2014-10-24 00:02:02,090 ERROR
[org.ovirt.engine.core.bll.GetProviderCertificateChainQuery]
(ajp--127.0.0.1-8702-11) Query GetProviderCertificateChainQuery failed.
Exception message is VdcBLLException: java.lang.RuntimeException: Could not
generate DH keypair (Failed with error PROVIDER_FAILURE and code 5050) :
org.ovirt.engine.core.common.errors.VdcBLLException: VdcBLLException:
java.lang.RuntimeException: Could not generate DH keypair (Failed with error
PROVIDER_FAILURE and code 5050):
org.ovirt.engine.core.common.errors.VdcBLLException: VdcBLLException:
java.lang.RuntimeException: Could not generate DH keypair (Failed with error
PROVIDER_FAILURE and code 5050)
   at
   
org.ovirt.engine.core.bll.provider.BaseProviderProxy.handleException(BaseProviderProxy.jav

Re: [ovirt-users] Adding foreman provider: Could not generate DH keypair (Failed with error PROVIDER_SSL_FAILURE and code 5052)

[ybronhei]

On 10/26/2014 08:52 AM, Oved Ourfali wrote:

Hi

What jdk version are you using?
According to 
http://stackoverflow.com/questions/10687200/java-7-and-could-not-generate-dh-keypair
 it might be related.

funny, thought only I encountered that issue and fought with it a day 
due my out-of-date machine..


sorry I didn't share (learned for next time) :/ all you need is to 
upgrade your jdk, read more about it in the stackoverflow page.


Thanks for raising the issue.


Thanks,
Oved

- Original Message -

From: "Daniel Helgenberger" 
To: users@ovirt.org
Sent: Friday, October 24, 2014 1:16:51 AM
Subject: [ovirt-users] Adding foreman provider: Could not generate DH keypair 
(Failed with error PROVIDER_SSL_FAILURE
and code 5052)

Hello,

I tried to add foreman as external provider - without successes.

Hosted Engine 3.5
CentOS6.5

The foreman is a plain vanilla install; working so far (can log in, do stuff,
local smart proxy registered)

foreman FQDN is resolvable via DNS

In the engine UI I enter:
https://foreman.lab.mbox.loc
user
pw

and press test.
The cert is shown and after clicking ok, the chain is imported. However, the
test fails with a SSL error. Please see engine log below:

2014-10-24 00:01:45,188 INFO
[org.ovirt.engine.core.bll.provider.ImportProviderCertificateChainCommand]
(ajp--127.0.0.1-8702-7) [710ac5c] Running command:
ImportProviderCertificateChainCommand internal: false. Entities affected :
ID: aaa0----123456789aaa Type: SystemAction group
CREATE_STORAGE_POOL with role type ADMIN
2014-10-24 00:01:45,296 INFO
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(ajp--127.0.0.1-8702-7) [710ac5c] Correlation ID: 710ac5c, Call Stack: null,
Custom Event ID: -1, Message: Certificate chain for provider foreman was
imported. (User: daniel)
2014-10-24 00:01:46,212 INFO
[org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand]
(ajp--127.0.0.1-8702-9) [6a77acf4] Running command:
TestProviderConnectivityCommand internal: false. Entities affected :  ID:
aaa0----123456789aaa Type: SystemAction group
CREATE_STORAGE_POOL with role type ADMIN
2014-10-24 00:01:46,662 ERROR
[org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand]
(ajp--127.0.0.1-8702-9) [6a77acf4] Command
org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand throw Vdc
Bll exception. With error message VdcBLLException:
java.lang.RuntimeException: Could not generate DH keypair (Failed with error
PROVIDER_SSL_FAILURE and code 5052)
2014-10-24 00:02:01,222 INFO
[org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand]
(ajp--127.0.0.1-8702-10) [2713e6dc] Running command:
TestProviderConnectivityCommand internal: false. Entities affected :  ID:
aaa0----123456789aaa Type: SystemAction group
CREATE_STORAGE_POOL with role type ADMIN
2014-10-24 00:02:01,625 ERROR
[org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand]
(ajp--127.0.0.1-8702-10) [2713e6dc] Command
org.ovirt.engine.core.bll.provider.TestProviderConnectivityCommand throw Vdc
Bll exception. With error message VdcBLLException:
java.lang.RuntimeException: Could not generate DH keypair (Failed with error
PROVIDER_SSL_FAILURE and code 5052)
2014-10-24 00:02:02,090 ERROR
[org.ovirt.engine.core.bll.GetProviderCertificateChainQuery]
(ajp--127.0.0.1-8702-11) Query GetProviderCertificateChainQuery failed.
Exception message is VdcBLLException: java.lang.RuntimeException: Could not
generate DH keypair (Failed with error PROVIDER_FAILURE and code 5050) :
org.ovirt.engine.core.common.errors.VdcBLLException: VdcBLLException:
java.lang.RuntimeException: Could not generate DH keypair (Failed with error
PROVIDER_FAILURE and code 5050):
org.ovirt.engine.core.common.errors.VdcBLLException: VdcBLLException:
java.lang.RuntimeException: Could not generate DH keypair (Failed with error
PROVIDER_FAILURE and code 5050)
 at
 
org.ovirt.engine.core.bll.provider.BaseProviderProxy.handleException(BaseProviderProxy.java:70)
 [bll.jar:]
 at
 
org.ovirt.engine.core.bll.provider.BaseProviderProxy.getCertificateChain(BaseProviderProxy.java:60)
 [bll.jar:]
 at
 
org.ovirt.engine.core.bll.GetProviderCertificateChainQuery.executeQueryCommand(GetProviderCertificateChainQuery.java:24)
 [bll.jar:]
 at
 
org.ovirt.engine.core.bll.QueriesCommandBase.executeCommand(QueriesCommandBase.java:73)
 [bll.jar:]
 at
 
org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:31)
 [dal.jar:]
 at org.ovirt.engine.core.bll.Backend.runQueryImpl(Backend.java:492)
 [bll.jar:]
 at org.ovirt.engine.core.bll.Backend.runQuery(Backend.java:466)
 [bll.jar:]
 at sun.reflect.GeneratedMethodAccessor100.invoke(Unknown Source)
 [:1.7.0_65]
 at
 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   

[ovirt-users] OVIRT-3.5-TEST-DAY-3 - Providing Neutron Appliance

[ybronhei]

Hey,

following the great demo in http://youtu.be/naLFSFwHI94 we successfully 
managed to use neutron to setup isolates network for 2 vms by using the 
neutron appliance image


we didn't open new bugs on it, but we plan to use and play with it later 
on and we'll update if something will be found


we saw that the mirrors for f19 are broken but it doesn't worth a bug, 
just wiki update (in 
http://repos.fedorapeople.org/repos/openstack/openstack-icehouse/rdo-release-icehouse-3.noarch.rpm)


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

Re: [ovirt-users] Proper way to change and persist vdsm configuration options

[ybronhei]

Hey,

Just noticed something that I forgot about..
before filing new BZ, see in ovirt-host-deploy README.environment [1] 
the section:

VDSM/configOverride(bool) [True]
Override vdsm configuration file.

changing it to false will keep your vdsm.conf file as is after deploying 
the host again (what happens after node upgrade)


[1] 
https://github.com/oVirt/ovirt-host-deploy/blob/master/README.environment


please check if that what you meant..

Thanks,
Yaniv Bronhaim.

On 08/05/2014 08:12 AM, Trey Dockendorf wrote:

I'll file BZ.  As far as I can recall this has been an issue since 3.3.x as
I have been using Puppet to modify values and have had to rerun Puppet
after installing a node via GUI and when performing update from GUI.  Given
that it has occurred when VDSM version didn't change on the node it seems
likely to be something being done by Python code that bootstraps a node and
performs the other tasks.  I won't have any systems available to test with
for a few days.  New hardware specifically for our oVirt deployment is on
order so should be able to more thoroughly debug and capture logs at that
time.

Would using vdsm-reg be a better solution for adding new nodes?  I only
tried using vdsm-reg once and it went very poorly...lots of missing
dependencies not pulled in from yum install I had to install manually via
yum.  Then the node was auto added to newest cluster with no ability to
change the cluster.  Be happy to debug that too if there's some docs that
outline the expected behavior.

Using vdsm-reg or something similar seems like a better fit for puppet
deployed nodes, as opposed to requiring GUI steps to add the node.

Thanks
- Trey
On Aug 4, 2014 5:53 AM, "ybronhei"  wrote:


On 07/31/2014 01:28 AM, Trey Dockendorf wrote:


I'm running ovirt nodes that are stock CentOS 6.5 systems with VDSM
installed.  I am using iSER to do iSCSI over RDMA and to make that
work I have to modify /etc/vdsm/vdsm.conf to include the following:

[irs]
iscsi_default_ifaces = iser,default

I've noticed that any time I upgrade a node from the engine web
interface that changes to vdsm.conf are wiped out.  I don't know if
this is being done by the configuration code or by the vdsm package.
Is there a more reliable way to ensure changes to vdsm.conf are NOT
removed automatically?



Hey,

vdsm.conf shouldn't wiped out and shouldn't changed at all during upgrade.
other related conf files (such as libvirtd.conf) might be overrided to keep
defaults configurations for vdsm. but vdsm.conf should persist with user's
modification. from my check, regular yum upgrade doesn't touch vdsm.conf

Douglas can you verify that with node upgrade? might be specific to that
flow..

Trey, can file a bugzilla on that and describe your steps there?

Thanks

Yaniv Bronhaim,



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




--
Yaniv Bronhaim.




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

Re: [ovirt-users] Proper way to change and persist vdsm configuration options

[ybronhei]

On 08/05/2014 08:12 AM, Trey Dockendorf wrote:

I'll file BZ.  As far as I can recall this has been an issue since 3.3.x as

please send a link to the BZ, or assign me there

I have been using Puppet to modify values and have had to rerun Puppet
after installing a node via GUI and when performing update from GUI.  Given
that it has occurred when VDSM version didn't change on the node it seems
likely to be something being done by Python code that bootstraps a node and
performs the other tasks.  I won't have any systems available to test with
for a few days.  New hardware specifically for our oVirt deployment is on
order so should be able to more thoroughly debug and capture logs at that
time.

Would using vdsm-reg be a better solution for adding new nodes?  I only
tried using vdsm-reg once and it went very poorly...lots of missing
dependencies not pulled in from yum install I had to install manually via
yum.  Then the node was auto added to newest cluster with no ability to
change the cluster.  Be happy to debug that too if there's some docs that
outline the expected behavior.

Using vdsm-reg or something similar seems like a better fit for puppet
deployed nodes, as opposed to requiring GUI steps to add the node.
please consult Fabian\Douglas on using vdsm-reg, though, I don't think 
it will do any change. after vdsm-reg engine still runs host-deploy 
process and this might overrides your vdsm.conf (which I need to test)


Thanks
- Trey
On Aug 4, 2014 5:53 AM, "ybronhei"  wrote:


On 07/31/2014 01:28 AM, Trey Dockendorf wrote:


I'm running ovirt nodes that are stock CentOS 6.5 systems with VDSM
installed.  I am using iSER to do iSCSI over RDMA and to make that
work I have to modify /etc/vdsm/vdsm.conf to include the following:

[irs]
iscsi_default_ifaces = iser,default

I've noticed that any time I upgrade a node from the engine web
interface that changes to vdsm.conf are wiped out.  I don't know if
this is being done by the configuration code or by the vdsm package.
Is there a more reliable way to ensure changes to vdsm.conf are NOT
removed automatically?



Hey,

vdsm.conf shouldn't wiped out and shouldn't changed at all during upgrade.
other related conf files (such as libvirtd.conf) might be overrided to keep
defaults configurations for vdsm. but vdsm.conf should persist with user's
modification. from my check, regular yum upgrade doesn't touch vdsm.conf

Douglas can you verify that with node upgrade? might be specific to that
flow..

Trey, can file a bugzilla on that and describe your steps there?

Thanks

Yaniv Bronhaim,



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




--
Yaniv Bronhaim.






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

Re: [ovirt-users] Proper way to change and persist vdsm configuration options

[ybronhei]

On 07/31/2014 01:28 AM, Trey Dockendorf wrote:

I'm running ovirt nodes that are stock CentOS 6.5 systems with VDSM
installed.  I am using iSER to do iSCSI over RDMA and to make that
work I have to modify /etc/vdsm/vdsm.conf to include the following:

[irs]
iscsi_default_ifaces = iser,default

I've noticed that any time I upgrade a node from the engine web
interface that changes to vdsm.conf are wiped out.  I don't know if
this is being done by the configuration code or by the vdsm package.
Is there a more reliable way to ensure changes to vdsm.conf are NOT
removed automatically?


Hey,

vdsm.conf shouldn't wiped out and shouldn't changed at all during 
upgrade. other related conf files (such as libvirtd.conf) might be 
overrided to keep defaults configurations for vdsm. but vdsm.conf should 
persist with user's modification. from my check, regular yum upgrade 
doesn't touch vdsm.conf


Douglas can you verify that with node upgrade? might be specific to that 
flow..


Trey, can file a bugzilla on that and describe your steps there?

Thanks

Yaniv Bronhaim,


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




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

[ovirt-users] Test-Day 3.5-2 -> Import Storage Domain

[ybronhei]

Hey all,

following the updated wikis - 
http://www.ovirt.org/Features/ImportUnregisteredEntities and 
http://www.ovirt.org/Features/ImportStorageDomain which describe in 
details the steps for import storage domain I successfully created a 
cluster with 1 hosts and 3 vms.

(host and engine run with rhel6.5)

Changed some of the details for the vms (ha, system infos, mem, cpus and 
more), then cleaned up the engine (ran engine-cleanup and rerun 
engine-setup). On clean environment I created new cluster with new 
storage domain (its a must currently to create new storage domain before 
the import - stated in the [1]). After that I imported the original sd 
that I used, went to import Virtual machines tab and imported all 
entities I had.


All of the vms' details were imported successfully with the same info 
that I configured before the cleanup.


Tried again also with templates and snapshots recovery, also worked as 
expected


seems green to me.

anything else you would like me to check in this area?

[1] http://www.ovirt.org/Features/ImportStorageDomain#Implementation_gaps

Thanks,
--
Yaniv Bronhaim.
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] starting VDSM gives "libvir: XML-RPC error : authentication failed: authentication failed" error

[ybronhei]

On 07/21/2014 01:45 AM, Jorick Astrego wrote:

Hi,

Some more info, I think this is the problem and I also have it on the
node image:

Jul 20 22:41:49 localhost libvirtd: unable to open Berkeley db
/etc/libvirt/passwd.db: No such file or directory


Hey

Did you check if libvirtd services is up?
can you share libvirtd.conf file?
I'm not sure what is exactly the issue, but you can try "vdsm-tool 
configure --module libvirt" command to see if you set the vdsm 
configuration for libvirt as required.


Regards,
Yaniv Bronhaim


Kind regards,
Jorick Astrego
Netbulae

On 07/19/2014 06:52 PM, Jorick Astrego wrote:

Good day,

Trying to setup a new 3.5 test environment with centos 6.5 as ovirt node.

But I keep getting these errors:

libvir: XML-RPC error : authentication failed: authentication failed
libvir: XML-RPC error : authentication failed: authentication failed
libvir: XML-RPC error : authentication failed: authentication failed
libvir: XML-RPC error : authentication failed: authentication failed
libvir: XML-RPC error : authentication failed: authentication failed
libvir: XML-RPC error : authentication failed: authentication failed
Traceback (most recent call last):
  File "/usr/bin/vdsm-tool", line 154, in main
return tool_command[cmd]["command"](*args)
  File "/usr/lib64/python2.6/site-packages/vdsm/tool/nwfilter.py",
line 37, in main
conn = libvirtconnection.get(None, False)
  File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py",
line 151, in get
conn = _open_qemu_connection()
  File "/usr/lib64/python2.6/site-packages/vdsm/libvirtconnection.py",
line 95, in _open_qemu_connection
return utils.retry(libvirtOpen, timeout=10, sleep=0.2)
  File "/usr/lib64/python2.6/site-packages/vdsm/utils.py", line 1086,
in retry
return func()
  File "/usr/lib64/python2.6/site-packages/libvirt.py", line 102, in
openAuth
if ret is None:raise libvirtError('virConnectOpenAuth() failed')
libvirtError: authentication failed: authentication failed

2014-07-19 16:45:20 DEBUG otopi.context context._executeMethod:152
method exception
Traceback (most recent call last):
  File "/tmp/ovirt-TTJojY73zc/pythonlib/otopi/context.py", line 142,
in _executeMethod
method['method']()
  File
"/tmp/ovirt-TTJojY73zc/otopi-plugins/ovirt-host-deploy/vdsm/packages.py",
line 219, in _start
self.services.state('vdsmd', True)
  File "/tmp/ovirt-TTJojY73zc/otopi-plugins/otopi/services/rhel.py",
line 188, in state
'start' if state else 'stop'
  File "/tmp/ovirt-TTJojY73zc/otopi-plugins/otopi/services/rhel.py",
line 96, in _executeServiceCommand
raiseOnError=raiseOnError
  File "/tmp/ovirt-TTJojY73zc/pythonlib/otopi/plugin.py", line 871, in
execute
command=args[0],
RuntimeError: Command '/sbin/service' failed to execute
2014-07-19 16:45:20 ERROR otopi.context context._executeMethod:161
Failed to execute stage 'Closing up': Command '/sbin/service' failed
to execute

I tried adding the node through ovirt engine interface and the manual
instrutions on the wiki
(http://wiki.ovirt.org/Installing_ovirt-node_from_rpm)

Running "service vdsm reconfigure" tells me everything is ok.

Thanks in advance!

Kind regards,
Jorick Astrego
Netbulae


___
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



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

[ovirt-users] [ovirt-devel] ovirt 3.5 Test day 1 - Import Storage Domain

[ybronhei]

Hey,
I assigned myself to the Import Storage Domain feature [1] in the first
ovirt 3.5 test day

Currently I checked that when setting OvfUpdateIntervalInMinutes (on 
vdc_options) to 2 minutes, it saves the ovf files as expected. After 
setting up new environment and importing the same nfs path that I used 
as storage domain, ovirt recovered my setup properly


I'll play with it more on second test day.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1083307

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

Re: [ovirt-users] feedback-on-oVirt-engine-3.4.2-1.el6 -- Network configuration issue with oVirt all is one sol

[ybronhei]

On 06/17/2014 10:23 AM, Sandro Bonazzola wrote:

Il 12/06/2014 15:06, Vikrant Pawar ha scritto:

Hi,



I tried to install oVirt on RHEL 6.4 with all in one package.



I found single  in summary:

[ INFO  ] Still waiting for VDSM host to become operational...

[ ERROR ] Timed out while waiting for host to start. Please check the logs.


Hi Vikrant,
can you upload somewhere the host-deploy, vdsm, supervdsm and libvirt logs too?
and will be great if you also attach your syslog's output 
(/var/log/messages)

Have you opened a BZ for this?





[WARNING] Local storage domain not added because the VDSM host was not up. 
Please add it manually.

[ INFO  ] Restarting nfs services



Went ahead restarted vsdm, login to admin portal.



First Issue I observed that Storage is not accessible over NFS.



Second issue is “Host local_host installation failed. Failed to configure 
management network on the host.”


Yaniv, this look like the issue we've seen on hosted engine deploy but need 
vdsm log to confirm.






I’m attaching installation log.



Let me know if there are any workaround / How to revert all changes so that I 
could try one – by – one installation of oVirt.


To revert changes you should just run engine-cleanup.
I guess he meant to revet to the old version. but I prefer to avoid 
that, lets check the logs and see how you can proceed






Thanks,

Vikrant Pawar



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







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

Re: [ovirt-users] off topic = newbie with bugzilla, gerrit and ovirt VDSM 4.14

[ybronhei]

On 04/11/2014 06:24 PM, Dan Kenigsberg wrote:

On Fri, Apr 11, 2014 at 04:06:48PM +0300, Itamar Heim wrote:

On 04/10/2014 11:04 PM, Tamer Lima wrote:


hi,

I have now ovirt 3.4 with vdsm 4.14


danken - the bug you referenced is fixed in 3.3, yet recurs in 3.4?


I have very little explanations.

The bug was hidden by an ad-hoc patch, adding "4.13" to
SupportedVDSMVersions. I hope that Yaniv, Yair or Eli have better
knowledge about the real fix, of honoring vdsm's supportedENGINEs again.


Hey Tamer,

until patch [1] will be merge, you can do the following:
where your engine is installed connect as root
than, "su - postgres"
than run,
psql [your-table-name, the default is "engine" if you didn't change it]
(e.g "psql engine")
than run
" update vdc_options set option_value = '4.9,4.10,4.11,4.12,4.13,4.14'
where option_name = 'SupportedVDSMVersions' "

control+d to get out of psql

restart engine service, and try to activate the host again

this is a workaround to work with current implementation of validate the 
compatibility of the host to join the cluster. it adds vdsm 4.14 to the 
supported vdsm versions.


please reply with the results

regards,







Well, my question is not exactly how to solve an specific problem.
  In fact, what I want is learn how to apply the corrections proposed on
bugzila, gerrit, etc.  Or this is only for ovirt internal developers ?
thanks


we'll be happy if you try.
this would be the starting point. if anything is not clear, ask, and
we should probably add it there:
http://www.ovirt.org/Develop



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

Re: [ovirt-users] off topic = newbie with bugzilla, gerrit and ovirt VDSM 4.14

[ybronhei]

On 04/11/2014 06:24 PM, Dan Kenigsberg wrote:

On Fri, Apr 11, 2014 at 04:06:48PM +0300, Itamar Heim wrote:

On 04/10/2014 11:04 PM, Tamer Lima wrote:


hi,

I have now ovirt 3.4 with vdsm 4.14


danken - the bug you referenced is fixed in 3.3, yet recurs in 3.4?


I have very little explanations.

The bug was hidden by an ad-hoc patch, adding "4.13" to
SupportedVDSMVersions. I hope that Yaniv, Yair or Eli have better
knowledge about the real fix, of honoring vdsm's supportedENGINEs again.



Hey Tamer,
actually, as dan stated, this is a bug that we currently work on.

please check if http://gerrit.ovirt.org/#/c/26061 uses the 
supportedEngines set as should. with this patch the host should join the 
cluster properly.




Well, my question is not exactly how to solve an specific problem.
  In fact, what I want is learn how to apply the corrections proposed on
bugzila, gerrit, etc.  Or this is only for ovirt internal developers ?
thanks


we'll be happy if you try.
this would be the starting point. if anything is not clear, ask, and
we should probably add it there:
http://www.ovirt.org/Develop



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

Re: [Users] affects of changing compatibility setting on running cluster

[ybronhei]

On 03/12/2014 04:33 PM, Itamar Heim wrote:

On 03/12/2014 04:32 PM, ybronhei wrote:

On 03/12/2014 04:25 PM, Dan Kenigsberg wrote:

On Wed, Mar 12, 2014 at 10:15:21AM +0200, Itamar Heim wrote:

On 03/12/2014 10:11 AM, Sven Kieske wrote:



Am 11.03.2014 17:38, schrieb Itamar Heim:


i understood this to "you can't use 4.14 with 3.4.0".


Well I examined BZ 1067096 again, this is what did not work:

Steps to Reproduce:
1.  Run Engine 3.3 Compatibility level 3.2 or 3.3
2.  Add node (vdsm 4.14)

Actual results:
Host is installed with VDSM version (4.14) and cannot join cluster
which
is compatible with VDSM versions [4.13, 4.9, 4.11, 4.12, 4.10].

Pay attention to the engine version, it states 3.3. not 3.4.0

So my conclusion is, you can't install vdsm 4.14. when you want
to use engine 3.3.

Am I reading something wrong?

Here's the link again:
https://bugzilla.redhat.com/show_bug.cgi?id=1067096#c0



this can be fixed via engine config, but is not supposed to be
needed, as vdsm is supposed to have
vdsm/dsaversion.py.in:'supportedENGINEs': ['3.0', '3.1', '3.2',
'3.3', '3.4'],

danken/eli - thoughts?


I do not really understand why we have this recurrent Engine bug, of
ignoring supportedENGINEs; I think Yaniv does.



i recall asking for detailed explanation for why do we have 3 different
restrictions , one for supportedEngines, one for the allowed vdsm
versions, and one for the cluster level?

if vdsm version is supported why isn't it in engine's capabilities yet?


because its a vdsm version which was released after that engine was
released, hence the vdsm package has to declare its supporting the old
engine.



so its an hack to allow users to add beta vdsm version to new engine 
release?.. sounds like that


please reopen if it reproduced



the issue was verified in
https://bugzilla.redhat.com/show_bug.cgi?id=1016461 , please reopen if
it still appears








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

Re: [Users] affects of changing compatibility setting on running cluster

[ybronhei]

On 03/12/2014 04:25 PM, Dan Kenigsberg wrote:

On Wed, Mar 12, 2014 at 10:15:21AM +0200, Itamar Heim wrote:

On 03/12/2014 10:11 AM, Sven Kieske wrote:



Am 11.03.2014 17:38, schrieb Itamar Heim:


i understood this to "you can't use 4.14 with 3.4.0".


Well I examined BZ 1067096 again, this is what did not work:

Steps to Reproduce:
1.  Run Engine 3.3 Compatibility level 3.2 or 3.3
2.  Add node (vdsm 4.14)

Actual results:
Host is installed with VDSM version (4.14) and cannot join cluster which
is compatible with VDSM versions [4.13, 4.9, 4.11, 4.12, 4.10].

Pay attention to the engine version, it states 3.3. not 3.4.0

So my conclusion is, you can't install vdsm 4.14. when you want
to use engine 3.3.

Am I reading something wrong?

Here's the link again:
https://bugzilla.redhat.com/show_bug.cgi?id=1067096#c0



this can be fixed via engine config, but is not supposed to be
needed, as vdsm is supposed to have
vdsm/dsaversion.py.in:'supportedENGINEs': ['3.0', '3.1', '3.2',
'3.3', '3.4'],

danken/eli - thoughts?


I do not really understand why we have this recurrent Engine bug, of
ignoring supportedENGINEs; I think Yaniv does.



i recall asking for detailed explanation for why do we have 3 different 
restrictions , one for supportedEngines, one for the allowed vdsm 
versions, and one for the cluster level?


if vdsm version is supported why isn't it in engine's capabilities yet?

the issue was verified in 
https://bugzilla.redhat.com/show_bug.cgi?id=1016461 , please reopen if 
it still appears




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

[Users] [oVirt Test Day 3] ovirt-guest-agent

[ybronhei]

I tried ovirt-guest-agent over fedora 19 and 20,
- installed a vm with f19
- yum install ovirt-guest-agent
- started the service
- the information about machine name, ip address, os, ram, user all 
appeared after installation

- notification for power off also appears

same for f20
looks ok on both

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

Re: [Users] latest vdsm cannot read ib device speeds causing storage attach fail

[ybronhei]

On 01/24/2013 12:44 AM, Dead Horse wrote:

I narrowed down on the commit where the originally reported issue crept in:
commitfc3a44f71d2ef202cff18d7203b9e4165b546621building and testing with
this commit or subsequent commits yields the original issue.
Interesting.. it might be related to this commit and we're trying to 
reproduce it.


Did you try to remove that code and run again? does it work without the 
additional of zombieReaper?
does the connectivity to the storage work well? when you run 'ls' on the 
mounted folder you get see the files without a long delay ? it might 
related to too long timeout when validating access to this mount..

we work on that.. any additional info can help

Thanks.


- DHC


On Wed, Jan 23, 2013 at 3:56 PM, Dead Horse
wrote:


Indeed reverting back to an older vdsm clears up the above issue. However
now I the issue is see is:
Thread-18::ERROR::2013-01-23
15:50:42,885::task::833::TaskManager.Task::(_setError)
Task=`08709e68-bcbc-40d8-843a-d69d4df40ac6`::Unexpected error

Traceback (most recent call last):
   File "/usr/share/vdsm/storage/task.py", line 840, in _run
 return fn(*args, **kargs)
   File "/usr/share/vdsm/logUtils.py", line 42, in wrapper
 res = f(*args, **kwargs)
   File "/usr/share/vdsm/storage/hsm.py", line 923, in connectStoragePool
 masterVersion, options)
   File "/usr/share/vdsm/storage/hsm.py", line 970, in _connectStoragePool
 res = pool.connect(hostID, scsiKey, msdUUID, masterVersion)
   File "/usr/share/vdsm/storage/sp.py", line 643, in connect
 self.__rebuild(msdUUID=msdUUID, masterVersion=masterVersion)
   File "/usr/share/vdsm/storage/sp.py", line 1167, in __rebuild
 self.masterDomain = self.getMasterDomain(msdUUID=msdUUID,
masterVersion=masterVersion)
   File "/usr/share/vdsm/storage/sp.py", line 1506, in getMasterDomain
 raise se.StoragePoolMasterNotFound(self.spUUID, msdUUID)
StoragePoolMasterNotFound: Cannot find master domain:
'spUUID=f90a0d1c-06ca-11e2-a05b-00151712f280,
msdUUID=67534cca-1327-462a-b455-a04464084b31'
Thread-18::DEBUG::2013-01-23
15:50:42,887::task::852::TaskManager.Task::(_run)
Task=`08709e68-bcbc-40d8-843a-d69d4df40ac6`::Task._run:
08709e68-bcbc-40d8-843a-d69d4df40ac6
('f90a0d1c-06ca-11e2-a05b-00151712f280', 2,
'f90a0d1c-06ca-11e2-a05b-00151712f280',
'67534cca-1327-462a-b455-a04464084b31', 433) {} failed - stopping task

This is with vdsm built from
commit25a2d8572ad32352227c98a86631300fbd6523c1
- DHC


On Wed, Jan 23, 2013 at 10:44 AM, Dead Horse <
deadhorseconsult...@gmail.com> wrote:


VDSM was built from:
commit 166138e37e75767b32227746bb671b1dab9cdd5e

Attached is the full vdsm log

I should also note that from engine perspective it sees the master
storage domain as locked and the others as unknown.


On Wed, Jan 23, 2013 at 2:49 AM, Dan Kenigsberg wrote:


On Tue, Jan 22, 2013 at 04:02:24PM -0600, Dead Horse wrote:

Any ideas on this one? (from VDSM log):
Thread-25::DEBUG::2013-01-22
15:35:29,065::BindingXMLRPC::914::vds::(wrapper) client

[3.57.111.30]::call

getCapabilities with () {}
Thread-25::ERROR::2013-01-22 15:35:29,113::netinfo::159::root::(speed)
cannot read ib0 speed
Traceback (most recent call last):
   File "/usr/lib64/python2.6/site-packages/vdsm/netinfo.py", line 155,

in

speed
 s = int(file('/sys/class/net/%s/speed' % dev).read())
IOError: [Errno 22] Invalid argument

Causes VDSM to fail to attach storage


I doubt that this is the cause of the failure, as vdsm has always
reported "0" for ib devices, and still is.
it happens only when you call to getCapabilities.. so it doesn't related 
to the flow, and it can't effect the storage.

Dan: I guess this is not the issue but why is the IOError?


Does a former version works with your Engine?
Could you share more of your vdsm.log? I suppose the culprit lies in one
one of the storage-related commands, not in statistics retrieval.



Engine side sees:
ERROR [org.ovirt.engine.core.bll.storage.NFSStorageHelper]
(QuartzScheduler_Worker-96) [553ef26e] The connection with details
192.168.0.1:/ovirt/ds failed because of error code 100 and error

message

is: general exception
2013-01-22 15:35:30,160 INFO
[org.ovirt.engine.core.bll.SetNonOperationalVdsCommand]
(QuartzScheduler_Worker-96) [1ab78378] Running command:
SetNonOperationalVdsCommand internal: true. Entities affected :  ID:
8970b3fe-1faf-11e2-bc1f-00151712f280 Type: VDS
2013-01-22 15:35:30,200 INFO
[org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand]
(QuartzScheduler_Worker-96) [1ab78378] START,
SetVdsStatusVDSCommand(HostName = kezan, HostId =
8970b3fe-1faf-11e2-bc1f-00151712f280, status=NonOperational,
nonOperationalReason=STORAGE_DOMAIN_UNREACHABLE), log id: 4af5c4cd
2013-01-22 15:35:30,211 INFO
[org.ovirt.engine.core.vdsbroker.SetVdsStatusVDSCommand]
(QuartzScheduler_Worker-96) [1ab78378] FINISH, SetVdsStatusVDSCommand,

log

id: 4af5c4cd
2013-01-22 15:35:30,242 ERROR
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector]
(QuartzScheduler_Worker-96) [1ab

Re: [Users] problems adding a domain

[ybronhei]

On 12/03/2012 11:47 AM, Cristian Falcas wrote:




On Mon, Dec 3, 2012 at 9:08 AM, Roy Golan > wrote:


On 12/02/2012 10:52 PM, Cristian Falcas wrote:




On Fri, Nov 30, 2012 at 1:53 AM, Cristian Falcas
mailto:cristi.fal...@gmail.com>> wrote:

Hi all,

I had some problems with the beta version and I tried again
the nightly builds. i think that somewhere in the code the
domain is not added correctly. Trying to add a domain, I got
this in the logs:

2012-11-30 01:38:33,962 DEBUG
[org.apache.commons.configuration.ConfigurationUtils]
ConfigurationUtils.locate(): base is null, name is
/etc/ovirt-engine/engine-manage-domains/engine-manage-domains.conf
2012-11-30 01:38:33,977 DEBUG
[org.apache.commons.configuration.ConfigurationUtils] Loading
configuration from the absolute path
/etc/ovirt-engine/engine-manage-domains/engine-manage-domains.conf
2012-11-30 01:38:37,523 ERROR
[org.ovirt.engine.core.utils.dns.DnsSRVLocator] Error: could
not find DNS SRV record name: _ldap._tcp..
Exception message is: DNS name not found [response code 3]
Possible causes: missing DNS entries in the DNS server or DNS
resolving issues from engine-core machine.
Please Ensure correct DNS entries exist in the DNS server and
ensure the DNS server is reachable from the engine-core machine.
2012-11-30 01:38:37,523 DEBUG
[org.ovirt.engine.core.utils.kerberos.ManageDomainsResult]
Got null value.
2012-11-30 01:38:37,527 ERROR
[org.ovirt.engine.core.utils.kerberos.ManageDomains] Failed
reading current configuration. Details: Could not locate LDAP
servers to be used to validate the input of the utility


It looks like it's trying to get the info for " _ldap._tcp."
instead of " _ldap._tcp.domain"?

Best regards,
Cristian Falcas



Hi,

I still have the same error with the nighly builds. Can anyone
tell me is this is an error on my side or if I should wait for a fix?




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


pls attach the whole log and the full command line.

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



Also the file /etc/ovirt-engine/krb5.conf is not created.

Doing a tcpdump trace, I it's asking the dns server to resolve the 
name "_ldap._tcp". The response is "Standard query response, No such 
name".


Command:
engine-manage-domains -action=add -domain=company.com 
 -provider=ActiveDirectory -user=user.name 
 -passwordFile=/tmp/pass


Logs:

2012-12-02 22:56:44,038 DEBUG 
[org.apache.commons.configuration.ConfigurationUtils] 
ConfigurationUtils.locate(): base is null, name is 
/etc/ovirt-engine/engine-manage-domains/engine-manage-domains.conf
2012-12-02 22:56:44,052 DEBUG 
[org.apache.commons.configuration.ConfigurationUtils] Loading 
configuration from the absolute path 
/etc/ovirt-engine/engine-manage-domains/engine-manage-domains.conf
2012-12-02 22:56:48,033 ERROR 
[org.ovirt.engine.core.utils.dns.DnsSRVLocator] Error: could not find 
DNS SRV record name: _ldap._tcp..

Exception message is: DNS name not found [response code 3]
Possible causes: missing DNS entries in the DNS server or DNS 
resolving issues from engine-core machine.
Please Ensure correct DNS entries exist in the DNS server and ensure 
the DNS server is reachable from the engine-core machine.
2012-12-02 22:56:48,033 DEBUG 
[org.ovirt.engine.core.utils.kerberos.ManageDomainsResult] Got null value.
2012-12-02 22:56:48,050 ERROR 
[org.ovirt.engine.core.utils.kerberos.ManageDomains] Failed reading 
current configuration. Details: Could not locate LDAP servers to be 
used to validate the input of the utility




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

Well, it sounds like the dns server can't resolve the name you gave,
Maybe the user 'user.name' does not exist ? maybe the domain company.com 
does not reachable (try to use explicit ip address)? Please verify both 
and try to add the domain again with existing user


--
Yaniv Bronhaim.
RedHat, Israel
09-7692289
054-7744187

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