date:20180307

Thanks Juan for your response. Appreciate it.
But for some reason still, I am facing the same SSL handshake failed (5).
Could you please check this configuration and let me know the issue in my
ovirt engine environment.

*Configuration of Apache server:*

1) httpd version,

# httpd -v
Server version: Apache/2.4.6 (CentOS)
Server built:   Oct 19 2017 20:39:16

2) I checked the status using the following command,

# systemctl status httpd -l
● httpd.service - The Apache HTTP Server
   Loaded: loaded (/usr/lib/systemd/system/httpd.service; enabled; vendor
preset: disabled)
   Active: active (running) since Wed 2018-03-07 23:46:32 IST; 1min 55s ago
 Docs: man:httpd(8)
   man:apachectl(8)
  Process: 4351 ExecStop=/bin/kill -WINCH ${MAINPID} (code=exited,
status=0/SUCCESS)
 Main PID: 4359 (httpd)
   Status: "Total requests: 264; Current requests/sec: 0.1; Current
traffic: 204 B/sec"
   CGroup: /system.slice/httpd.service
   ├─4359 /usr/sbin/httpd -DFOREGROUND
   ├─4360 /usr/sbin/httpd -DFOREGROUND
   ├─4362 /usr/sbin/httpd -DFOREGROUND
   ├─5100 /usr/sbin/httpd -DFOREGROUND
   ├─5386 /usr/sbin/httpd -DFOREGROUND
   ├─5415 /usr/sbin/httpd -DFOREGROUND
   └─5416 /usr/sbin/httpd -DFOREGROUND

3) Since the httpd is pointing to the path :
/usr/lib/systemd/system/httpd.service

vi /usr/lib/systemd/system/httpd.service

[Unit]
Description=The Apache HTTP Server
After=network.target remote-fs.target nss-lookup.target
Documentation=man:httpd(8)
Documentation=man:apachectl(8)

[Service]
Type=notify
EnvironmentFile=/etc/sysconfig/httpd
ExecStart=/usr/sbin/httpd $OPTIONS -DFOREGROUND
ExecReload=/usr/sbin/httpd $OPTIONS -k graceful
ExecStop=/bin/kill -WINCH ${MAINPID}
# We want systemd to give httpd some time to finish gracefully, but still
want
# it to kill httpd after TimeoutStopSec if something went wrong during the
# graceful stop. Normally, Systemd sends SIGTERM signal right after the
# ExecStop, which would kill httpd. We are sending useless SIGCONT here to
give
# httpd time to finish.
KillSignal=SIGCONT
PrivateTmp=true

[Install]
WantedBy=multi-user.target

4) As per the above command I found the env file is available
'/etc/sysconfig/httpd'

vi /etc/sysconfig/httpd

#
# This file can be used to set additional environment variables for
# the httpd process, or pass additional options to the httpd
# executable.
#
# Note: With previous versions of httpd, the MPM could be changed by
# editing an "HTTPD" variable here.  With the current version, that
# variable is now ignored.  The MPM is a loadable module, and the
# choice of MPM can be changed by editing the configuration file
/etc/httpd/conf.modules.d/00-mpm.conf
#

#
# To pass additional options (for instance, -D definitions) to the
# httpd binary at startup, set OPTIONS here.
#
#OPTIONS=

#
# This setting ensures the httpd process is started in the "C" locale
# by default.  (Some modules will not behave correctly if
# case-sensitive string comparisons are performed in a different
# locale.)
#
LANG=C

5) As per the above command, I found that the conf fileis available in the
path : /etc/httpd/conf.modules.d/00-mpm.conf

vi /etc/httpd/conf.modules.d/00-mpm.conf

# Select the MPM module which should be used by uncommenting exactly
# one of the following LoadModule lines:

# prefork MPM: Implements a non-threaded, pre-forking web server
# See: http://httpd.apache.org/docs/2.4/mod/prefork.html
#LoadModule mpm_prefork_module modules/mod_mpm_prefork.so

# worker MPM: Multi-Processing Module implementing a hybrid
# multi-threaded multi-process web server
# See: http://httpd.apache.org/docs/2.4/mod/worker.html
#
LoadModule mpm_worker_module modules/mod_mpm_worker.so

# event MPM: A variant of the worker MPM with the goal of consuming
# threads only for connections with active processing
# See: http://httpd.apache.org/docs/2.4/mod/event.html
#
#LoadModule mpm_event_module modules/mod_mpm_event.so

   ServerLimit 1000
   MaxRequestWorkers 1000

As per your comment, I enabled the 'LoadModule mpm_worker_module
modules/mod_mpm_worker.so' with the ServerLimit and MaxRequestWorkers as
1000 still I am facing the issue for the following command in apache
benchmark test.

Completed 100 requests
SSL handshake failed (5).
SSL handshake failed (5).
SSL handshake failed (5).
SSL handshake failed (5).
SSL handshake failed (5).
SSL handshake failed (5).

NOTE : It always scales when I have concurrent request below 400

What is wrong in this apache configuration, why SSL handshake is failing
for concurrent request above 400 ?

Thanks,
Hari

On Wed, Mar 7, 2018 at 9:20 PM, Juan Hernández  wrote:

> It means that with the default configuration the Apache web server can't
> serve more than 256 concurrent connections. This applies to any application
> that uses Apache as the web frontend, not just to oVirt. If you want to
> change that you have to change the MaxRequestWorkers and ServerLimit
>

Re: [ovirt-users] Tunable parameters in ovirt engine

2018-03-07 Thread Moran Goldboim

Hi Hari,

any specific use-case you are trying to achieve with this benchmark?
what are you trying to simulate? just wondering whether there are different
options to achieve it..

Thanks.

On Wed, Mar 7, 2018 at 5:50 PM, Juan Hernández  wrote:

> It means that with the default configuration the Apache web server can't
> serve more than 256 concurrent connections. This applies to any application
> that uses Apache as the web frontend, not just to oVirt. If you want to
> change that you have to change the MaxRequestWorkers and ServerLimit
> parameters, as explained here:
>
>   https://httpd.apache.org/docs/2.4/mod/mpm_common.html#maxrequestworkers
>
> So, go to your oVirt engine machine and create a /etc/httpd/conf.d/my.conf
> file with this content:
>
>   MaxRequestWorkers 1000
>   ServerLimit 1000
>
> Then restart the Apache server:
>
>   # systemctl restart httpd
>
> Then your web server should be able to handle 1000 concurrent requests,
> and you will probably start to find other limits, like the amount of memory
> and CPU that those 1000 Apache child processes will consume, the number of
> threads in the JBoss application server, the number of connections to the
> database, etc.
>
> Let me insist a bit that if you base your benchmark solely on the number
> of concurrent requests or connections that the server can handle you may
> end up with meaningless results, as a real world application can/should use
> the server much better than that.
>
> On 03/07/2018 04:33 PM, Hari Prasanth Loganathan wrote:
>
>> With the default configuration of the web server it is impossible to
>> handle
>> more than 256 *connections* simultaneously. I guess that "ab" is opening a
>> connection for each concurrent request, so when you reach request 257 the
>> web server will just reject the connection, there is nothing that the
>> JBoss
>> can do about it; you have to increase the number of connections supported
>> by the web server.
>>
>> *So Does it mean that oVirt cannot serve more than 257 request? *
>>
>> My question is, If its possible How to scale this and what is the
>> configuration we need to change?
>>
>> Also, we are taking a benchmark in using oVirt, So I need to find the
>> maximum possible oVirt request. So please let me know the configuration
>> tuning for oVirt to achieve maximum concurrent request.
>>
>> Thanks,
>> Hari
>>
>> On Wed, Mar 7, 2018 at 7:25 PM, Juan Hernández 
>> wrote:
>>
>> With the default configuration of the web server it is impossible to
>>> handle more than 256 *connections* simultaneously. I guess that "ab" is
>>> opening a connection for each concurrent request, so when you reach
>>> request
>>> 257 the web server will just reject the connection, there is nothing that
>>> the JBoss can do about it; you have to increase the number of connections
>>> supported by the web server.
>>>
>>> Or else you may want to re-consider why you want to use 1000 simultaneous
>>> connections. It may be OK for a performance test, but there are better
>>> ways
>>> to squeeze performance. For example, you could consider using HTTP
>>> pipelining, which is much more friendly for the server than so many
>>> connections. This is what we use when we need to send a large number of
>>> requests from other systems. There are examples of how to do that with
>>> the
>>> Python and Ruby SDKs here:
>>>
>>>Python:
>>>
>>> https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/
>>> examples/asynchronous_inventory.py
>>>
>>>Ruby:
>>>
>>> https://github.com/oVirt/ovirt-engine-sdk-ruby/blob/master/
>>> sdk/examples/asynchronous_inventory.rb
>>>
>>>
>>> On 03/07/2018 02:43 PM, Hari Prasanth Loganathan wrote:
>>>
>>> Hi Juan,

 Thanks for the response.

 I agree web server can handle only limited number of concurrent
 requests.
 But Why it is failing with SSL handshake failure for few requests, Can't
 the JBOSS wait and serve the request? We can spare the delay but not
 with
 the request fails. So Is there a configuration in oVirt which can be
 tuned
 to achieve this?

 Thanks,
 Hari

 On Wed, Mar 7, 2018 at 7:05 PM, Juan Hernández 
 wrote:

 The first thing you will need to change for such a test is the number of

> simultaneous connections accepted by the Apache web server: by default
> the
> max is 256. See the Apache documentation here:
>
> https://httpd.apache.org/docs/2.4/mod/mpm_common.html#m
> axrequestworkers
>
> In addition I also suggest that you consider using the "worker"
> multi-processing module instead of the "prefork", as it usually works
> better when talking to a Java application server, because it re-uses
> connections better.
>
> On 03/07/2018 02:20 PM, Hari Prasanth Loganathan wrote:
>
> Hi Team,
>
>>
>> *Description of problem:*
>>
>> I am trying to achieve 1000

[ovirt-users] Gluster Snapshot Schedule Failing on 4.2.1

2018-03-07 Thread Hesham Ahmed

I am having issues with the Gluster Snapshot UI since upgrade to 4.2 and
now with 4.2.1. The UI doesn't appear as I explained in the bug report:
https://bugzilla.redhat.com/show_bug.cgi?id=1530186

I can now see the UI when I clear the cookies and try the snapshots UI from
within the volume details screen, however scheduled snapshots are not being
created. The engine log shows a single error:

2018-03-07 20:00:00,051+03 ERROR
[org.ovirt.engine.core.utils.timer.JobWrapper] (QuartzOvirtDBScheduler1)
[12237b15] Failed to invoke scheduled method onTimer: null

Anyone scheduling snapshots successfully wtih 4.2?
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Unable to start VM after upgrade vom 4.1.9 to 4.2.1 - NPE

2018-03-07 Thread Oliver Riesener


On 07.03.2018 17:22, Arik Hadas wrote:



On Wed, Mar 7, 2018 at 6:15 PM, Jan Siml > wrote:


Hello,

Enable network and disks on your VM than do:
Run -> ONCE Ok Ignore errors. Ok
Run
Cheeers


WTF! That worked.

Did you know, why this works and what happens in the
background? Is there a Bugzilla bug ID for this issue?

I figured it out, by they attempt to change the VM CPU family from old 
VM's, as a last try to get it work again.
After i had a live upgrade to 4.2 with running VM's and shutdown them 
down they all dead with disabled network and disks.

No delight to delete them all and recreate them, the other way.

Have a nice day.


BTW, here is the list of devices before:

engine=# select type, device, address, is_managed, is_plugged,
alias from vm_device where vm_id in (select vm_guid from vm_static
where vm_name='prod-hub-201');
    type    |    device     |  address                    |
is_managed | is_plugged |    alias

+---+--+++
 video      | qxl           |                    | t       | t   
      |
 controller | virtio-scsi   |                    | t       | t   
      |
 balloon    | memballoon    |                    | t       | f   
      | balloon0
 graphics   | spice         |                    | t       | t   
      |
 controller | virtio-serial | {slot=0x06, bus=0x00, domain=0x,
type=pci, function=0x0} | t          | t       | virtio-serial0
 disk       | disk          | {slot=0x07, bus=0x00, domain=0x,
type=pci, function=0x0} | f          | t       | virtio-disk0
 memballoon | memballoon    | {slot=0x08, bus=0x00, domain=0x,
type=pci, function=0x0} | f          | t       | balloon0
 interface  | bridge        | {slot=0x03, bus=0x00, domain=0x,
type=pci, function=0x0} | f          | t       | net0
 interface  | bridge        | {slot=0x09, bus=0x00, domain=0x,
type=pci, function=0x0} | f          | t       | net1
 controller | scsi          | {slot=0x05, bus=0x00, domain=0x,
type=pci, function=0x0} | f          | t       | scsi0
 controller | ide           | {slot=0x01, bus=0x00, domain=0x,
type=pci, function=0x1} | f          | t         | ide
 controller | usb           | {slot=0x01, bus=0x00, domain=0x,
type=pci, function=0x2} | t          | t         | usb
 channel    | unix          | {bus=0, controller=0,
type=virtio-serial, port=1}            | f          | t         |
channel0
 channel    | unix          | {bus=0, controller=0,
type=virtio-serial, port=2}            | f          | t         |
channel1
 channel    | spicevmc      | {bus=0, controller=0,
type=virtio-serial, port=3}            | f          | t         |
channel2
 interface  | bridge        |                    | t       | t   
      | net1
 interface  | bridge        |                    | t       | t   
      | net0
 disk       | cdrom         |                    | t       | f   
      | ide0-1-0
 disk       | cdrom         | {bus=1, controller=0, type=drive,
target=0, unit=0}          | f          | t         | ide0-1-0
 disk       | disk          |                    | t       | t   
      | virtio-disk0
(20 rows)

and afterwards:

engine=# select type, device, address, is_managed, is_plugged,
alias from vm_device where vm_id in (select vm_guid from vm_static
where vm_name='prod-hub-201');
    type    |    device     |  address                    |
is_managed | is_plugged |    alias

+---+--+++
 channel    | spicevmc      | {type=virtio-serial, bus=0,
controller=0, port=3}            | f          | t | channel2
 channel    | unix          | {type=virtio-serial, bus=0,
controller=0, port=1}            | f          | t | channel0
 interface  | bridge        | {type=pci, slot=0x04, bus=0x00,
domain=0x, function=0x0} | t          | t       | net1
 controller | usb           | {type=pci, slot=0x01, bus=0x00,
domain=0x, function=0x2} | t          | t       | usb
 controller | virtio-serial | {type=pci, slot=0x06, bus=0x00,
domain=0x, function=0x0} | t          | t       | virtio-serial0
 interface  | bridge        | {type=pci, slot=0x03, bus=0x00,
domain=0x, function=0x0} | t          | t       | net0
 controller | virtio-scsi   | {type=pci, slot=0x05, bus=0x00,
domain=0x, function=0x0} | t          | t       | scsi0
 video      | qxl           | {type=pci, slot=0x02, bus=0x00,
domain=0x, function=0x0} |

Re: [ovirt-users] Unable to start VM after upgrade vom 4.1.9 to 4.2.1 - NPE

On Wed, Mar 7, 2018 at 6:15 PM, Jan Siml  wrote:

> Hello,
>
> Enable network and disks on your VM than do:
>>> Run -> ONCE Ok Ignore errors. Ok
>>> Run
>>> Cheeers
>>>
>>
>> WTF! That worked.
>>
>> Did you know, why this works and what happens in the background? Is there
>> a Bugzilla bug ID for this issue?
>>
>
> BTW, here is the list of devices before:
>
> engine=# select type, device, address, is_managed, is_plugged, alias from
> vm_device where vm_id in (select vm_guid from vm_static where
> vm_name='prod-hub-201');
> type|device |   address
> | is_managed | is_plugged | alias
> +---+---
> ---+++
>  video  | qxl   || t  | t
> |
>  controller | virtio-scsi   || t  | t
> |
>  balloon| memballoon|| t  | f
> | balloon0
>  graphics   | spice || t  | t
> |
>  controller | virtio-serial | {slot=0x06, bus=0x00, domain=0x,
> type=pci, function=0x0} | t  | t  | virtio-serial0
>  disk   | disk  | {slot=0x07, bus=0x00, domain=0x,
> type=pci, function=0x0} | f  | t  | virtio-disk0
>  memballoon | memballoon| {slot=0x08, bus=0x00, domain=0x,
> type=pci, function=0x0} | f  | t  | balloon0
>  interface  | bridge| {slot=0x03, bus=0x00, domain=0x,
> type=pci, function=0x0} | f  | t  | net0
>  interface  | bridge| {slot=0x09, bus=0x00, domain=0x,
> type=pci, function=0x0} | f  | t  | net1
>  controller | scsi  | {slot=0x05, bus=0x00, domain=0x,
> type=pci, function=0x0} | f  | t  | scsi0
>  controller | ide   | {slot=0x01, bus=0x00, domain=0x,
> type=pci, function=0x1} | f  | t  | ide
>  controller | usb   | {slot=0x01, bus=0x00, domain=0x,
> type=pci, function=0x2} | t  | t  | usb
>  channel| unix  | {bus=0, controller=0, type=virtio-serial,
> port=1}| f  | t  | channel0
>  channel| unix  | {bus=0, controller=0, type=virtio-serial,
> port=2}| f  | t  | channel1
>  channel| spicevmc  | {bus=0, controller=0, type=virtio-serial,
> port=3}| f  | t  | channel2
>  interface  | bridge|| t  | t
> | net1
>  interface  | bridge|| t  | t
> | net0
>  disk   | cdrom || t  | f
> | ide0-1-0
>  disk   | cdrom | {bus=1, controller=0, type=drive, target=0,
> unit=0}  | f  | t  | ide0-1-0
>  disk   | disk  || t  | t
> | virtio-disk0
> (20 rows)
>
> and afterwards:
>
> engine=# select type, device, address, is_managed, is_plugged, alias from
> vm_device where vm_id in (select vm_guid from vm_static where
> vm_name='prod-hub-201');
> type|device |   address
> | is_managed | is_plugged | alias
> +---+---
> ---+++
>  channel| spicevmc  | {type=virtio-serial, bus=0, controller=0,
> port=3}| f  | t  | channel2
>  channel| unix  | {type=virtio-serial, bus=0, controller=0,
> port=1}| f  | t  | channel0
>  interface  | bridge| {type=pci, slot=0x04, bus=0x00,
> domain=0x, function=0x0} | t  | t  | net1
>  controller | usb   | {type=pci, slot=0x01, bus=0x00,
> domain=0x, function=0x2} | t  | t  | usb
>  controller | virtio-serial | {type=pci, slot=0x06, bus=0x00,
> domain=0x, function=0x0} | t  | t  | virtio-serial0
>  interface  | bridge| {type=pci, slot=0x03, bus=0x00,
> domain=0x, function=0x0} | t  | t  | net0
>  controller | virtio-scsi   | {type=pci, slot=0x05, bus=0x00,
> domain=0x, function=0x0} | t  | t  | scsi0
>  video  | qxl   | {type=pci, slot=0x02, bus=0x00,
> domain=0x, function=0x0} | t  | t  | video0
>  channel| unix  | {type=virtio-serial, bus=0, controller=0,
> port=2}| f  | t  | channel1
>  balloon| memballoon|| t  | t
> | balloon0
>  graphics   | spice || t  | t
> |
>  disk   | cdrom || t  | f
> | ide0-1-0
>  disk   | disk  | {type=pci, slot=0x07, bus=0x00,
> domain=0x, function=0x0} | t  | t  | virtio-disk0
> (13

Re: [ovirt-users] Unable to start VM after upgrade vom 4.1.9 to 4.2.1 - NPE


Hello,


Enable network and disks on your VM than do:
Run -> ONCE Ok Ignore errors. Ok
Run
Cheeers


WTF! That worked.

Did you know, why this works and what happens in the background? Is 
there a Bugzilla bug ID for this issue?


BTW, here is the list of devices before:

engine=# select type, device, address, is_managed, is_plugged, alias 
from vm_device where vm_id in (select vm_guid from vm_static where 
vm_name='prod-hub-201');
type|device |   address 
   | is_managed | is_plugged | alias

+---+--+++
 video  | qxl   | 
   | t  | t  |
 controller | virtio-scsi   | 
   | t  | t  |
 balloon| memballoon| 
   | t  | f  | balloon0
 graphics   | spice | 
   | t  | t  |
 controller | virtio-serial | {slot=0x06, bus=0x00, domain=0x, 
type=pci, function=0x0} | t  | t  | virtio-serial0
 disk   | disk  | {slot=0x07, bus=0x00, domain=0x, 
type=pci, function=0x0} | f  | t  | virtio-disk0
 memballoon | memballoon| {slot=0x08, bus=0x00, domain=0x, 
type=pci, function=0x0} | f  | t  | balloon0
 interface  | bridge| {slot=0x03, bus=0x00, domain=0x, 
type=pci, function=0x0} | f  | t  | net0
 interface  | bridge| {slot=0x09, bus=0x00, domain=0x, 
type=pci, function=0x0} | f  | t  | net1
 controller | scsi  | {slot=0x05, bus=0x00, domain=0x, 
type=pci, function=0x0} | f  | t  | scsi0
 controller | ide   | {slot=0x01, bus=0x00, domain=0x, 
type=pci, function=0x1} | f  | t  | ide
 controller | usb   | {slot=0x01, bus=0x00, domain=0x, 
type=pci, function=0x2} | t  | t  | usb
 channel| unix  | {bus=0, controller=0, type=virtio-serial, 
port=1}| f  | t  | channel0
 channel| unix  | {bus=0, controller=0, type=virtio-serial, 
port=2}| f  | t  | channel1
 channel| spicevmc  | {bus=0, controller=0, type=virtio-serial, 
port=3}| f  | t  | channel2
 interface  | bridge| 
   | t  | t  | net1
 interface  | bridge| 
   | t  | t  | net0
 disk   | cdrom | 
   | t  | f  | ide0-1-0
 disk   | cdrom | {bus=1, controller=0, type=drive, 
target=0, unit=0}  | f  | t  | ide0-1-0
 disk   | disk  | 
   | t  | t  | virtio-disk0

(20 rows)

and afterwards:

engine=# select type, device, address, is_managed, is_plugged, alias 
from vm_device where vm_id in (select vm_guid from vm_static where 
vm_name='prod-hub-201');
type|device |   address 
   | is_managed | is_plugged | alias

+---+--+++
 channel| spicevmc  | {type=virtio-serial, bus=0, controller=0, 
port=3}| f  | t  | channel2
 channel| unix  | {type=virtio-serial, bus=0, controller=0, 
port=1}| f  | t  | channel0
 interface  | bridge| {type=pci, slot=0x04, bus=0x00, 
domain=0x, function=0x0} | t  | t  | net1
 controller | usb   | {type=pci, slot=0x01, bus=0x00, 
domain=0x, function=0x2} | t  | t  | usb
 controller | virtio-serial | {type=pci, slot=0x06, bus=0x00, 
domain=0x, function=0x0} | t  | t  | virtio-serial0
 interface  | bridge| {type=pci, slot=0x03, bus=0x00, 
domain=0x, function=0x0} | t  | t  | net0
 controller | virtio-scsi   | {type=pci, slot=0x05, bus=0x00, 
domain=0x, function=0x0} | t  | t  | scsi0
 video  | qxl   | {type=pci, slot=0x02, bus=0x00, 
domain=0x, function=0x0} | t  | t  | video0
 channel| unix  | {type=virtio-serial, bus=0, controller=0, 
port=2}| f  | t  | channel1
 balloon| memballoon| 
   | t  | t  | balloon0
 graphics   | spice | 
   | t  | t  |
 disk   | cdrom | 
   | t  | f  | ide0-1-0
 disk   | disk  | {type=pci, slot=0x07, bus=0x00, 
domain=0x, function=0x0} | t  | t  | virtio-disk0

(13 rows)

Regards

Jan
___
Users mailing list
Users@ovirt.org

Re: [ovirt-users] Unable to start VM after upgrade vom 4.1.9 to 4.2.1 - NPE

2018-03-07 Thread Oliver Riesener

Hi,

Enable network and disks on your VM than do:
Run -> ONCE Ok Ignore errors. Ok
Run 
Cheeers
Olri


> Am 07.03.2018 um 16:49 schrieb Arik Hadas :
> 
> 
> 
>> On Wed, Mar 7, 2018 at 5:32 PM, Jan Siml  wrote:
>> Hello Arik,
>> 
>> 
>>> we have upgrade one of our oVirt engines to 4.2.1 (from 4.1.9)
>>> and afterwards all nodes too. The cluster compatibility level
>>> has been set to 4.2.
>>> 
>>> Now we can't start a VM after it has been powered off. The only
>>> hint we found in engine.log is:
>>> 
>>> 2018-03-07 14:51:52,504+01 INFO
>>> [org.ovirt.engine.core.vdsbroker.UpdateVmDynamicDataVDSCommand]
>>> (EE-ManagedThreadFactory-engine-Thread-25)
>>> [f855b54a-56d9-4708-8a67-5609438ddadb] START,
>>> UpdateVmDynamicDataVDSCommand(
>>> UpdateVmDynamicDataVDSCommandParameters:{hostId='null',
>>> vmId='a7bc4124-06cb-4909-9389-bcf727df1304',
>>> vmDynamic='org.ovirt.engine.co
>>> 
>>> re.common.businessentities.VmDynamic@491983e9'}),
>>> 
>>> log id: 7d49849e
>>> 2018-03-07 14:51:52,509+01 INFO
>>> [org.ovirt.engine.core.vdsbroker.UpdateVmDynamicDataVDSCommand]
>>> (EE-ManagedThreadFactory-engine-Thread-25)
>>> [f855b54a-56d9-4708-8a67-5609438ddadb] FINISH,
>>> UpdateVmDynamicDataVDSCommand, log id: 7d49849e
>>> 2018-03-07 14:51:52,531+01 INFO
>>> [org.ovirt.engine.core.vdsbroker.CreateVDSCommand]
>>> (EE-ManagedThreadFactory-engine-Thread-25)
>>> [f855b54a-56d9-4708-8a67-5609438ddadb] START, CreateVDSCommand(
>>> 
>>> CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-4f7abd1f402b',
>>> vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM
>>> [prod-hub-201]'}), log id: 4af1f227
>>> 2018-03-07 14:51:52,533+01 INFO
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand]
>>> (EE-ManagedThreadFactory-engine-Thread-25)
>>> [f855b54a-56d9-4708-8a67-5609438ddadb] START,
>>> CreateBrokerVDSCommand(HostName = prod-node-210,
>>> 
>>> CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-4f7abd1f402b',
>>> vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM
>>> [prod-hub-201]'}), log id: 71dcc8e7
>>> 2018-03-07 14:51:52,545+01 ERROR
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand]
>>> (EE-ManagedThreadFactory-engine-Thread-25)
>>> [f855b54a-56d9-4708-8a67-5609438ddadb] Failed in
>>> 'CreateBrokerVDS' method, for vds: 'prod-node-210'; host:
>>> 'prod-node-210': null
>>> 2018-03-07 14:51:52,546+01 ERROR
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand]
>>> (EE-ManagedThreadFactory-engine-Thread-25)
>>> [f855b54a-56d9-4708-8a67-5609438ddadb] Command
>>> 'CreateBrokerVDSCommand(HostName = prod-node-210,
>>> 
>>> CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-4f7abd1f402b',
>>> vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM
>>> [prod-hub-201]'})' execution failed: null
>>> 2018-03-07 14:51:52,546+01 INFO
>>> [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand]
>>> (EE-ManagedThreadFactory-engine-Thread-25)
>>> [f855b54a-56d9-4708-8a67-5609438ddadb] FINISH,
>>> CreateBrokerVDSCommand, log id: 71dcc8e7
>>> 2018-03-07 14:51:52,546+01 ERROR
>>> [org.ovirt.engine.core.vdsbroker.CreateVDSCommand]
>>> (EE-ManagedThreadFactory-engine-Thread-25) [f855b5
>>> 4a-56d9-4708-8a67-5609438ddadb] Failed to create VM:
>>> java.lang.NullPointerException
>>> at
>>> 
>>> org.ovirt.engine.core.vdsbroker.builder.vminfo.LibvirtVmXmlBuilder.lambda$writeInterfaces$23(LibvirtVmXmlBuilder.java:1066)
>>>   [vdsbroker.jar:]
>>> 
>>> [...]
>>> 
>>> But this doesn't lead us to the root cause. I haven't found any
>>> matching bug tickets in release notes for upcoming 4.2.1. Can
>>> anyone help here?
>>> 
>>> 
>>> What's the mac address of that VM?
>>> You can find it in the UI or with:
>>> 
>>> select mac_addr from vm_interface where vm_guid in (select vm_guid
>>> from vm_static where vm_name='');
>>> 
>>> 
>>> Actually, different question - does this VM has unplugged network interface?
>> 
>> The VM has two NICs. Both are plugged.
>> 
>> The MAC addresses are 00:1a:4a:18:01:52 for nic1 and 00:1a:4a:36:01:67 for 
>> nic2.
> 
> OK, those seem like two valid mac addresses so maybe something is wrong with 
> the vm devices.
> Could you please provide the output of:
> select type, device, address, is_managed, is_plugged, alias from vm_device 
> where vm_id in (select vm_guid from vm_static where vm_name='');
>  
>> 
>> Regards
>> 
>> Jan
> 
>

Re: [ovirt-users] Unable to start VM after upgrade vom 4.1.9 to 4.2.1 - NPE


Hello Arik,


         we have upgrade one of our oVirt engines to 4.2.1 (from
4.1.9)
         and afterwards all nodes too. The cluster compatibility
level
         has been set to 4.2.

         Now we can't start a VM after it has been powered off.
The only
         hint we found in engine.log is:

         2018-03-07 14:51:52,504+01 INFO

[org.ovirt.engine.core.vdsbroker.UpdateVmDynamicDataVDSCommand]

         (EE-ManagedThreadFactory-engine-Thread-25)
         [f855b54a-56d9-4708-8a67-5609438ddadb] START,
         UpdateVmDynamicDataVDSCommand(
         UpdateVmDynamicDataVDSCommandParameters:{hostId='null',
         vmId='a7bc4124-06cb-4909-9389-bcf727df1304',
         vmDynamic='org.ovirt.engine.co 

re.common.businessentities.VmDynamic@491983e9'}),


         log id: 7d49849e
         2018-03-07 14:51:52,509+01 INFO

[org.ovirt.engine.core.vdsbroker.UpdateVmDynamicDataVDSCommand]

         (EE-ManagedThreadFactory-engine-Thread-25)
         [f855b54a-56d9-4708-8a67-5609438ddadb] FINISH,
         UpdateVmDynamicDataVDSCommand, log id: 7d49849e
         2018-03-07 14:51:52,531+01 INFO
         [org.ovirt.engine.core.vdsbroker.CreateVDSCommand]
         (EE-ManagedThreadFactory-engine-Thread-25)
         [f855b54a-56d9-4708-8a67-5609438ddadb] START,
CreateVDSCommand(

CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-4f7abd1f402b',

         vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM
         [prod-hub-201]'}), log id: 4af1f227
         2018-03-07 14:51:52,533+01 INFO

[org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand]

         (EE-ManagedThreadFactory-engine-Thread-25)
         [f855b54a-56d9-4708-8a67-5609438ddadb] START,
         CreateBrokerVDSCommand(HostName = prod-node-210,

CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-4f7abd1f402b',

         vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM
         [prod-hub-201]'}), log id: 71dcc8e7
         2018-03-07 14:51:52,545+01 ERROR

[org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand]

         (EE-ManagedThreadFactory-engine-Thread-25)
         [f855b54a-56d9-4708-8a67-5609438ddadb] Failed in
         'CreateBrokerVDS' method, for vds: 'prod-node-210'; host:
         'prod-node-210': null
         2018-03-07 14:51:52,546+01 ERROR

[org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand]

         (EE-ManagedThreadFactory-engine-Thread-25)
         [f855b54a-56d9-4708-8a67-5609438ddadb] Command
         'CreateBrokerVDSCommand(HostName = prod-node-210,

CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-4f7abd1f402b',

         vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM
         [prod-hub-201]'})' execution failed: null
         2018-03-07 14:51:52,546+01 INFO

[org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand]

         (EE-ManagedThreadFactory-engine-Thread-25)
         [f855b54a-56d9-4708-8a67-5609438ddadb] FINISH,
         CreateBrokerVDSCommand, log id: 71dcc8e7
         2018-03-07 14:51:52,546+01 ERROR
         [org.ovirt.engine.core.vdsbroker.CreateVDSCommand]
         (EE-ManagedThreadFactory-engine-Thread-25) [f855b5
         4a-56d9-4708-8a67-5609438ddadb] Failed to create VM:
         java.lang.NullPointerException
         at

org.ovirt.engine.core.vdsbroker.builder.vminfo.LibvirtVmXmlBuilder.lambda$writeInterfaces$23(LibvirtVmXmlBuilder.java:1066)

           [vdsbroker.jar:]

         [...]

         But this doesn't lead us to the root cause. I haven't
found any
         matching bug tickets in release notes for upcoming
4.2.1. Can
         anyone help here?


     What's the mac address of that VM?
     You can find it in the UI or with:

     select mac_addr from vm_interface where vm_guid in (select
vm_guid
     from vm_static where vm_name='');


Actually, different question - does this VM has unplugged
network interface?


The VM has two NICs. Both are plugged.

The MAC addresses are 00:1a:4a:18:01:52 for nic1 and
00:1a:4a:36:01:67 for nic2.


OK, those seem like two valid mac addresses so maybe something is wrong 
with the vm devices.

Could you please

Re: [ovirt-users] Tunable parameters in ovirt engine

2018-03-07 Thread Juan Hernández

It means that with the default configuration the Apache web server can't 
serve more than 256 concurrent connections. This applies to any 
application that uses Apache as the web frontend, not just to oVirt. If 
you want to change that you have to change the MaxRequestWorkers and 
ServerLimit parameters, as explained here:


  https://httpd.apache.org/docs/2.4/mod/mpm_common.html#maxrequestworkers

So, go to your oVirt engine machine and create a 
/etc/httpd/conf.d/my.conf file with this content:


  MaxRequestWorkers 1000
  ServerLimit 1000

Then restart the Apache server:

  # systemctl restart httpd

Then your web server should be able to handle 1000 concurrent requests, 
and you will probably start to find other limits, like the amount of 
memory and CPU that those 1000 Apache child processes will consume, the 
number of threads in the JBoss application server, the number of 
connections to the database, etc.


Let me insist a bit that if you base your benchmark solely on the number 
of concurrent requests or connections that the server can handle you may 
end up with meaningless results, as a real world application can/should 
use the server much better than that.


On 03/07/2018 04:33 PM, Hari Prasanth Loganathan wrote:

With the default configuration of the web server it is impossible to handle
more than 256 *connections* simultaneously. I guess that "ab" is opening a
connection for each concurrent request, so when you reach request 257 the
web server will just reject the connection, there is nothing that the JBoss
can do about it; you have to increase the number of connections supported
by the web server.

*So Does it mean that oVirt cannot serve more than 257 request? *
My question is, If its possible How to scale this and what is the
configuration we need to change?

Also, we are taking a benchmark in using oVirt, So I need to find the
maximum possible oVirt request. So please let me know the configuration
tuning for oVirt to achieve maximum concurrent request.

Thanks,
Hari

On Wed, Mar 7, 2018 at 7:25 PM, Juan Hernández  wrote:


With the default configuration of the web server it is impossible to
handle more than 256 *connections* simultaneously. I guess that "ab" is
opening a connection for each concurrent request, so when you reach request
257 the web server will just reject the connection, there is nothing that
the JBoss can do about it; you have to increase the number of connections
supported by the web server.

Or else you may want to re-consider why you want to use 1000 simultaneous
connections. It may be OK for a performance test, but there are better ways
to squeeze performance. For example, you could consider using HTTP
pipelining, which is much more friendly for the server than so many
connections. This is what we use when we need to send a large number of
requests from other systems. There are examples of how to do that with the
Python and Ruby SDKs here:

   Python:

https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/
examples/asynchronous_inventory.py

   Ruby:

https://github.com/oVirt/ovirt-engine-sdk-ruby/blob/master/
sdk/examples/asynchronous_inventory.rb


On 03/07/2018 02:43 PM, Hari Prasanth Loganathan wrote:


Hi Juan,

Thanks for the response.

I agree web server can handle only limited number of concurrent requests.
But Why it is failing with SSL handshake failure for few requests, Can't
the JBOSS wait and serve the request? We can spare the delay but not with
the request fails. So Is there a configuration in oVirt which can be tuned
to achieve this?

Thanks,
Hari

On Wed, Mar 7, 2018 at 7:05 PM, Juan Hernández 
wrote:

The first thing you will need to change for such a test is the number of

simultaneous connections accepted by the Apache web server: by default
the
max is 256. See the Apache documentation here:

https://httpd.apache.org/docs/2.4/mod/mpm_common.html#m
axrequestworkers

In addition I also suggest that you consider using the "worker"
multi-processing module instead of the "prefork", as it usually works
better when talking to a Java application server, because it re-uses
connections better.

On 03/07/2018 02:20 PM, Hari Prasanth Loganathan wrote:

Hi Team,


*Description of problem:*

I am trying to achieve 1000 concurrent request to oVirt. What are the
tunable parameters to achieve this?

I tried to perform the benchmarking for ovirt engine using Apache
benchmark
using the same SSO token.

ab -n 1000 -c 500 -k -H "accept: application/json" -H "Authorization:
Bearer SSOTOKEN" https://172.30.56.70/ovirt-engine/


When the number of concurrent request is 500, we are getting more than
100
failures with the following error,

SSL read failed (1) - closing connection
139620982339352:error:

NOTE: It is scaling for concurrent request below 500.

I used the profiler to get the memory and CPU and it seems very less,

Re: [ovirt-users] Unable to start VM after upgrade vom 4.1.9 to 4.2.1 - NPE

On Wed, Mar 7, 2018 at 5:32 PM, Jan Siml  wrote:

> Hello Arik,
>
>
> we have upgrade one of our oVirt engines to 4.2.1 (from 4.1.9)
>> and afterwards all nodes too. The cluster compatibility level
>> has been set to 4.2.
>>
>> Now we can't start a VM after it has been powered off. The only
>> hint we found in engine.log is:
>>
>> 2018-03-07 14:51:52,504+01 INFO
>> [org.ovirt.engine.core.vdsbroker.UpdateVmDynamicDataVDSCommand]
>> (EE-ManagedThreadFactory-engine-Thread-25)
>> [f855b54a-56d9-4708-8a67-5609438ddadb] START,
>> UpdateVmDynamicDataVDSCommand(
>> UpdateVmDynamicDataVDSCommandParameters:{hostId='null',
>> vmId='a7bc4124-06cb-4909-9389-bcf727df1304',
>> vmDynamic='org.ovirt.engine.co
>> re.common.businessentities.VmDyn
>> amic@491983e9'}),
>>
>> log id: 7d49849e
>> 2018-03-07 14:51:52,509+01 INFO
>> [org.ovirt.engine.core.vdsbroker.UpdateVmDynamicDataVDSCommand]
>> (EE-ManagedThreadFactory-engine-Thread-25)
>> [f855b54a-56d9-4708-8a67-5609438ddadb] FINISH,
>> UpdateVmDynamicDataVDSCommand, log id: 7d49849e
>> 2018-03-07 14:51:52,531+01 INFO
>> [org.ovirt.engine.core.vdsbroker.CreateVDSCommand]
>> (EE-ManagedThreadFactory-engine-Thread-25)
>> [f855b54a-56d9-4708-8a67-5609438ddadb] START, CreateVDSCommand(
>> CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-
>> 4f7abd1f402b',
>> vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM
>> [prod-hub-201]'}), log id: 4af1f227
>> 2018-03-07 14:51:52,533+01 INFO
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCo
>> mmand]
>> (EE-ManagedThreadFactory-engine-Thread-25)
>> [f855b54a-56d9-4708-8a67-5609438ddadb] START,
>> CreateBrokerVDSCommand(HostName = prod-node-210,
>> CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-
>> 4f7abd1f402b',
>> vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM
>> [prod-hub-201]'}), log id: 71dcc8e7
>> 2018-03-07 14:51:52,545+01 ERROR
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCo
>> mmand]
>> (EE-ManagedThreadFactory-engine-Thread-25)
>> [f855b54a-56d9-4708-8a67-5609438ddadb] Failed in
>> 'CreateBrokerVDS' method, for vds: 'prod-node-210'; host:
>> 'prod-node-210': null
>> 2018-03-07 14:51:52,546+01 ERROR
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCo
>> mmand]
>> (EE-ManagedThreadFactory-engine-Thread-25)
>> [f855b54a-56d9-4708-8a67-5609438ddadb] Command
>> 'CreateBrokerVDSCommand(HostName = prod-node-210,
>> CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-
>> 4f7abd1f402b',
>> vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM
>> [prod-hub-201]'})' execution failed: null
>> 2018-03-07 14:51:52,546+01 INFO
>> [org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCo
>> mmand]
>> (EE-ManagedThreadFactory-engine-Thread-25)
>> [f855b54a-56d9-4708-8a67-5609438ddadb] FINISH,
>> CreateBrokerVDSCommand, log id: 71dcc8e7
>> 2018-03-07 14:51:52,546+01 ERROR
>> [org.ovirt.engine.core.vdsbroker.CreateVDSCommand]
>> (EE-ManagedThreadFactory-engine-Thread-25) [f855b5
>> 4a-56d9-4708-8a67-5609438ddadb] Failed to create VM:
>> java.lang.NullPointerException
>> at
>> org.ovirt.engine.core.vdsbroker.builder.vminfo.LibvirtVmXmlB
>> uilder.lambda$writeInterfaces$23(LibvirtVmXmlBuilder.java:1066)
>>   [vdsbroker.jar:]
>>
>> [...]
>>
>> But this doesn't lead us to the root cause. I haven't found any
>> matching bug tickets in release notes for upcoming 4.2.1. Can
>> anyone help here?
>>
>>
>> What's the mac address of that VM?
>> You can find it in the UI or with:
>>
>> select mac_addr from vm_interface where vm_guid in (select vm_guid
>> from vm_static where vm_name='');
>>
>>
>> Actually, different question - does this VM has unplugged network
>> interface?
>>
>
> The VM has two NICs. Both are plugged.
>
> The MAC addresses are 00:1a:4a:18:01:52 for nic1 and 00:1a:4a:36:01:67 for
> nic2.
>

OK, those seem like two valid mac addresses so maybe something is wrong
with the vm devices.
Could you please provide the output of:

select type, device, address, is_managed, is_plugged, alias from vm_device
where vm_id in (select vm_guid from vm_static where vm_name='');


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

Re: [ovirt-users] Tunable parameters in ovirt engine

With the default configuration of the web server it is impossible to handle
more than 256 *connections* simultaneously. I guess that "ab" is opening a
connection for each concurrent request, so when you reach request 257 the
web server will just reject the connection, there is nothing that the JBoss
can do about it; you have to increase the number of connections supported
by the web server.

*So Does it mean that oVirt cannot serve more than 257 request? *
My question is, If its possible How to scale this and what is the
configuration we need to change?

Also, we are taking a benchmark in using oVirt, So I need to find the
maximum possible oVirt request. So please let me know the configuration
tuning for oVirt to achieve maximum concurrent request.

Thanks,
Hari

On Wed, Mar 7, 2018 at 7:25 PM, Juan Hernández  wrote:

> With the default configuration of the web server it is impossible to
> handle more than 256 *connections* simultaneously. I guess that "ab" is
> opening a connection for each concurrent request, so when you reach request
> 257 the web server will just reject the connection, there is nothing that
> the JBoss can do about it; you have to increase the number of connections
> supported by the web server.
>
> Or else you may want to re-consider why you want to use 1000 simultaneous
> connections. It may be OK for a performance test, but there are better ways
> to squeeze performance. For example, you could consider using HTTP
> pipelining, which is much more friendly for the server than so many
> connections. This is what we use when we need to send a large number of
> requests from other systems. There are examples of how to do that with the
> Python and Ruby SDKs here:
>
>   Python:
>
> https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/
> examples/asynchronous_inventory.py
>
>   Ruby:
>
> https://github.com/oVirt/ovirt-engine-sdk-ruby/blob/master/
> sdk/examples/asynchronous_inventory.rb
>
>
> On 03/07/2018 02:43 PM, Hari Prasanth Loganathan wrote:
>
>> Hi Juan,
>>
>> Thanks for the response.
>>
>> I agree web server can handle only limited number of concurrent requests.
>> But Why it is failing with SSL handshake failure for few requests, Can't
>> the JBOSS wait and serve the request? We can spare the delay but not with
>> the request fails. So Is there a configuration in oVirt which can be tuned
>> to achieve this?
>>
>> Thanks,
>> Hari
>>
>> On Wed, Mar 7, 2018 at 7:05 PM, Juan Hernández 
>> wrote:
>>
>> The first thing you will need to change for such a test is the number of
>>> simultaneous connections accepted by the Apache web server: by default
>>> the
>>> max is 256. See the Apache documentation here:
>>>
>>>https://httpd.apache.org/docs/2.4/mod/mpm_common.html#m
>>> axrequestworkers
>>>
>>> In addition I also suggest that you consider using the "worker"
>>> multi-processing module instead of the "prefork", as it usually works
>>> better when talking to a Java application server, because it re-uses
>>> connections better.
>>>
>>> On 03/07/2018 02:20 PM, Hari Prasanth Loganathan wrote:
>>>
>>> Hi Team,

 *Description of problem:*

 I am trying to achieve 1000 concurrent request to oVirt. What are the
 tunable parameters to achieve this?

 I tried to perform the benchmarking for ovirt engine using Apache
 benchmark
 using the same SSO token.

 ab -n 1000 -c 500 -k -H "accept: application/json" -H "Authorization:
 Bearer SSOTOKEN" https://172.30.56.70/ovirt-engine/
 

 When the number of concurrent request is 500, we are getting more than
 100
 failures with the following error,

 SSL read failed (1) - closing connection
 139620982339352:error:

 NOTE: It is scaling for concurrent request below 500.

 I used the profiler to get the memory and CPU and it seems very less,

 PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+
 COMMAND
 30413 ovirt 20   0 4226664 882396   6776 S 126.0 23.0  27:48.53 java

 Configuration of the machine in which Ovirt is deployed :

 RAM - 4GB,
 Hard disk - 100GB,
 core processor - 2,
 OS - Cent7.x.

 In which 2GB is allocated to oVirt.


 Version-Release number of selected component (if applicable):

 4.2.2


 How reproducible:

 If the number of concurrent requests are above 500, we are easily facing
 this issue.


 *Actual results:*

 SSL read failed (1) - closing connection
 139620982339352:error:

 *Expected results:*

 Request success.


 Thanks,
 Hari



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



>>>
>>
>

--

Re: [ovirt-users] Unable to start VM after upgrade vom 4.1.9 to 4.2.1 - NPE


Hello Arik,



we have upgrade one of our oVirt engines to 4.2.1 (from 4.1.9)
and afterwards all nodes too. The cluster compatibility level
has been set to 4.2.

Now we can't start a VM after it has been powered off. The only
hint we found in engine.log is:

2018-03-07 14:51:52,504+01 INFO
[org.ovirt.engine.core.vdsbroker.UpdateVmDynamicDataVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-25)
[f855b54a-56d9-4708-8a67-5609438ddadb] START,
UpdateVmDynamicDataVDSCommand(
UpdateVmDynamicDataVDSCommandParameters:{hostId='null',
vmId='a7bc4124-06cb-4909-9389-bcf727df1304',
vmDynamic='org.ovirt.engine.co

re.common.businessentities.VmDynamic@491983e9'}),
log id: 7d49849e
2018-03-07 14:51:52,509+01 INFO
[org.ovirt.engine.core.vdsbroker.UpdateVmDynamicDataVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-25)
[f855b54a-56d9-4708-8a67-5609438ddadb] FINISH,
UpdateVmDynamicDataVDSCommand, log id: 7d49849e
2018-03-07 14:51:52,531+01 INFO
[org.ovirt.engine.core.vdsbroker.CreateVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-25)
[f855b54a-56d9-4708-8a67-5609438ddadb] START, CreateVDSCommand(

CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-4f7abd1f402b',
vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM
[prod-hub-201]'}), log id: 4af1f227
2018-03-07 14:51:52,533+01 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-25)
[f855b54a-56d9-4708-8a67-5609438ddadb] START,
CreateBrokerVDSCommand(HostName = prod-node-210,

CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-4f7abd1f402b',
vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM
[prod-hub-201]'}), log id: 71dcc8e7
2018-03-07 14:51:52,545+01 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-25)
[f855b54a-56d9-4708-8a67-5609438ddadb] Failed in
'CreateBrokerVDS' method, for vds: 'prod-node-210'; host:
'prod-node-210': null
2018-03-07 14:51:52,546+01 ERROR
[org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-25)
[f855b54a-56d9-4708-8a67-5609438ddadb] Command
'CreateBrokerVDSCommand(HostName = prod-node-210,

CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-4f7abd1f402b',
vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM
[prod-hub-201]'})' execution failed: null
2018-03-07 14:51:52,546+01 INFO
[org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-25)
[f855b54a-56d9-4708-8a67-5609438ddadb] FINISH,
CreateBrokerVDSCommand, log id: 71dcc8e7
2018-03-07 14:51:52,546+01 ERROR
[org.ovirt.engine.core.vdsbroker.CreateVDSCommand]
(EE-ManagedThreadFactory-engine-Thread-25) [f855b5
4a-56d9-4708-8a67-5609438ddadb] Failed to create VM:
java.lang.NullPointerException
at

org.ovirt.engine.core.vdsbroker.builder.vminfo.LibvirtVmXmlBuilder.lambda$writeInterfaces$23(LibvirtVmXmlBuilder.java:1066)
  [vdsbroker.jar:]

[...]

But this doesn't lead us to the root cause. I haven't found any
matching bug tickets in release notes for upcoming 4.2.1. Can
anyone help here?


What's the mac address of that VM?
You can find it in the UI or with:

select mac_addr from vm_interface where vm_guid in (select vm_guid
from vm_static where vm_name='');


Actually, different question - does this VM has unplugged network interface?


The VM has two NICs. Both are plugged.

The MAC addresses are 00:1a:4a:18:01:52 for nic1 and 
00:1a:4a:36:01:67 for nic2.


Regards

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

Re: [ovirt-users] Unable to start VM after upgrade vom 4.1.9 to 4.2.1 - NPE

On Wed, Mar 7, 2018 at 5:20 PM, Arik Hadas  wrote:

>
>
> On Wed, Mar 7, 2018 at 4:11 PM, Jan Siml  wrote:
>
>> Hello,
>>
>> we have upgrade one of our oVirt engines to 4.2.1 (from 4.1.9) and
>> afterwards all nodes too. The cluster compatibility level has been set to
>> 4.2.
>>
>> Now we can't start a VM after it has been powered off. The only hint we
>> found in engine.log is:
>>
>> 2018-03-07 14:51:52,504+01 INFO [org.ovirt.engine.core.vdsbrok
>> er.UpdateVmDynamicDataVDSCommand] (EE-ManagedThreadFactory-engine-Thread-25)
>> [f855b54a-56d9-4708-8a67-5609438ddadb] START,
>> UpdateVmDynamicDataVDSCommand( 
>> UpdateVmDynamicDataVDSCommandParameters:{hostId='null',
>> vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vmDynamic='
>> org.ovirt.engine.core.common.businessentities.VmDynamic@491983e9'}), log
>> id: 7d49849e
>> 2018-03-07 14:51:52,509+01 INFO [org.ovirt.engine.core.vdsbrok
>> er.UpdateVmDynamicDataVDSCommand] (EE-ManagedThreadFactory-engine-Thread-25)
>> [f855b54a-56d9-4708-8a67-5609438ddadb] FINISH,
>> UpdateVmDynamicDataVDSCommand, log id: 7d49849e
>> 2018-03-07 14:51:52,531+01 INFO 
>> [org.ovirt.engine.core.vdsbroker.CreateVDSCommand]
>> (EE-ManagedThreadFactory-engine-Thread-25) 
>> [f855b54a-56d9-4708-8a67-5609438ddadb]
>> START, CreateVDSCommand( CreateVDSCommandParameters:{ho
>> stId='0add031e-c72f-473f-ab2f-4f7abd1f402b',
>> vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM [prod-hub-201]'}),
>> log id: 4af1f227
>> 2018-03-07 14:51:52,533+01 INFO [org.ovirt.engine.core.vdsbrok
>> er.vdsbroker.CreateBrokerVDSCommand] 
>> (EE-ManagedThreadFactory-engine-Thread-25)
>> [f855b54a-56d9-4708-8a67-5609438ddadb] START,
>> CreateBrokerVDSCommand(HostName = prod-node-210,
>> CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-4f7abd1f402b',
>> vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM [prod-hub-201]'}),
>> log id: 71dcc8e7
>> 2018-03-07 14:51:52,545+01 ERROR [org.ovirt.engine.core.vdsbrok
>> er.vdsbroker.CreateBrokerVDSCommand] 
>> (EE-ManagedThreadFactory-engine-Thread-25)
>> [f855b54a-56d9-4708-8a67-5609438ddadb] Failed in 'CreateBrokerVDS'
>> method, for vds: 'prod-node-210'; host: 'prod-node-210': null
>> 2018-03-07 14:51:52,546+01 ERROR [org.ovirt.engine.core.vdsbrok
>> er.vdsbroker.CreateBrokerVDSCommand] 
>> (EE-ManagedThreadFactory-engine-Thread-25)
>> [f855b54a-56d9-4708-8a67-5609438ddadb] Command
>> 'CreateBrokerVDSCommand(HostName = prod-node-210,
>> CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-4f7abd1f402b',
>> vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM
>> [prod-hub-201]'})' execution failed: null
>> 2018-03-07 14:51:52,546+01 INFO [org.ovirt.engine.core.vdsbrok
>> er.vdsbroker.CreateBrokerVDSCommand] 
>> (EE-ManagedThreadFactory-engine-Thread-25)
>> [f855b54a-56d9-4708-8a67-5609438ddadb] FINISH, CreateBrokerVDSCommand,
>> log id: 71dcc8e7
>> 2018-03-07 14:51:52,546+01 ERROR 
>> [org.ovirt.engine.core.vdsbroker.CreateVDSCommand]
>> (EE-ManagedThreadFactory-engine-Thread-25) [f855b5
>> 4a-56d9-4708-8a67-5609438ddadb] Failed to create VM:
>> java.lang.NullPointerException
>> at org.ovirt.engine.core.vdsbroker.builder.vminfo.LibvirtVmXmlB
>> uilder.lambda$writeInterfaces$23(LibvirtVmXmlBuilder.java:1066)
>>  [vdsbroker.jar:]
>>
>> [...]
>>
>> But this doesn't lead us to the root cause. I haven't found any matching
>> bug tickets in release notes for upcoming 4.2.1. Can anyone help here?
>>
>
> What's the mac address of that VM?
> You can find it in the UI or with:
>
> select mac_addr from vm_interface where vm_guid in (select vm_guid from
> vm_static where vm_name='');
>

Actually, different question - does this VM has unplugged network interface?


>
>
>>
>> Kind regards
>>
>> Jan Siml
>> ___
>> 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] Unable to start VM after upgrade vom 4.1.9 to 4.2.1 - NPE

On Wed, Mar 7, 2018 at 4:11 PM, Jan Siml  wrote:

> Hello,
>
> we have upgrade one of our oVirt engines to 4.2.1 (from 4.1.9) and
> afterwards all nodes too. The cluster compatibility level has been set to
> 4.2.
>
> Now we can't start a VM after it has been powered off. The only hint we
> found in engine.log is:
>
> 2018-03-07 14:51:52,504+01 INFO [org.ovirt.engine.core.vdsbrok
> er.UpdateVmDynamicDataVDSCommand] (EE-ManagedThreadFactory-engine-Thread-25)
> [f855b54a-56d9-4708-8a67-5609438ddadb] START,
> UpdateVmDynamicDataVDSCommand( 
> UpdateVmDynamicDataVDSCommandParameters:{hostId='null',
> vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vmDynamic='
> org.ovirt.engine.core.common.businessentities.VmDynamic@491983e9'}), log
> id: 7d49849e
> 2018-03-07 14:51:52,509+01 INFO [org.ovirt.engine.core.vdsbrok
> er.UpdateVmDynamicDataVDSCommand] (EE-ManagedThreadFactory-engine-Thread-25)
> [f855b54a-56d9-4708-8a67-5609438ddadb] FINISH,
> UpdateVmDynamicDataVDSCommand, log id: 7d49849e
> 2018-03-07 14:51:52,531+01 INFO 
> [org.ovirt.engine.core.vdsbroker.CreateVDSCommand]
> (EE-ManagedThreadFactory-engine-Thread-25) 
> [f855b54a-56d9-4708-8a67-5609438ddadb]
> START, CreateVDSCommand( CreateVDSCommandParameters:{ho
> stId='0add031e-c72f-473f-ab2f-4f7abd1f402b',
> vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM [prod-hub-201]'}),
> log id: 4af1f227
> 2018-03-07 14:51:52,533+01 INFO [org.ovirt.engine.core.vdsbrok
> er.vdsbroker.CreateBrokerVDSCommand] 
> (EE-ManagedThreadFactory-engine-Thread-25)
> [f855b54a-56d9-4708-8a67-5609438ddadb] START,
> CreateBrokerVDSCommand(HostName = prod-node-210,
> CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-4f7abd1f402b',
> vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM [prod-hub-201]'}),
> log id: 71dcc8e7
> 2018-03-07 14:51:52,545+01 ERROR [org.ovirt.engine.core.vdsbrok
> er.vdsbroker.CreateBrokerVDSCommand] 
> (EE-ManagedThreadFactory-engine-Thread-25)
> [f855b54a-56d9-4708-8a67-5609438ddadb] Failed in 'CreateBrokerVDS'
> method, for vds: 'prod-node-210'; host: 'prod-node-210': null
> 2018-03-07 14:51:52,546+01 ERROR [org.ovirt.engine.core.vdsbrok
> er.vdsbroker.CreateBrokerVDSCommand] 
> (EE-ManagedThreadFactory-engine-Thread-25)
> [f855b54a-56d9-4708-8a67-5609438ddadb] Command
> 'CreateBrokerVDSCommand(HostName = prod-node-210,
> CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-4f7abd1f402b',
> vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM
> [prod-hub-201]'})' execution failed: null
> 2018-03-07 14:51:52,546+01 INFO [org.ovirt.engine.core.vdsbrok
> er.vdsbroker.CreateBrokerVDSCommand] 
> (EE-ManagedThreadFactory-engine-Thread-25)
> [f855b54a-56d9-4708-8a67-5609438ddadb] FINISH, CreateBrokerVDSCommand,
> log id: 71dcc8e7
> 2018-03-07 14:51:52,546+01 ERROR 
> [org.ovirt.engine.core.vdsbroker.CreateVDSCommand]
> (EE-ManagedThreadFactory-engine-Thread-25) [f855b5
> 4a-56d9-4708-8a67-5609438ddadb] Failed to create VM:
> java.lang.NullPointerException
> at org.ovirt.engine.core.vdsbroker.builder.vminfo.LibvirtVmXmlB
> uilder.lambda$writeInterfaces$23(LibvirtVmXmlBuilder.java:1066)
>  [vdsbroker.jar:]
>
> [...]
>
> But this doesn't lead us to the root cause. I haven't found any matching
> bug tickets in release notes for upcoming 4.2.1. Can anyone help here?
>

What's the mac address of that VM?
You can find it in the UI or with:

select mac_addr from vm_interface where vm_guid in (select vm_guid from
vm_static where vm_name='');


>
> Kind regards
>
> Jan Siml
> ___
> 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] New oVirt blog - Your Container Volumes Served By oVirt

2018-03-07 Thread Yaniv Kaul

When running a virtualization workload on oVirt, a VM disk is 'natively' a
disk somewhere on your network-storage.
Entering containers world, on Kubernetes(k8s) or OpenShift, there are many
options specifically because the workload can be totally stateless, i.e
they are stored on a host supplied disk and can be removed when the
container is terminated. The more interesting case is *stateful workloads* i.e
apps that persist data (think DBs, web servers/services, etc).
k8s/OpenShift designed an API to dynamically provision the container
storage (volume in k8s terminology).

In this post I want to cover how oVirt can provide volumes for containers
running on k8s/OpenShift cluster.


Read more @
https://ovirt.org/blog/2018/02/your-container-volumes-served-by-ovirt/
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Unable to start VM after upgrade vom 4.1.9 to 4.2.1 - NPE


Hello,

we have upgrade one of our oVirt engines to 4.2.1 (from 4.1.9) and 
afterwards all nodes too. The cluster compatibility level has been set 
to 4.2.


Now we can't start a VM after it has been powered off. The only hint we 
found in engine.log is:


2018-03-07 14:51:52,504+01 INFO 
[org.ovirt.engine.core.vdsbroker.UpdateVmDynamicDataVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-25) 
[f855b54a-56d9-4708-8a67-5609438ddadb] START, 
UpdateVmDynamicDataVDSCommand( 
UpdateVmDynamicDataVDSCommandParameters:{hostId='null', 
vmId='a7bc4124-06cb-4909-9389-bcf727df1304', 
vmDynamic='org.ovirt.engine.core.common.businessentities.VmDynamic@491983e9'}), 
log id: 7d49849e
2018-03-07 14:51:52,509+01 INFO 
[org.ovirt.engine.core.vdsbroker.UpdateVmDynamicDataVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-25) 
[f855b54a-56d9-4708-8a67-5609438ddadb] FINISH, 
UpdateVmDynamicDataVDSCommand, log id: 7d49849e
2018-03-07 14:51:52,531+01 INFO 
[org.ovirt.engine.core.vdsbroker.CreateVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-25) 
[f855b54a-56d9-4708-8a67-5609438ddadb] START, CreateVDSCommand( 
CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-4f7abd1f402b', 
vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM [prod-hub-201]'}), 
log id: 4af1f227
2018-03-07 14:51:52,533+01 INFO 
[org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-25) 
[f855b54a-56d9-4708-8a67-5609438ddadb] START, 
CreateBrokerVDSCommand(HostName = prod-node-210, 
CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-4f7abd1f402b', 
vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM [prod-hub-201]'}), 
log id: 71dcc8e7
2018-03-07 14:51:52,545+01 ERROR 
[org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-25) 
[f855b54a-56d9-4708-8a67-5609438ddadb] Failed in 'CreateBrokerVDS' 
method, for vds: 'prod-node-210'; host: 'prod-node-210': null
2018-03-07 14:51:52,546+01 ERROR 
[org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-25) 
[f855b54a-56d9-4708-8a67-5609438ddadb] Command 
'CreateBrokerVDSCommand(HostName = prod-node-210, 
CreateVDSCommandParameters:{hostId='0add031e-c72f-473f-ab2f-4f7abd1f402b', 
vmId='a7bc4124-06cb-4909-9389-bcf727df1304', vm='VM

[prod-hub-201]'})' execution failed: null
2018-03-07 14:51:52,546+01 INFO 
[org.ovirt.engine.core.vdsbroker.vdsbroker.CreateBrokerVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-25) 
[f855b54a-56d9-4708-8a67-5609438ddadb] FINISH, CreateBrokerVDSCommand, 
log id: 71dcc8e7
2018-03-07 14:51:52,546+01 ERROR 
[org.ovirt.engine.core.vdsbroker.CreateVDSCommand] 
(EE-ManagedThreadFactory-engine-Thread-25) [f855b5
4a-56d9-4708-8a67-5609438ddadb] Failed to create VM: 
java.lang.NullPointerException
at 
org.ovirt.engine.core.vdsbroker.builder.vminfo.LibvirtVmXmlBuilder.lambda$writeInterfaces$23(LibvirtVmXmlBuilder.java:1066)

 [vdsbroker.jar:]

[...]

But this doesn't lead us to the root cause. I haven't found any matching 
bug tickets in release notes for upcoming 4.2.1. Can anyone help here?


Kind regards

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

Re: [ovirt-users] Tunable parameters in ovirt engine

2018-03-07 Thread Juan Hernández

With the default configuration of the web server it is impossible to
handle more than 256 *connections* simultaneously. I guess that "ab" is
opening a connection for each concurrent request, so when you reach
request 257 the web server will just reject the connection, there is
nothing that the JBoss can do about it; you have to increase the number
of connections supported by the web server.

Or else you may want to re-consider why you want to use 1000
simultaneous connections. It may be OK for a performance test, but there
are better ways to squeeze performance. For example, you could consider
using HTTP pipelining, which is much more friendly for the server than
so many connections. This is what we use when we need to send a large
number of requests from other systems. There are examples of how to do
that with the Python and Ruby SDKs here:

Python:

https://github.com/oVirt/ovirt-engine-sdk/blob/master/sdk/examples/asynchronous_inventory.py

Ruby:

https://github.com/oVirt/ovirt-engine-sdk-ruby/blob/master/sdk/examples/asynchronous_inventory.rb

On 03/07/2018 02:43 PM, Hari Prasanth Loganathan wrote:

Hi Juan,

Thanks for the response.

I agree web server can handle only limited number of concurrent requests.
But Why it is failing with SSL handshake failure for few requests, Can't
the JBOSS wait and serve the request? We can spare the delay but not with
the request fails. So Is there a configuration in oVirt which can be tuned
to achieve this?

Thanks,
Hari

On Wed, Mar 7, 2018 at 7:05 PM, Juan Hernández wrote:

The first thing you will need to change for such a test is the number of
simultaneous connections accepted by the Apache web server: by default the
max is 256. See the Apache documentation here:

https://httpd.apache.org/docs/2.4/mod/mpm_common.html#maxrequestworkers

In addition I also suggest that you consider using the "worker"
multi-processing module instead of the "prefork", as it usually works
better when talking to a Java application server, because it re-uses
connections better.

On 03/07/2018 02:20 PM, Hari Prasanth Loganathan wrote:

Hi Team,

*Description of problem:*

I am trying to achieve 1000 concurrent request to oVirt. What are the
tunable parameters to achieve this?

I tried to perform the benchmarking for ovirt engine using Apache
benchmark
using the same SSO token.

ab -n 1000 -c 500 -k -H "accept: application/json" -H "Authorization:
Bearer SSOTOKEN" https://172.30.56.70/ovirt-engine/

When the number of concurrent request is 500, we are getting more than 100
failures with the following error,

SSL read failed (1) - closing connection
139620982339352:error:

NOTE: It is scaling for concurrent request below 500.

I used the profiler to get the memory and CPU and it seems very less,

PID USER PR NIVIRTRESSHR S %CPU %MEM TIME+
COMMAND
30413 ovirt 20 0 4226664 882396 6776 S 126.0 23.0 27:48.53 java

Configuration of the machine in which Ovirt is deployed :

RAM - 4GB,
Hard disk - 100GB,
core processor - 2,
OS - Cent7.x.

In which 2GB is allocated to oVirt.

Version-Release number of selected component (if applicable):

4.2.2

How reproducible:

If the number of concurrent requests are above 500, we are easily facing
this issue.

*Actual results:*

SSL read failed (1) - closing connection
139620982339352:error:

*Expected results:*

Request success.

Thanks,
Hari

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

Re: [ovirt-users] Tunable parameters in ovirt engine

Hi Juan,

Thanks for the response.

I agree web server can handle only limited number of concurrent requests.
But Why it is failing with SSL handshake failure for few requests, Can't
the JBOSS wait and serve the request? We can spare the delay but not with
the request fails. So Is there a configuration in oVirt which can be tuned
to achieve this?

Thanks,
Hari

On Wed, Mar 7, 2018 at 7:05 PM, Juan Hernández  wrote:

> The first thing you will need to change for such a test is the number of
> simultaneous connections accepted by the Apache web server: by default the
> max is 256. See the Apache documentation here:
>
>   https://httpd.apache.org/docs/2.4/mod/mpm_common.html#maxrequestworkers
>
> In addition I also suggest that you consider using the "worker"
> multi-processing module instead of the "prefork", as it usually works
> better when talking to a Java application server, because it re-uses
> connections better.
>
> On 03/07/2018 02:20 PM, Hari Prasanth Loganathan wrote:
>
>> Hi Team,
>>
>> *Description of problem:*
>>
>> I am trying to achieve 1000 concurrent request to oVirt. What are the
>> tunable parameters to achieve this?
>>
>> I tried to perform the benchmarking for ovirt engine using Apache
>> benchmark
>> using the same SSO token.
>>
>> ab -n 1000 -c 500 -k -H "accept: application/json" -H "Authorization:
>> Bearer SSOTOKEN" https://172.30.56.70/ovirt-engine/
>> > b-9ff1-076fc07ebf50/statistics>
>>
>> When the number of concurrent request is 500, we are getting more than 100
>> failures with the following error,
>>
>> SSL read failed (1) - closing connection
>> 139620982339352:error:
>>
>> NOTE: It is scaling for concurrent request below 500.
>>
>> I used the profiler to get the memory and CPU and it seems very less,
>>
>>PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+
>> COMMAND
>> 30413 ovirt 20   0 4226664 882396   6776 S 126.0 23.0  27:48.53 java
>>
>> Configuration of the machine in which Ovirt is deployed :
>>
>> RAM - 4GB,
>> Hard disk - 100GB,
>> core processor - 2,
>> OS - Cent7.x.
>>
>> In which 2GB is allocated to oVirt.
>>
>>
>> Version-Release number of selected component (if applicable):
>>
>> 4.2.2
>>
>>
>> How reproducible:
>>
>> If the number of concurrent requests are above 500, we are easily facing
>> this issue.
>>
>>
>> *Actual results:*
>>
>> SSL read failed (1) - closing connection
>> 139620982339352:error:
>>
>> *Expected results:*
>>
>> Request success.
>>
>>
>> Thanks,
>> Hari
>>
>>
>>
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>>
>

-- 

DISCLAIMER

The information in this e-mail is confidential and may be subject to legal 
privilege. It is intended solely for the addressee. Access to this e-mail 
by anyone else is unauthorized. If you have received this communication in 
error, please address with the subject heading "Received in error," send to 
i...@msystechnologies.com,  then delete the e-mail and destroy any copies of 
it. If you are not the intended recipient, any disclosure, copying, 
distribution or any action taken or omitted to be taken in reliance on it, 
is prohibited and may be unlawful. The views, opinions, conclusions and 
other information expressed in this electronic mail and any attachments are 
not given or endorsed by the company unless otherwise indicated by an 
authorized representative independent of this message.
MSys cannot guarantee that e-mail communications are secure or error-free, 
as information could be intercepted, corrupted, amended, lost, destroyed, 
arrive late or incomplete, or contain viruses, though all reasonable 
precautions have been taken to ensure no viruses are present in this e-mail. 
As our company cannot accept responsibility for any loss or damage arising 
from the use of this e-mail or attachments we recommend that you subject 
these to your virus checking procedures prior to use
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Power off VM from VM portal

2018-03-07 Thread Nicolas Ecarnot


Le 07/03/2018 à 13:42, Alexandr Krivulya a écrit :



06.03.2018 17:39, Nicolas Ecarnot пишет:

Le 06/03/2018 à 16:02, Alexandr Krivulya a écrit :

Hi,

is there any way to power off VM from VM portal (4.2.1.7)? I can't 
find "power off" button, just "shutdown".



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


Hello Alexandr,

After having clicked on the VM link, you'll notice that on the right 
of the Shutdown button is an arrow allowing you to access to the Power 
Off feature.


I cant find this arrow on Shutdown button




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



Oh sorry I answered in the context of admin portal.
Indeed, in the VM portal, I neither see this poweroff button.

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

Re: [ovirt-users] Tunable parameters in ovirt engine

2018-03-07 Thread Juan Hernández

The first thing you will need to change for such a test is the number of 
simultaneous connections accepted by the Apache web server: by default 
the max is 256. See the Apache documentation here:


  https://httpd.apache.org/docs/2.4/mod/mpm_common.html#maxrequestworkers

In addition I also suggest that you consider using the "worker" 
multi-processing module instead of the "prefork", as it usually works 
better when talking to a Java application server, because it re-uses 
connections better.


On 03/07/2018 02:20 PM, Hari Prasanth Loganathan wrote:

Hi Team,

*Description of problem:*

I am trying to achieve 1000 concurrent request to oVirt. What are the
tunable parameters to achieve this?

I tried to perform the benchmarking for ovirt engine using Apache benchmark
using the same SSO token.

ab -n 1000 -c 500 -k -H "accept: application/json" -H "Authorization:
Bearer SSOTOKEN" https://172.30.56.70/ovirt-engine/


When the number of concurrent request is 500, we are getting more than 100
failures with the following error,

SSL read failed (1) - closing connection
139620982339352:error:

NOTE: It is scaling for concurrent request below 500.

I used the profiler to get the memory and CPU and it seems very less,

   PID USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+
COMMAND
30413 ovirt 20   0 4226664 882396   6776 S 126.0 23.0  27:48.53 java

Configuration of the machine in which Ovirt is deployed :

RAM - 4GB,
Hard disk - 100GB,
core processor - 2,
OS - Cent7.x.

In which 2GB is allocated to oVirt.


Version-Release number of selected component (if applicable):

4.2.2


How reproducible:

If the number of concurrent requests are above 500, we are easily facing
this issue.


*Actual results:*

SSL read failed (1) - closing connection
139620982339352:error:

*Expected results:*

Request success.


Thanks,
Hari



___
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] Tunable parameters in ovirt engine