[ovirt-users] Replication between storage domains

[Anantha Raghava]

Hello...

I am trying to setup a DC & DR with oVirt with two sets of rack servers 
and two Storage Boxes. In DC, I have FC storage and in DR I have iSCSI 
storage. Now the question is can I replicate the VM disks and data 
between these dissimilar storage domains at say 15 min interval?


--

Thanks & Regards,


Anantha Raghava

eXza Technology Consulting & Services

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

Re: [ovirt-users] remote-viewer from admin vs user portal

[Gianluca Cecchi]

On Thu, Oct 13, 2016 at 9:31 AM, Simone Tiraboschi 
wrote:

>
> Ciao Gianluca,
> Have you compared also the content of the two console.vv files?
>
>
>
It seems this:

$ diff user_portal.txt admin_portal.txt
5c5
< password=USuJCbk3UhzK
---
> password=4ZAr/w23pFPV
16c16
<
usb-filter=-1,60186,1,256,1|-1,1118,245,-1,1|-1,1133,2245,-1,1|-1,1133,2242,5,1|8,-1,-1,-1,1|7,-1,-1,-1,1|-1,-1,-1,-1,0
---
> usb-filter=-1,-1,-1,-1,0
19a20
> proxy=http://192.168.1.215:3128/
27c28
<
sso-token=f5PtHwvwE6erjVBfGpaLeUWmD9iEOeM3OXzAAocXDz4VQ-uYNsTUt1x9NXohbCalxFUw947sZfzZyvfevTEaBA
---
>
sso-token=pFNiF5viL6jiu9FZIdeEsvD74eA2OuPGjzZTFa_IfPoGXFMRkQSTmrGTB0J5lbTJ6Na_rKkGVMExxUsneLfhzw
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Unable to get HE up after update

[Susinthiran Sithamparanathan]

On Thu, Oct 13, 2016 at 3:23 PM, Yedidyah Bar David  wrote:

>
> OK. Can you please attach the output of:
>
> grep MANUAL /etc/ovirt-engine/engine.conf.d/*.conf
>

 [root@ovirt01 ~]# grep MANUAL /etc/ovirt-engine/engine.conf.d/*.conf
[root@ovirt01 ~]# ssh 192.168.0.101
root@192.168.0.101's password:
Last login: Thu Oct 13 19:50:02 2016 from ovirt01
[root@engine ~]# grep MANUAL /etc/ovirt-engine/engine.conf.d/*.conf
[root@engine ~]#

I.e nothing found by grep for that search on the host and the engine-vm.


-- 

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

Re: [ovirt-users] VM pauses/hangs after migration

[Davide Ferrari]

Hello

just for the record, after I have that server replaced (only
motherboard+ram+controller, same disks), now everything works ok, so it was
definitely an hardware issue.

Thanks everyone for the troubleshoot help!


2016-10-04 18:06 GMT+02:00 Michal Skrivanek :

>
> On 3 Oct 2016, at 10:39, Davide Ferrari  wrote:
>
>
>
> 2016-09-30 15:35 GMT+02:00 Michal Skrivanek :
>
>>
>>
>> that is a very low level error really pointing at HW issues. It may or
>> may not be detected by memtest…but I would give it a try
>>
>>
> I left memtest86 running for 2 days and no error detected :(
>
>
>> The only difference that this host (vmhost01) has is that it was the
>> first host installed in my self-hosted engine installation. But I have
>> already reinstalled it from GUI and menawhile I've upgraded to 4.0.4 from
>> 4.0.3.
>>
>>
>> does it happen only for the big 96GB VM? The others which you said are
>> working, are they all small?
>> Might be worth trying other system stability tests, playing with
>> safer/slower settings in BIOS, use lower CPU cluster, etc
>>
>>
> Yep, it happens only for the 96GB VM. Other VMs with fewer RAM (16GB for
> example) can be created on or migrated to that host flawlessly. I'll try to
> play a little with BIOS settings but otherwise I'll have the HW replaced. I
> was only trying to rule out possible oVirt SW problems due to that host
> being the first I deployed (from CLI) when I installed the cluster.
>
>
> I understand. Unfortunately it really does look like some sort of
> incompatibility rather than a sw issue:/
>
>
> Thanks!
>
> --
> Davide Ferrari
> Senior Systems Engineer
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
>
>


-- 
Davide Ferrari
Senior Systems Engineer
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Multi cluster question with regards to storage

[Beckman, Daniel]

Hi David,

Storage is associated with a particular data center, so if they are on the same 
data center they will have access to the same storage.

The Red Hat documentation on the commercial supported version RHEV (now RHV?) 
is a lot more comprehensive; the equivalent oVirt documentation is pretty 
sparse and uneven, so it’s understandable you never would have been introduced 
to that concept. You need an active subscription to access the KB articles but 
the basic documentation is freely available and it’s a good resource, as most 
things are going to be common on RHV vs. oVirt:

https://access.redhat.com/documentation/en/red-hat-virtualization?version=4.0/

Daniel



From:  on behalf of David Gossage 

Date: Thursday, October 13, 2016 at 9:08 AM
To: users 
Subject: [ovirt-users] Multi cluster question with regards to storage

I've not yet found a clean concise answer and so I wanted to ask before I start 
trying to play with things in my test setup and waste a bunch of time maybe.

If I have 2 clusters in one data center each running different cpu types 
(amd/intel) can they both access the same shared storage domain(gluster in my 
case)?

I'm not interested in live migration between the clusters really, though 
stopping and starting on another would be nice.  I've tried looking at various 
threads and list emails and I've found some mentions of it, but usually as an 
aside while discussing other matters so I could never quite say for certain it 
was working or not.


David Gossage
Carousel Checks Inc. | System Administrator
Office 708.613.2284
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Multi cluster question with regards to storage

[David Gossage]

On Thu, Oct 13, 2016 at 10:26 AM, Beckman, Daniel <
daniel.beck...@ingramcontent.com> wrote:

> Hi David,
>
>
>
> Storage is associated with a particular data center, so if they are on the
> same data center they will have access to the same storage.
>
>
>
> The Red Hat documentation on the commercial supported version RHEV (now
> RHV?) is a lot more comprehensive; the equivalent oVirt documentation is
> pretty sparse and uneven, so it’s understandable you never would have been
> introduced to that concept. You need an active subscription to access the
> KB articles but the basic documentation is freely available and it’s a good
> resource, as most things are going to be common on RHV vs. oVirt:
>
>
>
> https://access.redhat.com/documentation/en/red-hat-
> virtualization?version=4.0/
>

Thanks, I actually have RHEV licensed for some production servers and I
don't now why I didn't log back in to check that doc out as now that you
mentioned it I do recall perusing it long ago and it had decent
explanations on that.

Thanks for the reminder and the answer as well.


>
> Daniel
>
>
>
>
>
>
>
> *From: * on behalf of David Gossage <
> dgoss...@carouselchecks.com>
> *Date: *Thursday, October 13, 2016 at 9:08 AM
> *To: *users 
> *Subject: *[ovirt-users] Multi cluster question with regards to storage
>
>
>
> I've not yet found a clean concise answer and so I wanted to ask before I
> start trying to play with things in my test setup and waste a bunch of time
> maybe.
>
>
>
> If I have 2 clusters in one data center each running different cpu types
> (amd/intel) can they both access the same shared storage domain(gluster in
> my case)?
>
>
>
> I'm not interested in live migration between the clusters really, though
> stopping and starting on another would be nice.  I've tried looking at
> various threads and list emails and I've found some mentions of it, but
> usually as an aside while discussing other matters so I could never quite
> say for certain it was working or not.
>
>
>
>
> *David Gossage*
>
> *Carousel Checks Inc.** | System Administrator*
> *Office* 708.613.2284
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] unsupported configuration: Unable to find security driver for model selinux

[Николаев Алексей]

  12.10.2016, 16:35, "Tom Gamull" :This should work but that is a little strange (I’m copying from the suggested action)-If you believe that qemu-kvm should be allowed getattr access on the a3f29de7-c6b9-410e-b635-9b3016da7ba2 lnk_file by default.Then you should report this as a bug.You can generate a local policy module to allow this access.Doallow this access for now by executing:# grep qemu-kvm /var/log/audit/audit.log | audit2allow -M mypol# semodule -i mypol.pp——— It looks like the qemu-kvm is having access issues on lnk files. Could you try the above action on node69-02 and see if that resolves the issue? It may be a bug.  Yes, this resolves issues with migration to node69-02 and from it. Thx!   On Oct 12, 2016, at 9:27 AM, Николаев Алексей  wrote:   12.10.2016, 15:53, "Tom Gamull" :Can you set it to permissive and runsealart -a /var/log/audit/audit.log  Added logs to attachment.  you may need to install selinux tools On Oct 12, 2016, at 4:49 AM, Краснобаев Михаил  wrote: Good day, had a similar problem, disabling selinux helped. Best,Mikhail 11.10.2016, 09:55, "Николаев Алексей" :Hi community! I have 4 hosts: 2 old servers and 2 new serversI have this error trying to migrate VM from new host to old one. Oct 11 09:25:05 node69-06 journal: unsupported configuration: Unable to find security driver for model selinuxOct 11 09:25:05 node69-06 journal: vdsm vm.Vm ERROR vmId=`a9473a99-32c6-4548-8b85-dafe4ce8f94f`::unsupported configuration: Unable to find security driver for model selinuxOct 11 09:25:05 node69-06 journal: vdsm vm.Vm ERROR vmId=`a9473a99-32c6-4548-8b85-dafe4ce8f94f`::Failed to migrate#012Traceback (most recent call last):#012  File "/usr/share/vdsm/virt/migration.py", line 246, in run#012    self._startUnderlyingMigration(time.time())#012  File "/usr/share/vdsm/virt/migration.py", line 335, in _startUnderlyingMigration#012    None, maxBandwidth)#012  File "/usr/share/vdsm/virt/vm.py", line 703, in f#012    ret = attr(*args, **kwargs)#012  File "/usr/lib/python2.7/site-packages/vdsm/libvirtconnection.py", line 119, in wrapper#012    ret = f(*args, **kwargs)#012  File "/usr/lib64/python2.7/site-packages/libvirt.py", line 1825, in migrateToURI2#012    if ret == -1: raise libvirtError ('virDomainMigrateToURI2() failed', dom=self)#012libvirtError: unsupported configuration: Unable to find security driver for model selinux Migration from OLD host to another OLD host have not any problems.Migration from NEW host to another NEW host have not any problems.Migration from OLD host to NEW host have not any problems. Migration is not work only from NEW to OLD. oVirt Engine Version: 3.5.6.2-1.el6 All hosts:OS Version: RHEL - 7 - 2.1511.el7.centos.2.10Kernel Version: 3.10.0 - 327.36.1.el7.x86_64KVM Version: 2.3.0 - 29.1.el7LIBVIRT Version: libvirt-1.2.17-13.el7_2.5VDSM Version: vdsm-4.16.30-0.el7.centos Any ideas? Thx.,___Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users___Users mailing listUsers@ovirt.orghttp://lists.ovirt.org/mailman/listinfo/users___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Multi cluster question with regards to storage

[David Gossage]

I've not yet found a clean concise answer and so I wanted to ask before I
start trying to play with things in my test setup and waste a bunch of time
maybe.

If I have 2 clusters in one data center each running different cpu types
(amd/intel) can they both access the same shared storage domain(gluster in
my case)?

I'm not interested in live migration between the clusters really, though
stopping and starting on another would be nice.  I've tried looking at
various threads and list emails and I've found some mentions of it, but
usually as an aside while discussing other matters so I could never quite
say for certain it was working or not.


*David Gossage*
*Carousel Checks Inc. | System Administrator*
*Office* 708.613.2284
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] status update: running containers alongside VMs

[Martin Polednik]

On 13/10/16 06:40 -0400, Francesco Romani wrote:

Hi everyone,

I'm happy to share some progress about the former "convirt"[1] project,
which aims to let Vdsm containers alongside VMs, on bare metal.

In the last couple of months I kept updating the patch series, which
is approaching the readiness to be merged in Vdsm.

Please read through this mail to see what the patchset can do now,
how you could try it *now*, even before it is merged.

Everyone is invited to share thoughts and ideas about how this effort
could evolve.
This will be a long mail; I will amend, enhance and polish the content
and make a blog post (on https://mojaves.github.io) to make it easier
to consume and to have some easy-to-find documentation. Later on the
same content will appear also on the oVirt blog.


Thank you for the e-mail!


Happy hacking!

+++

# How to try how the experimental container support for Vdsm.

Vdsm is gaining *experimental* support to run containers alongside VMs.
Vdsm had since long time the ability to manage VMs which run containers,
and recently gained support for
[atomic 
guests](http://www.projectatomic.io/blog/2015/01/running-ovirt-guest-agent-as-privileged-container/).

With the new support we are describing, you will be able to manage containers
with the same, proven infrastructure that let you manage VMs.

This feature is currently being developed and it is still not merged in the
Vdsm codebase, so some extra work is needed if you want to try it out.
We aiming to merge it in the oVirt 4.1.z cycle.

## What works, aka what to expect

The basic features are expected to work:
1. Run any docker image on the public docker registry
2. Make the container accessible from the outside (aka not just from localhost)
3. Use file-based storage for persistent volumes

## What does not yet work, aka what NOT to expect

Few things are planned and currently under active development:
1. Monitoring. Engine will not get any update from the container besides "VM" 
status (Up, Down...)


The question is what to actually monitor. Do we want some performance
metrics or simple "service is running" probe?


  One important drawback is that you will not be told the IP of the container 
from Engine,
  you will need to connect to the Vdsm host to discover it using standard 
docker tools.
2. Proper network integration. Some steps still need manual intervention
3. Stability and recovery - it's pre-alpha software after all! :)


This is something we should really discuss and care about - to which
degree we want to pet our containers.



## 1. Introduction and prerequisites

Trying out container support affects only the host and the Vdsm.
Besides add few custom properties (totally safe and supported since early
3.z), there are zero changes required to the DB and to Engine.
Nevertheless, we recommend to dedicate one oVirt 4.y environment,
or at least one 4.y host, to try out the container feature.

To get started, first thing you need is to setup a vanilla oVirt 4.y
installation. We will need to make changes to the Vdsm and to the
Vdsm host, so hosted engine and/or oVirt node may add extra complexity,
better to avoid them at the moment.

The reminder of this tutorial assumes you are using two hosts,
one for Vdsm (will be changed) and one for Engine (will require zero changes);
furthermore, we assume the Vdsm host is running on CentOS 7.y.

We require:
- one test host for Vdsm. This host need to have one NIC dedicated to 
containers.
 We will use the [docker macvlan 
driver](https://raesene.github.io/blog/2016/07/23/Docker-MacVLAN/),
 so this NIC *must not be* part of one bridge.
- docker >= 1.12
- oVirt >= 4.0.5 (Vdsm >= 4.18.15)
- CentOS >= 7.2

Docker >= 1.12 is avaialable for download 
[here](https://docs.docker.com/engine/installation/linux/centos/)

Caveats:
1. docker from official rpms conflicts con docker from CentOS, and has a 
different package name: docker-engine vs docker.
  Please note that the kubernetes package from CentOS, for example, require 
'docker', not 'docker-engine'.
2. you may want to replace the default service file
  [with this 
one](https://github.com/mojaves/convirt/blob/master/patches/centos72/systemd/docker/docker.service)
  and to use this
  [sysconfig 
file](https://github.com/mojaves/convirt/blob/master/patches/centos72/systemd/docker/docker-engine).
  Here I'm just adding the storage options docker requires, much like the 
CentOS docker is configured.
  Configuring docker like this can save you some troubleshooting, especially if 
you had docker from CentOS installed
  on the testing box.

## 2. Patch Vdsm to support containers

You need to patch and rebuild Vdsm.
Fetch [this 
patch](https://github.com/mojaves/convirt/blob/master/patches/vdsm/4.18.15.1/0001-container-support-for-Vdsm.patch.gz)
and apply it against Vdsm 4.18.15.1. Vdsm 4.18.15.{1,2,...} are supported as 
well.

Rebuild Vdsm and reinstall on your box.
[centos 7.2 packages are 
here](https://github.com/mojaves/convirt/tree/master/rpms/cent

Re: [ovirt-users] vdsm ssl errors

[Simone Tiraboschi]

On Thu, Oct 13, 2016 at 3:19 PM, Gianluca Cecchi 
wrote:

>
>
> On Thu, Oct 13, 2016 at 2:59 PM, Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Thu, Oct 13, 2016 at 2:45 PM, Simone Tiraboschi 
>> wrote:
>>
>>>
>>>
>>> On Thu, Oct 13, 2016 at 11:23 AM, Piotr Kliczewski 
>>> wrote:
>>>
 Gianluca,

 The port needs to be open on machines where vdsm is installed.

 @Simone can you take a look why after running host deploy at 2016-10-03
 23:28:47,891
 we are not able to talk to vdsm anymore?

>>>
>>> OK, I'm on it.
>>>
>>
>> Gianluca, can you please share somehow the output of
>>   ss -at
>> on all your hosts, your /var/log/ovirt-hosted-engine-ha/agent.log and
>> /var/log/ovirt-hosted-engine-ha/broker.log
>> (maybe I simply lost them within this long thread).
>>
>>
Thanks, the only errors that I see on agent and broker logs are:

Thread-6::INFO::2016-10-13
12:29:40,783::engine_health::124::engine_health.CpuLoadNoEngine::(action)
VM is up on this host with healthy engine
Thread-1::ERROR::2016-10-13
12:29:42,859::notifications::39::ovirt_hosted_engine_ha.broker.notifications.Notifications::(send_email)
[Errno 101] Network is unreachable
Traceback (most recent call last):
  File
"/usr/lib/python2.7/site-packages/ovirt_hosted_engine_ha/broker/notifications.py",
line 26, in send_email
timeout=float(cfg["smtp-timeout"]))
  File "/usr/lib64/python2.7/smtplib.py", line 255, in __init__
(code, msg) = self.connect(host, port)
  File "/usr/lib64/python2.7/smtplib.py", line 315, in connect
self.sock = self._get_socket(host, port, self.timeout)
  File "/usr/lib64/python2.7/smtplib.py", line 290, in _get_socket
return socket.create_connection((host, port), timeout)
  File "/usr/lib64/python2.7/socket.py", line 571, in create_connection
raise err
error: [Errno 101] Network is unreachable

when it tries to send an email (it cannot reach the smtp server) but vdsm
communication seams fine.



>
>>>

 Thanks,
 Piotr

>>>
 On Thu, Oct 13, 2016 at 11:15 AM, Gianluca Cecchi <
 gianluca.cec...@gmail.com> wrote:

>
>
> On Thu, Oct 13, 2016 at 11:13 AM, Gianluca Cecchi <
> gianluca.cec...@gmail.com> wrote:
>
>> Il 13/Ott/2016 11:00, "Piotr Kliczewski"  ha
>> scritto:
>> >
>> > Gianluca,
>> >
>> > Checking the log it seems that we do not configure firewall:
>> >
>> > NETWORK/firewalldEnable=bool:'False'
>> > NETWORK/iptablesEnable=bool:'False'
>> >
>> > Please make sure that you reconfigure your firewall to open 54321
>> port or let host deploy to do it for you.
>> >
>> > Thanks,
>> > Piotr
>>
>> Hi,
>> at this moment Ihave:
>> On hypervisor iptables service configured and active.
>> On engine firewalld service configured and active.
>> Do I have to open port 54321 on host?
>>
> Actually it is already...
>
> root@ovirt01 ~]# iptables -L -n
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp
> dpt:53
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
> dpt:53
> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp
> dpt:67
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
> dpt:67
> ACCEPT all  --  192.168.1.2120.0.0.0/0
> ACCEPT all  --  0.0.0.0/00.0.0.0/0state
> RELATED,ESTABLISHED
> ACCEPT icmp --  0.0.0.0/00.0.0.0/0
> ACCEPT all  --  0.0.0.0/00.0.0.0/0
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
> dpt:54321
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
> dpt:111
> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp
> dpt:111
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
> dpt:22
> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp
> dpt:161
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
> dpt:16514
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0
> multiport dports 2223
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0
> multiport dports 5900:6923
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0
> multiport dports 49152:49216
> REJECT all  --  0.0.0.0/00.0.0.0/0
> reject-with icmp-host-prohibited
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source   destination
> ACCEPT all  --  0.0.0.0/0192.168.122.0/24 ctstate
> RELATED,ESTABLISHED
> ACCEPT all  --  192.168.122.0/24 0.0.0.0/0
> ACCEPT all  --  0.0.0.0/00.0.0.0/0
> REJECT all  --  0.0.0.0/00.0.0.0/0
> reject-with icmp-port-unreachable
> REJECT all  --  0.0.0.0/0   

Re: [ovirt-users] Unable to get HE up after update

[Yedidyah Bar David]

On Thu, Oct 13, 2016 at 2:42 PM, Susinthiran Sithamparanathan
 wrote:
>
>
> On Thu, Oct 13, 2016 at 10:45 AM, Yedidyah Bar David 
> wrote:
>> Is this file copied to [1]? The file in [1] is empty - has a size of zero.
>> Perhaps your engine vm suffered some serious corruption? Perhaps due to
>> storage/network/power problems? Please check/post the output of:
>
>  Yes, it was actually under engine-vm/ and not under the root, but something
> happened with the sync of the file, but is synced correctly now. Sorry for
> that!
>
>> rpm -V ovirt-engine-backend
>  [root@engine ~]# rpm -V ovirt-engine-backend
> S.5T.  c /etc/logrotate.d/ovirt-engine
> S.5T.  c /etc/pki/ovirt-engine/cacert.template.in
> S.5T.  c /etc/pki/ovirt-engine/cert.template.in
> S.5T.  c /etc/pki/ovirt-engine/openssl.conf
> [root@engine ~]#
>> [1]
>> https://my.owndrive.com/index.php/s/3Dcyho9bqo7oZs8/download?path=%2Fengine-vm&files=ovirt-engine.conf

OK. Can you please attach the output of:

grep MANUAL /etc/ovirt-engine/engine.conf.d/*.conf

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

Re: [ovirt-users] vdsm ssl errors

[Gianluca Cecchi]

On Thu, Oct 13, 2016 at 2:59 PM, Simone Tiraboschi 
wrote:

>
>
> On Thu, Oct 13, 2016 at 2:45 PM, Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Thu, Oct 13, 2016 at 11:23 AM, Piotr Kliczewski 
>> wrote:
>>
>>> Gianluca,
>>>
>>> The port needs to be open on machines where vdsm is installed.
>>>
>>> @Simone can you take a look why after running host deploy at 2016-10-03
>>> 23:28:47,891
>>> we are not able to talk to vdsm anymore?
>>>
>>
>> OK, I'm on it.
>>
>
> Gianluca, can you please share somehow the output of
>   ss -at
> on all your hosts, your /var/log/ovirt-hosted-engine-ha/agent.log and
> /var/log/ovirt-hosted-engine-ha/broker.log
> (maybe I simply lost them within this long thread).
>
>
>>
>>
>>>
>>> Thanks,
>>> Piotr
>>>
>>
>>> On Thu, Oct 13, 2016 at 11:15 AM, Gianluca Cecchi <
>>> gianluca.cec...@gmail.com> wrote:
>>>


 On Thu, Oct 13, 2016 at 11:13 AM, Gianluca Cecchi <
 gianluca.cec...@gmail.com> wrote:

> Il 13/Ott/2016 11:00, "Piotr Kliczewski"  ha
> scritto:
> >
> > Gianluca,
> >
> > Checking the log it seems that we do not configure firewall:
> >
> > NETWORK/firewalldEnable=bool:'False'
> > NETWORK/iptablesEnable=bool:'False'
> >
> > Please make sure that you reconfigure your firewall to open 54321
> port or let host deploy to do it for you.
> >
> > Thanks,
> > Piotr
>
> Hi,
> at this moment Ihave:
> On hypervisor iptables service configured and active.
> On engine firewalld service configured and active.
> Do I have to open port 54321 on host?
>
 Actually it is already...

 root@ovirt01 ~]# iptables -L -n
 Chain INPUT (policy ACCEPT)
 target prot opt source   destination
 ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp
 dpt:53
 ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
 dpt:53
 ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp
 dpt:67
 ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
 dpt:67
 ACCEPT all  --  192.168.1.2120.0.0.0/0
 ACCEPT all  --  0.0.0.0/00.0.0.0/0state
 RELATED,ESTABLISHED
 ACCEPT icmp --  0.0.0.0/00.0.0.0/0
 ACCEPT all  --  0.0.0.0/00.0.0.0/0
 ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
 dpt:54321
 ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
 dpt:111
 ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp
 dpt:111
 ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
 dpt:22
 ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp
 dpt:161
 ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
 dpt:16514
 ACCEPT tcp  --  0.0.0.0/00.0.0.0/0
 multiport dports 2223
 ACCEPT tcp  --  0.0.0.0/00.0.0.0/0
 multiport dports 5900:6923
 ACCEPT tcp  --  0.0.0.0/00.0.0.0/0
 multiport dports 49152:49216
 REJECT all  --  0.0.0.0/00.0.0.0/0
 reject-with icmp-host-prohibited

 Chain FORWARD (policy ACCEPT)
 target prot opt source   destination
 ACCEPT all  --  0.0.0.0/0192.168.122.0/24 ctstate
 RELATED,ESTABLISHED
 ACCEPT all  --  192.168.122.0/24 0.0.0.0/0
 ACCEPT all  --  0.0.0.0/00.0.0.0/0
 REJECT all  --  0.0.0.0/00.0.0.0/0
 reject-with icmp-port-unreachable
 REJECT all  --  0.0.0.0/00.0.0.0/0
 reject-with icmp-port-unreachable
 REJECT all  --  0.0.0.0/00.0.0.0/0PHYSDEV
 match ! --physdev-is-bridged reject-with icmp-host-prohibited

 Chain OUTPUT (policy ACCEPT)
 target prot opt source   destination
 ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp
 dpt:68
 [root@ovirt01 ~]#


>>>
>>
>

ss log for host:

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

ss log for engine
https://drive.google.com/file/d/0BwoPbcrMv8mvWGx0QWstWG1TSWc/view?usp=sharing

agent.log
https://drive.google.com/file/d/0BwoPbcrMv8mvMFBrQ2lneFVwaGc/view?usp=sharing

broker.log
https://drive.google.com/file/d/0BwoPbcrMv8mva2Jsc3BkNkpNZFE/view?usp=sharing

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

Re: [ovirt-users] vdsm ssl errors

[Gianluca Cecchi]

On Thu, Oct 13, 2016 at 2:45 PM, Simone Tiraboschi 
wrote:

>
>
> On Thu, Oct 13, 2016 at 11:23 AM, Piotr Kliczewski 
> wrote:
>
>> Gianluca,
>>
>> The port needs to be open on machines where vdsm is installed.
>>
>> @Simone can you take a look why after running host deploy at 2016-10-03
>> 23:28:47,891
>> we are not able to talk to vdsm anymore?
>>
>
> OK, I'm on it.
>
>
>>
>> Thanks,
>> Piotr
>>
>
>> On Thu, Oct 13, 2016 at 11:15 AM, Gianluca Cecchi <
>> gianluca.cec...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Oct 13, 2016 at 11:13 AM, Gianluca Cecchi <
>>> gianluca.cec...@gmail.com> wrote:
>>>
 Il 13/Ott/2016 11:00, "Piotr Kliczewski"  ha
 scritto:
 >
 > Gianluca,
 >
 > Checking the log it seems that we do not configure firewall:
 >
 > NETWORK/firewalldEnable=bool:'False'
 > NETWORK/iptablesEnable=bool:'False'
 >
 > Please make sure that you reconfigure your firewall to open 54321
 port or let host deploy to do it for you.
 >
 > Thanks,
 > Piotr

 Hi,
 at this moment Ihave:
 On hypervisor iptables service configured and active.
 On engine firewalld service configured and active.
 Do I have to open port 54321 on host?

>>> Actually it is already...
>>>
>>> root@ovirt01 ~]# iptables -L -n
>>> Chain INPUT (policy ACCEPT)
>>> target prot opt source   destination
>>> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:53
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:53
>>> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:67
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:67
>>> ACCEPT all  --  192.168.1.2120.0.0.0/0
>>> ACCEPT all  --  0.0.0.0/00.0.0.0/0state
>>> RELATED,ESTABLISHED
>>> ACCEPT icmp --  0.0.0.0/00.0.0.0/0
>>> ACCEPT all  --  0.0.0.0/00.0.0.0/0
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
>>> dpt:54321
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
>>> dpt:111
>>> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp
>>> dpt:111
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:22
>>> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp
>>> dpt:161
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
>>> dpt:16514
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0multiport
>>> dports 2223
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0multiport
>>> dports 5900:6923
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0multiport
>>> dports 49152:49216
>>> REJECT all  --  0.0.0.0/00.0.0.0/0
>>> reject-with icmp-host-prohibited
>>>
>>> Chain FORWARD (policy ACCEPT)
>>> target prot opt source   destination
>>> ACCEPT all  --  0.0.0.0/0192.168.122.0/24 ctstate
>>> RELATED,ESTABLISHED
>>> ACCEPT all  --  192.168.122.0/24 0.0.0.0/0
>>> ACCEPT all  --  0.0.0.0/00.0.0.0/0
>>> REJECT all  --  0.0.0.0/00.0.0.0/0
>>> reject-with icmp-port-unreachable
>>> REJECT all  --  0.0.0.0/00.0.0.0/0
>>> reject-with icmp-port-unreachable
>>> REJECT all  --  0.0.0.0/00.0.0.0/0PHYSDEV
>>> match ! --physdev-is-bridged reject-with icmp-host-prohibited
>>>
>>> Chain OUTPUT (policy ACCEPT)
>>> target prot opt source   destination
>>> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:68
>>> [root@ovirt01 ~]#
>>>
>>>
>>
>

In the mean time I confirmed that even without ipv6 the situation doesn't
change

global maintenance
stop ovirt-engine service
create no-ipv6.conf under /etc/sysctl.d of engine
systemctl restart network
no more ipv6
shutdown engine
exit from maintenance and after a while engine is powered on

on host
vdsm6767 vdsm   24u IPv4   15528247  0t0   TCP
*:54321 (LISTEN)
vdsm6767 vdsm   82u IPv4   15528876  0t0   TCP
ovirt01.mydomain:54321->ovirt.mydomain:52980 (ESTABLISHED)
vdsm6767 vdsm  110u IPv4   15534849  0t0   TCP
ovirt01.mydomain:54321->ovirt.mydomain:52984 (ESTABLISHED)

on engine now
[root@ovirt host-deploy]# netstat -an|grep 54321
tcp0  0 192.168.1.212:52984 192.168.1.211:54321
ESTABLISHED
tcp0  0 192.168.1.212:52980 192.168.1.211:54321
ESTABLISHED
[root@ovirt host-deploy]#

but vdsmd has the same errors. Also restarting vdsmd

Oct 13 14:49:20 ovirt01.mydomain vdsm[6767]: vdsm vds.dispatcher ERROR SSL
error during reading data: unexpected eof

how can I force the creation of the ovirt-host-mgtmt file?
I just see that has been generated this one file
ovirt-host-mgmt-20161013124548-ovirt01.mydomain-null.log
here:
https://drive.google.com/file/d/0BwoPbcrMv8mvbXI3cndGcEtXbWs/view?usp=sharing
___

Re: [ovirt-users] oVirt AD integration problems

[cmc]

Hi Ondra,

That is good to know that we don't need Kerberos - it complicates things a
lot.

I think the errors might be the options I'd selected during the setup. I
was thrown a bit that
it passed all the internal tests provided by the setup script, but failed
on the web GUI. When
I've seen 'unspecified GSS failure' and 'peer not authenticated' it's
usually been due to
Kerberos (though admittedly these are just generic errors). So I tried the
Redhat guide for SSO at:

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Virtualization/3.6/html/Administration_Guide/Configuring_LDAP_and_Kerberos_for_Single_Sign-on.html

which uses Kerberos (in ovirt-sso.conf) I had to remove the symlink to the
Apache
config it says to create, as it results in internal server errors in
Apache. It uses an SPN for
Apache in the keytab.

Now that you've confirmed that it can actually work without any need for
the Kerberos stuff,
I will start afresh from a clean setup and apply what I've learnt during
this process.

I'll try it out and let you know either way.

Many thanks for all the help!

Kind regards,

Cam



> Yes, you really do not need anything kerberos related to securely bind
> to AD via LDAP simple bind over TLS/SSL. This is really strange to me
> what errors you are getting, but you probably configured apache (or
> something else?) to require keytab, but you don't have to, and you can
> remove that configuration.
>
>
>> Thanks,
>>
>> Cam
>>
>>
>>
>>
>> Thanks,
>>
>> Cam
>>
>> ___
>>
>> Users mailing list
>> Users@ovirt.org 
>> >
>> http://lists.ovirt.org/mailman/listinfo/users
>> 
>> > >
>>
>>
>>
>>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] vdsm ssl errors

[Simone Tiraboschi]

On Thu, Oct 13, 2016 at 2:45 PM, Simone Tiraboschi 
wrote:

>
>
> On Thu, Oct 13, 2016 at 11:23 AM, Piotr Kliczewski 
> wrote:
>
>> Gianluca,
>>
>> The port needs to be open on machines where vdsm is installed.
>>
>> @Simone can you take a look why after running host deploy at 2016-10-03
>> 23:28:47,891
>> we are not able to talk to vdsm anymore?
>>
>
> OK, I'm on it.
>

Gianluca, can you please share somehow the output of
  ss -at
on all your hosts, your /var/log/ovirt-hosted-engine-ha/agent.log and
/var/log/ovirt-hosted-engine-ha/broker.log
(maybe I simply lost them within this long thread).


>
>
>>
>> Thanks,
>> Piotr
>>
>
>> On Thu, Oct 13, 2016 at 11:15 AM, Gianluca Cecchi <
>> gianluca.cec...@gmail.com> wrote:
>>
>>>
>>>
>>> On Thu, Oct 13, 2016 at 11:13 AM, Gianluca Cecchi <
>>> gianluca.cec...@gmail.com> wrote:
>>>
 Il 13/Ott/2016 11:00, "Piotr Kliczewski"  ha
 scritto:
 >
 > Gianluca,
 >
 > Checking the log it seems that we do not configure firewall:
 >
 > NETWORK/firewalldEnable=bool:'False'
 > NETWORK/iptablesEnable=bool:'False'
 >
 > Please make sure that you reconfigure your firewall to open 54321
 port or let host deploy to do it for you.
 >
 > Thanks,
 > Piotr

 Hi,
 at this moment Ihave:
 On hypervisor iptables service configured and active.
 On engine firewalld service configured and active.
 Do I have to open port 54321 on host?

>>> Actually it is already...
>>>
>>> root@ovirt01 ~]# iptables -L -n
>>> Chain INPUT (policy ACCEPT)
>>> target prot opt source   destination
>>> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:53
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:53
>>> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:67
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:67
>>> ACCEPT all  --  192.168.1.2120.0.0.0/0
>>> ACCEPT all  --  0.0.0.0/00.0.0.0/0state
>>> RELATED,ESTABLISHED
>>> ACCEPT icmp --  0.0.0.0/00.0.0.0/0
>>> ACCEPT all  --  0.0.0.0/00.0.0.0/0
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
>>> dpt:54321
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
>>> dpt:111
>>> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp
>>> dpt:111
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:22
>>> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp
>>> dpt:161
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
>>> dpt:16514
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0multiport
>>> dports 2223
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0multiport
>>> dports 5900:6923
>>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0multiport
>>> dports 49152:49216
>>> REJECT all  --  0.0.0.0/00.0.0.0/0
>>> reject-with icmp-host-prohibited
>>>
>>> Chain FORWARD (policy ACCEPT)
>>> target prot opt source   destination
>>> ACCEPT all  --  0.0.0.0/0192.168.122.0/24 ctstate
>>> RELATED,ESTABLISHED
>>> ACCEPT all  --  192.168.122.0/24 0.0.0.0/0
>>> ACCEPT all  --  0.0.0.0/00.0.0.0/0
>>> REJECT all  --  0.0.0.0/00.0.0.0/0
>>> reject-with icmp-port-unreachable
>>> REJECT all  --  0.0.0.0/00.0.0.0/0
>>> reject-with icmp-port-unreachable
>>> REJECT all  --  0.0.0.0/00.0.0.0/0PHYSDEV
>>> match ! --physdev-is-bridged reject-with icmp-host-prohibited
>>>
>>> Chain OUTPUT (policy ACCEPT)
>>> target prot opt source   destination
>>> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:68
>>> [root@ovirt01 ~]#
>>>
>>>
>>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] [ANN] oVirt 4.0.5 Second Release Candidate is now available

[Sandro Bonazzola]

The oVirt Project is pleased to announce the availability of oVirt 4.0.5
second release candidate for testing, as of October 13th, 2016.

This release is available now for:
* Fedora 23 (tech preview)
* Red Hat Enterprise Linux 7.2 or later
* CentOS Linux (or similar) 7.2 or later

This release supports Hypervisor Hosts running:
* Red Hat Enterprise Linux 7.2 or later
* CentOS Linux (or similar) 7.2 or later
* Fedora 23 (tech preview)
* oVirt Next Generation Node 4.0

This is pre-release software. Please take a look at our community page[1]
to know how to ask questions and interact with developers and users.
All issues or bugs should be reported via oVirt Bugzilla[2].
This pre-release should not to be used in production.

This update is the second release candidate of the fifth in a series of
stabilization updates to the 4.0 series.
4.0.5 brings 9 enhancements and 49 bugfixes, including 24 high or urgent
severity fixes, on top of oVirt 4.0 series
See the release notes [3] for installation / upgrade instructions and a
list of new features and bugs fixed.

Notes:
* A new oVirt Live ISO is available. [4]
* A new oVirt Next Generation Node is available [4]
* A new oVirt Engine Appliance is available for Red Hat Enterprise Linux
and CentOS Linux (or similar)
* Mirrors[5] might need up to one day to synchronize.

Additional Resources:
* Read more about the oVirt 4.0.5 release highlights:
http://www.ovirt.org/release/4.0.5/
* Get more oVirt Project updates on Twitter: https://twitter.com/ovirt
* Check out the latest project news on the oVirt blog:
http://www.ovirt.org/blog/

[1] https://www.ovirt.org/community/
[2] https://bugzilla.redhat.com/enter_bug.cgi?classification=oVirt
[3] http://www.ovirt.org/release/4.0.5/
[4] http://resources.ovirt.org/pub/ovirt-4.0-pre/iso/
[5] http://www.ovirt.org/Repository_mirrors#Current_mirrors


-- 
Sandro Bonazzola
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] vdsm ssl errors

[Simone Tiraboschi]

On Thu, Oct 13, 2016 at 11:23 AM, Piotr Kliczewski 
wrote:

> Gianluca,
>
> The port needs to be open on machines where vdsm is installed.
>
> @Simone can you take a look why after running host deploy at 2016-10-03
> 23:28:47,891
> we are not able to talk to vdsm anymore?
>

OK, I'm on it.


>
> Thanks,
> Piotr
>

> On Thu, Oct 13, 2016 at 11:15 AM, Gianluca Cecchi <
> gianluca.cec...@gmail.com> wrote:
>
>>
>>
>> On Thu, Oct 13, 2016 at 11:13 AM, Gianluca Cecchi <
>> gianluca.cec...@gmail.com> wrote:
>>
>>> Il 13/Ott/2016 11:00, "Piotr Kliczewski"  ha
>>> scritto:
>>> >
>>> > Gianluca,
>>> >
>>> > Checking the log it seems that we do not configure firewall:
>>> >
>>> > NETWORK/firewalldEnable=bool:'False'
>>> > NETWORK/iptablesEnable=bool:'False'
>>> >
>>> > Please make sure that you reconfigure your firewall to open 54321 port
>>> or let host deploy to do it for you.
>>> >
>>> > Thanks,
>>> > Piotr
>>>
>>> Hi,
>>> at this moment Ihave:
>>> On hypervisor iptables service configured and active.
>>> On engine firewalld service configured and active.
>>> Do I have to open port 54321 on host?
>>>
>> Actually it is already...
>>
>> root@ovirt01 ~]# iptables -L -n
>> Chain INPUT (policy ACCEPT)
>> target prot opt source   destination
>> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:53
>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:53
>> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:67
>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:67
>> ACCEPT all  --  192.168.1.2120.0.0.0/0
>> ACCEPT all  --  0.0.0.0/00.0.0.0/0state
>> RELATED,ESTABLISHED
>> ACCEPT icmp --  0.0.0.0/00.0.0.0/0
>> ACCEPT all  --  0.0.0.0/00.0.0.0/0
>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
>> dpt:54321
>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:111
>> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:111
>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:22
>> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:161
>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
>> dpt:16514
>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0multiport
>> dports 2223
>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0multiport
>> dports 5900:6923
>> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0multiport
>> dports 49152:49216
>> REJECT all  --  0.0.0.0/00.0.0.0/0
>> reject-with icmp-host-prohibited
>>
>> Chain FORWARD (policy ACCEPT)
>> target prot opt source   destination
>> ACCEPT all  --  0.0.0.0/0192.168.122.0/24 ctstate
>> RELATED,ESTABLISHED
>> ACCEPT all  --  192.168.122.0/24 0.0.0.0/0
>> ACCEPT all  --  0.0.0.0/00.0.0.0/0
>> REJECT all  --  0.0.0.0/00.0.0.0/0
>> reject-with icmp-port-unreachable
>> REJECT all  --  0.0.0.0/00.0.0.0/0
>> reject-with icmp-port-unreachable
>> REJECT all  --  0.0.0.0/00.0.0.0/0PHYSDEV
>> match ! --physdev-is-bridged reject-with icmp-host-prohibited
>>
>> Chain OUTPUT (policy ACCEPT)
>> target prot opt source   destination
>> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:68
>> [root@ovirt01 ~]#
>>
>>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Unable to get HE up after update

[Susinthiran Sithamparanathan]

On Thu, Oct 13, 2016 at 10:45 AM, Yedidyah Bar David 
wrote:
> Is this file copied to [1]? The file in [1] is empty - has a size of
zero. Perhaps your engine vm suffered some serious corruption? Perhaps due
to storage/network/power problems? Please check/post the output of:

>  Yes, it was actually under engine-vm/ and not under the root, but
something happened with the sync of the file, but is synced correctly now.
Sorry for that!

> rpm -V ovirt-engine-backend
 [root@engine ~]# rpm -V ovirt-engine-backend
S.5T.  c /etc/logrotate.d/ovirt-engine
S.5T.  c /etc/pki/ovirt-engine/cacert.template.in
S.5T.  c /etc/pki/ovirt-engine/cert.template.in
S.5T.  c /etc/pki/ovirt-engine/openssl.conf
[root@engine ~]#
> [1] https://my.owndrive.com/index.php/s/3Dcyho9bqo7oZs8/
download?path=%2Fengine-vm&files=ovirt-engine.conf
-- 

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

[ovirt-users] [vdsm] status update: running containers alongside VMs

[Francesco Romani]

Hi everyone,

I'm happy to share some progress about the former "convirt"[1] project,
which aims to let Vdsm containers alongside VMs, on bare metal.

In the last couple of months I kept updating the patch series, which
is approaching the readiness to be merged in Vdsm.

Please read through this mail to see what the patchset can do now,
how you could try it *now*, even before it is merged.

Everyone is invited to share thoughts and ideas about how this effort
could evolve.
This will be a long mail; I will amend, enhance and polish the content
and make a blog post (on https://mojaves.github.io) to make it easier
to consume and to have some easy-to-find documentation. Later on the
same content will appear also on the oVirt blog.

Happy hacking!

+++

# How to try how the experimental container support for Vdsm.

Vdsm is gaining *experimental* support to run containers alongside VMs.
Vdsm had since long time the ability to manage VMs which run containers,
and recently gained support for
[atomic 
guests](http://www.projectatomic.io/blog/2015/01/running-ovirt-guest-agent-as-privileged-container/).

With the new support we are describing, you will be able to manage containers
with the same, proven infrastructure that let you manage VMs.

This feature is currently being developed and it is still not merged in the
Vdsm codebase, so some extra work is needed if you want to try it out.
We aiming to merge it in the oVirt 4.1.z cycle.

## What works, aka what to expect

The basic features are expected to work:
1. Run any docker image on the public docker registry
2. Make the container accessible from the outside (aka not just from localhost)
3. Use file-based storage for persistent volumes

## What does not yet work, aka what NOT to expect

Few things are planned and currently under active development:
1. Monitoring. Engine will not get any update from the container besides "VM" 
status (Up, Down...)
   One important drawback is that you will not be told the IP of the container 
from Engine,
   you will need to connect to the Vdsm host to discover it using standard 
docker tools.
2. Proper network integration. Some steps still need manual intervention
3. Stability and recovery - it's pre-alpha software after all! :)

## 1. Introduction and prerequisites

Trying out container support affects only the host and the Vdsm.
Besides add few custom properties (totally safe and supported since early
3.z), there are zero changes required to the DB and to Engine.
Nevertheless, we recommend to dedicate one oVirt 4.y environment,
or at least one 4.y host, to try out the container feature.

To get started, first thing you need is to setup a vanilla oVirt 4.y
installation. We will need to make changes to the Vdsm and to the
Vdsm host, so hosted engine and/or oVirt node may add extra complexity,
better to avoid them at the moment.

The reminder of this tutorial assumes you are using two hosts,
one for Vdsm (will be changed) and one for Engine (will require zero changes);
furthermore, we assume the Vdsm host is running on CentOS 7.y.

We require:
- one test host for Vdsm. This host need to have one NIC dedicated to 
containers.
  We will use the [docker macvlan 
driver](https://raesene.github.io/blog/2016/07/23/Docker-MacVLAN/),
  so this NIC *must not be* part of one bridge.
- docker >= 1.12
- oVirt >= 4.0.5 (Vdsm >= 4.18.15)
- CentOS >= 7.2

Docker >= 1.12 is avaialable for download 
[here](https://docs.docker.com/engine/installation/linux/centos/)

Caveats:
1. docker from official rpms conflicts con docker from CentOS, and has a 
different package name: docker-engine vs docker.
   Please note that the kubernetes package from CentOS, for example, require 
'docker', not 'docker-engine'.
2. you may want to replace the default service file
   [with this 
one](https://github.com/mojaves/convirt/blob/master/patches/centos72/systemd/docker/docker.service)
   and to use this
   [sysconfig 
file](https://github.com/mojaves/convirt/blob/master/patches/centos72/systemd/docker/docker-engine).
   Here I'm just adding the storage options docker requires, much like the 
CentOS docker is configured.
   Configuring docker like this can save you some troubleshooting, especially 
if you had docker from CentOS installed
   on the testing box.

## 2. Patch Vdsm to support containers

You need to patch and rebuild Vdsm.
Fetch [this 
patch](https://github.com/mojaves/convirt/blob/master/patches/vdsm/4.18.15.1/0001-container-support-for-Vdsm.patch.gz)
and apply it against Vdsm 4.18.15.1. Vdsm 4.18.15.{1,2,...} are supported as 
well.

Rebuild Vdsm and reinstall on your box.
[centos 7.2 packages are 
here](https://github.com/mojaves/convirt/tree/master/rpms/centos72)
Make sure you install the Vdsm command line client (vdsm-cli)

Restart *both* Vdsm and Supervdsm, make sure Engine still works flawlessly with 
patched Vdsm.
This ensure that no regression is introduced, and that your environment can run 
VMs just as before.
Now we can proceed adding the conta

Re: [ovirt-users] Failed to read hardware information

[Nir Soffer]

On Thu, Oct 13, 2016 at 11:28 AM, Martin Polednik  wrote:
> On 13/10/16 09:01 +0300, Dan Kenigsberg wrote:
>>
>> On Thu, Oct 13, 2016 at 11:52:17AM +1100, David Pinkerton wrote:
>>>
>>> Nir,
>>>
>>> Looks like its crashing on the dmidecode system call.
>>>
>>> I've attached the output from gbd as well as a dmidecode text dump,
>>> dmidecode binary dump and each keywords run individually.
>>>
>>> >From the keywords it look like my dmi info is corrupted.  I have
>>> download a
>>> AMI dmi editor but this only allows access to limited fields.  Do you
>>> know
>>> another tools to rewrite the dmi info?
>>
>>
>> I don't. But whatever is inside your dmi, dmidecode must not crash.
>> Which version of python-dmidecode do you have installed?
>> Would you open a bug against it?
>
>
> This is really unfortunate - I've reproduced the issue with the
> attached dump

Can you explain how do you do that?

> and it's python-dmidecode that crashes. The issue is
> actually fixed upstream, but the version at least in RHEL does not
> contain the fix.

Can you link to the missing fix?

> RHEL version:
> python-dmidecode-3.10.13-11.el7.x86_64
>
> works with (actual upstream):
> python-dmidecode-3.12.2-1.el7.x86_64
> (actually it's ~6 line change in dmioem.c)
>
> VDSM output:
> # vdsClient 0 getVdsHardwareInfo
>systemFamily = 'To Be Filled By O.E.M.'
>systemManufacturer = 'Supermicro'
>systemProductName = 'H8DM8-2'
>systemSerialNumber = '1234567890'
>systemUUID = '00020003-0004-0005-0006-000700080009'
>systemVersion = '1234567890'
>
> Although the upstream version of python-dmidecode is able to deal with
> improper DMI tables, I can't say what else will/will not behave correctly.
>
> mpolednik
>
>
>> I believe that its maintainers would appriace a simple reproducer, that
>> does not involve ovirt or Vdsm. See if you can simplify the code in
>>
>> def __leafDict(d):
>>ret = {}
>>for k, v in d.iteritems():
>>if isinstance(v, dict):
>>ret.update(__leafDict(v))
>>else:
>>ret[k] = v
>>return ret
>>
>>
>> def getAllDmidecodeInfo():
>>import dmidecode
>>
>>myLeafDict = {}
>>for k in ('system', 'bios', 'cache', 'processor', 'chassis', 'memory'):
>>myLeafDict[k] = __leafDict(getattr(dmidecode, k)())
>>return myLeafDict
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Failed to read hardware information

[Nir Soffer]

On Thu, Oct 13, 2016 at 12:29 PM, David Pinkerton  wrote:
> Good News.
>
> I installed the fedora 24 version of python-dmidecode and was able to
> successfully add the host to my cluster...
>
> Thanks you to everyone who looked at this.  I owe you a beer or at least
> some reward points   :-)

You owe us a rhel bug for dmidecode :-)


Program received signal SIGSEGV, Segmentation fault.
dmi_set_vendor (s=0x0) at src/dmioem.c:45
45if(strcmp(s, "HP") == 0)

s is a null, cannot work with strcmp

(gdb) thread apply all bt full

Thread 1 (Thread 0x77feb740 (LWP 6318)):
#0  dmi_set_vendor (s=0x0) at src/dmioem.c:45
__s1 = 0x0
__result = 
#1  0x7fffead5f66f in dmi_table (logp=logp@entry=0xaa70e0,
type=type@entry=1, base=, len=,
num=, ver=,
devmem=devmem@entry=0x7fffead645e0 "/dev/mem",
xmlnode=xmlnode@entry=0x6e5420) at src/dmidecode.c:4902
next = 
h = {type = 0 '\000', length = 252 '\374', handle = 13, data =
0xa4f4aa ""}

It look like the code is trying to get the vendor name from type 0.

The fact that this leads to sending null vendor string is a second bug.

I believe dmidecode is missing this upstream patch:
https://github.com/nirs/dmidecode/commit/6e3a3f3cd36f633a56437b42e40d6769ad8acfe7

Nir

> On Thu, Oct 13, 2016 at 7:28 PM, Martin Polednik 
> wrote:
>>
>> On 13/10/16 09:01 +0300, Dan Kenigsberg wrote:
>>>
>>> On Thu, Oct 13, 2016 at 11:52:17AM +1100, David Pinkerton wrote:

 Nir,

 Looks like its crashing on the dmidecode system call.

 I've attached the output from gbd as well as a dmidecode text dump,
 dmidecode binary dump and each keywords run individually.

 >From the keywords it look like my dmi info is corrupted.  I have
 download a
 AMI dmi editor but this only allows access to limited fields.  Do you
 know
 another tools to rewrite the dmi info?
>>>
>>>
>>> I don't. But whatever is inside your dmi, dmidecode must not crash.
>>> Which version of python-dmidecode do you have installed?
>>> Would you open a bug against it?
>>
>>
>> This is really unfortunate - I've reproduced the issue with the
>> attached dump and it's python-dmidecode that crashes. The issue is
>> actually fixed upstream, but the version at least in RHEL does not
>> contain the fix.
>>
>> RHEL version:
>> python-dmidecode-3.10.13-11.el7.x86_64
>>
>> works with (actual upstream):
>> python-dmidecode-3.12.2-1.el7.x86_64
>> (actually it's ~6 line change in dmioem.c)
>>
>> VDSM output:
>> # vdsClient 0 getVdsHardwareInfo
>>systemFamily = 'To Be Filled By O.E.M.'
>>systemManufacturer = 'Supermicro'
>>systemProductName = 'H8DM8-2'
>>systemSerialNumber = '1234567890'
>>systemUUID = '00020003-0004-0005-0006-000700080009'
>>systemVersion = '1234567890'
>>
>> Although the upstream version of python-dmidecode is able to deal with
>> improper DMI tables, I can't say what else will/will not behave correctly.
>>
>> mpolednik
>>
>>
>>> I believe that its maintainers would appriace a simple reproducer, that
>>> does not involve ovirt or Vdsm. See if you can simplify the code in
>>>
>>> def __leafDict(d):
>>>ret = {}
>>>for k, v in d.iteritems():
>>>if isinstance(v, dict):
>>>ret.update(__leafDict(v))
>>>else:
>>>ret[k] = v
>>>return ret
>>>
>>>
>>> def getAllDmidecodeInfo():
>>>import dmidecode
>>>
>>>myLeafDict = {}
>>>for k in ('system', 'bios', 'cache', 'processor', 'chassis',
>>> 'memory'):
>>>myLeafDict[k] = __leafDict(getattr(dmidecode, k)())
>>>return myLeafDict
>>> ___
>>> Users mailing list
>>> Users@ovirt.org
>>> http://lists.ovirt.org/mailman/listinfo/users
>
>
>
>
> --
>
> David Pinkerton
> Consultant
> Red Hat Asia Pacific Pty. Ltd.
> Level 11, Canberra House
> 40 Marcus Clarke Street
> Canberra 2600 ACT
>
> Mobile: +61-488-904-232
> Email: david.pinker...@redhat.com
> Web: http://apac.redhat.com/
>
>
> ___
> Users mailing list
> Users@ovirt.org
> http://lists.ovirt.org/mailman/listinfo/users
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Failed to read hardware information

[David Pinkerton]

Good News.

I installed the fedora 24 version of python-dmidecode and was able to
successfully add the host to my cluster...

Thanks you to everyone who looked at this.  I owe you a beer or at least
some reward points   :-)



On Thu, Oct 13, 2016 at 7:28 PM, Martin Polednik 
wrote:

> On 13/10/16 09:01 +0300, Dan Kenigsberg wrote:
>
>> On Thu, Oct 13, 2016 at 11:52:17AM +1100, David Pinkerton wrote:
>>
>>> Nir,
>>>
>>> Looks like its crashing on the dmidecode system call.
>>>
>>> I've attached the output from gbd as well as a dmidecode text dump,
>>> dmidecode binary dump and each keywords run individually.
>>>
>>> >From the keywords it look like my dmi info is corrupted.  I have
>>> download a
>>> AMI dmi editor but this only allows access to limited fields.  Do you
>>> know
>>> another tools to rewrite the dmi info?
>>>
>>
>> I don't. But whatever is inside your dmi, dmidecode must not crash.
>> Which version of python-dmidecode do you have installed?
>> Would you open a bug against it?
>>
>
> This is really unfortunate - I've reproduced the issue with the
> attached dump and it's python-dmidecode that crashes. The issue is
> actually fixed upstream, but the version at least in RHEL does not
> contain the fix.
>
> RHEL version:
> python-dmidecode-3.10.13-11.el7.x86_64
>
> works with (actual upstream):
> python-dmidecode-3.12.2-1.el7.x86_64
> (actually it's ~6 line change in dmioem.c)
>
> VDSM output:
> # vdsClient 0 getVdsHardwareInfo
>systemFamily = 'To Be Filled By O.E.M.'
>systemManufacturer = 'Supermicro'
>systemProductName = 'H8DM8-2'
>systemSerialNumber = '1234567890'
>systemUUID = '00020003-0004-0005-0006-000700080009'
>systemVersion = '1234567890'
>
> Although the upstream version of python-dmidecode is able to deal with
> improper DMI tables, I can't say what else will/will not behave correctly.
>
> mpolednik
>
>
> I believe that its maintainers would appriace a simple reproducer, that
>> does not involve ovirt or Vdsm. See if you can simplify the code in
>>
>> def __leafDict(d):
>>ret = {}
>>for k, v in d.iteritems():
>>if isinstance(v, dict):
>>ret.update(__leafDict(v))
>>else:
>>ret[k] = v
>>return ret
>>
>>
>> def getAllDmidecodeInfo():
>>import dmidecode
>>
>>myLeafDict = {}
>>for k in ('system', 'bios', 'cache', 'processor', 'chassis', 'memory'):
>>myLeafDict[k] = __leafDict(getattr(dmidecode, k)())
>>return myLeafDict
>> ___
>> Users mailing list
>> Users@ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>>
>


-- 

David Pinkerton
Consultant
Red Hat Asia Pacific Pty. Ltd.
Level 11, Canberra House
40 Marcus Clarke Street
Canberra 2600 ACT

Mobile: +61-488-904-232
Email: david.pinker...@redhat.com
Web: http://apac.redhat.com/ 
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] vdsm ssl errors

[Piotr Kliczewski]

Gianluca,

The port needs to be open on machines where vdsm is installed.

@Simone can you take a look why after running host deploy at 2016-10-03
23:28:47,891
we are not able to talk to vdsm anymore?

Thanks,
Piotr

On Thu, Oct 13, 2016 at 11:15 AM, Gianluca Cecchi  wrote:

>
>
> On Thu, Oct 13, 2016 at 11:13 AM, Gianluca Cecchi <
> gianluca.cec...@gmail.com> wrote:
>
>> Il 13/Ott/2016 11:00, "Piotr Kliczewski"  ha
>> scritto:
>> >
>> > Gianluca,
>> >
>> > Checking the log it seems that we do not configure firewall:
>> >
>> > NETWORK/firewalldEnable=bool:'False'
>> > NETWORK/iptablesEnable=bool:'False'
>> >
>> > Please make sure that you reconfigure your firewall to open 54321 port
>> or let host deploy to do it for you.
>> >
>> > Thanks,
>> > Piotr
>>
>> Hi,
>> at this moment Ihave:
>> On hypervisor iptables service configured and active.
>> On engine firewalld service configured and active.
>> Do I have to open port 54321 on host?
>>
> Actually it is already...
>
> root@ovirt01 ~]# iptables -L -n
> Chain INPUT (policy ACCEPT)
> target prot opt source   destination
> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:53
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:53
> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:67
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:67
> ACCEPT all  --  192.168.1.2120.0.0.0/0
> ACCEPT all  --  0.0.0.0/00.0.0.0/0state
> RELATED,ESTABLISHED
> ACCEPT icmp --  0.0.0.0/00.0.0.0/0
> ACCEPT all  --  0.0.0.0/00.0.0.0/0
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
> dpt:54321
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:111
> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:111
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:22
> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:161
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp
> dpt:16514
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0multiport
> dports 2223
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0multiport
> dports 5900:6923
> ACCEPT tcp  --  0.0.0.0/00.0.0.0/0multiport
> dports 49152:49216
> REJECT all  --  0.0.0.0/00.0.0.0/0reject-with
> icmp-host-prohibited
>
> Chain FORWARD (policy ACCEPT)
> target prot opt source   destination
> ACCEPT all  --  0.0.0.0/0192.168.122.0/24 ctstate
> RELATED,ESTABLISHED
> ACCEPT all  --  192.168.122.0/24 0.0.0.0/0
> ACCEPT all  --  0.0.0.0/00.0.0.0/0
> REJECT all  --  0.0.0.0/00.0.0.0/0reject-with
> icmp-port-unreachable
> REJECT all  --  0.0.0.0/00.0.0.0/0reject-with
> icmp-port-unreachable
> REJECT all  --  0.0.0.0/00.0.0.0/0PHYSDEV
> match ! --physdev-is-bridged reject-with icmp-host-prohibited
>
> Chain OUTPUT (policy ACCEPT)
> target prot opt source   destination
> ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:68
> [root@ovirt01 ~]#
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] vdsm ssl errors

[Gianluca Cecchi]

On Thu, Oct 13, 2016 at 11:13 AM, Gianluca Cecchi  wrote:

> Il 13/Ott/2016 11:00, "Piotr Kliczewski"  ha scritto:
> >
> > Gianluca,
> >
> > Checking the log it seems that we do not configure firewall:
> >
> > NETWORK/firewalldEnable=bool:'False'
> > NETWORK/iptablesEnable=bool:'False'
> >
> > Please make sure that you reconfigure your firewall to open 54321 port
> or let host deploy to do it for you.
> >
> > Thanks,
> > Piotr
>
> Hi,
> at this moment Ihave:
> On hypervisor iptables service configured and active.
> On engine firewalld service configured and active.
> Do I have to open port 54321 on host?
>
Actually it is already...

root@ovirt01 ~]# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source   destination
ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:53
ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:53
ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:67
ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:67
ACCEPT all  --  192.168.1.2120.0.0.0/0
ACCEPT all  --  0.0.0.0/00.0.0.0/0state
RELATED,ESTABLISHED
ACCEPT icmp --  0.0.0.0/00.0.0.0/0
ACCEPT all  --  0.0.0.0/00.0.0.0/0
ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:54321
ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:111
ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:111
ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:22
ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:161
ACCEPT tcp  --  0.0.0.0/00.0.0.0/0tcp dpt:16514
ACCEPT tcp  --  0.0.0.0/00.0.0.0/0multiport
dports 2223
ACCEPT tcp  --  0.0.0.0/00.0.0.0/0multiport
dports 5900:6923
ACCEPT tcp  --  0.0.0.0/00.0.0.0/0multiport
dports 49152:49216
REJECT all  --  0.0.0.0/00.0.0.0/0reject-with
icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target prot opt source   destination
ACCEPT all  --  0.0.0.0/0192.168.122.0/24 ctstate
RELATED,ESTABLISHED
ACCEPT all  --  192.168.122.0/24 0.0.0.0/0
ACCEPT all  --  0.0.0.0/00.0.0.0/0
REJECT all  --  0.0.0.0/00.0.0.0/0reject-with
icmp-port-unreachable
REJECT all  --  0.0.0.0/00.0.0.0/0reject-with
icmp-port-unreachable
REJECT all  --  0.0.0.0/00.0.0.0/0PHYSDEV match
! --physdev-is-bridged reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target prot opt source   destination
ACCEPT udp  --  0.0.0.0/00.0.0.0/0udp dpt:68
[root@ovirt01 ~]#
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] vdsm ssl errors

[Gianluca Cecchi]

Il 13/Ott/2016 11:00, "Piotr Kliczewski"  ha scritto:
>
> Gianluca,
>
> Checking the log it seems that we do not configure firewall:
>
> NETWORK/firewalldEnable=bool:'False'
> NETWORK/iptablesEnable=bool:'False'
>
> Please make sure that you reconfigure your firewall to open 54321 port or
let host deploy to do it for you.
>
> Thanks,
> Piotr

Hi,
at this moment Ihave:
On hypervisor iptables service configured and active.
On engine firewalld service configured and active.
Do I have to open port 54321 on host?
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

[ovirt-users] Cannot start VM because of hanging migration task

[Matt .]

HI Guys,

I did a live migration of a VM it's disk on 4.0.3 where i saw some
failures but at the end it finished well. It looked like the migration
just tried again after those failures as it should.

I have a hanging task tho and when I want to start my VM I get the following:

Cannot run VM. Related operation is currently in progress. Please try
again later.

Can I remove some lock in the database or is there a different way ?

Thanks!

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

Re: [ovirt-users] vdsm ssl errors

[Piotr Kliczewski]

Gianluca,

Checking the log it seems that we do not configure firewall:

NETWORK/firewalldEnable=bool:'False'
NETWORK/iptablesEnable=bool:'False'

Please make sure that you reconfigure your firewall to open 54321 port or
let host deploy to do it for you.

Thanks,
Piotr


On Wed, Oct 12, 2016 at 7:14 PM, Gianluca Cecchi 
wrote:

>
>
> On Wed, Oct 12, 2016 at 5:39 PM, Piotr Kliczewski 
> wrote:
>
>> This log did not help me either because during this specific time there
>> was no logs in the engine.
>>
>> 2016-10-12 09:51:35,296 INFO  [org.ovirt.engine.core.bll.sto
>> rage.domain.IsoDomainListSyncronizer] (org.ovirt.thread.pool-8-thread-13)
>> [141b5168] Finished automatic refresh process for 'ISO' file type with
>> success, for storage domain id 'fd5754f1-bd00-4337-ad64-1abde35438ae'.
>> 2016-10-12 10:42:49,188 INFO  
>> [org.ovirt.engine.core.bll.EngineBackupAwarenessManager]
>> (DefaultQuartzScheduler8) [63f92190] Backup check started.
>>
>> This means that it is not the engine attempting to connect.
>> @Simone can you please check whether this is hosted engine?
>>
>> Looking more in to the logs I see that after hostdeploy there are no more
>> attempts to connect from the engine:
>>
>> 2016-10-03 23:28:47,891 INFO  [org.ovirt.engine.core.uutils.ssh.SSHDialog]
>> (DefaultQuartzScheduler8) [4afdc494] SSH execute 'root@ractor.mynewdomain'
>> 'umask 0077; MYTMP="$(TMPDIR="${OVIRT_TMPDIR}" mktemp -d -t
>> ovirt-XX)"; trap "chmod -R u+rwX \"${MYTMP}\" > /dev/null 2>&1; rm
>> -fr \"${MYTMP}\" > /dev/null 2>&1" 0; tar --warning=no-timestamp -C
>> "${MYTMP}" -x &&  "${MYTMP}"/ovirt-host-mgmt DIALOG/dialect=str:machine
>> DIALOG/customization=bool:True'
>>
>> Later in the logs I can see bunch of redeploys but no sign of attempt to
>> connect.
>>
>> Can you please share one of the host deploy logs?
>>
>> According to the logs this is the last one: /var/log/ovirt-engine/host-dep
>> loy/ovirt-host-mgmt-20161011233340-ractor.mynewdomain-23718eb3.log
>>
>> Thanks,
>> Piotr
>>
>
> Here the file
> ovirt-host-mgmt-20161011233340-ractor.mynewdomain-23718eb3.log
> https://drive.google.com/file/d/0BwoPbcrMv8mvUTVMa1h3cVA2cGs/
> view?usp=sharing
>
>
>
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

Re: [ovirt-users] Unable to get HE up after update

[Yedidyah Bar David]

On Wed, Oct 12, 2016 at 6:41 PM, Susinthiran Sithamparanathan <
chesu...@gmail.com> wrote:

> I see.
> The logs in the root of https://my.owndrive.com/index.
> php/s/3Dcyho9bqo7oZs8.
> Thanks for your time and looking forward to be able to use my VMs again :)
>
>
> On Wed, Oct 12, 2016 at 12:13 PM, Simone Tiraboschi 
> wrote:
>
>>
>>
>> On Wed, Oct 12, 2016 at 11:47 AM, Simone Tiraboschi 
>> wrote:
>>
>>>
>>>
>>> On Tue, Oct 11, 2016 at 10:19 PM, Susinthiran Sithamparanathan <
>>> chesu...@gmail.com> wrote:
>>>
 On Tue, Oct 11, 2016 at 9:42 AM, Simone Tiraboschi >>> > wrote:

>
> No, the issue is definitively there but I was trying to identify the
> root cause.
>
 Yes, hopefully we'll pretty soon.

>
>
>> I've uploaded engine-setup logs to https://my.owndrive.com/index.
>> php/s/3Dcyho9bqo7oZs8 in the folder engine-setup and you'll see many.
>>
>
> You uploaded ovirt-hosted-engine-setup logs from the host while now we
> need engine-setup logs from the engine VM.
>
 You can find the logs under engine-vm https://my.owndrive.com/index.
 php/s/3Dcyho9bqo7oZs8. I've uploaded the other logs from the engine VM
 in case those could be useful in our debugging purpose.


>>> Thanks,
>>> I found the issue in your https://my.owndrive.com/i
>>> ndex.php/s/3Dcyho9bqo7oZs8/download?path=%2Fengine-vm%2Fsetu
>>> p&files=ovirt-engine-setup-20160908144513-wfbxna.log
>>>
>>> due to this:
>>>
>>> 2016-09-08 14:45:14 DEBUG otopi.context context._executeMethod:142
>>> method exception
>>> Traceback (most recent call last):
>>>   File "/usr/lib/python2.7/site-packages/otopi/context.py", line 132,
>>> in _executeMethod
>>> method['method']()
>>>   File "/usr/share/ovirt-engine/setup/bin/../plugins/ovirt-engine-s
>>> etup/ovirt-engine/core/advertise_dwh.py", line 65, in _init
>>> if os.path.isdir(self._engine_manual):
>>>   File "/usr/lib64/python2.7/genericpath.py", line 41, in isdir
>>> st = os.stat(s)
>>> TypeError: coercing to Unicode: need string or buffer, NoneType found
>>> 2016-09-08 14:45:14 ERROR otopi.context context._executeMethod:151
>>> Failed to execute stage 'Initializing': coercing to Unicode: need string or
>>> buffer, NoneType found
>>> 2016-09-08 14:45:14 DEBUG otopi.context context.dumpEnvironment:760
>>> ENVIRONMENT DUMP - BEGIN
>>> 2016-09-08 14:45:14 DEBUG otopi.context context.dumpEnvironment:770 ENV
>>> BASE/error=bool:'True'
>>> 2016-09-08 14:45:14 DEBUG otopi.context context.dumpEnvironment:770 ENV
>>> BASE/exceptionInfo=list:'[(,
>>> TypeError('coercing to Unicode: need string or buffer, NoneType found',),
>>> )]'
>>>
>>> engine-setup didn't completed during the upgrade process and you ended
>>> with a not working engine.
>>> I'll try to understand why it happened.
>>>
>>
>> Can you please share /usr/share/ovirt-engine/servic
>> es/ovirt-engine/ovirt-engine.conf from that engine VM?
>>
>
Is this file copied to [1]? The file in [1] is empty - has a size of zero.
Perhaps your engine vm suffered some serious corruption? Perhaps due to
storage/network/power problems? Please check/post the output of:

rpm -V ovirt-engine-backend

[1]
https://my.owndrive.com/index.php/s/3Dcyho9bqo7oZs8/download?path=%2Fengine-vm&files=ovirt-engine.conf


>
>>
>>>
>>>




 --

 Susinthiran Sithamparanathan (who forgot to send to the list + Yedidyah
 hence this email)

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


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


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

Re: [ovirt-users] Failed to read hardware information

[David Pinkerton]

python-dmidecode-3.10.13-11.el7.x86_64

I cut and pasted your python code into a file and ran python file  no
workie

I did find the attached dmidump.py on github.  It segfaults after printing
bios on line 64.

Also attached is a dump from the AMIDEDOS utility.

Happy to do whatever is required to fix this issue..  I have a couple of
months of nights and weekends invested so far...  what's a couple more.  :)






On Thu, Oct 13, 2016 at 5:01 PM, Dan Kenigsberg  wrote:

> On Thu, Oct 13, 2016 at 11:52:17AM +1100, David Pinkerton wrote:
> > Nir,
> >
> > Looks like its crashing on the dmidecode system call.
> >
> > I've attached the output from gbd as well as a dmidecode text dump,
> > dmidecode binary dump and each keywords run individually.
> >
> > >From the keywords it look like my dmi info is corrupted.  I have
> download a
> > AMI dmi editor but this only allows access to limited fields.  Do you
> know
> > another tools to rewrite the dmi info?
>
> I don't. But whatever is inside your dmi, dmidecode must not crash.
> Which version of python-dmidecode do you have installed?
> Would you open a bug against it?
>
> I believe that its maintainers would appriace a simple reproducer, that
> does not involve ovirt or Vdsm. See if you can simplify the code in
>
> def __leafDict(d):
> ret = {}
> for k, v in d.iteritems():
> if isinstance(v, dict):
> ret.update(__leafDict(v))
> else:
> ret[k] = v
> return ret
>
>
> def getAllDmidecodeInfo():
> import dmidecode
>
> myLeafDict = {}
> for k in ('system', 'bios', 'cache', 'processor', 'chassis', 'memory'):
> myLeafDict[k] = __leafDict(getattr(dmidecode, k)())
> return myLeafDict
>



-- 

David Pinkerton
Consultant
Red Hat Asia Pacific Pty. Ltd.
Level 11, Canberra House
40 Marcus Clarke Street
Canberra 2600 ACT

Mobile: +61-488-904-232
Email: david.pinker...@redhat.com
Web: http://apac.redhat.com/ 
[SMBIOS Header]
===
Name  : SMBIOS SignatureStyle : 4 BYTEs
Data  : _SM_

Name  : SMBIOS Checksum Style : BYTE
Data  : 7Fh

Name  : SMBIOS Table Length Style : BYTE
Data  : 31 bytes

Name  : SMBIOS Version  Style : WORD
Data  : 2.4

Name  : SMBIOS Max. Struc. Size Style : WORD
Data  : 254 bytes

Name  : SMBIOS Point Revision   Style : BYTE
Data  : 00h

Name  : SMBIOS Formatted Area   Style : 5 BYTEs
Data  : 00 00 00 00 00h

Name  : DMI Signature   Style : 5 BYTEs
Data  : _DMI_

Name  : DMI ChecksumStyle : BYTE
Data  : 49h

Name  : DMI Table LengthStyle : WORD
Data  : 2911 bytes

Name  : DMI Table Address   Style : DWORD
Data  : 000FC5B0h

Name  : Number of SMBIOS Stuctures  Style : WORD
Data  : 49

Name  : DMI Revisiion   Style : BYTE
Data  : 0.0

[Type 000] -- BIOS Information
===
Name  : Struc. Length   Style : BYTE
Data  : 18h

Name  : Struc. Handle   Style : WORD
Data  : h

Name  : BIOS Vendor Style : STRING
Data  : "American Megatrends Inc."

Name  : BIOS VersionStyle : STRING
Data  : "080014"

Name  : BIOS Starting Add. Seg. Style : WORD
Data  : F000h

Name  : BIOS Release Date   Style : STRING
Data  : "10/22/2009"

Name  : BIOS ROM Size   Style : BYTE
Data  : 0Fh
-- 1024 KB

Name  : BIOS CharacteristicsStyle : QWORD
Data  :  0001 7F8B DE90h
-- Bit.04:ISA is supported
-- Bit.07:PCI is Reserved
-- Bit.09:Plug and Play is supported
-- Bit.10:APM is supported
-- Bit.11:BIOS is Upgradeable(Flash)
-- Bit.12:BIOS shadowing is allowed
-- Bit.14:ESCD support is available
-- Bit.15:Boot from CD is supported
-- Bit.16:Selectable Boot is supported
-- Bit.17:BIOS ROM is socketed
-- Bit.19:EDD(Enhanced Disk Drive) Specification is supported
-- Bit.23:Int 13h - 5.25" / 1.2MB Floppy Services are supported
-- Bit.24:Int 13h - 3.5" / 720 KB Floppy Services are supported
-- Bit.25:Int 13h - 3.5" / 2.88 MB Floppy Services are supported
-- Bit.26:Int 5h, Print Screen Service is supported
-- Bit.27:Int 9h, 8042 Keyboard services a

Re: [ovirt-users] Failed to read hardware information

[Martin Polednik]

On 13/10/16 09:01 +0300, Dan Kenigsberg wrote:

On Thu, Oct 13, 2016 at 11:52:17AM +1100, David Pinkerton wrote:

Nir,

Looks like its crashing on the dmidecode system call.

I've attached the output from gbd as well as a dmidecode text dump,
dmidecode binary dump and each keywords run individually.

>From the keywords it look like my dmi info is corrupted.  I have download a
AMI dmi editor but this only allows access to limited fields.  Do you know
another tools to rewrite the dmi info?


I don't. But whatever is inside your dmi, dmidecode must not crash.
Which version of python-dmidecode do you have installed?
Would you open a bug against it?


This is really unfortunate - I've reproduced the issue with the
attached dump and it's python-dmidecode that crashes. The issue is
actually fixed upstream, but the version at least in RHEL does not
contain the fix.

RHEL version:
python-dmidecode-3.10.13-11.el7.x86_64

works with (actual upstream):
python-dmidecode-3.12.2-1.el7.x86_64
(actually it's ~6 line change in dmioem.c)

VDSM output:
# vdsClient 0 getVdsHardwareInfo
   systemFamily = 'To Be Filled By O.E.M.'
   systemManufacturer = 'Supermicro'
   systemProductName = 'H8DM8-2'
   systemSerialNumber = '1234567890'
   systemUUID = '00020003-0004-0005-0006-000700080009'
   systemVersion = '1234567890'

Although the upstream version of python-dmidecode is able to deal with
improper DMI tables, I can't say what else will/will not behave correctly.

mpolednik



I believe that its maintainers would appriace a simple reproducer, that
does not involve ovirt or Vdsm. See if you can simplify the code in

def __leafDict(d):
   ret = {}
   for k, v in d.iteritems():
   if isinstance(v, dict):
   ret.update(__leafDict(v))
   else:
   ret[k] = v
   return ret


def getAllDmidecodeInfo():
   import dmidecode

   myLeafDict = {}
   for k in ('system', 'bios', 'cache', 'processor', 'chassis', 'memory'):
   myLeafDict[k] = __leafDict(getattr(dmidecode, k)())
   return myLeafDict
___
Users mailing list
Users@ovirt.org
http://lists.ovirt.org/mailman/listinfo/users

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

Re: [ovirt-users] remote-viewer from admin vs user portal

[Simone Tiraboschi]

On Wed, Oct 12, 2016 at 11:08 PM, Gianluca Cecchi  wrote:

> Hello,
> I have the impression that there is a different behavior between admin and
> user portal when opening a VM console with remote-viewer.
> My client is an updated CentOS 7 machine and I'm using firefox on it to
> connect to oVirt 4.0.4 portals.
> If I connect to a VM (that is a Fedora 24 os) from web admin it runs
> remote-viewer.
> I switch to full screen mode and leave it some hours.
> When I come back I see a black screen and I'm not able to re-get the
> session.
> I can click on top center to pop up the menu and exit the remote-viewer
> full screen but also in window mode I'm not able to get again the desktop
> environment inside the VM (I configured Mate desktop in fedora 24 VM): it
> remains black window. The VM itsel is ok: I can close the remote-viewer
> window and open again the console and I get the desktop environment.
>
> Instead from User Portal on the same client I can open the console (again
> remote-viewer), leave the session in full screen mode and come back many
> hours later and as soon as I click or press a key I get the session ok
> (sometimes actually I get the screen saver locked of the client desktop
> environment itself, but as soon as I unlock it I can connec thent to the VM
> desktop).
>
> Any special reason for this?
>
> In both cases the command seems the same:
>
> admin portal:
>  $ ps -ef|grep remote-viewer
> g.cecchi 10356  9462  0 18:59 pts/100:00:00 grep --color=auto
> remote-viewer
> g.cecchi 16814 20129  0 01:30 ?00:00:54 /usr/bin/remote-viewer
> /tmp/mozilla_g.cecchi0/console.vv
>
> user portal (extended mode)
> $ ps -ef|grep remote-viewer
> g.cecchi 11544 20129  0 19:02 ?00:01:18 /usr/bin/remote-viewer
> /tmp/mozilla_g.cecchi0/console.vv
> g.cecchi 23534  9462  0 22:54 pts/100:00:00 grep --color=auto
> remote-viewer
>
> Not a big problem, but quite strange.
>

Ciao Gianluca,
Have you compared also the content of the two console.vv files?


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