Re: [ovirt-users] ovirt-ha-agent cpu usage

2016-10-07 Thread Gianluca Cecchi 
On Fri, Oct 7, 2016 at 2:59 PM, Nir Soffer  wrote:

>
>> wasn’t it suppose to be fixed to reuse the connection? Like all the other
>> clients (vdsm migration code:-)
>>
>
> This is orthogonal issue.
>
>
>> Does schema validation matter then if there would be only one connection
>> at the start up?
>>
>
> Loading once does not help command line tools like vdsClient,
> hosted-engine and
> vdsm-tool.
>
> Nir
>
>
>>
>>
 Simone, reusing the connection is good idea anyway, but what you
 describe is
 a bug in the client library. The library does *not* need to load and
 parse the
 schema at all for sending requests to vdsm.

 The schema is only needed if you want to verify request parameters,
 or provide online help, these are not needed in a client library.

 Please file an infra bug about it.

>>>
>>> Done, https://bugzilla.redhat.com/show_bug.cgi?id=1381899
>>>
>>
>> Here is a patch that should eliminate most most of the problem:
>> https://gerrit.ovirt.org/65230
>>
>> Would be nice if it can be tested on the system showing this problem.
>>
>> Cheers,
>> Nir
>> ___
>>
>>

this is a video of 1 minute with the same system as the first post, but in
4.0.3 now and the same 3 VMs powered on without any particular load.
It seems very similar to the previous 3.6.6 in cpu used by ovirt-ha-agent.

https://drive.google.com/file/d/0BwoPbcrMv8mvSjFDUERzV1owTG8/view?usp=sharing

Enjoy Nir ;-)

If I can apply the patch also to 4.0.3 I'm going to see if there is then a
different behavior.
Let me know,

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

Re: [ovirt-users] ovirt-ha-agent cpu usage

2016-10-07 Thread Michal Skrivanek 

> On 7 Oct 2016, at 14:59, Nir Soffer  wrote:
> 
> On Fri, Oct 7, 2016 at 3:52 PM, Michal Skrivanek  > wrote:
> 
>> On 7 Oct 2016, at 14:42, Nir Soffer > > wrote:
>> 
>> On Wed, Oct 5, 2016 at 1:33 PM, Simone Tiraboschi > > wrote:
>> 
>> 
>> On Wed, Oct 5, 2016 at 10:34 AM, Nir Soffer > > wrote:
>> On Wed, Oct 5, 2016 at 10:24 AM, Simone Tiraboschi > > wrote:
>> 
>> 
>> On Wed, Oct 5, 2016 at 9:17 AM, gregor > > wrote:
>> Hi,
>> 
>> did you found a solution or cause for this high CPU usage?
>> I have installed the self hosted engine on another server and there is
>> no VM running but ovirt-ha-agent uses heavily the CPU.
>> 
>> Yes, it's due to the fact that ovirt-ha-agent periodically reconnects over 
>> json rpc and this is CPU intensive since the client has to parse the yaml 
>> API specification each time it connects.
> 
> wasn’t it suppose to be fixed to reuse the connection? Like all the other 
> clients (vdsm migration code:-) 
> 
> This is orthogonal issue.

Yes it is. And that’s the issue;-)
Both are wrong, but by “fixing” the schema validation only you lose the 
motivation to fix the meaningless wasteful reconnect

>  
> Does schema validation matter then if there would be only one connection at 
> the start up?
> 
> Loading once does not help command line tools like vdsClient, hosted-engine 
> and
> vdsm-tool. 

none of the other tools is using json-rpc.

> 
> Nir
>  
> 
>> 
>> Simone, reusing the connection is good idea anyway, but what you describe is 
>> a bug in the client library. The library does *not* need to load and parse 
>> the
>> schema at all for sending requests to vdsm.
>> 
>> The schema is only needed if you want to verify request parameters,
>> or provide online help, these are not needed in a client library.
>> 
>> Please file an infra bug about it.
>> 
>> Done, https://bugzilla.redhat.com/show_bug.cgi?id=1381899 
>> 
>> 
>> Here is a patch that should eliminate most most of the problem:
>> https://gerrit.ovirt.org/65230 
>> 
>> Would be nice if it can be tested on the system showing this problem.
>> 
>> Cheers,
>> Nir
>> ___
>> 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

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

Re: [ovirt-users] ovirt-ha-agent cpu usage

2016-10-07 Thread Simone Tiraboschi 
On Fri, Oct 7, 2016 at 3:22 PM, Gianluca Cecchi 
wrote:

> On Fri, Oct 7, 2016 at 2:59 PM, Nir Soffer  wrote:
>
>>
>>> wasn’t it suppose to be fixed to reuse the connection? Like all the
>>> other clients (vdsm migration code:-)
>>>
>>
>> This is orthogonal issue.
>>
>>
>>> Does schema validation matter then if there would be only one connection
>>> at the start up?
>>>
>>
>> Loading once does not help command line tools like vdsClient,
>> hosted-engine and
>> vdsm-tool.
>>
>> Nir
>>
>>
>>>
>>>
> Simone, reusing the connection is good idea anyway, but what you
> describe is
> a bug in the client library. The library does *not* need to load and
> parse the
> schema at all for sending requests to vdsm.
>
> The schema is only needed if you want to verify request parameters,
> or provide online help, these are not needed in a client library.
>
> Please file an infra bug about it.
>

 Done, https://bugzilla.redhat.com/show_bug.cgi?id=1381899

>>>
>>> Here is a patch that should eliminate most most of the problem:
>>> https://gerrit.ovirt.org/65230
>>>
>>> Would be nice if it can be tested on the system showing this problem.
>>>
>>> Cheers,
>>> Nir
>>> ___
>>>
>>>
>
> this is a video of 1 minute with the same system as the first post, but in
> 4.0.3 now and the same 3 VMs powered on without any particular load.
> It seems very similar to the previous 3.6.6 in cpu used by ovirt-ha-agent.
>
> https://drive.google.com/file/d/0BwoPbcrMv8mvSjFDUERzV1owTG8/
> view?usp=sharing
>
> Enjoy Nir ;-)
>
> If I can apply the patch also to 4.0.3 I'm going to see if there is then a
> different behavior.
> Let me know,
>
>
I'm trying it right now.
Any other tests will be really appreciated.

The patch is pretty simply, you can apply that on the fly.
You have to shutdown ovirt-ha-broker and ovirt-ha-agent; then you could
directly edit
/usr/lib/python2.7/site-packages/api/vdsmapi.py
around line 97 changing from
loaded_schema = yaml.load(f)
to
loaded_schema = yaml.load(f, Loader=yaml.CLoader)
Please pay attention to keep exactly the same amount of initial spaces.

Then you can simply restart the HA agent and check.

Gianluca
>
> ___
> 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] Can't add host - Failed to read hardware information

2016-10-07 Thread Michal Skrivanek 

> On 7 Oct 2016, at 12:52, David Pinkerton  wrote:
> 
> I'm trying to add a host to a freshly built cluster.
> 
> yum install finishes, then the message " Failed to read hardware information" 
> is displayed - host has installation failed.  
> If I try to re-install I get the same message and the host goes 
> non-responsive.
> 
> 
> engine log:
> 
> 2016-10-07 21:13:46,525 INFO  
> [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) 
> [2854e702] Connecting to /192.168.21.71 
> 2016-10-07 21:13:46,526 ERROR 
> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand] 
> (DefaultQuartzScheduler4) [3fa97b73] Command 
> 'GetCapabilitiesVDSCommand(HostName = rhv1, 
> VdsIdAndVdsVDSCommandParametersBase:{runAsync='true', 
> hostId='96358424-a14e-4d29-957f-3d7ddac99c12', 
> vds='Host[rhv1,96358424-a14e-4d29-957f-3d7ddac99c12]'})' execution failed: 
> org.ovirt.vdsm.jsonrpc.client.ClientConnectionException: Connection failed
> 2016-10-07 21:13:46,526 ERROR 
> [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] 
> (DefaultQuartzScheduler4) [3fa97b73] Failure to refresh Vds runtime info: 
> org.ovirt.vdsm.jsonrpc.client.ClientConnectionException: Connection failed
> 2016-10-07 21:13:46,526 ERROR 
> [org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring] 
> (DefaultQuartzScheduler4) [3fa97b73] Exception: 
> org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException: 
> org.ovirt.vdsm.jsonrpc.client.ClientConnectionException: Connection failed
> at 
> org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.createNetworkException(VdsBrokerCommand.java:157)
>  [vdsbroker.jar:]
> at 
> org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:120)
>  [vdsbroker.jar:]
> at 
> org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:73)
>  [vdsbroker.jar:]
> at 
> org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:33) 
> [dal.jar:]
> at 
> org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:451)
>  [vdsbroker.jar:]
> at 
> org.ovirt.engine.core.vdsbroker.VdsManager.refreshCapabilities(VdsManager.java:653)
>  [vdsbroker.jar:]
> at 
> org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring.refreshVdsRunTimeInfo(HostMonitoring.java:121)
>  [vdsbroker.jar:]
> at 
> org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring.refresh(HostMonitoring.java:85)
>  [vdsbroker.jar:]
> at 
> org.ovirt.engine.core.vdsbroker.VdsManager.onTimer(VdsManager.java:238) 
> [vdsbroker.jar:]
> at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source) 
> [:1.8.0_102]
> at 
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
>  [rt.jar:1.8.0_102]
> at java.lang.reflect.Method.invoke(Method.java:498) [rt.jar:1.8.0_102]
> at 
> org.ovirt.engine.core.utils.timer.JobWrapper.invokeMethod(JobWrapper.java:77) 
> [scheduler.jar:]
> at 
> org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.java:51) 
> [scheduler.jar:]
> at org.quartz.core.JobRunShell.run(JobRunShell.java:213) [quartz.jar:]
> at 
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
> [rt.jar:1.8.0_102]
> at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
> [rt.jar:1.8.0_102]
> at 
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
>  [rt.jar:1.8.0_102]
> at 
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
>  [rt.jar:1.8.0_102]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_102]
> Caused by: org.ovirt.vdsm.jsonrpc.client.ClientConnectionException: 
> Connection failed
> at 
> org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient.connect(ReactorClient.java:165)
>  [vdsm-jsonrpc-java-client.jar:]
> at 
> org.ovirt.vdsm.jsonrpc.client.JsonRpcClient.getClient(JsonRpcClient.java:134) 
> [vdsm-jsonrpc-java-client.jar:]
> at 
> org.ovirt.vdsm.jsonrpc.client.JsonRpcClient.call(JsonRpcClient.java:81) 
> [vdsm-jsonrpc-java-client.jar:]
> at 
> org.ovirt.engine.core.vdsbroker.jsonrpc.FutureMap.(FutureMap.java:70) 
> [vdsbroker.jar:]
> at 
> org.ovirt.engine.core.vdsbroker.jsonrpc.JsonRpcVdsServer.getCapabilities(JsonRpcVdsServer.java:258)
>  [vdsbroker.jar:]
> at 
> org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand.executeVdsBrokerCommand(GetCapabilitiesVDSCommand.java:15)
>  [vdsbroker.jar:]
> at 
> org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:110)
>  [vdsbroker.jar:]
> ... 18 more
> 
> 2016-10-07 21:13:49,531 INFO  
> [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor) 
> [2854e702] Connecting to /192.168.21.71

Re: [ovirt-users] can't import vm from KVM host

2016-10-07 Thread Michal Skrivanek 

> On 7 Oct 2016, at 09:42, Nelson Lameiras  
> wrote:
> 
> hello,
> 
> any news on this issue ?

Hi, Shahar is out on vacation for few weeks

> can I do anything to help ?

hm...looking at the error, can you please confirm those paths 
('/dev/mapper/vg_00-lv_sys’, /dev/sdc) are mounted/correct on the source host?
Seems like the patch works and adds those disks all right, but further queries 
fails indicating those disks are not reachable.

Thanks,
michal

> 
> cordialement, regards, 
> Nelson LAMEIRAS 
> 
> Lyra Network 
> Service Projets et Processus 
> Tel : +33 (0) 5 32 09 09 70 
> 109 rue de l’innovation 
> 31670 Labège - France 
> www.lyra-network.com
> 
> - Original Message -
> From: "Shahar Havivi" 
> To: "Nelson Lameiras" 
> Cc: users@ovirt.org
> Sent: Thursday, September 29, 2016 2:31:42 PM
> Subject: Re: [ovirt-users] can't import vm from KVM host
> 
> On 29.09.16 14:22, Nelson Lameiras wrote:
>> Shahar,
>> 
>> I took the liberty to try to patch our test setup with the fix I took from 
>> https://gerrit.ovirt.org/#/c/64272/4/ (lib/vdsm/v2v.py)
>> I restarted vdsm afterwards
>> 
>> Result :
>> In the GUI import page, now when clicking on "load" button (just before 
>> guetting the list of vm to import on source), an error occurs : "Failed to 
>> communicate with the external provider, see log for additional details."
>> 
>> Error on engine log :
>> 
>> "
>> 2016-09-29 14:13:48,637 ERROR 
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand]
>>  (default task-30) [] Failed in 'GetVmsFromExternalProviderVDS' method, for 
>> vds: 'virtintelan01.lbg.office.lyra'; host: 'virtintelan01.lbg.office.lyra': 
>> null
>> 2016-09-29 14:13:48,637 ERROR 
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand]
>>  (default task-30) [] Command 'GetVmsFromExternalProviderVDSCommand(HostName 
>> = virtintelan01.lbg.office.lyra, 
>> GetVmsFromExternalProviderParameters:{runAsync='true', 
>> hostId='20b59a24-0098-461a-b4a3-7d6213b96c52', 
>> url='qemu+ssh://root@192.168.210.140/system', username='null', 
>> originType='KVM'})' execution failed: null
>> 2016-09-29 14:13:48,637 INFO  
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand]
>>  (default task-30) [] FINISH, GetVmsFromExternalProviderVDSCommand, log id: 
>> 6e062276
>> 2016-09-29 14:13:48,637 ERROR 
>> [org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery] (default 
>> task-30) [] Query 'GetVmsFromExternalProviderQuery' failed: EngineException: 
>> java.lang.NumberFormatException: null (Failed with error ENGINE and code 
>> 5001)
>> 2016-09-29 14:13:48,637 ERROR 
>> [org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery] (default 
>> task-30) [] Exception: org.ovirt.engine.core.common.errors.EngineException: 
>> EngineException: java.lang.NumberFormatException: null (Failed with error 
>> ENGINE and code 5001)
>>at 
>> org.ovirt.engine.core.bll.VdsHandler.handleVdsResult(VdsHandler.java:114) 
>> [bll.jar:]
>>at 
>> org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.runVdsCommand(VDSBrokerFrontendImpl.java:33)
>>  [bll.jar:]
>>at 
>> org.ovirt.engine.core.bll.QueriesCommandBase.runVdsCommand(QueriesCommandBase.java:257)
>>  [bll.jar:]
>>...
>> "
>> 
>> In the host, I can see the following errors on /var/log/messages : 
>> 
>> "
>> Sep 29 14:11:39 virtintelan01 journal: vdsm root ERROR Error getting disk 
>> size#012Traceback (most recent call last):#012  File 
>> "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 931, in 
>> _add_disk_info#012vol = conn.storageVolLookupByPath(disk['alias'])#012  
>> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4596, in 
>> storageVolLookupByPath#012if ret is None:raise 
>> libvirtError('virStorageVolLookupByPath() failed', 
>> conn=self)#012libvirtError: Volume de stockage introuvable : no storage vol 
>> with matching path '/dev/mapper/vg_00-lv_sys'
>> Sep 29 14:11:39 virtintelan01 journal: vdsm root ERROR Error getting disk 
>> size#012Traceback (most recent call last):#012  File 
>> "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 931, in 
>> _add_disk_info#012vol = conn.storageVolLookupByPath(disk['alias'])#012  
>> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4596, in 
>> storageVolLookupByPath#012if ret is None:raise 
>> libvirtError('virStorageVolLookupByPath() failed', 
>> conn=self)#012libvirtError: Volume de stockage introuvable : no storage vol 
>> with matching path '/dev/sdc'
>> "
>> 
>> FYI "Volume de stockage introuvable" (french) = "storage volume not found" 
>> 
>> This error did not appear before patching with the fix.
>> 
>> I repeated the operation 2 times with a clean setup + patch. Same behaviour. 
>> Maybe I'm doing something wrong?
> I need to check,
> Thanks for the info.
> 
>> 
>> my setup :
>> ovirt-engine : centos 7.2 + ovirt

Re: [ovirt-users] RE > Multiple export domains limit?

2016-10-07 Thread Yaniv Kaul 
On Fri, Oct 7, 2016 at 6:55 PM,  wrote:

> Hello oVirt guru`s!
>
> http://lists.ovirt.org/pipermail/users/2015-November/036056.html
>
> Is there a progress on this issue?
>

As far as I can see it is not an issue, but a feature request. Patches are
welcome, of course.

We are working on a download image API which might change the need for an
export domain, or the way it'll be used.
Y.

___
> 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] ovirt-ha-agent cpu usage

2016-10-07 Thread Sam Cappello 
it worked for me as well - load avg. < 1 now, ovirt-ha-agent pops up in 
top periodically, but not on top using 100% CPU all the time anymore.

thanks!
sam

Gianluca Cecchi wrote on 10/7/2016 10:13 AM:



On Fri, Oct 7, 2016 at 3:35 PM, Simone Tiraboschi > wrote:




On Fri, Oct 7, 2016 at 3:22 PM, Gianluca Cecchi
> wrote:

On Fri, Oct 7, 2016 at 2:59 PM, Nir Soffer > wrote:


wasn’t it suppose to be fixed to reuse the connection?
Like all the other clients (vdsm migration code:-)


This is orthogonal issue.

Does schema validation matter then if there would be
only one connection at the start up?


Loading once does not help command line tools like
vdsClient, hosted-engine and
vdsm-tool.

Nir




Simone, reusing the connection is good idea
anyway, but what you describe is
a bug in the client library. The library does
*not* need to load and parse the
schema at all for sending requests to vdsm.

The schema is only needed if you want to
verify request parameters,
or provide online help, these are not needed
in a client library.

Please file an infra bug about it.


Done,
https://bugzilla.redhat.com/show_bug.cgi?id=1381899



Here is a patch that should eliminate most most of
the problem:
https://gerrit.ovirt.org/65230

Would be nice if it can be tested on the system
showing this problem.

Cheers,
Nir
___




this is a video of 1 minute with the same system as the first
post, but in 4.0.3 now and the same 3 VMs powered on without
any particular load.
It seems very similar to the previous 3.6.6 in cpu used by
ovirt-ha-agent.


https://drive.google.com/file/d/0BwoPbcrMv8mvSjFDUERzV1owTG8/view?usp=sharing



Enjoy Nir ;-)

If I can apply the patch also to 4.0.3 I'm going to see if
there is then a different behavior.
Let me know,


I'm trying it right now.
Any other tests will be really appreciated.

The patch is pretty simply, you can apply that on the fly.
You have to shutdown ovirt-ha-broker and ovirt-ha-agent; then you
could directly edit
/usr/lib/python2.7/site-packages/api/vdsmapi.py
around line 97 changing from
loaded_schema = yaml.load(f)
to
loaded_schema = yaml.load(f, Loader=yaml.CLoader)
Please pay attention to keep exactly the same amount of initial
spaces.

Then you can simply restart the HA agent and check.

Gianluca

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





What I've done (I didn't read your answer in between and this is a 
test system not so important... )


set to global maintenance
patch vdsmapi.py
restart vdsmd
restart ovirt-ha-agent
set maintenance to none

And a bright new 3-minutes video here:
https://drive.google.com/file/d/0BwoPbcrMv8mvVzBPUVRQa1pwVnc/view?usp=sharing

It seems that now ovirt-ha-agent or is not present in top cpu process 
or at least has ranges between 5% and 12% and not more


BTW: I see this in vdsm status now

[root@ovirt01 api]# systemctl status vdsmd
● vdsmd.service - Virtual Desktop Server Manager
   Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled; 
vendor preset: enabled)

   Active: active (running) since Fri 2016-10-07 15:30:57 CEST; 32min ago
  Process: 20883 ExecStopPost=/usr/libexec/vdsm/vdsmd_init_common.sh 
--post-stop (code=exited, status=0/SUCCESS)
  Process: 20886 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh 
--pre-start (code=exited, status=0/SUCCESS)

 Main PID: 21023 (vdsm)
   CGroup: /system.slice/vdsmd.service
   ├─21023 /usr/bin/python /usr/share/vdsm/vdsm
   ├─21117 /usr/libexec/ioprocess --read-pipe-fd 41 
--write-pipe-fd 40 --max-threads 10 --max-queue...
   ├─21123 /usr/libexec/ioprocess --read-pipe-fd 48 
--write-pipe-fd 46 --max-threads 10 --max-queue...
   ├─21134 /usr/libexec/ioprocess --read-pipe-fd 57 
--write-pipe-fd 56 --max-threads 10

Re: [ovirt-users] vdsm ssl errors

2016-10-07 Thread Gianluca Cecchi 
On Mon, Jul 25, 2016 at 12:07 PM, Nir Soffer  wrote:

>
>
> This log is not very useful as is, we must show the relevant remote
> address.
>
> Should be improved in
> https://gerrit.ovirt.org/61303
>
> Can you try this patch and share the log?
>

Hello,
I take on this as I have the same problem.
I'm in 4.0.3 and it seems that the gerrit above was not inside.
So I applied and restarted vdsmd.

Now I have
Oct 07 19:54:10 ovirt01.lutwyn.org vdsm[11306]: vdsm vds.dispatcher ERROR
SSL error receiving from : unexpected eof

In my case single host environment with Self Hosted Engine
Ip of host is 192.168.1.211
Ip of engine is 192.168.1.212

Let me know if you need full logs and which ones.

in the mean time 1000 line around in vdsm.log here:
https://drive.google.com/file/d/0BwoPbcrMv8mvTk9SYTF0UDZUMUU/view?usp=sharing

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

Re: [ovirt-users] ovirt-ha-agent cpu usage

2016-10-07 Thread Simone Tiraboschi 
On Fri, Oct 7, 2016 at 4:02 PM, Michal Skrivanek <
michal.skriva...@redhat.com> wrote:

>
> On 7 Oct 2016, at 15:28, Simone Tiraboschi  wrote:
>
>
>
> On Fri, Oct 7, 2016 at 3:25 PM, Michal Skrivanek <
> michal.skriva...@redhat.com> wrote:
>
>>
>> On 7 Oct 2016, at 14:59, Nir Soffer  wrote:
>>
>> On Fri, Oct 7, 2016 at 3:52 PM, Michal Skrivanek <
>> michal.skriva...@redhat.com> wrote:
>>
>>>
>>> On 7 Oct 2016, at 14:42, Nir Soffer  wrote:
>>>
>>> On Wed, Oct 5, 2016 at 1:33 PM, Simone Tiraboschi 
>>> wrote:
>>>


 On Wed, Oct 5, 2016 at 10:34 AM, Nir Soffer  wrote:

> On Wed, Oct 5, 2016 at 10:24 AM, Simone Tiraboschi <
> stira...@redhat.com> wrote:
>
>>
>>
>> On Wed, Oct 5, 2016 at 9:17 AM, gregor 
>> wrote:
>>
>>> Hi,
>>>
>>> did you found a solution or cause for this high CPU usage?
>>> I have installed the self hosted engine on another server and there
>>> is
>>> no VM running but ovirt-ha-agent uses heavily the CPU.
>>>
>>
>> Yes, it's due to the fact that ovirt-ha-agent periodically reconnects
>> over json rpc and this is CPU intensive since the client has to parse the
>> yaml API specification each time it connects.
>>
>
>>> wasn’t it suppose to be fixed to reuse the connection? Like all the
>>> other clients (vdsm migration code:-)
>>>
>>
>> This is orthogonal issue.
>>
>>
>> Yes it is. And that’s the issue;-)
>> Both are wrong, but by “fixing” the schema validation only you lose the
>> motivation to fix the meaningless wasteful reconnect
>>
>
> Yes, we are going to fix that too ( https://bugzilla.redhat.com/
> show_bug.cgi?id=1349829 )
>
>
> that’s great! Also al the other vdsClient uses?:-)
>

https://gerrit.ovirt.org/#/c/62729/


> What is that periodic one call anyway? Is there only one? Maybe we don’t
> need it so much.
>

Currently ovirt-ha-agent is periodically reconnecting the hosted-engine
storage domain and checking its status. This is already on jsonrpc.
In 4.1 all the monitoring will be moved to jsonrpc.


>
> but it would require also https://bugzilla.redhat.com/
> show_bug.cgi?id=1376843 to be fixed.
>
>
> This is less good. Well, worst case you can reconnect yourself, all you
> need is a notification when the existing connection breaks
>
>
>
>>
>>
>>
>>> Does schema validation matter then if there would be only one connection
>>> at the start up?
>>>
>>
>> Loading once does not help command line tools like vdsClient,
>> hosted-engine and
>> vdsm-tool.
>>
>>
>> none of the other tools is using json-rpc.
>>
>
> hosted-engine-setup is, and sooner or later we'll have to migrate also the
> remaining tools since xmlrpc has been deprecated with 4.0
>
>
> ok. though setup is a one-time action so it’s not an issue there
>
>
>
>>
>>
>> Nir
>>
>>
>>>
>>>
> Simone, reusing the connection is good idea anyway, but what you
> describe is
> a bug in the client library. The library does *not* need to load and
> parse the
> schema at all for sending requests to vdsm.
>
> The schema is only needed if you want to verify request parameters,
> or provide online help, these are not needed in a client library.
>
> Please file an infra bug about it.
>

 Done, https://bugzilla.redhat.com/show_bug.cgi?id=1381899

>>>
>>> Here is a patch that should eliminate most most of the problem:
>>> https://gerrit.ovirt.org/65230
>>>
>>> Would be nice if it can be tested on the system showing this problem.
>>>
>>> Cheers,
>>> Nir
>>> ___
>>> 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
>>
>>
>>
>> ___
>> 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
>
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] RE > Multiple export domains limit?

2016-10-07 Thread aleksey . maksimov 
Hello oVirt guru`s!

http://lists.ovirt.org/pipermail/users/2015-November/036056.html

Is there a progress on this issue?
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] ovirt-ha-agent cpu usage

2016-10-07 Thread Nir Soffer 
>
> And a bright new 3-minutes video here:
> https://drive.google.com/file/d/0BwoPbcrMv8mvVzBPUVRQa1pwVnc/
> view?usp=sharing
>

> It seems that now ovirt-ha-agent or is not present in top cpu process or
> at least has ranges between 5% and 12% and not more
>

5-12% is probably 10 times more than needed for the agent, profiling
should tell us where time is spent.

Since the agent depends on vdsm, we can reuse vdsm cpu profiler, see
lib/vdsm/profiling/cpu.py. It is not ready yet to be used by other
applications,
but making it more general should be easy.

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

Re: [ovirt-users] ovirt-ha-agent cpu usage

2016-10-07 Thread Gianluca Cecchi 
On Fri, Oct 7, 2016 at 3:35 PM, Simone Tiraboschi 
wrote:

>
>
> On Fri, Oct 7, 2016 at 3:22 PM, Gianluca Cecchi  > wrote:
>
>> On Fri, Oct 7, 2016 at 2:59 PM, Nir Soffer  wrote:
>>
>>>
 wasn’t it suppose to be fixed to reuse the connection? Like all the
 other clients (vdsm migration code:-)

>>>
>>> This is orthogonal issue.
>>>
>>>
 Does schema validation matter then if there would be only one
 connection at the start up?

>>>
>>> Loading once does not help command line tools like vdsClient,
>>> hosted-engine and
>>> vdsm-tool.
>>>
>>> Nir
>>>
>>>


>> Simone, reusing the connection is good idea anyway, but what you
>> describe is
>> a bug in the client library. The library does *not* need to load and
>> parse the
>> schema at all for sending requests to vdsm.
>>
>> The schema is only needed if you want to verify request parameters,
>> or provide online help, these are not needed in a client library.
>>
>> Please file an infra bug about it.
>>
>
> Done, https://bugzilla.redhat.com/show_bug.cgi?id=1381899
>

 Here is a patch that should eliminate most most of the problem:
 https://gerrit.ovirt.org/65230

 Would be nice if it can be tested on the system showing this problem.

 Cheers,
 Nir
 ___


>>
>> this is a video of 1 minute with the same system as the first post, but
>> in 4.0.3 now and the same 3 VMs powered on without any particular load.
>> It seems very similar to the previous 3.6.6 in cpu used by ovirt-ha-agent.
>>
>> https://drive.google.com/file/d/0BwoPbcrMv8mvSjFDUERzV1owTG8
>> /view?usp=sharing
>>
>> Enjoy Nir ;-)
>>
>> If I can apply the patch also to 4.0.3 I'm going to see if there is then
>> a different behavior.
>> Let me know,
>>
>>
> I'm trying it right now.
> Any other tests will be really appreciated.
>
> The patch is pretty simply, you can apply that on the fly.
> You have to shutdown ovirt-ha-broker and ovirt-ha-agent; then you could
> directly edit
> /usr/lib/python2.7/site-packages/api/vdsmapi.py
> around line 97 changing from
> loaded_schema = yaml.load(f)
> to
> loaded_schema = yaml.load(f, Loader=yaml.CLoader)
> Please pay attention to keep exactly the same amount of initial spaces.
>
> Then you can simply restart the HA agent and check.
>
> Gianluca
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>

What I've done (I didn't read your answer in between and this is a test
system not so important... )

set to global maintenance
patch vdsmapi.py
restart vdsmd
restart ovirt-ha-agent
set maintenance to none

And a bright new 3-minutes video here:
https://drive.google.com/file/d/0BwoPbcrMv8mvVzBPUVRQa1pwVnc/view?usp=sharing

It seems that now ovirt-ha-agent or is not present in top cpu process or at
least has ranges between 5% and 12% and not more

BTW: I see this in vdsm status now

[root@ovirt01 api]# systemctl status vdsmd
● vdsmd.service - Virtual Desktop Server Manager
   Loaded: loaded (/usr/lib/systemd/system/vdsmd.service; enabled; vendor
preset: enabled)
   Active: active (running) since Fri 2016-10-07 15:30:57 CEST; 32min ago
  Process: 20883 ExecStopPost=/usr/libexec/vdsm/vdsmd_init_common.sh
--post-stop (code=exited, status=0/SUCCESS)
  Process: 20886 ExecStartPre=/usr/libexec/vdsm/vdsmd_init_common.sh
--pre-start (code=exited, status=0/SUCCESS)
 Main PID: 21023 (vdsm)
   CGroup: /system.slice/vdsmd.service
   ├─21023 /usr/bin/python /usr/share/vdsm/vdsm
   ├─21117 /usr/libexec/ioprocess --read-pipe-fd 41 --write-pipe-fd
40 --max-threads 10 --max-queue...
   ├─21123 /usr/libexec/ioprocess --read-pipe-fd 48 --write-pipe-fd
46 --max-threads 10 --max-queue...
   ├─21134 /usr/libexec/ioprocess --read-pipe-fd 57 --write-pipe-fd
56 --max-threads 10 --max-queue...
   ├─21143 /usr/libexec/ioprocess --read-pipe-fd 65 --write-pipe-fd
64 --max-threads 10 --max-queue...
   ├─21149 /usr/libexec/ioprocess --read-pipe-fd 73 --write-pipe-fd
72 --max-threads 10 --max-queue...
   ├─21156 /usr/libexec/ioprocess --read-pipe-fd 80 --write-pipe-fd
78 --max-threads 10 --max-queue...
   ├─21177 /usr/libexec/ioprocess --read-pipe-fd 88 --write-pipe-fd
87 --max-threads 10 --max-queue...
   ├─21204 /usr/libexec/ioprocess --read-pipe-fd 99 --write-pipe-fd
98 --max-threads 10 --max-queue...
   └─21239 /usr/libexec/ioprocess --read-pipe-fd 111
--write-pipe-fd 110 --max-threads 10 --max-que...

Oct 07 16:02:52 ovirt01.lutwyn.org vdsm[21023]: vdsm vds.dispatcher ERROR
SSL error during reading data... eof
Oct 07 16:02:54 ovirt01.lutwyn.org vdsm[21023]: vdsm vds.dispatcher ERROR
SSL error during reading data... eof
Oct 07 16:02:56 ovirt01.lutwyn.org vdsm[21023]: vdsm

Re: [ovirt-users] ovirt-ha-agent cpu usage

2016-10-07 Thread Michal Skrivanek 

> On 7 Oct 2016, at 15:28, Simone Tiraboschi  wrote:
> 
> 
> 
> On Fri, Oct 7, 2016 at 3:25 PM, Michal Skrivanek  > wrote:
> 
>> On 7 Oct 2016, at 14:59, Nir Soffer > > wrote:
>> 
>> On Fri, Oct 7, 2016 at 3:52 PM, Michal Skrivanek 
>> > wrote:
>> 
>>> On 7 Oct 2016, at 14:42, Nir Soffer >> > wrote:
>>> 
>>> On Wed, Oct 5, 2016 at 1:33 PM, Simone Tiraboschi >> > wrote:
>>> 
>>> 
>>> On Wed, Oct 5, 2016 at 10:34 AM, Nir Soffer >> > wrote:
>>> On Wed, Oct 5, 2016 at 10:24 AM, Simone Tiraboschi >> > wrote:
>>> 
>>> 
>>> On Wed, Oct 5, 2016 at 9:17 AM, gregor >> > wrote:
>>> Hi,
>>> 
>>> did you found a solution or cause for this high CPU usage?
>>> I have installed the self hosted engine on another server and there is
>>> no VM running but ovirt-ha-agent uses heavily the CPU.
>>> 
>>> Yes, it's due to the fact that ovirt-ha-agent periodically reconnects over 
>>> json rpc and this is CPU intensive since the client has to parse the yaml 
>>> API specification each time it connects.
>> 
>> wasn’t it suppose to be fixed to reuse the connection? Like all the other 
>> clients (vdsm migration code:-) 
>> 
>> This is orthogonal issue.
> 
> Yes it is. And that’s the issue;-)
> Both are wrong, but by “fixing” the schema validation only you lose the 
> motivation to fix the meaningless wasteful reconnect
> 
> Yes, we are going to fix that too ( 
> https://bugzilla.redhat.com/show_bug.cgi?id=1349829 
>  )

that’s great! Also al the other vdsClient uses?:-)
What is that periodic one call anyway? Is there only one? Maybe we don’t need 
it so much.

> but it would require also https://bugzilla.redhat.com/show_bug.cgi?id=1376843 
>  to be fixed.

This is less good. Well, worst case you can reconnect yourself, all you need is 
a notification when the existing connection breaks

>  
> 
>>  
>> Does schema validation matter then if there would be only one connection at 
>> the start up?
>> 
>> Loading once does not help command line tools like vdsClient, hosted-engine 
>> and
>> vdsm-tool. 
> 
> none of the other tools is using json-rpc.
> 
> hosted-engine-setup is, and sooner or later we'll have to migrate also the 
> remaining tools since xmlrpc has been deprecated with 4.0

ok. though setup is a one-time action so it’s not an issue there

>  
> 
>> 
>> Nir
>>  
>> 
>>> 
>>> Simone, reusing the connection is good idea anyway, but what you describe 
>>> is 
>>> a bug in the client library. The library does *not* need to load and parse 
>>> the
>>> schema at all for sending requests to vdsm.
>>> 
>>> The schema is only needed if you want to verify request parameters,
>>> or provide online help, these are not needed in a client library.
>>> 
>>> Please file an infra bug about it.
>>> 
>>> Done, https://bugzilla.redhat.com/show_bug.cgi?id=1381899 
>>> 
>>> 
>>> Here is a patch that should eliminate most most of the problem:
>>> https://gerrit.ovirt.org/65230 
>>> 
>>> Would be nice if it can be tested on the system showing this problem.
>>> 
>>> Cheers,
>>> Nir
>>> ___
>>> 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 
>> 
> 
> 
> ___
> 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

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

Re: [ovirt-users] ovirt-ha-agent cpu usage

2016-10-07 Thread Michal Skrivanek 


> On 07 Oct 2016, at 16:10, Simone Tiraboschi  wrote:
> 
> 
> 
>> On Fri, Oct 7, 2016 at 4:02 PM, Michal Skrivanek 
>>  wrote:
>> 
>>> On 7 Oct 2016, at 15:28, Simone Tiraboschi  wrote:
>>> 
>>> 
>>> 
>>> On Fri, Oct 7, 2016 at 3:25 PM, Michal Skrivanek 
>>>  wrote:
 
> On 7 Oct 2016, at 14:59, Nir Soffer  wrote:
> 
>> On Fri, Oct 7, 2016 at 3:52 PM, Michal Skrivanek 
>>  wrote:
>> 
>>> On 7 Oct 2016, at 14:42, Nir Soffer  wrote:
>>> 
 On Wed, Oct 5, 2016 at 1:33 PM, Simone Tiraboschi 
  wrote:
 
 
> On Wed, Oct 5, 2016 at 10:34 AM, Nir Soffer  
> wrote:
>> On Wed, Oct 5, 2016 at 10:24 AM, Simone Tiraboschi 
>>  wrote:
>> 
>> 
>>> On Wed, Oct 5, 2016 at 9:17 AM, gregor  
>>> wrote:
>>> Hi,
>>> 
>>> did you found a solution or cause for this high CPU usage?
>>> I have installed the self hosted engine on another server and there 
>>> is
>>> no VM running but ovirt-ha-agent uses heavily the CPU.
>> 
>> Yes, it's due to the fact that ovirt-ha-agent periodically 
>> reconnects over json rpc and this is CPU intensive since the client 
>> has to parse the yaml API specification each time it connects.
>> 
>> wasn’t it suppose to be fixed to reuse the connection? Like all the 
>> other clients (vdsm migration code:-) 
> 
> This is orthogonal issue.
 
 Yes it is. And that’s the issue;-)
 Both are wrong, but by “fixing” the schema validation only you lose the 
 motivation to fix the meaningless wasteful reconnect
>>> 
>>> Yes, we are going to fix that too ( 
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1349829 )
>> 
>> that’s great! Also al the other vdsClient uses?:-)
> 
> https://gerrit.ovirt.org/#/c/62729/

Cool. It's not so important for one time actions but we need it to be able to 
drop xmlrpc finally, so it is important:)

>  
>> What is that periodic one call anyway? Is there only one? Maybe we don’t 
>> need it so much.
> 
> Currently ovirt-ha-agent is periodically reconnecting the hosted-engine 
> storage domain and checking its status. This is already on jsonrpc.

Ok. As long as it is low frequency it's ok. Just bear in mind for future that 
some of the vdsm calls may be heavy and impact performance, regardless the 
communication layer. 

Thanks and have a nice weekend,
michal

> In 4.1 all the monitoring will be moved to jsonrpc.
>  
>> 
>>> but it would require also 
>>> https://bugzilla.redhat.com/show_bug.cgi?id=1376843 to be fixed.
>> 
>> This is less good. Well, worst case you can reconnect yourself, all you need 
>> is a notification when the existing connection breaks
>> 
>>>  
 
>  
>> Does schema validation matter then if there would be only one connection 
>> at the start up?
> 
> Loading once does not help command line tools like vdsClient, 
> hosted-engine and
> vdsm-tool. 
 
 none of the other tools is using json-rpc.
>>> 
>>> hosted-engine-setup is, and sooner or later we'll have to migrate also the 
>>> remaining tools since xmlrpc has been deprecated with 4.0
>> 
>> ok. though setup is a one-time action so it’s not an issue there
>> 
>>>  
 
> 
> Nir
>  
>> 
> 
> Simone, reusing the connection is good idea anyway, but what you 
> describe is 
> a bug in the client library. The library does *not* need to load and 
> parse the
> schema at all for sending requests to vdsm.
> 
> The schema is only needed if you want to verify request parameters,
> or provide online help, these are not needed in a client library.
> 
> Please file an infra bug about it.
 
 Done, https://bugzilla.redhat.com/show_bug.cgi?id=1381899
>>> 
>>> Here is a patch that should eliminate most most of the problem:
>>> https://gerrit.ovirt.org/65230
>>> 
>>> Would be nice if it can be tested on the system showing this problem.
>>> 
>>> Cheers,
>>> Nir
>>> ___
>>> 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
 
 
 ___
 Users mailing list
 Users@ovirt.org
 http://lists.ovirt.org/mailman/listinfo/users
>>> 
>>> ___
>>> Users mailing list
>>> Users@ovirt.org
>>>

[ovirt-users] Unexpected behaviour during creating VM using oVirt API

2016-10-07 Thread Roman Chukov 
Hello, 

I am trying to create a virtual machine from a template using oVirt
API. Somehow like this:

---
def createVM(connection, cluster, vmname, vmtemplate):
try:
 param = params.VM( name=vmname, \
 cluster=connection.clusters.get(name=cluster), \
 template=connection.templates.get(name=vmtemplate), \
 use_latest_template_version = True ) 
except: 
print "Could not construct a request to oVirtapi,please check 
parameters which were being sent to" 
return None

try:
connection.vms.add(param)
except:
print "I was not able to commit my request into oVirt api."
return None
return "OK"
---

Everything is fine when I have only ONE version of a template. But I am 
used to create several number of versions for one template because it
is quite flexible. In this case, when I run my script, I receive an
"AmbiguousQueryError" error even if an option
"use_latest_template_version = True" is used.

I revised
file  /usr/lib/python2.7/site-packages/ovirtsdk/utils/filterhelper.py
and found near line 30 that this error is raised unquestionably:

--
if len(result) > 1:
raise AmbiguousQueryError(query)
return result[0] if result else None
--

It seems quite strange. Either I do not understand the meaning of
option "use_latest_template_version" or using of this option does not
make sense, I mean query constructed in params.VM() function will not
be passed by filterhelper.py in current implementation.
I made a small patch that allows me to use the latest
version of the template during VM creation:

--
if len(result) > 1 :
result = result[len(result) - 1]
return result
#raise AmbiguousQueryError(query)
return result[0] if result else Nonepython-2.7.5-34.el7.x86_64
--
But I am still not sure that original behaviour of filehelper.py is
unexpectable. I would be very pleasant if you explain me this issue.

My OS is CentOS 7. I use Python python-2.7.5-34.el7.x86_64. Version of
ovirt-engine-sdk is ovirt-engine-sdk-python-3.6.8.0-1.el7.centos.noarch

--
Thanks in advance, Roman A. Chukov.
https://asgardahost.org
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] vdsm ssl errors

2016-10-07 Thread Piotr Kliczewski 
Gianluca,

Please share the engine log. We shoukd find more info about the issue there.

Thanks,
Piotr

7 paź 2016 20:09 "Gianluca Cecchi"  napisał(a):

>
> On Mon, Jul 25, 2016 at 12:07 PM, Nir Soffer  wrote:
>
>>
>>
>> This log is not very useful as is, we must show the relevant remote
>> address.
>>
>> Should be improved in
>> https://gerrit.ovirt.org/61303
>>
>> Can you try this patch and share the log?
>>
>
> Hello,
> I take on this as I have the same problem.
> I'm in 4.0.3 and it seems that the gerrit above was not inside.
> So I applied and restarted vdsmd.
>
> Now I have
> Oct 07 19:54:10 ovirt01.lutwyn.org vdsm[11306]: vdsm vds.dispatcher ERROR
> SSL error receiving from  192.168.1.211:36296 at 0x359c5f0>: unexpected eof
>
> In my case single host environment with Self Hosted Engine
> Ip of host is 192.168.1.211
> Ip of engine is 192.168.1.212
>
> Let me know if you need full logs and which ones.
>
> in the mean time 1000 line around in vdsm.log here:
> https://drive.google.com/file/d/0BwoPbcrMv8mvTk9SYTF0UDZUMUU/
> view?usp=sharing
>
> Thanks,
> Gianluca
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Can't add host - Failed to read hardware information

2016-10-07 Thread David Pinkerton 
I'm trying to add a host to a freshly built cluster.

yum install finishes, then the message " Failed to read hardware
information" is displayed - host has installation failed.
If I try to re-install I get the same message and the host goes
non-responsive.


engine log:

2016-10-07 21:13:46,525 INFO
 [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor)
[2854e702] Connecting to /192.168.21.71
2016-10-07 21:13:46,526 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand]
(DefaultQuartzScheduler4) [3fa97b73] Command
'GetCapabilitiesVDSCommand(HostName = rhv1,
VdsIdAndVdsVDSCommandParametersBase:{runAsync='true',
hostId='96358424-a14e-4d29-957f-3d7ddac99c12',
vds='Host[rhv1,96358424-a14e-4d29-957f-3d7ddac99c12]'})' execution failed:
org.ovirt.vdsm.jsonrpc.client.ClientConnectionException: Connection failed
2016-10-07 21:13:46,526 ERROR
[org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring]
(DefaultQuartzScheduler4) [3fa97b73] Failure to refresh Vds runtime info:
org.ovirt.vdsm.jsonrpc.client.ClientConnectionException: Connection failed
2016-10-07 21:13:46,526 ERROR
[org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring]
(DefaultQuartzScheduler4) [3fa97b73] Exception:
org.ovirt.engine.core.vdsbroker.vdsbroker.VDSNetworkException:
org.ovirt.vdsm.jsonrpc.client.ClientConnectionException: Connection failed
at
org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.createNetworkException(VdsBrokerCommand.java:157)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:120)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.VDSCommandBase.executeCommand(VDSCommandBase.java:73)
[vdsbroker.jar:]
at
org.ovirt.engine.core.dal.VdcCommandBase.execute(VdcCommandBase.java:33)
[dal.jar:]
at
org.ovirt.engine.core.vdsbroker.ResourceManager.runVdsCommand(ResourceManager.java:451)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.VdsManager.refreshCapabilities(VdsManager.java:653)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring.refreshVdsRunTimeInfo(HostMonitoring.java:121)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.monitoring.HostMonitoring.refresh(HostMonitoring.java:85)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.VdsManager.onTimer(VdsManager.java:238)
[vdsbroker.jar:]
at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source)
[:1.8.0_102]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[rt.jar:1.8.0_102]
at java.lang.reflect.Method.invoke(Method.java:498)
[rt.jar:1.8.0_102]
at
org.ovirt.engine.core.utils.timer.JobWrapper.invokeMethod(JobWrapper.java:77)
[scheduler.jar:]
at
org.ovirt.engine.core.utils.timer.JobWrapper.execute(JobWrapper.java:51)
[scheduler.jar:]
at org.quartz.core.JobRunShell.run(JobRunShell.java:213)
[quartz.jar:]
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
[rt.jar:1.8.0_102]
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
[rt.jar:1.8.0_102]
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
[rt.jar:1.8.0_102]
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
[rt.jar:1.8.0_102]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_102]
Caused by: org.ovirt.vdsm.jsonrpc.client.ClientConnectionException:
Connection failed
at
org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient.connect(ReactorClient.java:165)
[vdsm-jsonrpc-java-client.jar:]
at
org.ovirt.vdsm.jsonrpc.client.JsonRpcClient.getClient(JsonRpcClient.java:134)
[vdsm-jsonrpc-java-client.jar:]
at
org.ovirt.vdsm.jsonrpc.client.JsonRpcClient.call(JsonRpcClient.java:81)
[vdsm-jsonrpc-java-client.jar:]
at
org.ovirt.engine.core.vdsbroker.jsonrpc.FutureMap.(FutureMap.java:70)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.jsonrpc.JsonRpcVdsServer.getCapabilities(JsonRpcVdsServer.java:258)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.vdsbroker.GetCapabilitiesVDSCommand.executeVdsBrokerCommand(GetCapabilitiesVDSCommand.java:15)
[vdsbroker.jar:]
at
org.ovirt.engine.core.vdsbroker.vdsbroker.VdsBrokerCommand.executeVDSCommand(VdsBrokerCommand.java:110)
[vdsbroker.jar:]
... 18 more

2016-10-07 21:13:49,531 INFO
 [org.ovirt.vdsm.jsonrpc.client.reactors.ReactorClient] (SSL Stomp Reactor)
[2854e702] Connecting to /192.168.21.71





vdsm.log

jsonrpc.Executor/3::INFO::2016-10-07
20:45:31,554::__init__::513::jsonrpc.JsonRpcServer::(_serveRequest) RPC
call Host.getCapabilities succeeded in 0.06 seconds
jsonrpc.Executor/4::DEBUG::2016-10-07
20:45:32,566::__init__::530::jsonrpc.JsonRpcServer::(_handle_request)
Calling 'Host.getHardwareInfo' in bridge with {}
jsonrpc.Executor/4::ERROR::2016-10-07

Re: [ovirt-users] VM incremental backup

2016-10-07 Thread Arman Khalatyan 
The sparse files are special files(please checkout the wiki pages) to
conserve some diskspace and copy time.
The rsync --sparce does not take an advantage of it. It is trying to
checksum whole virtual diskspace which is obviously zero filled.
If you "cp" file then "cp" will try to autodetect it otherwise your file
willbe converted to regular file. You can also copy files with "tar -S ".
To check the size of actual vs virtual(sparse) you can use:
df -bsh filename vs  df -sh

Am 06.10.2016 11:34 vorm. schrieb "Nathanaël Blanchet" :

> Hi all,
>
> I didn't know this tool, after testing the original 40GB image size is
> reduced as expected to 2,9GB with du -sh, but transfer between servers
> continue to act as a 40GB image.
>
> So if I understand virt-sparsify reduces the effective space on the local
> disk, but the disk is seen with its original size by other systems, and
> there is no advantage in transferring the image from one server to an other.
>
> Please tell me if I'm wrong.
> Le 29/09/2016 à 15:10, Kai Wagner a écrit :
>
> Hey,
>
> I don't wont to break into your discussion, but I also never heard about
> virt-sparsfiy and the sparse option for dd.
>
> I tested it and it works like a charm. I converted a block device 65GB
> with dd sparse to 40GB raw image and afterwards I used virsh-sparsify to
> reduce the size down to 6.8GB into a qcow2 image file.
>
> Thanks a lot for that hint.
>
> Kai
> Am 27.09.2016 um 15:17 schrieb Sven Achtelik:
>
> No, I never came across this approach. I didn’t know about virt-sparsify.
>
>
>
> I’ll look into that and give it a try.
>
>
>
> Thank you
>
>
>
> it-novum GmbH
> i. A. Kai Wagner   ● Team Lead Support & Presales openATTIC
>  _
>   Unser Newsletter Service: Jetzt Business Open Source News abonnieren!
> 
> 
> Folgen Sie uns: 
>  
> 
> 
> 
> 
> 
>  Tel: +49 661 103-762
> Fax: +49 661 10317762
> Mail: kai.wag...@it-novum.com
> it-novum GmbH • Edelzeller Straße 44 • 36043 Fulda •
> http://www.it-novum.com/
> Handelsregister Amtsgericht Fulda, HRB 1934 • Geschäftsführer: Michael
> Kienle • Sitz der Gesellschaft: Fulda
>
> Der Inhalt dieser E-Mail ist vertraulich. Wenn Sie nicht der eigentliche
> Empfänger sein sollten, informieren Sie bitte sofort den Absender oder
> vernichten umgehend diese Mail. Jegliche unerlaubte Vervielfältigung oder
> Weiterleitung dieser Mail ist strengstens verboten.
> This e-mail may contain confidential and/or priviledged information. If
> you are not the intended recepient (or have received this e-mail in error)
> please notify the sender immediately and destroy this e-mail. Any
> unauthorised copying, disclosure or distribution of material in this e-mail
> is strictly forbidden.
>
> *Von:* Yaniv Dary [mailto:yd...@redhat.com ]
> *Gesendet:* Dienstag, 27. September 2016 15:10
> *An:* Sven Achtelik 
> 
> *Cc:* Maton, Brett  ;
> vasily.lamy...@megafon.ru; Ovirt Users  
> *Betreff:* Re: [ovirt-users] VM incremental backup
>
>
>
> As I see it you have two options:
> - In backup use 'dd' with 'conv=sparse' (or similar tool that
> allows sparse).
>
> - After backup use virt-sparsify [1] to reduce the size to the real used
> size prior to restore.
>
>
>
> To make this extra efficient you can use virt-sparsify anyways after
> backup to make the file even smaller.
>
> Have you considered this approach?
>
>
>
> [1] http://libguestfs.org/virt-sparsify.1.html
>
>
>
>
> Yaniv Dary
>
> Technical Product Manager
>
> Red Hat Israel Ltd.
>
> 34 Jerusalem Road
>
> Building A, 4th floor
>
> Ra'anana, Israel 4350109
>
>
>
> Tel : +972 (9) 7692306
>
> 8272306
>
> Email: yd...@redhat.com
>
> IRC : ydary
>
>
>
> On Tue, Sep 27, 2016 at 4:01 PM, Sven Achtelik 
> wrote:
>
> Hi Yaniv,
>
>
>
> how can this be done with DD ? Since it doesn’t know if the block is free
> space ? I’ve been looking for such a solution for a long time now.
> Everything I could find out was that I have to use a utility that
> understands the FS and therefore knows where the free space is.
>
>
>
> Thank you,
>
>
>
> Sven
>
> *Von:* users-boun...@ovirt.org [mailto:users-boun...@ovirt.org] *Im
> Auftrag von *Yaniv Dary
> *Gesendet:* Dienstag, 27. September 2016 14:38
> *An:* Maton, Brett 
> *Cc:* vasily.lamy...@megafon.ru; Ovirt

[ovirt-users] VM SSO

2016-10-07 Thread Maxence Sartiaux 
Hello,

I try to use the VM SSO but no login, still on the logon screen ...

I'm on ovirt 4.0.3, connected to an AD (Samba 4.5) + VMs Windows 7/10
stateless sysprep-ed to integrate to the domain and obviously the
guest-agent is installed.

My AD user can connect to the user panel, take a vm and connect to the
console but no sign on on the windows. (the "Connect Automatically"
option is ticked)

Also, i don't know why but my username on ovirt panel has a double
domain  "u...@labo.lan@labo.lan" <- is this my problem ?
The AD configuration is the configuration from the extension setup
wizard, no custom config, no mapping

Any ideas ? 

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

Re: [ovirt-users] change broker.conf configuration on shared storage

2016-10-07 Thread emanuel . santosvarina 
Simon, that works, thanks!  Whish list: edit the configuration from the 
web UI ;-)

--
Emanuel



Von:Simone Tiraboschi 
An: emanuel.santosvar...@mahle.com, 
Kopie:  users 
Datum:  06.10.2016 12:17
Betreff:Re: [ovirt-users] change broker.conf configuration on 
shared storage





On Wed, Oct 5, 2016 at 4:29 PM,  wrote:
hi all, 

hmm, broker.conf is now on the shared storage and not replicated on each 
host local file system. how to make changes to the conf, e.g.  the notify 
key? 

You can use something like what is documented here:
https://bugzilla.redhat.com/show_bug.cgi?id=1366879#c23

Instead of fixing fhanswers.conf as in that script, you have to fix 
broker.conf 

 

thanks, emanuel 


___
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] VM SSO

2016-10-07 Thread Ondra Machacek 

On 10/07/2016 09:09 AM, Maxence Sartiaux wrote:

Hello,

I try to use the VM SSO but no login, still on the logon screen ...

I'm on ovirt 4.0.3, connected to an AD (Samba 4.5) + VMs Windows 7/10
stateless sysprep-ed to integrate to the domain and obviously the
guest-agent is installed.

My AD user can connect to the user panel, take a vm and connect to the
console but no sign on on the windows. (the "Connect Automatically"
option is ticked)

Also, i don't know why but my username on ovirt panel has a double
domain  "u...@labo.lan @labo.lan" <- is this my problem ?


That is fine. One is for domain and second one is for UPN, so it's 
actually: UPN@domain.



The AD configuration is the configuration from the extension setup
wizard, no custom config, no mapping

Any ideas ?


Unfortunatelly, we have a regression bug:

 https://bugzilla.redhat.com/show_bug.cgi?id=1381606

There is no workaround I am aware of.



Thank you


___
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] VMs paused due to IO issues - Dell Equallogic controller failover

2016-10-07 Thread Gary Lloyd 
>From the sounds of it the best we can do then is to use a 60 second timeout
on paths in multipathd.
The main reason we use Direct Lun is because we replicate /snapshot VMs
associated Luns at SAN level as a means of disaster recovery.

I have read a bit of documentation of how to backup virtual machines in
storage domains, but the process of mounting snapshots for all our machines
within a dedicated VM doesn't seem as efficient when we have almost 300
virtual machines and only 1Gb networking.

Thanks for the advice.

*Gary Lloyd*

I.T. Systems:Keele University
Finance & IT Directorate
Keele:Staffs:IC1 Building:ST5 5NB:UK
+44 1782 733063 <%2B44%201782%20733073>


On 6 October 2016 at 11:07, Nir Soffer  wrote:

> On Thu, Oct 6, 2016 at 10:19 AM, Gary Lloyd  wrote:
>
>> I asked on the Dell Storage Forum and they recommend the following:
>>
>> *I recommend not using a numeric value for the "no_path_retry" variable
>> within /etc/multipath.conf as once that numeric value is reached, if no
>> healthy LUNs were discovered during that defined time multipath will
>> disable the I/O queue altogether.*
>>
>> *I do recommend, however, changing the variable value from "12" (or even
>> "60") to "queue" which will then allow multipathd to continue queing I/O
>> until a healthy LUN is discovered (time of fail-over between controllers)
>> and I/O is allowed to flow once again.*
>>
>> Can you see any issues with this recommendation as far as Ovirt is
>> concerned ?
>>
> Yes, we cannot work with unlimited queue. This will block vdsm for
> unlimited
> time when the next command try to access storage. Because we don't have
> good isolation between different storage domains, this may cause other
> storage
> domains to become faulty. Also engine flows that have a timeout will fail
> with
> a timeout.
>
> If you are on 3.x, this will be very painfull, on 4.0 it should be better,
> but it is not
> recommended.
>
> Nir
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] can't import vm from KVM host

2016-10-07 Thread Nelson Lameiras 
hello,

any news on this issue ?
can I do anything to help ?

cordialement, regards, 
Nelson LAMEIRAS 

Lyra Network 
Service Projets et Processus 
Tel : +33 (0) 5 32 09 09 70 
109 rue de l’innovation 
31670 Labège - France 
www.lyra-network.com

- Original Message -
From: "Shahar Havivi" 
To: "Nelson Lameiras" 
Cc: users@ovirt.org
Sent: Thursday, September 29, 2016 2:31:42 PM
Subject: Re: [ovirt-users] can't import vm from KVM host

On 29.09.16 14:22, Nelson Lameiras wrote:
> Shahar,
> 
> I took the liberty to try to patch our test setup with the fix I took from 
> https://gerrit.ovirt.org/#/c/64272/4/ (lib/vdsm/v2v.py)
> I restarted vdsm afterwards
> 
> Result :
> In the GUI import page, now when clicking on "load" button (just before 
> guetting the list of vm to import on source), an error occurs : "Failed to 
> communicate with the external provider, see log for additional details."
> 
> Error on engine log :
> 
> "
> 2016-09-29 14:13:48,637 ERROR 
> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand]
>  (default task-30) [] Failed in 'GetVmsFromExternalProviderVDS' method, for 
> vds: 'virtintelan01.lbg.office.lyra'; host: 'virtintelan01.lbg.office.lyra': 
> null
> 2016-09-29 14:13:48,637 ERROR 
> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand]
>  (default task-30) [] Command 'GetVmsFromExternalProviderVDSCommand(HostName 
> = virtintelan01.lbg.office.lyra, 
> GetVmsFromExternalProviderParameters:{runAsync='true', 
> hostId='20b59a24-0098-461a-b4a3-7d6213b96c52', 
> url='qemu+ssh://root@192.168.210.140/system', username='null', 
> originType='KVM'})' execution failed: null
> 2016-09-29 14:13:48,637 INFO  
> [org.ovirt.engine.core.vdsbroker.vdsbroker.GetVmsFromExternalProviderVDSCommand]
>  (default task-30) [] FINISH, GetVmsFromExternalProviderVDSCommand, log id: 
> 6e062276
> 2016-09-29 14:13:48,637 ERROR 
> [org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery] (default task-30) 
> [] Query 'GetVmsFromExternalProviderQuery' failed: EngineException: 
> java.lang.NumberFormatException: null (Failed with error ENGINE and code 5001)
> 2016-09-29 14:13:48,637 ERROR 
> [org.ovirt.engine.core.bll.GetVmsFromExternalProviderQuery] (default task-30) 
> [] Exception: org.ovirt.engine.core.common.errors.EngineException: 
> EngineException: java.lang.NumberFormatException: null (Failed with error 
> ENGINE and code 5001)
> at 
> org.ovirt.engine.core.bll.VdsHandler.handleVdsResult(VdsHandler.java:114) 
> [bll.jar:]
> at 
> org.ovirt.engine.core.bll.VDSBrokerFrontendImpl.runVdsCommand(VDSBrokerFrontendImpl.java:33)
>  [bll.jar:]
> at 
> org.ovirt.engine.core.bll.QueriesCommandBase.runVdsCommand(QueriesCommandBase.java:257)
>  [bll.jar:]
> ...
> "
> 
> In the host, I can see the following errors on /var/log/messages : 
> 
> "
> Sep 29 14:11:39 virtintelan01 journal: vdsm root ERROR Error getting disk 
> size#012Traceback (most recent call last):#012  File 
> "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 931, in 
> _add_disk_info#012vol = conn.storageVolLookupByPath(disk['alias'])#012  
> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4596, in 
> storageVolLookupByPath#012if ret is None:raise 
> libvirtError('virStorageVolLookupByPath() failed', 
> conn=self)#012libvirtError: Volume de stockage introuvable : no storage vol 
> with matching path '/dev/mapper/vg_00-lv_sys'
> Sep 29 14:11:39 virtintelan01 journal: vdsm root ERROR Error getting disk 
> size#012Traceback (most recent call last):#012  File 
> "/usr/lib/python2.7/site-packages/vdsm/v2v.py", line 931, in 
> _add_disk_info#012vol = conn.storageVolLookupByPath(disk['alias'])#012  
> File "/usr/lib64/python2.7/site-packages/libvirt.py", line 4596, in 
> storageVolLookupByPath#012if ret is None:raise 
> libvirtError('virStorageVolLookupByPath() failed', 
> conn=self)#012libvirtError: Volume de stockage introuvable : no storage vol 
> with matching path '/dev/sdc'
> "
> 
> FYI "Volume de stockage introuvable" (french) = "storage volume not found" 
> 
> This error did not appear before patching with the fix.
> 
> I repeated the operation 2 times with a clean setup + patch. Same behaviour. 
> Maybe I'm doing something wrong?
I need to check,
Thanks for the info.

> 
> my setup :
> ovirt-engine : centos 7.2 + ovirt 4.0.4
> hosts : centos 7.2 + ovirt 4.0.4 + fix
> 
> cordialement, regards, 
> Nelson LAMEIRAS 
> 
> Lyra Network 
> Service Projets et Processus 
> Tel : +33 (0) 5 32 09 09 70 
> 109 rue de l’innovation 
> 31670 Labège - France 
> www.lyra-network.com
> 
> - Original Message -
> From: "Nelson Lameiras" 
> To: "Shahar Havivi" 
> Cc: users@ovirt.org
> Sent: Friday, September 23, 2016 11:55:08 AM
> Subject: Re: [ovirt-users] can't import vm from KVM host
> 
> Shahar,
> 
> Thanks!
> I'll keep an eye on

Re: [ovirt-users] VDSM Network Interface configuration

2016-10-07 Thread Marcin Mirecki 
Brett,

Does your /etc/resolv.conf contain the correct dns's?
If not, please update them.

If you need to override the changes done to the ifcfg files, you can use the 
hooks
to introduce your own custom changes. You can find an article describing this in
more details here:
https://www.ovirt.org/blog/2016/05/modify-ifcfg-files/

Marcin

- Original Message -
> From: "Brett Maton" 
> To: "Ovirt Users" 
> Sent: Thursday, October 6, 2016 6:03:23 PM
> Subject: [ovirt-users] VDSM Network Interface configuration
> 
> 
> Where is the configuration that VDSM uses to generate ifcfg files?
> 
> My nameservers have moved and it seems to regenerate the ifcfg (ovirtmgmt)
> file overwriting the changes with the correct name servers in when the
> server is rebooted and s putting in the wrong (old) nameserver addresses.
> 
> Where can I fix this ?
> 
> Thanks
> 
> ___
> 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] change broker.conf configuration on shared storage

2016-10-07 Thread Simone Tiraboschi 
On Fri, Oct 7, 2016 at 10:52 AM,  wrote:

> Simon, that works, thanks!  Whish list: edit the configuration from the
> web UI ;-)
>
>
I think we already have an open RFE for that, not sure about its priority.


> --
> Emanuel
>
>
>
> Von:Simone Tiraboschi 
> An:emanuel.santosvar...@mahle.com,
> Kopie:users 
> Datum:06.10.2016 12:17
> Betreff:Re: [ovirt-users] change broker.conf configuration on
> shared storage
> --
>
>
>
>
>
> On Wed, Oct 5, 2016 at 4:29 PM, <*emanuel.santosvar...@mahle.com*
> > wrote:
> hi all,
>
> hmm, broker.conf is now on the shared storage and not replicated on each
> host local file system. how to make changes to the conf, e.g.  the notify
> key?
>
> You can use something like what is documented here:
> *https://bugzilla.redhat.com/show_bug.cgi?id=1366879#c23*
> 
>
> Instead of fixing fhanswers.conf as in that script, you have to fix
> broker.conf
>
>
>
> thanks, emanuel
>
>
> ___
> 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] ovirt-ha-agent cpu usage

2016-10-07 Thread Michal Skrivanek 

> On 7 Oct 2016, at 14:42, Nir Soffer  wrote:
> 
> On Wed, Oct 5, 2016 at 1:33 PM, Simone Tiraboschi  > wrote:
> 
> 
> On Wed, Oct 5, 2016 at 10:34 AM, Nir Soffer  > wrote:
> On Wed, Oct 5, 2016 at 10:24 AM, Simone Tiraboschi  > wrote:
> 
> 
> On Wed, Oct 5, 2016 at 9:17 AM, gregor  > wrote:
> Hi,
> 
> did you found a solution or cause for this high CPU usage?
> I have installed the self hosted engine on another server and there is
> no VM running but ovirt-ha-agent uses heavily the CPU.
> 
> Yes, it's due to the fact that ovirt-ha-agent periodically reconnects over 
> json rpc and this is CPU intensive since the client has to parse the yaml API 
> specification each time it connects.

wasn’t it suppose to be fixed to reuse the connection? Like all the other 
clients (vdsm migration code:-) 
Does schema validation matter then if there would be only one connection at the 
start up?

> 
> Simone, reusing the connection is good idea anyway, but what you describe is 
> a bug in the client library. The library does *not* need to load and parse the
> schema at all for sending requests to vdsm.
> 
> The schema is only needed if you want to verify request parameters,
> or provide online help, these are not needed in a client library.
> 
> Please file an infra bug about it.
> 
> Done, https://bugzilla.redhat.com/show_bug.cgi?id=1381899 
> 
> 
> Here is a patch that should eliminate most most of the problem:
> https://gerrit.ovirt.org/65230 
> 
> Would be nice if it can be tested on the system showing this problem.
> 
> Cheers,
> Nir
> ___
> 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] ovirt-ha-agent cpu usage

2016-10-07 Thread Nir Soffer 
On Wed, Oct 5, 2016 at 1:33 PM, Simone Tiraboschi 
wrote:

>
>
> On Wed, Oct 5, 2016 at 10:34 AM, Nir Soffer  wrote:
>
>> On Wed, Oct 5, 2016 at 10:24 AM, Simone Tiraboschi 
>> wrote:
>>
>>>
>>>
>>> On Wed, Oct 5, 2016 at 9:17 AM, gregor  wrote:
>>>
 Hi,

 did you found a solution or cause for this high CPU usage?
 I have installed the self hosted engine on another server and there is
 no VM running but ovirt-ha-agent uses heavily the CPU.

>>>
>>> Yes, it's due to the fact that ovirt-ha-agent periodically reconnects
>>> over json rpc and this is CPU intensive since the client has to parse the
>>> yaml API specification each time it connects.
>>>
>>
>> Simone, reusing the connection is good idea anyway, but what you describe
>> is
>> a bug in the client library. The library does *not* need to load and
>> parse the
>> schema at all for sending requests to vdsm.
>>
>> The schema is only needed if you want to verify request parameters,
>> or provide online help, these are not needed in a client library.
>>
>> Please file an infra bug about it.
>>
>
> Done, https://bugzilla.redhat.com/show_bug.cgi?id=1381899
>

Here is a patch that should eliminate most most of the problem:
https://gerrit.ovirt.org/65230

Would be nice if it can be tested on the system showing this problem.

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

Re: [ovirt-users] ovirt-ha-agent cpu usage

2016-10-07 Thread Nir Soffer 
On Fri, Oct 7, 2016 at 3:52 PM, Michal Skrivanek <
michal.skriva...@redhat.com> wrote:

>
> On 7 Oct 2016, at 14:42, Nir Soffer  wrote:
>
> On Wed, Oct 5, 2016 at 1:33 PM, Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Wed, Oct 5, 2016 at 10:34 AM, Nir Soffer  wrote:
>>
>>> On Wed, Oct 5, 2016 at 10:24 AM, Simone Tiraboschi 
>>> wrote:
>>>


 On Wed, Oct 5, 2016 at 9:17 AM, gregor  wrote:

> Hi,
>
> did you found a solution or cause for this high CPU usage?
> I have installed the self hosted engine on another server and there is
> no VM running but ovirt-ha-agent uses heavily the CPU.
>

 Yes, it's due to the fact that ovirt-ha-agent periodically reconnects
 over json rpc and this is CPU intensive since the client has to parse the
 yaml API specification each time it connects.

>>>
> wasn’t it suppose to be fixed to reuse the connection? Like all the other
> clients (vdsm migration code:-)
>

This is orthogonal issue.


> Does schema validation matter then if there would be only one connection
> at the start up?
>

Loading once does not help command line tools like vdsClient, hosted-engine
and
vdsm-tool.

Nir


>
>
>>> Simone, reusing the connection is good idea anyway, but what you
>>> describe is
>>> a bug in the client library. The library does *not* need to load and
>>> parse the
>>> schema at all for sending requests to vdsm.
>>>
>>> The schema is only needed if you want to verify request parameters,
>>> or provide online help, these are not needed in a client library.
>>>
>>> Please file an infra bug about it.
>>>
>>
>> Done, https://bugzilla.redhat.com/show_bug.cgi?id=1381899
>>
>
> Here is a patch that should eliminate most most of the problem:
> https://gerrit.ovirt.org/65230
>
> Would be nice if it can be tested on the system showing this problem.
>
> Cheers,
> Nir
> ___
> 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] vdsm ssl errors

2016-10-07 Thread Gianluca Cecchi 
On Fri, Oct 7, 2016 at 10:14 PM, Piotr Kliczewski 
wrote:

> Gianluca,
>
> Please share the engine log. We shoukd find more info about the issue
> there.
>
> Thanks,
> Piotr
>
>
here it is
https://drive.google.com/file/d/0BwoPbcrMv8mvQlVwVDlGTVEtR00/view?usp=sharing

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

Re: [ovirt-users] change broker.conf configuration on shared storage

2016-10-07 Thread Gianluca Cecchi 
On Fri, Oct 7, 2016 at 11:04 AM, Simone Tiraboschi 
wrote:

>
>
> On Fri, Oct 7, 2016 at 10:52 AM,  wrote:
>
>> Simon, that works, thanks!  Whish list: edit the configuration from the
>> web UI ;-)
>>
>>
> I think we already have an open RFE for that, not sure about its priority.
>
>
>> --
>
>

I think there is this one, that was related to SMTP server settings change:
https://bugzilla.redhat.com/show_bug.cgi?id=1301681

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

Re: [ovirt-users] change broker.conf configuration on shared storage

2016-10-07 Thread Simone Tiraboschi 
On Fri, Oct 7, 2016 at 11:12 AM, Gianluca Cecchi 
wrote:

>
> On Fri, Oct 7, 2016 at 11:04 AM, Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Fri, Oct 7, 2016 at 10:52 AM,  wrote:
>>
>>> Simon, that works, thanks!  Whish list: edit the configuration from the
>>> web UI ;-)
>>>
>>>
>> I think we already have an open RFE for that, not sure about its priority.
>>
>>
>>> --
>>
>>
>
> I think there is this one, that was related to SMTP server settings change:
> https://bugzilla.redhat.com/show_bug.cgi?id=1301681
>

Yes, exactly. Thanks Gianluca.
I added the small replace script also there as a reference.


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