[ovirt-users] Re: Disk Statistics API in oVirt

[Hari Prasanth Loganathan]

Hi Karli,

Sorry for the confusion, Initially I thought it is an issue from our side
so posted like 'ignore it',
But this issue is from oVirt. So could you please help me.

*Steps to reproduce :*
1) Attach the disk to any VM
2) Perform some read and write operation in the VM which will increase the disk
level - 'Read data rate / Write data rate / disk.read.latency /
disk.write.latency'
3) Now when I bring down the VM, all the disk statistics should come down
to be zero *But it is still retaining with last known value when the VM was
in UP state.*


*Expected : All values should go to ZeroActual : All values retains the
last known values when the VM was in UP state. *

Thanks,
Hari


On Wed, Jul 18, 2018 at 11:20 AM, Karli Sjöberg  wrote:

>
>
> On Jul 17, 2018 11:56, Hari Prasanth Loganathan  msystechnologies.com> wrote:
>
> It is an issue from our side. Please ignore my question.
>
>
> You've now made several posts about wanting help, but this completely
> contradicts it!
>
>
> I don't get it, do you have an issue you want help with, or should
> everyone just ignore you?
>
> /K
>
>
> But How frequently we will collect the disk statistics and update in
> PostgreSQL?
>
> Thanks,
> Hari
>
> On Tue, Jul 17, 2018 at 3:18 PM, Hari Prasanth Loganathan  msystechnologies.com> wrote:
>
> Hi Team,
>
> We are using the following API to collect the disk statistics,
>
> https://X.X.X.2/ovirt-engine/api/
> *disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics*
> 
>
> I found one issue in the disk statistics. In case If the Virtual Machine
> has this disk (*2331bad7-71ec-4fad-95bb-2b3449f3dbda*) attached to it and
> I perform some read / write operation in the VM and it increases the
> corresponding disk level Read data rate / Write data rate /
> disk.read.latency / disk.write.latency.
>
> *Example*, I received the following values for this disk, But the problem
> is even when I bring down the VM still the last known value is received
> continuously.
> *Is it a known issue Or any workaround is available? *
>
> *Expected : All values should go to Zero*
>
> *Actual : All values retains the last known values when the VM was in UP
> state. *
>
>
> {
> "statistic": [
> {
> "kind": "gauge",
> "type": "decimal",
> "unit": "bytes_per_second",
> "values": {
> "value": [
> {
> "datum": 2184
> }
> ]
> },
> "disk": {
> "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
> 2b3449f3dbda",
> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
> },
> "name": "data.current.read",
> "description": "Read data rate",
> "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
> 2b3449f3dbda/statistics/33b9212b-f9cb-3fd0-b364-248fb61e1272",
> "id": "33b9212b-f9cb-3fd0-b364-248fb61e1272"
> },
> {
> "kind": "gauge",
> "type": "decimal",
> "unit": "bytes_per_second",
> "values": {
> "value": [
> {
> "datum": 41202005
> }
> ]
> },
> "disk": {
> "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
> 2b3449f3dbda",
> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
> },
> "name": "data.current.write",
> "description": "Write data rate",
> "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
> 2b3449f3dbda/statistics/2f23addd-4ebd-3d82-a449-c28778bc33eb",
> "id": "2f23addd-4ebd-3d82-a449-c28778bc33eb"
> },
> {
> "kind": "gauge",
> "type": "decimal",
> "unit": "seconds",
> "values": {
> "value": [
> {
> "datum": 0.12
> }
> ]
> },
> "disk": {
> "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
> 2b3449f3dbda",
> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
> },
> "name": "disk.read.latency",
> "description": "Read latency",
> "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
> 2b3449f3dbda/statistics/3a7b3f72-d035-3bb9-b196-e86a4eb34993",
> "id": "3a7b3f72-d035-3bb9-b196-e86a4eb34993"
> },
> {
> "kind": "gauge",
> "type": "decimal",
> "unit": "seconds",
> "values": {
> "value": [
> {
> "datum": 1.4
> }
> ]
> },
> "disk": {
> "href": 

[ovirt-users] Re: Disk Statistics API in oVirt

[Karli Sjöberg]

On Jul 17, 2018 11:56, Hari Prasanth Loganathan  wrote:It is an issue from our side. Please ignore my question. You've now made several posts about wanting help, but this completely contradicts it!I don't get it, do you have an issue you want help with, or should everyone just ignore you?/KBut How frequently we will collect the disk statistics and update in PostgreSQL? Thanks,Hari  On Tue, Jul 17, 2018 at 3:18 PM, Hari Prasanth Loganathan  wrote:Hi Team,We are using the following API to collect the disk statistics,https://X.X.X.2/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statisticsI found one issue in the disk statistics. In case If the Virtual Machine has this disk (2331bad7-71ec-4fad-95bb-2b3449f3dbda) attached to it and I perform some read / write operation in the VM and it increases the corresponding disk level Read data rate / Write data rate / disk.read.latency / disk.write.latency.Example, I received the following values for this disk, But the problem is even when I bring down the VM still the last known value is received continuously. Is it a known issue Or any workaround is available? Expected : All values should go to ZeroActual : All values retains the last known values when the VM was in UP state. {    "statistic": [    {    "kind": "gauge",    "type": "decimal",    "unit": "bytes_per_second",    "values": {    "value": [    {    "datum": 2184    }    ]    },    "disk": {    "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda",    "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"    },    "name": "data.current.read",    "description": "Read data rate",    "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics/33b9212b-f9cb-3fd0-b364-248fb61e1272",    "id": "33b9212b-f9cb-3fd0-b364-248fb61e1272"    },    {    "kind": "gauge",    "type": "decimal",    "unit": "bytes_per_second",    "values": {    "value": [    {    "datum": 41202005    }    ]    },    "disk": {    "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda",    "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"    },    "name": "data.current.write",    "description": "Write data rate",    "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics/2f23addd-4ebd-3d82-a449-c28778bc33eb",    "id": "2f23addd-4ebd-3d82-a449-c28778bc33eb"    },    {    "kind": "gauge",    "type": "decimal",    "unit": "seconds",    "values": {    "value": [    {    "datum": 0.12    }    ]    },    "disk": {    "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda",    "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"    },    "name": "disk.read.latency",    "description": "Read latency",    "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics/3a7b3f72-d035-3bb9-b196-e86a4eb34993",    "id": "3a7b3f72-d035-3bb9-b196-e86a4eb34993"    },    {    "kind": "gauge",    "type": "decimal",    "unit": "seconds",    "values": {    "value": [    {    "datum": 1.4    }    ]    },    "disk": {    "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda",    "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"    },    "name": "disk.write.latency",    "description": "Write latency",    "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics/b1e75c7b-cea4-37d2-8459-f7d68efc69a3",    "id": "b1e75c7b-cea4-37d2-8459-f7d68efc69a3"    },    {    "kind": "gauge",    "type": "decimal",    "unit": "seconds",    "values": {    "value": [    {    "datum": 0    }    ]    },    "disk": {    "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda",    "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"    },    "name": "disk.flush.latency",    "description": "Flush latency",    "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics/9c17ad7b-9ef1-3e8d-ad0a-ff8bee3925f0",    "id": "9c17ad7b-9ef1-3e8d-ad0a-ff8bee3925f0"    }    ]}Thanks,Hari 



DISCLAIMER - MSysTechnologies LLC This email message, 

[ovirt-users] Re: oVirt 4.2.5.1-1.el7 JSON-RPC statistics error

[Maton, Brett]

Thanks Francesco,

  Log attached.

On 17 July 2018 at 13:12, Francesco Romani  wrote:

> On 07/17/2018 07:30 AM, Maton, Brett wrote:
>
> I've got one physical host in a 3 host CentOS7.5 cluster that reports the
> following error several times a day
>
> VDSM node3.example.com command Get Host Statistics failed: Internal
> JSON-RPC error: {'reason': ' \'exceptions.AttributeError\'>:\'NoneType\'
> object has no attribute \'statistics\'">'}
>
> Any ideas what the problem might be?
>
>
> Hi,
>
> I can make a wild guess[1], but let's try educated guesses first: could
> you please share the Vdsm logs around the time on which you see this error?
>
> Thanks,
>
> +++
>
> [1] It seems to me that a NIC card was removed from a VM during a
> statistic reporting cycle, or somehow failed to report stats. But really,
> is a wild guess.Let's look at the logs first.
>
> --
> Francesco Romani
> Senior SW Eng., Virtualization R
> Red Hat
> IRC: fromani github: @fromanirh
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/JSRLKAZSSPXGUBDE7CXRQDXZTQJBY5YY/
>
>


vdsm.log.gz
Description: GNU Zip compressed data
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/JQBKBLKCI7WJOERG6W6DOJ7P2DM4S34S/

[ovirt-users] Re: Disk Statistics API in Ovirt

[Hari Prasanth Loganathan]

These statistics give wrong result when the VM is down. Guys did you get
any update on this?

Any help is appreciated.

Thanks,
Hari

On Tue, 17 Jul 2018 at 5:47 PM, Hari Prasanth Loganathan <
hariprasant...@msystechnologies.com> wrote:

> Hi Team,
>
> *Steps to reproduce :*
> 1) Attach the disk to any VM
> 2) Perform some read and write operation in the VM which will increase the 
> disk
> level - 'Read data rate / Write data rate / disk.read.latency /
> disk.write.latency'
> 3) Now when I bring down the VM, all the disk statistics needs to be zero *But
> it is still retaining with last known value when the VM was in UP state.*
>
>
>
> *Expected : All values should go to ZeroActual : All values retains the
> last known values when the VM was in UP state. *
>
> Thanks,
> Hari
>
>
>
> On Tue, Jul 17, 2018 at 3:39 PM, Hari Prasanth Loganathan <
> hariprasant...@msystechnologies.com> wrote:
>
>> Hi Guys,
>>
>> I think it is a serious issue, please let us know your thoughts?
>>
>>
>> On Tue, Jul 17, 2018 at 3:27 PM, Hari Prasanth Loganathan <
>> hariprasant...@msystechnologies.com> wrote:
>>
>>> Hi Team,
>>>
>>> We are using the following API to collect the disk statistics,
>>>
>>> https://X.X.X.2/ovirt-engine/api/
>>> *disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics*
>>> 
>>>
>>> I found one issue in the disk statistics. In case If the Virtual Machine
>>> has this disk (*2331bad7-71ec-4fad-95bb-2b3449f3dbda*) attached to it
>>> and I perform some read / write operation in the VM and it increases the
>>> corresponding disk level Read data rate / Write data rate /
>>> disk.read.latency / disk.write.latency.
>>>
>>> *Example*, I received the following values for this disk, But the
>>> problem is even when I bring down the VM still the last known value is
>>> received continuously.
>>> *Is it a known issue Or any workaround is available? *
>>>
>>> *Expected : All values should go to Zero*
>>>
>>> *Actual : All values retains the last known values when the VM was in UP
>>> state. *
>>>
>>>
>>> {
>>> "statistic": [
>>> {
>>> "kind": "gauge",
>>> "type": "decimal",
>>> "unit": "bytes_per_second",
>>> "values": {
>>> "value": [
>>> {
>>> "datum": 2184
>>> }
>>> ]
>>> },
>>> "disk": {
>>> "href":
>>> "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda",
>>> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
>>> },
>>> "name": "data.current.read",
>>> "description": "Read data rate",
>>> "href":
>>> "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics/33b9212b-f9cb-3fd0-b364-248fb61e1272",
>>> "id": "33b9212b-f9cb-3fd0-b364-248fb61e1272"
>>> },
>>> {
>>> "kind": "gauge",
>>> "type": "decimal",
>>> "unit": "bytes_per_second",
>>> "values": {
>>> "value": [
>>> {
>>> "datum": 41202005
>>> }
>>> ]
>>> },
>>> "disk": {
>>> "href":
>>> "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda",
>>> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
>>> },
>>> "name": "data.current.write",
>>> "description": "Write data rate",
>>> "href":
>>> "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics/2f23addd-4ebd-3d82-a449-c28778bc33eb",
>>> "id": "2f23addd-4ebd-3d82-a449-c28778bc33eb"
>>> },
>>> {
>>> "kind": "gauge",
>>> "type": "decimal",
>>> "unit": "seconds",
>>> "values": {
>>> "value": [
>>> {
>>> "datum": 0.12
>>> }
>>> ]
>>> },
>>> "disk": {
>>> "href":
>>> "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda",
>>> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
>>> },
>>> "name": "disk.read.latency",
>>> "description": "Read latency",
>>> "href":
>>> "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics/3a7b3f72-d035-3bb9-b196-e86a4eb34993",
>>> "id": "3a7b3f72-d035-3bb9-b196-e86a4eb34993"
>>> },
>>> {
>>> "kind": "gauge",
>>> "type": "decimal",
>>> "unit": "seconds",
>>> "values": {
>>> "value": [
>>> {
>>> "datum": 1.4
>>> }
>>> ]
>>> },
>>> "disk": {
>>> 

[ovirt-users] Re: Disk Statistics API in Ovirt

[Hari Prasanth Loganathan]

Hi Team,

*Steps to reproduce :*
1) Attach the disk to any VM
2) Perform some read and write operation in the VM which will increase the disk
level - 'Read data rate / Write data rate / disk.read.latency /
disk.write.latency'
3) Now when I bring down the VM, all the disk statistics needs to be zero *But
it is still retaining with last known value when the VM was in UP state.*



*Expected : All values should go to ZeroActual : All values retains the
last known values when the VM was in UP state. *

Thanks,
Hari



On Tue, Jul 17, 2018 at 3:39 PM, Hari Prasanth Loganathan <
hariprasant...@msystechnologies.com> wrote:

> Hi Guys,
>
> I think it is a serious issue, please let us know your thoughts?
>
>
> On Tue, Jul 17, 2018 at 3:27 PM, Hari Prasanth Loganathan  msystechnologies.com> wrote:
>
>> Hi Team,
>>
>> We are using the following API to collect the disk statistics,
>>
>> https://X.X.X.2/ovirt-engine/api/
>> *disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics*
>> 
>>
>> I found one issue in the disk statistics. In case If the Virtual Machine
>> has this disk (*2331bad7-71ec-4fad-95bb-2b3449f3dbda*) attached to it
>> and I perform some read / write operation in the VM and it increases the
>> corresponding disk level Read data rate / Write data rate /
>> disk.read.latency / disk.write.latency.
>>
>> *Example*, I received the following values for this disk, But the
>> problem is even when I bring down the VM still the last known value is
>> received continuously.
>> *Is it a known issue Or any workaround is available? *
>>
>> *Expected : All values should go to Zero*
>>
>> *Actual : All values retains the last known values when the VM was in UP
>> state. *
>>
>>
>> {
>> "statistic": [
>> {
>> "kind": "gauge",
>> "type": "decimal",
>> "unit": "bytes_per_second",
>> "values": {
>> "value": [
>> {
>> "datum": 2184
>> }
>> ]
>> },
>> "disk": {
>> "href": "/ovirt-engine/api/disks/2331b
>> ad7-71ec-4fad-95bb-2b3449f3dbda",
>> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
>> },
>> "name": "data.current.read",
>> "description": "Read data rate",
>> "href": "/ovirt-engine/api/disks/2331b
>> ad7-71ec-4fad-95bb-2b3449f3dbda/statistics/33b9212b-f9cb-3fd
>> 0-b364-248fb61e1272",
>> "id": "33b9212b-f9cb-3fd0-b364-248fb61e1272"
>> },
>> {
>> "kind": "gauge",
>> "type": "decimal",
>> "unit": "bytes_per_second",
>> "values": {
>> "value": [
>> {
>> "datum": 41202005
>> }
>> ]
>> },
>> "disk": {
>> "href": "/ovirt-engine/api/disks/2331b
>> ad7-71ec-4fad-95bb-2b3449f3dbda",
>> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
>> },
>> "name": "data.current.write",
>> "description": "Write data rate",
>> "href": "/ovirt-engine/api/disks/2331b
>> ad7-71ec-4fad-95bb-2b3449f3dbda/statistics/2f23addd-4ebd-3d8
>> 2-a449-c28778bc33eb",
>> "id": "2f23addd-4ebd-3d82-a449-c28778bc33eb"
>> },
>> {
>> "kind": "gauge",
>> "type": "decimal",
>> "unit": "seconds",
>> "values": {
>> "value": [
>> {
>> "datum": 0.12
>> }
>> ]
>> },
>> "disk": {
>> "href": "/ovirt-engine/api/disks/2331b
>> ad7-71ec-4fad-95bb-2b3449f3dbda",
>> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
>> },
>> "name": "disk.read.latency",
>> "description": "Read latency",
>> "href": "/ovirt-engine/api/disks/2331b
>> ad7-71ec-4fad-95bb-2b3449f3dbda/statistics/3a7b3f72-d035-3bb
>> 9-b196-e86a4eb34993",
>> "id": "3a7b3f72-d035-3bb9-b196-e86a4eb34993"
>> },
>> {
>> "kind": "gauge",
>> "type": "decimal",
>> "unit": "seconds",
>> "values": {
>> "value": [
>> {
>> "datum": 1.4
>> }
>> ]
>> },
>> "disk": {
>> "href": "/ovirt-engine/api/disks/2331b
>> ad7-71ec-4fad-95bb-2b3449f3dbda",
>> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
>> },
>> "name": "disk.write.latency",
>> "description": "Write latency",
>> "href": "/ovirt-engine/api/disks/2331b
>> ad7-71ec-4fad-95bb-2b3449f3dbda/statistics/b1e75c7b-cea4-37d
>> 

[ovirt-users] Re: oVirt 4.2.5.1-1.el7 JSON-RPC statistics error

[Francesco Romani]

On 07/17/2018 07:30 AM, Maton, Brett wrote:
I've got one physical host in a 3 host CentOS7.5 cluster that reports 
the following error several times a day


VDSM node3.example.com  command Get Host 
Statistics failed: Internal JSON-RPC error: {'reason': '":\'NoneType\' object has no 
attribute \'statistics\'">'}


Any ideas what the problem might be?


Hi,

I can make a wild guess[1], but let's try educated guesses first: could 
you please share the Vdsm logs around the time on which you see this error?


Thanks,

+++

[1] It seems to me that a NIC card was removed from a VM during a 
statistic reporting cycle, or somehow failed to report stats. But 
really, is a wild guess.Let's look at the logs first.


--
Francesco Romani
Senior SW Eng., Virtualization R
Red Hat
IRC: fromani github: @fromanirh

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/JSRLKAZSSPXGUBDE7CXRQDXZTQJBY5YY/

[ovirt-users] Re: Gluster Deployment hangs on enabling or disabling chronyd service

[Gobinda Das]

Hi Sakhi,
 Can you please provide engine log and ovirt-host-deploy log ? You
mentioned that, you have attached log but unfortunately I can't find the
attachment.

On Tue, Jul 17, 2018 at 3:12 PM, Sakhi Hadebe  wrote:

> Hi,
>
> Why is gluster deployment hangs on enabling or disabling the chronyd
> service? I have enabled passwordless ssh to access itself and other two
> nodes.
>
> What would be the solution to get it pass this stage?
>
> On Fri, Jul 13, 2018 at 10:41 AM, Sakhi Hadebe  wrote:
>
>> Hi,
>>
>> We are running the following setup:
>>
>> ovirt-engine:
>> - CentOS Linux release 7.5.1804 (Core)
>> - ovirt-engine-4.2.4.5-1.el7.noarch
>>
>> node (trying to add):
>> - CentOS Linux release 7.5.1804 (Core)
>> - vdsm-4.20.32-1.el7.x86_64
>>
>> - ovirt-release42-4.2.4-1.el7.noarch
>>
>>
>> We successfully added the second node to the Cluster. Two nodes that have 
>> been successfully added are running ovirt-node-4.2.4.
>>
>> ovirt-node-ng-image-update-placeholder-4.2.4-1.el7.noarch
>> ovirt-node-ng-nodectl-4.2.0-0.20180626.0.el7.noarch
>> ovirt-provider-ovn-driver-1.2.11-1.el7.noarchovirt-release42-4.2.4-1.el7.noarch
>> ovirt-release-host-node-4.2.4-1.el7.noarch
>>
>> While adding a new node to our cluster the installations fail.
>>
>> I have attached a piece of engine.log and a full ovirt-host-deploy logs of 
>> the failing node from the engine.
>> Help would be very much appreciated.
>>
>>
>> --
>> Regards,
>> Sakhi Hadebe
>>
>>
>
>
> --
> Regards,
> Sakhi Hadebe
>
> Engineer: South African National Research Network (SANReN)Competency Area, 
> Meraka, CSIR
>
> Tel:   +27 12 841 2308 <+27128414213>
> Fax:   +27 12 841 4223 <+27128414223>
> Cell:  +27 71 331 9622 <+27823034657>
> Email: sa...@sanren.ac.za 
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/KBMRRUJWHZZGWBKFLOC5MXYQWGNUATSN/
>
>


-- 
Thanks,
Gobinda
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/AU4EHLJAGSA7MD7SH7HKE2E2XJOY63YN/

[ovirt-users] isolated-privatevlan vdsm hook

[g . vasilopoulos]

How does this filter work ? 
Do I have to set a custom property on the engine ?
Should I add clean traffic on vnic profile and then add GATEWAY_MAC and IP ?
is there a way to select it on a specific vm? 

I installed the hook on one hook restarted the engine put the host in 
maintenance restarted libvirt exited the host from maintenance.
I put the host on maintenance removed the hook. Restarted the host. The message 
keeps popping up
Now I have a message "Finished activating host" popping up a lot of times, 
maybe a 100 times..
Should I reinstall the specific host ?
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/74ZN4ML7TVGXZGCZKCBCABFOCD56TEHM/

[ovirt-users] Re: oVirt Metrics

[g . vasilopoulos]

Very usefull information thank you!
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/CK7LRV6JNB6M6SJ2BIH2Z4EY6D7YYC7B/

[ovirt-users] Re: oVirt Metrics

[g . vasilopoulos]

Very usefull information thank you
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/MBZ7AJCSM7NNZ2C25QVWOOIMBUWJZH5E/

[ovirt-users] Re: oVirt node not installed

[Qin Yuan]

The error said "Looks like the system already has imgbase working properly."

Did you clean up your disks before installation?

On Mon, Jul 16, 2018 at 4:16 PM, Spickiy Nikita 
wrote:

> Hi, i try install oVirt node, but getting errors on step post-install
> script. Screen error in attachment.
>
>
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/2NAYW6CR72YP6ADQMCID7ANH2D756WZT/
>
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/4PB4GUT4A6Q7MP4BTYIKLT4D2FGC5K5J/

[ovirt-users] Re: Disk Statistics API in Ovirt

[Hari Prasanth Loganathan]

Hi Guys,

I think it is a serious issue, please let us know your thoughts?


On Tue, Jul 17, 2018 at 3:27 PM, Hari Prasanth Loganathan <
hariprasant...@msystechnologies.com> wrote:

> Hi Team,
>
> We are using the following API to collect the disk statistics,
>
> https://X.X.X.2/ovirt-engine/api/
> *disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics*
> 
>
> I found one issue in the disk statistics. In case If the Virtual Machine
> has this disk (*2331bad7-71ec-4fad-95bb-2b3449f3dbda*) attached to it and
> I perform some read / write operation in the VM and it increases the
> corresponding disk level Read data rate / Write data rate /
> disk.read.latency / disk.write.latency.
>
> *Example*, I received the following values for this disk, But the problem
> is even when I bring down the VM still the last known value is received
> continuously.
> *Is it a known issue Or any workaround is available? *
>
> *Expected : All values should go to Zero*
>
> *Actual : All values retains the last known values when the VM was in UP
> state. *
>
>
> {
> "statistic": [
> {
> "kind": "gauge",
> "type": "decimal",
> "unit": "bytes_per_second",
> "values": {
> "value": [
> {
> "datum": 2184
> }
> ]
> },
> "disk": {
> "href": "/ovirt-engine/api/disks/2331b
> ad7-71ec-4fad-95bb-2b3449f3dbda",
> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
> },
> "name": "data.current.read",
> "description": "Read data rate",
> "href": "/ovirt-engine/api/disks/2331b
> ad7-71ec-4fad-95bb-2b3449f3dbda/statistics/33b9212b-f9cb-
> 3fd0-b364-248fb61e1272",
> "id": "33b9212b-f9cb-3fd0-b364-248fb61e1272"
> },
> {
> "kind": "gauge",
> "type": "decimal",
> "unit": "bytes_per_second",
> "values": {
> "value": [
> {
> "datum": 41202005
> }
> ]
> },
> "disk": {
> "href": "/ovirt-engine/api/disks/2331b
> ad7-71ec-4fad-95bb-2b3449f3dbda",
> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
> },
> "name": "data.current.write",
> "description": "Write data rate",
> "href": "/ovirt-engine/api/disks/2331b
> ad7-71ec-4fad-95bb-2b3449f3dbda/statistics/2f23addd-4ebd-
> 3d82-a449-c28778bc33eb",
> "id": "2f23addd-4ebd-3d82-a449-c28778bc33eb"
> },
> {
> "kind": "gauge",
> "type": "decimal",
> "unit": "seconds",
> "values": {
> "value": [
> {
> "datum": 0.12
> }
> ]
> },
> "disk": {
> "href": "/ovirt-engine/api/disks/2331b
> ad7-71ec-4fad-95bb-2b3449f3dbda",
> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
> },
> "name": "disk.read.latency",
> "description": "Read latency",
> "href": "/ovirt-engine/api/disks/2331b
> ad7-71ec-4fad-95bb-2b3449f3dbda/statistics/3a7b3f72-d035-
> 3bb9-b196-e86a4eb34993",
> "id": "3a7b3f72-d035-3bb9-b196-e86a4eb34993"
> },
> {
> "kind": "gauge",
> "type": "decimal",
> "unit": "seconds",
> "values": {
> "value": [
> {
> "datum": 1.4
> }
> ]
> },
> "disk": {
> "href": "/ovirt-engine/api/disks/2331b
> ad7-71ec-4fad-95bb-2b3449f3dbda",
> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
> },
> "name": "disk.write.latency",
> "description": "Write latency",
> "href": "/ovirt-engine/api/disks/2331b
> ad7-71ec-4fad-95bb-2b3449f3dbda/statistics/b1e75c7b-cea4-
> 37d2-8459-f7d68efc69a3",
> "id": "b1e75c7b-cea4-37d2-8459-f7d68efc69a3"
> },
> {
> "kind": "gauge",
> "type": "decimal",
> "unit": "seconds",
> "values": {
> "value": [
> {
> "datum": 0
> }
> ]
> },
> "disk": {
> "href": "/ovirt-engine/api/disks/2331b
> ad7-71ec-4fad-95bb-2b3449f3dbda",
> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
> },
> "name": "disk.flush.latency",
> "description": "Flush latency",
> "href": "/ovirt-engine/api/disks/2331b
> 

[ovirt-users] Disk Statistics API in Ovirt

[Hari Prasanth Loganathan]

Hi Team,

We are using the following API to collect the disk statistics,

https://X.X.X.2/ovirt-engine/api/
*disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics*


I found one issue in the disk statistics. In case If the Virtual Machine
has this disk (*2331bad7-71ec-4fad-95bb-2b3449f3dbda*) attached to it and I
perform some read / write operation in the VM and it increases the
corresponding disk level Read data rate / Write data rate /
disk.read.latency / disk.write.latency.

*Example*, I received the following values for this disk, But the problem
is even when I bring down the VM still the last known value is received
continuously.
*Is it a known issue Or any workaround is available? *

*Expected : All values should go to Zero*

*Actual : All values retains the last known values when the VM was in UP
state. *


{
"statistic": [
{
"kind": "gauge",
"type": "decimal",
"unit": "bytes_per_second",
"values": {
"value": [
{
"datum": 2184
}
]
},
"disk": {
"href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
2b3449f3dbda",
"id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
},
"name": "data.current.read",
"description": "Read data rate",
"href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
2b3449f3dbda/statistics/33b9212b-f9cb-3fd0-b364-248fb61e1272",
"id": "33b9212b-f9cb-3fd0-b364-248fb61e1272"
},
{
"kind": "gauge",
"type": "decimal",
"unit": "bytes_per_second",
"values": {
"value": [
{
"datum": 41202005
}
]
},
"disk": {
"href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
2b3449f3dbda",
"id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
},
"name": "data.current.write",
"description": "Write data rate",
"href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
2b3449f3dbda/statistics/2f23addd-4ebd-3d82-a449-c28778bc33eb",
"id": "2f23addd-4ebd-3d82-a449-c28778bc33eb"
},
{
"kind": "gauge",
"type": "decimal",
"unit": "seconds",
"values": {
"value": [
{
"datum": 0.12
}
]
},
"disk": {
"href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
2b3449f3dbda",
"id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
},
"name": "disk.read.latency",
"description": "Read latency",
"href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
2b3449f3dbda/statistics/3a7b3f72-d035-3bb9-b196-e86a4eb34993",
"id": "3a7b3f72-d035-3bb9-b196-e86a4eb34993"
},
{
"kind": "gauge",
"type": "decimal",
"unit": "seconds",
"values": {
"value": [
{
"datum": 1.4
}
]
},
"disk": {
"href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
2b3449f3dbda",
"id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
},
"name": "disk.write.latency",
"description": "Write latency",
"href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
2b3449f3dbda/statistics/b1e75c7b-cea4-37d2-8459-f7d68efc69a3",
"id": "b1e75c7b-cea4-37d2-8459-f7d68efc69a3"
},
{
"kind": "gauge",
"type": "decimal",
"unit": "seconds",
"values": {
"value": [
{
"datum": 0
}
]
},
"disk": {
"href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
2b3449f3dbda",
"id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
},
"name": "disk.flush.latency",
"description": "Flush latency",
"href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
2b3449f3dbda/statistics/9c17ad7b-9ef1-3e8d-ad0a-ff8bee3925f0",
"id": "9c17ad7b-9ef1-3e8d-ad0a-ff8bee3925f0"
}
]
}

Thanks,
Hari

-- 


DISCLAIMER - *MSysTechnologies LLC* 



This email message, contents and 
its attachments may contain confidential, proprietary or legally privileged 
information and is intended solely for the use of the individual or entity 
to whom it is actually intended. If you have erroneously received this 
message, 

[ovirt-users] Re: Disk Statistics API in oVirt

[Hari Prasanth Loganathan]

It is an issue from our side. Please ignore my question.

But How frequently we will collect the disk statistics and update in
PostgreSQL?

Thanks,
Hari

On Tue, Jul 17, 2018 at 3:18 PM, Hari Prasanth Loganathan <
hariprasant...@msystechnologies.com> wrote:

> Hi Team,
>
> We are using the following API to collect the disk statistics,
>
> https://X.X.X.2/ovirt-engine/api/
> *disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics*
> 
>
> I found one issue in the disk statistics. In case If the Virtual Machine
> has this disk (*2331bad7-71ec-4fad-95bb-2b3449f3dbda*) attached to it and
> I perform some read / write operation in the VM and it increases the
> corresponding disk level Read data rate / Write data rate /
> disk.read.latency / disk.write.latency.
>
> *Example*, I received the following values for this disk, But the problem
> is even when I bring down the VM still the last known value is received
> continuously.
> *Is it a known issue Or any workaround is available? *
>
> *Expected : All values should go to Zero*
>
> *Actual : All values retains the last known values when the VM was in UP
> state. *
>
>
> {
> "statistic": [
> {
> "kind": "gauge",
> "type": "decimal",
> "unit": "bytes_per_second",
> "values": {
> "value": [
> {
> "datum": 2184
> }
> ]
> },
> "disk": {
> "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
> 2b3449f3dbda",
> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
> },
> "name": "data.current.read",
> "description": "Read data rate",
> "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
> 2b3449f3dbda/statistics/33b9212b-f9cb-3fd0-b364-248fb61e1272",
> "id": "33b9212b-f9cb-3fd0-b364-248fb61e1272"
> },
> {
> "kind": "gauge",
> "type": "decimal",
> "unit": "bytes_per_second",
> "values": {
> "value": [
> {
> "datum": 41202005
> }
> ]
> },
> "disk": {
> "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
> 2b3449f3dbda",
> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
> },
> "name": "data.current.write",
> "description": "Write data rate",
> "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
> 2b3449f3dbda/statistics/2f23addd-4ebd-3d82-a449-c28778bc33eb",
> "id": "2f23addd-4ebd-3d82-a449-c28778bc33eb"
> },
> {
> "kind": "gauge",
> "type": "decimal",
> "unit": "seconds",
> "values": {
> "value": [
> {
> "datum": 0.12
> }
> ]
> },
> "disk": {
> "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
> 2b3449f3dbda",
> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
> },
> "name": "disk.read.latency",
> "description": "Read latency",
> "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
> 2b3449f3dbda/statistics/3a7b3f72-d035-3bb9-b196-e86a4eb34993",
> "id": "3a7b3f72-d035-3bb9-b196-e86a4eb34993"
> },
> {
> "kind": "gauge",
> "type": "decimal",
> "unit": "seconds",
> "values": {
> "value": [
> {
> "datum": 1.4
> }
> ]
> },
> "disk": {
> "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
> 2b3449f3dbda",
> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
> },
> "name": "disk.write.latency",
> "description": "Write latency",
> "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
> 2b3449f3dbda/statistics/b1e75c7b-cea4-37d2-8459-f7d68efc69a3",
> "id": "b1e75c7b-cea4-37d2-8459-f7d68efc69a3"
> },
> {
> "kind": "gauge",
> "type": "decimal",
> "unit": "seconds",
> "values": {
> "value": [
> {
> "datum": 0
> }
> ]
> },
> "disk": {
> "href": "/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-
> 2b3449f3dbda",
> "id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
> },
> "name": "disk.flush.latency",
> "description": "Flush latency",
> "href": 

[ovirt-users] Disk Statistics API in oVirt

[Hari Prasanth Loganathan]

Hi Team,

We are using the following API to collect the disk statistics,

https://X.X.X.2/ovirt-engine/api/
*disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics*


I found one issue in the disk statistics. In case If the Virtual Machine
has this disk (*2331bad7-71ec-4fad-95bb-2b3449f3dbda*) attached to it and I
perform some read / write operation in the VM and it increases the
corresponding disk level Read data rate / Write data rate /
disk.read.latency / disk.write.latency.

*Example*, I received the following values for this disk, But the problem
is even when I bring down the VM still the last known value is received
continuously.
*Is it a known issue Or any workaround is available? *

*Expected : All values should go to Zero*

*Actual : All values retains the last known values when the VM was in UP
state. *


{
"statistic": [
{
"kind": "gauge",
"type": "decimal",
"unit": "bytes_per_second",
"values": {
"value": [
{
"datum": 2184
}
]
},
"disk": {
"href":
"/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda",
"id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
},
"name": "data.current.read",
"description": "Read data rate",
"href":
"/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics/33b9212b-f9cb-3fd0-b364-248fb61e1272",
"id": "33b9212b-f9cb-3fd0-b364-248fb61e1272"
},
{
"kind": "gauge",
"type": "decimal",
"unit": "bytes_per_second",
"values": {
"value": [
{
"datum": 41202005
}
]
},
"disk": {
"href":
"/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda",
"id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
},
"name": "data.current.write",
"description": "Write data rate",
"href":
"/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics/2f23addd-4ebd-3d82-a449-c28778bc33eb",
"id": "2f23addd-4ebd-3d82-a449-c28778bc33eb"
},
{
"kind": "gauge",
"type": "decimal",
"unit": "seconds",
"values": {
"value": [
{
"datum": 0.12
}
]
},
"disk": {
"href":
"/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda",
"id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
},
"name": "disk.read.latency",
"description": "Read latency",
"href":
"/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics/3a7b3f72-d035-3bb9-b196-e86a4eb34993",
"id": "3a7b3f72-d035-3bb9-b196-e86a4eb34993"
},
{
"kind": "gauge",
"type": "decimal",
"unit": "seconds",
"values": {
"value": [
{
"datum": 1.4
}
]
},
"disk": {
"href":
"/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda",
"id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
},
"name": "disk.write.latency",
"description": "Write latency",
"href":
"/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics/b1e75c7b-cea4-37d2-8459-f7d68efc69a3",
"id": "b1e75c7b-cea4-37d2-8459-f7d68efc69a3"
},
{
"kind": "gauge",
"type": "decimal",
"unit": "seconds",
"values": {
"value": [
{
"datum": 0
}
]
},
"disk": {
"href":
"/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda",
"id": "2331bad7-71ec-4fad-95bb-2b3449f3dbda"
},
"name": "disk.flush.latency",
"description": "Flush latency",
"href":
"/ovirt-engine/api/disks/2331bad7-71ec-4fad-95bb-2b3449f3dbda/statistics/9c17ad7b-9ef1-3e8d-ad0a-ff8bee3925f0",
"id": "9c17ad7b-9ef1-3e8d-ad0a-ff8bee3925f0"
}
]
}

Thanks,
Hari

-- 


DISCLAIMER - *MSysTechnologies LLC* 



This email message, contents and 
its attachments may contain confidential, proprietary or legally privileged 
information and is intended solely for the use of the individual or entity 
to whom it is actually intended. If you have erroneously received this 
message, please 

[ovirt-users] Gluster Deployment hangs on enabling or disabling chronyd service

[Sakhi Hadebe]

Hi,

Why is gluster deployment hangs on enabling or disabling the chronyd
service? I have enabled passwordless ssh to access itself and other two
nodes.

What would be the solution to get it pass this stage?

On Fri, Jul 13, 2018 at 10:41 AM, Sakhi Hadebe  wrote:

> Hi,
>
> We are running the following setup:
>
> ovirt-engine:
> - CentOS Linux release 7.5.1804 (Core)
> - ovirt-engine-4.2.4.5-1.el7.noarch
>
> node (trying to add):
> - CentOS Linux release 7.5.1804 (Core)
> - vdsm-4.20.32-1.el7.x86_64
>
> - ovirt-release42-4.2.4-1.el7.noarch
>
>
> We successfully added the second node to the Cluster. Two nodes that have 
> been successfully added are running ovirt-node-4.2.4.
>
> ovirt-node-ng-image-update-placeholder-4.2.4-1.el7.noarch
> ovirt-node-ng-nodectl-4.2.0-0.20180626.0.el7.noarch
> ovirt-provider-ovn-driver-1.2.11-1.el7.noarch
> ovirt-release42-4.2.4-1.el7.noarch
> ovirt-release-host-node-4.2.4-1.el7.noarch
>
> While adding a new node to our cluster the installations fail.
>
> I have attached a piece of engine.log and a full ovirt-host-deploy logs of 
> the failing node from the engine.
> Help would be very much appreciated.
>
>
> --
> Regards,
> Sakhi Hadebe
>
>


-- 
Regards,
Sakhi Hadebe

Engineer: South African National Research Network (SANReN)Competency
Area, Meraka, CSIR

Tel:   +27 12 841 2308 <+27128414213>
Fax:   +27 12 841 4223 <+27128414223>
Cell:  +27 71 331 9622 <+27823034657>
Email: sa...@sanren.ac.za 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/KBMRRUJWHZZGWBKFLOC5MXYQWGNUATSN/

[ovirt-users] Re: Issue when updating node to 4.2.4

[Callum Smith]

Dear all,

Has anyone else experienced these issues or are the exclusive to these nodes? 
I'd rather avoid re-installing them as a work-around if possible.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 12 Jul 2018, at 12:13, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Error in the scripts as part of doing a yum update on the host:


/var/log/messages
Jul 12 12:07:00 virtA003 imgbased: 2018-07-12 12:07:00,170 [INFO] (MainThread) 
Extracting image 
'/usr/share/ovirt-node-ng/image//ovirt-node-ng-4.2.0-0.20180626.0.el7.squashfs.img'
Jul 12 12:07:00 virtA003 kernel: EXT4-fs (loop3): mounted filesystem with 
ordered data mode. Opts: (null)
Jul 12 12:07:00 virtA003 imgbased: 2018-07-12 12:07:00,295 [INFO] (MainThread) 
Starting base creation
Jul 12 12:07:00 virtA003 imgbased: 2018-07-12 12:07:00,295 [INFO] (MainThread) 
New base will be: ovirt-node-ng-4.2.4-0.20180626.0
Jul 12 12:07:00 virtA003 python: detected unhandled Python exception in 
'/tmp/tmp.awWEfeJStR/usr/lib/python2.7/site-packages/imgbased/__main__.py'
Jul 12 12:07:00 virtA003 abrt-server: Executable 
'/tmp/tmp.awWEfeJStR/usr/lib/python2.7/site-packages/imgbased/__main__.py' 
doesn't belong to any package and ProcessUnpackaged is set to 'no'
Jul 12 12:07:00 virtA003 abrt-server: 'post-create' on 
'/var/tmp/abrt/Python-2018-07-12-12:07:00-4688' exited with 1
Jul 12 12:07:00 virtA003 abrt-server: Deleting problem directory 
'/var/tmp/abrt/Python-2018-07-12-12:07:00-4688'
Jul 12 12:07:00 virtA003 yum[4558]: Updated: 
ovirt-node-ng-image-update-4.2.4-1.el7.noarch

/tmp/imgbased.log

2018-07-12 12:07:00,166 [DEBUG] (MainThread) Version: imgbased-1.0.20
2018-07-12 12:07:00,170 [DEBUG] (MainThread) Arguments: 
Namespace(FILENAME='/usr/share/ovirt-node-ng/image//ovirt-node-ng-4.2.0-0.20180626.0.el7.squashfs.img',
 command='update', debug=True, experimental=False, format='liveimg', 
stream='Image')
2018-07-12 12:07:00,170 [INFO] (MainThread) Extracting image 
'/usr/share/ovirt-node-ng/image//ovirt-node-ng-4.2.0-0.20180626.0.el7.squashfs.img'
2018-07-12 12:07:00,170 [DEBUG] (MainThread) Calling binary: (['mktemp', '-d', 
'--tmpdir', 'mnt.X'],) {}
2018-07-12 12:07:00,170 [DEBUG] (MainThread) Calling: (['mktemp', '-d', 
'--tmpdir', 'mnt.X'],) {'close_fds': True, 'stderr': -2}
2018-07-12 12:07:00,173 [DEBUG] (MainThread) Returned: /tmp/mnt.qTRik
2018-07-12 12:07:00,173 [DEBUG] (MainThread) Calling binary: (['mount', 
'/usr/share/ovirt-node-ng/image//ovirt-node-ng-4.2.0-0.20180626.0.el7.squashfs.img',
 u'/tmp/mnt.qTRik'],) {}
2018-07-12 12:07:00,174 [DEBUG] (MainThread) Calling: (['mount', 
'/usr/share/ovirt-node-ng/image//ovirt-node-ng-4.2.0-0.20180626.0.el7.squashfs.img',
 u'/tmp/mnt.qTRik'],) {'close_fds': True, 'stderr': -2}
2018-07-12 12:07:00,180 [DEBUG] (MainThread) Returned:
2018-07-12 12:07:00,180 [DEBUG] (MainThread) Mounted squashfs
2018-07-12 12:07:00,180 [DEBUG] (MainThread) Found fsimage at 
'/tmp/mnt.qTRik/LiveOS/rootfs.img'
2018-07-12 12:07:00,180 [DEBUG] (MainThread) Calling binary: (['mktemp', '-d', 
'--tmpdir', 'mnt.X'],) {}
2018-07-12 12:07:00,181 [DEBUG] (MainThread) Calling: (['mktemp', '-d', 
'--tmpdir', 'mnt.X'],) {'close_fds': True, 'stderr': -2}
2018-07-12 12:07:00,184 [DEBUG] (MainThread) Returned: /tmp/mnt.SIk9q
2018-07-12 12:07:00,184 [DEBUG] (MainThread) Calling binary: (['mount', 
u'/tmp/mnt.qTRik/LiveOS/rootfs.img', u'/tmp/mnt.SIk9q'],) {}
2018-07-12 12:07:00,184 [DEBUG] (MainThread) Calling: (['mount', 
u'/tmp/mnt.qTRik/LiveOS/rootfs.img', u'/tmp/mnt.SIk9q'],) {'close_fds': True, 
'stderr': -2}
2018-07-12 12:07:00,199 [DEBUG] (MainThread) Returned:
2018-07-12 12:07:00,212 [DEBUG] (MainThread) Using nvr: 
ovirt-node-ng-4.2.4-0.20180626.0
2018-07-12 12:07:00,212 [DEBUG] (MainThread) Fetching image for '/'
2018-07-12 12:07:00,212 [DEBUG] (MainThread) Calling binary: (['findmnt', 
'--noheadings', '-o', 'SOURCE', '/'],) {}
2018-07-12 12:07:00,212 [DEBUG] (MainThread) Calling: (['findmnt', 
'--noheadings', '-o', 'SOURCE', '/'],) {'close_fds': True, 'stderr': -2}
2018-07-12 12:07:00,217 [DEBUG] (MainThread) Returned: 
/dev/mapper/onn_virta003-ovirt--node--ng--4.2.3.1--0.20180530.0+1
2018-07-12 12:07:00,218 [DEBUG] (MainThread) Found 
'/dev/mapper/onn_virta003-ovirt--node--ng--4.2.3.1--0.20180530.0+1'
2018-07-12 12:07:00,218 [DEBUG] (MainThread) Calling binary: (['lvs', 
'--noheadings', '--ignoreskippedcluster', '-ovg_name,lv_name', 
u'/dev/mapper/onn_virta003-ovirt--node--ng--4.2.3.1--0.20180530.0+1'],) 
{'stderr': }
2018-07-12 12:07:00,218 [DEBUG] (MainThread) Calling: (['lvs', '--noheadings', 
'--ignoreskippedcluster', '-ovg_name,lv_name', 
u'/dev/mapper/onn_virta003-ovirt--node--ng--4.2.3.1--0.20180530.0+1'],) 
{'close_fds': True, 'stderr': }
2018-07-12 12:07:00,248 [DEBUG] (MainThread) Returned: onn_virta003 
ovirt-node-ng-4.2.3.1-0.20180530.0+1
2018-07-12 12:07:00,248 [DEBUG] 

[ovirt-users] Re: Using the web-ui VM portal through a proxy failing

[Callum Smith]

Dear All,

Does anyone know how to set such options in the web-ui?

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

On 12 Jul 2018, at 11:09, Callum Smith 
mailto:cal...@well.ox.ac.uk>> wrote:

Dear oVirt Gurus,

Using the oVirt user VM portal seems to not work through the squid proxy setup 
(configured as per the guide). The page loads and login works fine through the 
proxy, but the asynchronous requests just hang. I've attached a screenshot, but 
you can see the "api" endpoint just hanging in a web inspector:
"https://proxyfqdn/ovirt-engine/api/;



This works fine when not going through the proxy.

Is there a way to force noVNC HTML as the console mode through the web-ui, or 
at least have it as an option if not default?

The console seems not to work when logged in with a base 'user role'.

Regards,
Callum

--

Callum Smith
Research Computing Core
Wellcome Trust Centre for Human Genetics
University of Oxford
e. cal...@well.ox.ac.uk

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to 
users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/VZIGGZZ2IIHBZ65QCX5PLB65DEMRQD4X/

___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/7NBOGYVL4EAH4QQI6ETPMFNXC5VSTZCP/

[ovirt-users] Re: oVirt Metrics

[Shirly Radco]

Hi,

I'm so happy you managed to get it working for you.
I'm aware of the ansible version issue and the Openshift team is working to
fix it.
Currently ansible 2.5.5 and 2.5.6 seem to be working ok.

Yes. You can add to the /etc/ovirt-engine-metrics/config.yml

collectd_interval: 20

(The default is 10 seconds)

And rerun
the 
/usr/share/ovirt-engine-metrics/setup/ansible/configure_ovirt_machines_for_metrics.sh
This will update the collection interval on all your machines.

In addition, If there are metrics you do not wish to collect you can update
the collectd config files in
/usr/share/ansible/roles/oVirt.metrics/roles/oVirt.ovirt-collectd/ovirt-host/templates/
and
/usr/share/ansible/roles/oVirt.metrics/roles/oVirt.ovirt-collectd/ovirt-engine/templates/

and rerun the
 
/usr/share/ovirt-engine-metrics/setup/ansible/configure_ovirt_machines_for_metrics.sh

We would like to add aggregations in the future for long term storage.
Currently we set the curator to save 3 days of metrics data. since metrics
consume lots of disk space.
Logs are kept for a month by default.
After that the curator deletes the old indexes.

You can update the curator but that will affect the disk size you will need.

This is the documentation for curator update and general info about curator:
https://docs.openshift.com/container-platform/3.9/install_config/aggregate_logging.html#configuring-curator
https://docs.openshift.com/container-platform/3.9/install_config/aggregate_logging.html#aggregate-logging-creating-the-curator-configuration

I hope this will help you.

Best regards,

--

SHIRLY RADCO

BI SENIOR SOFTWARE ENGINEER

Red Hat Israel 

TRIED. TESTED. TRUSTED. 

On Tue, Jul 17, 2018 at 9:04 AM,  wrote:

> I did set it up yesterday and I intent to use it. Setup worked ok on
> Centos 7.5. Only problem was with depency of ansible for
> centos-openshift-origin39-candidate, which I had to deactivate from
> repos. It did work though and I am getting reports now. Anyway is there a
> way to "relax" the amount of data collected, say make collection every 20
> seconds instead of 10 seconds (I think that is the default.) Is there a way
> to get keep data for specific amount of time say 1 year and then discard
> the older data and vacuum the database ?
>
> Thank you and redhat for all your efforts on providing such a fine product.
> Regards
> George Vasilopoulos
> ___
> Users mailing list -- users@ovirt.org
> To unsubscribe send an email to users-le...@ovirt.org
> Privacy Statement: https://www.ovirt.org/site/privacy-policy/
> oVirt Code of Conduct: https://www.ovirt.org/community/about/community-
> guidelines/
> List Archives: https://lists.ovirt.org/archives/list/users@ovirt.org/
> message/ZEMUFIGU46H5LHS5IIIR4M54YWJNYY7N/
>
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/3OENF54ILEGBHFPKNOO3QCT3BLC5HWKX/

[ovirt-users] Re: oVirt Metrics

[g . vasilopoulos]

I did set it up yesterday and I intent to use it. Setup worked ok on Centos 
7.5. Only problem was with depency of ansible for 
centos-openshift-origin39-candidate, which I had to deactivate from repos. It 
did work though and I am getting reports now. Anyway is there a way to "relax" 
the amount of data collected, say make collection every 20 seconds instead of 
10 seconds (I think that is the default.) Is there a way to get keep data for 
specific amount of time say 1 year and then discard the older data and vacuum 
the database ?

Thank you and redhat for all your efforts on providing such a fine product.
Regards 
George Vasilopoulos
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/site/privacy-policy/
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/ZEMUFIGU46H5LHS5IIIR4M54YWJNYY7N/