[ovirt-users] oVirt: Training, Webinars, Forums etc!!

2018-09-05 Thread femi adegoke 
Are there any plans for training's/webinars/workshops/documentation etc.

Anything to help learn, process more info & get more comfortable with oVirt?
___
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/OYWEGTOXABZBNZ2TBJL5QREC5WF34KKL/

[ovirt-users] Re: Info on HCI single host

2018-09-05 Thread femi adegoke 
Gobinda,

Any updates on this fix?
___
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/5L5EFEYREJ2ODTNXADKSQYOZXLV4NGD5/

[ovirt-users] Re: [ANN] oVirt 4.2.6 is now generally available

2018-09-05 Thread Nir Soffer 
On Wed, Sep 5, 2018 at 4:06 PM Fabrice Bacchella <
fabrice.bacche...@orange.fr> wrote:

>
>
> Le 3 sept. 2018 à 18:31, Nir Soffer  a écrit :
>
> On Mon, Sep 3, 2018 at 5:07 PM Fabrice Bacchella <
> fabrice.bacche...@orange.fr> wrote:
>
>> In the release notes, I see:
>>
>> • BZ 1622700 [downstream clone - 4.2.6] [RFE][Dalton] - Blacklist all
>> local disk in multipath on RHEL / RHEV Host (RHEL 7.5)
>> Feature:
>> Blacklist local devices in multipath.
>>
>> Reason:
>> multipath repeatedly logs irrelevant errors for local devices.
>>
>> Result:
>> Local devices are blacklisted, and no irrelevant errors are logged
>> anymore.
>>
>> What defines a local disk ? I'm using a SAN on SAS. For many peoples, SAS
>> is only for local disks, but that's not the case. Will other 4.2.6 will
>> detect that ?
>>
>
> We don't have any support for SAS.
>
>
> What you call SAS is any block device we might want to attach directly and
> let oVirt manage. I was doing the same thing on old HPE hardware, using old
> smart array controlers. I gave the raw device to ovirt. After an upgrade,
> it fails as it was
> blacklisted. I need to add it  to the blacklist exceptions:
>
> cat /etc/multipath/conf.d/enable-sas.conf
> blacklist_exceptions {
> protocol "cciss"
> }
>
> I think your default rule is quite hard, and can brake many existing setup:
>
> multipathd show blacklist
> ...
> protocol rules:
> - blacklist:
> (config file rule) .*
> - exceptions:
> (config file rule) (scsi:fcp|scsi:iscsi)
> (config file rule) cciss  <-- mine
>

Thanks for this info.

Yes, our current default is too naive. The next 4.2.6 build
will remove this blacklist or replace it with a better one that
will not break existing setups.

See:
- https://gerrit.ovirt.org/c/94190/
- https://gerrit.ovirt.org/c/94168/

It would be helpful if you can test the next build before we release,
since we don't have your particular storage in our lab.

Nir
___
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/FOZHZR65LPIEVICB56PJGXP2DRTRWSAO/

[ovirt-users] Re: OVN and impact of missing connectivity with OVN Provider/Central

2018-09-05 Thread Gianluca Cecchi 
On Wed, Sep 5, 2018 at 1:05 PM Miguel Duarte de Mora Barroso <
mdbarr...@redhat.com> wrote:

> Hi Gianluca,
>
> I really don't think it should.
>
>
Hi Miguel,
thanks for your feedback.
Actually my doubts and my question originate from a particular failure
detected.
I'm going to explain better the environment.
I have two hypervisors hv1 and hv2 with oVirt 4.2.5. They are placed into 2
different racks, rack1 and rack2.
I have a virtual cluster used for testing/scalability purposes, composed
by 4 pacemaker/corosync nodes with CentOS 7.4 as OS.
2 nodes (cl1 and cl2) of this virtual cluster are VMs running on hv1 and 2
nodes (cl3 and cl4) are VMs unning on hv2.
hv1 is in rack1 and hv2 is in rack2
They simulate possible future scenario of a physical stretched cluster with
2 nodes in datacenter1 and 2 nodes in datacenter 2.
Due to a network problem rack1 has been isolated for about 1 minute.

What I registered in /var/log/messages of cl* has been this one below:

. cl1
Aug 31 14:53:33 cl1 corosync[1291]: [TOTEM ] A processor failed, forming
new configuration.
Aug 31 14:53:36 cl1 corosync[1291]: [TOTEM ] A new membership (
172.16.1.68:436) was formed. Members left: 4 2 3
Aug 31 14:53:36 cl1 corosync[1291]: [TOTEM ] Failed to receive the leave
message. failed: 4 2 3

. cl2
Aug 31 14:53:33 cl2 corosync[32749]: [TOTEM ] A processor failed, forming
new configuration.
Aug 31 14:53:36 cl2 corosync[32749]: [TOTEM ] A new membership (
172.16.1.69:436) was formed. Members left: 4 1 3
Aug 31 14:53:36 cl2 corosync[32749]: [TOTEM ] Failed to receive the leave
message. failed: 4 1 3

- cl3
Aug 31 14:53:33 cl3 corosync[1282]: [TOTEM ] A processor failed, forming
new configuration.
Aug 31 14:54:10 cl3 corosync[1282]: [TOTEM ] A new membership (
172.16.1.63:432) was formed. Members left: 1 2
Aug 31 14:54:10 cl3 corosync[1282]: [TOTEM ] Failed to receive the leave
message. failed: 1 2

- cl4
Aug 31 14:53:33 cl4 corosync[1295]: [TOTEM ] A processor failed, forming
new configuration.
Aug 31 14:54:10 cl4 corosync[1295]: [TOTEM ] A new membership (
172.16.1.63:432) was formed. Members left: 1 2
Aug 31 14:54:10 cl4 corosync[1295]: [TOTEM ] Failed to receive the leave
message. failed: 1 2

The intracluster of this virtual cluster is on OVN and the isolation of
rack1 caused the virtual nodes inside hv1 not to be able to see any of the
other nodes, including the other VM running inside the same hypervisor
So cl1 lost 2, 3 and 4; cl2 lost 1, 3 and 4
While both cl3 and cl4 only lost 1 and 2
I supposed that due to the isolation of hv1 the VMs cl1 and cl2 able to see
each other over their OVN based vnic.

Just for reference the node hv1 (real hostname ov200) got these messages
(storage domains are on iSCSI, so unaccessible during the rack1 isolation):

Aug 31 14:53:04 ov200 ovn-controller: ovs|26823|reconnect|ERR|ssl:
10.4.192.49:6642: no response to inactivity probe after 5 seconds,
disconnecting
Aug 31 14:53:11 ov200 kernel: connection2:0: ping timeout of 5 secs
expired, recv timeout 5, last rx 4562746767, last ping 4562751768, now
4562756784
Aug 31 14:53:11 ov200 kernel: connection1:0: ping timeout of 5 secs
expired, recv timeout 5, last rx 4562746768, last ping 4562751770, now
4562756784
Aug 31 14:53:11 ov200 kernel: connection1:0: detected conn error (1022)
Aug 31 14:53:11 ov200 kernel: connection2:0: detected conn error (1022)
Aug 31 14:53:11 ov200 iscsid: Kernel reported iSCSI connection 1:0 error
(1022 - Invalid or unknown error code) state (3)
Aug 31 14:53:11 ov200 iscsid: Kernel reported iSCSI connection 2:0 error
(1022 - Invalid or unknown error code) state (3)
. . .
Aug 31 14:54:04 ov200 multipathd: 8:32: reinstated
Aug 31 14:54:04 ov200 kernel: device-mapper: multipath: Reinstating path
8:32.
Aug 31 14:54:04 ov200 multipathd: 36090a0d88034667163b315f8c906b0ac:
remaining active paths: 2


>
> Could you provide the output of 'ovs-ofctl dump-flows br-int' *before*
> and *after* engine is shutdown ?
>
>
Unfortunately not.
If it can help verify current situation with all ok and cl1 and cl2 running
on hv1, here it is the output on hv1:
https://drive.google.com/file/d/1gLtpkKFCBXV46lXJYsMlbonp853EqLun/view?usp=sharing

My question regarding engine originated because as a side effect of rack1
isolation, the engine, that is a VM in another environment and configured
as the OVN provider, has been unreachable for about 1 minute during the
problem. And I saw the first line of ov200 log above:

Aug 31 14:53:04 ov200 ovn-controller: ovs|26823|reconnect|ERR|ssl:
10.4.192.49:6642: no response to inactivity probe after 5 seconds,
disconnecting



> Also outputs to 'ovs-vsctl show' and 'ovs-ofctl show br-int' . Also
> before and after engine-shutdown.
>

Now where all is ok and cl1 and cl2 running on hv1:
 # ovs-vsctl show
0c8ccaa3-b215-4860-8102-0ea7a24ebcaf
Bridge br-int
fail_mode: secure
Port "ovn-8eea86-0"
Interface "ovn-8eea86-0"
type: geneve
options: {csum="true", key=flow,

[ovirt-users] Re: [ANN] oVirt 4.2.6 is now generally available

2018-09-05 Thread Fabrice Bacchella 


> Le 3 sept. 2018 à 18:31, Nir Soffer  a écrit :
> 
> On Mon, Sep 3, 2018 at 5:07 PM Fabrice Bacchella  > wrote:
> In the release notes, I see:
> 
> • BZ 1622700 [downstream clone - 4.2.6] [RFE][Dalton] - Blacklist all local 
> disk in multipath on RHEL / RHEV Host (RHEL 7.5)
> Feature:
> Blacklist local devices in multipath. 
> 
> Reason: 
> multipath repeatedly logs irrelevant errors for local devices.
> 
> Result: 
> Local devices are blacklisted, and no irrelevant errors are logged anymore.
> 
> What defines a local disk ? I'm using a SAN on SAS. For many peoples, SAS is 
> only for local disks, but that's not the case. Will other 4.2.6 will detect 
> that ?
> 
> We don't have any support for SAS.
> 

What you call SAS is any block device we might want to attach directly and let 
oVirt manage. I was doing the same thing on old HPE hardware, using old smart 
array controlers. I gave the raw device to ovirt. After an upgrade, it fails as 
it was
blacklisted. I need to add it  to the blacklist exceptions:

cat /etc/multipath/conf.d/enable-sas.conf 
blacklist_exceptions {
protocol "cciss"
}

I think your default rule is quite hard, and can brake many existing setup:

multipathd show blacklist
...
protocol rules:
- blacklist:
(config file rule) .*
- exceptions:
(config file rule) (scsi:fcp|scsi:iscsi)
(config file rule) cciss  <-- mine

 

___
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/LBMFW6QF44VBW3MYRF6WBYWS5CCSMIRK/

[ovirt-users] Re: Engine Setup Error

2018-09-05 Thread Simone Tiraboschi 
Can you please check if on your host you have /var/log/ovirt-imageio-daemon
and its ownership and permissions (it should be vdsm:kvm,700)?
Can you please report which version of  ovirt-imageio-daemon you are using?
We had a bug there but it has been fixed long time ago.

On Wed, Sep 5, 2018 at 12:04 PM Sakhi Hadebe  wrote:

> Sorry, I mistakenly send the email:
>
> Below is the output of:
> [root@glustermount ~]# systemctl status ovirt-imageio-daemon.service -l
> ● ovirt-imageio-daemon.service - oVirt ImageIO Daemon
>Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio-daemon.service;
> disabled; vendor preset: disabled)
>Active: failed (Result: start-limit) since Tue 2018-09-04 16:55:16
> SAST; 19h ago
> Condition: start condition failed at Wed 2018-09-05 11:56:46 SAST; 2min 9s
> ago
>ConditionPathExists=/etc/pki/vdsm/certs/vdsmcert.pem was not met
>   Process: 11345 ExecStart=/usr/bin/ovirt-imageio-daemon (code=exited,
> status=1/FAILURE)
>  Main PID: 11345 (code=exited, status=1/FAILURE)
>
> Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt
> ImageIO Daemon.
> Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
> ovirt-imageio-daemon.service entered failed state.
> Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
> failed.
> Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
> holdoff time over, scheduling restart.
> Sep 04 16:55:16 glustermount.goku systemd[1]: start request repeated too
> quickly for ovirt-imageio-daemon.service
> Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt
> ImageIO Daemon.
> Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
> ovirt-imageio-daemon.service entered failed state.
> Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
> failed.
> [root@glustermount ~]# journalctl -xe -u ovirt-imageio-daemon.service
> Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: File
> "/usr/lib64/python2.7/logging/handlers.py",
> Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]:
> BaseRotatingHandler.__init__(self, filename, mode
> Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: File
> "/usr/lib64/python2.7/logging/handlers.py",
> Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]:
> logging.FileHandler.__init__(self, filename, mode
> Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: File
> "/usr/lib64/python2.7/logging/__init__.py",
> Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]:
> StreamHandler.__init__(self, self._open())
> Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: File
> "/usr/lib64/python2.7/logging/__init__.py",
> Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: stream =
> open(self.baseFilename, self.mode)
> Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: IOError:
> [Errno 2] No such file or directory: '/v
> Sep 04 16:55:16 glustermount.goku systemd[1]:
> ovirt-imageio-daemon.service: main process exited, code=exited, st
> Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt
> ImageIO Daemon.
> -- Subject: Unit ovirt-imageio-daemon.service has failed
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit ovirt-imageio-daemon.service has failed.
> --
> -- The result is failed.
> Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
> ovirt-imageio-daemon.service entered failed state.
> Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
> failed.
> Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
> holdoff time over, scheduling restart
> Sep 04 16:55:16 glustermount.goku systemd[1]: start request repeated too
> quickly for ovirt-imageio-daemon.servic
> Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt
> ImageIO Daemon.
> -- Subject: Unit ovirt-imageio-daemon.service has failed
> -- Defined-By: systemd
> -- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
> --
> -- Unit ovirt-imageio-daemon.service has failed.
> --
> -- The result is failed.
> Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
> ovirt-imageio-daemon.service entered failed state.
> Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
> failed.
>
>
> On Wed, Sep 5, 2018 at 12:01 PM, Sakhi Hadebe  wrote:
>
>> # systemctl status ovirt-imageio-daemon.service
>> ● ovirt-imageio-daemon.service - oVirt ImageIO Daemon
>>Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio-daemon.service;
>> disabled; vendor preset: disabled)
>>Active: failed (Result: start-limit) since Tue 2018-09-04 16:55:16
>> SAST; 19h ago
>> Condition: start condition failed at Wed 2018-09-05 11:56:46 SAST; 1min
>> 58s ago
>>ConditionPathExists=/etc/pki/vdsm/certs/vdsmcert.pem was not
>> met
>>   Process: 11345 ExecStart=/usr/bin/ovirt-imageio-daemon (code=exited,
>> status=1/FAILURE)
>>  Main PID: 11345

[ovirt-users] Re: OVN and impact of missing connectivity with OVN Provider/Central

2018-09-05 Thread Miguel Duarte de Mora Barroso 
Hi Gianluca,

I really don't think it should.

I've re-created that scenario - I didn't go as far as to stop the
engine, but stopped *all* of the ovn stuff running on it - and despite
that, the flows on the host were unaffected, and traffic kept flowing.

Could you provide the output of 'ovs-ofctl dump-flows br-int' *before*
and *after* engine is shutdown ?

Also outputs to 'ovs-vsctl show' and 'ovs-ofctl show br-int' . Also
before and after engine-shutdown.

All of the above on the host where the VMs are running.

Another question; is the OVN network you created an overlay, or is it
attached to a physical network?

Regards,
Miguel


On Tue, Sep 4, 2018 at 3:15 PM, Gianluca Cecchi
 wrote:
> Hello,
> I have VM1 and VM2 with their vnics on OVN.
> They are running on the same host.
> Suppose this host (and so its OVN Controller) looses connectivity with the
> OVN Provider (that in my case runs on oVirt engine, that is an external
> server).
> Is it correct/expected that VM1 looses connectivity with VM2 until fixed?
>
> So, in other words, is the OVN Provider a sort of single point of failure
> (eg if I restart enigine in my case)?
>
> Thanks,
> Gianluca
>
> ___
> 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/ESBKINTLKTWNQ2PXCCFSPQBHNK5ECSNO/
>
___
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/32M6CQSIJTSNYSY3HW5SFMDSLKQYTKLH/

[ovirt-users] Re: problem with multipath.conf

2018-09-05 Thread Fabrice Bacchella 
In almost the same configuration, the protocol was detected as being 
scsi:unspec, did you try that ?

> 
> Le 5 sept. 2018 à 10:23, g.vasilopou...@uoc.gr a écrit :
> 
> Thank you very much for your answer, somehow the exception did not work, but 
> I guess it is ok it is not a shared storage, it is a dual sas port external 
> JBOD box. I guess multipath is not really needed in that case
> ___
> 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/7AC3XX5SSIE26YT5Y2WVHKISDX6S7NAW/
___
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/YHTLASZXFA2OSOXL7UDRVCLL4RJ26A37/

[ovirt-users] Re: Engine Setup Error

2018-09-05 Thread Sakhi Hadebe 
Sorry, I mistakenly send the email:

Below is the output of:
[root@glustermount ~]# systemctl status ovirt-imageio-daemon.service -l
● ovirt-imageio-daemon.service - oVirt ImageIO Daemon
   Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio-daemon.service;
disabled; vendor preset: disabled)
   Active: failed (Result: start-limit) since Tue 2018-09-04 16:55:16 SAST;
19h ago
Condition: start condition failed at Wed 2018-09-05 11:56:46 SAST; 2min 9s
ago
   ConditionPathExists=/etc/pki/vdsm/certs/vdsmcert.pem was not met
  Process: 11345 ExecStart=/usr/bin/ovirt-imageio-daemon (code=exited,
status=1/FAILURE)
 Main PID: 11345 (code=exited, status=1/FAILURE)

Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt ImageIO
Daemon.
Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
ovirt-imageio-daemon.service entered failed state.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
failed.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
holdoff time over, scheduling restart.
Sep 04 16:55:16 glustermount.goku systemd[1]: start request repeated too
quickly for ovirt-imageio-daemon.service
Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt ImageIO
Daemon.
Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
ovirt-imageio-daemon.service entered failed state.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
failed.
[root@glustermount ~]# journalctl -xe -u ovirt-imageio-daemon.service
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: File
"/usr/lib64/python2.7/logging/handlers.py",
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]:
BaseRotatingHandler.__init__(self, filename, mode
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: File
"/usr/lib64/python2.7/logging/handlers.py",
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]:
logging.FileHandler.__init__(self, filename, mode
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: File
"/usr/lib64/python2.7/logging/__init__.py",
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]:
StreamHandler.__init__(self, self._open())
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: File
"/usr/lib64/python2.7/logging/__init__.py",
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: stream =
open(self.baseFilename, self.mode)
Sep 04 16:55:16 glustermount.goku ovirt-imageio-daemon[11345]: IOError:
[Errno 2] No such file or directory: '/v
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service:
main process exited, code=exited, st
Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt ImageIO
Daemon.
-- Subject: Unit ovirt-imageio-daemon.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ovirt-imageio-daemon.service has failed.
-- 
-- The result is failed.
Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
ovirt-imageio-daemon.service entered failed state.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
failed.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
holdoff time over, scheduling restart
Sep 04 16:55:16 glustermount.goku systemd[1]: start request repeated too
quickly for ovirt-imageio-daemon.servic
Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt ImageIO
Daemon.
-- Subject: Unit ovirt-imageio-daemon.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit ovirt-imageio-daemon.service has failed.
-- 
-- The result is failed.
Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
ovirt-imageio-daemon.service entered failed state.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
failed.


On Wed, Sep 5, 2018 at 12:01 PM, Sakhi Hadebe  wrote:

> # systemctl status ovirt-imageio-daemon.service
> ● ovirt-imageio-daemon.service - oVirt ImageIO Daemon
>Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio-daemon.service;
> disabled; vendor preset: disabled)
>Active: failed (Result: start-limit) since Tue 2018-09-04 16:55:16
> SAST; 19h ago
> Condition: start condition failed at Wed 2018-09-05 11:56:46 SAST; 1min
> 58s ago
>ConditionPathExists=/etc/pki/vdsm/certs/vdsmcert.pem was not
> met
>   Process: 11345 ExecStart=/usr/bin/ovirt-imageio-daemon (code=exited,
> status=1/FAILURE)
>  Main PID: 11345 (code=exited, status=1/FAILURE)
>
> Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt
> ImageIO Daemon.
> Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
> ovirt-imageio-daemon.service entered failed state.
> Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
> failed.
> Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
> holdoff time over, scheduling ...art.
> Sep 04 16:55:16 glustermount.goku systemd[1]: start request repeated

[ovirt-users] Re: Engine Setup Error

2018-09-05 Thread Sakhi Hadebe 
# systemctl status ovirt-imageio-daemon.service
● ovirt-imageio-daemon.service - oVirt ImageIO Daemon
   Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio-daemon.service;
disabled; vendor preset: disabled)
   Active: failed (Result: start-limit) since Tue 2018-09-04 16:55:16 SAST;
19h ago
Condition: start condition failed at Wed 2018-09-05 11:56:46 SAST; 1min 58s
ago
   ConditionPathExists=/etc/pki/vdsm/certs/vdsmcert.pem was not met
  Process: 11345 ExecStart=/usr/bin/ovirt-imageio-daemon (code=exited,
status=1/FAILURE)
 Main PID: 11345 (code=exited, status=1/FAILURE)

Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt ImageIO
Daemon.
Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
ovirt-imageio-daemon.service entered failed state.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
failed.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
holdoff time over, scheduling ...art.
Sep 04 16:55:16 glustermount.goku systemd[1]: start request repeated too
quickly for ovirt-imageio-daemon...vice
Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt ImageIO
Daemon.
Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
ovirt-imageio-daemon.service entered failed state.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
failed.
Hint: Some lines were ellipsized, use -l to show in full.
[root@glustermount ~]# systemctl status ovirt-imageio-daemon.service -l
● ovirt-imageio-daemon.service - oVirt ImageIO Daemon
   Loaded: loaded (/usr/lib/systemd/system/ovirt-imageio-daemon.service;
disabled; vendor preset: disabled)
   Active: failed (Result: start-limit) since Tue 2018-09-04 16:55:16 SAST;
19h ago
Condition: start condition failed at Wed 2018-09-05 11:56:46 SAST; 2min 9s
ago
   ConditionPathExists=/etc/pki/vdsm/certs/vdsmcert.pem was not met
  Process: 11345 ExecStart=/usr/bin/ovirt-imageio-daemon (code=exited,
status=1/FAILURE)
 Main PID: 11345 (code=exited, status=1/FAILURE)

Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt ImageIO
Daemon.
Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
ovirt-imageio-daemon.service entered failed state.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
failed.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
holdoff time over, scheduling restart.
Sep 04 16:55:16 glustermount.goku systemd[1]: start request repeated too
quickly for ovirt-imageio-daemon.service
Sep 04 16:55:16 glustermount.goku systemd[1]: Failed to start oVirt ImageIO
Daemon.
Sep 04 16:55:16 glustermount.goku systemd[1]: Unit
ovirt-imageio-daemon.service entered failed state.
Sep 04 16:55:16 glustermount.goku systemd[1]: ovirt-imageio-daemon.service
failed.

Output of:

On Wed, Sep 5, 2018 at 11:35 AM, Simone Tiraboschi 
wrote:

>
>
> On Wed, Sep 5, 2018 at 11:10 AM Sakhi Hadebe  wrote:
>
>> Hi All,
>>
>> The host deploy logs are showing the below errors:
>>
>> [root@garlic engine-logs-2018-09-05T08:48:22Z]# cat
>> /var/log/ovirt-hosted-engine-setup/engine-logs-2018-09-
>> 05T08\:34\:55Z/ovirt-engine/host-deploy/ovirt-host-deploy-
>> 20180905103605-garlic.sanren.ac.za-543b536b.log | grep -i error
>> 2018-09-05 10:35:46,909+0200 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV BASE/error=bool:'False'
>> 2018-09-05 10:35:47,116 [ERROR] __main__.py:8011:MainThread
>> @identity.py:145 - Reload of consumer identity cert
>> /etc/pki/consumer/cert.pem raised an exception with msg: [Errno 2] No such
>> file or directory: '/etc/pki/consumer/key.pem'
>> 2018-09-05 10:35:47,383+0200 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV BASE/error=bool:'False'
>> 2018-09-05 10:35:47,593 [ERROR] __main__.py:8011:MainThread
>> @identity.py:145 - Reload of consumer identity cert
>> /etc/pki/consumer/cert.pem raised an exception with msg: [Errno 2] No such
>> file or directory: '/etc/pki/consumer/key.pem'
>> 2018-09-05 10:35:48,245+0200 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV BASE/error=bool:'False'
>> Job for ovirt-imageio-daemon.service failed because the control process
>> exited with error code. See "systemctl status ovirt-imageio-daemon.service"
>> and "journalctl -xe" for details.
>> RuntimeError: Failed to start service 'ovirt-imageio-daemon'
>> 2018-09-05 10:36:05,098+0200 ERROR otopi.context
>> context._executeMethod:152 Failed to execute stage 'Closing up': Failed to
>> start service 'ovirt-imageio-daemon'
>> 2018-09-05 10:36:05,099+0200 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV BASE/error=bool:'True'
>> 2018-09-05 10:36:05,099+0200 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV BASE/exceptionInfo=list:'[(> 'exceptions.RuntimeError'>, RuntimeError("Failed to start service
>> 'ovirt-imageio-daemon'",), )]'
>> 2018-09-05 10:36:05,106+0200 DEBUG otopi.context
>> context.dumpEnvironment:869 ENV BASE/error=bool:'True'
>> 2018-09-05 10:36:05,106+0200 DEBUG otopi.context
>>

[ovirt-users] vm operation after host fence

2018-09-05 Thread Kapetanakis Giannis 
Hi,

Last night we have an incident of a failed host. Engine issued a fence but did 
not restart the vms running on that node on other operational hosts. I'd like 
to know if this is normal or I can tune it somehow.

Here are some relevant logs from engine:

2018-09-05 03:00:51,496+03 WARN  [org.ovirt.engine.core.vdsbroker.VdsManager] 
(EE-ManagedThreadFactory-engine-Thread-827644) [] Host 'v3' is not responding. 
It will stay in Connecting state for a grace period of 63 seconds and after 
that an attempt to fence the host will be issued.

2018-09-05 03:01:11,945+03 INFO  
[org.ovirt.engine.core.vdsbroker.monitoring.PollVmStatsRefresher] 
(EE-ManagedThreadFactory-engineScheduled-Thread-57) [] Failed to fetch vms info 
for host 'v3' - skipping VMs monitoring.
2018-09-05 03:01:48,028+03 WARN  
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(EE-ManagedThreadFactory-engine-Thread-827679) [] EVENT_ID: 
VM_SET_TO_UNKNOWN_STATUS(142), VM vm7 was set to the Unknown status.

2018-09-05 03:02:10,033+03 INFO  [org.ovirt.engine.core.bll.pm.StopVdsCommand] 
(EE-ManagedThreadFactory-engine-Thread-827680) [30369e01] Power-Management: 
STOP of host 'v3' initiated.

2018-09-05 03:02:55,935+03 INFO  
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(EE-ManagedThreadFactory-engine-Thread-827680) [3adcac38] EVENT_ID: 
VM_WAS_SET_DOWN_DUE_TO_HOST_REBOOT_OR_MANUAL_FENCE(143), Vm vm7 was shut down 
due to v3 host reboot or manual fence

2018-09-05 03:02:56,018+03 INFO  [org.ovirt.engine.core.bll.pm.StopVdsCommand] 
(EE-ManagedThreadFactory-engine-Thread-827680) [ea0f582] Power-Management: STOP 
host 'v3' succeeded.

2018-09-05 03:08:20,818+03 INFO  
[org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
(EE-ManagedThreadFactory-engineScheduled-Thread-91) [326878] EVENT_ID: 
VDS_DETECTED(13), Status of host v3 was set to Up.

2018-09-05 03:08:23,391+03 INFO  
[org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] 
(EE-ManagedThreadFactory-engineScheduled-Thread-88) [] VM 
'3b1262ef-7fff-40af-b85e-9fd01a4f422b'(vm7) was unexpectedly detected as 'Down' 
on VDS '4970369d-21c2-467d-9247-c73ca2d71b3e'(v3) (expected on 'null')

As you can see, engine does a fence on node v3.
vm7 as well as the others running on that node did not re-start.

any tips?

engine is ovirt-engine-4.2.5.3-1.el7.noarch and host is 
vdsm-4.20.35-1.el7.x86_64

best regards,

Giannis
___
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/2FIAENRQOJ7LS5ACX2XJFGT27WOCDU6D/

[ovirt-users] Re: vm operation after host fence

2018-09-05 Thread Kapetanakis Giannis 
On 05/09/18 12:40, Kapetanakis Giannis wrote:
> Hi,
> 
> Last night we have an incident of a failed host. Engine issued a fence but 
> did not restart the vms running on that node on other operational hosts. I'd 
> like to know if this is normal or I can tune it somehow.
> 
> Here are some relevant logs from engine:
> 
> 2018-09-05 03:00:51,496+03 WARN  [org.ovirt.engine.core.vdsbroker.VdsManager] 
> (EE-ManagedThreadFactory-engine-Thread-827644) [] Host 'v3' is not 
> responding. It will stay in Connecting state for a grace period of 63 seconds 
> and after that an attempt to fence the host will be issued.
> 
> 2018-09-05 03:01:11,945+03 INFO  
> [org.ovirt.engine.core.vdsbroker.monitoring.PollVmStatsRefresher] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-57) [] Failed to fetch vms 
> info for host 'v3' - skipping VMs monitoring.
> 2018-09-05 03:01:48,028+03 WARN  
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engine-Thread-827679) [] EVENT_ID: 
> VM_SET_TO_UNKNOWN_STATUS(142), VM vm7 was set to the Unknown status.
> 
> 2018-09-05 03:02:10,033+03 INFO  
> [org.ovirt.engine.core.bll.pm.StopVdsCommand] 
> (EE-ManagedThreadFactory-engine-Thread-827680) [30369e01] Power-Management: 
> STOP of host 'v3' initiated.
> 
> 2018-09-05 03:02:55,935+03 INFO  
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engine-Thread-827680) [3adcac38] EVENT_ID: 
> VM_WAS_SET_DOWN_DUE_TO_HOST_REBOOT_OR_MANUAL_FENCE(143), Vm vm7 was shut down 
> due to v3 host reboot or manual fence
> 
> 2018-09-05 03:02:56,018+03 INFO  
> [org.ovirt.engine.core.bll.pm.StopVdsCommand] 
> (EE-ManagedThreadFactory-engine-Thread-827680) [ea0f582] Power-Management: 
> STOP host 'v3' succeeded.
> 
> 2018-09-05 03:08:20,818+03 INFO  
> [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-91) [326878] EVENT_ID: 
> VDS_DETECTED(13), Status of host v3 was set to Up.
> 
> 2018-09-05 03:08:23,391+03 INFO  
> [org.ovirt.engine.core.vdsbroker.monitoring.VmAnalyzer] 
> (EE-ManagedThreadFactory-engineScheduled-Thread-88) [] VM 
> '3b1262ef-7fff-40af-b85e-9fd01a4f422b'(vm7) was unexpectedly detected as 
> 'Down' on VDS '4970369d-21c2-467d-9247-c73ca2d71b3e'(v3) (expected on 'null')
> 
> As you can see, engine does a fence on node v3.
> vm7 as well as the others running on that node did not re-start.
> 
> any tips?
> 
> engine is ovirt-engine-4.2.5.3-1.el7.noarch and host is 
> vdsm-4.20.35-1.el7.x86_64
> 
> best regards,
> 
> Giannis
> 

Maybe it has to do with HA VM options?
https://www.ovirt.org/documentation/how-to/ha-vms/

G
___
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/KO3LDGLYSH7CBZYLIQ4NHAOPHBT7C44I/

[ovirt-users] Re: Engine Setup Error

2018-09-05 Thread Simone Tiraboschi 
On Wed, Sep 5, 2018 at 11:10 AM Sakhi Hadebe  wrote:

> Hi All,
>
> The host deploy logs are showing the below errors:
>
> [root@garlic engine-logs-2018-09-05T08:48:22Z]# cat
> /var/log/ovirt-hosted-engine-setup/engine-logs-2018-09-05T08\:34\:55Z/ovirt-engine/host-deploy/ovirt-host-deploy-20180905103605-garlic.sanren.ac.za-543b536b.log
> | grep -i error
> 2018-09-05 10:35:46,909+0200 DEBUG otopi.context
> context.dumpEnvironment:869 ENV BASE/error=bool:'False'
> 2018-09-05 10:35:47,116 [ERROR] __main__.py:8011:MainThread
> @identity.py:145 - Reload of consumer identity cert
> /etc/pki/consumer/cert.pem raised an exception with msg: [Errno 2] No such
> file or directory: '/etc/pki/consumer/key.pem'
> 2018-09-05 10:35:47,383+0200 DEBUG otopi.context
> context.dumpEnvironment:869 ENV BASE/error=bool:'False'
> 2018-09-05 10:35:47,593 [ERROR] __main__.py:8011:MainThread
> @identity.py:145 - Reload of consumer identity cert
> /etc/pki/consumer/cert.pem raised an exception with msg: [Errno 2] No such
> file or directory: '/etc/pki/consumer/key.pem'
> 2018-09-05 10:35:48,245+0200 DEBUG otopi.context
> context.dumpEnvironment:869 ENV BASE/error=bool:'False'
> Job for ovirt-imageio-daemon.service failed because the control process
> exited with error code. See "systemctl status ovirt-imageio-daemon.service"
> and "journalctl -xe" for details.
> RuntimeError: Failed to start service 'ovirt-imageio-daemon'
> 2018-09-05 10:36:05,098+0200 ERROR otopi.context
> context._executeMethod:152 Failed to execute stage 'Closing up': Failed to
> start service 'ovirt-imageio-daemon'
> 2018-09-05 10:36:05,099+0200 DEBUG otopi.context
> context.dumpEnvironment:869 ENV BASE/error=bool:'True'
> 2018-09-05 10:36:05,099+0200 DEBUG otopi.context
> context.dumpEnvironment:869 ENV BASE/exceptionInfo=list:'[( 'exceptions.RuntimeError'>, RuntimeError("Failed to start service
> 'ovirt-imageio-daemon'",), )]'
> 2018-09-05 10:36:05,106+0200 DEBUG otopi.context
> context.dumpEnvironment:869 ENV BASE/error=bool:'True'
> 2018-09-05 10:36:05,106+0200 DEBUG otopi.context
> context.dumpEnvironment:869 ENV BASE/exceptionInfo=list:'[( 'exceptions.RuntimeError'>, RuntimeError("Failed to start service
> 'ovirt-imageio-daemon'",), )]'
>
> I coudn't find anything helpful from the internet.
>

something relevant int he output of
  systemctl status ovirt-imageio-daemon.service
and
  journalctl -xe -u ovirt-imageio-daemon.service
?



>
> On Tue, Sep 4, 2018 at 6:46 PM, Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Tue, Sep 4, 2018 at 6:07 PM Sakhi Hadebe  wrote:
>>
>>> Hi Sahina,
>>>
>>> I am sorry I can't reproduce the error nor access the logs since I did a
>>> fresh installed pn nodes. However now I can't even react that far because
>>> the engine deployment fails to start the host up:
>>>
>>>
>>> [ INFO ] TASK [Wait for the host to be up]
>>> [ ERROR ] fatal: [localhost]: FAILED! => {"ansible_facts":
>>> {"ovirt_hosts": [{"address": "goku.sanren.ac.za", "affinity_labels":
>>> [], "auto_numa_status": "unknown", "certificate": {"organization": "
>>> sanren.ac.za", "subject": "O=sanren.ac.za,CN=goku.sanren.ac.za"},
>>> "cluster": {"href": 
>>> "/ovirt-engine/api/clusters/1ca368cc-b052-11e8-b7de-00163e008187",
>>> "id": "1ca368cc-b052-11e8-b7de-00163e008187"}, "comment": "", "cpu":
>>> {"speed": 0.0, "topology": {}}, "device_passthrough": {"enabled": false},
>>> "devices": [], "external_network_provider_configurations": [],
>>> "external_status": "ok", "hardware_information": {"supported_rng_sources":
>>> []}, "hooks": [], "href": "/ovirt-engine/api/hosts/
>>> 1c575995-70b1-43f7-b348-4a9788e070cd", "id": 
>>> "1c575995-70b1-43f7-b348-4a9788e070cd",
>>> "katello_errata": [], "kdump_status": "unknown", "ksm": {"enabled": false},
>>> "max_scheduling_memory": 0, "memory": 0, "name": "goku.sanren.ac.za",
>>> "network_attachments": [], "nics": [], "numa_nodes": [], "numa_supported":
>>> false, "os": {"custom_kernel_cmdline": ""}, "permissions": [], "port":
>>> 54321, "power_management": {"automatic_pm_enabled": true, "enabled": false,
>>> "kdump_detection": true, "pm_proxies": []}, "protocol": "stomp",
>>> "se_linux": {}, "spm": {"priority": 5, "status": "none"}, "ssh":
>>> {"fingerprint": "SHA256:B3/PDH551EFid93fm6PoRryi6/cXuVE8yNgiiiROh84",
>>> "port": 22}, "statistics": [], "status": "install_failed",
>>> "storage_connection_extensions": [], "summary": {"total": 0}, "tags":
>>> [], "transparent_huge_pages": {"enabled": false}, "type": "ovirt_node",
>>> "unmanaged_networks": [], "update_available": false}]}, "attempts": 120,
>>> "changed": false}
>>>
>>> "status": "install_failed"
>>
>> You have to check host-deploy logs to get a details error message.
>>
>>
>>>
>>> Please help.
>>>
>>> On Mon, Sep 3, 2018 at 1:34 PM, Sahina Bose  wrote:
>>>


 On Wed, Aug 29, 2018 at 8:39 PM, Sakhi Hadebe 
 wrote:

> Hi,
>
> I am sorry to bother you again.
>
> I am trying to deploy an oVirt engine for oVirtNode-4.2.5.1. I get the
> same

[ovirt-users] Re: Engine Setup Error

2018-09-05 Thread Sakhi Hadebe 
Hi All,

The host deploy logs are showing the below errors:

[root@garlic engine-logs-2018-09-05T08:48:22Z]# cat
/var/log/ovirt-hosted-engine-setup/engine-logs-2018-09-05T08\:34\:55Z/ovirt-engine/host-deploy/ovirt-host-deploy-20180905103605-garlic.sanren.ac.za-543b536b.log
| grep -i error
2018-09-05 10:35:46,909+0200 DEBUG otopi.context
context.dumpEnvironment:869 ENV BASE/error=bool:'False'
2018-09-05 10:35:47,116 [ERROR] __main__.py:8011:MainThread
@identity.py:145 - Reload of consumer identity cert
/etc/pki/consumer/cert.pem raised an exception with msg: [Errno 2] No such
file or directory: '/etc/pki/consumer/key.pem'
2018-09-05 10:35:47,383+0200 DEBUG otopi.context
context.dumpEnvironment:869 ENV BASE/error=bool:'False'
2018-09-05 10:35:47,593 [ERROR] __main__.py:8011:MainThread
@identity.py:145 - Reload of consumer identity cert
/etc/pki/consumer/cert.pem raised an exception with msg: [Errno 2] No such
file or directory: '/etc/pki/consumer/key.pem'
2018-09-05 10:35:48,245+0200 DEBUG otopi.context
context.dumpEnvironment:869 ENV BASE/error=bool:'False'
Job for ovirt-imageio-daemon.service failed because the control process
exited with error code. See "systemctl status ovirt-imageio-daemon.service"
and "journalctl -xe" for details.
RuntimeError: Failed to start service 'ovirt-imageio-daemon'
2018-09-05 10:36:05,098+0200 ERROR otopi.context context._executeMethod:152
Failed to execute stage 'Closing up': Failed to start service
'ovirt-imageio-daemon'
2018-09-05 10:36:05,099+0200 DEBUG otopi.context
context.dumpEnvironment:869 ENV BASE/error=bool:'True'
2018-09-05 10:36:05,099+0200 DEBUG otopi.context
context.dumpEnvironment:869 ENV BASE/exceptionInfo=list:'[(, RuntimeError("Failed to start service
'ovirt-imageio-daemon'",), )]'
2018-09-05 10:36:05,106+0200 DEBUG otopi.context
context.dumpEnvironment:869 ENV BASE/error=bool:'True'
2018-09-05 10:36:05,106+0200 DEBUG otopi.context
context.dumpEnvironment:869 ENV BASE/exceptionInfo=list:'[(, RuntimeError("Failed to start service
'ovirt-imageio-daemon'",), )]'

I coudn't find anything helpful from the internet.

On Tue, Sep 4, 2018 at 6:46 PM, Simone Tiraboschi 
wrote:

>
>
> On Tue, Sep 4, 2018 at 6:07 PM Sakhi Hadebe  wrote:
>
>> Hi Sahina,
>>
>> I am sorry I can't reproduce the error nor access the logs since I did a
>> fresh installed pn nodes. However now I can't even react that far because
>> the engine deployment fails to start the host up:
>>
>>
>> [ INFO ] TASK [Wait for the host to be up]
>> [ ERROR ] fatal: [localhost]: FAILED! => {"ansible_facts":
>> {"ovirt_hosts": [{"address": "goku.sanren.ac.za", "affinity_labels": [],
>> "auto_numa_status": "unknown", "certificate": {"organization": "
>> sanren.ac.za", "subject": "O=sanren.ac.za,CN=goku.sanren.ac.za"},
>> "cluster": {"href": "/ovirt-engine/api/clusters/1ca368cc-b052-11e8-b7de-
>> 00163e008187", "id": "1ca368cc-b052-11e8-b7de-00163e008187"}, "comment":
>> "", "cpu": {"speed": 0.0, "topology": {}}, "device_passthrough":
>> {"enabled": false}, "devices": [], 
>> "external_network_provider_configurations":
>> [], "external_status": "ok", "hardware_information":
>> {"supported_rng_sources": []}, "hooks": [], "href":
>> "/ovirt-engine/api/hosts/1c575995-70b1-43f7-b348-4a9788e070cd", "id":
>> "1c575995-70b1-43f7-b348-4a9788e070cd", "katello_errata": [],
>> "kdump_status": "unknown", "ksm": {"enabled": false},
>> "max_scheduling_memory": 0, "memory": 0, "name": "goku.sanren.ac.za",
>> "network_attachments": [], "nics": [], "numa_nodes": [], "numa_supported":
>> false, "os": {"custom_kernel_cmdline": ""}, "permissions": [], "port":
>> 54321, "power_management": {"automatic_pm_enabled": true, "enabled": false,
>> "kdump_detection": true, "pm_proxies": []}, "protocol": "stomp",
>> "se_linux": {}, "spm": {"priority": 5, "status": "none"}, "ssh":
>> {"fingerprint": "SHA256:B3/PDH551EFid93fm6PoRryi6/cXuVE8yNgiiiROh84",
>> "port": 22}, "statistics": [], "status": "install_failed",
>> "storage_connection_extensions": [], "summary": {"total": 0}, "tags":
>> [], "transparent_huge_pages": {"enabled": false}, "type": "ovirt_node",
>> "unmanaged_networks": [], "update_available": false}]}, "attempts": 120,
>> "changed": false}
>>
>> "status": "install_failed"
>
> You have to check host-deploy logs to get a details error message.
>
>
>>
>> Please help.
>>
>> On Mon, Sep 3, 2018 at 1:34 PM, Sahina Bose  wrote:
>>
>>>
>>>
>>> On Wed, Aug 29, 2018 at 8:39 PM, Sakhi Hadebe 
>>> wrote:
>>>
 Hi,

 I am sorry to bother you again.

 I am trying to deploy an oVirt engine for oVirtNode-4.2.5.1. I get the
 same error I encountered before:

 [ INFO  ] TASK [Add glusterfs storage domain]
 [ ERROR ] Error: Fault reason is "Operation Failed". Fault detail is
 "[Problem while trying to mount target]". HTTP response code is 400.
 [ ERROR ] fatal: [localhost]: FAILED! => {"changed": false, "msg":
 "Fault reason is \"Operation Failed\". Fault detail is \"[Problem while
  trying to

[ovirt-users] ERROR: Malformed metadata for host 3

2018-09-05 Thread info 
Hi,

we have a Hyperconverged oVirt Cluster with three machines. All three are 
running GlusterFS (Replica 3), and on two of them we are running the VMs 
(because they have better hardware).

Now we wanted to add a new oVirt host. Due to some network related errors, 
adding this host was unsuccessful, so we removed it from GUI and also via 
"hosted-engine --clean-metadata --host-id=3 --force-clean" (as it was still 
listed using "hosted-engine --vm-status" after removal from the GUI).

Inside the GUI and with "hosted-engine --vm-status", everything looks fine now, 
the third oVirt host is gone, and there are no problems at all. But in the 
/var/log/ovirt-hosted-engine-ha/agent.log, we now get every 15 minutes a 
"MainThread::ERROR::2018-09-05 
10:20:17,190::hosted_engine::793::ovirt_hosted_engine_ha.agent.hosted_engine.HostedEngine::(process_remote_metadata)
 Malformed metadata for host 3: received 0 of 512 expected bytes", on both of 
the remaining oVirt hosts.

Can someone explain what is wrong?

oVirt 4.2.2.6-1.el7.centos

Thank you
Markus
___
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/JJ442KHT2UONHL4HPT6ILYWCSNMG7ONB/

[ovirt-users] Re: problem with multipath.conf

2018-09-05 Thread g . vasilopoulos 
Thank you very much for your answer, somehow the exception did not work, but I 
guess it is ok it is not a shared storage, it is a dual sas port external JBOD 
box. I guess multipath is not really needed in that case
___
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/7AC3XX5SSIE26YT5Y2WVHKISDX6S7NAW/

[ovirt-users] Re: [ANN] oVirt 4.2.6 is now generally available

2018-09-05 Thread Fabrice Bacchella 


> Le 4 sept. 2018 à 21:56, Nir Soffer  a écrit :
> 
> 

> For reference, I just installed multipath on CentOS:
> 
> # cat /etc/redhat-release 
> CentOS Linux release 7.5.1804 (Core) 
> 
> # rpm -q device-mapper-multipath
> device-mapper-multipath-0.4.9-119.el7_5.1.x86_64
> 
> # lsblk
> NAMEMAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
> sda   8:00   50G  0 disk 
> ├─sda18:101G  0 part /boot
> └─sda28:20   49G  0 part 
>   ├─centos_voodoo4-root 253:00 45.1G  0 lvm  /
>   └─centos_voodoo4-swap 253:10  3.9G  0 lvm  [SWAP]
> sr0  11:01 1024M  0 rom  
> 
> # multipathd show paths format "%d %P"
> dev protocol   
> sda scsi:unspec
> 
> # man multipath.conf 
> ...
> blacklist section
> ...
>protocol Regular expression of the protocol to be excluded. 
> See below for a list of recognized protocols
> ...
>The  protocol strings that multipath recognizes are scsi:fcp, 
> scsi:spi, scsi:ssa, scsi:sbp, scsi:srp, scsi:iscsi, scsi:sas, scsi:adt, 
> scsi:ata, scsi:unspec, ccw, cciss, nvme, and
>undef.  The protocol that a path is using can be viewed by running 
> multipathd show paths format "%d %P"
> 

My version:
device-mapper-multipath-0.4.9-119.el7.x86_64

yours:
> device-mapper-multipath-0.4.9-119.el7_5.1.x86_64

So this is quite new.

After a yum update it's much 'better':

~$ sudo multipathd show paths format "%d %P"
dev  protocol   
sddi scsi:unspec
sddj scsi:unspec
sda  scsi:unspec
sdc  scsi:unspec
sdd  scsi:unspec

But as it's not in the blacklist_exceptions, that's what I will need to add.

___
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/C2LI5HWVME5SJ2RXJDG2E2PQHWV3G5C6/

[ovirt-users] Re: qemu-kvm memory leak in 4.2.5

2018-09-05 Thread Alex K 
On Mon, Sep 3, 2018 at 9:56 AM Hesham Ahmed  wrote:

> Starting oVirt 4.2.4 (also in 4.2.5 and maybe in 4.2.3) I am facing
> some sort of memory leak. The memory usage on the hosts keep
> increasing till it reaches somewhere around 97%. Putting the host in
> maintenance and back resolves it. The memory usage by the qemu-kvm
> processes is way above the defined VM memory for instance below is the
> memory usage of a VM:
>
Sounds to me as the recent gluster memory leak which is fixed at version
3.12.13.


>
>PID   USER  PR  NIVIRTRESSHR S  %CPU %MEM TIME+
> COMMAND
>  12271  qemu  20   0  35.4g   30.9g  8144 S  13.3 49.3
> 9433:15 qemu-kvm
>
> The VM memory settings are:
>
> Defined Memory: 8192 MB
> Physical Memory Guaranteed: 5461 MB
>
> This is for a 3 node hyperconverged cluster running on latest oVirt Node
> 4.2.5.
> ___
> 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/Q7W7S3V2GRBIJ4ID6EJVJWRCBM4DE42L/
>
___
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/DSRLGE32TAZ5Z4DPEX6KGW55M7N43PGL/